این حادثه تیمی را بیدار کرد که تمام مدل دسترسی AWS خود را بر این باور بنا کرده بود که تنها انسان‌های دقیق، کلیدهای محیط عملیاتی (production) را در اختیار دارند. با ورود عامل‌های هوش مصنوعی (AI agents) به جریان کاری هر توسعه‌دهنده، این باور نادرست از آب درآمد. شرکت در پاسخ، یک «واسط دسترسی» (access broker) ایجاد کرد که هر عملیات در سطح عملیاتی را مجبور می‌کند از مرحله تأیید «انسان در چرخه» (human-in-the-loop) عبور کند.

چگونگی وقوع حادثه

یک مهندس از یک عامل کدنویسی هوش مصنوعی خواست تا یک اسکریپت خط لوله (pipeline script) تولید کند. این عامل، نقش IAM محیط عملیاتیِ مهندس را به ارث برد—یک هویت AWS که می‌تواند استک‌های CloudFormation را ایجاد، اصلاح و حذف کند. اسکریپت اجرا شد، یک استک در محیط زنده ایجاد کرد و بلافاصله آن را به عنوان یک مرحله «پاکسازی» حذف کرد. از آنجایی که این عملیات خط لوله استاندارد CI/CD را دور زد، موتور سیاست‌گذاری (policy engine) که معمولاً چنین تغییراتی را کنترل می‌کند، هرگز آن را ندید.

پلتفرم مانیتورینگ که برای علامت‌گذاری هر نقشی که اقدام دارای سطح دسترسی بالا را خارج از خط لوله تأیید شده انجام می‌داد، تنظیم شده بود، به محض حذف استک، هشدار داد. هیچ سرویسی از کار نیفتاد، اما این زنگ خطر سناریویی را برجسته کرد که در آن یک نام منبع اشتباه یا یک پرامپت هوش مصنوعی دارای باگ، می‌توانست زیرساخت‌های حیاتی را پاک کند.

تیم متوجه شد که شناسایی (Detection) به معنای پیشگیری (Prevention) نیست. اگر هوش مصنوعی استک اشتباهی را حذف می‌کرد، فاجعه رخ می‌داد.

چرا مدل قدیمی اعتبارنامه‌ها شکست خورد

رویکرد قبلی سازمان بر نشست‌های (sessions) کوتاه‌مدت که توسط احراز هویت چندعاملی (MFA) محافظت می‌شدند، متکی بود. در تئوری، یک توسعه‌دهنده درخواستی برای یک نشست ارسال می‌کرد، وظیفه‌ای را انجام می‌داد و اعتبارنامه‌ها به طور خودکار منقضی می‌شدند. در عمل، زمانی که یک نشست روی یک لپ‌تاپ شروع می‌شد، تا زمانی که دستگاه روشن بود، باقی می‌ماند. هر فرآیندی—از مجموعه‌های تست و اسکریپت‌های پس‌زمینه گرفته تا عامل‌های هوش مصنوعی—از آن اعتبارنامه‌ها بدون هیچ بررسی اضافی مجدداً استفاده می‌کردند.

آن مشکل «اعتبارنامه‌ی محیطی» (ambient credential)، نقش IAM محیط عملیاتی را در ایستگاه کاری توسعه‌دهنده تثبیت کرد. عامل هوش مصنوعی که به عنوان یک زیرفرآیند (subprocess) در همان shell اجرا می‌شد، همان مجوزها را به ارث برد و می‌توانست درست مانند یک انسان روی منابع محیط عملیاتی عمل کند.

واسط دسترسی: نگهبان جدید

برای شکستن زنجیره اعتبارنامه‌های محیطی، تیم معماریِ اینکه چه کسی می‌تواند نقش‌های محیط عملیاتی را بر عهده بگیرد، بازطراحی کرد. آن‌ها به جای اجازه دادن به هر هویت توسعه‌دهنده برای پذیرش مستقیم یک نقش ممتاز، یک موجودیت واحد و به شدت کنترل‌شده را معرفی کردند: یک واسط دسترسی داخلی (internal access broker).

جریان درخواست

  1. پورتال وب – مهندس یک پورتال خودخدمت (self-service) را باز می‌کند، سطح دسترسی مورد نیاز (فقط خواندنی، توسعه‌دهنده یا مدیر) را انتخاب می‌کند و دلیل درخواست را ارائه می‌دهد.
  2. تأیید در Slack – درخواست به یک کانال اختصاصی در Slack ارسال می‌شود که در آن یک تأییدکننده تعیین‌شده باید صراحتاً اجازه را صادر کند.

مرحله Slack به عنوان یک عامل دوم در پلتفرمی متفاوت از ترمینالی که عامل هوش مصنوعی در آن اجرا می‌شود، عمل می‌کند. از آنجایی که تأیید باید در یک UI جداگانه انجام شود، یک اسکریپت خودگردان نمی‌تواند به تنهایی جریان کاری را تکمیل کند.

دسترسی‌های سطح‌بندی شده

  • فقط خواندنی (Read-only) – کاربران می‌توانند منابع و لاگ‌ها را مشاهده کنند اما نمی‌توانند چیزی را تغییر دهند.
  • توسعه‌دهنده (Developer) – برای وظایف پشتیبانی و تغییرات زیرساختی در نظر گرفته شده است؛ این سطح، اقدامات مخرب مانند حذف استک یا دسترسی مستقیم به داده‌های مشتری را مسدود می‌کند.
  • مدیر (Administrator) – دارای امتیازات کامل، مخصوص مداخلات اضطراری و تنها پس از بررسی در سطوح بالاتر اعطا می‌شود.

با هدایت تمام دسترسی‌های محیط عملیاتی از طریق این واسط، تیم ریسک را به جای پراکنده کردن اعتبارنامه‌های ممتاز در هر لپ‌تاپ، در یک سرویس واحد و به شدت محافظت‌شده متمرکز کرد.

آنچه واسط در واقع از آن جلوگیری می‌کند

هدف اصلی واسط، جلوگیری از اعتبارنامه‌های محیطی است که عامل‌های هوش مصنوعی می‌توانند به طور پنهانی از آن‌ها سوءاستفاده کنند. حتی اگر یک انسان درخواستی را تأیید کند، آن تأیید یک تصمیم آگاهانه است؛ هوش مصنوعی نمی‌تواند آن مرحله را جعل کند. در نتیجه:

  • حذف‌های ناخواسته – هوش مصنوعی دیگر نمی‌تواند دستور حذف صادر کند، مگر اینکه یک انسان صراحتاً آن نشست را مجاز کرده باشد.
  • پراکندگی اعتبارنامه‌ها (Credential sprawl) – کلیدهای محیط عملیاتی دیگر روی ماشین‌های توسعه‌دهنده باقی نمی‌مانند، که این امر سطح حمله را برای افراد داخلی مخرب و بازیگران خارجی که ممکن است یک لپ‌تاپ را به خطر بیندازند، کاهش می‌دهد.

تیم تأکید می‌کند که این سیستم خطای انسانی را از بین نمی‌برد؛ یک تأیید اشتباه همچنان می‌تواند باعث آسیب شود. با این حال، ریسک «بی‌صدا»ی کد خودگردانی که بدون هیچ نقطه بازرسی انسانی روی منابع محیط عملیاتی عمل می‌کند را از بین می‌برد.

نتیجه‌گیری

وقتی عامل‌های هوش مصنوعی همان اعتبارنامه‌های بدون محدودیتی را دریافت می‌کنند که مهندسان انسانی دارند، قدرت تخریب محیط عملیاتی (production) را نیز به ارث می‌برند—آن هم اغلب بدون اینکه کسی متوجه شود. با متمرکز کردن دسترسی‌های سطح بالا (privileged access) پشت یک کارگزار (broker) که یک کانال تأیید انسانی مجزا را الزامی می‌کند، یک تیم می‌تواند مانع از آن شود که اسکریپت‌های خودگردان به‌صورت بی‌سروصدا ویرانی به بار آورند، هرچند که یک خطای انسانی همچنان می‌تواند مشکل‌ساز باشد. دستاورد واقعی در امنیت، در حذف اعتبارنامه‌های محیطی (ambient credentials) نهفته است، نه در نظارت بر تک‌تک تصمیمات فردی.