مدیریت دسترسی
کاربران

تفاوت احراز هویت و کنترل دسترسی

احراز هویت پاسخ می‌دهد «این فرد کیست؟»؛ کنترل دسترسی مشخص می‌کند «این فرد مجاز به انجام چه کاری است؟». ورود موفق نباید به معنی اختیار مشاهده یا تغییر همهٔ اطلاعات باشد. در یک نرم‌افزار، کاربر ممکن است درخواست خودش را ببیند، اما مجوز مشاهدهٔ درخواست دیگران را نداشته باشد.

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

پیش‌نیاز؛ فهرست منابع و مالک اطلاعات

ابتدا بدانید چه منابعی دارید و چه کسی صلاحیت تأیید دسترسی به آن‌ها را دارد. مسئول فنی می‌تواند مجوز را اجرا کند، اما تصمیم دربارهٔ محتوای مالی، پرسنلی یا پروژه معمولاً به مالک همان اطلاعات نیاز دارد. مسئول تأیید و مسئول اجرا را در مستند پروژه روشن کنید.

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

طراحی نقش‌ها و گروه‌های دسترسی

در مدل نقش‌محور یا RBAC، مجوزها به نقش کاری وابسته‌اند؛ کاربر از طریق نقش خود آن‌ها را دریافت می‌کند. نقش «کارشناس فروش» لزوماً نباید با نقش «مدیر فروش» یکسان باشد. پروژه‌های مشترک نیز ممکن است گروه مستقلی با محدوده و پایان مشخص نیاز داشته باشند.

در شبکهٔ دارای Active Directory، گروه‌های امنیتی برای مدیریت مجوز منابع کاربرد دارند. تخصیص گروهی، پیگیری و تغییر عضویت را ساده‌تر از مجوزهای پراکندهٔ فردی می‌کند. گروه توزیع ایمیل را با گروه امنیتی مجوزدهی یکسان نگیرید.

نام هر گروه باید هدف آن را نشان دهد؛ مثلاً Finance-Reports-Read یک نام نمونه برای خواندن گزارش‌های مالی است، نه دستور قابل اجرای آماده. برای گروه، مالک، منبع، عملیات مجاز و قواعد عضویت ثبت کنید. عضویت در گروه‌های دیگر هم باید بررسی شود تا مجوز غیرمستقیم از قلم نیفتد.

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

سطح دسترسی پوشه‌ها و فایل‌سرور

در فایل‌سرور ویندوزی، مجوزهای فایل و پوشه و تنظیمات اشتراک باید هماهنگ بررسی شوند. دسترسی مستقیم روی سرور و دسترسی از مسیر شبکه را یکسان فرض نکنید. وراثت پوشه‌ها و عضویت‌های گروهی می‌توانند نتیجهٔ واقعی را با تصور اولیه متفاوت کنند.

• Read: برای خواندن اطلاعات، بدون نیاز به ویرایش.
• Modify: برای کار روی فایل‌ها؛ معمولاً حذف را هم ممکن می‌کند.
• Full Control: اختیار گسترده‌تر، از جمله تغییر مجوزها؛ برای هر کاربر عادی لازم نیست.

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

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

چرخهٔ ورود، تغییر سمت و خروج کارکنان

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

1. شروع همکاری: ایجاد هویت مشخص، تأیید نقش و تحویل دسترسی موردنیاز.
2. تغییر سمت: بررسی مجوزهای قبلی و جدید؛ استثناها فقط با دلیل و مدت مشخص.
3. دسترسی موقت: تعیین منبع، مسئول تأیید و زمان پایان پروژه یا نیاز.
4. پایان همکاری: لغو دسترسی در سرویس‌های مرتبط و ثبت نتیجهٔ بررسی.

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

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

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

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

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

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

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

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

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

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

بازبینی دسترسی و ثبت رخدادها

برای هر منبع، مالک باید بتواند فهرست افراد دارای دسترسی را بررسی و تأیید کند. دسترسی‌های بدون مالک، حساب‌های بلااستفاده و استثناهای بدون تاریخ پایان، نشانهٔ نیاز به بازبینی‌اند. تغییر سمت و پایان پروژه هم نباید تا بازبینی دوره‌ای بعدی منتظر بماند.

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

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

اشتباه‌های رایج در تعیین سطح دسترسی

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

مراحل اجرا و چک‌لیست تحویل

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

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

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

هزینه اجرای مدیریت دسترسی کاربران

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

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

مدیریت دسترسی سازمانی با ویوان نت

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