امنیت ایجنت یک مسئلهٔ حرکت جانبی است، نه یک مسئلهٔ پرامپت

چارچوبی که مدام شکست می‌خورد

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

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

مهاجمان پیشاپیش این تغییر را انجام داده‌اند. گزارش‌ها دربارهٔ ازدحام ایجنت‌هایی که برای سرقت کارت استفاده می‌شوند، زیرساخت را توصیف می‌کنند، نه گفتگو را: فرایندهای هماهنگ‌شده‌ای که حساب می‌سازند، اعتبارنامه‌های پرداخت را نگه می‌دارند، و ارزش را از طریق سرویس‌های پایین‌دستی مسیریابی می‌کنند. ایجنت‌ها همان بار کاری‌اند. پرامپت صرفاً رابط آن است.

فروشندگان هویت به همان نتیجه‌گیری همگرا شده‌اند. کار روی هویت ایجنت — صدور هویت مستقل برای ایجنت‌ها، محدودسازی توکن‌هایشان، حسابرسی اقداماتشان — دقیقاً به این دلیل وجود دارد که یک ایجنت دارای اعتبارنامه، یک بار کاری است که به چرخهٔ عمر هویت نیاز دارد. این چارچوب درست است، و این جستار از همان موضع استدلال می‌کند.

حرکت جانبی چه شکلی است

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

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

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

دو ضریب این وضعیت را بدتر می‌کنند.

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

دوم، توکن‌های بلندمدت. توکنی با عمر چندروزه، یک تزریق موفق را به یک جای پای پایدار تبدیل می‌کند. مهاجم نیازی به تزریق مجدد ندارد؛ اعتبارنامه‌ای در دست دارد که پس از پایان گفتگویی که آن را تولید کرده، همچنان کار می‌کند. بازه‌های چرخش که با هفته اندازه‌گیری می‌شوند، یک حادثهٔ گذرا را به یک مجوز دسترسی دائمی تبدیل می‌کنند.

کنترل‌هایی که واقعاً محدود می‌کنند

کنترل‌هایی که شعاع انفجار را کاهش می‌دهند، همان‌هایی هستند که برای هر بار کاری مخصوص اعمال می‌شوند، متناسب با الگوی فراخوانی ایجنت.

اعتبارنامه‌های کوتاه‌مدت، به‌ازای هر ایجنت و هر ابزار

هر ایجنت باید هویت خودش را داشته باشد، و آن هویت باید به ابزارهای مشخصی که نیاز دارد محدود شود. اعتبارنامه‌ها باید در آغاز یک وظیفه صادر شوند و در پایان آن منقضی شوند، با یک محدودیت مخاطب صریح که ابزاری را که برای آن معتبرند نام می‌برد. توکنی که برای یک نقطهٔ پایانی تحلیلی فقط-خواندنی صادر شده، باید توسط API پیام‌رسان رد شود حتی اگر به‌درستی ارائه شده باشد.

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

فهرست‌های مجاز خروج در لایهٔ شبکه

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

معاوضهٔ صادقانه در اینجا اصطکاک است. فهرست‌های مجاز وقتی می‌شکنند که یک ابزار نقطهٔ پایانی جدیدی اضافه کند، یک فروشنده CDN را تغییر دهد، یا یک گردش‌کار مشروع به میزبان جدیدی برسد. هزینه واقعی و تکرارشونده است. با این حال از هزینهٔ یک مسیر خروج بی‌کران کمتر است، اما تیم‌ها باید برای نگهداری بودجه در نظر بگیرند نه اینکه فهرست مجاز را یک پیکربندی یک‌باره بداcode-on-screen-dark-9fc1eb-81348e.jpg)

هر فراخوانی ابزار باید با هویتی که آن را مجاز کرده، اعتبارنامهٔ استفاده‌شده، پارامترهای ارسال‌شده، و نتیجهٔ بازگشتی ثبت شود. گزارش باید فقط-افزودنی باشد و جایی ذخیره شود که ایجنت نتواند در آن بنویسد. گزارش مسیری که ایجنت می‌تواند تغییر دهد، یک رد حسابرسی نیست.

مکانیزم مهم‌تر از قالب است. یک رکورد مسیر مفید سه چیز را به هم پیوند می‌دهد: هویت ایجنت، نمونهٔ مشخص اعتبارنامه، و فراخوانی ابزار. بدون نمونهٔ اعتبارنامه، نمی‌توانید فراخوانی‌ای که پیش از چرخش انجام شده را از یکی که پس از آن انجام شده تشخیص دهید. بدون هویت ایجنت، نمی‌توانید یک حادثه را به یک ایجنت مشخص محدود کنید نه یک حساب مشترک.

ارزیابی به‌عنوان یک کنترل امنیتی

ارزیابی امنیتی برای ایجنت‌ها باید از همان الگویی پیروی کند که برای سرویس‌ها استفاده می‌شود: فرض کن ورودی خصمانه است، و اندازه‌گیری کن که خصم تا کجا می‌تواند برسد.

ایجنت را همان‌طور تیم سرخ کن که یک API را تیم سرخ می‌کردی. از هر کانالی که ایجنت می‌خواند تزریق کن — اسناد بازیابی‌شده، خروجی‌های ابزار، پیام‌های کاربر، محتوای فایل — و ببین کدام فراخوانی‌های ابزار حاصل می‌شود. هدف یافتن پرامپت‌هایی نیست که متن بد تولید می‌کنند. یافتن ورودی‌هایی است که فراخوانی‌های غیرمجاز تولید می‌کنند.

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

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

سطح حمله را منتشر کنید

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

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

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