مدیریت دسترسی زمانی قابل اتکا است که ایجاد، تغییر و حذف آن به رویدادهای واقعی سازمان متصل باشد. استخدام، جابه‌جایی، مرخصی طولانی، تغییر پیمانکار و خروج هرکدام باید مسیر مشخصی داشته باشند. هدف فقط بستن حساب یک نفر نیست؛ سازمان باید بداند چه کسی، به چه داده‌ای، با چه دلیلی و تا چه زمانی دسترسی دارد.
در این راهنما، موضوع از چند زاویه بررسی می‌شود: خروج از سازمان یک رویداد امنیتی و عملیاتی است، فهرست دسترسی از شرح شغل شروع می‌شود، حساب شخصی، حساب خدماتی و حساب مشترک را جدا کنیم. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.
در این مقاله می‌خوانید
- خروج از سازمان یک رویداد امنیتی و عملیاتی است
- فهرست دسترسی از شرح شغل شروع می‌شود
- حساب شخصی، حساب خدماتی و حساب مشترک را جدا کنیم
- نقش واحد منابع انسانی در آغاز فرایند
خروج از سازمان یک رویداد امنیتی و عملیاتی است
در بسیاری از شرکت‌ها، فرایند خروج بر تسویه مالی، تحویل تجهیزات و مدارک اداری تمرکز دارد. دسترسی‌های دیجیتال میان چند تیم و چند سامانه پراکنده‌اند. اگر مسئول واحد فهرست کامل را نداند، درخواست بستن دسترسی فقط به موارد شناخته‌شده ارسال می‌شود. حساب‌های محلی، سرویس‌های ابری، پنل تأمین‌کننده یا کلیدهای فنی ممکن است جا بمانند.
این موضوع لزوماً به سوءنیت فرد خارج‌شده مربوط نیست. حساب فعال می‌تواند بعداً توسط مهاجم استفاده شود یا گزارش‌های ممیزی را مبهم کند. اگر نام یک کارمند سابق در رخداد دیده شود، تیم زمان ارزشمندی را صرف تشخیص مالک واقعی فعالیت می‌کند. حذف به‌موقع دسترسی، سطح حمله و پیچیدگی پاسخ‌گویی را کاهش می‌دهد.
فهرست دسترسی از شرح شغل شروع می‌شود
برای اصلاح، بهتر است سازمان ابتدا نقش‌ها و نیازهای کاری را بنویسد. کارشناس بازرگانی برای انجام وظیفه خود به کدام سامانه، پوشه، گزارش و ارتباط بیرونی نیاز دارد؟ چه دسترسی‌هایی عمومی نقش‌اند و کدام مورد استثنایی است؟ این تصویر کمک می‌کند هنگام ورود فرد، دسترسی بیش از نیاز داده نشود و هنگام خروج، موارد قابل حذف مشخص باشند.
دسترسی مبتنی بر نقش نیز به معنای ساختن گروه‌های بسیار کلی نیست. اگر همه اعضای واحد بازرگانی به همه قراردادها دسترسی داشته باشند، جابه‌جایی یک نفر میان تیم‌ها خطر را بیشتر می‌کند. نقش باید با مسئولیت واقعی، حساسیت اطلاعات و سطح اقدام هماهنگ باشد. بازبینی دوره‌ای نشان می‌دهد نقش‌ها با تغییر سازمان به‌روز مانده‌اند یا نه.
حساب شخصی، حساب خدماتی و حساب مشترک را جدا کنیم
حساب شخصی باید به یک فرد مشخص متصل باشد و فعالیت آن قابل انتساب بماند. حساب خدماتی برای اجرای برنامه یا ارتباط میان سامانه‌ها استفاده می‌شود و چرخه رمز، کلید و مالک فنی متفاوتی دارد. حساب مشترک میان چند نفر، انتساب را دشوار می‌کند و خروج یک نفر را به تغییر رمز برای همه وابسته می‌سازد.
در سناریوی ما، یک حساب مشترک برای دسترسی به پنل تأمین‌کننده وجود دارد. تیم نمی‌تواند مطمئن شود فرد خارج‌شده رمز را ذخیره نکرده است. تصمیم فوری، تغییر رمز و ثبت مالک جدید است؛ تصمیم پایدار، بررسی امکان ساخت حساب مجزا و ثبت رویدادهاست. اگر سرویس چنین امکانی ندارد، محدودیت باید به‌عنوان ریسک مستند شود و کنترل جبرانی داشته باشد.
نقش واحد منابع انسانی در آغاز فرایند
منابع انسانی زمان خروج و وضعیت همکاری را می‌داند، اما جزئیات هر حساب را مدیریت نمی‌کند. مدیر واحد می‌داند فرد چه مسئولیتی داشته و چه کاری باید تحویل شود. فناوری دسترسی‌های فنی را می‌بندد و امنیت نتیجه را پایش می‌کند. تدارکات یا حقوقی نیز ممکن است مالک پنل‌های بیرونی و قراردادها باشند. فرایند خوب این نقش‌ها را به یک جریان مشترک وصل می‌کند.
در فرم خروج باید زمان دقیق اثرگذاری مشخص باشد. خروج فوری، پایان قرارداد در انتهای روز و انتقال داخلی شرایط یکسانی ندارند. بعضی دسترسی‌ها باید پیش از جلسه خروج بسته شوند و برخی برای تحویل کنترل‌شده با تأیید مدیر باقی بمانند. عبارت کلی «دسترسی‌ها قطع شود» بدون زمان، دامنه و مسئول، قابل سنجش نیست.
دسترسی‌هایی که در سامانه مرکزی دیده نمی‌شوند
غیرفعال کردن حساب Active Directory یا سرویس هویت می‌تواند بخش بزرگی از دسترسی‌ها را متوقف کند، اما سامانه‌های محلی و حساب‌های مستقل ممکن است به آن متصل نباشند. پنل تجهیزات، حساب پایگاه داده، ابزار مانیتورینگ، مخزن کد، سرویس پیام‌رسان، سامانه فروشنده و دسترسی فیزیکی از نمونه‌هایی‌اند که باید جداگانه بررسی شوند.
تیم فناوری می‌تواند فهرستی از سامانه‌ها و مالک هرکدام ایجاد کند. برای هر سامانه مشخص شود هویت از کجا می‌آید، حذف کاربر چگونه انجام می‌شود و گزارش آخرین دسترسی کجاست. کامل شدن این فهرست زمان می‌برد؛ بهتر است از سرویس‌های حیاتی و حساب‌های دارای اختیار بالا آغاز شود. هدف مرحله اول پوشش ریسک‌های بزرگ‌تر است.
کلیدها، Tokenها و نشست‌های فعال را فراموش نکنیم
بستن نام کاربری همیشه همه مسیرها را قطع نمی‌کند. ممکن است کاربر Token فعال، کلید API، گواهی، نشست مرورگر یا رمز ذخیره‌شده داشته باشد. حساب‌های فنی نیز گاهی با نام فرد ساخته شده‌اند و حذف عجولانه آن‌ها یک سرویس را متوقف می‌کند. پیش از اقدام باید وابستگی و مالک جایگزین مشخص شود.
برای حساب پرریسک می‌توان خروج از همه نشست‌ها، ابطال Token، تغییر کلید و بررسی دستگاه‌های ثبت‌شده را در Runbook قرار داد. اگر سامانه امکان این کار را ندارد، باید محدودیت و روش جایگزین ثبت شود. تیم نباید در روز خروج برای نخستین بار بفهمد یک حساب شخصی، بخشی از عملیات سازمان را اجرا می‌کند.
تغییر نقش هم به اندازه خروج اهمیت دارد
کارمندی که از فروش به مالی منتقل می‌شود، معمولاً دسترسی‌های جدید می‌گیرد؛ اما دسترسی‌های قبلی همیشه حذف نمی‌شوند. پس از چند جابه‌جایی، فرد مجموعه‌ای از مجوزها دارد که هیچ نقش فعلی آن را توجیه نمی‌کند. این انباشت می‌تواند اصل حداقل دسترسی را بی‌اثر کند.
رویداد تغییر نقش باید دو بخش داشته باشد: افزودن نیازهای جدید و بازبینی نیازهای قبلی. مدیر قبلی و مدیر جدید هرکدام بخشی از تصمیم را تأیید می‌کنند. یک دوره کوتاه هم‌پوشانی ممکن است برای تحویل کار لازم باشد، ولی باید تاریخ پایان داشته باشد. دسترسی موقت بدون موعد، به‌تدریج دائمی می‌شود.
پیمانکار و تأمین‌کننده را در همان چرخه بیاوریم
کارکنان رسمی تنها هویت‌های سازمان نیستند. پیمانکار نگهداری، مشاور پروژه، فروشنده نرم‌افزار یا تیم نصب ممکن است دسترسی مدیریتی دریافت کنند. این دسترسی گاهی برای رفع یک مشکل فوری ساخته می‌شود و پس از پایان کار باقی می‌ماند. چون نام آن‌ها در فرایند خروج منابع انسانی نیست، هیچ رویدادی حذف را آغاز نمی‌کند.
برای دسترسی بیرونی، حامی داخلی، دامنه، زمان شروع و پایان و روش نظارت باید مشخص باشد. تمدید دسترسی نیازمند تأیید دوباره باشد و گزارش استفاده قابل مشاهده بماند. اگر پشتیبانی اضطراری لازم است، حساب می‌تواند غیرفعال باشد و فقط با فرایند کنترل‌شده فعال شود. این روش اختیار دائمی را به امکان دسترسی هنگام نیاز تبدیل می‌کند.
بازبینی دسترسی را به امضای تشریفاتی تبدیل نکنیم
ارسال یک فایل طولانی از نام کاربران به مدیر واحد معمولاً نتیجه ضعیفی دارد. مدیر ممکن است بدون شناخت سطح مجوز، همه موارد را تأیید کند. بازبینی باید به زبان قابل فهم نشان دهد هر فرد به چه منبعی و با چه سطحی دسترسی دارد و آخرین استفاده چه زمانی بوده است. موارد پرریسک یا بدون استفاده باید برجسته شوند.
مالک کسب‌وکار درباره نیاز به داده تصمیم می‌گیرد و تیم فناوری امکان فنی را بررسی می‌کند. اگر مدیر واحد نمی‌تواند دلیل یک دسترسی را بیان کند، آن مورد باید حذف یا محدود شود، مگر اینکه مالک دیگری مسئولیتش را بپذیرد. خروجی بازبینی، فهرست اقدام با مسئول و موعد است؛ امضای یک صفحه پایان کار نیست.
شواهدی که پایان دسترسی را اثبات می‌کنند
تیک خوردن یک چک‌لیست شروع خوبی است، اما برای حساب‌های حساس باید شاهد فنی وجود داشته باشد. گزارش غیرفعال شدن حساب، ابطال نشست‌ها، تغییر مالک کلید و آخرین ورود می‌تواند نگهداری شود. NIST در کنترل‌های مدیریت حساب بر غیرفعال کردن حساب‌ها در شرایطی مانند پایان همکاری و بازبینی دوره‌ای آن‌ها تأکید دارد.[۱]
شاهد باید متناسب با ریسک باشد. برای همه حساب‌ها لازم نیست پرونده سنگین ایجاد شود، اما دسترسی مدیریتی، اطلاعات مالی یا داده مشتری نیازمند اطمینان بیشتری است. نمونه‌برداری دوره‌ای از پرونده‌های خروج نیز کیفیت فرایند را نشان می‌دهد. اگر در پنج نمونه، دو حساب جا مانده باشد، مسئله فردی نیست و فرایند باید اصلاح شود.
خودکارسازی کجا مفید است و کجا کافی نیست؟
اتصال سامانه منابع انسانی به سرویس هویت می‌تواند زمان واکنش را کاهش دهد. پروتکل‌هایی مانند SCIM نیز برای خودکارسازی ایجاد و حذف هویت و مدیریت مجوزها به کار می‌روند.[۲] با این حال، خودکارسازی فقط سامانه‌های متصل و قواعد تعریف‌شده را پوشش می‌دهد. حساب محلی فراموش‌شده یا دسترسی استثنایی بیرون از جریان باقی می‌ماند.
پیش از خودکارسازی، منبع حقیقت و نقش مالک باید روشن شود. اگر تاریخ خروج اشتباه ثبت شود یا حساب خدماتی به نام کارمند باشد، اجرای خودکار می‌تواند اختلال ایجاد کند. طراحی باید مسیر استثنا، تأیید و بازگشت کنترل‌شده داشته باشد. خودکارسازی خوب، فرایند روشن را سریع‌تر می‌کند؛ فرایند مبهم را فقط با سرعت بیشتری تکرار می‌کند.
یک مانور خروج انجام دهیم
سازمان می‌تواند یک پرونده خروج اخیر را به‌صورت کنترل‌شده بازسازی کند. از لحظه اعلام منابع انسانی تا بستن آخرین دسترسی، زمان و اقدام‌ها ثبت شوند. سپس سامانه‌ها، حساب‌های بیرونی، کلیدها و نشست‌ها جست‌وجو شوند. هدف یافتن مقصر نیست؛ باید نقاطی که به حافظه افراد وابسته‌اند دیده شوند.
در سناریوی ما، مانور نشان می‌دهد پنل تأمین‌کننده مالک داخلی مشخصی ندارد. واحد خرید مسئول قرارداد است ولی حساب را فناوری ساخته است. مدیریت تصمیم می‌گیرد مالک کسب‌وکاری، مالک فنی و جانشین برای هر پنل تعیین شود. همین اصلاح کوچک، احتمال باقی ماندن دسترسی در خروج بعدی را کاهش می‌دهد.
نقش راگا در بازبینی چرخه دسترسی
راگا می‌تواند دارایی‌های هویتی و مسیر دسترسی در لایه‌های زیرساخت، مجازی‌سازی، شبکه، Storage، بکاپ و سامانه‌های مدیریتی را بررسی کند. تمرکز ارزیابی بر حساب‌های دارای اختیار، حساب‌های مشترک و خدماتی، دسترسی بیرونی و فرایند ایجاد، تغییر و حذف است. خروجی باید شکاف‌های قابل اقدام را نشان دهد.
برنامه اصلاح می‌تواند از حذف حساب‌های بلااستفاده، محدود کردن مسیرهای مدیریتی و تعریف مالک آغاز شود و سپس به یکپارچه‌سازی هویت، ثبت رویداد و خودکارسازی برسد. اولویت‌ها با حساسیت داده، دامنه اختیار و امکان سوءاستفاده تعیین می‌شوند. این مسیر اجازه می‌دهد سازمان با بودجه محدود، ابتدا خطرهای بزرگ‌تر را کاهش دهد.
تصمیم جلسه مدیریت
مدیرعامل سازمان می‌خواهد تا پایان هفته سه خروج اخیر نمونه‌برداری شوند. منابع انسانی زمان و وضعیت همکاری را می‌دهد، مدیران واحد نیازهای باقی‌مانده را تأیید می‌کنند و فناوری شواهد قطع دسترسی را جمع می‌کند. حساب مشترک تأمین‌کننده نیز باید مالک، رمز جدید و مسیر جایگزین داشته باشد.
سؤال «کدام دسترسی هنوز باز است؟» نباید فقط پس از یک حادثه مطرح شود. سازمان باید بتواند در زمان کوتاه پاسخ دهد چه هویت‌هایی فعال‌اند، چرا فعال‌اند و چه کسی مسئول آن‌هاست. بلوغ امنیتی از همین پاسخ‌گویی شروع می‌شود؛ از تبدیل یک نام در فهرست کارکنان به چرخه‌ای قابل مشاهده و قابل کنترل در کل زیرساخت.
داشبورد مدیریتی چرخه دسترسی چه چیزی نشان دهد؟
مدیریت به فهرست هزاران حساب نیاز ندارد. چند شاخص می‌تواند وضعیت را روشن کند: تعداد خروج‌های ثبت‌شده، درصد دسترسی‌های بسته‌شده در زمان هدف، حساب‌های بدون مالک، دسترسی‌های موقت منقضی‌شده و موارد استثنا. روند این شاخص‌ها نشان می‌دهد فرایند بهتر شده یا فقط یک پاک‌سازی مقطعی انجام شده است.
برای حساب‌های پرریسک می‌توان زمان از اعلام خروج تا قطع آخرین دسترسی را جدا گزارش کرد. اگر تأخیر بیشتر از هدف است، دلیل آن باید میان نبود مالک، وابستگی فنی یا خطای اطلاع‌رسانی تفکیک شود. گزارش باید به اصلاح فرایند کمک کند و به مسابقه برای سبز کردن اعداد تبدیل نشود. یک استثنای مستند و تأییدشده از حذف عجولانه حسابی که سرویس را متوقف می‌کند، قابل قبول‌تر است.
دسترسی‌های ممتاز را با اولویت بالاتر بررسی کنیم
همه حساب‌ها پیامد یکسانی ندارند. دسترسی مدیر دامنه، مجازی‌سازی، بکاپ، Storage یا فایروال می‌تواند محدوده بزرگی را تغییر دهد. برای این حساب‌ها، قطع دسترسی، ابطال نشست، تغییر کلید و بازبینی آخرین فعالیت باید سریع‌تر و با شاهد قوی‌تری انجام شود. حساب عادی یک سامانه کم‌حساسیت می‌تواند مسیر ساده‌تری داشته باشد.
اولویت‌بندی کمک می‌کند تیم با منابع محدود ابتدا اختیارهایی را کنترل کند که بیشترین دامنه اثر را دارند. فهرست حساب‌های ممتاز باید مالک و جانشین داشته باشد و تغییر آن‌ها بدون اطلاع باقی نماند. اگر حسابی به فرد خارج‌شده وابسته است، انتقال مالکیت پیش از حذف انجام می‌شود تا امنیت به توقف عملیات منجر نگردد.
زمان‌بندی قطع دسترسی نیز باید با سطح اختیار هماهنگ باشد. برای حساب ممتاز، تأخیر چندساعته می‌تواند مهم باشد؛ برای حساب کم‌خطر ممکن است پایان همان روز هدف قابل قبولی باشد. تعریف یک زمان ثابت برای همه، منابع را از موارد حساس دور می‌کند.
همچنین باید حساب‌های رهاشده‌ای بررسی شوند که مالکشان مدت‌ها پیش از سازمان رفته است. پاک‌سازی اولیه می‌تواند با گزارش آخرین ورود و تأیید مالک سامانه انجام شود. هر حساب بدون مالک یا دلیل کسب‌وکاری، نامزد حذف یا محدودسازی است.
نتیجه این بررسی باید در مالکیت سامانه‌ها ثبت شود و در خروج‌های بعدی به‌صورت خودکار یا کنترل‌شده مورد استفاده قرار گیرد.
چک‌لیست تصمیم‌گیری
- دارایی، مالک و سطح دسترسی واقعی ثبت شوند.
- دسترسی‌های اضافه و حساب‌های مشترک کاهش یابند.
- Patch، لاگ و مسیر پاسخ‌گویی کنترل شوند.
- هر اقدام اصلاحی مسئول، موعد و معیار پذیرش داشته باشد.
ریسک امنیتی را به اقدام اجرایی تبدیل کنید
دسترسی‌ها، تنظیمات، Patchها و مسئولیت بهره‌برداری زیرساخت را براساس ریسک واقعی بررسی کنید.
سؤالات متداول
اولین قدم ارزیابی امنیت زیرساخت چیست؟
از موجودی دارایی‌ها، مالک هر سامانه، حساب‌های مدیریتی و مسیرهای دسترسی شروع کنید.
ریسک‌ها چگونه اولویت‌بندی می‌شوند؟
حساسیت دارایی، سطح دسترسی، احتمال سوءاستفاده و اثر رخداد باید هم‌زمان سنجیده شوند.
خرید ابزار امنیتی برای کاهش ریسک کافی است؟
خیر. تنظیمات، فرایند بهره‌برداری، مانیتورینگ، مسئول پاسخ‌گویی و آزمون کنترل‌ها تعیین‌کننده‌اند.
منابع
[۱] NIST SP ۸۰۰-۵۳ Rev. ۵ — کنترل AC-۲ برای مدیریت حساب‌ها مشاهده منبع
[۲] Microsoft Learn — مدیریت خودکار چرخه حساب در محیط‌های سازمانی و Multi-Tenant مشاهده منبع
مطالب مرتبط در سایت راگا
برای تکمیل این مسیر، خدمات امنیت شبکه و فایروال راگا و مقاله «فضای ذخیره‌سازی داریم؛ پس چرا سامانه‌ها کند شده‌اند؟» را ببینید.