تو یک بلای ابری را به ارث برداشتی. از کجا شروع کنی؟

تازه کنترل یک حساب ابری (یا ده تا) را به دست گرفتی که شخص دیگری طی سه سال با هیچ مستندات، گروهی در حال چرخش از پیمانکاران، و یک کانال Slack به نام #aws-help که از سال ۲۰۲۲ فعال نیست، ساخت است. این یکی از شایع‌ترین موقعیت‌ها در کار امنیت ابری است، و ناراحت‌کننده است زیرا تو مسئول چیزی هستی که هنوز نمی‌توانی آن را توضیح دهی.

اینجا نحوه رفتن از صفر دید تا موضع دفاعی است بدون اینکه همه چیز را غرق کنی.

قدس و یک فهرست بگیر

نمی‌توانی چیزی را ایمن کنی که نمی‌توانی ببینی. قبل از اینکه یک سیاست IAM را لمس کنی، یک پروند فهرست‌سازی اجرا کن:

• AWS: aws organizations list-accounts برای دیدن ساختار حساب کامل، سپس Steampipe یا aggregatorهای AWS Config برای کشش منابع در حساب‌ها به یک دید قابل پرسش‌دهی.
• Azure: پرسش‌های Resource Graph (az graph query) در سراسر اشتراک‌ها، چون مدل tenant/subscription Azure پخش را به آسانی پنهان می‌کند.
• GCP: gcloud asset search-all-resources در سطح سازمان.

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

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

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

AWS IAM Access Analyzer یا iam-lint-سبک ابزار را اجرا کن تا مجوزهای استفاده نشده در ۹۰ روز گذشته را نشانه‌گذاری کنی. در عمل، حساب‌های به ارث رفته تقریباً همیشه حداقل یک کاربر IAM با کلیدهای دسترسی دراز‌مدتی دارند که فرض بر این بود که