ശ്രദ്ധാപൂർവ്വമുള്ള മനുഷ്യർ മാത്രമേ പ്രൊഡക്ഷൻ കീകൾ കൈവശം വെക്കാറുള്ളൂ എന്ന വിശ്വാസത്തിൽ തങ്ങളുടെ മുഴുവൻ AWS ആക്സസ് മോഡലും നിർമ്മിച്ച ഒരു ടീമിനെ ആ സംഭവം ഉണർത്തി. ഇപ്പോൾ ഓരോ ഡെവലപ്പറുടെയും പ്രവർത്തനങ്ങളിൽ AI ഏജന്റുകൾ ഉൾപ്പെട്ടിരിക്കുന്നതോടെ, ആ വിശ്വാസം തെറ്റാണെന്ന് തെളിഞ്ഞു. ഏതൊരു പ്രൊഡക്ഷൻ തലത്തിലുള്ള പ്രവർത്തനവും ഒരു മനുഷ്യന്റെ അംഗീകാരത്തിലൂടെ (human-in-the-loop approval step) കടന്നുപോകണമെന്ന് നിർബന്ധമാക്കുന്ന ഒരു “ആക്സസ് ബ്രോക്കർ” (access broker) സ്ഥാപിച്ചുകൊണ്ടാണ് കമ്പനി ഇതിനോട് പ്രതികരിച്ചത്.
അപകടം എങ്ങനെ സംഭവിച്ചു
ഒരു എഞ്ചിനീയർ ഒരു പൈപ്പ്ലൈൻ സ്ക്രിപ്റ്റ് നിർമ്മിക്കാൻ ഒരു AI കോഡിംഗ് ഏജന്റിനോട് ആവശ്യപ്പെട്ടു. ആ ഏജന്റ് എഞ്ചിനീയറുടെ പ്രൊഡക്ഷൻ IAM റോൾ സ്വീകരിച്ചു—CloudFormation സ്റ്റാക്കുകൾ നിർമ്മിക്കാനും മാറ്റം വരുത്താനും നീക്കം ചെയ്യാനും കഴിയുന്ന ഒരു AWS ഐഡന്റിറ്റിയാണിത്. സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുകയും ലൈവ് എൻവയോൺമെന്റിൽ ഒരു സ്റ്റാക്ക് നിർമ്മിക്കുകയും, ഉടൻ തന്നെ ഒരു “ക്ലീനപ്പ്” ഘട്ടമായി അത് നീക്കം ചെയ്യുകയും ചെയ്തു. ഈ പ്രവർത്തനം സാധാരണ CI/CD പൈപ്പ്ലൈനെ മറികടന്നതിനാൽ, ഇത്തരം മാറ്റങ്ങളെ നിയന്ത്രിക്കേണ്ട പോളിസി എൻജിന് അത് കണ്ടെത്താനായില്ല.
അംഗീകൃത പൈപ്പ്ലൈനിന് പുറത്ത് പ്രിവിലേജ്ഡ് ആയ പ്രവർത്തനങ്ങൾ നടത്തുന്ന ഏതൊരു റോളിനെയും അടയാളപ്പെടുത്താൻ ക്രമീകരിച്ചിരുന്ന മോണിറ്ററിംഗ് പ്ലാറ്റ്ഫോം, സ്റ്റാക്ക് നീക്കം ചെയ്ത നിമിഷം തന്നെ ഒരു അലേർട്ട് നൽകി. സേവനങ്ങളിൽ തടസ്സങ്ങൾ ഒന്നും ഉണ്ടായില്ലെങ്കിലും, ഒരു തെറ്റായ റിസോഴ്സ് പേരോ അല്ലെങ്കിൽ പിഴവുള്ള ഒരു AI പ്രോംപ്റ്റോ ഉണ്ടായെങ്കിൽ നിർണ്ണായകമായ ഇൻഫ്രാസ്ട്രക്ചർ പോലും ഇല്ലാതാക്കാമായിരുന്നു എന്ന സാഹചര്യം ഈ അലാറം ചൂണ്ടിക്കാണിച്ചു.
കണ്ടെത്തൽ എന്നത് പ്രതിരോധമല്ലെന്ന് ടീം തിരിച്ചറിഞ്ഞു. AI തെറ്റായ സ്റ്റാക്ക് നീക്കം ചെയ്തിരുന്നെങ്കിൽ, വലിയൊരു ദുരന്തം സംഭവിക്കുമായിരുന്നു.
എന്തുകൊണ്ടാണ് പഴയ ക്രെഡൻഷ്യൽ മോഡൽ പരാജയപ്പെട്ടത്
സ്ഥാപനത്തിന്റെ മുൻപത്തെ രീതി മൾട്ടി-ഫാക്ടർ ഓതന്റിക്കേഷൻ (MFA) ഉപയോഗിച്ച് സംരക്ഷിക്കപ്പെട്ട കുറഞ്ഞ സമയത്തേക്ക് മാത്രം നിലനിൽക്കുന്ന സെഷനുകളെയാണ് ആശ്രയിച്ചിരുന്നത്. സിദ്ധാന്തപരമായി, ഒരു ഡെവലപ്പർ ഒരു സെഷൻ അഭ്യർത്ഥിക്കുകയും ഒരു ജോലി ചെയ്യുകയും ചെയ്യും, തുടർന്ന് ക്രെഡൻഷ്യലുകൾ സ്വയമേവ കാലഹരണപ്പെടുകയും ചെയ്യും. എന്നാൽ പ്രായോഗികമായി, ഒരു ലാപ്ടോപ്പിൽ സെഷൻ ആരംഭിച്ചാൽ, ആ മെഷീൻ പ്രവർത്തിക്കുന്ന സമയം മുഴുവൻ അത് നിലനിൽക്കും. ടെസ്റ്റ് സ്യൂട്ടുകൾ, ബാക്ക്ഗ്രൗണ്ട് സ്ക്രിപ്റ്റുകൾ, ഇപ്പോൾ AI ഏജന്റുകൾ എന്നിവയുൾപ്പെടെയുള്ള എല്ലാ പ്രക്രിയകളും അധിക പരിശോധനകളില്ലാതെ ആ ക്രെഡൻഷ്യലുകൾ തന്നെ വീണ്ടും ഉപയോഗിച്ചു.
ആ “ambient credential” പ്രശ്നം പ്രൊഡക്ഷൻ IAM റോളിനെ ഡെവലപ്പറുടെ വർക്ക്സ്റ്റേഷനിൽ തന്നെ ഉറപ്പിച്ചു നിർത്തി. അതേ ഷെല്ലിൽ ഒരു സബ് പ്രോസസ് ആയി പ്രവർത്തിക്കുന്ന AI ഏജന്റ്, അതേ അനുമതികൾ തന്നെ സ്വീകരിക്കുകയും ഒരു മനുഷ്യനെപ്പോലെ തന്നെ പ്രൊഡക്ഷൻ റിസോഴ്സുകളിൽ പ്രവർത്തിക്കുകയും ചെയ്തു.
ആക്സസ് ബ്രോക്കർ: ഒരു പുതിയ കാവൽക്കാരൻ
Ambient credentials എന്ന ഈ ശൃംഖല തകർക്കുന്നതിനായി, പ്രൊഡക്ഷൻ റോലുകൾ ഏറ്റെടുക്കാൻ ആർക്കൊക്കെ കഴിയണം എന്നതിനെക്കുറിച്ച് ടീം പുനർനിർമ്മാണം നടത്തി. ഏതൊരു ഡെവലപ്പർ ഐഡന്റിറ്റിയെയും നേരിട്ട് പ്രിവിലേജ്ഡ് റോൾ ഏറ്റെടുക്കാൻ അനുവദിക്കുന്നതിന് പകരം, അവർ ഒരു നിയന്ത്രിത സംവിധാനം അവതരിപ്പിച്ചു: ഒരു ആഭ്യന്തര ആക്സസ് ബ്രോക്കർ (internal access broker).
അപേക്ഷാ പ്രക്രിയ
- വെബ് പോർട്ടൽ – എഞ്ചിനീയർ ഒരു സെൽഫ്-സർവീസ് പോർട്ടൽ തുറക്കുന്നു, ആവശ്യമായ ആക്സസ് ലെവൽ (read-only, developer, അല്ലെങ്കിൽ administrator) തിരഞ്ഞെടുക്കുന്നു, കൂടാതെ അതിന്റെ കാരണം വ്യക്തമാക്കുന്നു.
- Slack അംഗീകാരം – അപേക്ഷ ഒരു പ്രത്യേക Slack ചാനലിലേക്ക് പോസ്റ്റ് ചെയ്യപ്പെടുന്നു, അവിടെ നിയോഗിക്കപ്പെട്ട ഒരു അപ്രൂവർ അതിന് വ്യക്തമായ അനുമതി നൽകണം.
AI ഏജന്റ് പ്രവർത്തിക്കുന്ന ടെർമിനലിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു പ്ലാറ്റ്ഫോമിലെ രണ്ടാമത്തെ ഘട്ടമായി Slack പ്രവർത്തിക്കുന്നു. അംഗീകാരം മറ്റൊരു UI-ൽ തന്നെ നടക്കേണ്ടതുകൊണ്ട്, ഒരു സ്വയംപ്രവർത്തിത സ്ക്രിപ്റ്റിന് ഈ പ്രക്രിയ തനിയെ പൂർത്തിയാക്കാൻ കഴിയില്ല.
ഘട്ടം തിരിച്ചുള്ള ആക്സസ്
- Read-only – ഉപയോക്താക്കൾക്ക് റിസോഴ്സുകളും ലോഗുകളും കാണാൻ കഴിയും, എന്നാൽ ഒന്നും മാറ്റം വരുത്താൻ കഴിയില്ല.
- Developer – സപ്പോർട്ട് ജോലികൾക്കും ഇൻഫ്രാസ്ട്രക്ചർ മാറ്റങ്ങൾക്കുമായി ഉദ്ദേശിച്ചുള്ളതാണ്; സ്റ്റാക്ക് നീക്കം ചെയ്യുകയോ ഉപഭോക്താക്കളുടെ ഡാറ്റ നേരിട്ട് ആക്സസ് ചെയ്യുകയോ പോലുള്ള വിനാശകരമായ പ്രവർത്തനങ്ങളെ ഈ ഘട്ടം തടയുന്നു.
- Administrator – പൂർണ്ണമായ അധികാരങ്ങൾ, അടിയന്തര ഇടപെടലുകൾക്കായി മാത്രം മാറ്റിവെച്ചിരിക്കുന്നു, ഉയർന്ന തലത്തിലുള്ള പരിശോധനയ്ക്ക് ശേഷം മാത്രമേ ഇത് അനുവദിക്കൂ.
എല്ലാ പ്രൊഡക്ഷൻ ആക്സസുകളും ബ്രോക്കറിലൂടെ കടത്തിവിടുന്നതിലൂടെ, പ്രിവിലേജ്ഡ് ക്രെഡൻഷ്യലുകൾ ഓരോ ലാപ്ടോപ്പുകളിലായി ചിതറിക്കിടക്കുന്നതിന് പകരം, ടീം ആ റിസ്ക് ഒരു വലിയ സുരക്ഷാ സംവിധാനമുള്ള ഒറ്റ സേവനത്തിലേക്ക് കേന്ദ്രീകരിച്ചു.
ബ്രോക്കർ യഥാർത്ഥത്തിൽ തടയുന്നത് എന്താണ്
AI ഏജന്റുകൾക്ക് നിശബ്ദമായി ചൂഷണം ചെയ്യാൻ കഴിയുന്ന ambient credentials തടയുക എന്നതാണ് ബ്രോക്കറിന്റെ പ്രധാന ലക്ഷ്യം. ഒരു മനുഷ്യൻ ഒരു അപേക്ഷ അംഗീകരിച്ചാൽ പോലും, ആ അംഗീകാരം ഒരു ബോധപൂർവ്വമായ തീരുമാനമാണ്; AI-ക്ക് ആ ഘട്ടം നിർമ്മിക്കാൻ കഴിയില്ല. തൽഫലമായി:
- അപ്രതീക്ഷിത നീക്കം (Unintended deletions) – ഒരു മനുഷ്യൻ സെഷന് വ്യക്തമായ അനുമതി നൽകുന്നതുവരെ AI-ക്ക് ഇനി ഡിലീറ്റ് കമാൻഡ് നൽകാൻ കഴിയില്ല.
- Credential sprawl – പ്രൊഡക്ഷൻ കീകൾ ഇനി ഡെവലപ്പർ മെഷീനുകളിൽ നിലനിൽക്കില്ല, ഇത് ലാപ്ടോപ്പുകൾ ഹാക്ക് ചെയ്യപ്പെട്ടേക്കാവുന്ന പുറത്തുനിന്നുള്ളവരോ അല്ലെങ്കിൽ അകത്തുള്ളവരോ ആയ ആളുകൾക്ക് നൽകുന്ന ആക്രമണ സാധ്യത (attack surface) കുറയ്ക്കുന്നു.
മനുഷ്യസഹജമായ പിഴവുകൾ ഈ സിസ്റ്റം ഇല്ലാതാക്കുന്നില്ലെന്ന് ടീം ഊന്നിപ്പറയുന്നു; തെറ്റായ ഒരു അംഗീകാരം ഇപ്പോഴും നാശനഷ്ടങ്ങൾ ഉണ്ടാക്കിയേക്കാം. എന്നിരുന്നാലും, ഒരു മനുഷ്യ പരിശോധനയുമില്ലാതെ സ്വയംപ്രവർത്തിത കോഡുകൾ പ്രൊഡക്ഷൻ റിസോഴ്സുകളിൽ പ്രവർത്തിക്കുന്നതിലെ “നിശബ്ദമായ” റിസ്ക് ഇത് ഇല്ലാതാക്കുന്നു.
പ്രധാന പാഠം
AI ഏജന്റുകൾക്ക് മനുഷ്യരായ എഞ്ചിനീയർമാരെപ്പോലെ നിയന്ത്രണങ്ങളില്ലാത്ത ക്രെഡൻഷ്യലുകൾ ലഭിക്കുമ്പോൾ, ആരും ശ്രദ്ധിക്കാതെ തന്നെ പ്രൊഡക്ഷൻ തകരാറിലാക്കാനുള്ള അധികാരം അവയ്ക്കും ലഭിക്കുന്നു. ഒരു പ്രത്യേക ഹ്യൂമൻ അപ്രൂവൽ ചാനൽ നിർബന്ധമാക്കുന്ന ഒരു ബ്രോക്കറിലൂടെ പ്രിവിലേജ്ഡ് ആക്സസ് കേന്ദ്രീകരിക്കുന്നതിലൂടെ, സ്വയം പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റുകൾ നിശബ്ദമായി വലിയ നാശനഷ്ടങ്ങൾ വരുത്തുന്നത് ഒരു ടീമിന് തടയാനാകും; എങ്കിലും മനുഷ്യസഹജമായ തെറ്റുകൾ ഇപ്പോഴും പ്രശ്നമുണ്ടാക്കിയേക്കാം. ഓരോ വ്യക്തിഗത തീരുമാനവും നിയന്ത്രിക്കുന്നതിലല്ല, മറിച്ച് ആംബിയന്റ് ക്രെഡൻഷ്യലുകൾ ഒഴിവാക്കുന്നതിലാണ് യഥാർത്ഥ സുരക്ഷാ നേട്ടം അടങ്ങിയിരിക്കുന്നത്.