امنیت RAG در هوش مصنوعی سازمانی؛ وقتی کنترل دسترسی به مسیر نشت اطلاعات تبدیل می‌شود

فهرست مطالب

مجوز کاربر با مجوز سند یکی نیست

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

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

چه اطلاعاتی اجازه دارند وارد پاسخ هوش مصنوعی شوند؟

۱. چرا RAG مرز دسترسی را پیچیده می‌کند؟

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

خطر فقط مربوط به متن سند نیست. گاهی یک سند به چند بخش کوچک تقسیم می‌شود و سطح محرمانگی آن بخش‌ها به‌درستی ثبت نمی‌شود. گاهی پاسخ قبلی در حافظه موقت (Cache) باقی می‌ماند و به کاربر دیگری نشان داده می‌شود. حتی ممکن است دسترسی فرد لغو شده باشد، اما اطلاعات قدیمی در فهرست جست‌وجوی سامانه هنوز به‌روزرسانی نشده باشد.

در فهرست OWASP Top 10 for LLM Applications 2025، ریسکی با نام «ضعف‌های بردار و تعبیه» (Vector and Embedding Weaknesses، کد LLM08:2025) معرفی شده است. در بسیاری از سامانه‌های RAG، متن اسناد به نمایش عددی تبدیل و در پایگاه داده برداری ذخیره می‌شود تا سامانه بتواند بخش‌های مرتبط را پیدا کند. اگر این فرایند و دسترسی به نتایج آن به‌درستی محافظت نشود، خطر افشای اطلاعات یا دستکاری محتوای بازیابی‌شده وجود دارد. 

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

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

۲. اصل طراحی: مجوز باید پیش از ورود محتوا به زمینه اعمال شود

ابتدا سامانه باید مطمئن شود درخواست را چه کسی ارسال کرده است و آن فرد مجاز است به چه اسنادی دسترسی داشته باشد. این اطلاعات باید از سامانه معتبر مدیریت هویت و دسترسی گرفته شود، نه از متن سؤال یا شناسه‌ای که کاربر بتواند خودش تغییر دهد. اگر عضویت کاربر در گروهی تغییر کرد، سامانه باید آن تغییر را به‌موقع اعمال کند.

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

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

۳. مدل تهدید: فقط مهاجم بیرونی را فرض نکنید

۳.۱. خطای پیکربندی و اعتماد بیش از حد به سرویس

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

۳.۲. تزریق دستور غیرمستقیم در اسناد

ممکن است داخل یک سند یا صفحه وب، دستور مخربی نوشته شده باشد؛ مثلاً از مدل بخواهد اطلاعات محرمانه را نمایش دهد یا ابزاری را اجرا کند. به این روش «تزریق دستور غیرمستقیم» می‌گویند. سامانه باید محتوای سند را فقط اطلاعات ورودی بداند، نه دستور معتبر. همچنین اجرای هر ابزار باید مجوز مستقل داشته باشد. کنترل دسترسی به سند و مقابله با تزریق دستور، دو کنترل متفاوت و مکمل هستند.

۳.۳. نشت بین واحدها یا مشتریان

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

۳.۴. تغییر مجوز و داده  قدیمی

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

مطالعه بیشتر: Shadow AI ؛ وقتی کارکنان بدون اطلاع سازمان از هوش مصنوعی استفاده می‌کنند

۴. معماری مرجع برای کنترل دسترسی در RAG

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

1.    شناسایی کاربر: هویت، گروه سازمانی و محدوده دسترسی را از نشست یا توکن معتبر دریافت کنید؛ نه از متن سؤال.

2.    تعیین مجوز: روشن کنید هر کاربر به چه اسنادی دسترسی دارد و تغییر یا انقضای مجوز چگونه اعمال می‌شود.

3.    کنترل هنگام جست‌وجو: پیش از برگرداندن نتیجه، اسناد غیرمجاز را از نتایج حذف کنید.

4.    بررسی دوباره: بعد از بازیابی، مالک سند، سطح محرمانگی و مجوز کاربر را دوباره بررسی کنید. اسناد فاقد اطلاعات ضروری را نپذیرید.

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

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

7.    حافظه موقت: پاسخ ذخیره‌شده یک کاربر نباید بدون بررسی مجوز برای کاربر دیگری استفاده شود.

8.    ثبت رویداد: مشخص کنید چه اسنادی بررسی و با چه مجوزی پذیرفته یا رد شده‌اند؛ اما متن محرمانه را بی‌دلیل در گزارش‌ها ذخیره نکنید.

۵. چارچوب عملیاتی: از سیاست روی کاغذ تا آزمون قابل تکرار

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

۵.۱. آزمون‌های ضروری

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

۵.۲. شاخص‌هایی که مدیر امنیت می‌تواند پیگیری کند

• برای ارزیابی امنیت RAG، تنها تعداد حملات مسدودشده را نشمارید. شاخص‌های زیر نشان می‌دهند کنترل دسترسی در عمل چقدر قابل اعتماد است:
• نرخ موفقیت آزمون‌های دسترسی غیرمجاز؛ هدف برای افشای سند غیرمجاز باید صفر باشد.
• مدت‌زمان لازم برای اعمال تغییر مجوز یا حذف سند در جست‌وجو و حافظه موقت؛ هم زمان معمول و هم موارد دارای تأخیر زیاد بررسی شوند.
• درصد نتایج بازیابی‌شده‌ای که شناسه، طبقه‌بندی و تصمیم مجوز قابل ردیابی دارند.
• تعداد مسیرهای بازیابی، خلاصه‌سازی یا کش که از سیاست مرکزی مجوز عبور نمی‌کنند.
• پوشش آزمون‌های منفی در نقش‌ها، گروه‌ها، مشتریان و سطوح طبقه‌بندی مختلف.

۶. نگاشت به حاکمیت و مدیریت ریسک

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

چارچوب مدیریت ریسک هوش مصنوعی NIST و راهنمای هوش مصنوعی مولد آن کمک می‌کنند مسئولیت‌ها، روش ارزیابی و بازبینی ریسک مشخص شود. این منابع، معماری آماده RAG ارائه نمی‌کنند. از سوی دیگر، معماری «اعتماد صفر» NIST یادآوری می‌کند که داخلی‌بودن یک سامانه به معنی مجازبودن همه دسترسی‌ها نیست. در RAG نیز باید مجوز هر درخواست و هر منبع بررسی شود. 

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

۷. خطاهای رایج در پیاده‌سازی

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

در RAG، خطر نشت اطلاعات زمانی ایجاد می‌شود که سندی بدون بررسی مجوز کاربر وارد فرایند تولید پاسخ شود. حتی اگر ورود به سامانه امن باشد، ممکن است دستیار از سندی استفاده کند که کاربر اجازه دیدن آن را ندارد. راهکار، بررسی مجوز پیش از بازیابی، کنترل دوباره نتایج و محافظت از حافظه، گزارش‌ها و منابع پاسخ است.

برای شروع ارزیابی، این سؤال را مطرح کنید:

« آیا می‌توان مشخص کرد هر پاسخ با استفاده از کدام اسناد ساخته شده و چرا کاربر اجازه دسترسی به آن‌ها را داشته است؟ »

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

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