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

 

اصل حداقل دسترسی (Least Privilege) چیست؟

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

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

  • نرم‌افزارهای سیستمی نصب کند،
  • تنظیمات امنیتی سیستم را تغییر دهد،
  • به سرورهای دیگر متصل شود،
  • عضویت کاربران در گروه‌ها را تغییر دهد،
  • یا به پوشه‌های حساس واحدهای دیگر دسترسی داشته باشد،

سطح دسترسی او بیشتر از نیاز واقعی شغلی‌اش است.

در چنین شرایطی، مشکل فقط «دسترسی زیاد» نیست؛ بلکه دامنه خسارت احتمالی در صورت سرقت Credential یا سوءاستفاده از حساب نیز افزایش پیدا می‌کند.

 

چرا دسترسی بیش از نیاز یک ریسک امنیتی است؟

فرض کنید مهاجم Credential یک کاربر عادی را به دست آورده است.

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

اما اگر همان حساب به چندین سرور، Share، برنامه، پایگاه داده یا سرویس مدیریتی دسترسی داشته باشد، سرقت یک Credential می‌تواند نقطه شروع یک زنجیره حمله بزرگ‌تر باشد.

بنابراین Least Privilege یک دیوار غیرقابل نفوذ ایجاد نمی‌کند؛ بلکه با محدود کردن دسترسی‌های یک هویت، دامنه عملیاتی مهاجم و در نتیجه Blast Radius یک حساب به خطر افتاده را کاهش می‌دهد. هدف این نیست که فرض کنیم یک حساب هیچ‌وقت به خطر نمی‌افتد؛ هدف این است که compromise یک حساب به معنی دسترسی مهاجم به بخش بزرگی از سازمان نباشد.

 

Least Privilege فقط برای کاربران نیست

یکی از اشتباهات رایج این است که Least Privilege را فقط برای حساب‌های کاربری در نظر بگیریم.

در یک محیط سازمانی، هویت‌های مختلفی وجود دارند:

  • کاربران عادی
  • مدیران سیستم
  • حساب‌های Service Account
  • Applicationها
  • APIها
  • حساب‌های Cloud
  • حساب‌های SaaS
  • فرایندها و سرویس‌های سیستم‌عامل
  • حساب‌های مربوط به تجهیزات شبکه

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

 

Service Accountها؛ یکی از نقاط حساس Least Privilege

Service Accountها معمولاً برای اجرای سرویس‌ها، برنامه‌ها و Jobهای خودکار استفاده می‌شوند و ممکن است سال‌ها بدون تغییر باقی بمانند.

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

برای مثال، سرویسی فقط باید بتواند:

Read → Database A

را انجام دهد؛ اما حساب آن به‌جای این دسترسی محدود، امکان:

Read + Write + Modify → چندین Database

را داشته باشد.

بنابراین برای Service Accountها باید مشخص باشد:

این حساب دقیقاً چه سرویسی را اجرا می‌کند؟ به کدام منابع نیاز دارد؟ چه عملیاتی باید انجام دهد؟ و چه دسترسی‌هایی هیچ توجیه کاری ندارند؟

 

اصل حداقل دسترسی در اکتیو دایرکتوری (Active Directory)

در محیط‌های مبتنی بر Active Directory، اجرای این اصل اهمیت بیشتری پیدا می‌کند؛ چون یک Permission یا عضویت اشتباه در Group می‌تواند دامنه دسترسی کاربر را به شکل قابل‌توجهی افزایش دهد.

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

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

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

 

تفاوت اصل حداقل دسترسی با PAM چیست؟

Least Privilege یک اصل امنیتی است:

هر هویت فقط باید حداقل دسترسی لازم را داشته باشد.

اما PAM یا Privileged Access Management مجموعه‌ای از فرایندها و کنترل‌ها برای مدیریت دسترسی‌های حساس و Privileged است.

برای مثال، PAM می‌تواند برای موارد زیر استفاده شود:

  • مدیریت حساب‌های Administrator
  • نگهداری امن Credentialهای حساس
  • کنترل زمان دسترسی
  • ثبت فعالیت Administrator
  • Rotation کردن Credentialها
  • اعطای دسترسی موقت
  • کنترل و تأیید دسترسی‌های حساس

بنابراین:

سیاست حداقل دسترسی مشخص می‌کند چه مقدار دسترسی باید وجود داشته باشد؛ PAM به مدیریت و کنترل بسیاری از دسترسی‌های Privileged کمک می‌کند.

 

RBAC چه نقشی در اجرای اصل حداقل دسترسی دارد؟

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

RBAC یا Role-Based Access Control می‌تواند این مشکل را کاهش دهد.

در RBAC به‌جای اینکه مستقیماً برای هر کاربر مجموعه‌ای از مجوزها تعریف شود، ابتدا Roleهای مشخص ایجاد می‌شوند.

مثلاً:

کارشناس مالی → دسترسی‌های موردنیاز واحد مالی

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

مدیر منابع انسانی → دسترسی‌های موردنیاز سیستم منابع انسانی

سپس کاربران بر اساس نقش خود عضو Role مناسب می‌شوند.

نکته:

RBAC به‌تنهایی اصل حداقل دسترسی را تضمین نمی‌کند.

اگر Role مربوط به «کارشناس مالی» از ابتدا Permissionهای اضافی داشته باشد، تمام کاربران عضو آن Role نیز همان دسترسی‌های اضافی را دریافت خواهند کرد.

پس باید خود Roleها نیز به‌صورت دوره‌ای بررسی شوند.

 

آیا اصل حداقل دسترسی یعنی دسترسی کاربران را تا حد ممکن کم کنیم؟

خیر. هدف اصل حداقل دسترسی این نیست که دسترسی کاربران را تا حد ممکن کاهش دهیم؛ بلکه باید دسترسی‌های غیرضروری حذف شوند، بدون اینکه Permission موردنیاز برای انجام وظیفه از بین برود.

بنابراین معیار مناسب این نیست که «آیا می‌توانیم این دسترسی را حذف کنیم؟» بلکه باید پرسید: «آیا نیاز تجاری یا فنی مشخصی برای این دسترسی وجود دارد؟»

 

دسترسی دائمی همیشه بهترین انتخاب نیست

یکی از پیشرفت‌های مهم در مدیریت دسترسی، فاصله گرفتن از Permanent Privilege است.

فرض کنید مدیر شبکه فقط برای ۳۰ دقیقه باید یک تغییر حساس روی یک سرور انجام دهد.

در مدل سنتی ممکن است حساب او همیشه Administrator باشد.

اما در مدل‌های جدیدتر می‌توان دسترسی Privileged را فقط زمانی که لازم است فعال کرد.

این رویکرد با مفاهیمی مانند:

  • Just-in-Time Access
  • Just Enough Administration
  • Privileged Access Management

پیاده‌سازی می‌شود.

 

اشتباهات رایج در پیاده‌سازی اصل حداقل دسترسی (Least Privilege)

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

۱. دسترسی Administrator برای حل سریع مشکل

گاهی یک نرم‌افزار یا کاربر با Permission محدود با خطا مواجه می‌شود و ساده‌ترین راه، Administrator کردن کاربر است.

این راه‌حل موقت ممکن است به یک ریسک دائمی تبدیل شود.

۲. ساخت Roleهای بیش از حد گسترده

اگر یک Role برای راحتی چندین Permission اضافی داشته باشد، تمام کاربران آن Role از دسترسی‌های غیرضروری برخوردار می‌شوند.

۳. فراموش کردن Service Accountها

گاهی Permission کاربران بررسی می‌شود، اما حساب‌های سرویس سال‌ها بدون بازبینی باقی می‌مانند.

۴. حذف نکردن دسترسی بعد از تغییر شغل

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

۵. استفاده از حساب Privileged برای کارهای روزمره

استفاده از Domain Admin یا حساب مدیریتی برای Web Browsing، Email و فعالیت‌های روزمره، سطح ریسک Credential آن حساب را بالا می‌برد.

۶. اجرای یکسان Least Privilege برای همه سیستم‌ها

Permission موردنیاز یک کاربر در یک Application ممکن است با Permission موردنیاز همان کاربر در یک Database یا Network Device متفاوت باشد.

بنابراین باید Context و وظیفه واقعی هر دسترسی بررسی شود.

 

چگونه سیاست حداقل دسترسی را در سازمان پیاده‌سازی کنیم؟

اجرای این اصل بهتر است مرحله‌ای باشد.

1. فهرست کردن هویت‌ها و دسترسی‌ها

ابتدا باید مشخص شود چه کسانی و چه چیزهایی به سیستم‌ها دسترسی دارند:

  • کاربران
  • Administratorها
  • Service Accountها
  • Applicationها
  • APIها
  • حساب‌های Cloud
  • حساب‌های SaaS
  • حساب‌های مربوط به تجهیزات شبکه

بدون داشتن این دید، نمی‌توان Permissionهای اضافی را شناسایی کرد.

 

2. مشخص کردن نیاز واقعی هر نقش

برای هر Role مشخص کنید:

این فرد یا سرویس دقیقاً چه کاری باید انجام دهد؟

بعد Permissionهای موردنیاز برای همان کار تعریف شوند.

 

3. حذف دسترسی‌های غیرضروری

مجوزهایی که Business Justification مشخصی ندارند باید بررسی و در صورت امکان حذف شوند.

 

4. جدا کردن دسترسی عادی از Privileged

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

 

5. استفاده از دسترسی موقت برای عملیات حساس

در مواردی که دسترسی Privileged فقط برای مدت کوتاهی لازم است، استفاده از JIT یا مدل‌های مشابه می‌تواند بهتر از Permanent Privilege باشد.

 

6. بازبینی دوره‌ای

نقش افراد، پروژه‌ها، سیستم‌ها و نیازهای کسب‌وکار تغییر می‌کنند؛ بنابراین Permissionها نیز باید مرتباً بازبینی شوند.

 

از کجا بفهمیم سازمان واقعاً Least Privilege را رعایت نمی‌کند؟

چند نشانه می‌تواند زنگ خطر باشد:

  • تعداد زیادی از کاربران Local Administrator هستند.
  • Service Accountها Permissionهای گسترده و بدون توجیه مشخص دارند.
  • حساب‌های قدیمی یا بلااستفاده هنوز فعال‌اند.
  • دسترسی کاربران پس از تغییر سمت یا نقش بازبینی نمی‌شود.
  • برای Permissionهای حساس مالک مشخصی وجود ندارد.
  • دسترسی‌های موقت بدون زمان انقضا به‌صورت دائمی باقی می‌مانند.
  • Permissionهای SaaS و Cloud بدون بازبینی باقی می‌مانند.

وجود حتی چند مورد از این نشانه‌ها به این معنی نیست که سازمان حتماً دچار یک رخداد امنیتی شده است؛ اما نشان می‌دهد سطح حمله ناشی از دسترسی‌های غیرضروری می‌تواند بیشتر از حد موردنیاز باشد.

 

اصل حداقل دسترسی را در چه بخش‌هایی باید اجرا کرد؟

این اصل نباید فقط در Active Directory یا سیستم‌عامل اجرا شود.

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

حوزه

نمونه دسترسی قابل کنترل

کاربران

 File Share، Application، VPN
Active Directory

Group Membership، Admin Role

سرورها

 Local Admin، RDP، SSH
شبکه

دسترسی به تجهیزات و Commandها

Database

 Read، Write، Modify
SaaS و Cloud

Role و Resource Access

API و Service Account

 Scope، Token و دسترسی سرویس
Container/Kubernetes

Role و Namespace Access

 

Least Privilege در کنار Zero Trust چه نقشی دارد؟

اصل کمترین سطح دسترسی یکی از پایه‌های مهم مدل‌های Zero Trust است.

Zero Trust فرض نمی‌کند که صرفاً به دلیل قرار داشتن کاربر در شبکه سازمان، باید دسترسی گسترده‌ای داشته باشد؛ بلکه دسترسی را بر اساس هویت، نقش، منبع، شرایط و نیاز واقعی کنترل می‌کند. بنابراین داشتن یک حساب معتبر به معنی داشتن دسترسی نامحدود نیست.

به همین دلیل، Least Privilege می‌تواند در کنار کنترل‌های Identity، MFA، Device Trust، Segmentation و Continuous Monitoring قرار بگیرد تا سطح دسترسی هر هویت محدود و قابل کنترل باقی بماند.

 

آیا Least Privilege جلوی حمله را می‌گیرد؟

خیر. Least Privilege مانع سرقت Credential یا وقوع حمله نمی‌شود؛ هدف آن کاهش سطح دسترسی و محدود کردن دامنه اثر یک حساب یا فرایند به خطر افتاده است.

برای همین، Least Privilege باید در کنار کنترل‌هایی مانند:

استفاده شود.

هدف، ساختن یک لایه امنیتی واحد نیست؛ بلکه ایجاد چند کنترل مستقل است تا compromise یک حساب به معنی compromise کل محیط نباشد.

 

چک ‌لیست Least Privilege برای تیم IT

قبل از اینکه بگوییم Least Privilege در سازمان اجرا شده است، این موارد را بررسی کنید:

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