構築していないクラウド環境をセキュアにする

3年間放置されてきたクラウドアカウントの鍵を突然渡されました。ドキュメントは何も残されていません。IAMには40のロールがあり、ワイルドカードのアクセス許可が付与されています。誰が作成したか覚えていないS3バケットがあります。ネットワークトポロジーを理解していた最後の人物は2022年に会社を去りました。これはほとんどの求人広告が認める以上に一般的であり、最初の1ヶ月がその後すべての基調を決めます。

何も触る前にインベントリを取得する

即座にロックダウンを開始したい衝動を抑えてください。まず地図が必要です。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が同じビューを提供します。

請求と照合してください。お金がかかっているものはすべてリソースインベントリに表示される必要があります。インベントリ内で最近のアクティビティがゼロのものはアーカイブの候補です。ここでの矛盾は通常、怖いものが隠れている場所です。パブリックIPを持つ孤立したEC2インスタンス、暗号化されていない忘れられたRDSスナップショット、何も指さしていないロードバランサー。

IAMを犯罪現場のように監査する

すべてのIAMポリシーを取得し、"Action": "*"と"Resource": "*"の組み合わせを探してください。この組み合わせはほんの一握りの緊急時管理者ロール以外に存在してはいけません。そしてそれらにはMFA適用とCloudTrailアラートが付与されている必要があります。IAM Access Analyzerを使用して、外部アカウントへのアクセスを許可するロールを見つけてください。これにより、意図的なクロスアカウント信頼関係と、誤ったアカウントIDに対してTerraformモジュールをテストしていた人の誤りの両方が検出されます。

aws iam generate-credential-reportで90日以上前のアクセスキーを確認してください。継承された環境にはサービスアカウントに付与された長期間有効なキーがほぼ常にあり、Lambda環境変数やJenkinsジョブにハードコードされていることもあります。それらをローテーションしてください。ただしステージングしてください。夜間バッチジョブが依存しているキーを午前2時に削除すると、最初の週にポケベルが鳴ります。

攻撃者より先に公開露出を見つける

VPC全体でネットワーク到達可能性チェックを実行してください。80/443以外で0.0.0.0/0を持つセキュリティグループは、仮定ではなく正当化が必要です。ScoutSuiteやProwlerなどのツールは数分でアカウントを処理し、重大度でランク付けされたレポートを出力します。ゼロから独自のチェックリストを構築する代わりに、そこから始めてください。

S3バケットは、継承された環境の典型的な地雷であるため、特別な注意が必要です。バケットポリシーとアカウントレベルのBlock Public Access設定の両方を確認してください。誰かが数年前にワンオフの静的サイトのためにアカウントのデフォルトを無効にしてそのままにしたかもしれません。aws s3api list-bucketsを各バケットのget-bucket-aclとget-bucket-policy-statusをチェックするループと組み合わせると、ほとんどのアカウントで10分以下で明確な画像が得られます。

信頼を確立する前にロギングを確立する

CloudTrail、VPC Flow Logs、またはGuardDutyがまだ至る所で実行されていない場合は、他の変更を加える前に今すぐ有効にしてください。このポイント以降に何が起こるかの記録が必要です。削除を開始する前にそれが必要です。削除は正確にミスが発生して新しい人のせいにされるときだからです。可能な限り別のアカウントまたはサブスクリプションにログを送信してください。侵害されたワークロードがその証拠を消去することもできないようにするためです。

GuardDutyまたはAzure Defender for Cloudをセットアップし、アラートをを実際に人間がチェックしている場所にルーティングしてください。400の未読メッセージがあるSlackチャネルではなく。検出ツールの価値は、アラートが無効な場所に着地する場合、ゼロに近いです。

最も目立つ問題を最初に修正し、すべてを文書化する

継承された環境をスプリントで修正することはできません。影響範囲でトリアージしてください。公開データ露出が最初、次に過度な権限を持つアイデンティティ、次にネットワークセグメンテーション、最後にそれ以外のすべて。見つけたものと変更したものを書き留めてください。プレーンなGoogle Docでもいいです。あなたから次にこれを継承する人は、あなたが受け取ったものより良いものに値するからです。

セキュリティグループを厳しくしたときに開発者の統合テストが失敗し始めたときは、反発を予期してください。これは正常です。監査が機能していることを意味します。本番環境で何かをフリップする前にワークロードを所有するチームと話し合い、最初の2週間はロールバック計画を準備しておいてください。

クラウド監査の背後にあるツールと推論についての詳細は、Korra Studioのセグメント(IAM強化とクラウド検出エンジニアリング)を確認してください。どちらも上記のワークフローとよく組み合わさります。