‏SCPها در برابر Permission Boundaryها: کدام برای AWS مناسب‌تره؟

در اکثر محیط‌های AWS سازمانی، تعداد هویت‌های غیرانسانی — مثل Lambda roleها، CI/CD pipelineها و AI agentها — از هویت‌های انسانی بیشتره. این هویت‌ها معمولاً با دسترسی‌های گسترده ساخته میشن و کسی بعداً بهشون نگاه نمی‌کنه. ابزارهای کنترل دسترسی هم برای همه‌ی این موارد طراحی نشدن.

Permission Boundary یه قابلیت IAM هست که سقف حداکثر دسترسی یه user یا role رو مشخص می‌کنه. اگه policy به S3 و CloudWatch دسترسی بده ولی Boundary فقط S3 رو شامل بشه، دسترسی CloudWatch لغو میشه. مشکل اینجاست که Boundaryها باید به‌صورت جداگانه روی هر entity اعمال بشن و هر role بدون Boundary یه شکاف امنیتیه. در محیط‌هایی با هزاران نقش، این روش عملی نیست.

Service Control Policy (به‌اختصار SCP) یه سیاست سازمانی‌ه که سقف دسترسی رو برای تمام اکانت‌ها، واحدهای سازمانی (OU)، یا کل سازمان AWS تعیین می‌کنه. برخلاف Boundary، SCP نیازی به پیکربندی جداگانه نداره — روی همه‌ی IAM principalهای در scope اعمال میشه؛ چه انسانی، چه غیرانسانی، چه امروز ساخته شده باشن، چه فردا. نکته‌ی مهم: SCP روی اکانت management AWS اعمال نمیشه.

پس چرا اکثر تیم‌ها از SCPها برای اعمال least privilege (حداقل دسترسی لازم) استفاده نمی‌کنن؟ مشکل نوشتن SCP نیست — مشکل اینه که نمی‌دونن کدوم دسترسی‌ها واقعاً استفاده میشن. یه deny-list SCP اشتباه می‌تونه سرویس‌های پروداکشن رو از کار بندازه. از طرفی SCP خیلی permissive هم ریسک اصلی رو حل نمی‌کنه. نتیجه اینه که اکثر سازمان‌ها استقرار SCP رو به تعویق می‌ندازن.

راه‌حل پیشنهادی Sonrai اینه که با تحلیل استفاده‌ی واقعی از دسترسی‌ها، مشخص کنه کدوم permissionها فعالن و کدوم‌ها خاموشن. بعد SCPها رو بر اساس این داده‌ها و با استفاده از native cloud controls استقرار میده — بدون نیاز به تنظیم دستی هر role. هر دسترسی خارج از این baseline از طریق یه فرایند درخواست-تأیید (JIT) در ChatOps در دسترس قرار می‌گیره و بلافاصله بازیابی میشه.

این رویکرد نتیجه‌ی ملموسی هم برای تیم‌های امنیتی و compliance داره: یه سقف دسترسی مستند برای هر هویت، قابل ارائه به ممیزهای SOC 2، ISO 27001، PCI DSS و HIPAA. به جای اینکه بعد از ممیزی شواهد جمع کنی، خود مدل اجرایی شواهده.

نکات کلیدی:

• Permission Boundaryها برای سناریوهای delegation خاص مناسبن، نه اجرای org-wide
• SCPها در سطح سازمان کار می‌کنن و همه‌ی IAM principalها رو پوشش میدن
• اکانت management AWS از SCPها مستثناست
• بزرگ‌ترین مانع استقرار SCP، نداشتن دید به دسترسی‌های فعال در پروداکشنه
• ترکیب SCP و Permission Boundary در بسیاری از محیط‌ها توصیه میشه — هر کدوم برای کار خودشون