مقالههوش مصنوعی سازمانی
RAG با رعایت سطح دسترسی: چرا دستیار نباید نامه محرمانه را به همه نشان دهد
در RAG، اسناد در نمایه مشترک ذخیره می‌شوند و اگر دسترسی کاربر در لحظه بازیابی بررسی نشود، نشت مستقیم، نشت در متن پاسخ یا نشت استنتاجی رخ میدهد. OWASP افشای اطلاعات حساس و ضعف بردار و نمایه را از ریسک‌های اصلی می‌داند. الگوهای درست: فراداده دسترسی برای هر قطعه، فیلتر پیش از بازیابی، بررسی با سامانه منبع، نمایه جداگانه برای داده بسیار حساس و ممیزی مشاهده. فیلتر پس از تولید کافی نیست.
خلاصه در چند نکته
- نمایه یکجا بدون فیلتر مجوز یعنی نشت اطلاعات محرمانه.
- نشت ممکن است مستقیم، در متن پاسخ یا استنتاجی باشد.
- هر قطعه نمایه باید فراداده دسترسی سند مادر را داشته باشد.
- فیلتر باید پیش از ارسال قطعه به مدل اعمال شود.
- تغییر دسترسی باید سریع به نمایه منتقل شود.
- مشاهده اسناد از طریق دستیار باید در سابقه ممیزی ثبت شود.
فهرست مطالب
تصور کنید سازمانی تازه یک دستیار هوش مصنوعی راه‌اندازی کرده است. تیم فنی برای سرعت کار، همه نامه‌ها، صورت‌جلسات و اسناد را در یک نمایه واحد ریخته و دستیار را در اختیار همه کارکنان گذاشته است. روز سوم، کارمندی در واحد پشتیبانی می‌پرسد: «برنامه افزایش حقوق امسال چیست؟» و دستیار، با کمال ادب و همراه با ارجاع، خلاصه صورت‌جلسه محرمانه هیئت‌مدیره درباره ترمیم حقوق مدیران را نمایش میدهد.
این سناریو تخیلی نیست؛ یکی از رایج‌ترین خطاهای طراحی در پروژه‌های RAG سازمانی است. این مقاله توضیح میدهد چرا RAG بدون فیلتر مجوز عملاً یک ابزار نشت اطلاعات است، کنترل دسترسی در دستیارهای هوش مصنوعی چه تفاوتی با کنترل دسترسی در سامانه‌های معمولی دارد و چه الگوهایی برای پیاده‌سازی درست آن وجود دارد. تمرکز این مقاله بر هوش مصنوعی است؛ مفاهیم پایه دسترسی مبتنی بر نقش در مقاله‌های جداگانه پایگاه دانش بررسی شده‌اند.
مسئله: نمایه یکجا + پاسخ بدون فیلتر = نشت
در سامانه‌های سنتی مانند اتوماسیون اداری، هر کاربر فقط نامه‌هایی را می‌بیند که در کارتابل او هستند یا به آن‌ها دسترسی دارد. این کنترل در لایه نمایش اعمال میشود و کاربر هرگز فهرست نامه‌های دیگران را نمی‌بیند.
اما در RAG، معماری متفاوت است. اسناد برای جستجو در یک نمایه مشترک ذخیره می‌شوند و مدل زبانی، بر اساس قطعه‌هایی که بازیابی شده، پاسخ می‌سازد. اگر در لحظه بازیابی دسترسی کاربر بررسی نشود، سه اتفاق ممکن است رخ دهد:
| نوع نشت | شرح | مثال |
|---|---|---|
| نشت مستقیم | قطعه محرمانه به‌عنوان منبع نمایش داده میشود | نمایش پیوند صورت‌جلسه محرمانه |
| نشت در متن پاسخ | منبع نمایش داده نمی‌شود اما محتوای آن در پاسخ می‌آید | «طبق تصمیم اخیر، حقوق مدیران ۴۰٪ افزایش می‌یابد» |
| نشت استنتاجی | پاسخ نشان میدهد چیزی وجود دارد | «اطلاعاتی درباره تعدیل نیرو در واحد فروش وجود دارد اما…» |
فهرست OWASP Top 10 for LLM Applications، افشای اطلاعات حساس را یکی از ریسک‌های اصلی برنامه‌های مدل زبانی می‌داند و در نسخه ۲۰۲۵ خود، ضعف‌های مربوط به بردارها و نمایه‌ها را هم به‌عنوان ریسکی جداگانه افزوده است؛ از جمله نشت اطلاعات بین کاربران یا گروه‌هایی که از یک نمایه مشترک استفاده می‌کنند.
چرا کنترل دسترسی در RAG دشوارتر است؟
۱. داده از سامانه اصلی کپی میشود
برای نمایه‌سازی، متن اسناد از سامانه منبع استخراج و در نمایه جداگانه‌ای ذخیره میشود. اگر دسترسیها همراه متن منتقل نشوند، نمایه یک «نسخه بی‌قفل» از کل داده سازمان خواهد بود.
۲. دسترسیها پویا هستند
نامه‌ای که امروز به کارمندی ارجاع شده، فردا ممکن است از دسترس او خارج شود. کارمندی که از واحد مالی به واحد فروش منتقل میشود، باید فوراً دسترسی به اسناد مالی را از دست بدهد. نمایه‌ای که این تغییرات را با تأخیر چند روزه دریافت کند، در این فاصله نشت ایجاد میکند.
۳. دسترسیها چندلایه‌اند
در یک سازمان، دسترسی فقط به نقش بستگی ندارد؛ به واحد، سطح طبقه‌بندی سند (عادی، محرمانه، سری)، گیرندگان نامه، اعضای جلسه و گاهی پروژه هم بستگی دارد. همه این لایه‌ها باید در بازیابی رعایت شوند.
۴. مدل حافظه ندارد، اما سابقه گفت‌وگو دارد
اگر در یک گفت‌وگوی چندمرحله‌ای، قطعه‌ای در پاسخ اول بازیابی شده باشد، در پاسخ‌های بعدی هم ممکن است در زمینه گفت‌وگو باقی بماند. هر گفت‌وگو باید به هویت یک کاربر محدود باشد.
راهکار: الگوهای RAG آگاه از مجوز
الگوی ۱: فیلتر پیش از بازیابی
درست‌ترین رویکرد این است که هر قطعه در نمایه فراداده دسترسی داشته باشد (مثلاً شناسه گروه‌ها، نقش‌ها یا کاربران مجاز) و جستجو از ابتدا فقط در قطعه‌هایی انجام شود که با هویت کاربر پرسشگر سازگارند. در این حالت، قطعه غیرمجاز هرگز به مدل نمی‌رسد.
الگوی ۲: بررسی دسترسی با سامانه منبع
در برخی معماری‌ها، پس از بازیابی و پیش از ارسال به مدل، برای هر قطعه از سامانه منبع پرسیده میشود: «آیا این کاربر الان اجازه دیدن این سند را دارد؟» این روش دقیق‌تر است، چون همیشه آخرین وضعیت دسترسی را می‌گیرد، اما کندتر است. ترکیب دو الگو، یعنی فیلتر اولیه در نمایه و بررسی نهایی با منبع، رایج است.
الگوی ۳: نمایه‌های جداگانه برای سطوح حساس
برای داده‌های بسیار حساس، برخی سازمان‌ها نمایه جداگانه‌ای می‌سازند که فقط برای گروه محدودی قابل جستجوست. این کار سطح جداسازی را بالا می‌برد، اما مدیریت آن پیچیده‌تر است.
الگوی ۴: ممیزی مشاهده
حتی با بهترین فیلتر، باید بدانید چه کسی، چه زمانی و در پاسخ به چه پرسشی کدام سند را دیده است. سابقه ممیزی هم بازدارنده است و هم امکان بررسی پس از رخداد را فراهم میکند. موضوع ممیزی و جلوگیری از نشت اسناد را در مقاله جلوگیری از نشت اسناد با واترمارک و ممیزی بررسی کرده‌ایم.
مقایسه الگوها
| الگو | امنیت | سرعت | پیچیدگی | مناسب برای |
|---|---|---|---|---|
| فیلتر پیش از بازیابی | بالا | بالا | متوسط | بیشتر سازمان‌ها |
| بررسی با سامانه منبع | بسیار بالا | متوسط | متوسط | دسترسی‌های پرتغییر |
| نمایه جداگانه | بسیار بالا | بالا | بالا | داده سری و بسیار حساس |
| فیلتر پس از تولید | پایین | بالا | پایین | توصیه نمی‌شود |
یک نمونه درست
مدیر واحد فروش می‌پرسد: «وضعیت قرارداد با شرکت الف چیست؟»
- سامانه هویت او را از سامانه احراز هویت سازمان می‌گیرد: نقش «مدیر فروش»، واحد «فروش».
- جستجو فقط در قطعه‌هایی انجام میشود که برای این نقش و واحد مجازند.
- سه نامه و یک قرارداد پیدا میشود. یک نامه محرمانه واحد حقوقی درباره دعوای احتمالی با همین شرکت هم در نمایه هست، اما چون مدیر فروش به آن دسترسی ندارد، اصلاً در نتایج نمی‌آید.
- پاسخ بر اساس چهار منبع مجاز ساخته و با ارجاع نمایش داده میشود.
- در سابقه ممیزی ثبت میشود که این کاربر در این زمان این چهار سند را از طریق دستیار دیده است.
فراتر از خواندن: دسترسی در خلاصه و گزارش
کنترل دسترسی فقط به پرسش و پاسخ محدود نیست. وقتی دستیار خلاصه یک پرونده، گزارش وضعیت یک پروژه یا مرور کارتابل روزانه تولید میکند، همان اصل باید رعایت شود: خلاصه فقط از اسنادی ساخته شود که درخواست‌کننده مجاز به دیدن آن‌هاست. یک خطای ظریف این است که خلاصه‌ای برای مدیر ارشد ساخته شود و سپس همان متن برای فرد دیگری ارسال یا در جای مشترکی ذخیره شود. در این حالت، خلاصه خود به یک «سند جدید» با محتوای محرمانه تبدیل شده که باید طبقه‌بندی و کنترل دسترسی داشته باشد.
همچنین اگر در آینده دستیار امکان انجام اقداماتی مانند پیش‌نویس نامه یا ایجاد کار را داشته باشد، این اقدامات باید با مجوزهای خود کاربر انجام شوند، نه با یک حساب فنی پرقدرت. اصل «حداقل دسترسی» برای هوش مصنوعی هم صادق است: دستیار نباید بیش از کاربری که از طرف او کار میکند، اختیار داشته باشد.
چک‌لیست ارزیابی امنیت دسترسی در دستیار
- [ ] هر قطعه نمایه، فراداده دسترسی سند مادر را دارد.
- [ ] فیلتر مجوز پیش از ارسال قطعه به مدل اعمال میشود.
- [ ] تغییر دسترسی و حذف سند در کمترین زمان به نمایه منتقل میشود.
- [ ] دسترسیها از سامانه منبع گرفته می‌شوند، نه اینکه دوباره تعریف شوند.
- [ ] هر گفت‌وگو به هویت یک کاربر محدود است.
- [ ] مشاهده اسناد از طریق دستیار در سابقه ممیزی ثبت میشود.
- [ ] آزمون نفوذ با کاربرانی از نقش‌های مختلف انجام شده است.
- [ ] سند حاوی دستورهای مخرب نمی‌تواند فیلتر را دور بزند.
پرسش‌هایی که باید از فروشنده بپرسید
- فیلتر دسترسی در کدام مرحله اعمال میشود: پیش از بازیابی، پیش از تولید یا پس از آن؟
- تغییر دسترسی یک کاربر چقدر طول می‌کشد تا در پاسخ‌های دستیار اعمال شود؟
- دسترسیها از کجا خوانده می‌شوند؟
- آیا مشاهده اسناد از طریق دستیار در سابقه ممیزی قابل گزارش‌گیری است؟
- آیا می‌توان نشان داد کاربری با نقش پایین‌تر، با هیچ پرسشی به سند محرمانه نمی‌رسد؟
برای سیاست کلی استفاده کارکنان از ابزارهای هوش مصنوعی، مقاله ریسک داده در استفاده از ChatGPT در محل کار و برای طراحی کلی معماری، راهنمای معماری RAG سازمانی را ببینید. اهمیت همین اصل در چت‌بات داخلی کارکنان هم بررسی شده است.
اشتباه‌های رایج
- «همه کارکنان مورد اعتمادند»: اعتماد جای کنترل دسترسی را نمی‌گیرد؛ الزامات قانونی و قراردادی هم همین را می‌خواهند.
- فیلتر فقط روی پیوند منبع: پنهان کردن پیوند کافی نیست اگر محتوا در متن پاسخ بیاید.
- همگام‌سازی هفتگی دسترسی: فاصله زمانی، پنجره نشت است.
- نبود آزمون با نقش‌های مختلف: فقط با حساب مدیر سامانه آزمون شده است.
رویکرد آریا آیتی
در دستیار هوش مصنوعی سازمانی آریا آیتی، پاسخ فقط از نامه‌ها، جلسات، کارها و اسنادی ساخته میشود که کاربر اجازه دیدن آن‌ها را دارد؛ نتیجه محرمانه فقط برای نقش مجاز نمایش داده میشود و مشاهدهها در سابقه ممیزی ثبت میشود. نقش‌ها و هویت کاربران از لایه هویت و نقش پلتفرم گرفته میشود. دستیار در پلن سازمانی ارائه میشود.
جمع‌بندی
RAG بدون فیلتر مجوز، هر نامه محرمانه‌ای را در دسترس هر پرسشگری قرار میدهد؛ گاهی مستقیم، گاهی در متن پاسخ و گاهی با استنتاج. راه درست، انتقال فراداده دسترسی به نمایه، فیلتر پیش از بازیابی، همگام‌سازی سریع تغییرات، محدود کردن هر گفت‌وگو به یک هویت و ثبت مشاهدهها در سابقه ممیزی است. این‌ها ویژگی‌های اختیاری نیستند؛ پیش‌شرط استفاده سازمانی از هوش مصنوعی‌اند.
مشاوره رایگان: برای بررسی اینکه دستیار هوش مصنوعی چگونه دسترسی‌های سازمان شما را رعایت میکند، با کارشناسان آریا آیتی گفت‌وگو کنید یا درخواست پایلوت دستیار (پلن سازمانی) را ثبت کنید.
پرسش‌های متداول
چرا RAG بدون فیلتر مجوز خطرناک است؟
+
چون همه اسناد در یک نمایه مشترک هستند و بدون بررسی دسترسی، مدل ممکن است محتوای نامه محرمانه را به هر پرسشگری نشان دهد یا در متن پاسخ بیاورد.
آیا پنهان کردن پیوند منبع کافی است؟
+
خیر. اگر قطعه محرمانه به مدل رسیده باشد، محتوای آن ممکن است در متن پاسخ بیاید. قطعه غیرمجاز نباید اصلاً به مدل برسد.
تغییر دسترسی کاربر چقدر سریع باید در دستیار اعمال شود؟
+
هرچه سریعتر. هر فاصله زمانی بین تغییر دسترسی در سامانه منبع و اعمال آن در نمایه، پنجرهای برای نشت است.
دستیار آریا آیتی دسترسیها را رعایت میکند؟
+
بله. دستیار فقط از داده مجاز کاربر پاسخ میدهد، نتیجه محرمانه فقط برای نقش مجاز نمایش داده میشود و مشاهدهها در سابقه ممیزی ثبت میشود.