azure-security-benchmark

Microsoft Cloud Security Benchmark（MCSB）

Microsoft Cloud Security Benchmark（MCSB、Azure Security Benchmark の後継）は、Microsoft が定める、規範的なクラウドセキュリティのベストプラクティスです。CIS、NIST SP 800-53、PCI DSS、ISO 27001 に対応するコントロールが割り当てられており、Microsoft Defender for Cloud でネイティブに監視されます。MCSB は Defender for Cloud の既定のイニシアチブです。すでに MCSB に基づいてスコアが評価されています。

使用する場面

ユーザーが広く認知され、フレームワークに対応したクラウドセキュリティのベースラインを求めている場合、コンプライアンス要件を具体的な Azure コントロールに落とし込む必要がある場合、または Defender for Cloud の推奨事項にどこから取り組むべきかを優先順位付けしようとしている場合に、このスキルを使用します。

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

• Defender for Cloud の戦術的な修復作業（defender-for-cloud-hardening を使用）
• Azure Policy の作成方法の詳細（azure-policy を使用）
• ワークロード固有の脅威モデリング（threat-modelling を使用）

最初に適切な MCSB コントロールドメインを選択する

MCSB には 12 のコントロールドメインがあります。並行してすべてに取り組むのではなく、リスクと依存関係に基づいて選択してください。

優先度	ドメイン	この順序である理由	最初に行う一般的なアクション
P0	ID 管理と特権アクセス	ID が新たな境界です。管理者アカウントが侵害されれば、ゲームオーバーです	MFA を強制し、PIM を使って常時割り当てられているグローバル管理者を削除する
P0	ログ記録と脅威検出	可視性がなければ対応できません	サブスクリプションで診断設定と Sentinel／Defender を有効にする
P1	ネットワークセキュリティ	ID が侵害された場合の影響範囲を縮小します	既定で拒否する NSG、PaaS 用のプライベートエンドポイント
P1	データ保護	暗号化、キー管理、分類	最重要データにカスタマー管理キーを使用し、秘密度ラベルを適用する
P1	資産管理	可視化できないものは保護できません	タグポリシーとリソースインベントリ
P2	セキュリティ態勢と脆弱性の管理	継続的な改善サイクル	Defender for Servers にオンボードし、週次で Secure Score を確認する
P2	エンドポイントセキュリティとバックアップおよび復旧	レジリエンスのベースライン	Defender for Endpoint と、イミュータブルなコンテナーを使用した Azure Backup
P2	インシデント対応	プロセスの成熟度	Defender XDR／Sentinel を使用したランブックと机上演習
P3	DevOps セキュリティ	開発の早い段階でのコントロール	GitHub Advanced Security、または Defender for DevOps を備えた Azure DevOps
P3	ガバナンスと戦略	ほかのドメインを持続させます	Azure Policy と管理グループ構造

経験則： 成熟したテナントでは、MCSB Secure Score の**65～75％**が現実的な実務上の目標です。85％超の場合、通常はワークロードに該当しない推奨事項を監査していることを意味します。100％を目指す前に、適用可能かどうかを確認してください。

アプローチ

1. MCSB が有効なベースラインであることを確認する — Defender for Cloud → Regulatory compliance で、MCSB は既定で有効になっていますが、テナントで無効にされている場合があります。見つからない場合は再度有効にしてください。 確認方法：Regulatory compliance ダッシュボードで、「Microsoft cloud security benchmark」が現在の合格率／不合格率とともに有効な標準として表示されていることを確認します。
2. Secure Score のベースラインを設定する — サブスクリプションごと、およびコントロールドメインごとの現在のスコアを記録します。これが改善の目標となる数値です。ベースラインがなければ、経営陣に進捗を示すことはできません。 確認方法：修復を開始する前に、サブスクリプションごとの Secure Score をスクリーンショットに撮るか、エクスポートします。
3. MCSB を準拠義務のあるフレームワークに対応付ける — CIS、NIST、ISO、PCI を個別の作業として扱わないでください。MCSB を標準的な実装として使い、各フレームワークとのマッピングでコンプライアンスを証明します。これにより、4 回の監査分の作業を 1 回に減らせます。 確認方法：Regulatory compliance ダッシュボードに、準拠義務のあるフレームワークが MCSB とともに表示され、重複が確認できることを確認します。
4. 上記の優先度表に従ってトリアージする — まず、すべてのサブスクリプションで P0 ドメインに取り組みます。各ドメイン内では、推奨事項をSecure Score への影響度（降順）、次に影響を受けるリソース数（降順）で並べ替えます。多くのチームでは、各ドメインの上位 5 件が四半期分の作業になります。
5. 実装の詳細にはサービスのベースラインを使う — MCSB のコントロールは抽象的です（「転送中の暗号化を有効にする」など）。サービスごとのセキュリティベースラインは、具体的な Azure 構成に落とし込みます（例：App Service では、TLS 1.2 を最低バージョンに設定し、HTTPS のみを有効にします）。修正を設計する前に、必ずサービスのベースラインを確認してください。 確認方法：デプロイ済みのリソースが、Defender for Cloud のサービスベースラインチェックに合格することを確認します。
6. Azure Policy で適用する — 推奨事項だけでは、後退を防げません。修復した各コントロールを、まず 2 週間 Audit モードのポリシーに昇格させ、その後 Deny または DeployIfNotExists に切り替えます。これにより、次のデプロイでスコアが低下するのを防げます。 確認方法：ポリシーに違反するテストデプロイがブロックされる（Deny）、または自動修復される（DeployIfNotExists）ことを確認します。
7. プログラムを統制する — MCSB の各コントロールドメインにドメインオーナーを割り当てます。セキュリティ評議会で毎月 Secure Score を確認します。コンプライアンス監査が近づいたら、四半期ごとにフレームワークとのマッピングを調整します。

ガードレール

• MCSB はベースラインであり、ワークロードの脅威モデルではありません。 Secure Score が 100％でも、アプリケーションが安全だとは限りません。プラットフォーム構成が既定の要件を満たしていることを意味するだけです。ワークロード固有のリスクについては、threat-modelling と組み合わせてください。
• Secure Score は指標であり、絶対的な基準ではありません。 一部の推奨事項は、すべてのワークロードに該当するわけではありません（例：「Microsoft Defender for SQL を有効にする」は、SQL を使用していないテナントには関係ありません）。無視するのではなく、「Not applicable」のワークフローを使ってください。
• 推奨事項はコストに影響します。 Defender プラン、Customer-Managed Keys、不変バックアップ保管庫を有効にすると、Azure の実費が増加します。一括で有効にする前に、コストを見積もってください。
• 本番環境では Quick Fix に頼らないでください。 Defender for Cloud の自動修復 Quick Fix は開発／テスト環境には適していますが、本番環境では、まず基盤となる Bicep／ARM の変更を確認してください。
• 先にマッピングし、その後で修復します。 フレームワークとのマッピング作業をせずに修復スプリントに着手すると、次に監査担当者が来たときに作業が重複します。
• サービスのベースラインはプラットフォームの更新に追いつかないことがあります。 ベースラインを有力な既定値として扱いつつ、より新しいガイダンスがないか、サービス独自の「Security best practices」ドキュメントも確認してください。

よくあるアンチパターン

• 「セキュアスコア100％を目指す。」 約75～85％を超えると効果が逓減し、該当しない推奨事項の監査でチームが疲弊します。
• 「MCSBとCISを別々のプロジェクトとして扱う。」 作業が二重になります。MCSBは実装レイヤーであり、CISは多数ある出力マッピングの一つです。
• 「予算を立てずにすべてのDefenderプランを有効にする。」 翌月に請求額を見て驚き、慌てて無効にすることになり、その結果、スコアとプログラムの信頼性が損なわれます。
• 「ポリシーを設定せずに推奨事項に対応する。」 今日修正しても、明日の新しいデプロイで元に戻ります。修正を維持するにはポリシーが必要です。
• 「該当なしを無視する。」 正式に除外すべき推奨事項によってスコアが下がり、本当のギャップが見えにくくなります。

プロンプトの例

• Azure のコントロールを Microsoft Cloud Security Benchmark（MCSB）にマッピングしてください。
• MCSB は CIS および NIST のコントロールとどのように整合していますか？
• Defender for Cloud の規制コンプライアンスダッシュボードを MCSB に照らして使用してください。
• 最初に優先すべき MCSB のコントロールドメインはどれですか？
• テナントの現実的なセキュアスコアの目標はどのくらいですか？
• Azure Policy を使用して MCSB のコントロールを適用してください。

Microsoft Learn

• MCSB の概要：https://learn.microsoft.com/security/benchmark/azure/overview
• はじめにとコントロール：https://learn.microsoft.com/security/benchmark/azure/introduction
• サービスのセキュリティベースライン：https://learn.microsoft.com/security/benchmark/azure/security-baselines-overview
• 規制コンプライアンスダッシュボード：https://learn.microsoft.com/azure/defender-for-cloud/regulatory-compliance-dashboard
• Defender for Cloud のセキュアスコア：https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls
• クイック修正による修復：https://learn.microsoft.com/azure/defender-for-cloud/implement-security-recommendations