You Inherited a Cloud Mess. Where Do You Start?

誰かが3年かけて文書化なし、出入りする契約業者、2022年以降アクティブになっていない #aws-help という Slack チャンネルで構築したクラウドアカウント（またはそれ以上）を引き継いだばかりです。これはクラウドセキュリティ業務で最も一般的な状況の1つであり、まだ説明できないものに責任を持つことになるため、不快感があります。

ここでは、ゼロから可視性を持ち、防御可能な状態に到達する方法を説明します。

推測をやめて、まずインベントリを取得する

見えないものをセキュリティで保護することはできません。IAM ポリシーに1つも手を付ける前に、インベントリパスを実行してください。

• AWS: aws organizations list-accounts でアカウント構造全体を確認し、その後 Steampipe または AWS Config アグリゲーターを使用してアカウント全体のリソースを1つのクエリ可能ビューに取り込みます。
• Azure: Azure のテナント/サブスクリプションモデルは展開を簡単に隠すため、サブスクリプション全体で Resource Graph クエリ（az graph query）を実行してください。
• GCP: 組織レベルで gcloud asset search-all-resources を実行してください。

これを課金データと相互参照してください。課金は、タグとドキュメントがどうであれ、実行中の内容について嘘をつきません。オンボーディング中に誰も言及していないサービスの支出が見える場合、それが最初の発見です。

壊れているものを見つける前に、何ができるかを見つける

設定ミスがヘッドラインになりますが、継承された環境では通常、実際の露出はアイデンティティにあります。すべての IAM ユーザー、ロール、およびサービスアカウントを取得し、3つの質問をしてください。これは依然として存在する必要があるか、使用していないアクセス権があるか、そして人間なのかマシンなのか。

AWS IAM Access Analyzer または iam-lint スタイルのツールを実行して、過去90日間の未使用のアクセス許可にフラグを付けてください。実際には、継承されたアカウントにはほぼ常に、想定されていた長寿命アクセスキーを持つ IAM ユーザーが少なくとも1人います。