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