
آزمون دسترسی کارکنان به اسناد در دستیار هوش مصنوعی باید نشان دهد هر کاربر فقط اطلاعات مجاز خود را دریافت میکند؛ هم در متن پاسخ، هم در ارجاع و هم هنگام بازکردن فایل. یک پاسخ درست برای مدیر ممکن است برای کارشناس واحد دیگر افشای اطلاعات باشد. بنابراین کیفیت پاسخ و مجوز مشاهده دو نتیجهٔ جدا در گزارش آزموناند.
این راهنما برای مدیر پروژه، مالک اسناد و تیم فنی است که میخواهند نمونهٔ دستیار داخلی را تحویل بگیرند یا تغییر دسترسی را بررسی کنند. راهنمای ساخت پایگاه دانش چتبات مراحل عمومی و فایل دوازده سناریوی پایه را دارد؛ اینجا یک تمرین عمیقتر برای مرز مجوز و تغییر نقش میسازیم. همهٔ نامها، سندها و کدهای تمرین زیر فرضی و آموزشیاند.
ابتدا مشخص کنید «مجاز بودن» دقیقاً یعنی چه
برای هر سند، مالک کسبوکار تعیین کند چه گروهی به چه بخشی دسترسی دارد. عبارت «کارکنان شرکت» کافی نیست: ممکن است دو کارشناس همرده در دو پروژه، مجوز متفاوت داشته باشند. در جدول دسترسی، مشاهدهٔ خلاصه، دیدن عنوان، دریافت فایل و مشاهدهٔ تاریخچه را جدا کنید. اگر عنوان یک سند نیز اطلاعات محدود دارد، پنهانکردن متن بهتنهایی کافی نیست.
ورود موفق به سامانه، مجوز مشاهدهٔ همهٔ منابع نیست. راهنمای مجوزدهی OWASP بر کمترین دسترسی لازم، رد دسترسی در نبود مجوز مشخص و بررسی مجوز در هر درخواست تأکید میکند. در طراحی دستیار، همین قاعده باید به پاسخ، پیوست و مسیر دریافت منبع برسد. جملهٔ «محرمانهها را نشان نده» در دستور مدل، کنترل فنی مجوز محسوب نمیشود. اگر خود فایل دستور تغییر رفتار داشته باشد، کنترل دستورهای مخرب داخل سند نیز باید جدا آزموده شود.
یک مجموعهٔ کوچک با انتظار روشن بسازید
الگوی پیشنهادی این مقاله از سه حساب آزمایشی و سه سند ساختگی شروع میشود. مالک محتوا پیش از اجرای آزمون، جدول زیر را تأیید میکند. حسابها باید مستقل باشند؛ نوشتن «من مدیرم» در گفتگو تغییر نقش واقعی نیست. برای سند محدود، یک عبارت ساختگی و بیخطر مانند «نشان آزمون بنفش» قرار دهید تا مشاهدهٔ آن در خروجی غیرمجاز بهسادگی قابل تشخیص باشد.
| سند فرضی | کارشناس فروش | کارشناس پشتیبانی | مسئول اسناد |
|---|---|---|---|
| راهنمای عمومی محصول، DEMO-PUBLIC | متن و فایل مجاز | متن و فایل مجاز | متن و فایل مجاز |
| روال داخلی پشتیبانی، DEMO-SUPPORT | متن، عنوان و فایل غیرمجاز | متن و فایل مجاز | متن و فایل مجاز |
| پیشنویس بازبینی، DEMO-DRAFT | غیرمجاز | غیرمجاز | فقط بررسی در محیط آزمون |
برای تکرار همین تمرین، در DEMO-SUPPORT نسخهٔ ۱ بنویسید: «درخواست پشتیبانی با فرم ساختگی F-S01 ثبت میشود؛ نشان آزمون بنفش.» سند عمومی فقط معرفی محصول و پیشنویس فقط متن بازبینی ساختگی داشته باشند. این جدول سیاست همهٔ شرکتها نیست. اگر عنوان سند در سازمان شما عمومی است، انتظار آزمون را همانطور تنظیم کنید. پیشنویس نیز صرفاً به دلیل دسترسی مسئول اسناد نباید منبع پاسخ جاری کارکنان شود؛ اعتبار محتوا و نسخهٔ قابلاستفاده از مجوز کاربر مستقل است.
همان پرسش را از ابتدا تا دریافت فایل دنبال کنید
پرسش «برای ثبت درخواست پشتیبانی از کدام فرم استفاده کنم؟» را یکبار با کارشناس پشتیبانی و بار دیگر با کارشناس فروش اجرا کنید. برای نقش مجاز، پاسخ باید از DEMO-SUPPORT و نسخهٔ مشخص آن بیاید و فایل منبع باز شود. برای نقش غیرمجاز، پاسخ نباید متن یا نشان ساختگی سند را بازگو کند. اگر مسیر عمومی درخواست وجود دارد، معرفی همان مسیر مجاز کافی است.
تیم فنی در محیط کنترلشده باید جداگانه بررسی کند کدام شناسههای سند و قطعه به مدل تحویل شدهاند. پنهانماندن اطلاعات در جواب نهایی، بهتنهایی ثابت نمیکند سند غیرمجاز بازیابی نشده است. در مستند کنترل دسترسی در سطح سند مایکروسافت، محدودکردن نتیجه با مجوز کاربر در مرحلهٔ جستوجو توضیح داده شده است؛ اجرای آن به منبع داده و روش همگامسازی وابسته است.
اکنون ارجاع پاسخ را با همان حساب باز کنید. سپس با حساب آزمایشی غیرمجاز، همان نشانی از پیشتعیینشده را بررسی کنید؛ آزمون فقط روی منابع و حسابهای مجاز تیم انجام شود. ممکن است پاسخ چت محدود باشد ولی فایل پشت ارجاع بدون کنترل باز شود. نتیجهٔ «پاسخ مجاز» و «دریافت فایل مجاز» را در دو ستون بنویسید تا یکی، ضعف دیگری را پنهان نکند.
تغییر نقش را وسط یک گفتگوی باز آزمایش کنید
در تمرین فرضی، کارشناس پشتیبانی به واحد فروش منتقل میشود. ابتدا با مجوز قبلی یک پاسخ دریافت کنید؛ سپس مسئول دسترسی، عضویت آزمایشی او را تغییر دهد و زمان تغییر ثبت شود. همان پرسش را در گفتگوی قبلی و یک گفتگوی تازه تکرار کنید. در هر دو حالت، سامانه باید مطابق سیاست جاری و زمان اعمال مجوز عمل کند؛ سابقهٔ گفتگو نباید مجوز تازه ایجاد کند.
سه زمان را جدا ثبت کنید: تغییر در مرجع هویت، رسیدن تغییر به لایهٔ مجوز یا نمایه، و نخستین پاسخ منطبق با وضعیت جدید. سند مایکروسافت تصریح میکند در روشهایی که مجوز در نمایه نگهداری میشود، تغییر منبع پس از همگامسازی مربوط در نتایج منعکس میشود. بنابراین عبارت «لغو فوری دسترسی» باید با رفتار واقعی همهٔ اجزا سنجیده شود، نه صرفاً پیام موفقیت پنل مدیریت.
پاسخی که قبلاً به کاربر تحویل شده ممکن است کپی یا ذخیره شده باشد؛ لغو دسترسی به معنی پسگرفتن آن نسخه نیست. اما درخواست تازه، پاسخ ذخیرهشدهٔ سامانه، پیشنمایش ارجاع و دانلود مجدد باید مطابق سیاست جدید کنترل شوند. دربارهٔ نمایش پیامهای قدیمی، مالک سامانه باید قاعدهٔ روشن داشته باشد و تیم همان رفتار را در گزارش ثبت کند.
خطاهای مجوز را با میانگین کیفیت پنهان نکنید
| مشاهده در تمرین | تفسیر | اقدام برای پذیرش |
|---|---|---|
| پاسخ درست است، اما سند محدود به نقش غیرمجاز رسیده | نقض مرز دسترسی | توقف پذیرش مسیر آسیبدیده و اصلاح کنترل |
| پاسخ محدود است، ولی لینک فایل باز میشود | مجوز دانلود با چت همراستا نیست | اصلاح مسیر دریافت فایل و تکرار آزمون |
| نقش مجاز هم پاسخ نمیگیرد | محدودیت بیش از نیاز یا نقص بازیابی | بررسی نگاشت گروهها و ثبت خطای جدا |
| پس از تغییر نقش، پاسخ قبلی دوباره برمیگردد | احتمال مجوز یا پاسخ ذخیرهشدهٔ کهنه | بررسی همگامسازی و کش در دامنهٔ آزمون |
برای هر اجرا، شناسهٔ آزمون، نقش، زمان، نسخهٔ سیاست دسترسی، شناسهٔ منابع بازیابیشده، نتیجهٔ پاسخ و نتیجهٔ بازشدن فایل را نگه دارید. توکن ورود و متن کامل اسناد حساس نباید وارد گزارش مدیریتی شوند. گزارش میتواند شناسهٔ سند و نوع خطا را نشان دهد؛ شاهد جزئی فقط در محل محدود و متناسب با نیاز بازبینی نگهداری شود.
چه چیزی برای تحویل قابل قبول است؟
پیش از آزمون، دامنه و حد پذیرش را مکتوب کنید. پیشنهاد این راهنما این است که هر افشای مشاهدهشده در سناریوهای توافقشده، مانع پذیرش همان مسیر باشد؛ تعداد زیاد پاسخهای صحیح آن را جبران نکند. «همهٔ آزمونهای اجراشده قبول شدند» نیز با «همهٔ حالتهای ممکن امناند» برابر نیست. نقش، منبع یا مسیری که آزموده نشده باید صریحاً در محدودیت گزارش بماند.
برای دستیار هوش مصنوعی اسناد سازمان، جدول مجوز مصوب و نتیجهٔ آزمون تغییر نقش میتوانند بخشی از تحویل باشند. اگر دستیار فعال دارید، این سناریوها را پس از تغییر اتصال، گروههای کاربران یا تنظیمات پاسخ در دامنهٔ پشتیبانی و ارزیابی کیفیت دستیار هوش مصنوعی بازاجرا کنید. خروجی مطلوب، فهرست خطاهای قابل پیگیری و شاهد اصلاح آنهاست.
پرسش و پاسخ
خیر. نقش باید از هویت معتبر و مجوزهای سامانه دریافت شود. ادعای کاربر در گفتگو نباید دسترسی به سند ایجاد کند. آزمون را با حسابهای مستقل و مجوز واقعی انجام دهید.
زیرا پاسخ چت و دریافت فایل ممکن است از مسیرهای متفاوت عبور کنند. محدودبودن متن پاسخ، کنترل مجوز فایل یا پیشنمایش آن را ثابت نمیکند.
پرسش تازه در گفتگوی قدیمی و جدید، پاسخ ذخیرهشدهٔ سامانه و دریافت دوبارهٔ منبع. اطلاعاتی که قبلاً تحویل و کپی شده، با تغییر مجوز خودبهخود پس گرفته نمیشود.




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