یکی از خطاهای رایج در کنترلهای فناوری اطلاعات این است که یک نفر بتواند درخواست ایجاد کند، آن را تأیید کند، تغییر را اجرا کند و در پایان همان تغییر را تأییدشده اعلام کند. حتی اگر آن فرد قابل اعتماد باشد، طراحی کنترل ضعیف است. اصل تفکیک وظایف یا Separation of Duties برای همین مسئله است: فعالیتهای حساس باید طوری تقسیم شوند که یک نفر بهتنهایی نتواند کل زنجیره تصمیم، اجرا و تأیید را کنترل کند.
این اصل در NIST SP 800-53 با کنترل AC-5 بهعنوان Separation of Duties شناخته میشود و در NIST Cybersecurity Framework نیز در کنار Least Privilege برای مدیریت دسترسیها و مجوزها دیده میشود.
تفکیک وظایف چه چیزی را کاهش میدهد؟
هدف SoD فقط جلوگیری از سوءاستفاده عمدی نیست. این کنترل احتمال خطای انسانی، تغییر بدون بازبینی، حذف شواهد و تصمیمگیری بدون نظارت را هم کاهش میدهد.
| ریسک | نمونه بدون SoD | کنترل پیشنهادی |
|---|---|---|
| تغییر غیرمجاز | ادمین خودش Change را ثبت و اجرا میکند | درخواست، تأیید و اجرا بین نقشها تقسیم شود |
| دسترسی بیش از حد | یک ادمین IAM هم Role میسازد و هم خودش را عضو میکند | Role Admin و Access Approver جدا باشند |
| حذف شواهد | مدیر سیستم به لاگ ممیزی همان سامانه دسترسی حذف دارد | Audit Log به سامانه یا نقش مستقل ارسال شود |
| تقلب در Backup | مجری Backup امکان حذف نسخهها و تأیید Restore Test را دارد | Backup Operator و Recovery Approver جدا شوند |
SoD با Least Privilege یکی نیست
Least Privilege میگوید هر کاربر فقط حداقل دسترسی لازم برای انجام وظیفه را داشته باشد. SoD میگوید حتی اگر دو دسترسی بهتنهایی مجاز باشند، ترکیب آنها در اختیار یک نفر ممکن است خطرناک باشد. بنابراین این دو اصل مکمل هم هستند.
برای نمونه، کارشناس شبکه ممکن است بهدرستی مجوز تغییر Configuration را داشته باشد و مدیر تغییر نیز بهدرستی مجوز Approval داشته باشد. مشکل زمانی ایجاد میشود که یک حساب هر دو اختیار را همزمان داشته باشد.
مرحله ۱: فرایندهای حساس را مشخص کنید
از فهرست داراییها شروع نکنید؛ از فرایندها شروع کنید. فرایندهایی را پیدا کنید که در آنها خطا یا سوءاستفاده میتواند اثر مالی، امنیتی یا عملیاتی جدی داشته باشد.
- ایجاد و حذف حسابهای ممتاز؛
- اعطای نقش مدیریتی؛
- تغییر Firewall، Switch و Router؛
- انتشار Patch روی سرورهای حیاتی؛
- تغییر Policyهای Active Directory؛
- Backup، Restore و حذف نسخههای پشتیبان؛
- تغییرات Production و Emergency Change؛
- مدیریت Log و شواهد ممیزی.
مرحله ۲: فعالیتهای متعارض را پیدا کنید
برای هر فرایند، زنجیره فعالیت را روی کاغذ بنویسید: درخواست، بررسی، تأیید، اجرا، ثبت شواهد و بازبینی. سپس مشخص کنید کدام دو فعالیت نباید بدون کنترل جبرانی در اختیار یک نفر باشد.
قاعده ساده این است: کسی که یک اقدام حساس را اجرا میکند، نباید تنها مرجع تأیید صحت همان اقدام باشد.
مرحله ۳: ماتریس SoD بسازید
| نقش | درخواست | تأیید | اجرا | ممیزی |
|---|---|---|---|---|
| مالک سرویس | بله | در موارد تعریفشده | خیر | مشاهده |
| مدیر تغییر | خیر | بله | خیر | مشاهده |
| ادمین فنی | خیر | خیر | بله | خیر |
| ممیز | خیر | خیر | خیر | بله |
این جدول نمونه است و باید با اندازه سازمان، حساسیت سرویس و تعداد نیروی واقعی تطبیق داده شود.
مرحله ۴: تعارض دسترسی را در ابزارها پیاده کنید
SoD فقط یک سند حاکمیتی نیست. باید در سامانههای عملیاتی نیز دیده شود. برای دسترسی ممتاز میتوان Approval و Session Audit را در PAM360 به کار گرفت. برای فرایند تغییر، Workflow و Approval در ServiceDesk Plus میتواند جدایی میان درخواستکننده، تأییدکننده و مجری را عملی کند.
در حوزه هویت نیز پلتفرمهایی مانند AD360 برای مدیریت نقشها، ممیزی و Governance مفیدند؛ اما ابزار جای طراحی درست نقشها را نمیگیرد.
مرحله ۵: برای سازمان کوچک کنترل جبرانی تعریف کنید
در یک تیم کوچک ممکن است جداسازی کامل نقشها ممکن نباشد. در این حالت باید کنترل جبرانی تعریف شود؛ برای مثال Approval دومرحلهای، ضبط Session، ارسال Log به سامانه مستقل، بازبینی هفتگی تغییرات یا الزام Ticket معتبر قبل از اجرای دسترسی ممتاز.
مرحله ۶: حساب اضطراری را استثنا نکنید
Break-glass Account باید وجود داشته باشد، اما نباید به حساب دائمی برای دور زدن SoD تبدیل شود. استفاده از آن باید محدود، ثبتشده و پس از استفاده بازبینی شود.
رابطه SoD با COBIT و حاکمیت
تفکیک وظایف یک کنترل فنی صرف نیست؛ بخشی از پاسخگویی سازمانی است. در طراحی حاکمیت فناوری اطلاعات، مسئول تصمیم، مسئول اجرا و مسئول نظارت باید قابل تفکیک باشند. برای مطالعه ساختار گستردهتر حاکمیت فناوری اطلاعات، صفحه COBIT در مدانت را ببینید.
شاخصهای کنترل
- تعداد حسابهایی که همزمان دو نقش متعارض دارند؛
- تعداد تغییرات بدون Approval مستقل؛
- تعداد استفاده از حساب Break-glass؛
- درصد عملیات ممتاز دارای Session Audit؛
- تعداد استثناهای SoD که تاریخ انقضا ندارند.
نکات کلیدی
- SoD و Least Privilege مکمل هماند.
- تعارض باید در سطح فرایند شناسایی شود، نه فقط عنوان شغلی.
- اجرای کنترل باید در Workflow و Access Control ابزارها دیده شود.
- برای تیم کوچک میتوان کنترل جبرانی طراحی کرد.
- استثناهای SoD باید مالک، دلیل و تاریخ بازبینی داشته باشند.
سخن پایانی
تفکیک وظایف یعنی هیچ فرد یا حسابی نتواند یک فرایند حساس را از ابتدا تا انتها بدون نظارت مستقل کنترل کند. این اصل وقتی مؤثر است که از سیاست سازمانی به Role، Approval، Log و بازبینی دورهای تبدیل شود.
مدانت در طراحی کنترلهای دسترسی، Governance، PAM، ITSM و نگاشت کنترلهای امنیتی به فرایندهای عملیاتی سازمان خدمات مشاوره و پیادهسازی ارائه میدهد.
منابع
- NIST؛ کنترل AC-5 Separation of Duties
- NIST Cybersecurity Framework؛ Least Privilege و Separation of Duties
