ایمن‌سازی محیط ابری که شما آن را ساخته‌اید نیستید

اگر شما به‌تازگی کلیدهای یک حساب ابری را دریافت کرده‌اید که برای سه سال بدون نظارت رشد کرده است. هیچ کس مستندات را به جا نگذاشته. IAM دارای 40 نقش با مجوزهای wildcard است، S3 bucket‌هایی وجود دارند که هیچ کس به یاد نمی‌آورد که آن‌ها را ایجاد کرده است، و آخرین شخصی که توپولوژی شبکه را درک می‌کرد در سال 2022 شرکت را ترک کرد. این بیش‌تر از آنچه اکثر آگهی‌های شغلی قبول می‌کنند شایع است، و اولین ماه تن و توانی را برای همه چیزهایی که بعد می‌آید تعیین می‌کند.

قبل از اینکه چیزی را لمس کنید، موجودی داشته باشید

به آرزوی شروع فوری قفل‌کردن مقاومت کنید. ابتدا نقشه‌ای نیاز دارید. aws resourcegroupstaggingapi get-resources را در هر منطقه، نه تنها us-east-1 اجرا کنید — تیم‌ها دوست دارند منابع تست را در ap-southeast-2 راه‌اندازی کنند و آن‌ها را فراموش کنند. آن را با AWS Config جفت کنید اگر قبلاً فعال است، یا اکنون آن را روشن کنید اگر نیست. در Azure، az resource list --output table به یک صفحه‌گسترده برای اولین بار خوب است. در GCP، Cloud Asset Inventory gcloud asset search-all-resources همین نما را می‌دهد.

در مقابل صورت‌حساب متقابل بررسی کنید. هر چیزی که هزینه درمی‌آورد باید در موجودی منابع شما ظاهر شود؛ هر چیزی در موجودی با فعالیت اخیر صفر، نامزد بایگانی است. اختلافات اینجا معمولاً جایی است که چیزهای ترسناک پنهان می‌شوند — نمونه‌های EC2 یتیم با IP‌های عمومی، اسنپ‌شات‌های RDS فراموش‌شده بدون رمزگذاری، تعادل‌دهنده‌های بار که به هیچ چیز اشاره نمی‌کنند.

IAM را مانند یک صحنه جنایت حسابرسی کنید

هر سیاست IAM را بکشید و به دنبال "Action": "*" در ترکیب با "Resource": "*" باشید. این ترکیب نباید خارج از تعداد کمی از نقش‌های مدیر break-glass وجود داشته باشد، و حتی آن‌ها باید اجرای MFA و هشدار CloudTrail را الحاق کنند. از IAM Access Analyzer استفاده کنید تا نقش‌هایی را بیابید که به حساب‌های خارجی دسترسی دهند — این هم رابطه‌های اعتماد cross-account عمدی و هم اشتباه‌های کسی را که ماژول Terraform را در مقابل شناسه حساب غلط آزمایش می‌کند می‌گیرد.

کلیدهای دسترسی قدیم‌تر از 90 روز را با aws iam generate-credential-report بررسی کنید. اموال ارثی تقریباً همیشه کلیدهای عمر طولانی داشته‌اند که به حساب‌های خدمات الحاق شده‌اند، گاهی اوقات در متغیر محیط Lambda یا کار Jenkins کدبندی شده است. آن‌ها را بچرخانید، اما آن را مرحله‌ای کنید — کشتن کلیدی که یک شغل دسته‌ای شبانه به آن بستگی دارد ساعت 2 بامداد، این طریق شما را در طول اولین هفته صدا زده می‌شود.

قبل از اینکه مهاجم انجام دهد، نمایش عمومی را بیابید

بررسی قابلیت دسترسی شبکه را در VPC‌های خود اجرا کنید. گروه‌های امنیتی با 0.0.0.0/0 در هر چیزی غیر از 80/443 نیاز به توجیه دارند، نه فرض. ابزارهایی مانند ScoutSuite یا Prowler در دقایق یک حساب را میل می‌کنند و تقریری را که بر اساس شدت رتبه‌بندی شده است بیرون می‌دهند — به جای ساخت چک‌لیست خود از ابتدا شروع کنید.

S3 bucket‌ها شایستگی توجه ویژه دارند زیرا آن‌ها معدن زمین اموال ارثی کلاسیک هستند. هم سیاست bucket و هم تنظیمات Block Public Access سطح حساب را بررسی کنید؛ کسی ممکن است پیش‌فرض حساب را سال‌ها برای یک سایت ایستا یکبار غیرفعال کرده باشد و هرگز آن را روشن نکرده است. aws s3api list-buckets در ترکیب با حلقه‌ای بررسی get-bucket-acl و get-bucket-policy-status بر روی هر کدام تصویر تمیز را در کمتر از ده دقیقه برای اکثر حساب‌ها می‌دهد.

قبل از اینکه اعتماد را ایجاد کنید، ثبت‌کردن را ایجاد کنید

اگر CloudTrail، VPC Flow Logs، یا GuardDuty قبلاً در همه جا اجرا نمی‌شوند، آن‌ها را اکنون روشن کنید، قبل از اینکه هر تغییر دیگری انجام دهید. شما از این نقطه به جلو سابقه‌ای از آنچه اتفاق می‌افتد می‌خواهید، و شما می‌خواهید آن را قبل از شروع حذف چیزها، زیرا حذف دقیقاً زمانی است که اشتباه انجام می‌شود و بر عهده شخص جدید گذاشته می‌شود. اگر ممکن است، log‌ها را برای یک حساب یا subscription جداگانه بفرستید، بنابراین بار کار مخروب نمی‌تواند شواهد خود را نیز پاک کند.

GuardDuty یا Azure Defender for Cloud را با هشدار مسیریابی جایی تنظیم کنید که انسان واقعاً بررسی کند — نه کانال Slack با 400 پیام خوانده‌نشده. ارزش ابزار تشخیص نزدیک به صفر است اگر هشدارها در خلاء فرود بیایند.

مشکلات بلندتر را ابتدا برطرف کنید، همه چیز را مستند کنید

شما یک اموال ارثی را در یک sprint برطرف نمی‌کنید. بر اساس شعاع انفجار طبقه‌بندی کنید: اول نمایش داده‌های عمومی، سپس هویت‌های بیش‌تر امتیاز، سپس تقسیم‌بندی شبکه، سپس همه چیز دیگر. آنچه را پیدا کرده‌اید و تغییر دادید یادداشت کنید، حتی در یک Google Doc ساده، زیرا شخص بعدی که این را از شما به ارث می‌برد بهتر از آنچه شما دریافت کرده‌اید سزاوار است.

انتظار مقاومت را داشته باشید هنگامی که گروه امنیتی را سخت‌گیرانه کنید و تست یکپارچه‌سازی dev شروع به شکست می‌کند. این عادی است — این بدان معنی است که حسابرسی کار می‌کند. قبل از اینکه هر چیزی را در production برگردانید با تیمی صحبت کنید که بار کار را مالک هستند، و نقشه‌ای برای بازگشت برای دو هفته اول آماده داشته باشید.

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