【Azure導入 × NIST/GDPR対応｜スポット技術支援・完全版前編】
- 山崎行政書士事務所
- 1 日前
- 読了時間: 40分
— 山崎行政書士事務所：E5前提／規格準拠と現場運用の両立 —
目次（全体構成案）
戦略と前提（経営・法務・運用の交差点）
NIST CSF 2.0／GDPRの“運用化”マッピング
要件定義：ゴールから逆算する設計（法務→技術→メトリクス）
ゼロトラスト設計原則 in Azure（ID・デバイス・ネットワーク・データ・アプリ）
Entra ID P2 詳細設計（CA／PIM／Risk／CAE／認証強度）
Defender for Identity（MDI）パラメータ設計（NNR・イベント・タグ・欺瞞）
Defender for Endpoint（MDE P2）実装（ASR／EDR Block／AIR／Tamper／Intune）
Defender for Office 365（MDO P2）実装（Safe Links/Attachments／Anti‑phish）
Sentinel＋Defender XDR統合（KQL／SOAR／重複抑制）
GDPR実装（ROPA／DPIA／Art.33／越境移転／証跡）
ログ保持・監査設計（期間／改ざん耐性／検索性）
IR体制とSLA（Runbook／机上演習／ウォーゲーム）
KPIダッシュボード（運用KPI／結果KPI／ガバナンスKPI）
E3→E5差分と移行戦略（代替・段階移行・費用効果）
スポット支援メニュー（導入前／移行時／監査前／事後是正）
戦略と前提（経営・法務・運用の交差点）—「要件→設計→証跡」を一本線に通す
クラウド・セキュリティは、単独の部門が単独の善で成立する領域ではありません。経営は事業の存続と成長、取引先からの信頼、限られた予算や人員の制約をにらみ、法務はGDPRや国内法、業界ガイドラインに適合するためのルールと手続を求め、運用（情シス／SOC）は毎日の検知、封じ込め、復旧、そして改善の歯車を回し続けます。どれか一層が強くても、三層の整合が欠ければ、「規格に適合しているのに現場が回らない」「運用は必死に頑張っているのに監査の席で説明に窮する」といったトラブルに行き着きます。山崎行政書士事務所のスポット支援は、この三層を**“要件→設計→証跡”の一本道で結び切ることに集中します。私たちがこだわるのは、正しいことより回ること**、回ることより証明できることです。
1. 経営の目的を、設計の“測定可能な条件”に翻訳する
経営が本当に求めているのは、最新の流行用語や高価なセキュリティ製品ではありません。狙いはいつもシンプルで、①事業継続（止めない／止まっても戻す）、②対外信頼（お客様・監督当局・株主に説明できる）、③コスト／人員の制約下での最適化、の三点です。ここから私たちは測定可能な設計条件を作ります。たとえば「止めない」を「重大インシデント（P1）は検知→封じ込めを15分以内」「初報は2時間以内」「復旧は72時間以内」といったSLAにまで落とし込む。「説明できる」を「72時間以内のGDPR報告パッケージが自動生成され、法務レビューを経て提出可能」という運用フローにまで砕く。「制約下での最適化」を「運用KPIを月次レビューし、効果の薄い統制は除外・簡素化の候補リストへ」という継続改善の仕組みに変換する。経営語をエンジニア語に、エンジニア語を監査語に翻訳する役割を、スポットで一気に担います。
2. 法規制の要求を、設計図の“構造材”へ
GDPRや国内法は、条文としては抽象的で、読み込むほど「で、それをどう設定すればいいのか？」という壁にぶつかります。私たちの原則は**“証跡先行設計”です。つまり、規制の各要求に対し「どう守るか」の前に「どう証明するか」を先に決め、その証明の取り回しやすさを軸に技術設計を固めます。たとえばGDPR第33条（72時間報告）。ここでは「体制がある」だけでは足りず、「何が、いつ、どの範囲で、どう影響し、どんな対策が取られたか」を事実として短時間で提示できることが要点です。そこで私たちは、Defender XDR／Sentinelの検知結果から初報ドラフトを自動生成し、影響範囲（データ主体・レコード種別）、暫定封じ込め、再発防止の骨子までテンプレートに組み込みます。条文の文章は解釈の余地があっても、証跡の形式を先に固定しておけば、運用は迷いません。Art.30（処理台帳）なら、データフローとIaC（Infrastructure as Code）のリソースタグを一対一に結び「台帳＝構成の写し」となるよう設計します。Art.32（安全管理）なら、条件付きアクセス／最小権限／暗号／閉域化／検知—対応—復旧フローがひとつの連鎖であることを設計図で示し、同じ連鎖をKPIと監査証跡**で裏づけます。
3. 運用現場が回り続けるための“三つの摩擦”を最初に潰す
毎日アラートをさばくのは情シス／SOCです。設計書は美しくても、ここに摩擦が残れば回りません。典型的な摩擦は三つ。ひとつ目は情報の散在。異なる製品・ポータルにアラートが分散し、時系列も重複も見えない。ここはDefender XDR経由で事象を統合し、Sentinelに相関の“定盤”を置く。アラートは「箱」ではなく「線」で見るのが原則です。二つ目は判断基準の不統一。誰が何分で何を決めるか、曖昧なほど現場は止まります。ここはRunbookを秒単位で書く。たとえば「MDIのハニートークン発火＝P1。自動隔離が成功したらT+5分までに初報ドラフトを生成、T+30分で封じ込め完了をレビュー。T+120分までに法務レビュー済みの初報を提出」まで時間で縛る。三つ目は例外処理の積み残し。業務都合の例外は必ず発生します。例外が悪なのではなく、期限・理由・承認・証跡が無ければ悪になる。だから設計段階で**“例外の生まれ方”を標準化**し、期限切れ例外の自動通知まで含めておきます。
4. 「要件→設計→証跡」を一本線にする作法
私たちがどの案件でも最初にやるのは、要件カタログを作ることです。要件カタログは、経営目的・規制要求・運用制約を1枚のリストにまとめ、各要件に**「設計要素」「運用ルール」「KPI」「証跡の保存先」を必ず紐づけます。ここに“空欄”を残さないのがコツです。次に設計原本（Design Source of Truth）を作る。これは絵としての構成図ではなく、各制御のパラメータまで落ちた「設計の辞書」です。たとえば「サインインリスク=高→ブロック」「中→MFA」「特権ロール→PIM JIT最大4時間、承認者A/B、根拠チケット必須」「EDR in block mode=有効」「ASR 12ルール→既定はBlock、LOB干渉の例外は理由と期限を添付して許可」など。設計が運用の言葉で読めることが重要です。三つ目に証跡の台帳を作る。どの統制の有効性を、どのシステムから、どのクエリで、どれくらいの保持で、誰がレビューするか。“誰が、どの棚から、どの箱を取り出せば、どの監査質問に答えられるか”**を先に地図化します。証跡設計は面倒ですが、いざという時に「探す」時間をゼロにしてくれます。
5. “回せる設計”は、最初からKPIで書く
よくある落とし穴は、「導入が終わったらKPIを考える」という順序です。私たちは最初からKPIで設計します。KPIは三種類に分けます。運用KPI（毎日回るか）—例：未調査アラート24時間以内解消率100%、自動修復成功率85%以上、ハニートークン発火ゼロ。結果KPI（守れたか）—例：既知悪性URLクリック率0.5%以下/月、再感染率、横展開封じ込めまでの平均時間。ガバナンスKPI（説明できるか）—例：72時間報告の初動完了SLA遵守率、例外の期限切れゼロ、ROPAの差分反映期限遵守率。KPIは可視化して初めて力を持つため、ダッシュボードのワイヤー（どのKQLをどこに乗せ、誰がいつレビューするか）まで設計に含めます。数字で設計し、数字で回し、数字で語る。これが“回せるセキュリティ”の体幹です。
6. 例外は「悪」ではない。設計されない例外が悪である
現実の業務に“純粋な最小権限”は存在しません。決算、監査、障害復旧、緊急対応、外部委託など、例外は必ず生まれます。重要なのは、例外が生まれる設計を初めから持つこと。私たちは、例外を期限・理由・承認・証跡で包み、自動的に失効させる仕掛けを提案します。たとえば、PIMでの特権昇格は「最大4時間」「承認者はローテーション」「チケット番号必須」「完了後に操作ログが監査ストアへ」「ロールの恒久付与は原則禁止」など。これにより、例外の負債が時間の経過とともにシステムに溜まっていく事態を防ぎます。例外が悪なのではない。例外のメモリ管理に失敗することが悪なのだ、という考え方です。
7. コミュニケーションの設計：経営・法務・運用の“待ち時間”を無くす
事故の現場で最も時間を奪うのは、技術ではなく連絡の待ち時間です。だからこそ、コミュニケーションも設計の一部に含めます。インシデントRunbookには、技術ステップだけでなく、誰が誰に、どのテンプレートで、どのチャンネルから、何分以内に連絡するかを明記します。初報、続報、クローズ報告、再発防止策の共有までテンプレート化し、法務レビューの“通過点”を工程に組み込む。さらに、経営層向けのエグゼクティブブリーフも定型化します。技術詳細ではなく「被害の現状」「拡大リスク」「社会的影響」「法的義務」「今後72時間のマイルストーン」をA4一枚で表現する訓練を、平時から回します。技術と意思決定の橋を普段から渡しておくと、いざという時の速度は別物になります。
8. 文化の埋め込み：規格準拠を“紙”ではなく“習慣”に
規格準拠は紙の上ではなく習慣の中に定着させるしかありません。だから私たちは、導入の最後に必ず机上演習とウォーゲームを入れます。机上演習では、典型的なシナリオ（ランサム、内部不正、誤送信、クラウド設定ミスなど）をもとに、技術・法務・広報・経営が同じ部屋で動作確認を行う。ウォーゲームでは、実際の運用ポータルを触り、ダッシュボードとRunbookを時間軸で“早回し”します。これにより、「あるはずの連絡先が見つからない」「承認ルートで詰まる」「法務レビューの想定時間が現実と合わない」などの摩擦を前もって摘み取ることができます。文化とは、決めたことを同じ手順・同じ品質・同じスピードで繰り返せることです。規格文書が机の上で眠るのではなく、ダッシュボードとRunbookが毎日のリズムを作る。ここに、規格と現場が重なる接点があります。
9. よくある失敗と、その避け方
「製品から入ってしまう」。魅力的な機能は多いのですが、経営・法務の目的に繋がっていない導入は、運用の負債になります。製品名は最後でいい。最初に決めるのはKPIと証跡です。「監査のためのフォルダ」を後追いで作る。監査用の証跡は設計の一部です。後から作り直すのは二度手間。最初から「どの箱に入れるか」を決め、運用で自動的に溜まるようにします。「例外を口約束で許す」。いいことは何も起こりません。例外は必ず期限・理由・承認・証跡。「SLAが“気合い”で書かれている」。人の頑張りに頼る限界はすぐ来ます。SLAは自動化の設計とセットで書く（自動隔離、初報ドラフト、承認ルートのショートカット等）。
10. スポット支援という選択肢
私たちの支援は、フル常駐ではなく**“必要なところだけ”**呼び出せるスポット型です。
導入前の要件定義だけ：経営・法務・運用の合意形成を2〜3週間で一気にまとめ、要件カタログ／設計原本／証跡台帳の第一版を作る。
E5移行時の再設計だけ：E3で積み上げた手順を壊さず、MDIやPIMなどの新要素を既存KPIに直結させる。
監査直前の証跡整理だけ：既設構成を崩さず、“聞かれ方”に沿った棚の作り替えを短期で実施。
重大インシデント後の再発防止だけ：事実に基づく設計修正（Runbook／例外運用／承認系）を、最小変更で最大効果の観点から提示。
スポットで入るからこそ、外部の目線で**“回すために要らないもの”も遠慮なく削ぎ落とせます。クラウドは足すより削る設計**が効きます。足した統制はコストになり、削った統制はスピードになります。削るには、目的と証跡が明確であることが条件です。
11. 仕上げとしての「一本線」チェック
最後に必ず、三層—経営・法務・運用—を貫く一本線チェックを行います。
経営の目的はKPIに変換されたか。
法規制の要求は証跡の形式で固定されたか。
運用の手順はRunbookとなり、ダッシュボードで回るか。
例外は期限・理由・承認・証跡で制御され、自動で失効するか。
インシデントはSLAで動き、72時間のタイムボックスに耐えるか。
そして、これらを誰が、いつ、どの棚から取り出せるかまで地図化されているか。
一本線が引けていれば、監査室とSOCの会話は滑らかになります。一本線が引けていないと、いつまでも「翻訳」に時間を食われます。セキュリティは翻訳作業ではありません。設計と運用と証跡が同じ言語で書かれている状態が、私たちの目指すゴールです。
NIST CSF 2.0／GDPRの“運用化”マッピング（第1巻・拡張完全版）
本稿は「規格の言葉」を「運用のスイッチ」と「監査の証跡」に翻訳するための実装ガイドです。ポイントは三つ――①条文やフレームワークを測定可能な運用条件に落とす、②設定値・手順・KPI・証跡を一対一で結びつける、③例外と改善を設計済みにする。以下、NIST CSF 2.0の6関数（Govern/Identify/Protect/Detect/Respond/Recover）と、GDPR主要条文（Art.25/30/32/33/35/Chapter V）を、Azure＋Microsoft 365 E5前提で“回る”形に変換します。
総論：運用化の原則（要件→設計→証跡の直結）
要件は経営・法務・運用の合意文（例：72h報告、P1封じ込め≤15分、ASR適用率≥95%）。
設計はダイヤル（CAポリシー、ASR Block、MDIタグ、隔離基準、復旧SLA）を数値で定義。
証跡は「どの棚のどの箱に、どのKQLで取り出すか」まで固定（保持期間・レビュー頻度も明記）。
この三点が最初から接続されていれば、監査も運用も迷いません。
1. NIST CSF 2.0 の運用化
Govern（方針／組織／責任）
1-1. ガバナンスポリシーの層構造
ポリシー（Why）… ゼロトラスト、最小権限、暗号、証跡主義。
標準（What）… CA強度、ASR必須ルール、鍵管理・タグ体系、ログ保持。
手順（How）… Runbook（初動・隔離・初報）、例外承認、ロール付与、証跡保管。
各文書はRACIで責任を固定：
Responsible：SOC L1/L2、情シス運用
Accountable：CISO/セキュリティ統括
Consulted：法務/DPO、業務オーナー
Informed：経営、監査
1-2. 例外設計（悪なのは“無設計の例外”）
前提：例外は必ず生まれる。
要件：期限・理由・承認・証跡・自動失効。
実装：PIM昇格（最大4h／承認者ローテーション／チケット必須）＋失効リマインド。
証跡：昇格ログ、承認記録、作業トレーサビリティを監査ストアへ。
1-3. 証跡台帳（Evidence Catalog）
各統制に棚卸キーを付与：
例：「CA-ADMIN-01：特権CA」「ASR-BASE-12：標準ASR」「MDI-TAG-01：Sensitiveタグ」
保管先（Sentinelワークスペース／M365監査／Key Vaultログ）、保持期間、KQL取得例を紐付け。
Identify（資産・リスク把握）
2-1. 資産台帳の自動化
Azure資産：Azure Resource Graph（ARG）で収集。
ID/アカウント：Entra ID、ロール割当、PIM履歴。
端末：MDEデバイスインベントリ（Intune準拠状態含む）。
SaaS：Defender for Cloud Apps（シャドーIT検出、OAuthアプリ監査）。
データ：Microsoft Purview（データマップ、スキーマ、機密ラベル）。
ARG例（ROPAタグの有無）
kustoresources | where type !contains "providers" | project name, type, location, ropaId = tostring(tags.ROPAId), dataClass = tostring(tags.DataClass)
2-2. クラウンジュエルの定義
基準：機密度×業務影響×外部露出。
指標：PKI/IDP/会計・支払・顧客PII・暗号鍵保管。
MDI Sensitiveタグ・ネットワーク閉域・運用分離で最初から別扱い。
2-3. リスク登録簿と設計の接合
リスク→設計要素→KPI→証跡を同じ行で管理。
例：「内部不正→PIM昇格＋JIT短時間＋操作ログ→“特権行使の平均時間≤30分、異常昇格=0”→監査KQL」。
Protect（最小権限・暗号・閉域）
3-1. IDと認証強度
CA：サインインリスク中以上→MFA、高→ブロック。
認証強度：FIDO2/Windows Hello既定、Authenticatorは番号一致、SMSは代替。
セッション：CAE有効、特権はサインイン頻度12h。
3-2. 最小権限（RBAC & PIM）
ロールはJITで短時間、恒久付与は原則禁止。
昇格には承認・理由・チケット、完了後は操作ログをEvidenceに集約。
3-3. ネットワーク閉域化
Private Endpoint/Linkで東西を最小化。
Azure Firewall/NSGでレイヤ分離、Outboundも許可リストで明示。
TLS検査の是非を製品要件で判断（例：MDI通信は中間解除不可）。
3-4. 暗号・鍵管理（Key Vault/Managed HSM）
CMK（顧客管理鍵）で重要データを暗号化。
ローテーションポリシー、アクセス分離（運用者≠鍵管理者）、監査ログの常時保全。
Purge ProtectionとSoft Deleteを既定で有効。
3-5. 端末ハードニング（MDE/Intune）
ASR（攻撃面削減）：標準はBlock、LOB干渉は“期限付き例外”。
Tamper Protection=ON、EDR in block modeを既定。
Intuneで構成プロファイルを強制し、逸脱は準拠外＝遮断のルールへ。
Detect（異常検知）
4-1. 検知の“線”を描く
MDI（ID横断）＋MDE（端末）＋MDO（メール）＋Sentinel（SIEM）＋Defender XDR（相関）。
アラートは“種類別の箱”ではなく、“時系列の線”で追う。XDRで統合→Sentinelで持久戦。
4-2. 品質メトリクス
カバレッジ：センサー健全性、ログ欠測率、MDI NNR成功率≥98%。
ノイズ：誤検知除外（IP/端末/ユーザー）をルール単位で実施。
SLA：未調査>24h=0、P1初動≤15分。
4-3. 代表KQL
高深刻度の未調査インシデント（24h超）：
kustoSecurityIncident | where Severity in ("High","Medium") | where Status in ("Active","New") and CreatedTime < ago(24h) | summarize count() by ProviderName, Severity
MDI NNR失敗トレンド：
kustoIdentityDirectoryEvents | where ActionType == "ActiveNameResolutionFailed" | summarize Failures=count() by bin(Timestamp, 1d)
Respond（対応）
5-1. 自動隔離基準
高深刻度×横展開兆候＝自動隔離（端末/アカウント/トークン失効）。
単発は承認制。Action Centerに根拠と時間を残す。
5-2. 初報テンプレ（72hラインに収まる骨格）
事象概要／検知源／時系列（T0〜）／影響範囲（データ主体・件数・国）／暫定対策／継続対応／再発防止の方向性。
法務レビューをRunbookに組み込み、ドラフト自動生成で“書く時間”を削減。
5-3. 法務・広報・経営の合流点
経営ブリーフ（A4一枚）：被害・拡大リスク・社会的影響・義務・72hマイルストーン。
連絡経路、テンプレ、承認者を工程に埋め込み、待ち時間を設計段階で潰す。
Recover（復旧）
6-1. RTO/RPOを“資産ごとに”固定
例：基幹DB RTO=8h/RPO=15min、認証基盤 RTO=2h/RPO=5min。
ASR（Site Recovery）／Azure Backup／**Immutable Blob（WORM）**で整合性を確保。
6-2. バックアップの耐タンパ
Soft Delete/Purge Protection、**多要素承認（MUA）**相当の運用、異常削除アラートを設計に組み込む。
6-3. 演習と教訓
ゲームデー（復旧テスト）を四半期ごとに実施。
収穫はポリシーとRunbookへ反映し、KPIにも連鎖させる。
2. GDPR の運用化
Art.25（設計段階の保護：Privacy by Design/Default）
7-1. IaCに“規格”を書き込む
Terraform/Bicepのモジュール標準に、暗号（CMK）、PE、タグ、診断設定、ポリシー割当を埋め込む。
Denyポリシーで逸脱を未然に遮断（例：公開Storageの作成禁止）。
7-2. データ最小化・認可の分離
最小権限（RBAC分離、PIM JIT）とデータ最小化（必要最小の属性収集）の両輪。
用途別サブスクリプションでデータ流通を分節化。
7-3. 既定で安全（Default）
暗号ON、公開エンドポイントOFF、ログ収集ON、タグ必須。
“デフォルトが安全”を設計の初期値にする。
Art.30（処理台帳：ROPA）
8-1. ROPAと構成の一体化
ROPA IDをタグとして全リソースに付与（例：tags.ROPAId="ROPA-AR-00123"）。
データフロー図とPurviewのデータマップに同じIDを記載。
監査では「その処理のシステムは？」と聞かれて、ARG/KQLで即抽出できる状態に。
8-2. 差分の自動追従
CI/CDの変更時にROPA更新タスクを自動生成。
期日超過は自動通知。**「台帳は常に構成の鏡」**が原則。
Art.32（安全管理）
9-1. 技術的措置（例示）
CA（リスクベースMFA、地理・端末・リスクの複合）
ASR（実行抑止・スクリプト制御・資格情報窃取防止）
MDE/MDI/MDO（横断検知）
鍵管理（Key Vault、ローテ、監査）
ログ・監査証跡（保持≥365日、改ざん耐性）
9-2. 組織的措置
RACI、Runbook、教育、ウォーゲーム、例外の設計。
定期レビューでKPIと証跡の両輪を回す。
Art.33（72時間報告）
10-1. 72hタイムボックスに収まる仕組み
検知→ドラフト自動生成→法務レビュー→提出の直線動線。
必要項目（時系列・影響範囲・暫定対策）をテンプレ化して“考える時間”を最小化。
10-2. 連絡網と責任
DPO/監督機関の連絡先、承認者、代替者をRunbookに埋め込み。
障害時の臨時承認ルートも設計（夜間・休日の想定）。
Art.35（DPIA）
11-1. 変更管理と接続
変更申請にDPIA要否判定を必須化。
ハイリスク処理（位置情報、大規模監視、センシティブ区分等）はDPIA完了で初めて本番反映。
11-2. 証跡と再利用
DPIAはテンプレ＋チェックリスト＋関連KPIで構造化。
次回の類似処理にそのまま再利用できる“設計知”として蓄える。
Chapter V（越境移転）
12-1. 技術・契約の両輪
EU Data Boundaryを既定としつつ、SCC/DPAで契約面を補強。
Customer Lockboxでサポートアクセスを都度承認。
CMK/DKE（必要に応じて）で鍵の主導権を維持。
12-2. 可視化と監査
どのデータがどの地域に置かれ、誰がどの理由で越境したかを証跡として可視化。
Purview＋ROPAタグ＋Sentinelで一元追跡できる線を作る。
3. “回る”ためのKPIとダッシュボード
運用KPI：未調査アラート24h以内100%、MDI NNR≥98%、ASR適用率≥95%、AIR成功率≥85%。
結果KPI：既知悪性URLクリック率≤0.5%/月、横展開封じ込め中央値≤15分。
ガバナンスKPI：72h初動SLA遵守率100%、期限切れ例外=0、ROPA差分反映≤7日。
可視化原則：
“一画面＝一判断”。L1は対応優先度、CISOは健全度、DPOは72h準備度。
各タイルに取得KQLと証跡棚を紐付け、見たら取れるを徹底。
4. ランブック（抜粋）
P1：ハニートークン発火（MDI）
自動：アカウント無効化、トークン破棄、セッション強制切断。
T+5分：初報ドラフト自動生成。
T+15分：封じ込め完了レビュー、横展開確認。
T+120分：法務レビュー済み初報提出。
T+24h：原因分析と再発防止案（暫定）共有。証跡：アラート、対処ログ、承認、提出物、時系列、関係者一覧。
5. よくある落とし穴と回避策
“製品から入る”：まずKPIと証跡。製品はその後。
“監査用フォルダを後追いで作る”：証跡は設計の一部。自動で溜まる仕掛けに。
“例外を口頭で許す”：期限・理由・承認・証跡・自動失効。
“SLAが気合い”：SOAR・自動隔離・ドラフト自動化で時間を設計。
6. 90日導入ロードマップ（例）
Day 0–30：要件カタログ／設計原本／証跡台帳、CA/ASR/MDI基本、タグ体系、ARG基盤。
Day 31–60：Sentinel相関・SOAR、PIM運用、ROPA連携、72hテンプレ、KPI初版。
Day 61–90：机上演習・ゲームデー、例外運用開始、KPI調整、監査パッケージ試作。
7. 成果物の標準パッケージ
要件カタログ（法務・経営・運用の合意）
設計原本（CA/ASR/MDI/MDE/MDO/鍵/ネットワークの数値）
証跡台帳（棚・箱・KQL・保持）
Runbook（P1/P2、初報テンプレ、承認ルート）
KPIダッシュボード（L1/CISO/DPOビュー）
DPIAテンプレ／ROPA連携仕様
例外運用要領（自動失効・通知）
8. 付録：さらに深く実装するためのスニペット
ARG：公開リソース検出（設計違反の早期検知）
kustoresources | where type =~ "microsoft.storage/storageaccounts" | extend allowBlobPublicAccess = tobool(properties.allowBlobPublicAccess) | where allowBlobPublicAccess == true | project name, resourceGroup, location, tags
Sentinel：72h報告ビューのベース（直近72hの高深刻度）
kustoSecurityIncident | where Severity == "High" and CreatedTime > ago(72h) | project Title, CreatedTime, Description, Owner, Status
MDE：ASRブロック適用率（端末群ごと）
kustoDeviceTvmSecureConfigurationAssessment | where ConfigurationId startswith "ASR" | summarize Applied=countif(ConfigurationValue == "Blocked"), Total=count() by DeviceGroup | extend Rate = todouble(Applied) / todouble(Total) * 100.0
結語：規格の言葉を「運用のダイヤル」に
NIST CSF 2.0の6関数は、Azureの設定ダイヤルに置き換えられます。GDPRの条文は、証跡テンプレとRunbookの見出しに変換されます。要件→設計→証跡が一本線で結ばれた瞬間、監査は運用の副産物になり、運用は数字で語れる文化に変わります。
3) 要件定義：ゴールから逆算する設計
0. なぜ“逆算（バックキャスト）”なのか
セキュリティは「積み上げ式」にすると必ず破綻します。プロダクト単位の“善”を足し合わせると、現場では運べず、監査では語れず、費用は雪だるま。だから最初にゴール（成果と証跡）を決め、そこからKPI→設計→手順→自動化→監査棚を逆算します。以降は、その作法を目的定義／測定指標／設計要素／運用体制／テスト／成果物の6レイヤで具体化します。
1. 目的定義：ゴールは“時間”と“証跡”で表現する
まず、経営・法務・運用の三者が時刻と成果物で握れる目標に変換します。
P1のID侵害を封じ込める → 「検知→封じ込め ≤ 15分」
GDPRの報告をミスなく → 「発生日基準72時間以内に、初報パッケージ（時系列・影響範囲・暫定対策・再発防止方針）を法務レビュー済みで提出可能」
監査で説明できる運用 → 「監査質問→証跡取得まで≤10分、棚と箱が一意に決まる」
日常を止めない → 「高深刻度の自動隔離は人待ちゼロ、承認は“戻し”にだけ必要」
コスト最適化 → 「ノイズ（不要アラート）を四半期で30%削減、同時に封じ込め中央値を維持または短縮」
目標は名詞＋時間＋提出物で書くのがコツ。「やる」ではなく「何分で何が出るか」まで言い切る。
2. 測定指標（KPI）：設計に“数字の骨”を入れる
2.1 運用KPI（回るか）
未調査アラート24h=0（High/Medium）
MFA登録率=100%（全ユーザー、来訪者は除外定義を明記）
ASR適用率≥95%（対象端末群）
MDI NNR成功率≥98%（95～98%は観察、＜95%は即是正）
AIR（自動修復）成功率≥85%（MDE）
2.2 結果KPI（守れたか）
既知悪性URLクリック率≤0.5%/月（MDO）
横展開封じ込め中央値≤15分（感染からブロック完了まで）
再感染率（月次）↓（前月比改善）
2.3 ガバナンスKPI（語れるか）
72h初動SLA遵守率=100%（Art.33）
期限切れ例外=0（PIM昇格・ASR例外）
ROPA差分反映≤7日（構成変更→台帳更新）
KPIはダッシュボードのタイルに直結。各タイルにはKQLと“証跡棚”（取り出し先）を紐づけます。
3. 設計要素：ダイヤルを“数値”で固定する
要件を叶えるダイヤルをCA／PIM／ASR／MDIタグ／SOAR／証跡保管の6群に分解し、既定値→例外→証跡まで一気に定義します。
3.1 CA（条件付きアクセス）
サインインリスク：中以上→MFA必須／高→ブロック
ユーザーリスク：高→アクセス許可＋パスワード変更必須（SSPR+Writeback）
セッション：CAE=ON。特権ロールはサインイン頻度12h、一般は既定（90日）または7日
場所/デバイス：特権は準拠端末のみ。新規ASN・高リスク地域は段階的ブロック
認証強度：既定=FIDO2/Windows Hello、Authenticatorは番号一致、SMSは代替（廃止計画も併記）
CAポリシー雛形（抜粋）
pgsqlPolicy: CA-ADMIN-01 (Privileged Access) Users: Privileged Roles Grant: Require Compliant Device + MFA Session: Sign-in frequency = 12h, CAE = On Exception: Break-glass (2 accounts), stored offline; monthly drill Evidence: Entra Sign-in Logs, Policy export, Change history
3.2 PIM（特権のJIT）
昇格は最大4h、承認者ローテーション、理由＆チケット必須
恒久付与禁止（移行期間の正当化は期限付き例外として管理）
操作ログをEvidenceに自動保管（変更不可ストア推奨）
3.3 ASR（攻撃面削減ルール）
既定はBlock。LOB干渉は期限付き例外（理由・承認・失効日）
代表ルール：
Office子プロセス生成抑止
他プロセス注入抑止
実行ファイル作成抑止
難読化スクリプト抑止
資格情報窃取防止（LSA）
適用率≥95%を維持。逸脱はIntune準拠違反として自動検出
3.4 MDI（タグと欺瞞、検知の土台）
Sensitiveタグ：EA/DA/Schema Admins、PKI/IDP/会計・支払系=100%タグ付け
ハニートークン最小3/フォレスト（各ドメイン1＋冠ジュエルOU1）
NNR成功率≥98%、重大ヘルス=0を日次巡回
誤検知除外は“ルール単位”（IP/端末/ユーザー）
3.5 SOAR（自動化：Sentinel/Defender XDR）
高深刻度×横展開兆候＝自動隔離（デバイス・セッション・トークン）
72h初報ドラフト自動生成（XDR/Incidents→Logic Apps→Teams/メール）
重複インシデント抑制（相関ルール＋サプレッション）
3.6 証跡保管（Evidence Vault）
棚（Workspace/Container）→箱（フォルダ/テーブル）→索引（KQL/ID）を定義
保持≥365日（規制要件に応じ延長）
改ざん耐性（Immutable/WORM・変更履歴）
目次（Evidence Catalog）で「監査質問→KQL→取り出し先」を1行で繋げる
4. 運用体制：Who/When/HowをRunbookで固定
RACIとRunbookで人待ちゼロを設計します。
4.1 RACI（典型）
Responsible：SOC L1/L2、情シス運用
Accountable：CISO／セキュリティ統括
Consulted：法務（DPO）、広報、業務オーナー
Informed：経営、監査
4.2 重大度定義（例）
P1：ハニートークン発火、特権侵害、横展開兆候、PII大量流出の恐れ
P2：単一端末感染、限定的フィッシング
P3：設定逸脱、検知テスト、情報提供
4.3 P1 Runbook（抜粋・分単位）
T+0 : XDR High Incident created (MDI Honeytoken) Auto : Device isolation / Session revoke / Token revoke T+5 : 初報ドラフト自動生成（事象・時系列・影響範囲・暫定対策） T+10 : L2レビュー→承認→法務へ提出（Teams/専用チャンネル） T+15 : 封じ込め完了レビュー（隔離成功・横展開なしを確認） T+30 : 追加スキャン／IOCハント（範囲：同セグメント＋関連ユーザー） T+120 : 法務レビュー済み初報、DPO/経営へエスカレーション D+1 : 暫定再発防止策の実装確認、KPI更新、Evidence登録
“誰が”“どこを開く”“何を押す”まで書きます。リンク・画面名・代替経路（夜間/休日）もRunbookに明記。
4.4 連絡テンプレ（法務・経営・広報）
技術報：タイムライン／検知根拠／封じ込め状況／未解決リスク
法務ブリーフ：GDPR該当性／データ主体範囲／提出期限／必要追加情報
経営ブリーフ：業務影響評価／メディア露出リスク／意思決定ポイント
広報雛形：外部説明の骨子（必要時）
5. テスト：設計は“訓練”で完成する
設計は図面のままでは動きません。机上演習／フィッシング模擬／ハニートークン発火テストで時間と摩擦を削ります。
5.1 机上演習（Tabletop）
参加：運用・法務・広報・経営（必要最小）
シナリオ：ID侵害、メール踏み台、誤送信、設定ミス
目的：Runbookの“待ち時間”と“曖昧語”を特定して潰す
アウトプット：Runbook修正、連絡先・承認ルートの更新
5.2 フィッシング模擬（MDO/攻撃シミュレーション）
指標：クリック率、報告率、初動SLA
改善：セーフリンク適用漏れ、送信者偽装ルールのしきい値調整
5.3 ハニートークン発火テスト（MDI）
頻度：月次
完了条件：P1 Runbookの分単位SLA遵守、証跡の完全収集
5.4 ゲームデー（自動化検証）
SOARの直列動線（アラート→隔離→初報ドラフト→承認→保管）が分単位で動くか
失敗時：Playbookの分岐・例外処理を増補
6. 成果物：最初に“棚”を決め、最後までブレさせない
着手30日で第一版を出し、60/90日で成熟させる想定。以下は各成果物の目次と完成条件です。
6.1 政策文書（Policy）
目次（例）
目的・範囲
定義（重大度、例外、証跡 等）
ゼロトラスト原則
認証・権限管理（CA/PIM/認証強度）
端末防御（ASR/EDR）
検知・対応（MDI/MDE/MDO/Sentinel/XDR）
監査・証跡・保持
教育・訓練
例外管理（期限・理由・承認・証跡・自動失効）完成条件：RACI明記／例外の“生まれ方”を仕様化／改訂手順を付録化
6.2 標準手順（SOP・Runbook集）
P1/P2インシデント、72h初報、法務レビュー、メディア対応、復旧
完成条件：分単位SLA／UIスクリーン名／代替経路／連絡テンプレURL
6.3 構成図（As-is/To-be、論理・物理・データフロー）
色分け：ゼロトラスト境界／クラウンジュエル／閉域／監査管路
完成条件：ROPA ID・データ分類・鍵管理の紐付け
6.4 IaC（Bicep/Terraformモジュール標準）
既定で安全：暗号ON、PE/Firewall、診断設定、タグ必須、Policy割当
例：Bicep断片（Storageアカウントの安全既定）
bicepresource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: name location: location sku: { name: 'Standard_GRS' } kind: 'StorageV2' properties: { allowBlobPublicAccess: false minimumTlsVersion: 'TLS1_2' supportsHttpsTrafficOnly: true encryption: { services: { blob: { enabled: true }, file: { enabled: true } } keySource: 'Microsoft.Keyvault' } networkAcls: { defaultAction: 'Deny' bypass: 'AzureServices' virtualNetworkRules: [ for id in vnetRules: { id: id } ] ipRules: [ for ip in ipAllow: { value: ip } ] } } tags: { ROPAId: ropaId DataClass: dataClass } }
6.5 KQLライブラリ（ダッシュボード直結）
未調査×高深刻度（24h超）
kustoSecurityIncident | where Severity in ("High","Medium") | where Status in ("Active","New") and CreatedTime < ago(24h) | summarize count() by ProviderName, Severity
MDI NNR失敗率（日次）
kustoIdentityDirectoryEvents | where ActionType == "ActiveNameResolutionFailed" | summarize Failures=count() by bin(Timestamp, 1d)
ASR適用率（端末群）
kustoDeviceTvmSecureConfigurationAssessment | where ConfigurationId startswith "ASR" | summarize Applied=countif(ConfigurationValue == "Blocked"), Total=count() by DeviceGroup | extend Rate = 100.0 * todouble(Applied) / todouble(Total)
クリック率（既知悪性URL）
kustoEmailUrlInfo | where ThreatTypes has "KnownMalware" | summarize Clicks=count() by bin(Timestamp, 1d)
6.6 監査用パッケージ（Evidence Pack）
目次：質問→取得手順→KQL→出力例→保管先→保持
必須同梱：
CA/PIM/ASR/MDI/MDE/MDOの設定エクスポート
72h初報テンプレ（埋め込み例つき）
例外台帳（失効自動通知のログ）
ROPA対応表（リソースタグとの突合）
訓練記録（机上演習・ゲームデー結果）
7. “逆算”の実装例：72h報告を自動で回す
ゴール：「発生日から72h以内に法務レビュー済み初報を提出可能」逆算：
XDR/Incident作成→Playbook起動（T+0）
ドラフト自動生成（タイトル／時系列／検知源／影響範囲候補／暫定対策／今後の予定）
法務レビューチャネルに自動配信（T+5分）
担当アサインとToDo生成（データ主体確定、件数、越境有無）
Evidence保管（バージョンを刻み保存）
提出（DPO承認ルート、代替ルート含む）KPI：T+120分でレビュー可能な品質、72h以内100%提出
8. “逆算”の実装例：ID侵害15分封じ込め
ゴール：「検知→封じ込め≤15分」逆算：
自動隔離の基準を高深刻度×横展開兆候に固定
セッション失効／トークン破棄／パスワードリセットの順序をPlaybookで直列化
MDI→XDR→Sentinel→Intune/Entra APIの連携遅延をテストで短縮
人の承認は“復帰”のみに（隔離側は自動）
ダッシュボードに**“封じ込め時計”**を表示（開始→完了の実測）
9. リスクと例外：悪いのは例外ではなく、未設計の例外
期限・理由・承認・証跡・自動失効の5点セットを標準化
例：ASR例外は最大30日、延長はCISO承認、失効7日前通知
月次レビューで**例外の“借金残高”**を可視化し、削減OKRを設定
10. 30/60/90日の“完成のしかた”
Day 0–30：ゴール合意（SLA/72h/KPI）／CA・PIM・ASR・MDI最小セット／Evidence棚の雛形
Day 31–60：SOAR直列化／72hドラフト自動化／KQLダッシュボード初版／Runbookの分単位化
Day 61–90：机上演習→Runbook改訂／ハニートークン定期運用開始／監査パッケージ初版／例外運用稼働
“完成”は静止画ではなく回る系の動画です。運用→証跡→改善が止まらない状態が完成。
11. 付録：テンプレ断片
11.1 72h初報テンプレ（骨子）
事象の要約（1段落）
検知源と時系列（T0/T+5/T+10…）
影響範囲（データ主体、件数、地域、越境有無）
暫定対策（封じ込め・追加防御）
再発防止の方向性（確定/検討中を明示）
次の更新予定（日時・担当）
11.2 例外申請票（標準）
例外対象（ポリシー/端末/ユーザー/システム）
理由（業務・障害・検証）
代替統制（暫定）
期限（自動失効日）
承認者（一次/二次）
証跡格納先（Evidence ID）
11.3 机上演習チェックリスト（抜粋）
連絡先・承認者の “当日有効性”
法務レビューの “通過点” がRunbookに書かれているか
ダッシュボードの タイルからKQL→証跡棚 がワンクリックで辿れるか
復旧判断材料（RTO/RPO、業務影響）の提示速度
12. まとめ：要件→設計→証跡、一本線のまま回す
ゴールは名詞＋時間＋提出物で握る（例：15分封じ込め、72h初報）。
KPIは運用／結果／ガバナンスの三層で“ダッシュボード前提”に設計。
ダイヤル（CA/PIM/ASR/MDI/SOAR/Evidence）は既定値・例外・証跡までセットで書く。
Runbookは分単位、例外は期限と自動失効、テストは発火まで行う。
成果物は棚から箱まで最初に決め、監査の質問に10分以内で答えられる形に。
4) ゼロトラスト設計原則 in Azure（実装・運用完全版）
ゼロトラストは「何を買うか」ではなく「どう判断し、どう証明するか」の体系です。本稿では、次の6原則を要件→設計→KPI→証跡→運用テストの流れで結びます。
ID中心：本人＋端末＋リスクでリアルタイム判定（CAEで即反映）
最小権限：常時付与はしない。特権はPIMでJIT短時間
閉域優先：Private Endpoint／Firewall、OutBoundも明示
データ分類：ラベルとタグで機密度→CAやDLP・暗号に接続
検知前提：失敗を前提に、MDI/MDE/MDO→Sentinelで相関
証跡第一：変更・承認・検知・対応を参照可能に一元保存
各原則は独立して見えても、KPIと**Evidence（証跡）**で縦に貫くと日常運転で機能します。
原則1｜ID中心：本人・端末・リスク・コンテキストの合成評価
目的（例）
P1（高リスクサインイン＋非準拠端末）の自動ブロック
「旅程矛盾（Impossible Travel）」「匿名プロキシ」などのサインインリスクを即時MFA/ブロックへ
セッション内のリスク変化を**CAE（Continuous Access Evaluation）**で即反映
設計の要点
条件付きアクセス（CA）
サインインリスク：中以上→MFA必須／高→ブロック
ユーザーリスク：高→アクセス許可＋パスワード変更必須（SSPR/Writeback前提）
セッション：CAE=ON、特権ロールのサインイン頻度=12h、一般は既定（または7日）
端末：準拠端末のみ特権可、BYODはアプリ保護ポリシー／VDI経由へ誘導
場所/ASN：ハイリスク地域・ASNは段階的ブロック（観察→MFA→拒否）
認証強度
既定：FIDO2/Windows Hello
Authenticator：番号一致必須
SMS/音声：代替（縮退パスとして扱い、段階廃止計画）
外部コラボ（B2B）
Cross-tenant access の既定ルール＋来訪者に対するMFA/準拠端末要求
“必要時のみ招待／期限付き”を運用基準化。期限切れ自動失効を必須
KPI
MFA登録率=100%
高リスクサインインの自動ブロック率=100%
特権の“非準拠端末からの成功サインイン”=0
サインイン後の強制再評価（CAE反映）遅延中央値≤2分
Evidence（例）
CAポリシーのエクスポート、サインインログ（高リスク→MFA/ブロックの実績）、CAE有効化確認、来訪者ポリシーの差分履歴
原則2｜最小権限：JIT/JEAで“必要な時に必要なだけ”
目的（例）
常時の特権ロール付与ゼロ
昇格は最大4時間／承認・理由・チケット必須
操作の追跡可能性（誰が・いつ・何を・なぜ）
設計の要点
PIM（Privileged Identity Management）
JIT昇格：最大4h／承認者ローテーション／理由・チケット必須
緊急用ブレークグラス：2アカウント、金庫保管、月1回のドリル必須
昇格後の操作ログをEvidence Vaultへ自動格納
RBAC（ロール）
組織標準の最小ロールセットを定義（読取・監査・オペ・所有の4層など）
カスタムロールは“禁止×許可の明確化”と棚卸サイクルを付帯
管理者作業は**PAW（特権アクセス用端末）**からのみ許可（CA＋条件）
JEA（Just Enough Access）
「端末の再起動」「診断ログ取得」等の限定権限の手続き化
スクリプトは署名・改変監査＋バージョン固定
KPI
恒久付与の特権ロール=0
PIM昇格の承認率×理由記入率=100%
PAW以外からの特権操作=0
特権行使の平均所要時間≤30分（JITでの業務阻害を許容範囲に）
Evidence（例）
PIM昇格履歴、承認ログ、PAW準拠証跡、操作コマンド記録、ロール定義・変更履歴
原則3｜閉域優先：入口も出口も“既定で閉じる”
目的（例）
主要PaaS（Storage/Key Vault/SQL/SB/EH/AKS/ACR 等）はPrivate Endpointで閉域
Outboundは“許可リスト方式”で明示
TLS中間解除の可否は製品要件ベースで決定（例：MDIは不可）
設計の要点
Private Endpoint（PE）
すべての機密データ面はPE必須。Private DNS Zone とセットで展開
共有PEの“過密”を避け、目的別サブネットで分節
Outbound制御
Azure Firewall でFQDNタグ／FQDN許可リスト化
“どこにも出られない”を既定、必要先だけ開ける
MDIなどTLS中間解除不可のサービスはバイパス
Ingress最小化
Public IPは原則禁止（例外は期限付き承認）
App/Function/AKSはPrivate構成が既定。公開が必要ならFront Door/WAF越し
DDoS/NSG
DDoS Standard（要件に応じ）、NSGは明示拒否を下層に
IaC断片（Storageの安全既定・Bicep）
bicepresource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: name location: location sku: { name: 'Standard_GRS' } kind: 'StorageV2' properties: { allowBlobPublicAccess: false minimumTlsVersion: 'TLS1_2' supportsHttpsTrafficOnly: true encryption: { services: { blob: { enabled: true }, file: { enabled: true } } keySource: 'Microsoft.Keyvault' } networkAcls: { defaultAction: 'Deny' bypass: 'AzureServices' } } tags: { ROPAId: ropaId, DataClass: dataClass } }
KPI
PE未適用の機密リソース=0
Public IP直公開の機密ワークロード=0
Outbound未定義の“暗黙通信”検出=0
Evidence（例）
Azure Policy 準拠レポート、Firewall ルール・ヒットログ、PE/DNS構成のIaC出力、Public禁則の否認イベント
原則4｜データ分類：ラベルとタグを“制御の鍵”へ直結
目的（例）
ラベル/タグがCA・DLP・暗号・鍵管理に連動
GDPR Art.30 の ROPA と一対一で対応（台帳＝構成の鏡）
設計の要点
分類の軸
機密度（Public/Confidential/Restricted など）
個人データ種別（PII/Health/Financial）
処理ID（ROPAId）
タグ設計（Azure）
DataClass, ROPAId, Owner, BIA-Tierを標準化
Policyでタグ必須・未設定時は作成拒否
暗号・鍵管理
CMK（Key Vault/Managed HSM）／ローテ／アクセス分離
Purge Protection/Soft Delete＝必須
DLP/CA連動
高機密は条件付きアクセスで“準拠端末＋強認証のみ”
電子メール・SharePoint/OneDrive などのDLPポリシーにラベル連動
KPI
タグ/ラベル未設定の本番ワークロード=0
CMK未適用の“高機密”=0
ROPA差分反映≤7日
Evidence（例）
ARG（タグ充足率）結果、Key Vault 監査ログ、DLPヒット／例外の履歴、ROPAと構成タグの突合レポート
原則5｜検知前提：MDI/MDE/MDO→XDR→Sentinel の“線”で追う
目的（例）
ID・端末・メールのアラートをXDRで一元化
Sentinel で時系列相関（線）とSOAR
自動隔離→初報ドラフト→法務レビューが直列で走る
設計の要点
センサー品質
MDI：NNR成功率≥98%／重大ヘルス=0
MDE：センサーバージョン最新率≥95%、ASR適用率≥95%
MDO：Safe Links/Attachments=ON、Anti‑phish 高しきい値
相関とノイズ抑制
XDRで重複抑制、Sentinelでサプレッション
誤検知はルール単位で除外（IP/端末/ユーザー）し、根拠をEvidenceへ
SOAR直列
高深刻度×横展開兆候→自動隔離
72h初報ドラフト自動生成→法務レビュー→Evidence格納
代表KQL
未調査×高深刻度（24h超）棚卸
kustoSecurityIncident | where Severity in ("High","Medium") | where Status in ("Active","New") and CreatedTime < ago(24h) | summarize count() by ProviderName, Severity
MDI NNR失敗トレンド
kustoIdentityDirectoryEvents | where ActionType == "ActiveNameResolutionFailed" | summarize Failures=count() by bin(Timestamp, 1d)
KPI
未調査アラート24h=0
横展開封じ込め中央値≤15分
自動修復（AIR）成功率≥85%
Evidence（例）
XDRインシデント一覧、SOAR実行履歴、隔離・復帰のアクションログ、初報ドラフトの版管理
原則6｜証跡第一：監査は“運用の副産物”にする
目的（例）
監査質問→証跡取得まで**≤10分**
証跡は改ざん耐性＋長期保持で集中保管
72h報告に必要な最小パッケージが“自動で溜まる”
設計の要点
Evidence Vault
棚（Workspace/Container）→箱（Table/Folder）→索引（KQL/ID）
保持≥365日（規制で延長）、WORM/Immutableで保全
目次（Evidence Catalog）で**“どの統制→どのKQL→どの棚”**を1行で参照可能
診断設定の既定
すべての本番リソースにDiagnostic Settings必須（Log Analytics/Archive）
変更・承認・実行（人と自動化）の三層ログを収集
監査パッケージ
CA/PIM/ASR/MDI/MDE/MDOの設定エクスポート
72h初報テンプレ＋埋め込み例
例外台帳（期限・理由・承認・自動失効ログ）
KPI
証跡取得SLA≤10分（監査想定質問5種）
保持切れ・欠測=0
期限切れ例外=0
ゴールドパス（30/60/90日の実装ロードマップ）
Day 0–30（基礎固め）
CA：サインイン/ユーザーリスク、PAW必須、CAE
PIM：JIT昇格（4h/承認/理由/チケ）、ブレークグラス整備
ASR：Block標準・例外は期限付き
PE：機密面のPrivate化／Public禁止Policy
Evidence Vault雛形（保持・WORM）／診断設定の既定化
Day 31–60（検知前提化）
MDIセンサー／MDE適用率95%／MDO高しきい値
XDR統合→Sentinel相関・SOAR直列（自動隔離→初報）
分単位Runbook（P1/P2）＋法務・経営ブリーフ雛形
データ分類タグ/ラベル→CA/DLP/暗号連動
Day 61–90（運用定着）
机上演習・ハニートークン発火テスト・フィッシング模擬
KPIダッシュボード（運用/結果/ガバナンス）初版
監査パッケージ（“72hセット”）初版
例外台帳の自動失効・月次棚卸運用開始
よくある落とし穴（回避策セット）
“製品から入る” → 先にKPIとEvidenceを決め、製品はダイヤルとして後付け。
“Public例外の常態化” → 例外は期限・理由・承認・証跡・自動失効。延長はCISO承認。
“TLS検査の全面適用” → 製品要件で可否を分ける（MDIなどは不可）。
“タグ不統一” → DataClass/ROPAId/Owner/BIA-Tier をPolicyで必須に。
“Runbookが名詞止まり” → 誰が/どの画面で/何を押すか/何分以内まで書く。
監査に強いKQLスニペット（抜粋）
72h報告ビュー（直近72hのHigh）
kustoSecurityIncident | where Severity == "High" and CreatedTime > ago(72h) | project Title, CreatedTime, Owner, Status, Description
ASR適用率（端末群）
kustoDeviceTvmSecureConfigurationAssessment | where ConfigurationId startswith "ASR" | summarize Applied=countif(ConfigurationValue == "Blocked"), Total=count() by DeviceGroup | extend Rate = 100.0 * todouble(Applied) / todouble(Total)
特権操作の監査（直近7日）
kustoAuditLogs | where ActivityDisplayName has "Activate eligible assignment" or ActivityDisplayName has "Add member to role" | project TimeGenerated, InitiatedBy, ActivityDisplayName, TargetResources
まとめ：原則は“ダイヤル”、運用は“習慣”、監査は“副産物”
ID中心で“誰・どこ・どの端末・どのリスク”を常時評価し、CAEで変化を即反映。
最小権限はPIMのJIT/JEAで、権限の“時間”と“範囲”を絞る。
閉域優先はPE＋Firewall＋Outbound許可リストで「既定で閉じる」。
データ分類はラベル/タグ→CA/DLP/暗号の“制御の鍵”。
検知前提はMDI/MDE/MDO→XDR→Sentinelの“線”で追い、SOAR直列で15分封じ込めと72h初報を実現。
証跡第一でEvidence Vaultを整え、監査の質問に10分で答える。
5) Entra ID P2 詳細設計（CA／PIM／Risk／CAE／認証強度）—実装・運用・証跡
ゼロトラストの中心は**「IDで判断し、秒で反映し、数字で証明する」**こと。ここでは、Entra ID P2 の中核である 条件付きアクセス（CA）／PIM／Identity Protection（Risk）／CAE／認証強度を、要件 → 設計ダイヤル → 運用KPI → 証跡（Evidence） → テスト の一本線で固めます。
A. 条件付きアクセス（CA）設計
A-1. 目的と原則
リスク発生時の自動分岐（MFA/ブロック/パスワード変更）を人の判断に先行させる
特権と一般を分離（特権は“準拠端末＋強認証＋短セッション”）
“既定で閉じる”（未知の国/ASN、レガシー認証、非準拠端末は原則拒否）
A-2. ポリシー・パッケージ（基礎10本）
CA-ADMIN-01：特権アクセス強化
対象：管理者ロール（全）
条件：任意サインイン
付与：準拠端末必須＋MFA必須
セッション：サインイン頻度=12h、CAE=ON
例外：ブレークグラス2アカウント（監査で証跡）
CA-BASE-02：一般ユーザー強化
対象：一般ユーザー
条件：サインインリスク=中以上
付与：MFA必須／リスク=高はブロック
CA-RISK-03：ユーザーリスク対応
対象：Identity Protection でユーザーリスク=高
付与：アクセス許可＋パスワード変更必須（SSPR/Writeback前提）
CA-LOC-04：来歴のない国／匿名IP/トーネル
条件：国判定・匿名IP・TOR/アノニマイザ
付与：ブロック（またはMFA→ブロックの段階）
CA-DEV-05：非準拠端末の制御
対象：Managed端末以外
付与：アプリ保護（MAM）に迂回、特権はブロック
CA-LEG-06：レガシー認証の遮断
条件：レガシークライアント（POP/IMAP/SMTP AUTH ほか）
付与：ブロック（必要なら期限付き例外）
CA-B2B-07：来訪者（External）の最小化
対象：B2B ゲスト／外部ID
付与：MFA必須、高価値アプリは準拠端末要求
期限：来訪者ライフサイクルに合わせ失効
CA-APP-08：高機密アプリの強認証縛り
対象：冠ジュエル（会計/PII/PKI）
付与：認証強度=フィッシング耐性（下記C節）
CA-SES-09：セッション衛生
対象：全ユーザー
セッション：Persistent Browser=無効／Sign-in frequencyは一般既定or7日
CA-API-10：自動化アクセス保護
対象：Workload Identity／Service Principal
付与：制約付き（許可アプリ／許可IP）、Secret→証明書/JWTへ移行
いずれもポリシー名／目的／対象／条件／付与・セッション／例外／証跡をセットで定義。**例外は“期限・理由・承認・自動失効”**が必須。
A-3. 認証強度（Authentication Strength）との接続
標準強度：MFA（任意）
中強度：MFA＋デバイス準拠
高強度（フィッシング耐性）：FIDO2/Windows Hello のみ通過
CA-APP-08 で冠ジュエルへ適用
Authenticator は番号一致必須（ワンタイムコードは代替）
A-4. セッション設計（CAE 前提）
CAE=ON（後述D節）：トークン寿命に依らず、リスク変化・失効を即反映
Sign-in frequency：特権=12h、一般=既定（または7日）
アプリ制御：Defender for Cloud Apps のセッション・プロキシで高機密の操作制限
A-5. KPI／Evidence／KQL
KPI：
MFA登録率=100%
特権の非準拠端末から成功サインイン=0
高リスクサインインの自動ブロック率=100%
レガシー認証の月次ヒット=0
Evidence（証跡）：
CAエクスポート（JSON）／変更履歴
SigninLogs（条件→結果の相関）
Named Location／認証強度設定の構成
例外台帳（失効ログ付き）
KQL（例）：
kusto// 高リスクサインインの結果サマリ（直近7日） SigninLogs | where TimeGenerated > ago(7d) | where RiskLevelDuringSignIn in ("high","medium") | summarize MFARequired=countif(ConditionalAccessStatus == "success" and AuthenticationRequirement == "multiFactorAuthentication"), Blocked=countif(ConditionalAccessStatus == "failure")
kusto// レガシー認証の遮断ヒット（直近30日） SigninLogs | where TimeGenerated > ago(30d) | where ClientAppUsed in ("Other clients","IMAP","POP","SMTP") | summarize count() by UserPrincipalName
B. PIM（Privileged Identity Management）設計
B-1. 目的
常時付与=ゼロ。特権は**JIT（Just-In-Time）**で付与し、**短時間（最大4h）**で失効
承認者必須／理由必須／チケット紐付けにより責任の所在を固定
操作ログを一元保管し、監査で10分以内に提示
B-2. 対象と分界
ディレクトリロール（全管理者ロール）
Azure リソースロール（Owner/Contributor ほか）
Privileged Access Groups（管理グループ／ミッション系）
B-3. フロー（標準）
Request：ユーザーが昇格要求（理由＋チケットID必須）
Approval：ローテーション承認者が確認（バイアス低減）
MFA：昇格前に強制
Activate：最大4hで付与（最小ロール）
Monitor：PAW（特権端末）経由のみ許可／操作ログ収集
Expire：自動失効→作業報告→レビュー
B-4. ブレークグラス
2アカウント、CA適用外（隔離ネットワーク／金庫保管）
月1回のドリルで有効性検証
署名付きアクセス手順書と開封ログを Evidence に保存
B-5. PAW（Privileged Access Workstation）
CA＋デバイス準拠で特権作業は PAW のみ許可
ローカル昇格不可／記憶媒体制限／ログ一元収集
リモート作業は短時間・記録付きで
B-6. アクセスレビュー／アラート
四半期レビュー：Eligible/Active の棚卸
高リスク昇格／長時間昇格の即時アラート
B-7. KPI／Evidence／KQL
KPI：
恒久付与の特権ロール=0
PIM昇格の承認率=100%／理由記入率=100%
特権行使の平均所要≤30分
PAW以外からの特権操作=0
Evidence：昇格履歴／承認ログ／実作業ログ（Change/Activity）／PAW準拠証跡
KQL（例）：
kusto// 特権昇格の監査（直近7日） AuditLogs | where TimeGenerated > ago(7d) | where ActivityDisplayName has_any ("Activate eligible assignment","Add member to role","Update permanent role assignment") | project TimeGenerated, InitiatedBy, ActivityDisplayName, TargetResources, Result
C. Identity Protection（Risk）設計
C-1. リスク種別と動作
SSPR＋Writebackが無いとパスワード変更でオンプレミラーと不整合が起きるため、前提化。
C-2. 検知チューニング
匿名IP／マルウェアリンクIP／Impossible Travel／不審なサインイン特性の精度向上
Named Locations（本社／DC／VPN）で誤検知低減
国別の段階制御（観察→MFA→拒否）
C-3. ハイリスク時の自動復帰フロー
ユーザーリスク=高 → サインイン許可＋パスワード変更へ誘導
完了後、リスク解消→通常CAへ復帰
DLP/MDI/MDE側で横展開が無いか自動ハント
C-4. KPI／Evidence／KQL
KPI：
高リスクサインインのMFA/ブロック適用率=100%
高ユーザーリスクのパスワード変更完了率=100%（~24h以内）
再リスク化率の月次低下
Evidence：Riskポリシー設定／リスクイベント履歴／再評価の時刻線／SSPR完了ログ
KQL（例）：
kusto// 高ユーザーリスク→変更完了の追跡（概念例） IdentityProtectionRiskEvents | where RiskLevel == "high" | join kind=leftouter (AuditLogs | where ActivityDisplayName has "Reset user password") on UserId | summarize HighRisk=count(), Remediated=countif(isnotempty(AuditLogs.TimeGenerated))
D. CAE（Continuous Access Evaluation）運用
D-1. 目的
ポリシー・リスク・口座状態の変化をトークン寿命待ちにせず即反映
例：アカウント無効化／パスワード変更／位置情報変化／CA変更 をリアルタイムに強制
D-2. 設計
テナント全体で CAE=ON
Sign-in frequency を併用（特権短期、一般は業務UXに合わせ最小）
対応アプリ（Exchange/SharePoint/Graph 等）のカバレッジ確認と例外掘り出し
D-3. テスト
代表イベントごとに反映遅延を実測（無効化→アクセス拒否までの秒数）
反映遅延が大きいワークロードはセッション制御で補完
D-4. KPI／Evidence
KPI：CAE反映遅延中央値≤2分
Evidence：イベント→拒否までのログ時刻線／CA変更の適用時刻
E. 認証強度（Authentication Strength）設計
E-1. 目的
冠ジュエルは“フィッシング耐性”のみ通過
管理者・決済者・財務・人事など高価値ユーザーは原則FIDO2/WHfB
E-2. 設計
強度プロファイルを3段階で定義（標準／強化／フィッシング耐性）
CA-APP-08 でアプリ単位に強度を要求
登録・配布：FIDO2 セキュリティキー配布／WHfB プロファイル展開
回復策：回復用手段は別チャネルで（同一端末・同一要素は不可）
E-3. 移行計画
現状調査（要素種別・登録率・利用実績）
強度マップ作成（部門×アプリ×必要強度）
段階適用（監視→強制→例外の縮退）
月次レビュー（SMS依存率の逓減）
E-4. KPI／Evidence
KPI：フィッシング耐性要素採用率（対象者）=100%、SMS依存月次-20%
Evidence：Auth Methods レポート／強度別CAの適用ログ／例外台帳
F. 運用・監査・自動化（Evidence-first）
F-1. Evidence Vault（証跡保管）
棚（Workspace/Container）→箱（Table/Folder）→索引（KQL/ID）
保持≥365日、改ざん耐性（WORM/Immutable）
Evidence Catalog：統制→KQL→保管箱→保持 の1行対応表
F-2. 監査パッケージ（テンプレ）
CA/PIM/Risk/Strength/CAE の設定エクスポート
72h初報テンプレ＋サンプル
例外台帳（期限・理由・承認・自動失効ログ）
テスト記録（机上演習／ドリル／反映遅延の実測）
F-3. 自動化（Graph/Logic Apps の例）
CA変更の差分通知（Pull→Diff→Teams）
PIM昇格の承認カード（Adaptive Cards）
高ユーザーリスクのSSPR完了監視（未完了を自動リマインド）
強度違反の検出（冠ジュエルへ弱要素での試行）
G. 30/60/90日 ロードマップ（現実解）
Day 0–30：基盤整備
CA 基礎10本／認証強度（強度定義）／CAE有効化
PIM：JIT（4h／承認／理由／チケット）＋PAW必須化、BGドリル
Identity Protection：リスクポリシー適用、Named Locations 整備
Evidence Vault 雛形／監査パック雛形
Day 31–60：自動化と可視化
SOAR（高深刻度→自動隔離→72hドラフト）
ダッシュボード（運用KPI／結果KPI／ガバナンスKPI）
冠ジュエルへフィッシング耐性強制、レガシー遮断
Day 61–90：定着と演習
机上演習／PIMドリル／反映遅延のゲームデー
例外台帳の自動失効運用、月次棚卸
監査パッケージ初版をレビュー→手直し→社内標準へ
H. ランブック抜粋（分単位）
P1：高ユーザーリスク（漏えい疑い） → 迅速復帰
T+0 : Identity Protection が High（UserRisk）を発報 Auto : CA-RISK-03 発動 → サインイン許可＋パスワード変更必須へ誘導 T+5 : 初報ドラフト自動生成（時系列・対象・暫定対策） T+10 : L2レビュー、影響範囲の確定（対象システム・越境有無） T+15 : 完了確認（SSPR/Writeback 成功）、XDRハント開始 T+30 : 経営・法務ブリーフ送付、継続監視セット
P1：特権濫用の疑い（異常昇格） → 即座の収束
T+0 : PIM 異常検知（深夜帯・非PAW・長時間要求） Auto : 承認ブロック／セッション失効／昇格イベント凍結 T+5 : 担当者と経営へ同報、アカウント確認（なりすまし判定） T+15 : 代替管理者で業務継続、証跡抽出、再発防止策
I. よくある落とし穴（回避テク）
“CA を大量に作って自己衝突”→ レイヤ設計（基礎／特権／リスク／アプリ／セッション）と優先テーブルで整流。
“Writeback 無しでリスク緩和を有効化”→ ハイブリッドはSSPR＋Writebackが前提。整わない間はブロック側に寄せる。
“PIM を入れたのに恒久付与が残る”→ 棚卸＋アクセスレビューを四半期に固定、恒久付与=0をKPIに。
“SMS 依存の固定化”→ 強度マップで対象者→FIDO2/WHfBの強制、SMSは縮退へ。
“CAE を有効化したのに遅い”→ 反映遅延の実測と非対応ワークロードの迂回（セッション制御）で補完。
J. まとめ：秒で分岐、短く付与、強く証明
CAで“誰・どこ・何で・どのリスク”を秒で分岐、CAEで即反映。
PIMで特権は短く、理由付きで付与し、PAWで面を限定。
Riskで危険は自動緩和（MFA/ブロック/パスワード変更）。
認証強度で冠ジュエルはフィッシング耐性のみ。
すべてをKPIとEvidenceで縦串にし、監査の質問に10分で答える。
Comments