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

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

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

دسترسی پرقدرت یک دارایی حساس است

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

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

حساب شخصی و نقش مدیریتی را جدا کنیم

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

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

نقش‌ها را بر اساس کار تعریف کنیم

در سناریوی ما، کارشناس Backup برای بررسی Job و اجرای بازیابی آزمایشی به دسترسی نیاز دارد، اما لزوماً نباید بتواند Repository را حذف یا تنظیمات شبکه را تغییر دهد. مدیر مجازی‌سازی نیز برای مدیریت Cluster به مجوز نیاز دارد، اما دسترسی به همه داده‌های سامانه‌ها جزو وظیفه او نیست.

مدل Role Based Access Control دسترسی را به نقش وصل می‌کند. نقش‌ها باید از روی وظایف واقعی ساخته شوند: مشاهده، عملیات روزمره، تغییر پیکربندی، مدیریت امنیت و مدیریت کامل. اگر نقش «مدیر کامل» پاسخ پیش‌فرض باشد، اصل حداقل دسترسی فقط در سیاست باقی می‌ماند.

حساب مشترک زنجیره مسئولیت را قطع می‌کند

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

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

احراز هویت چندعاملی باید به مسیر مدیریت برسد

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

اگر پنل اصلی MFA دارد اما همان سامانه از طریق SSH، API یا کنسول بدون کنترل مشابه در دسترس است، مهاجم مسیر ساده‌تر را انتخاب می‌کند. نقشه مسیرهای مدیریت باید تمام کانال‌ها را پوشش دهد. استثناها نیز باید محدود، ثبت‌شده و زمان‌دار باشند.

ایستگاه مدیریتی دامنه مواجهه را کاهش می‌دهد

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

این محیط باید Patch، حفاظت Endpoint، ثبت رویداد و محدودیت نرم‌افزار داشته باشد. اتصال از شبکه‌های عمومی یا دستگاه شخصی نباید مسیر عادی باشد. تجربه کاربری نیز اهمیت دارد؛ اگر مسیر رسمی بسیار کند یا ناپایدار باشد، کارکنان به میان‌برهای ناامن بازمی‌گردند.

دسترسی موقت از دسترسی دائمی ایمن‌تر است

بسیاری از مجوزهای کامل فقط برای یک تغییر یا حادثه لازم‌اند، اما پس از پایان کار باقی می‌مانند. مدل Just in Time دسترسی را پس از درخواست و تأیید برای زمان محدود فعال می‌کند. این روش پنجره سوءاستفاده را کاهش می‌دهد و دلیل دسترسی را کنار رویداد ثبت می‌کند.

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

حساب اضطراری باید وجود داشته باشد و پنهان نماند

در بحران ممکن است سامانه هویت یا ابزار مدیریت دسترسی در دسترس نباشد. حساب Break Glass برای چنین وضعیتی لازم است، اما اگر رمز آن میان افراد گردش کند یا استفاده‌اش پایش نشود، به در پشتی دائمی تبدیل می‌شود. تعداد این حساب‌ها باید محدود و نگهداری اعتبارنامه آن‌ها کنترل‌شده باشد.

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

Backup باید از همان هویت عمومی جدا باشد

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

حساب‌های سرویس، Credentialهای Repository و نقش‌های بازیابی باید حداقل دسترسی را داشته باشند. حذف نسخه‌ها یا تغییر دوره نگهداری می‌تواند به تأیید اضافه نیاز داشته باشد. نسخه Immutable زمانی ارزش دارد که مسیر مدیریت آن نیز محافظت شود.

حساب‌های سرویس را از حساب افراد جدا کنیم

اسکریپت‌ها، Agentها و یکپارچه‌سازی‌ها به هویت نیاز دارند، اما استفاده از حساب شخصی یا رمز ثابت مشترک مشکل‌ساز است. با تغییر شغل فرد، سرویس از کار می‌افتد یا دسترسی قدیمی باقی می‌ماند. حساب سرویس باید مالک فنی و کسب‌وکاری، هدف مشخص و مجوز محدود داشته باشد.

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

ثبت فرمان از ثبت ورود مهم‌تر است

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

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

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

ساخت حساب و فراموش‌کردن آن، دسترسی را با ساختار قدیمی سازمان منطبق نگه می‌دارد. پروژه‌ها تمام می‌شوند، پیمانکاران می‌روند و افراد نقش عوض می‌کنند. مالک هر سامانه باید در دوره مشخص فهرست دسترسی‌های حساس را بازبینی و ادامه نیاز را تأیید کند.

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

پیمانکار و پشتیبانی بیرونی مسیر جدا می‌خواهند

تیم بیرونی ممکن است برای رفع خطا به دسترسی فوری نیاز داشته باشد، اما حساب دائمی مشترک برای چند نفر، مسئولیت را مبهم می‌کند. هر جلسه دسترسی باید به فرد، سازمان، Ticket و بازه زمانی مشخص متصل باشد. اتصال از مسیر امن و ترجیحاً با ثبت نشست انجام می‌شود.

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

سرعت عملیات را با طراحی حفظ کنیم

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

نقش‌های از پیش تعریف‌شده، دسترسی زمان‌دار و Runbook باعث می‌شوند تیم بدون درخواست موردی طولانی کار کند. معیار موفقیت فقط کاهش مجوز نیست؛ زمان پاسخ، تعداد میان‌برها و رضایت عملیات نیز باید سنجیده شود.

از یک دامنه محدود شروع کنیم

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

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

شاخص‌هایی که مدیریت باید ببیند

تعداد حساب‌های پرقدرت، درصد حساب‌های دارای مالک، پوشش MFA، تعداد حساب مشترک، سن Credentialهای سرویس و دسترسی‌های موقت منقضی‌نشده شاخص‌های اصلی‌اند. زمان لغو دسترسی پس از خروج فرد و تعداد استفاده از Break Glass نیز آمادگی فرایند را نشان می‌دهد.

گزارش باید روند و استثنا را توضیح دهد. صفرکردن همه استثناها شاید ممکن نباشد، اما هر استثنا باید دلیل، کنترل جبرانی و تاریخ پایان داشته باشد. هیئت‌مدیره به فهرست نام کاربری نیاز ندارد؛ باید بداند دامنه آسیب و قابلیت پیگیری در حال بهترشدن است یا نه.

نقش راگا در ارزیابی دسترسی حساس

راگا می‌تواند مسیرهای مدیریت در Virtualization، Network، Storage، Backup و Monitoring را کنار هم ترسیم کند. این بررسی نشان می‌دهد یک هویت در چند لایه قدرت دارد، کدام مسیرها MFA یا ثبت کافی ندارند و کدام حساب‌ها بدون مالک یا بیش از نیاز فعال‌اند.

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

فرایند خروج همکار باید به سامانه‌ها برسد

واحد منابع انسانی ممکن است پایان همکاری را ثبت کند، اما حساب محلی روی Storage یا Hypervisor در فهرست مرکزی دیده نشود. Offboarding باید حساب‌های دامنه‌ای، محلی، VPN، کنسول، API و Credentialهای مشترک را پوشش دهد. زمان لغو برای دسترسی پرقدرت باید کوتاه و قابل گزارش باشد.

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

ابزار مدیریت دسترسی پس از طراحی فرایند انتخاب می‌شود

راهکار PAM می‌تواند نگهداری Credential، دسترسی زمان‌دار، تأیید و ثبت Session را خودکار کند. اما اگر نقش‌ها، مالک‌ها و عملیات حساس مشخص نباشند، ابزار فقط حساب‌های نامنظم را در مخزن جدید جمع می‌کند. نیازها باید از سناریوهای واقعی استخراج شوند.

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

تعارض وظایف را در تغییرهای پرخطر رعایت کنیم

فردی که دسترسی می‌سازد، همان فرد نباید بدون نظارت آن را برای خود تأیید و لاگ را حذف کند. برای تغییرهای پرخطر مانند حذف Backup یا تغییر سیاست هویت، تأیید دوم می‌تواند دامنه خطا را کم کند. این کنترل باید محدود به عملیات واقعاً حساس باشد تا فرایند روزانه کند نشود.

نتیجه رخداد صبح دوشنبه

بررسی نشان می‌دهد ورود غیرمعمول مربوط به کارشناس شیفت بوده، اما او از حساب مشترک استفاده کرده و Ticket ثبت نشده است. حادثه امنیتی تأیید نمی‌شود، ولی سازمان نمی‌تواند با قطعیت نشان دهد چه فرمان‌هایی اجرا شده‌اند. این ابهام به‌اندازه کافی جدی است که مدیریت برنامه اصلاح را تصویب کند.

حساب مشترک طی یک دوره کنترل‌شده کنار گذاشته می‌شود، دسترسی‌های کامل کاهش می‌یابند و فعالیت‌های حساس به هویت شخصی و درخواست تغییر متصل می‌شوند. سؤال نهایی مدیریت این است: اگر یک Credential از دست رفت، چند سامانه و راه بازیابی هم‌زمان در خطر قرار می‌گیرند؟ طراحی دسترسی باید پاسخ این سؤال را تا حد ممکن کوچک و قابل کنترل کند.

چک‌لیست تصمیم‌گیری

• دارایی، مالک و سطح دسترسی واقعی ثبت شوند.
• دسترسی‌های اضافه و حساب‌های مشترک کاهش یابند.
• Patch، لاگ و مسیر پاسخ‌گویی کنترل شوند.
• هر اقدام اصلاحی مسئول، موعد و معیار پذیرش داشته باشد.

سؤالات متداول

اولین قدم ارزیابی امنیت زیرساخت چیست؟

از موجودی دارایی‌ها، مالک هر سامانه، حساب‌های مدیریتی و مسیرهای دسترسی شروع کنید.

ریسک‌ها چگونه اولویت‌بندی می‌شوند؟

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

خرید ابزار امنیتی برای کاهش ریسک کافی است؟

خیر. تنظیمات، فرایند بهره‌برداری، مانیتورینگ، مسئول پاسخ‌گویی و آزمون کنترل‌ها تعیین‌کننده‌اند.

منابع

[۱] NIST — کنترل‌های دسترسی و ثبت فعالیت در SP ۸۰۰ ۵۳ مشاهده منبع

[۲] CISA — راهنمای مدیریت هویت و دسترسی مشاهده منبع

مطالب مرتبط در سایت راگا

برای تکمیل این مسیر، خدمات امنیت شبکه و فایروال راگا و مقاله «دیتاسنتر دوم داریم و باید بدانیم هنگام بحران چه چیزی به آن منتقل می‌شود» را ببینید.