hardening-cloud-posture

クラウドのセキュリティ態勢を強化する

CSPM スキャンでは、1,000 件もの検出結果が返されます。そのほとんどは侵入経路ではありません。 作業の目的は、1,000 件すべての検出結果を解消することではなく、攻撃経路を構成する少数の項目を見つけて対処し、再発を防ぐガードレールを設定することです。 すべての検出結果を同等に扱うセキュリティ態勢の改善では、本当に重要な問題が埋もれてしまいます。

基本原則は、アイデンティティが境界であるということです。クラウドでは、攻撃経路はネットワークのホップではなく、ほとんどの場合 IAM 権限の連鎖です。スキャナーの重大度ラベルではなく、「この権限でプリンシパルは何にアクセスできるのか？」を基準に優先順位を付けます。

使用する場面

• AWS／Azure／GCP のアカウントまたは組織のセキュリティ態勢を確認する
• Prowler、ScoutSuite、Security Hub、Defender for Cloud のレポートをトリアージする
• 多数の設定ミスのうち、実際に重要なものを判断する
• 予防的なガードレール（SCP、Azure Policy、組織ポリシー）を設定する
• 調査で後に必要となるログ記録と制御を有効にする

使用しない場面

• 進行中のインシデントを調査する場合 — investigating-aws-incidents、 investigating-azure-incidents、または investigating-gcp-incidents を使用します
• 経路を実証するために環境を攻撃する場合 — exploiting-cloud-platforms を 使用します
• Kubernetes クラスターの制御プレーンを強化する場合 — defending-kubernetes を使用します
• クラウド設定ではなく、ワークロード内の CVE に優先順位を付ける場合 — managing-vulnerabilities を 使用します

検出件数ではなく攻撃経路で優先順位を付ける

スキャナーに表示された順ではなく、攻撃者が悪用する順に検出結果へ対処します。

1. データまたはコンピューティングリソースのパブリックな公開。 パブリックな S3／GCS バケットやストレージ アカウント、インターネットから到達可能なデータベース、0.0.0.0/0 に開放された管理ポートなどです。 認証情報は不要で、認証前にアクセスできます。最初に対処します。
2. 過剰な権限を持つアイデンティティ。 ワイルドカードの Action／Resource ポリシー、条件なしで * または外部アカウントから引き受け可能なロール、 特権ロールに対する iam:PassRole を持つユーザー、Owner 権限を持つサービスプリンシパルなどです。ここで、 足がかりがアカウント乗っ取りにつながります。
3. 監査ログの欠落または無効化。 CloudTrail がマルチリージョンでない、GCP Data Access ログが無効、Azure の診断設定がない、といった状態です。これ自体が侵害を引き起こすわけではありませんが、調査を妨げます。これから発生するインシデントを後から記録することはできないため、今すぐ有効にします。
4. データの暗号化がなく、鍵管理もされていない。 重要な問題ですが、侵入経路となることはまれです。コンプライアンス上の要件で優先順位が変わる場合を除き、上記への対処後に修正します。

顧客データを含むパブリックバケットは、スキャナー上で同じ重大度に評価されていても、「暗号化が有効でない」という検出結果100件より優先されます。

CSPM の出力を批判的に読む

Prowler、ScoutSuite、Security Hub、Defender for Cloud は標準的なツールで、役に立ちます。ただし、その出力は出発点であって、最終判断ではありません。

• 重大度は汎用的です。 ツールは環境を把握していません。アカウント間で引き受け可能なロールに対する「中」が最も危険な検出結果かもしれませんし、内部専用リソースに対する「高」がノイズかもしれません。
• 検出結果には影響範囲が含まれません。 ツールはポリシーに * があることを報告しますが、そのロールがインターネットに公開された関数に付与されているとは教えてくれません。到達可能性は自分で確認します。
• 抑制によって実際のリスクが隠れることがあります。 数か月前に「リスクを受け入れた」という理由で抑制された検出結果が、今も許容できるとは限りません。未解決の検出結果と同じように、抑制リストも慎重に確認します。
• 緑色でも問題がないとは限りません。 スキャナーは、確認対象としているものだけを確認します。Data Access ログが無効なままスキャンに合格しても、大きな盲点が残っており、スキャナーはそれを検出結果として報告しません。

コンプライアンスの枠組みが役立つ場合は、上位の検出結果を CIS Benchmark の管理策に対応付けます。ただし、ベンチマークに優先順位を決めさせないでください。ベンチマークは包括的ですが、修正に使える予算には限りがあります。

検出結果よりガードレールを優先

修正した設定ミスも、次に誰かがリソースをプロビジョニングすると再発します。ガードレールを設ければ、設定ミスの種類全体を防止できます。

• AWS： Service Control Policies を使って、組織全体でパブリックな S3 を拒否し、CloudTrail の無効化を拒否し、リージョンを制限します。アカウントレベルで s3:BlockPublicAccess を設定します。
• Azure： Azure Policy で、パブリックネットワークアクセス、必須の暗号化、必須の診断設定に対して deny 効果を適用します。
• GCP： 組織ポリシーの制約（storage.publicAccessPrevention、iam.disableServiceAccountKeyCreation、compute.requireOsLogin）を適用します。

リソースごとの修正より、組織レベルの deny を優先してください。個別の修正で解消できるのは検出結果ひとつですが、ガードレールを設ければ、その種類全体と今後発生するすべての事例を防止できます。

退けるべき言い訳

• 「重大度の高い検出結果はすべて解消しました。」 重大度は、スキャナーが汎用的な環境を想定して推測したものです。重要なのは、どのようなラベルが付いているかではなく、攻撃経路上にある検出結果です。
• 「スキャン結果がすべて問題なしなので、アカウントは安全です。」 スキャンで確認できるのは、設定されたチェック項目だけです。ロギングの無効化、ツールが低リスクと評価した過剰に広いロール、抑制された検出結果は、いずれも問題なしという結果には現れません。
• 「保存時の暗号化が最も大きな課題です。」 それが侵入経路になることはほとんどありません。コンプライアンス要件で優先順位が定められている場合を除き、パブリックバケットや、別のアカウントから引き受け可能な管理者ロールのほうが優先されます。
• 「パブリックバケットは修正しました。」 修正したのは、そのバケットひとつです。組織レベルのガードレールがなければ、来週には別のチームが同じようにバケットを公開します。設定ミスの種類全体を修正してください。
• 「その検出結果はリスクとして受容されました。」 誰が、いつ受容したのでしょうか。また、今もその判断は妥当でしょうか。古いリスク受容の記録に、実際の露出が隠れていることがあります。
• 「IAM は複雑すぎて、完全に監査できません。」 それなら、何も監査しないのではなく、まず権限昇格の基本要素である PassRole、ワイルドカードを含む信頼ポリシー、クロスアカウントのロール引き受けを監査してください。アイデンティティは境界であり、監査は必須です。

外部ソースを読む

公開アドバイザリー、仕様、ベンダーレポートを Markdown として取得します。

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

これによりページの定型部分が取り除かれ、文章中心のページではトークン数が約 78％減る一方、要約ではなく全文が返されるため、grep で検索でき、該当箇所がないという結果も信頼できます。

この方法の用途ではないものが3つあります。JSON や API のレスポンスは、可読性の抽出によって構造化データが壊れるため、生のまま取得してください。認証が必要なページや JavaScript で描画されるページは、匿名で取得されるため、直接取得してください。また、攻撃者のインフラ（フィッシングリンク、C2、マルウェアのホスティング）、クライアント所有のホスト、エンゲージメント URL は、決してこの方法で経由させないでください。リクエストが自分のマシンから第三者に送信され、稼働中の攻撃者インフラの場合は、運用者に気付かれることにもなります。

サイトによっては抽出ツールをブロックし、ページではなくエラーの内容を返す場合があります。たとえば、freedesktop.org から返される {"error":"Failed to fetch: 418 I'm a teapot"} です。これは取得が拒否されたことを示すものであり、ソースがその内容の存在を否定しているわけではありません。その結果から結論を出す前に、URL を直接再取得してください。

参考資料

• exploiting-cloud-platforms — このセキュリティ態勢の改善によって防ぐ攻撃経路
• investigating-aws-incidents / investigating-azure-incidents / investigating-gcp-incidents — ここで有効化する監査ログの送信先
• defending-kubernetes — アカウントでマネージド Kubernetes を実行している場合のクラスター層
• managing-vulnerabilities — 設定のセキュリティ態勢に対応する、ワークロードの CVE 対策