فهرست این فصلبخش ۳، فصل ۲۷
بخش ۳، فصل ۲۷
کاربرد در سازمان‌های ایرانی — امنیت یادگیری ماشین خصمانه: از رده‌شناسی تا کنترل عملیاتی
متن اصلی فارسی با منشأ، شناسه و پیوند استناد پایدار.
تفسیر اجرایی تدوینگر: رده‌شناسی AML در روزمرهٔ یک سازمان ایرانی
رده‌شناسی «یادگیری ماشین خصمانه» (AML) برای یک سازمان ایرانی در عمل یعنی اینکه مدل‌های هوش مصنوعی دیگر صرفاً «نرم‌افزار» نیستند؛ دارایی‌هایی داده‌محورند که ماهیت آماری آن‌ها بردارهای حملهٔ تازه‌ای فراتر از تهدیدهای نرم‌افزار سنتی در برابر سازمان می‌گشاید. در لایهٔ اجرایی این کتاب پیشنهاد می‌شود این پیام در سه محور به زبان سازمانی ترجمه شود:
- محور دارایی: هر مدل، مجموعه‌دادهٔ آموزشی، خط لولهٔ داده و سرویس استنتاج (API) یک دارایی اطلاعاتی است؛ باید شناسایی، ارزش‌گذاری، دارای مالک و در فهرست دارایی‌ها ثبت شود.
- محور تهدید: اهداف مهاجم در سه دستهٔ «فروپاشی دسترس‌پذیری»، «نقض یکپارچگی» و «به‌خطرافتادن حریم خصوصی» گزارش شده است؛ برای هر دارایی باید مشخص کنید کدام دسته دربارهٔ آن قابل تصور است و چه توانمندی و دانشی از مهاجم فرض می‌شود (جعبه‌سفید/جعبه‌سیاه).
- محور چرخهٔ عمر: حمله می‌تواند در «مرحلهٔ آموزش» یا «مرحلهٔ استقرار» رخ دهد؛ کنترل‌ها باید هر دو مرحله و مرز میان آن‌ها — داده‌های بیرونی، مدل‌های پیش‌آموزش‌دیدهٔ ثالث، به‌روزرسانی‌ها و افزونه‌ها — را پوشش دهند.
واحدهای درگیر: این موضوع فقط مسئلهٔ تیم AI/ML نیست؛ CISO (نقش معادل سازمانی: مدیر ارشد امنیت اطلاعات)، تیم داده، مهندسی نرم‌افزار، SOC و زیرساخت (کنترل‌های عملیاتی و پایش)، مدیر ریسک و انطباق (رجیستر و سیاست)، حقوقی و حریم خصوصی (داده‌های اشخاص و قراردادها)، تدارکات (مدل‌ها و خدمات ثالث) و ممیزی داخلی (شواهد) همگی درگیر می‌شوند. ممکن است بسته به صنعت و مقررات حاکم، الزامات دیگری نیز اعمال شود.
مدارک، تصمیم‌ها و شواهد لازم: فهرست دارایی‌های هوش مصنوعی، رجیستر ریسک AML، مدل تهدید مختص هر کاربرد، مدارک آزمون (تزریق دستور، نمونه‌های خصمانه)، لاگ پرس‌وجو و خروجی API، قراردادهای تأمین مدل و داده و صورت‌جلسات پذیرش ریسک. تصمیم‌های کلیدی عبارت‌اند از: تعیین دامنهٔ برنامهٔ امنیت هوش مصنوعی، آستانهٔ ریسک‌پذیری، مجوز یا توقف استقرار هر مدل پرریسک و انتخاب منابع مدل و داده.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P03-C27-S01
شناسهٔ محتوا KDJ-AI-2026E1-P03-C27-S01-3BD6EB29
راهنمای اجرای عملی: برپایی برنامهٔ امنیت یادگیری ماشین خصمانه
جعبهٔ پیاده‌سازی زیر «نمونهٔ پیشنهادی تدوینگر بر پایهٔ مفاهیم مطرح‌شده در منابع این بخش» است؛ اندازه و جزئیات آن را متناسب با مقیاس و بلوغ سازمان خود تنظیم کنید.
| فیلد | شرح پیشنهادی |
|---|---|
| هدف | برقراری کنترل‌های عملیاتی امنیت یادگیری ماشین خصمانه (AML) بر دارایی‌های هوش مصنوعی سازمان |
| دامنه | همهٔ مدل‌های در تولید یا توسعه، خط لوله‌های داده، سرویس‌های استنتاج (API) و مدل‌های ثالث یا پیش‌آموزش‌دیده |
| مسئول اصلی | CISO با هم‌راهی AI Officer (نقش معادل سازمانی: مدیر راهبری هوش مصنوعی یا دبیر کمیتهٔ هوش مصنوعی) |
| واحدهای درگیر | تیم AI/ML، تیم داده، مهندسی نرم‌افزار، SOC، زیرساخت، تدارکات، حقوقی، حریم خصوصی، مدیر ریسک، ممیزی داخلی |
| پیش‌نیازها | فهرست دارایی‌ها، سیاست امنیت اطلاعات موجود، تعیین مالک هر مدل، بودجهٔ آزمون و پایش |
| ورودی‌ها | فهرست مدل‌ها و کاربردها، توصیف داده‌های آموزشی و منابع آن‌ها، قراردادهای تأمین‌کننده، نتایج ارزیابی ریسک |
| فعالیت‌ها | مدل‌سازی تهدید، انتخاب کنترل‌های کاهنده، آزمون‌های امنیتی مدل، اتصال لاگ‌ها به SIEM، تمرین پاسخ به رخداد |
| خروجی‌ها | رجیستر ریسک AML، مجموعه‌کنترل مصوب، برنامهٔ پایش، گزارش وضعیت برای مدیریت ارشد |
| مدارک مورد نیاز | سیاست امنیت هوش مصنوعی، رویهٔ ثبت و انتشار مدل، رویهٔ پاسخ به رخداد هوش مصنوعی، فرم ارزیابی تأمین‌کننده |
| شواهد قابل ممیزی | صورت‌جلسات کمیتهٔ ریسک، گزارش آزمون‌ها، لاگ‌های SIEM، مدارک بازبینی دوره‌ای، نسخه‌های تاریخ‌دار رجیستر ریسک |
| KPIها (نمونه تدوینگر) | پوشش فهرست دارایی‌ها؛ درصد مدل‌های پرریسک دارای مدل تهدید مستند؛ میانگین زمان ترمیم یافته‌های امنیتی مدل |
| ریسک‌ها | کمبود مهارت AML، پراکندگی مدل‌های ثبت‌نشده (AI سایه)، اتکا به مدل‌های ثالث ارزیابی‌نشده، حجم بالای لاگ |
| کنترل‌ها | آموزش هدفمند، الزام ثبت پیش از استقرار، ارزیابی اجباری تأمین‌کننده، نمونه‌برداری و نگه‌داشت هوشمند لاگ |
| تناوب بازبینی | فصلی برای رجیستر ریسک؛ شش‌ماهه برای سیاست؛ سالانه برای دامنهٔ کامل برنامه |
| سطح بلوغ پیشنهادی | آغاز در سطح ۱ و رسیدن به سطح ۳ طی ۱۲ تا ۱۸ ماه (ر.ک. مدل بلوغ در پایان این فصل) |
نمونه فرم — رجیستر ریسک یادگیری ماشین خصمانه (AML) — نمونهٔ پیشنهادی تدوینگر (نمونه پیشنهادی تدوینگر بر پایه مفاهیم مطرح‌شده در منابع این فصل)
| فیلد | English | توضیح | نمونه |
|---|---|---|---|
| شناسهٔ ریسک | risk_id | شناسهٔ یکتای ریسک در رجیستر برای ارجاع در گزارش‌ها و صورت‌جلسات | AML-RSK-001 |
| دارایی/مدل | asset_model | نام مدل یا سیستم، کاربرد و محیط استقرار آن | دستیار پاسخ به مشتری (محیط تولید، سرویس داخلی) |
| مرحلهٔ چرخهٔ عمر | lifecycle_stage | مرحلهٔ آموزش، تنظیم یا استقراری که ریسک دربارهٔ آن مطرح است | استقرار (سرویس API داخلی) |
| طبقهٔ حملهٔ AML | aml_attack_class | کلاس حمله بر پایهٔ رده‌شناسی یادگیری ماشین خصمانه | تزریق مستقیم دستور (Direct Prompt Injection) |
| هدف مهاجم | attacker_goal | دسترس‌پذیری، یکپارچگی، حریم خصوصی یا امکان‌ساختن سوءاستفاده | نقض یکپارچگی و نشت داده از پایگاه دانش |
| سناریوی حمله | attack_scenario | شرح کوتاه سناریو همراه با فرض دانش و توانمندی مهاجم | کاربر داخلی با پرس‌وجوهای ساخت‌یافته دستیار را به چشم‌پوشی از قواعد پاسخ‌گویی وامی‌دارد |
| اثر کسب‌وکاری | business_impact | اثر مالی، انطباقی، حقوقی یا اعتباری در صورت وقوع | افشای اسناد محرمانه در برابر کارمند غیرمجاز |
| احتمال و شدت | likelihood_severity | درجهٔ احتمال و شدت بر پایهٔ مقیاس مصوب سازمان | احتمال متوسط / شدت زیاد |
| کنترل‌های کاهنده | mitigating_controls | کنترل‌های موجود یا برنامه‌ریزی‌شده برای کاهش ریسک | فیلتر ورودی/خروجی، جداسازی مجوز بازیابی بر پایهٔ نقش، آموزش کاربران |
| مالک ریسک و وضعیت | risk_owner_status | مالک نام‌دار ریسک، وضعیت درمان و تاریخ بازبینی بعدی | مالک: مدیر محصول دستیار — وضعیت: در حال درمان — بازبینی: پایان فصل |
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P03-C27-S02
شناسهٔ محتوا KDJ-AI-2026E1-P03-C27-S02-FA399DF4
نگاشت مفاهیم به هدف‌ها، کنترل‌ها و مسئولان (با جدول RACI)
نگاشت پیش رو «نمونهٔ تدوینگر» است و مفاهیم مطرح‌شده در منابع این بخش را به زبان هدف سازمانی، کنترل عملیاتی، شواهد و مالک ترجمه می‌کند:
| مفهوم NIST | هدف سازمانی | کنترل عملیاتی | شواهد | KPI (نمونه تدوینگر) | مالک |
|---|---|---|---|---|---|
| حملهٔ گریز (Evasion) | پایداری تصمیم مدل در برابر ورودی دستکاری‌شده | آزمون نمونه‌های خصمانه پیش از انتشار؛ پایش انحراف خروجی | گزارش آزمون؛ لاگ انحراف | درصد مدل‌های پرریسک آزمون‌شده | مالک مدل / تیم AI/ML |
| مسموم‌سازی داده (Data Poisoning) | یکپارچگی خط لولهٔ دادهٔ آموزش | کنترل منبع داده؛ راستی‌آزمایی درهم‌ساز؛ جداسازی محیط آموزش | مدارک راستی‌آزمایی؛ ثبت تغییرات خط لوله | زمان تا کشف ناهنجاری داده | تیم داده |
| مسموم‌سازی با درِ پشتی و مدل‌های ثالث | اصالت مدل‌های پیش‌آموزش‌دیده | تهیه از منابع ثبت‌شده؛ ضبط اثر انگشت مدل (hash)؛ آزمون ماشه | رجیستر مدل؛ گزارش آزمون | درصد مدل‌های ثالث دارای ثبت اصالت | CISO / تدارکات |
| حملات حریم خصوصی (استنتاج عضویت، بازسازی، استنتاج ویژگی) | صیانت از داده‌های اشخاص در مدل‌ها | ارزیابی ریسک حریم خصوصی پیش از انتشار؛ حفظ‌محرمانگی (مانند حریم خصوصی تفاضلی) در صورت نیاز | مستند ارزیابی؛ سابقهٔ تنظیم پارامتر محرمانگی | شمار یافته‌های بازبینی حریم خصوصی | حریم خصوصی / تیم داده |
| استخراج مدل (Model Extraction) | حمایت از دارایی فکری مدل | محدودسازی نرخ پرس‌وجو؛ احراز هویت API؛ پایش الگوی فراخوانی | لاگ API؛ گزارش پایش | شمار فراخوانی‌های ناهنجار شناسایی‌شده | SOC / مهندسی نرم‌افزار |
| تزریق دستور (Prompt Injection) | کنترل‌پذیری رفتار دستیارهای مولد | جداسازی دستور سیستمی از دادهٔ کاربر؛ فیلتر ورودی/خروجی؛ حداقل مجوز عامل | گزارش آزمون تزریق؛ لاگ مسدودسازی | نرخ شناسایی و توقف تلاش‌های تزریق | تیم AI/ML / SOC |
| زنجیرهٔ تأمین هوش مصنوعی | امنیت وابستگی‌ها و خدمات ثالث | ارزیابی تأمین‌کننده؛ فهرست اجزای مدل؛ بند امنیتی قرارداد | فرم ارزیابی؛ قرارداد مصوب | درصد تأمین‌کنندگان ارزیابی‌شده | تدارکات / CISO |
جدول RACI زیر نیز نمونهٔ تدوینگر است؛ R = مسئول اجرا، A = پاسخگوی نهایی، C = مشاور، I = مطلع. «AI Officer» نقش رسمی همهٔ سازمان‌ها نیست و نقش معادل سازمانی می‌تواند «مدیر راهبری تحول دیجیتال» یا «دبیر کمیتهٔ هوش مصنوعی» باشد:
| فعالیت | هیئت‌مدیره | مدیرعامل | CISO | AI Officer | تیم AI/ML | تیم داده | SOC | ممیزی داخلی | حقوقی/انطباق |
|---|---|---|---|---|---|---|---|---|---|
| تصویب سیاست امنیت AI و پذیرش ریسک باقی‌مانده | A | R | C | C | C | C | I | I | C |
| تدوین فهرست دارایی‌های هوش مصنوعی | I | I | A | R | C | R | I | I | I |
| مدل‌سازی تهدید AML و ارزیابی ریسک مدل‌ها | I | I | A | C | R | C | C | I | C |
| پیاده‌سازی کنترل‌های فنی (IAM، API، لاگ، پایش) | I | I | A | C | R | C | R | I | I |
| آزمون‌های امنیتی مدل (تزریق دستور، گریز، مسموم‌سازی) | I | I | A | C | R | C | C | I | I |
| پایش و پاسخ به رخداد هوش مصنوعی در SOC | I | I | A | I | C | I | R | I | C |
| ارزیابی تأمین‌کنندگان و مدل‌های ثالث | I | C | A | C | C | C | I | I | R |
| بازبینی دوره‌ای و ممیزی برنامهٔ امنیت AI | I | I | C | C | C | C | C | A/R | I |
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P03-C27-S03
شناسهٔ محتوا KDJ-AI-2026E1-P03-C27-S03-05C7A7FB
سناریوهای سازمانی و مثال تدوینگر
سناریوی ۱ — دستیار مشتری مبتنی بر RAG در یک بانک ایرانی: یک بانک ایرانی دستیار پاسخ‌گویی به مشتریان را بر پایهٔ یک LLM و بازیابی از پایگاه دانش مقرراتی داخلی (RAG) مستقر می‌کند. چند ماه بعد، تیم SOC الگوی پرس‌وجوهایی را مشاهده می‌کند که به‌جای پاسخ به نیاز مشتری، در پی وادارکردن دستیار به تکرار دستور سیستمی و محتویات اسناد داخلی است (تلاش تزریق مستقیم دستور و نشت داده). بازبینی نشان می‌دهد فیلتر خروجی و کنترل دسترسی در سطح سند وجود نداشته و هر کاربر به کل پایگاه دانش دسترسی داشته است. اقدام اصلاحی: تبعیت مجوز بازیابی از نقش کاربر، فیلتر ورودی/خروجی، محدودسازی نرخ پرس‌وجو و افزودن قواعد کشف به SIEM.
سناریوی ۲ — بازرسی کیفیت بصری در یک شرکت صنعتی: یک شرکت صنعتی برای کنترل کیفیت قطعات از مدل بینایی ماشین استفاده می‌کند که داده‌های آموزشی آن بخشی توسط برچسب‌گذاران برون‌سپاری‌شده تهیه شده است. پس از یک نوبت داده‌گذاری جدید، نرخ پذیرش قطعات معیوب به‌طور نامحسوس بالا می‌رود. ریشه‌یابی، ناهمگونی نظام‌مند برچسب‌ها در آخرین محمولهٔ داده (نمونه‌ای از ریسک آلودگی/مسموم‌سازی داده) و نبود راستی‌آزمایی تغییرات خط لولهٔ داده را نشان می‌دهد. اقدام اصلاحی: تعریف شاخص کیفیت برچسب در قرارداد، راستی‌آزمایی آماری هر محموله پیش از آموزش و آزمون رگرسیون مدل پیش از انتشار.
مثال تدوینگر — «استنتاج عضویت» به زبان ساده: تصور کنید بیمارستان خصوصی مدلی برای پیش‌بینی خطر بستری‌شدن مجدد آموزش داده و خروجی مدل را در اختیار واحدهای بیرونی می‌گذارد. مهاجم با مقایسهٔ رفتار مدل روی پروندهٔ یک فرد خاص با رفتار کلی مدل می‌تواند حدس بزند آن فرد در مجموعهٔ آموزش (یعنی احتمالاً میان بیماران) بوده است یا نه؛ اطلاعی که خود می‌تواند افشای وضعیت سلامت تلقی شود. پیام اجرایی: انتشار هر خروجی آماری یا مدلی که با داده‌های اشخاص آموزش دیده، پیش از اشتراک‌گذاری باید از دریچهٔ ارزیابی حریم خصوصی عبور کند.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P03-C27-S04
شناسهٔ محتوا KDJ-AI-2026E1-P03-C27-S04-BD80CAE6
چک‌لیست اجرایی امنیت یادگیری ماشین خصمانه
طبقه‌بندی اقلام زیر طبقه‌بندی تدوینگر است و راهنماهای اختیاری منابع را به الزام تبدیل نمی‌کند.
- همهٔ مدل‌ها، خط لوله‌های داده و سرویس‌های استنتاج را شناسایی کنید و آن‌ها را در فهرست دارایی‌های هوش مصنوعی ثبت کنید. (ضروری برای اجرای پایه)
- برای هر دارایی یک مالک نام‌دار و سطح ریسک اولیه تعیین کنید. (ضروری برای اجرای پایه)
- هر دارایی پرریسک را در برابر سه هدف مهاجم ارزیابی کنید: دسترس‌پذیری، یکپارچگی و حریم خصوصی. (ضروری برای اجرای پایه)
- مدل تهدید مختص هر کاربرد پرریسک را، شامل فرض دانش و توانمندی مهاجم، مستندسازی کنید. (ضروری برای اجرای پایه)
- لاگ پرس‌وجوها و خروجی سرویس‌های مدل‌محور را پایش کنید و آن‌ها را به SIEM متصل کنید. (ضروری برای اجرای پایه)
- رخدادهای مشکوک (تزریق، استخراج، ناهنجاری داده) را در رجیستر رخداد هوش مصنوعی ثبت کنید. (ضروری برای اجرای پایه)
- وضعیت ریسک‌ها و کنترل‌ها را در بازه‌های تعریف‌شده به مدیریت ارشد گزارش کنید. (ضروری برای اجرای پایه)
- سیاست امنیت هوش مصنوعی و آستانهٔ ریسک‌پذیری را در بالاترین سطح مجاز سازمان تصویب کنید. (ضروری برای اجرای پایه)
- فهرست دارایی‌ها و رجیستر ریسک را دست‌کم هر فصل بازبینی کنید. (ضروری برای اجرای پایه)
- مقاومت دستیارهای مولد را در برابر تزریق دستور و بازیابی غیرمجاز از RAG، پیش از انتشار و پس از هر تغییر عمده آزمون کنید. (پیشنهادی)
- تأمین‌کنندگان مدل، داده و خدمات برچسب‌گذاری را پیش از قرارداد و به‌صورت دوره‌ای ارزیابی کنید. (پیشنهادی)
- مدل‌های پرریسک را در برابر نمونه‌های خصمانه (گریز) و سناریوهای مسموم‌سازی هدفمند آزمون کنید. (پیشرفته)
- سازوکارهای حفظ محرمانگی (مانند حریم خصوصی تفاضلی) را برای انتشار داده و مدل‌های حساس پیاده‌سازی کنید. (پیشرفته)
- برنامهٔ مستمر red teaming هوش مصنوعی را با سناریوهای سازگارشونده (adaptive) برگزار کنید. (پیشرفته)
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P03-C27-S05
شناسهٔ محتوا KDJ-AI-2026E1-P03-C27-S05-1D14F279
اگر سازمان شما از صفر شروع می‌کند: توالی آغاز
اگر سازمان شما هنوز برنامه‌ای برای امنیت هوش مصنوعی ندارد، توالی آغاز پیشنهادی تدوینگر چنین است:
- ثبت دارایی‌ها (دو تا چهار هفته): فهرستی از مدل‌ها، کاربردها، داده‌ها و خدمات ثالث تهیه کنید؛ فهرست ناقص بهتر از نبود فهرست است.
- تعیین مالک و طبقهٔ ریسک: برای هر دارایی یک مالک نام‌دار و برچسب «پرریسک/کم‌ریسک» تعیین کنید.
- سیاست حداقلی: سندی کوتاه (دو تا سه صفحه) با تعریف دامنه، ممنوعیت استقرار مدل ثبت‌نشده و الزام بازبینی تدوین و تصویب کنید.
- کنترل‌های پایه: احراز هویت و کنترل دسترسی (IAM) روی سرویس‌های مدل، لاگ‌گیری پرس‌وجو و خروجی، محدودسازی نرخ API و محافظت از داده‌های آموزشی.
- رجیستر ریسک اولیه: پنج تا ده سناریوی کلیدی (نشت داده از دستیار مولد، آلودگی دادهٔ برون‌سپاری‌شده، سوءاستفاده از API، درِ پشتی مدل ثالث، تزریق دستور) را ثبت و برای هر یک کنترل و مالک تعیین کنید.
- آماده‌سازی واکنش: نقش‌های پاسخ به رخداد هوش مصنوعی را مشخص و SOC را با انواع هشدارهای مدل‌محور آشنا کنید.
- چرخهٔ بازبینی: جلسهٔ فصلی مرور ریسک‌ها و شاخص‌ها را در تقویم سازمان جای‌دهید.
«حداقل حاکمیت قابل‌دوام هوش مصنوعی»: در لایهٔ اجرایی این کتاب، حداقل مجموعهٔ پایدار را چنین تعریف می‌کنیم: «فهرست دارایی + مالک نام‌دار + ریسک‌های ثبت‌شده + کنترل‌های پایهٔ دسترسی و لاگ + بازبینی فصلی». این اصطلاح، اصطلاح رسمی NIST نیست و پیشنهادی تدوینگر برای سازمان‌هایی است که نمی‌توانند یک‌باره برنامهٔ کامل بسازند. ممکن است بسته به صنعت و مقررات حاکم، الزامات دیگری نیز اعمال شود.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P03-C27-S06
شناسهٔ محتوا KDJ-AI-2026E1-P03-C27-S06-D21FB050
برای تیم فنی: لایه‌های دفاعی و کنترل‌های مهندسی
- معماری و چرخهٔ عمر مدل: محیط آموزش و استنتاج را از هم جدا کنید؛ در رجیستر مدل، نسخه، درهم‌ساز (hash) و منبع هر مدل پیش‌آموزش‌دیده را ثبت کنید؛ انتشار مدل را مشروط به قبولی آزمون‌های امنیتی کنید.
- زنجیرهٔ تأمین مدل: مدل‌ها و مجموعه‌داده‌ها را فقط از منابع ثبت‌شده تهیه کنید؛ فهرست اجزای مدل (به‌سان SBOM نرم‌افزار) تهیه و درهم‌سازها را در زمان بارگیری راستی‌آزمایی کنید.
- RAG و مسموم‌سازی پایگاه دانش: منابع ورودی به پایگاه دانش را محدود و مستند کنید؛ اسناد حساس را با کنترل دسترسی در سطح سند جدا کنید؛ مجوز بازیابی را از مجوز کاربر تبعیت دهید تا RAG به مجرای نشت داده تبدیل نشود.
- تزریق دستور (Prompt Injection): دستور سیستمی را از دادهٔ کاربر جدا نگه دارید؛ ورودی و خروجی را پالایش کنید؛ هر اقدام عامل با اثر بیرونی (ارسال پیام، تغییر داده، فراخوانی API) را مشروط به تأیید کنید.
- مجوز عامل‌ها: به عامل‌های هوش مصنوعی کمترین مجوز ممکن بدهید؛ اعتبارنامهٔ دائمی ممنوع؛ دامنهٔ اقدام هر عامل را صریح و قابل ابطال تعریف کنید.
- سرقت و استخراج مدل: روی سرویس‌های استنتاج، احراز هویت، سقف نرخ پرس‌وجو و آستانهٔ هشدار برای الگوهای استخراج‌گونه فعال کنید.
- امنیت API و IAM: سرویس‌های مدل را پشت دروازهٔ API قرار دهید؛ کلیدها را چرخشی کنید؛ اصل کمترین امتیاز را در IAM اعمال کنید.
- لاگ، SIEM و SOC: پرس‌وجو، پاسخ، شناسهٔ کاربر و تصمیم‌های خودکار را ثبت و به SIEM متصل کنید؛ برای SOC دفترچهٔ انواع رخداد هوش مصنوعی (تزریق، استخراج، ناهنجاری داده) بنویسید؛ در لاگ‌گیری اصل کمترین دادهٔ شخصی را رعایت کنید.
- آزمون و DevSecOps: آزمون تزریق دستور و نمونه‌های خصمانه را در خط لولهٔ CI/CD بگنجانید؛ پیش از هر انتشار عمده، رگرسیون رفتار مدل را بسنجید.
- پایش استقرار: انحراف توزیع ورودی و خروجی (drift)، فراوانی امتناع از پاسخ و نرخ خطا را پایش کنید تا اثر حملات آرام‌رشده زودتر آشکار شود.
نمونه فرم — چک‌لیست امنیت RAG و دستیارهای مولد — نمونهٔ پیشنهادی تدوینگر (نمونه پیشنهادی تدوینگر بر پایه مفاهیم مطرح‌شده در منابع این فصل)
| فیلد | English | توضیح | نمونه |
|---|---|---|---|
| محدودهٔ منابع دانش | knowledge_source_scope | فهرست مجاز و مستند منابع ورودی به پایگاه دانش RAG | مقررات داخلی و راهنمای محصول (نسخهٔ ۳) |
| راستی‌آزمایی منبع | source_verification | درهم‌ساز یا امضای منابع و بازبینی تغییرات پیش از نمایه‌سازی | درهم‌ساز SHA-256 فایل‌ها پیش از نمایه‌سازی راستی‌آزمایی شد |
| جداسازی مجوز بازیابی | retrieval_access_control | تبعیت دسترسی به هر سند از نقش کاربر پرسش‌گر | اسناد حقوقی فقط برای واحد حقوقی بازیابی می‌شود |
| پالایش ورودی | input_filtering | کشف و مسدودسازی الگوهای تزریق دستور در پرس‌وجو | پرس‌وجوهای درخواست‌کنندهٔ نادیده‌گرفتن قواعد مسدود و ثبت شد |
| پالایش خروجی | output_filtering | بازبینی پاسخ پیش از ارسال برای جلوگیری از نشت دادهٔ حساس | شمارهٔ حساب و دادهٔ هویتی در پاسخ ماسک شد |
| حداقل مجوز عامل | agent_least_privilege | دامنهٔ اقدام‌های مجاز عامل و اعتبارنامه‌های موقت و قابل ابطال | عامل فقط دسترسی خواندن از پایگاه دانش دارد؛ بدون دسترسی نوشتن |
| احراز هویت و سقف نرخ API | api_auth_rate_limit | احراز هویت سرویس‌گیرنده و محدودیت نرخ پرس‌وجو برای مهار استخراج مدل | ۲۰ پرس‌وجو در دقیقه برای هر کاربر |
| لاگ و پایش | logging_monitoring | ثبت پرس‌وجو/پاسخ و قواعد کشف ناهنجاری در SIEM | هشدار برای ۵۰ پرس‌وجوی ناهنجار در ۵ دقیقه |
| آزمون تزریق و پاسخ به رخداد | injection_test_ir | نتیجهٔ آخرین آزمون تزریق دستور و مسیر گزارش رخداد به SOC | آزمون فصلی انجام شد؛ یک یافتهٔ متوسط در حال ترمیم؛ گزارش به SOC |
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P03-C27-S07
شناسهٔ محتوا KDJ-AI-2026E1-P03-C27-S07-9046AA3C
جمع‌بندی تطبیقی: مدل بلوغ، KPI/KRI و نگاشت ISO/IEC
مدل بلوغ تدوینگر (سطح ۰ تا ۵):
| سطح | عنوان | نشانهٔ کلیدی |
|---|---|---|
| ۰ | ناشناخته | مدل‌ها شناسایی نشده‌اند؛ «AI سایه» فراگیر است |
| ۱ | آغازین | فهرست دارایی ناقص است؛ مالک مشخص نیست |
| ۲ | تعریف‌شده | سیاست، رجیستر ریسک و مالک برای دارایی‌های اصلی موجود است |
| ۳ | مدیریت‌شده | آزمون‌های امنیتی منظم، پایش SOC و KPI برقرار است |
| ۴ | کمّی | سنجه‌ها مبنای تصمیم‌اند؛ red teaming و خودکارسازی انجام می‌شود |
| ۵ | بهینه | بهبود مستمر و هم‌راستایی کامل با اهداف کسب‌وکار |
این مدل بلوغ، چارچوب رسمی NIST نیست و برای کاربرد اجرایی این کتاب تدوین شده است.
نمونهٔ KPI/KRI (پیشنهادی تدوینگر): KPI: درصد دارایی‌های دارای مالک؛ درصد مدل‌های پرریسک دارای مدل تهدید مستند؛ میانگین زمان ترمیم یافته‌های امنیتی مدل. KRI: شمار رخدادهای مشکوک تزریق/استخراج در ماه؛ درصد مدل‌های ثبت‌نشدهٔ کشف‌شده در بازبینی؛ شمار تأمین‌کنندگان ارزیابی‌نشدهٔ فعال.
نگاشت به ISO/IEC (با سطح اطمینان):
| مفهوم این بخش | سند مرجع | سطح اطمینان | دلیل مفهومی |
|---|---|---|---|
| رده‌شناسی حملات AML (خودِ طبقه‌بندی) | ISO/IEC 42001 | NO_DIRECT_EQUIVALENT | این سند چارچوب نظام مدیریت است و طبقه‌بندی فنی حملات خصمانه ارائه نمی‌دهد |
| فرایند ارزیابی ریسک حملات مدل | ISO/IEC 23894 | PARTIAL | چارچوب مدیریت ریسک هوش مصنوعی دارد اما رده‌شناسی AML و کنترل‌های حمله‌محور ندارد |
| کنترل‌های عملیاتی (IAM، لاگ، زنجیرهٔ تأمین) | ISO/IEC 27001 | PARTIAL | کنترل‌های امنیت اطلاعات کلاسیک به‌کارگرفتنی‌اند اما بردارهای ویژهٔ ML را پوشش نمی‌دهند |
| روش‌شناسی ریسک دارایی‌های مدل | ISO/IEC 27005 | RELATED | روش‌شناسی عمومی ریسک امنیت اطلاعات است و تعمیم آن به دارایی مدل نیازمند تطبیق مفهومی است |
| صیانت از داده‌های اشخاص در برابر حملات استنتاج و بازسازی | ISO/IEC 27701 | RELATED | نظام مدیریت حریم خصوصی مبنای مدیریتی می‌دهد اما کنترل فنی حملات AML در آن به‌صورت مستقیم نیامده است |
در لایهٔ اجرایی این کتاب پیشنهاد می‌شود سازمان‌هایی که بر پایهٔ اسناد ISO سازماندهی شده‌اند، کنترل‌های این فصل را به‌عنوان تفصیل ویژهٔ هوش مصنوعی در ساختار موجود خود جای‌دهند، نه به‌عنوان برنامه‌ای موازی.
استناد
محمدعلی کهندژ، راهنمای جامع حاکمیت، امنیت و مدیریت ریسک هوش مصنوعی، شناسه بخش: KDJ-AI-2026E1-P03-C27-S08
شناسهٔ محتوا KDJ-AI-2026E1-P03-C27-S08-C38EBDE2