کنترل امنیت شماره ۱۴: دسترسی بر اساس نیاز کاری، نه اعتماد کلی

در شبکه‌های واقعی، دسترسی‌ها معمولا یک‌باره خراب نمی‌شوند؛ آرام‌آرام زیاد می‌شوند. یک کاربر به پوشه‌ای نیاز داشته، عضو یک گروه شده، بعد سمتش عوض شده، ولی دسترسی قبلی مانده است. چند سال بعد همان دسترسی تبدیل می‌شود به مسیر خوب برای نشت اطلاعات یا حرکت جانبی مهاجم.

مبنای این مطلب: SANS Critical Security Control 14: Controlled Access Based on the Need to Know، یعنی «دسترسی کنترل‌شده بر اساس نیاز کاری» در فهرست ۲۰ کنترل امنیتی SANS/CIS. متن زیر ترجمه خشک کنترل نیست؛ برداشت عملی از همان کنترل برای شبکه و زیرساخت سازمانی است.

کنترل شماره ۱۴ می‌گوید دسترسی باید بر اساس نیاز کاری باشد. یعنی کاربر، اکانت سرویس، مدیر سیستم و حتی تیم‌های فنی فقط به همان داده و سرویسی دسترسی داشته باشند که واقعا برای انجام کار لازم است.

فرق این کنترل با کنترل ادمین چیست؟

کنترل دسترسی مدیریتی که در کنترل شماره ۵ درباره‌اش نوشتم، بیشتر روی اکانت‌های ادمین تمرکز دارد. کنترل ۱۴ گسترده‌تر است. اینجا بحث همه دسترسی‌هاست: فایل، دیتابیس، پنل داخلی، گزارش‌ها، CRM، SharePoint، فولدرهای پروژه و حتی دسترسی API.

گروه‌ها باید قابل فهم باشند

اگر اسم گروه‌ها نامفهوم باشد، بعد از مدتی کسی جرئت حذف دسترسی ندارد. گروهی مثل Folder_X_RW_Old یا Temp_Access_2019 بعد از چند سال تبدیل به دردسر می‌شود. بهتر است گروه‌ها با ساختار روشن ساخته شوند: واحد، سیستم، سطح دسترسی و مالک.

• مالک هر دسترسی مشخص باشد.
• دسترسی موقت تاریخ پایان داشته باشد.
• گروه‌های قدیمی بدون مالک حذف یا بازطراحی شوند.
• دسترسی مستقیم به کاربر تا حد ممکن استفاده نشود.

بازبینی دوره‌ای لازم است

هیچ طراحی دسترسی برای همیشه درست نمی‌ماند. آدم‌ها جابه‌جا می‌شوند، پروژه‌ها تمام می‌شوند، سرویس‌ها تغییر می‌کنند. حداقل برای مسیرهای حساس باید بازبینی دوره‌ای داشته باشیم: چه کسی دسترسی دارد، چرا دارد، آخرین بار کی استفاده کرده و آیا هنوز لازم است یا نه.

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

Need to Know برای سرویس‌ها هم هست

اکانت سرویس‌ها معمولا فراموش می‌شوند. یک سرویس برای خواندن یک دیتابیس ساخته شده، ولی دسترسی Write یا حتی دسترسی به چند دیتابیس دیگر هم دارد. اگر آن سرویس آسیب ببیند، مهاجم از همان دسترسی اضافه استفاده می‌کند.

برای اکانت سرویس باید مشخص باشد کدام سیستم از آن استفاده می‌کند، چه سطح دسترسی دارد، رمز آن چطور نگهداری می‌شود و اگر غیرفعال شود چه چیزی از کار می‌افتد.

جمع‌بندی عملی

این کنترل بیشتر از اینکه ابزار بخواهد، نظم می‌خواهد. دسترسی‌ها را با مالک، دلیل، سطح و تاریخ بازبینی نگه داریم. هر دسترسی اضافه‌ای که امروز بی‌ضرر به نظر می‌رسد، ممکن است روز حادثه همان مسیری باشد که کار مهاجم را راحت می‌کند.