شهریور
آموزش هوش مصنوعی
مدل تهدید برای یک ایجنت؛ چه کسی چه چیزی را میتواند دستکاری کند
یک ایجنت هوش مصنوعی برخلاف یک اسکریپت ساده، ورودیهای متعددی از منابع مختلف دریافت میکند — دستور کاربر، محتوای یک صفحهٔ وب، پاسخ یک API، نتیجهٔ یک جستوجو — و بر اساس همهٔ آنها تصمیم میگیرد چه ابزاری را با چه پارامتری اجرا کند. این ترکیب، سطح حملهای متفاوت از یک برنامهٔ سنتی ایجاد میکند. پیش از آنکه هر ایجنتی به تولید برود، باید مشخص شود چه کسی میتواند روی رفتار آن اثر بگذارد و آن اثر چه حدی از آسیب ممکن است داشته باشد. این کار را مدل تهدید (threat model) مینامند، و این مقاله چارچوبی برای ساختن آن ارائه میدهد — بدون شرح هیچ روش اجرای حمله.
لیست مطالب
چرا ایجنت با نرمافزار معمولی فرق دارد
در نرمافزار سنتی، مسیر اجرا از پیش مشخص است؛ ورودی کاربر در قالبهای محدودی پردازش میشود. یک ایجنت مبتنی بر مدل زبانی اما تصمیم میگیرد — و این تصمیم میتواند تحت تأثیر هر متنی قرار گیرد که در بافت (context) آن قرار میگیرد، نه فقط دستور مستقیم کاربر. اگر ایجنت یک صفحهٔ وب، یک ایمیل یا خروجی یک ابزار را میخواند، آن محتوا هم بخشی از ورودی تصمیمگیری میشود. مدل تهدید باید همهٔ این منابع را بهعنوان سطح حمله (attack surface) در نظر بگیرد، نه فقط کادر چت.
چهار سؤال پایه برای مدلسازی تهدید
برای هر ایجنت، پیش از استقرار، پاسخ این چهار سؤال باید مکتوب باشد:
- چه داراییهایی در معرض خطرند؟ داده مشتری، اعتبار پرداخت، دسترسی به سیستمهای داخلی، اعتبار برند (اگر ایجنت پیام عمومی میفرستد).
- چه کسی ورودی به ایجنت میدهد؟ کاربر نهایی، یک سیستم دیگر (API)، یا محتوای بیرونی که ایجنت خودش واکشی میکند (صفحهٔ وب، فایل آپلودشده، ایمیل).
- ایجنت به چه ابزارهایی دسترسی دارد؟ هر ابزار (خواندن دیتابیس، ارسال ایمیل، اجرای کد، پرداخت) یک مسیر بالقوهٔ اثرگذاری روی دنیای واقعی است.
- مرز اعتماد کجاست؟ کدام بخش از ورودی «قابلاعتماد» فرض میشود (مثلاً دستور مستقیم صاحب سیستم) و کدام بخش «داده» است که فقط باید خوانده شود، نه بهعنوان دستور اجرا شود.
دستهبندی تهدیدها برای یک ایجنت
در امنیت سنتی از چارچوبهایی مثل STRIDE استفاده میشود؛ برای ایجنتها میتوان نسخهٔ سادهشدهای از دستهبندی تهدید به کار برد که روی نتیجه تمرکز دارد، نه روش اجرا:
| دستهٔ تهدید | توصیف ریسک (بدون روش اجرا) | مثال کنترل دفاعی |
|---|---|---|
| دستکاری بافت (context manipulation) | محتوای بیرونی که ایجنت میخواند، میتواند حاوی متنی باشد که تلاش میکند رفتار ایجنت را تغییر دهد | جداسازی محتوای بیرونی از دستور سیستم؛ برچسبگذاری صریح منبع هر بخش از بافت |
| سوءاستفاده از ابزار | یک ابزار با دسترسی گسترده میتواند برای کاری غیر از هدف اصلیاش استفاده شود | کمترین دسترسی ممکن برای هر ابزار؛ تفکیک ابزار خواندن از نوشتن |
| افشای داده | ایجنت ممکن است دادهای را در پاسخی نمایش دهد که قرار نبوده در دسترس آن مخاطب باشد | فیلتر خروجی؛ کنترل دسترسی در سطح داده نه فقط سطح ایجنت |
| افزایش پیامد خطا (blast radius) | یک تصمیم اشتباه ایجنت میتواند بهجای یک اثر کوچک، اثر گسترده روی سیستم بگذارد | محدود کردن دامنهٔ عملیات هر اجرا؛ نیاز به تأیید انسانی برای اقدامات برگشتناپذیر |
| تقلید هویت (impersonation) | ورودی میتواند وانمود کند از یک منبع معتبرتر (مثلاً مدیر سیستم) میآید | احراز هویت واقعی در سطح سیستم، نه اتکا به ادعای متنی در بافت |
مرز اعتماد؛ مهمترین مفهوم این مدل
شاید مهمترین تصمیم طراحی یک ایجنت امن، تعیین دقیق مرز اعتماد است: کدام ورودی «دستور» است و کدام «داده». دستور سیستم که توسط صاحب واقعی سرویس تنظیم شده، در بالاترین سطح اعتماد قرار دارد. محتوایی که ایجنت از منابع بیرونی (وب، ایمیل ورودی، فایل کاربر) میخواند، باید همیشه بهعنوان «دادهای که باید خوانده شود» در نظر گرفته شود، نه چیزی که اختیار تصمیمگیری ایجنت را تغییر میدهد. این تفکیک، موضوع اصلی مقالهٔ بعدی این مجموعه دربارهٔ پاکسازی ورودی است.
مدل تهدید یک سند زنده است
مدل تهدید یک بار نوشته نمیشود و کنار گذاشته نمیشود. هر بار که یک ابزار جدید به ایجنت اضافه میشود، یا منبع دادهٔ جدیدی به بافت آن وصل میشود، داراییها و سطح دسترسی تغییر میکند و مدل باید بهروزرسانی شود. یک روال ساده و عملی، بازبینی مدل تهدید هر بار پیش از افزودن یک قابلیت جدید به ایجنت است — نه فقط یکبار در ابتدای پروژه.
برای گام بعدی — طراحی دسترسی محدود برای هر ابزار — نقشهٔ راه امنیت هوش مصنوعی و راهنمای ایجنتهای هوش مصنوعی منابع خوبی برای ادامهٔ مطالعه هستند.
مستندسازی مدل تهدید؛ فرمت پیشنهادی
یک مدل تهدید که فقط در ذهن یک نفر وجود دارد، عملاً وجود ندارد. فرمت پیشنهادی برای مستندسازی میتواند ساده باشد: یک جدول با ستونهای «دارایی»، «منبع تهدید»، «سطح اعتماد فعلی»، و «کنترل دفاعی فعال». این سند باید در کنار کد ایجنت نگهداری شود (نه در یک فایل جداگانه که فراموش میشود) و بخشی از فرایند بازبینی کد برای هر تغییر مرتبط با ابزار یا منبع داده باشد. تیمهایی که این سند را در همان مخزن کد (repository) نگه میدارند، معمولاً بهتر متوجه میشوند که یک Pull Request خاص داراییها یا مرز اعتماد را تغییر داده است.
چه کسی باید مدل تهدید را بنویسد
نوشتن مدل تهدید صرفاً وظیفهٔ تیم امنیت نیست؛ کسی که بیشترین دانش را دربارهٔ رفتار واقعی ایجنت دارد — معمولاً همان توسعهدهندهای که ابزارها را طراحی کرده — باید نسخهٔ اولیه را بنویسد، و سپس یک نفر مستقل (تیم امنیت، یا حتی یک همکار دیگر) آن را بازبینی کند. این جفتِ «نویسنده + بازبین مستقل» از کوری ناشی از آشنایی بیشازحد با سیستم (که باعث نادیده گرفتن ریسکهای بدیهی میشود) جلوگیری میکند.
جمعبندی
- سطح حمله یک ایجنت شامل هر منبعی میشود که وارد بافت آن میشود، نه فقط دستور مستقیم کاربر.
- پیش از استقرار، داراییها، منابع ورودی، ابزارهای در دسترس و مرز اعتماد را صریح مکتوب کنید.
- تفکیک بین «دستور قابلاعتماد» و «دادهای که باید فقط خوانده شود» مهمترین تصمیم طراحی است.
- هر ابزار جدید یا منبع دادهٔ جدید، داراییها و ریسک را تغییر میدهد؛ مدل تهدید باید مرتب بهروزرسانی شود.
- روی نتیجهٔ ریسک (چه چیزی آسیب میبیند) تمرکز کنید، نه روش دقیق اجرای یک حمله.
