فایلی که نباید خوانده می‌شد
برای پاسخ به پرسش پایان جلسهٔ قبل، مدیر فناوری یک آزمون دسترسی آماده کرده بود. چند سند نمونه را در محیط آزمایشی گذاشته بودند؛ بعضی عمومی و بعضی مخصوص یک گروه محدود.
با حسابی که نقش کارمند عادی داشت، از دستیار دربارهٔ مقررات پرداخت پرسید.
پاسخ سریع آمد. چند سطر توضیح، یک عدد و ارجاع به سندی که روی آن نوشته بودند: «مخصوص گروه مجاز».
مدیر منابع انسانی به نمایشگر نزدیک شد: «این حساب نباید اون فایل رو ببینه.»
مدیر فناوری گفت: «باید بررسی کنیم سند از چه مسیری وارد پاسخ شده.»
مدیر عملیات به صفحهٔ وضعیت خدمت نگاه کرد: «ولی همه‌چیز عادیه. خطا هم نداده.»
مسئول ریسک و انطباق گفت: «همین پاسخ، موضوع بررسی ماست. سامانه کار کرده، ولی باید می‌فهمیدیم آیا این کاربر اجازهٔ استفاده از اون منبع رو داشته یا نه.»
مدیرعامل پرسید: «می‌تونیم از دستیار بخوایم اطلاعات اون فایل رو در جواب نیاره؟»
مدیر فناوری مکث کرد. «قبل از اون باید روشن کنیم چرا اصلاً برای پاسخ به این کاربر، فایل رو خوانده.»
مدیرعامل پاسخ را کنار برگهٔ حدود اختیار گذاشت.
«پس کنترل رو باید در همون مسیری ببینیم که اطلاعات وارد پاسخ می‌شه. بعد از نمایش جواب، ممکنه دیر شده باشه.»
در درس دهم دیدیم هر قابلیت، خروجی و ارزیابی متناسب می‌خواهد و شیوهٔ ادارهٔ دستیار باید مسئولیت منابع و کنترل دسترسی را روشن کند. جلسه با پرسش دربارهٔ حفظ مرز دسترسی کاربران در میان منابع واحدها پایان یافت.
آزمون این جلسه همان پرسش را به یک مشاهده تبدیل کرده است: حساب کارمند عادی، از سند محدود پاسخ گرفته، درحالی‌که صفحهٔ وضعیت خدمت همه‌چیز را عادی نشان می‌دهد. برای ارزیابی امنیت، باید مسیر ورود اطلاعات به پاسخ و اجرای مجوز را ببینیم. اکنون، پس از عبور از بخش موسوم به «پرانتز فنی» دوره، وارد بخش پنجم، «امنیت، مسئولیت و نظارت انسانی»، می‌شویم.
این درس، اسلایدهای ۸۵ تا ۸۹ را به ترتیب دنبال می‌کند: دامنهٔ امنیت هوش مصنوعی، تهدیدهای آن، انحراف رفتار در یک خدمت ظاهراً سالم و کنترل مجوز پیش از خواندن منبع و پیش از اقدام.
امنیت، باید کل مسیر خدمت را پوشش دهد
کنترل‌های شناخته‌شدهٔ هویت و دسترسی، شبکه، برنامه، داده و عملیات زیرساخت، نقطهٔ شروع بررسی امنیت‌اند. با ورود هوش مصنوعی، باید اجزای دیگری از خدمت را هم در ارزیابی ببینیم.
نسبت این دامنه با امنیت سایبری و ردیابی داده، مدل و رفتار سامانه را در وقتی امنیت هوش مصنوعی از امنیت سایبری جدا می‌شود با تمرکز بر استاندارد ISO/IEC 27090 و معماری ZTAI توضیح داده‌ام.
داده از منابع مختلف وارد می‌شود و ممکن است در چند مرحله استفاده شود. مدل و تنظیمات آن تغییر می‌کنند. سامانه ممکن است به اسناد، خدمات و ابزارهای سازمانی متصل باشد. بخشی از این اجزا نیز از تأمین‌کنندگان مختلف تهیه شده‌اند.
پرسش امنیت فقط دربارهٔ ورود به محیط دستیار نیست. باید بدانیم در ادامهٔ مسیر چه اتفاقی می‌افتد: چه منبعی استفاده می‌شود، چه کسی تغییر آن را تأیید می‌کند، چه اطلاعاتی در اختیار مدل قرار می‌گیرد و چه اقدامی می‌تواند انجام شود.
برای مدیر، این دامنهٔ گسترده باید به مسئولیت‌های روشن تبدیل شود. مسئول تأیید منبع کیست؟ تغییر مدل یا تنظیمات چه بررسی‌ای می‌خواهد؟ دسترسیِ ایجادشده برای یک خدمت، تا کجا مجاز است؟ چه کسی می‌تواند استفاده از یک جزء مسئله‌دار را متوقف کند؟
پاسخ این پرسش‌ها در مرز واحدها قرار می‌گیرد. صاحب محتوا، فناوری، امنیت، صاحب فرایند و تأمین‌کننده ممکن است هرکدام بخشی از کار را انجام دهند. لازم است ارتباط مسئولیت‌ها نیز روشن باشد؛ به‌ویژه در تغییرات و رسیدگی به رخداد.
مدیر فناوری گفت: «ورود با حساب کاربری درست انجام شده. حالا باید مسیر انتخاب سند رو بررسی کنیم.»
مدیر مالی پرسید: «طبقه‌بندی فایل رو چه کسی تعیین کرده بود؟»
مسئول ریسک و انطباق گفت: «هم تعریف طبقه‌بندی رو می‌خوایم، هم شاهد اینکه در زمان استفاده رعایت شده.»
مدیرعامل گفت: «این دو تا رو کنار هم بررسی کنیم. داشتن سیاست و اجراشدن اون، هر دو باید روشن باشه.»
تهدیدها، مسئولیت بررسی متفاوتی ایجاد می‌کنند
شش گروه تهدید را بررسی می‌کنیم. هدف مدیریتی از شناخت آن‌ها این است که بدانیم چه چیزی ممکن است آسیب ببیند و از چه کسی چه شواهدی بخواهیم.
| موضوع تهدید | چه اتفاقی محل نگرانی است؟ | پرسش مدیریتی |
|---|---|---|
| مسمومیت داده‌ها | دادهٔ دستکاری‌شده بر رفتار سامانه اثر بگذارد. | ورود و تأیید منابع چگونه کنترل می‌شود؟ |
| وارونگی مدل | از رفتار مدل، اطلاعاتی دربارهٔ داده‌های آن استنباط شود. | افشای احتمالی اطلاعات حساس چگونه ارزیابی می‌شود؟ |
| سرقت مدل | اجزای مدل یا قابلیت آن به‌صورت غیرمجاز برداشت یا بازسازی شود. | دسترسی به دارایی‌های مدل و استفاده از آن چگونه حفاظت و بررسی می‌شود؟ |
| نمونه‌های خصمانه | ورودیِ هدفمند، رفتار سامانه را منحرف کند. | رفتار در ورودی‌های نامعمول یا گمراه‌کننده چگونه آزموده می‌شود؟ |
| به‌روزرسانی‌های مسموم | تغییر یک جزء، رفتار آسیب‌زا وارد خدمت کند. | منبع تغییر، تأیید انتشار و امکان بازگشت چگونه روشن است؟ |
| نشت اطلاعات | اطلاعات به فرد یا مقصد نامجاز برسد. | مجوز خواندن، استفاده و انتقال اطلاعات کجا اعمال می‌شود؟ |
برای مقابله با این تهدیدها، مجموعه‌ای از کنترل‌ها در کنار هم قرار می‌گیرند: سیاست و حکمرانی، هویت و دسترسی، پایش و کشف تهدید، حفاظت از مدل و داده، اعتبارسنجی تغییرات و تاب‌آوری خدمت.
برای بازکردن هر یک از این لایه‌ها، اصول و کنترل‌های عملی هوش مصنوعی بدون اعتماد از راستی‌آزمایی مستمر و کمترین دسترسی تا حفاظت از داده، مدل و خروجی را در کنار هم بررسی می‌کند.
برای نمونه، بررسی امنیت در زمان تحویل اولیه باید با بررسی تغییرات بعدی همراه شود. سند تازه، مدل تازه یا گسترش یک دسترسی می‌تواند وضعیت خدمت را تغییر دهد.
همچنین، نباید هر پاسخ نامناسب را پیش از بررسی علت، به یک منشأ مشخص نسبت داد. ممکن است در محتوا، مجوز، تغییرات یا نحوهٔ استفاده مسئله‌ای وجود داشته باشد. رسیدگی باید با شواهد مسیر همان درخواست انجام شود.
مدیر عملیات پرسید: «پس این مورد حتماً حمله بوده؟»
مسئول ریسک و انطباق گفت: «هنوز علت رو نمی‌دونیم. باید مشخص بشه مجوز چطور تعریف و چطور اعمال شده.»
مدیر فناوری گفت: «نسخهٔ منابع و تنظیمات این آزمون رو هم بررسی می‌کنیم. باید بتونیم همون وضعیت رو دوباره ببینیم.»
مدیرعامل گفت: «در گزارش، چیزی رو که دیدیم از چیزی که هنوز باید اثبات بشه جدا بنویسیم.»
سامانه می‌تواند روشن باشد و رفتار نامناسب داشته باشد
خدمت می‌تواند در دسترس باشد، سریع پاسخ بدهد، ورود کاربران عادی به نظر برسد و هشدار بحرانی هم نداشته باشد؛ درحالی‌که به دادهٔ آلوده یا قدیمی، متن و زمینهٔ دستکاری‌شده یا سند نامعتبر تکیه می‌کند و پاسخ نامجاز یا تصمیم منحرف می‌سازد.
این تفکیک، دامنهٔ پایش را تغییر می‌دهد. دسترس‌پذیری مهم است؛ در کنار آن باید بدانیم سامانه به چه اطلاعاتی تکیه کرده و آیا در حدود مجاز رفتار کرده است.
برای نمونه، یک متن واردشده از سند یا منبع بیرونی ممکن است حاوی دستورهایی باشد که رفتار دستیار را از وظیفهٔ اصلی منحرف کنند. خواندن یک منبع نباید به آن منبع اختیار تعیین سیاست دسترسی یا تغییر حدود کار را بدهد. راهنمای OWASP نیز به امکان انحراف رفتار از طریق محتوای منابع بیرونی توجه می‌دهد.
برای مدیر، نتیجهٔ عملی این است که گزارش خدمت باید فراتر از تعداد پاسخ و زمان انتظار باشد. باید بتوان موارد مهم را بررسی کرد: کدام منبع استفاده شده، تصمیم مجوز چه بوده، چه تغییری در خدمت رخ داده و چه بازخوردی دربارهٔ رفتار آن ثبت شده است.
در پروندهٔ ما، همین آزمون دسترسی بخشی از شواهد پذیرش است. باید با نقش‌های متفاوت بررسی کنیم چه چیزی قابل مشاهده است، چه چیزی باید مسدود شود و آیا نتیجه با سیاست مصوب سازگار است. دیدن چند پاسخ درست با یک حساب پر‌دسترسی، رعایت محدودیت کاربران دیگر را ثابت نمی‌کند.
مدیر عملیات دوباره به صفحهٔ وضعیت نگاه کرد: «این گزارش فقط می‌گه خدمت در دسترس بوده.»
مدیر فناوری گفت: «برای این مسئله، باید گزارش مجوز و منابع استفاده‌شده رو هم ببینیم.»
مدیر منابع انسانی گفت: «و آزمون رو با نقش‌های مختلف انجام بدیم. دسترسی کارشناس منابع انسانی با کارمند عادی یکی نیست.»
مدیرعامل گفت: «پس از گزارش سلامت، انتظار روشن داشته باشیم. باید معلوم بشه هر شاخص، چه چیزی رو نشان می‌ده.»
دو نقطهٔ کنترل: پیش از خواندن منبع و پیش از اقدام
دو نقطهٔ تعیین‌کننده برای اعمال کنترل داریم. این دو نقطه، همان حدودی را به اجرا وصل می‌کنند که در درس‌های قبل درباره‌شان تصمیم گرفتیم.
نقطهٔ نخست، پیش از خواندن منبع است. هویت کاربر، طبقه‌بندی اطلاعات، هدف استفاده و سیاست دسترسی باید تعیین کنند چه سندی برای پاسخ به این درخواست مجاز است.
اگر کاربر مجاز به دیدن یک سند نیست، محتوای آن نباید برای پاسخ به همان کاربر در اختیار مدل قرار بگیرد. سپردن اطلاعات به مدل و سپس انتظارِ پنهان‌کردن آن در پاسخ، کنترل دسترسی پیش از خواندن منبع را جایگزین نمی‌کند.
همچنین، ورود موفق کاربر به سامانه به معنای دسترسی به همهٔ منابع متصل نیست. مجوز باید با هویت و دامنهٔ مجاز همان کاربر در همان درخواست تطبیق داده شود.
این مرز در بازیابی اسناد را در RAG سازمانی فقط embedding نیست؛ مجوز دسترسی باید در خود بازیابی اجرا شود با مثال پاسخ درست از سند نامجاز شرح داده‌ام؛ مطالعهٔ آن، کنترل پیش از خواندن منبع را ملموس‌تر می‌کند.
نقطهٔ دوم، پیش از اقدام است. اگر دستیار به ابزاری برای ارسال، ثبت، تغییر، ارجاع یا اجرای کار متصل باشد، مجوز آن عملیات نیز باید بررسی شود. اجازهٔ خواندن یک سند، اختیار اجرای همهٔ اقدام‌های مربوط به آن را ایجاد نمی‌کند.
در این نقطه، حد اختیار، تأیید انسانیِ لازم و ثبت رویداد اهمیت دارند. در نسخهٔ فعلی پروندهٔ ما، رد خودکار درخواست خرید تصویب نشده است؛ بنابراین پیشنهاد یا متن تولیدشده نباید راهی برای اجرای همان اقدام خارج از دامنهٔ مصوب ایجاد کند.
برای ادامهٔ فنیِ بحث اجرای ابزار، اختیار محدود عامل‌های خودکار در تمام مسیر اجرا کنترل عملیات بیرون از مدل، اعتبارنامهٔ متناسب با مأموریت و امکان توقف و لغو اختیار را دنبال می‌کند.
اجرای مجوز باید در سازوکار کنترل دسترسیِ سامانه و خدمات متصل اعمال شود. خودِ پاسخ مدل یا ادعای کاربر دربارهٔ سمتش، شاهد کافی برای اجازهٔ اقدام نیست. راهنمای OWASP نیز بر اجرای عملیات در محدودهٔ مجوز همان کاربر و با کمترین دسترسی لازم تأکید دارد.
چهار اصل را کنار هم قرار می‌دهیم: اختیار متناسب با نقش، ثبت و ممیزی، کنترل در لحظهٔ اجرا و کمترین سطح دسترسی. این‌ها مبنای پرسش از تیم اجرا و تأمین‌کننده‌اند: نشان دهید محدودیت کجا اعمال می‌شود و با چه آزمونی می‌توان رعایت آن را دید.
برای پاسخ‌گویی نیز باید کارها به هم وصل باشند. صاحب محتوا و فرایند، حدود استفاده را مشخص می‌کنند؛ مسئولان اجرای کنترل، رعایت آن را در خدمت فراهم و بررسی می‌کنند؛ مرجع پذیرش، شواهد را می‌سنجد. این مسئولیت‌ها کلاه‌اند و می‌توانند میان افراد توزیع یا در یک نفر جمع شوند، اما مسیر تصمیم و رسیدگی باید روشن بماند.
کنترل، پیش از آنکه دیر شود
مدیرعامل به پاسخ آغاز جلسه برگشت: «پس برای این حساب، فایل محدود نباید وارد مسیر پاسخ می‌شد.»
مدیر فناوری گفت: «بله. باید همان‌جا مجوز بررسی و دسترسی نامجاز متوقف می‌شد.»
مدیر مالی پرسید: «اگر بعداً امکان ثبت یا ارجاع اضافه کنیم؟»
مسئول ریسک و انطباق گفت: «پیش از اجرای اون کار هم باید مجوز و حدود اختیار بررسی بشه. تصویب یک قابلیت، مجوز همهٔ اقدام‌ها نیست.»
مدیرعامل گفت: «تا نتیجهٔ این آزمون روشن و کنترل اصلاح نشده، دامنهٔ استفاده رو گسترش نمی‌دیم.»
بعد به برگه‌های سیاست و گزارش نگاه کرد: «حالا باید مطمئن بشیم این فقط یک اصلاح موردی نمی‌مونه. با کاربر تازه، سند تازه و تغییر نسخه، چطور دوباره رعایتش رو می‌سنجیم؟»
جلسه به پرسش بعدی رسیده بود: چگونه کنترل‌ها از پیگیری موردی افراد، به روشی مستند و قابل تکرار تبدیل شوند؟
در درس دوازدهم، از اسلاید ۹۰ ادامه می‌دهیم و مدل بلوغ حکمرانی را بررسی می‌کنیم. موضوع این است که سازمان چگونه سیاست، مجوزدهی، ارزیابی و پایش را در طول تغییرات، قابل تکرار و قابل پیگیری نگه می‌دارد.
این درس، یازدهمین درس مجموعهٔ «حکمرانی هوش مصنوعی در سازمان» و تشریح اسلایدهای ۸۵ تا ۸۹ دوره است. درس قبل: آیا هر مسئله‌ای به هوش مصنوعی مولد نیاز دارد؟؛ اسلایدهای کامل دوره
منابع تکمیلی: راهنمای OWASP دربارهٔ تزریق دستور از طریق ورودی‌ها و حدود اختیار سامانه‌های مبتنی بر مدل زبانی.