RAG با کنترل دسترسی اسناد؛ مجوز باید پیش از ورود متن به مدل اعمال شود

معماری Permission-aware RAG را از هویت کاربر تا قطعهٔ سند، کش و استناد بررسی کنید؛ همراه با سناریوی لغو دسترسی و آزمون جلوگیری از نشت میان نقش‌ها.

نویسنده
تحریریه آیوان
تاریخ انتشار
۳ آبان ۱۴۰۵
زمان مطالعه
۸ دقیقه
فهرست بخش‌ها
  1. مرز اصلی کجاست؟
  2. هویت را از برنامهٔ معتبر بگیرید، نه از متن سؤال
  3. مجوز سند باید به قطعه‌هایش برسد
  4. فیلتر دسترسی را در مسیر واقعی بازیابی اجرا کنید
  5. لغو دسترسی، آزمون مهم‌تر از ورود اولیه است
  6. کش، خلاصه و گزارش هم می‌توانند داده را عبور دهند
  7. عنوان و لینک منبع نیز جزو کنترل دسترسی‌اند
  8. ماتریس آزمون و تحویل عملیاتی
  9. پرسش‌های متداول
  10. منابع و مطالعهٔ پژوهشی

مرز اصلی کجاست؟

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

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

هویت را از برنامهٔ معتبر بگیرید، نه از متن سؤال

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

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

مجوز سند باید به قطعه‌هایش برسد

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

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

فیلتر دسترسی را در مسیر واقعی بازیابی اجرا کنید

الگوی Security Filter در مستندات Microsoft، تطبیق هویت یا گروه با فیلدهای نمایه را توضیح می‌دهد. این الگو به‌خودی‌خود سامانهٔ احراز هویت نمی‌سازد؛ برنامه مسئول تولید دامنهٔ معتبر و اعمال همیشگی فیلتر است. همچنین باید مطمئن شوید نسخهٔ API و موتور جست‌وجوی انتخاب‌شده، ترکیب موردنظر فیلتر و بازیابی را واقعاً پشتیبانی می‌کنند.

برای ارزیابی پیشنهادی، یک مسیر مجاز و یک مسیر تلاش برای حذف فیلتر داشته باشید. اگر ابزار فاقد زمینهٔ معتبر کاربر فراخوانی شد، رفتار امن باید روشن باشد؛ معمولاً توقف یا بازگرداندن نتیجهٔ فاقد داده، نه جست‌وجوی کل نمایه. این آزمون را روی ابزار مستقیم، Agent چندمرحله‌ای و درخواست بازنویسی‌شده هم تکرار کنید.

لغو دسترسی، آزمون مهم‌تر از ورود اولیه است

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

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

کش، خلاصه و گزارش هم می‌توانند داده را عبور دهند

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

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

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

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

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

ماتریس آزمون و تحویل عملیاتی

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

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

پرسش‌های متداول

آیا می‌توان همهٔ اسناد را به مدل داد و فقط خروجی را فیلتر کرد؟

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

اگر فرادادهٔ مجوز یک قطعه ناقص بود چه کنیم؟

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

آیا ACL یک بار در زمان واردسازی کافی است؟

خیر. تغییر عضویت، لغو مجوز، کش و دسترسی به لینک منبع هم باید در سیاست به‌روزرسانی و آزمون دیده شوند.

منابع و مطالعهٔ پژوهشی

مطالعهٔ بیشتر در دانشنامهٔ لیان

طراحی سناریوی قابل‌آزمون برای سازمان

داده، مرز دسترسی و معیار پذیرش کاربرد موردنظر خود را با تیم آیوان بررسی کنید.