امنیت سازمانی
امنیت RAG سازمانی؛ از مجوز سند تا حافظه و کش
پاسخِ درست به کاربرِ نامجاز، موفقیت نیست. زنجیرهٔ دسترسی را از منبع تا مدل، تاریخچه و ثبت رویداد دنبال کنیم.
آنچه از این مقاله می‌آموزید
- مجوز باید پیش از رسیدن شواهد به مدل اعمال شود.
- خلاصه، حافظه، کش و لاگ هم می‌توانند اطلاعات حساس داشته باشند.
- استقرار خصوصی، جای آزمون دسترسی متقاطع را نمی‌گیرد.
فرض کنید کارمند واحد فروش از دستیار داخلی دربارهٔ وضعیت یک مشتری سؤال می‌پرسد و پاسخ، بخشی از گزارش محرمانهٔ حقوقی را هم در خود دارد. حتی اگر تمام جمله‌ها درست باشند، سامانه کار درستی انجام نداده است. در RAG سازمانی، «درستی پاسخ» و «مجاز بودن دسترسی» دو معیار مستقل‌اند و هر دو باید پیش از بهره‌برداری آزموده شوند.
ساخت یک اپلیکیشن ارتباطی امن برای گفت‌وگو با داده‌های سازمان، از صفحهٔ ورود شروع و به آن ختم نمی‌شود. باید ببینیم هویت کاربر چگونه تا منبع، قطعه، مدل، حافظهٔ گفت‌وگو و لاگ ادامه پیدا می‌کند. این مقاله، یک نقشهٔ طراحی برای همین زنجیره ارائه می‌کند؛ کنترل‌ها باید با سیاست‌ها و زیرساخت واقعی هر سازمان تطبیق داده شوند.
از دارایی و جریان داده شروع کنید
پیش از انتخاب مدل، فهرست کنید چه نوع داده‌ای وارد سامانه می‌شود: راهنمای عمومی کارکنان، قرارداد، گزارش مدیریتی، اطلاعات مشتری یا سند شخصی. سپس برای هر گروه، مالک، طبقهٔ دسترسی، محل نگهداری و قاعدهٔ حذف را مشخص کنید. نام یک پوشه به‌تنهایی سیاست امنیتی نیست؛ باید بتوان این تصمیم را در مرحلهٔ بازیابی اعمال و در آزمون مشاهده کرد.
نقشهٔ جریان داده باید مسیرهای کم‌پیدا را هم نشان دهد. متن سند ممکن است هنگام استخراج به سرویس دیگری برود؛ سؤال ممکن است در ابزار پایش ثبت شود؛ خلاصه در نمایه‌ای جدا بماند و پاسخ در کش ذخیره شود. خصوصی بودن پایگاه اصلی، دربارهٔ این مسیرهای جانبی چیزی ثابت نمی‌کند. برای هر مسیر بپرسید چه داده‌ای خارج می‌شود، چه کسی به آن دسترسی دارد و چه مدت نگه داشته می‌شود.
هویت کاربر باید به بازیابی برسد
ورود یکپارچه کمک می‌کند هویت کاربر مشخص باشد، اما به‌تنهایی تعیین نمی‌کند کدام قطعه قابل بازیابی است. معمولاً باید شناسهٔ کاربر، نقش، واحد، گروه‌های دسترسی و زمینهٔ سازمانی به درخواست متصل شوند. فیلتر منابع مجاز باید پیش از ارسال شواهد به مدل اعمال شود؛ پنهان کردن متن در صفحهٔ پاسخ، بعد از آنکه مدل آن را دیده، کنترل کافی نیست.
در سامانه‌ای که از PostgreSQL استفاده می‌کند، سیاست‌های سطح ردیف یکی از سازوکارهای قابل بررسی برای اعمال دسترسی در لایهٔ داده‌اند. این سازوکار، جای طراحی نقش‌ها و آزمون همهٔ مسیرهای دسترسی را نمی‌گیرد. مستندات رسمی میان فعال کردن امنیت سطح ردیف، تعریف سیاست و رفتار نقش‌های دارای اختیارات ویژه تفاوت می‌گذارند. ۱
برای چندسازمانی بودن نیز فقط فیلتر کردن یک ستون در یک درخواست کافی نیست. ورود داده، جست‌وجوی برداری، جست‌وجوی واژگانی، دریافت اصل سند، کش و ابزار پرس‌وجو باید مرز یکسانی را رعایت کنند. هر مسیر تازه‌ای که این مرز را دور بزند، می‌تواند کنترل مسیر اصلی را بی‌اثر کند.
مجوز سند چگونه به قطعه و نمایه منتقل می‌شود؟
بخش‌بندی، سند را به چند شیء قابل بازیابی تبدیل می‌کند. اگر مجوز فقط روی فایل اصلی باقی بماند، نمایهٔ قطعه‌ها ممکن است بدون محدودیت جست‌وجو شود. بنابراین هر قطعه باید به شناسهٔ سند مادر و نسخهٔ مشخص آن متصل باشد و دادهٔ لازم برای تصمیم دسترسی را حمل کند یا از مرجع معتبر بخواند.
همین قاعده دربارهٔ خلاصه، زیرقطعه و پرسش مصنوعی نیز برقرار است. خلاصهٔ یک گزارش محرمانه همچنان می‌تواند محرمانه باشد. متن‌های مشتق‌شده نباید از سیاست منبع جدا شوند. هنگام حذف سند یا تغییر مجوز نیز باید همهٔ این نماها در محدودهٔ زمانی تعریف‌شده به وضعیت تازه برسند.
یک آزمون کاربردی این است: سندی را با دو نقش مختلف جست‌وجو کنید؛ سپس مجوز یکی را بردارید و دوباره همان سؤال را از مسیر بازیابی، پیوند مستقیم، حافظهٔ گفت‌وگو و کش بپرسید. موفقیت باید در همهٔ مسیرها تعریف شود. اگر فقط جست‌وجوی تازه محدود شود اما پاسخ قبلی در کش عمومی بماند، زنجیره کامل نیست.
تزریق دستور در سند با دستور کاربر فرق دارد
منبع بازیابی‌شده، دادهٔ بیرونی است؛ حتی اگر در شبکهٔ داخلی نگهداری شود. ممکن است در یک صفحه یا فایل جمله‌ای وجود داشته باشد که از مدل بخواهد دستورهای قبلی را نادیده بگیرد یا ابزار دیگری را اجرا کند. OWASP تزریق دستور را یکی از ریسک‌های اصلی برنامه‌های مبتنی بر مدل زبانی معرفی می‌کند؛ تفکیک داده از دستور، محدودسازی اختیارات و آزمون سناریوهای غیرمستقیم در این بحث اهمیت دارند. ۲
در طراحی، متن سند نباید حق تعیین مجوز، مقصد ارسال یا عملیات ابزار را پیدا کند. برای نمونه، یک یادداشت موجود در فایل نباید بتواند سامانه را به ارسال اطلاعات به یک نشانی تازه وادار کند. کنترل چنین عملیاتی باید در کد و سیاست ابزار باشد، نه فقط در جمله‌ای که از مدل می‌خواهد «مراقب باش».
اگر عامل به ابزارها دسترسی دارد، دامنهٔ هر ابزار را محدود کنید: کدام منبع خوانده می‌شود، کدام پارامتر مجاز است و چه عملیاتی به تأیید انسان نیاز دارد؟ عاملِ جست‌وجوگر نباید صرفاً به دلیل توانایی تولید متن، اختیار تغییر منبع یا ارسال گزارش را هم به دست بیاورد. میان پاسخ‌گویی و اقدام عملی مرز مشخص بگذارید.
حافظه و کش، مرز دسترسی را دوباره باز می‌کنند
پاسخ یک کاربر را نمی‌توان بدون بررسی مجوز به کاربر دیگری نشان داد؛ حتی اگر سؤال‌ها شبیه باشند. کلید و سیاست کش باید هویت، محدودهٔ دسترسی، نسخهٔ داده و اعتبار زمانی را در نظر بگیرد. در برخی سناریوها، کش پاسخ اصلاً انتخاب مناسبی نیست و فقط بخش‌های کم‌حساس‌ترِ پردازش قابل استفادهٔ مجددند.
حافظهٔ گفت‌وگو نیز باید مالک و مدت نگهداری مشخص داشته باشد. کاربری که دسترسی او تغییر کرده است نباید فقط با ادامه دادن گفت‌وگوی قبلی، متن محرمانه را دوباره بازیابی کند. تصمیم دربارهٔ تاریخچه، پیوست و خلاصهٔ مکالمه باید با چرخهٔ تغییر نقش و خروج کارکنان هماهنگ شود.
لاگ مفید، کمترین دادهٔ لازم را ثبت می‌کند
برای بازسازی خطا به اطلاعاتی مانند شناسهٔ درخواست، نسخهٔ منبع، مسیر بازیابی، زمان هر مرحله و وضعیت کنترل‌ها نیاز داریم. این الزام به معنی ثبت دائمیِ متن کاملِ همهٔ سؤال‌ها و پاسخ‌ها نیست. خودِ سؤال می‌تواند نام مشتری، جزئیات داخلی یا اطلاعات شخصی داشته باشد.
از ابتدا تعیین کنید چه چیزی برای عیب‌یابی لازم است و چه چیزی باید حذف، ماسک یا جدا نگهداری شود. دسترسی تیم توسعه به لاگ نباید به راه جایگزین دسترسی به اسناد محرمانه تبدیل شود. مدت نگهداری، روش پاک‌سازی و رویدادهای ممیزی باید به‌صورت قابل اجرا تعریف شوند؛ جملهٔ کلی «لاگ داریم» کافی نیست.
برای پایلوت، ماتریس آزمون بنویسید
| وضعیت | انتظار | شاهدی که باید ثبت شود |
|---|---|---|
| کاربر مجاز و سند معتبر | پاسخ مستند | شناسه و نسخهٔ سندِ واقعاً استفاده‌شده |
| کاربر نامجاز | نبود دسترسی به شواهد | عدم ورود متن ممنوع به زمینهٔ مدل |
| لغو مجوز | اعمال تغییر در همهٔ مسیرها | نتیجهٔ آزمون کش، تاریخچه و پیوند مستقیم |
| حذف یا اصلاح سند | کنار رفتن نسخهٔ نامعتبر | زمان به‌روزرسانی نمایه و وابسته‌ها |
| دستور مخرب در فایل | بی‌اثر ماندن دستور بیرونی | عدم اجرای ابزار یا ارسال غیرمجاز |
| نبود شواهد کافی | اعلام محدودیت پاسخ | ثبت دلیل و امکان ارجاع به مسئول منبع |
این آزمون‌ها باید با حساب‌های جدا و نقش‌های واقعیِ نماینده اجرا شوند. استفاده از یک حساب مدیر برای همهٔ آزمایش‌ها، رفتار کاربران عادی را نشان نمی‌دهد. همچنین بهتر است سنجهٔ کیفیت و نتیجهٔ آزمون دسترسی در گزارش‌های جدا دیده شوند تا بهبود یکی، افت دیگری را پنهان نکند.
استقرار خصوصی چه چیزی را حل می‌کند و چه چیزی را نه؟
استقرار خصوصی می‌تواند بخشی از کنترل محل پردازش و مسیر شبکه باشد. با این حال، مشکلاتی مانند مجوز اشتباه، لاگ بیش‌ازحد، کش مشترک یا ابزار دارای اختیار گسترده را خودبه‌خود حل نمی‌کند. در انتخاب معماری، محل اجرا را در کنار مدل دسترسی، به‌روزرسانی، پشتیبان‌گیری و توان بهره‌برداری بسنجید.
برای یک سازمان، ممکن است مدل و نمایه هر دو در زیرساخت داخلی باشند. برای سازمان دیگر، ترکیب منابع کم‌حساس در ابر و منابع محدود در محیط اختصاصی مطرح شود. این تصمیم باید از طبقه‌بندی واقعی داده به دست آید. انتخاب یک برچسب مانند «ابری» یا «خصوصی» جای نقشهٔ جریان داده و مسئولیت‌ها را نمی‌گیرد.
نقطهٔ شروع یک پروژهٔ سازمانی
یک واحد، چند نقش، مجموعه‌ای از منابع نماینده و سؤال‌های پرتکرار را انتخاب کنید. مالک هر منبع را مشخص کنید و هم‌زمان معیارهای کیفیت، مجوز و عملیات را بنویسید. محصولی که برای کارکنان مفید است باید هم پاسخ را سریع‌تر در دسترس قرار دهد و هم راه بازگشت به سند معتبر را روشن نگه دارد.
پیش از توسعه به واحد بعدی، بررسی کنید کدام کنترل‌ها واقعاً آزموده شده‌اند، چه خطاهایی باز مانده‌اند و چه کسی مسئول رسیدگی است. بزرگ شدن تعداد فایل‌ها و کاربران، فقط افزایش ظرفیت نیست؛ پیچیدگی نقش‌ها و چرخهٔ دانش هم بیشتر می‌شود. پایلوت زمانی ارزش توسعه دارد که این تجربهٔ نگهداری را نیز روشن کرده باشد.
منابع و مطالعهٔ بیشتر
منابع این مطلب در انتهای مقاله آمده‌اند. محتوا با کمک ابزارهای هوش مصنوعی تدوین می‌شود و تاریخ بازبینی آن مشخص است.
