mcpField
C
cloud-app-security-posture

cloud-app-security-posture

github.com/vinayaklattheセキュリティ17887 回インストール19 週間前に更新
リポジトリ

cloud-app-security-posture について

CSPMとSSPMを組み合わせ、クラウドインフラとSaaSの構成を評価し、継続的に強化するクラウドセキュリティチーム向けのスキルです。露出度と影響に基づく修復の優先順位付けを重視します。

主な機能

  1. 01CSPMによるクラウドインフラ評価
  2. 02SaaSアプリのSSPM推奨事項の確認
  3. 03露出度と影響に基づく修正の優先順位付け
  4. 04修復担当者と期限の割り当て
  5. 05Azure Policyによる構成の再発防止
  6. 06ポスチャードリフトの継続監視

活用シーン

  1. 01Azure、AWS、GCPの構成確認
  2. 02Microsoft 365やSalesforceのSaaS設定確認
  3. 03攻撃経路に基づくクラウドリスクの優先対応
  4. 04繰り返す構成問題へのポリシー適用

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill cloud-app-security-posture

インストール後、Claude Code で/cloud-app-security-postureを入力して読み込まれたか確認します。

詳細

クラウドとアプリのセキュリティ態勢

セキュリティ態勢の管理は、相互に補完する 2 つのレイヤーにまたがります。Microsoft Defender for Cloud を利用したクラウドインフラストラクチャ(IaaS/PaaS)向けの CSPM と、Microsoft Defender for Cloud Apps を利用した SaaS アプリケーション向けの SSPM です。両者を組み合わせることで、クラウドと SaaS 環境全体にわたる設定ミスのリスクを継続的に低減できます。

使用する場面

クラウドインフラストラクチャと SaaS アプリケーションの両方について、設定態勢を評価し、継続的に強化します。特に、修復が滞っている場合や、「次に何を修正すべきか」に答えられない場合に有効です。

このスキルは次の場合には使用しないでください:

  • IaaS/PaaS ワークロードの脅威保護プラン(defender-for-cloud-hardening を使用してください)
  • SaaS の脅威検出やシャドー IT の検出のみ(defender-for-cloud-apps を使用してください)
  • AI 向け DSPM(purview-dspm-ai を使用してください)

適切な態勢の視点を選ぶ

強化する対象...使用するもの確認場所
Azure サブスクリプション、AWS アカウント、GCP プロジェクトDefender for Cloud CSPMDefender for Cloud → 推奨事項
インターネットに公開された VM/有害な組み合わせがあるデータDefender CSPM(有料)+ attack-pathDefender for Cloud → 攻撃経路分析
Microsoft 365、Salesforce、ServiceNow、GitHub の設定Defender for Cloud Apps SSPMDefender XDR → クラウドアプリ → 態勢
コンテナー/Kubernetes の態勢Defender CSPM コンテナプランDefender for Cloud → クラウドセキュリティグラフ
コード/IaC の設定ミスDefender for Cloud の DevOps セキュリティDefender for Cloud → DevOps
クラウドの ID 衛生上の不備ID の推奨事項(CIEM)Defender for Cloud + Entra Permissions Mgmt

目安: 基本の CSPM は Defender for Cloud プランに含まれており、Secure Score と MCSB の推奨事項を利用できます。有料の Defender CSPM プランでは、攻撃経路分析、クラウドセキュリティグラフ、エージェントレススキャン、DevOps が追加されます。件数ではなく悪用可能性に基づいて優先順位を付ける必要がある環境では、有効にしてください。

アプローチ

  1. すべての環境で基盤となる CSPM を有効にする - すべての Azure サブスクリプションで Defender for Cloud を有効にし、AWS アカウントと GCP プロジェクトを接続して、Microsoft Cloud Security Benchmark(MCSB) の推奨事項と Secure Score が反映されていることを確認します。 確認方法:Defender for Cloud → Inventory にすべてのサブスクリプション/アカウントが表示され、各スコープの Secure Score が 0 より大きいこと。
  2. 重要度の高いスコープで Defender CSPM(有料)を有効にする - インターネットに公開されているワークロードや機密データを含むサブスクリプション/アカウントで有料プランを有効にし、攻撃経路分析とクラウドセキュリティグラフを利用できるようにします。基盤となる CSPM で分かるのは何が誤設定されているかですが、Defender CSPM では、どの誤設定が悪用可能な連鎖を形成しているかが分かります。 確認方法:攻撃経路分析のページに少なくとも 1 つの経路が表示され、インターネットから機密データまでの経路をたどれること。
  3. Defender for Cloud Apps で SSPM を有効にする - API コネクタを使って、各 SaaS アプリ(Microsoft 365、Salesforce、ServiceNow、GitHub、Okta など)を接続します。SSPM の推奨事項では、アプリごとに管理者コントロール、MFA 設定、共有による露出、非アクティブな特権ユーザーが対象になります。 確認方法:Defender XDR → Cloud apps → Posture に、検出結果だけでなく、接続したアプリごとの推奨事項が表示されること。
  4. 露出度と影響度に基づいて優先順位を付ける - インターネットへの露出、機密データ、特権 ID、攻撃経路の重要度に基づいて、修復の優先順位を決めます。クラウドセキュリティグラフを使って、同じ経路を断つ推奨事項をまとめます。 確認方法:修復対象の上位 10 件が推奨事項の件数順ではなく、リスクを加味した影響度順になっていること。
  5. 担当者と SLA を割り当てる - 担当者のいない推奨事項は修正されません。ワークロード(サブスクリプションのタグ、リソースグループ、SaaS アプリの所有者)ごとにチケット管理システムへ振り分け、重大度に応じた修復 SLA を設定します。 確認方法:ワークロード担当者ごとのチケット件数を確認でき、経過時間レポートに重大度ごとのクローズまでの中央値が表示されること。
  6. 安全な範囲で適用を徹底し、自動化する - Azure Policy を使って修正済みの構成への再発を防止します(暗号化されていない新しいリソースを拒否する、タグ付きスコープでパブリック IP の作成をブロックするなど)。Defender for Cloud のワークフロー自動化を使って、取り消し可能な自動修復について推奨事項を Logic Apps に振り分けます。 確認方法:以前よく見られた誤設定を拒否する Azure Policy が少なくとも 1 つあり、自動修復のログに 1 種類の推奨事項に対する修正成功が記録されていること。
  7. 構成のずれを継続的に監視する - 環境の変化(新しいサブスクリプション、新しい SaaS アプリ、新しいアカウント)に応じて基準を再設定します。セキュリティ態勢の管理は一度限りのプロジェクトではなく、運用モデルです。 確認方法:90 日間の Secure Score の推移が乱高下せず、横ばいまたは改善していること。

ガードレール

  • セキュリティ態勢の管理は予防的な対策です。脅威検出(Defender for Cloud のワークロードプラン、Defender for Cloud Apps の脅威ポリシー)と組み合わせてください。検出を伴わないセキュリティ態勢管理では進行中の攻撃を見逃し、セキュリティ態勢管理を伴わない検出では同じ穴が繰り返し悪用されます。
  • スコア自体を追い求めないでください - まず、悪用可能で影響の大きい問題を修正します。Secure Score が 95% でも、最重要データへの攻撃経路が開いていれば、経路のない 70% のスコアよりも悪い状態です。
  • アプリ/ワークロードの担当者と修復を調整し、障害を避けてください。パートナーが依存しているストレージアカウントのパブリックアクセスを無効にすると、修正ではなく停止につながります。
  • 無料の CSPM は最低限であり、上限ではありません。 基盤となる CSPM には攻撃経路やグラフの機能がありません。リスクの高いスコープでは、有料の Defender CSPM プランを適切な基準として使用してください。
  • SaaS アプリを接続するたびに、ガバナンス対応が必要になります - 存在するコネクタをすべて使うのではなく、実際に管理しているアプリを接続してください。
  • セキュリティ態勢の検出結果はコードとして扱ってください - デプロイ済みのリソースだけでなく、元となるテンプレート(Bicep、Terraform、IaC)を修正し、次のデプロイ後も修正が維持されるようにします。

よくあるアンチパターン

  • 「すべてを有効にして、アナリストにノイズのトリアージを任せる。」 スコープ、担当者、優先順位がなければ、セキュリティ態勢は1万件のバックログとなり、何も進まなくなります。
  • 攻撃経路を無視して、Secure Scoreの数値を追いかけること。悪用可能な経路があるなら、スコアがきれいでも、スコアが悪くても悪用可能な経路がない場合より深刻です。
  • SSPMをチェックボックスとして扱うこと――SaaSアプリを接続しても、推奨事項を一度も確認しません。価値があるのは、定期的に見直すことです。
  • Azure Policyによる保護策がないこと。 次のデプロイで同じ設定ミスが再発するのを防ぐ仕組みがないため、修正した推奨事項も元に戻ってしまいます。
  • SSPMとCSPMを別々の領域として扱うこと。 多くの攻撃チェーンは両者の境界を越えます(侵害されたSaaS管理者 → クラウドワークロード)。リスクの高いユーザーについては、両方の観点から併せて確認してください。

プロンプトの例

  • Microsoft 365 SaaS の設定を強化し、セキュリティ態勢に関する推奨事項を確認してください。
  • SSPM を使って、Salesforce または ServiceNow の設定ミスを見つけてください。
  • 複数のクラウドアプリ全体で SaaS のセキュリティ態勢を改善するにはどうすればよいですか?
  • 攻撃経路分析を使って、CSPM の修正項目に優先順位を付けてください。
  • クラウドをまたぐセキュリティ態勢の問題のうち、上位10件を確認して修正してください。

Microsoft Learn

コメント