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