Principle of Least Privilege، توضیح شده

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

معنای واقعی آن

اصل کمترین امتیاز (PoLP) می‌گوید هر موضوع در یک سیستم — یک کاربر، یک حساب سرویس، یک برنامه، یک container — باید با حداقل مجموعه‌ای از مجوزهایی که برای تکمیل عملکردش لازم است عمل کند. نه مجوزهایی که راحت هستند. نه مجوزهایی که کسی سه سال پیش اعطا کرد و فراموش کرد که آن را لغو کند. حداقل.

این در هر لایه اعمال می‌شود: مجوزهای سیستم فایل، نقش‌های پایگاه‌داده، دامنه‌های API، خط‌مشی‌های IAM ابری، قوانین firewall، دسترسی sudo. یک فرآیند وب‌سرور که فایل‌های ایستا را می‌خواند نیازی به دسترسی نوشتن به /etc ندارد. یک اسکریپت گزارش‌گری که فقط کوئری‌های SELECT اجرا می‌کند نیازی به نقش پایگاه‌داده با حقوق DROP TABLE ندارد. یک کارآموز بخش بازاریابی نیازی به دسترسی مدیر دامنه ندارد فقط به‌این‌دلیل که برای فناوری اطلاعات آسان‌تر بود.

چرا اهمیت بیشتری دارد نسبت به آنچه به نظر می‌رسد

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

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

جایی که در عمل ظاهر می‌شود

IAM ابری. AWS، Azure و GCP اگر احتیاط نکنید به رفتار مجاز‌کننده پیش‌فرض تنظیم می‌شوند — یک خط‌مشی IAM با "Action": "*" و "Resource": "*" از تایید می‌گذرد و خوب کار می‌کند، تا زمانی‌که یک کلید دسترسی نشتی کنترل کامل حساب را به مهاجم نمی‌دهد. خط‌مشی‌ها را به اقدامات خاص و ARN منابع محدود کنید نه به استفاده از wildcard.

حساب‌های سرویس. اینها اغلب بدترین متخلفین هستند زیرا کسی آن‌ها را بر اساس روشی که حساب‌های انسانی را بررسی می‌کنند بررسی نمی‌کند. یک خط‌لوله CI/CD که به یک bucket S3 استقرار می‌یابد نباید اعتبار‌نامه‌ای را نگه‌دارد که می‌تواند هر bucket را در حساب بخواند.

نقش‌های پایگاه‌داده. نقش‌های گزارش‌گری فقط‌خواندنی را از نقش‌های برنامه‌ای که به INSERT/UPDATE نیاز دارند جدا کنید، و آن‌ها را از نقش DBA که می‌تواند schema را تغییر دهد جدا کنید. PostgreSQL و MySQL هر دو از دستورات GRANT دانه‌ریز پشتیبانی می‌کنند — از آن‌ها استفاده کنید به‌جای اعطای هر اتصال برنامه معادل root.

Sudo و مدیر محلی. افزایش just-in-time (درخواست دسترسی، آن را برای یک پنجره محدود دریافت کنید، آن را به‌طور خودکار از دست بدهید) همیشه بهتر از حقوق مدیر ایستا است. ابزارهایی مانند sudo با قوانین محدود زمانی، یا راه‌حل‌های PAM در محیط‌های سازمانی، دقیقاً برای این موجود هستند.

تنش با