برای بسیاری از سازمان‌های ایرانی، ارزیابی هوش مصنوعی با چند پرسش اساسی آغاز می‌شود: آیا داده از سازمان خارج می‌شود؟ آیا کاربر به اسناد خارج از سطح دسترسی خود دسترسی پیدا می‌کند؟ در صورت افشای اطلاعات محرمانه یا تولید پاسخ نادرست، آیا علت و دامنه اثر قابل شناسایی است؟ پاسخ معتبر به این پرسش‌ها مستلزم کنترل‌های قابل آزمون است.
استقرار داخلی یا On-Premise، اختیار بیشتری در مدیریت شبکه، ذخیره‌سازی و مسیر پردازش فراهم می‌کند. با این حال، امنیت داده به مدیریت هویت، مجوز منابع، عملکرد ابزارها، نگهداری رویدادهای ثبت‌شده و آمادگی تیم عملیات نیز وابسته است. محل سرور به‌تنهایی نشان‌دهنده کیفیت این کنترل‌ها نیست.
مقایسه مدل‌های استقرار از منظر مسئولیت امنیت
محل استقرار و مسئولیت کنترل
| مسیر | مزیت قابل بررسی | پرسش ضروری |
|---|---|---|
| ابزار ابری آماده | راه‌اندازی ساده‌تر و امکانات مدیریتی متناسب با طرح انتخابی | طرح و قرارداد خدمت چیست و داده در کجا پردازش و نگهداری می‌شود؟ |
| رابط مدل ابری | امکان طراحی برنامه با خدمات مدیریت‌شده | چه داده‌ای ارسال می‌شود و آیا ارائه خدمت به سازمان مجاز است؟ |
| ابر خصوصی یا محیط اختصاصی | امکان تفکیک منابع و کنترل قراردادی | چه اشخاصی به زیرساخت، کلیدها، نسخه‌های پشتیبان و رویدادهای ثبت‌شده دسترسی دارند؟ |
| استقرار داخلی | کنترل مستقیم‌تر شبکه و محل داده | کدام تیم مسئول وصله‌های امنیتی، مدیریت هویت، پایش و بازیابی است؟ |
محرمانگی، دسترس‌پذیری و صحت پاسخ باید به‌صورت مستقل ارزیابی شوند. یک محیط ابری با تنظیمات و قرارداد مناسب ممکن است از کنترل‌های مؤثری برخوردار باشد، در حالی که یک سرور داخلی بدون نگهداری مناسب می‌تواند پرریسک باشد. همچنین خصوصی‌بودن پردازش، خطای مدل در تفسیر یک آیین‌نامه را برطرف نمی‌کند.
اصل مهم در معماری اعتماد صفر NIST این است که صرف قرارداشتن در شبکه داخلی، اعتماد خودکار ایجاد نمی‌کند. برای خدمت هوش مصنوعی نیز مجوز کاربر و منبع باید هنگام دسترسی بررسی شود.
تعیین کنترل و شواهد آزمون برای هر تهدید
جدول زیر، الگویی پیشنهادی برای طراحی و آزمون کنترل‌هاست. اجرای مؤثر این کنترل‌ها در هر محصول یا استقرار مشخص باید به‌صورت مستقل اثبات شود. درج نام یک قابلیت در کاتالوگ، جایگزین بررسی نتیجه آزمون آن نیست.
ماتریس پیشنهادی کنترل‌های امنیتی
| تهدید | کنترل اجرایی و مالک | آزمون و شواهد |
|---|---|---|
| نمایش سند غیرمجاز | اعمال مجوز در بازیابی و ابزار؛ مالک سامانه و داده | پرسش یکسان با دو نقش آزموده و گزارش منابع بازیابی‌شده ثبت شود |
| خروج داده به مقصد ناشناخته | فهرست مقصدهای مجاز و کنترل ترافیک؛ شبکه و امنیت | مسیرهای مدل، جست‌وجو، لاگ و پشتیبان بررسی و خروج غیرمجاز مسدود شود |
| دستور مخرب داخل سند | تفکیک محتوا از دستور و محدودیت اختیار ابزار؛ تیم محصول | سند آزمایشیِ دارای دستور تغییر رفتار، مجوز کاربر یا ابزار را تغییر ندهد |
| نشت اطلاعات از لاگ و حافظه موقت | حداقل‌سازی داده، محدودیت دسترسی و حذف دوره‌ای؛ تیم عملیات | متن حساس آزمایشی در گزارش عمومی یا حساب پشتیبان فاقد مجوز قابل مشاهده نباشد |
| اجرای عملیات اشتباه | ابزار محدود، اعتبارسنجی ورودی و تأیید انسانی؛ مالک فرایند | درخواست خارج از دامنه رد شود و عملیات حساس بدون تأیید اجرا نشود |
| تغییر ناامن نسخه | منشأ معتبر، بررسی تغییر و آزمون پیش از انتشار؛ زیرساخت | نسخه و نتیجه آزمون قابل پیگیری باشند و بازگشت نسخه در عمل تمرین شده باشد |
مثال فرضی: قرارداد محرمانه در پایگاه دانش
در این مثال فرضی، قرارداد واحد حقوقی وارد نمایه دانش شده است، اما سطح محرمانگی و گروه‌های مجاز آن ثبت نشده‌اند. در چنین شرایطی، کاربری از واحد دیگر ممکن است با یک پرسش عادی، خلاصه‌ای از همان قرارداد را دریافت کند. پنهان‌کردن پیوند سند در رابط کاربری یا حذف نام آن از پاسخ، مانع انتقال محتوای غیرمجاز به مدل نمی‌شود.
مجوز دسترسی باید پیش از تحویل متن بازیابی‌شده به مدل اعمال شود. اطلاعات مالک و سطح دسترسی در منبع، قطعه‌های استخراج‌شده و نسخه‌های نمایه باید معتبر باشند. استناد به منبع، بررسی صحت پاسخ را تسهیل می‌کند، اما جایگزین کنترل دسترسی نیست. تغییر واحد سازمانی کاربر یا لغو مجوز سند نیز باید در رفتار سامانه اعمال شود.
دو آزمون ضروری پیش از بهره‌برداری
آزمون اول: یک پرسش با دو هویت
در محیط آزمون، یک سند ساختگی با نشانه‌ای منحصربه‌فرد و دسترسی محدود به گروه حقوقی قرار دهید. پرسش یکسان را با یک کاربر مجاز و یک کاربر غیرمجاز اجرا کنید. برای کاربر غیرمجاز، متن یا نشانه سند نباید در پاسخ، منابع، پیشنهادهای تکمیلی یا خروجی ابزار نمایش داده شود. سپس مجوز کاربر اول را لغو و آزمون را تکرار کنید تا تأخیر همگام‌سازی مجوز نیز مشخص شود.
آزمون دوم: دستور مخرب در یک سند
به سند آزمایشی، دستوری ساختگی برای نادیده‌گرفتن قواعد و نمایش اطلاعات خارج از مجوز اضافه کنید. رفتار مورد انتظار آن است که سامانه، متن سند را داده تلقی کند و حدود دسترسی یا اختیار ابزار تغییر نکند. ارزیابی باید علاوه بر متن پاسخ، عملیات ابزار و منابع بازیابی‌شده را نیز پوشش دهد. در این آزمون نباید از اطلاعات محرمانه واقعی استفاده شود.
این تهدید با نام تزریق دستور یا Prompt Injection شناخته می‌شود و می‌تواند از درخواست کاربر یا محتوای بیرونی وارد شود. مستندات Prompt Shields مایکروسافت این دو مسیر را توضیح می‌دهد. ابزار تشخیص، یکی از کنترل‌هاست و نباید تنها مانع میان مدل و داده یا عملیات حساس باشد.
ثبت رویداد قابل ممیزی و محدودیت نگهداری اطلاعات
ثبت رویداد باید امکان پیگیری را فراهم کند و اطلاعاتی مانند شناسه درخواست، زمان، شناسه کاربر یا شناسه مستعار، نتیجه بررسی مجوز، نسخه مدل و منابع، ابزار فراخوانی‌شده و نوع خطا را در بر گیرد. نگهداری متن کامل پرسش و پاسخ باید به موارد دارای نیاز و سیاست مشخص محدود شود. مدت نگهداری، سطح دسترسی، پوشاندن داده حساس و حذف آن باید برای لاگ، خروجی پشتیبانی و نسخه پشتیبان تعریف شده باشند.
ارسال لاگ به ابزار بیرونی، حتی در صورت اجرای داخلی مدل، یک مسیر خروج داده ایجاد می‌کند. همین ملاحظه درباره جست‌وجوی وب، استخراج متن ابری و استفاده از مدل جایگزین هنگام قطعی نیز وجود دارد. نقشه جریان داده باید همه این مسیرها را پوشش دهد.
تفسیر مدیریتی شاخص‌های امنیتی
شاخص‌های پیشنهادی و محدودیت تفسیر
| شاخص | روش سنجش | نکته مدیریتی |
|---|---|---|
| مجوز منابع | تعداد آزمون‌های موفق و ناموفق به تفکیک نقش | نبود گزارش نشت، اثبات درست‌بودن همه مجوزها نیست |
| تشخیص داده حساس | نرخ موارد شناسایی‌نشده و هشدارهای کاذب در نمونه برچسب‌خورده | حجم بالای داده پوشانده‌شده، به‌تنهایی اثربخشی کنترل جلوگیری از نشت داده (DLP) را اثبات نمی‌کند |
| رسیدگی به رخداد | فاصله کشف تا مهار و بازیابی، برحسب شدت | تعداد هشدارها با رخداد تأییدشده یکسان نیست |
| خروج داده | رویدادهای مقصد غیرمجاز و نتیجه آزمون مسیرها | هم مسدودسازی و هم تلاش‌های ناموفق بررسی شوند |
| پوشش نسخه‌های امن | اجزای دارای مالک، نسخه مشخص و آزمون به‌روز | مدل، برنامه، نمایه و ابزارهای متصل همگی در دامنه ارزیابی باشند |
مدیریت و رسیدگی به رخداد امنیتی
پیش از بهره‌برداری، مسئول اعلام رخداد و حدود اختیار برای توقف مسیر آلوده را تعیین کنید. در صورت احتمال نشت، دسترسی یا اتصال مرتبط را محدود کنید، شواهد لازم را با دسترسی کنترل‌شده حفظ کنید و دامنه کاربران و داده‌های تحت تأثیر را بررسی کنید. پس از اصلاح، آزمون ناموفق و موارد مشابه باید تکرار شوند. ازسرگیری خدمت نیز باید با تأیید مسئولان تعیین‌شده انجام شود.
راهنمای مدیریت ریسک هوش مصنوعی NIST برای تعریف مسئولیت‌ها، ارزیابی و بازبینی ریسک مفید است. الزامات خاص صنعت و سازمان باید به‌صورت مستقل توسط مسئولان مربوط بررسی شوند؛ این مقاله به‌منزله گواهی انطباق نیست.
چک‌لیست پیش از بهره‌برداری
- مالک و سطح حساسیت منابع مشخص است و مجوز دسترسی در مسیر اجرا اعمال می‌شود
- ورود، لغو دسترسی، تغییر نقش و حذف سند آزمایش شده‌اند
- تزریق دستور، نشت از لاگ و ابزارهای خارج از مجوز آزموده شده‌اند
- سیاست نگهداری و حذف، شامل حافظه موقت و پشتیبان است
- پاسخ و عملیات حساس مسیر بازبینی انسانی دارند
- مسئول وصله‌های امنیتی، نسخه پشتیبان، بازیابی و رسیدگی به رخداد مشخص است
برای طراحی لایه منابع، راهنمای RAG و دانش سازمانی و برای محدودکردن عملیات، اتصال کنترل‌شده به سامانه‌های سازمانی را مطالعه کنید.
مسیر پیشنهادی بعدی
برای طراحی هوش مصنوعی با کنترل داده، نقش‌ها، ثبت رویداد و مدل‌های مجاز، صفحه هوش مصنوعی خصوصی برای سازمان، ملاحظات مسیر امن‌تر اجرا را جمع‌بندی می‌کند.
