کنترل دسترسی‌های مدیریتی؛ ادمین کمتر، امنیت بیشتر

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

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

چرا دسترسی ادمین اینقدر حساس است؟

اکانت مدیریتی فقط برای ورود به سرور نیست. در عمل می‌تواند تنظیمات فایروال، روتر، سوئیچ، Active Directory، پنل مجازی‌سازی، بکاپ، سامانه مانیتورینگ، VPN، ایمیل و حتی سیستم‌های امنیتی را تغییر دهد. اگر این حساب‌ها بدون کنترل باقی بمانند، مهاجم می‌تواند ردپا را پاک کند، دسترسی جدید بسازد، سرویس‌ها را خاموش کند یا تنظیمات امنیتی را طوری تغییر دهد که حمله دیرتر دیده شود.

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

اصل حداقل دسترسی

اصل least privilege یعنی دسترسی به اندازه نیاز، نه بیشتر. مدیر Helpdesk لازم نیست همیشه دسترسی کامل Domain Admin داشته باشد. کارشناس شبکه لازم نیست با یک اکانت مشترک وارد همه تجهیزات شود. حساب سرویس بکاپ نباید بتواند روی کل دامنه کارهای غیرمرتبط انجام دهد.

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

اکانت‌های مشترک؛ مشکل قدیمی و خطرناک

وجود یک اکانت مثل admin، netadmin یا root که چند نفر رمز آن را دارند، هنوز در خیلی از شبکه‌ها دیده می‌شود. مشکل فقط لو رفتن رمز نیست. مشکل بزرگ‌تر این است که بعد از تغییر تنظیمات یا حادثه، نمی‌توان دقیق فهمید چه کسی وارد شده و چه کاری انجام داده است.

راه بهتر این است که هر مدیر حساب اختصاصی داشته باشد و ورودها با لاگ مرکزی ثبت شوند. اگر تجهیزات قدیمی امکان اتصال به TACACS+، RADIUS یا LDAP ندارند، حداقل باید رمز آنها در سامانه مدیریت رمز نگهداری شود و دسترسی به رمزها ثبت و محدود باشد.

MFA برای دسترسی‌های حساس

برای حساب‌های ادمین، رمز عبور به تنهایی کافی نیست. MFA باید برای VPN، پنل‌های مدیریتی، ایمیل مدیران، حساب‌های ابری، کنترل پنل هاست، Git، ابزار مانیتورینگ و سامانه‌های مدیریت پسورد فعال باشد. در محیط‌هایی که ادمین‌ها از بیرون سازمان وصل می‌شوند، نبود MFA یک ریسک مستقیم است.

برای دسترسی‌های خیلی حساس، بهتر است ورود فقط از سیستم‌های مشخص، شبکه‌های مشخص یا Jump Server انجام شود. این کار سطح حمله را کمتر می‌کند و لاگ‌ها را هم متمرکزتر نگه می‌دارد.

مدیریت رمز و کلیدها

رمز ادمین نباید در فایل‌های متنی، چت‌ها، ایمیل‌ها یا اسکریپت‌های ساده بماند. کلیدهای SSH، API Tokenها و رمز حساب‌های سرویس هم همانقدر حساس هستند. برای این موارد باید از Password Vault یا Secret Manager استفاده شود و دسترسی به آنها قابل ثبت و قابل بازبینی باشد.

• رمز حساب‌های ادمین بعد از خروج نیرو یا تغییر نقش عوض شود.
• کلیدهای SSH قدیمی و بدون مالک حذف شوند.
• توکن‌های API تاریخ انقضا و مالک مشخص داشته باشند.
• رمزهای ذخیره‌شده در اسکریپت‌ها به Secret Manager منتقل شوند.

ثبت لاگ و هشدار

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

چند هشدار ساده ارزش زیادی دارد: ورود ادمین در ساعت غیرعادی، ورود از کشور یا IP ناشناس، اضافه شدن کاربر به گروه‌های حساس، غیرفعال شدن MFA، تغییر تنظیمات لاگ و تلاش‌های ناموفق زیاد روی حساب‌های مدیریتی.

حساب‌های سرویس را دست کم نگیرید

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

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

چک‌لیست سریع کنترل دسترسی مدیریتی

• آیا حساب‌های ادمین شخصی و قابل ردیابی هستند؟
• آیا حساب‌های مشترک حذف یا محدود شده‌اند؟
• آیا MFA برای مسیرهای مدیریتی فعال است؟
• آیا گروه‌های Domain Admin، Enterprise Admin و ادمین‌های شبکه دوره‌ای بازبینی می‌شوند؟
• آیا ورود و تغییرات ادمین‌ها در SIEM یا لاگ مرکزی ثبت می‌شود؟
• آیا حساب‌های سرویس دسترسی حداقلی دارند؟
• آیا رمزها، کلیدها و توکن‌ها در محل امن نگهداری می‌شوند؟

چک‌لیست ذهنی برای کنترل دسترسی‌های مدیریتی

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