«دسترسی را تنظیم کردیم» هنوز یک ادعاست
جلسه‌ی تصویب راهاندازی یک دستیار هوشمند سازمانی است. مدیر امنیت می‌پرسد: «از کجا بدانم کارمند واحد بازرگانی نامه‌ی محرمانه‌ی واحد حقوقی را نمی‌بیند؟» مدیر فناوری اطلاعات جواب میدهد: «دسترسی‌ها را تنظیم کردیم.» و جلسه همان‌جا گیر می‌کند. تنظیم کردن یک کار است و اثبات کردن کار دیگر. مدیر امنیت چیزی می‌خواهد که بتواند امضا کند، نه چیزی که بشنود.
خبر خوب این است که اثبات این موضوع کار پیچیده‌ای نیست. نه ابزار اضافه می‌خواهد، نه تخصص ویژه. فقط یک روش منظم می‌خواهد که ببیند سامانه در رفتار واقعی‌اش چه می‌کند. این مقاله همین روش را در 5 قدم می‌گوید، برای تیمی که می‌خواهد دانابات را پیش از راهاندازی در سازمان بسنجد.
دانابات دسترسی را کجا اعمال می‌کند
قبل از تست باید بدانید چه چیزی را تست می‌کنید. سه اصل در طراحی دانابات به دسترسی مربوط است. اول، فیلتر روی ورودی است نه روی خروجی. یعنی سندی که کاربر اجازه‌ی دیدنش را ندارد اصلاً وارد فرآیند ساخت پاسخ نمیشود، نه اینکه پاسخ ساخته شود و بعد سانسور شود. دوم، در منابعی که به سامانهی خودِ سازمان وصل‌اند، دسترسی کاربر از همان سامانه استعلام می‌شود و اگر جواب «مجاز» نبود، سند نمایش داده نمیشود. سوم، سند غیرمجاز حتی در فهرست منابع هم دیده نمیشود.
بالای این، چهار سطح دسترسی ترکیب‌پذیر (دانشنامه، پوشه، فایل و گروه)، دسترسی بر اساس چارت سازمانی و برای دانش‌نامه‌های حساس یک رمز دومرحله‌ای پیامکی وجود دارد. اگر می‌خواهید لایه‌های حاکمیتی بالاتر را بشناسید، مقاله‌ی حاکمیت داده و دسترسی آن‌ها را توضیح میدهد.
یک نکته‌ی مهم که باید در تست به یاد داشته باشید: لینک عمومی دانشنامه کنترل دسترسی در سطح سند ندارد و پنل هنگام فعال‌کردنش هشدار میدهد. پس هر چیزی که قرار است محدود بماند، نباید از این مسیر منتشر شود.
چه کسی تست را اجرا می‌کند
تست پذیرش کار یک نفر نیست. دست‌کم 3 نفر لازم است: یک نفر از فناوری اطلاعات که سامانه را می‌شناسد، یک نفر از امنیت که قضاوت می‌کند چه چیزی «نشت» حساب می‌شود و یک نماینده‌ی واحدی که اسناد حساس دارد، مثلاً حقوقی یا منابع انسانی. نفر چهارم میتواند صاحب سند باشد که بداند محتوای سند واقعاً چیست.
دلیل این ترکیب ساده است: مدیر فناوری اطلاعات نمی‌داند کدام نامه واقعاً محرمانه است و نماینده‌ی واحد نمی‌داند سامانه چطور کار می‌کند. هر کدام نیمی از تصویر را دارند.
قدم اول: شخصیت‌های آزمون را انتخاب کنید
به‌جای «کاربر عادی» و «مدیر»، چند شخصیت مشخص بسازید که مرز دسترسی را واقعاً آزمایش کنند. پیشنهاد ما 6 شخصیت است: یک کارمند عادی، یک مدیر میانی از واحدی دیگر، یک نیروی تازه‌وارد، یک پیمانکار، کسی که هفته‌ی گذشته از واحد A به واحد B منتقل شده، و یک مدیر ارشد.
ترکیب دو شخصیت آخر از همه جالب‌تر است. فرد منتقل‌شده کسی است که دسترسی قدیمی‌اش ممکن است هنوز جایی مانده باشد، و مدیر ارشد کسی است که انتظار داریم بیشترین دسترسی را داشته باشد ولی نه لزوماً به همه‌چیز. اگر دانشنامه یا انتشار شما برای مخاطب بیرونی هم باز است، یک «غریبه» هم به این فهرست اضافه کنید: کسی که هیچ حسابی ندارد.
قدم دوم: سوال‌های تله بسازید
برای هر شخصیت، 3 دسته سوال آماده کنید که جواب‌شان فقط در اسنادی است که نباید ببیند.
دسته‌ی اول سوال مستقیم است، مثل «جدول حقوق مدیران ارشد چیست؟» دسته‌ی دوم سوال غیرمستقیم است که فقط وجود یک سند را می‌پرسد: «آیا درباره‌ی ادغام واحد X صورت‌جلسه‌ای تنظیم شده؟» چون گاهی وجود یک سند هم خودش یک اطلاعات است. دسته‌ی سوم سوال ترکیبی است که بخشی از جوابش در اسناد مجاز و بخشی در اسناد غیرمجاز است: «روند تصمیم‌گیری درباره‌ی پروژه‌ی Y را از ابتدا بگو.» اینجا انتظار این است که سامانه فقط از قسمت مجاز استفاده کند و بخش غیرمجاز را وارد جواب نکند.
برای هر سوال، «پاسخ مورد انتظار» را هم از قبل بنویسید. معمولاً «یافت نشد» است. بدون این ستون، تست یک نظرسنجی سلیقه‌ای می‌شود.
قدم سوم: سه جا را نگاه کنید، نه فقط متن پاسخ
بیشتر تست‌ها همین‌جا ناقص می‌مانند: فقط به متن جواب نگاه می‌کنند. ولی نشت میتواند در سه جا رخ دهد. اول در خود متن پاسخ. دوم در فهرست منابع زیر پاسخ، چون نام یک سند محرمانه هم میتواند اطلاعات باشد؛ در طراحی دانابات سند غیرمجاز در این فهرست هم نمیآید و شما باید همین را با چشم ببینید. سوم در پیشنهادهای ادامهی گفتگو و تاریخچهی جلسه.
یک نکته‌ی دیگر: کانال‌ها را جدا تست کنید. ویجت، تلگرام و بله، گفتینو و API هر کدام یک مسیر انتشار با تنظیمات مجزا هستند و هر دانشنامه برای هر انتشار جداگانه اجازه می‌گیرد. اگر فقط در ویجت تست کنید و بعد آن را روی بله هم منتشر کنید، یک مسیر آزمون‌نشده باز گذاشته‌اید. قاعده‌ی «حوزه‌ی کاربرد سند» را هم بسنجید: سندی که مخصوص یک گروه است نباید برای پرسشگر گروه دیگر جواب ساخته شود.
قدم چهارم: تغییر را تست کنید، نه فقط وضعیت ثابت را
سامانهی دسترسی روزی که تنظیم می‌شود درست است. سوال اصلی این است که یک ماه بعد، وقتی آدم‌ها جابه‌جا شده‌اند، چه می‌شود. پس تست پذیرش باید یک مرحله‌ی «تغییر» داشته باشد.
مجوز یکی از شخصیت‌ها را در سامانهی مبدأ بردارید و همان سوال را دوباره بپرسید. در منابعی که استعلام زنده‌ی دسترسی روشن است، انتظار می‌رود جواب فوراً عوض شود. برای کسی که در چارت سازمانی جابه‌جا شده، همین کار را تکرار کنید. و برای پیمانکار، مطمئن شوید با پایان قرارداد، دسترسی هم پایان می‌یابد؛ این موضوع را در مقاله‌ی مدیریت دسترسی موقت پیمانکاران جداگانه بررسی کرده‌ایم.