در محیط‌های ابری AWS، سوءاستفاده از کلیدهای دسترسی (Access Keys) کاربران IAM همچنان یکی از رایج‌ترین بردارهای حمله اولیه است. این کلیدها معمولاً از طریق انتشار تصادفی در مخازن عمومی کد (مانند GitHub) یا فایل‌های متغیرهای محیطی (Environment Variables) لو می‌روند. برای مقابله با این تهدید، AWS مکانیزمی را از طریق یک سیاست مدیریتی به نام AWSCompromisedKeyQuarantine پیاده‌سازی کرده است.
عملکرد سیاست AWSCompromisedKeyQuarantine
زمانی که AWS متوجه لو رفتن کلیدهای دسترسی یک کاربر در محیط‌های عمومی شود، به‌طور خودکار سیاست AWSCompromisedKeyQuarantine را به آن کاربر IAM متصل می‌کند. این سیاست بر اساس اصل Explicit Deny عمل می‌کند؛ به این معنا که هرگونه دسترسی منع شده در این سیاست، حتی اگر در سیاست‌های دیگر کاربر اجازه (Allow) داده شده باشد، لغو می‌شود.
هدف از این رویکرد، محدود کردن آسیب‌های احتمالی (مانند ایجاد هزینه‌های غیرمجاز یا تخریب منابع) بدون متوقف کردن کامل عملیات‌های تجاری ضروری است. این سیاست در سه نسخه (V1, V2, V3) تکامل یافته و هر نسخه بر اساس متدهای جدید مهاجمان به‌روزرسانی شده است:
- نسخه V1: تمرکز بر محدود کردن ۲۸ اکشن در ۵ سرویس کلیدی برای جلوگیری از حملاتی مانند Cryptomining.
- نسخه V2: گسترش محدودیت‌ها به ۶۱ دسترسی در ۱۷ سرویس، از جمله S3 برای جلوگیری از حذف داده‌ها پس از سرقت (Exfiltration).
- نسخه V3: به‌روزرسانی‌های تکمیلی برای مقابله با تهدیدات جدیدتر، از جمله محدود کردن دسترسی‌های سرویس Amazon Bedrock جهت جلوگیری از فراخوانی‌های غیرمجاز API.
یکپارچگی با GitHub Secret Scanning
AWS با برنامه Secret Scanning گیت‌هاب همکاری می‌کند. گیت‌هاب مخازن عمومی و بسته‌های npm را برای شناسایی توالی‌های حساس اسکن کرده و در صورت یافتن کلیدهای AWS، از طریق یک Endpoint اطلاع‌رسانی می‌کند. در تست‌های واقعی مشاهده شده است که AWS تنها در عرض ۱۰ ثانیه پس از انتشار کلید در GitHub، سیاست قرنطینه را اعمال کرده و تیکت‌های پشتیبانی مربوطه را ایجاد می‌کند.
استراتژی‌های مانیتورینگ برای تیم‌های SOC
مدیران امنیت و مهندسان SOC می‌توانند برای شناسایی سریع این وقایع، موارد زیر را در لاگ‌های CloudTrail رصد کنند:
- Sourcing Event: رصد رویداد
AttachUserPolicyبا منبعIAM. در بخشPolicyArn، نام سیاست قرنطینه قابل مشاهده است. - GitHub Validity Checks: گیت‌هاب برای تایید فعال بودن کلید، درخواست
GetCallerIdentityرا از طریق STS ارسال می‌کند. این درخواست‌ها دارای User-Agentهای خاصی هستند (مانندGHAS-AWS_KEYID-validation) که با رصد آن‌ها می‌توان پیش از سوءاستفاده مهاجم، از لو رفتن کلید مطلع شد.
