𝗧𝗵𝗲 𝗦𝗮𝗳𝗲𝘀𝘁 𝗕𝗼𝘂𝗻𝗱𝗮𝗿𝘆 𝗜𝘀 𝗧𝗵𝗲 𝗢𝗻𝗲 𝗧𝗵𝗲 𝗔𝗴𝗲𝗻𝘁 𝗖𝗮𝗻'𝘁 𝗥𝗲𝗮𝗰𝗵 𝗔𝗰𝗿𝗼𝘀𝘀

ஒரு AI ஏஜென்ட் பல நிறுவனங்களுக்கான உள்கட்டமைப்பை (infrastructure) இயக்கினால், பாதுகாப்பு என்பது ஒரு பயங்கரமான சவாலாகிவிடும்.

ஏஜென்ட் ஏதேனும் புத்திசாலித்தனமான தவறு செய்வதில் ஆபத்து இல்லை. ஏஜென்ட் ஒரு சாதாரணமான விஷயத்தை தவறான நபருக்காகச் செய்வதில்தான் ஆபத்து உள்ளது.

வாடிக்கையாளர் A-விற்குப் பதிலாக வாடிக்கையாளர் B-க்காக ஒரு டிக்கெட்டை எழுதுவது அல்லது ஒரு ரகசியத்தை (secret) மாற்றுவது என்பது ஒரு பாதுகாப்பு மீறலாகும் (breach). ஒரு பாதுகாப்பு மீறலை நீங்கள் சரிசெய்து (patch)விட முடியாது. அதை நீங்கள் வெளிப்படையாக அறிவிக்க வேண்டும்.

பெரும்பாலான மக்கள் இதை அனுமதிகள் (permissions) மூலம் தீர்க்க முயல்கிறார்கள். ஏஜென்ட் எதைத் தொடலாம் என்பதற்கான ஒரு பட்டியலை அவர்கள் உருவாக்குகிறார்கள். ஒவ்வொரு செயலையும் அந்தப் பட்டியலுடன் ஒப்பிட்டுப் பார்க்கிறார்கள்.

இது தோல்வியடையும். அனுமதிகள் என்பது அந்தத் தரவு (resource) அங்கு இருப்பதை ஏற்றுக்கொண்டு, நீங்கள் 'இல்லை' என்று சொல்வதாகும். உங்கள் விதியில் ஏதேனும் பிழை (bug) இருந்தாலோ அல்லது ஒரு சூழலை நீங்கள் கவனிக்கத் தவறினாலோ, ஏஜென்ட் தவறான தரவை அணுகிவிடும்.

நான் ஒரு மாறுபட்ட மாதிரியைப் பயன்படுத்துகிறேன். தவறான தரவை அதன் கட்டமைப்பிலேயே (structurally) இல்லாமல் செய்துவிடுகிறேன்.

வாடிக்கையாளர் A-விற்கான ஒரு அமர்வில் (session), வாடிக்கையாளர் B-க்கான வளங்கள் (resources) அங்கு இருக்காது. அங்கீகரிக்கப்பட்ட விவரங்கள் (credentials) ஏற்றப்படாது. எண்ட்-பாயிண்ட்கள் (endpoints) வரைபடத்தில் இருக்காது. அங்கு கேட்க எதுவுமே இல்லை, எனவே மறுப்பதற்கு எதுவுமே இல்லை.

விதிகளில் பிழைகள் இருக்கலாம். ஆனால் அமைப்பின் (system) இயற்பியல் கட்டமைப்பில் பிழைகள் இருக்காது.

இதை நான் கடினமான அனுபவத்தின் மூலம் கற்றுக்கொண்டேன். ஒரு secrets manager போதுமானது என்று நான் நினைத்தேன். ரகசியங்களைப் பிரித்து வைப்பதன் மூலம் வாடிக்கையாளர்களைப் (tenants) பிரித்துவிடலாம் என்று நினைத்தேன். நான் தவறாக இருந்தேன்.

ஒரு secrets manager ரகசியங்களைப் பிரிக்கிறது, ஆனால் அது எண்ட்-பாயிண்ட்களைப் பிரிப்பதில்லை. ஒரு ஏஜென்ட் வாடிக்கையாளர் A-விற்கான சரியான டோக்கனை (token) வைத்திருந்தாலும், அந்த முகவரி உள்ளமைப்பில் (configuration) இருந்தால், அது வாடிக்கையாளர் B-யின் முகவரிக்கு கோரிக்கையை அனுப்பக்கூடும்.

கசிவு ரகசியத்தில் இல்லை. கசிவு ரூட்டிங்கில் (routing) உள்ளது.

ஒவ்வொரு வளத்தையும் ஒரே பதிவில் (record) இணைப்பதன் மூலம் இதை நான் சரிசெய்தேன்: • Resource • Endpoint • Credential • Owning tenant

உரிமையாளரைத் தெரியாமல் உங்களால் முகவரியைப் பெற முடியாது. தரவை அனுப்பும் லைப்ரரி (library), அமர்வுடன் (session) வாடிக்கையாளர் பொருந்தவில்லை என்றால் வேலை செய்ய மறுத்துவிடும். நீங்கள் இதை ஹார்ட்கோட் (hardcode) செய்து தவிர்க்க முடியாது, ஏனெனில் முகவரி அதன் உரிமையாளருடன் இணைக்கப்பட்டிருக்கும் போது மட்டுமே இருக்கும்.

நான் மூன்று அடுக்கு பாதுகாப்பைப் பயன்படுத்துகிறேன்:

  • கட்டமைப்புத் தனிமைப்படுத்தல் (Structural isolation) - இதனால் தவறான தரவு அங்கு இருக்காது.
  • ஒரு பைபாஸ் பிளாக் (bypass block) - இதனால் ஏஜென்ட் சோதனைகளைத் தவிர்க்க நேரடித் கருவிகளைப் பயன்படுத்த முடியாது.
  • எக்ரெஸ் ஸ்கோப்பிங் (Egress scoping) - இதனால் அமர்வு அனுமதிக்கப்பட்ட முகவரிகளுடன் மட்டுமே பேச முடியும்.

இது 'fails closed' எனப்படும் ஒரு அமைப்பை உருவாக்குகிறது.

எனது முந்தைய வேலையில், 'failing open' முறையை நான் ஆதரித்தேன். ஒரு செயல் பாதுகாப்பானதா என்பதில் ஏஜென்ட்டுக்குத் தெரியவில்லை என்றால், அது தொடர வேண்டும் என்று நான் கருதினேன். ஒவ்வொரு சந்தேகத்திலும் முடங்கிப்போகும் ஒரு ஏஜென்ட் பயனற்றது.

ஆனால் வாடிக்கையாளர் எல்லைகள் (tenant boundaries) வேறுபட்டவை. தான் எதன் தரவைத் தொடுகிறோம் என்பதில் ஏஜென்ட்டுக்குத் தெரியவில்லை என்றால், அது கண்டிப்பாக நிறுத்தப்பட வேண்டும்.

செயலில் உள்ள நிச்சயமற்ற தன்மை இயக்கத்திற்கு வழிவகுக்கிறது. உரிமையில் உள்ள நிச்சயமற்ற தன்மை அமைதிக்கு வழிவகுக்க வேண்டும்.

'இல்லை' என்று சொல்லும் சரிபார்ப்புகளை உருவாக்காதீர்கள். சரிபார்க்க வேண்டிய வடிவங்களை நீக்கிவிடுங்கள்.

மூலம்: https://dev.to/artemmatviychuk/the-safest-boundary-is-the-one-the-agent-cant-reach-across-20ad

விருப்பத்தேர்வு கற்றல் சமூகம்: https://t.me/GyaanSetuAi