NIST×Entra ID

目的は、NIST SP 800‑63（AAL/IAL/FAL）・SP 800‑53（AC/IA/AU 等）・CSFの要求を、Entra ID の具体機能（MFA／Passwordless／Conditional Access／Identity Protection／PIM／ログ連携）で確実に満たすこと。手戻りが出やすい箇所（例：例外・ブレークグラス・レガシー認証・来訪者・サービスID）も最初から運用を含めて設計します。

0) 5分で全体像

• スコープ分割：一般ユーザー／特権ユーザー／外部（来訪者）／サービスID（非対話）

• 目標強度：

  • 一般：AAL2（Authenticator App、WHfB、FIDO2のいずれか）

  • 特権：AAL3相当（フィッシング耐性）（FIDO2 または WHfB 強制）

  • フェデレーション：FAL2 以上（署名＋推奨で暗号化）

• ゼロトラスト：条件付きアクセス（CA）＋デバイス準拠（Intune）＋CAE＋Identity Protection

• 運用基準：PIM（JIT/承認/MFA）／ログ（Sentinel）／レポート（KPI/監査パック）

1) NIST ⇄ Entra ID マッピング（実務クロスウォーク）

1-1. AAL/IAL/FAL と機能対応（抜粋）

NIST	代表要件	Entra ID/周辺機能	実装ポイント
AAL2	MFA必須（2要素 or 多要素認証器）	CA + Authenticator/WHfB/TOTP	SMS/音声は縮退用に限定。Authenticator/WHfBを主経路に。
AAL3	ハードウェア/フィッシング耐性	FIDO2 セキュリティキー or WHfB（TPM）	特権アカウントはFIDO2強制。バックアップ方法（複数キー）必須。
IAL2–3	厳格な本人確認	Entra Verified ID／B2C + KYC 連携	採用時や委託契約時のeKYC／証明提示ワークフローで証跡化。
FAL2–3	署名・暗号化	OIDC/SAML（署名鍵はKV/HSM）	トークン署名鍵ローテ／メタデータ監視／暗号化対応の検討。

注：AAL・IAL・FALはリスク／規制／ユーザー層で使い分け。AAL3を全社強制するのではなく、特権＆高リスク業務に集中的に適用。

1-2. SP 800‑53 / CSF と Entra 対応（主要）

• AC-2/6（アカウント/最小権限）：RBAC／PIM（JIT・承認・MFA）／アクセスレビュー

• IA-2（認証）：MFA／Passwordless（FIDO2/WHfB）

• AU-2/6/12（監査）：サインイン/監査ログ → Sentinel 相関分析

• SC-7/13（通信/セッション）：CA（デバイス・ロケーション）／CAE／セッション制御

• IR-4/6（インシデント）：リスクベース自動ブロック（Identity Protection）＋ Playbook（自動封じ込め）

• CSF PR.AC/DE.CM/RS.CO：CA／継続監視／法務・広報連携の報告フロー

2) ベースライン・ポリシー（Conditional Access）設計書

ロールアウト順：①Report‑Only → ②限定スコープ（パイロット）→ ③全社展開（例外管理/手戻り窓口を先に用意）

2-1. 最低限の 10 本（推奨既定）

1. Block Legacy Authentication（レガシー完全遮断）

2. Global Require MFA（全ユーザーMFA）

3. Admin Require Phishing‑Resistant MFA（特権はFIDO2/WHfB限定）

4. From Non‑Trusted Locations = Block/Require MFA（国/IP ベース）

5. Require Compliant/Hybrid‑Joined Device for Sensitive Apps（Intune準拠 or ハイブリッド）

6. Grant Controls = MFA OR Compliant Device（段階導入の安全弁）

7. Session Controls（Sign‑in frequency＝12h、Persistent Session＝Off、CA 連続評価=On）

8. App‑Based Controls（財務・人事・CUIアプリは厳格／一般SaaSはMFA要）

9. Guest/External Users（B2BはMFA必須＋条件拡張、招待リンク期限）

10. Break‑Glass Exclusion + 監査（2アカウント・CA除外・監視・保管手順）

2-2. CA ポリシー JSON（Graph API 例：2本）

置換：<GUID>（ユーザー/グループ/アプリ）／<namedLocationId>／<countryNamedLocationId>

(A) Block Legacy Authentication

{
  "displayName": "CA-001 Block Legacy Authentication",
  "state": "enabled",
  "conditions": {
    "users": { "includeUsers": ["All"] },
    "clientAppTypes": [ "exchangeActiveSync", "other" ]  // レガシー系
  },
  "grantControls": { "operator": "OR", "builtInControls": [ "block" ] }
}

(B) Require MFA (All Cloud Apps, exclude break‑glass)

{
  "displayName": "CA-002 Require MFA for All Users",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeUsers": ["All"],
      "excludeUsers": [ "<breakGlassUserGuid1>", "<breakGlassUserGuid2>" ]
    },
    "applications": { "includeApplications": [ "All" ] },
    "clientAppTypes": [ "browser", "mobileAppsAndDesktopClients" ]
  },
  "grantControls": { "operator": "OR", "builtInControls": [ "mfa" ] },
  "sessionControls": {
    "signInFrequency": { "isEnabled": true, "frequencyInterval": "hours", "value": 12 },
    "persistentBrowser": { "mode": "never" }
  }
}

管理者向け（AAL3相当）は、grantControls.customAuthenticationFactors/fido2 を要件化（運用上はFIDO2登録の完了と予備キー配布まで含めてGo判定）。

3) 身元確認（IAL）と外部連携（FAL）

3-1. IAL の実装オプション

• 採用・入館・委託契約での KYC：Entra Verified ID（検証可能な資格情報）＋ eKYC ベンダ連携

• 社内アカウント発行：人事システム → ID プロビジョニング（SCIM/HR 連携）→ JML（Joiner‑Mover‑Leaver） 自動化

• 証跡：発行根拠、発行者、本人同一性確認の手順・ログを保全

3-2. FAL の実装

• OIDC/SAML フェデレーション：署名必須・暗号化推奨、KeyVault/HSMで証明書保護、定期ローテ

• 連携先のトークン有効期限／クレーム最小化、SCIMで権限の過剰付与防止

4) 特権 ID 管理（PIM）ベースライン

項目	推奨値
対象ロール	Global Admin, Privileged Role Admin, Security Admin, User Access Admin, Subscription Owner 等
付与方式	Eligible（常時は非アクティブ）
有効時間	1–4 時間（業務に応じ最短）
追加要件	承認者 1 名以上／MFA 必須／理由記入／チケット番号
通知	アクティベーション時・割当変更時・失効時
監査	週次レビュー（異常アクティベーション）／四半期レビュー（継続必要性）

運用要点：恒久付与をゼロに。ベンダー/監査用は専用グループ＋時間制。ブレークグラスはクラウド専用・CA適用外・厳格監視。

5) MFA/Passwordless 戦略（AAL2→AAL3）

1. 第1段階（全社MFA/AAL2）：Authenticator Push/TOTP、SMSは縮退

2. 第2段階（特権AAL3）：FIDO2 セキュリティキー必須（管理者/高リスクアプリ）

3. 第3段階（広域AAL3/フィッシング耐性）：WHfB + FIDO2 の二経路準備（キー紛失時の可用性）

4. 端末条件：Intune 準拠、TPM 必須、生体は偽装耐性を確認

6) デバイス & セッション

• Intune 準拠（暗号化・AV・OSパッチ・セキュアブート）＋ 条件付きアクセスで “準拠 or ブロック/制限”

• CAE（Continuous Access Evaluation）：資格情報変更・特権昇格で即セッション再評価

• Sign‑in Frequency：12h（機密は4h）／Persistent Sessionは既定で無効

7) 外部（B2B）／来訪者管理

• 招待はライフサイクル管理（有効期限・自動失効）／来訪者にもMFA

• 高機密テナント：ゲストのダウンロード制限（MCAS/Defender for Cloud Apps）、セッション制御でプレビューのみ

8) サービスID・自動化（Workload Identities）

• Managed Identity（MI）を最優先。アプリ登録の秘密は発行禁止を原則（例外は期限・ローテ自動化）

• 権限は最小化（Graph/ARM の最小スコープ）＋ 認可の棚卸（四半期）

9) モニタリング／検知（Sentinel + Identity Protection）

9-1. 重要アラート（推奨ルール）

• Risky Users / Risky Sign‑ins（High＝自動ブロック／パスワードリセット）

• Impossible Travel／匿名プロキシ／旧認証サインイン

• 特権ロール割当／PIM アクティベーション

• CAポリシー変更／無効化（コンプライアンス事故の温床）

9-2. KQL スニペット（抜粋）

特権ロール付与検知

AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName has_any ("Add eligible member", "Add member to role")
| extend Actor = tostring(InitiatedBy.user.displayName)
| extend Target = tostring(TargetResources[0].displayName)
| project TimeGenerated, Actor, Target, Result, OperationName

レガシー認証の残留

SigninLogs
| where TimeGenerated > ago(7d)
| where ClientAppUsed in ("IMAP","POP","SMTP","Exchange ActiveSync","Other clients")
| summarize cnt=count() by UserPrincipalName, ClientAppUsed

ブレークグラス利用

let BG = dynamic(["userGuid1","userGuid2"]);
SigninLogs
| where TimeGenerated > ago(30d)
| where UserId in (BG)
| project TimeGenerated, UserPrincipalName, IPAddress, Location, ResultType

自動封じ込め：Playbook（Logic Apps）でDisable Account／ブロックIP／チケット作成を自動化。高リスクのみ承認ステップを挟む。

10) 例外・ブレークグラス・BCP

項目	ルール
ブレークグラス	クラウド専用 2 アカウント／CA除外／超長ランダムPW／物理金庫保管／毎月サインイン試験
例外申請	期限付（<=30日）・代替統制・責任者承認・自動失効
監査	例外台帳・失効監視・月次レビュー

11) KPI / SLO（運用で“効き目”を測る）

• MFA 適用率（全社 ≥ 98%、特権 100%）

• AAL3 適用率（特権）（FIDO2/WHfB ≥ 95%）

• レガシー認証サインイン（0件）

• 来訪者の休眠率（>90日未使用）（≤ 2% → 自動失効）

• MTTD/MTTR（30分/4時間、重大度でSLA分け）

• PIM 常時付与ゼロ／承認漏れゼロ

12) ロールアウト計画（手戻り防止の順番）

1. 資産・ID 現況把握（全ユーザー分類／特権棚卸／来訪者台帳）

2. Report‑Only で CA を全て影響評価（2–4 週）

3. レガシー遮断 → 全社MFA → 管理者AAL3 の順で拡張

4. デバイス準拠（重要アプリ → 全社）／ゲスト方針適用

5. PIM／Identity Protection 有効化、Playbook 自動化

6. KPI ダッシュボードを経営・監査向けに定着

13) 監査パック（エビデンス束：例）

• CA エクスポート（ポリシー一覧・ステート・例外）

• PIM 設定／アクティベーション・ログ

• MFA/Passwordless 登録状況レポート（AAL レベル推定）

• Sentinel ルール定義・アラート統計

• 例外台帳／失効証跡

• NIST SP 800‑53 / CSF 対応マトリクス（AC/IA/AU/IR）

監査対応は「構成で守る、証跡で証明」。構成（ポリシー）を資産化し、ログと台帳で継続性を担保。

14) 参考・補助アセット（貼り付け可）

14-1. 特権向け CA（FIDO2/WHfB 強制）・概念 JSON

{
  "displayName": "CA-Admin Require Phishing-Resistant MFA",
  "state": "enabled",
  "conditions": {
    "users": { "includeGroups": [ "<PrivilegedRoleGroupGuid>" ] },
    "applications": { "includeApplications": [ "All" ] }
  },
  "grantControls": {
    "operator": "AND",
    "authenticationStrength": { "id": "c960c8e5-xxxx-xxxx-xxxx-xxxxxxxx" } // “Phishing-resistant MFA”強度（環境で選択）
  }
}

14-2. Identity Protection（リスクベース制御：方針）

• User risk policy：High＝パスワード変更＋再登録

• Sign‑in risk policy：Medium/High＝MFA 必須 or ブロック

• 検知の訓練：旅程・VPN 利用ガイド／開発者向け分離ブラウザ

15) よくある落とし穴（先回り対策）

• CAの自縄自縛：ロールアウトはReport‑Only → 段階本番。ブレークグラスは先に準備、月次動作確認。

• SMS依存：Authenticator/WHfB/FIDO2へ移行（紛失時の救済・多経路登録）。

• 来訪者の放置：期限・最終サインインで自動失効（Access Reviews）。

• サービスIDの秘密管理：Managed Identity最優先、どうしても秘密が要る場合は短寿命＋自動ローテ。

• 監査時の実効性不足：定義書だけでなく構成エクスポート＋ログを束ねておく。

16) ライセンス指針（費用見通し）

• P1：条件付きアクセス／MFA／基本レポート

• P2：PIM／Identity Protection／Access Reviews（本稿の“成熟運用”はP2前提）

• FIDO2/WHfB：機能はテナント標準、キー端末費用と配布オペレーションを別途見積

17) まとめ（実務要点）

• AAL2 を全社、AAL3 を特権へ集中—NIST 800‑63 を“強さの配分”に使う

• CA×Intune×CAEでゼロトラストを日常運用へ

• PIM と Identity Protectionで“人起因リスク”を JIT/自動化で抑制

• Sentinel/KQLで“見える化”し、KPI で経営と監査に説明可能にする

付録：実装チェックリスト（抜粋）

•  CA-001 レガシー遮断（Report‑Only→有効化）

•  CA-002 全社MFA（ブレークグラス除外）

•  CA-Admin フィッシング耐性強度（FIDO2/WHfB）

•  Identity Protection（ユーザー/サインイン リスク方針）

•  PIM（対象ロール／時間制／承認／通知）

•  Intune 準拠ポリシー／デバイス制御

•  ゲスト方針（MFA・有効期限・セッション制限）

•  Workload Identity（MI 優先・秘密禁止）

•  Sentinel ルール（特権／CA変更／旧認証／Impossible Travel）

•  KPI ダッシュボード＆監査パック

スターターキット

セット内容（同梱物の要点）

1) 条件付きアクセス（CA）ポリシー群（Graph 用 JSON）

NIST の PR.AC / AC, IA コントロールに整合し、Report‑Only → 段階適用 → 本番の移行前提で設計済み。プレースホルダは config/variables.example.json を variables.json に複製して GUID を埋めれば、scripts/deploy_ca_policies.ps1 で一括適用できます（既存名は自動で更新）。

• CA-001-Block-Legacy.json：レガシー認証遮断（EAS/IMAP/POP/SMTP/Other）

• CA-002-Require-MFA-All.json：全ユーザー MFA（Break‑Glass 除外、サインイン頻度/永続ブラウザ制御）

• CA-003-Admins-PhishingResistant.json：特権ロールに Phishing‑resistant（FIDO2/WHfB）強制

• CA-004-NonTrusted-Access.json：非信頼ロケーションからは MFA / ブロック

• CA-005-Require-Compliant-Device.json：機密アプリに準拠端末/ハイブリッド参加必須

• CA-006-Guests-MFA-Expiry.json：ゲストは MFA 前提（招待管理と併用を想定）

• CA-007-Session-Controls.json：サインイン頻度/永続ブラウザの全社既定

いずれも Break‑Glass 2 アカウント除外を前提化。variables.json に GUID を設定します。

2) Sentinel 向け KQL & スケジュール ルール（Scheduled）

DE.CM / AU 対応。監査証跡・異常イベントを即時可視化。sentinel_kql/ に KQL、sentinel_rules/ に Scheduled ルール JSON（最小構成）を同梱。

• risky_users.kql / risky_signins.kql：リスクユーザー/サインイン（Identity Protection 連携前提）

• impossible_travel.kql：簡易インポッシブルトラベル検出

• legacy_auth_clients.kql：レガシークライアント残存の棚卸し（7日）

• pim_role_changes.kql：PIM 活性/割当の監査

• ca_policy_changes.kql：CA ポリシー作成/変更/削除の監査

• breakglass_signin.kql：Break‑Glass 利用監査（GUID 置換）

Scheduled ルール：

• SR-001-RiskyUsers.json（High）

• SR-002-ImpossibleTravel.json（Medium）

• SR-003-CAChanges.json（Medium）

Playbook 紐付け前に、まずはアラート観測 → 誤検知是正 → 自動化段階へ進める方針を同梱のロールアウト計画に記載。

3) SOAR（Logic Apps）プレイブック（スケルトン）

RS.MI / IR 対応。Managed Identity 前提の軽量スケルトンを同梱。

• Disable-User-HighRisk.logicapp.json：アラート入力 → Graph PATCH /users/{upn} → accountEnabled:false

• Create-Ticket-Webhook.logicapp.json：任意の ITSM Webhook にインシデント起票

本番では「手動承認（Approvals）」や「抑止→通知→確認→遮断」の段階化、サービス影響回避のための抑止対象のスコープ最小化をご検討ください。

4) 展開順の計画・初期調整（脆弱ポイント是正）・バックアウト

rollout/ ディレクトリに計画・手順を収録。

• rollout_plan.md：**Report‑Only → 第1弾（レガシ遮断/MFA）→ 第2弾（特権 AAL3 / 非信頼ロケーション / 準拠端末）**の段階展開

• backout_plan.md：サービス影響時の即時退避手順（Break‑Glass 想定、対象限定の停止）

• change_checklist.md：切替前の必須確認（例外洗い出し、代替統制、関係者合意、ロールバック確認）

初期調整の要点（脆弱ポイント）は計画書に明記：

• Break‑Glass：2アカウント、CA 除外、封緘保管、月次サインイン試験を必須化

• レガシー認証：要因別（旧 MFP/ジョブ/外部連携）に代替策 or 期限付例外

• ゲスト：招待/有効期限/ダウンロード制御/監査（MIP/DLP と併用）

• 自動化/サービス ID：ワークロード ID 化・証明書/秘密管理（Key Vault）・最小権限

5) 教育資材（運用ルール／KPI）

education/ に現場説明用の軽量ドキュメントを同梱。

• one_pager_mfa_passwordless.md：ユーザー向け 1 ページ

• admin_runbook_breakglass.md：Break‑Glass 運用手順（毎月の動作確認を明文化）

• kpi_dashboard.md：MFA 適用率、特権 AAL3、レガシー認証 0 件、MTTD/MTTR などの KPI 指標例

• faq.md：MFA/SMS/予備キー/ゲスト制御など標準 QA

6) 命名・ID 置換・自動展開スクリプト

• config/naming_conventions.md：**CA / Playbook / SR / NL（Named Location）**の命名規約（監査タグ例含む）

• config/id_lookup.ps1：Named Location / 認証強度ポリシー / グループの ID 取得（Graph）

• config/variables.example.json：GUID などプレースホルダ定義

• scripts/deploy_ca_policies.ps1：displayName をキーに 作成/更新（Report‑Only 運用も容易）

注意：Graph の権限同意が必要です（Policy.ReadWrite.ConditionalAccess など）。検証テナントでの乾式展開を推奨。

すぐに始める（最短手順）

1. Zip を展開 → config/variables.example.json を variables.json にリネームして GUID/ID を入力

   • Break‑Glass 2 ユーザー GUID

   • 特権ロール用グループ ID（PIM 対象）

   • Named Location（信頼済/ブロック国）ID

   • 認証強度（Phishing‑resistant）ポリシー ID

2. 準備

   • Break‑Glass 除外を 全 CA で確認（CA-002/004/…）

   • rollout/change_checklist.md を全関係者で合意

3. Report‑Only 展開

   • scripts/deploy_ca_policies.ps1 -VariablesPath .\config\variables.json

   • sentinel_kql/legacy_auth_clients.kql 等で影響把握

4. 本番化（第1弾）

   • CA-001（レガシ遮断）→ CA-002（全社 MFA）を 狭いスコープで先行 → 段階拡大

   • sentinel_rules/ をインポートして観測開始（Playbook は通知中心で試運転）

5. 本番化（第2弾）

   • CA-003（特権 AAL3、PIM 併用）

   • CA-004（非信頼ロケーション制御）、CA-005（準拠端末必須：機密アプリ）

6. 最適化

   • 誤検知/過検知チューニング、例外の期限つき化、ダッシュボードの KPI 運用

実運用の注意（必読）

• ロックアウト予防：Break‑Glass の月次試験、CA 変更は常に Report‑Only → 限定適用 → 全社 の順

• ゲスト/自動化：例外は期限/代替統制/監査ログをセットで（棚置き例外は禁止）

• 監査証跡：ca_policy_changes.kql・pim_role_changes.kql を定例レビュー、責任者承認の痕跡を残す

• 人の手順：backout_plan.md をヘルプデスクに周知、一次対応の退避手順を標準化

追加ご要望（カスタマイズ）

• テナント現況に合わせた置換自動化（ID 収集→変数→デプロイの一括化）

• 認証強度（Authentication Strength）のポリシー作成と CA 参照の自動連携

• 業務アプリ別のスコープ設計（例：高リスク部門先行、本社/海外拠点差分）

• Sentinel ルール/Playbook の ITSM・EDR 連携（ServiceNow/JSM、Defender スイート）

• 教育資材の社内ポータル化、ドリル（フィッシング耐性演習）同梱

必要であれば、現テナントの棚卸し → 変数解決 → 段階展開 → 伴走運用まで当方で一気通貫対応します。（評価基準：Secure Score +15〜25pt、レガシー認証 0、特権 AAL3=≥95%、MTTD<30分/MTTR<4時間）

参考

• 同梱ドキュメント：README.md（全体の使い方）／rollout/*.md（導入計画）／education/*.md（教育資材）

• すべて プレースホルダ（PLACEHOLDER） を置換すれば即時適用できるよう最小限の依存関係で構成しています。