mcpField
C
conditional-access-mfa

conditional-access-mfa

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

conditional-access-mfa について

conditional-access-mfaは、Entraの条件付きアクセスとMFAポリシーを計画・展開するスキルです。ID管理者向けに、ベースライン、安全なテスト、緊急用アカウントの除外、ポリシー管理を案内します。

主な機能

  1. 016つのベースラインポリシーの計画
  2. 02作成前のサインイン状況の棚卸し
  3. 03フィッシング耐性のある認証強度の利用
  4. 04レポート専用モードとWhat Ifによるテスト
  5. 05緊急用アカウントの除外とポリシー台帳の管理

活用シーン

  1. 01Entraテナントの基本アクセス制御の設定
  2. 02管理者ロールに強固なMFAを要求
  3. 03レガシー認証を使うアプリの特定
  4. 04準拠デバイス要件の安全な展開

インストール

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

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill conditional-access-mfa

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

詳細

条件付きアクセスと MFA

条件付きアクセス(CA)は、Entra のゼロトラストポリシーエンジンです。ユーザー/ グループ、デバイスの状態、場所、アプリケーション、サインインリスクなどのシグナルを評価し、許可、ブロック、または制御付きの許可(MFA、準拠デバイス、セッション制御)を適用します。CA を使わない MFA はまれです。この 2 つは連携して設計されています。

使用する場面

Microsoft 365 および Entra と統合されたあらゆるアプリで、適応型の ID 中心のアクセス制御を適用する場合に使用します。このスキルは、ベースラインポリシーセットの適用や新しいポリシーの展開に使用してください。

このスキルを使用しない場面:リスク検出(entra-id-protection)、ジャストインタイムの管理者権限昇格(azure-pim)、アプリ側の OAuth 権限(entra-id)。

ベースラインの 6 つのポリシー

2026 年には、すべての Entra テナントで、次の 6 つのポリシーをこの順序で最低限設定する必要があります。

#ポリシースコープ許可の制御
1管理者に MFA を要求すべての Entra 管理者ロールMFA + フィッシング耐性のある認証強度
2すべてのユーザーに MFA を要求すべてのユーザー(緊急アクセス用アカウントを除く)MFA
3レガシ認証をブロックすべてのユーザーブロック
4M365 に準拠デバイスを要求すべてのユーザー、M365 アプリ準拠またはハイブリッド参加
5リスクベース CA - サインインリスクが高い場合すべてのユーザーMFA(EID P2 が必要)
6リスクベース CA - ユーザーリスクが高い場合すべてのユーザー安全なパスワード変更(EID P2 が必要)

経験則: テナントに 6 つすべてが設定されていない場合、2026 年の Microsoft ベースラインを満たしていません。 ポリシー 5 と 6 には Entra ID P2 が必要です。必要に応じて、E3 ではリスクベースの認証強度で代替してください。

進め方

  1. ポリシーを作成する前にインベントリを確認する — 現状を把握するため、現在のサインインログをエクスポートします。 アプリごとの MFA 使用状況、レガシ認証の量、デバイスの準拠状況、使用中の名前付き場所を確認します。 想定したトラフィックパターンに基づいてポリシーを作成しないでください。 確認方法:Sign-ins ブックに、アプリごとの MFA の割合とレガシ認証の件数が表示されます。

  2. 「MFA を要求」だけでなく、認証強度を使用する — 認証強度を使うと、重要なスコープに対してフィッシング耐性のある方法(FIDO2 パスキー、Windows Hello for Business、証明書ベース)を要求できます。一般的な「MFA を要求」では SMS も許可されるため、依然としてフィッシングに脆弱です。 確認方法:管理者ポリシーの許可制御で、汎用 MFA ではなく、組み込みのフィッシング耐性 MFA認証強度を使用します。

  3. 必ず最初にレポート専用モードで運用する — 新しいポリシーは、少なくとも 7 日間、レポート専用モードで運用します。 What If を使って、特定のユーザーとアプリのシナリオをモデル化します。レポート専用の結果に予期しない点がないことを確認してから、オンに切り替えます。 確認方法:ポリシーのレポート専用の影響に、評価されたサインインが 0 件を超えて表示されます(それ以外の場合、ポリシーのスコープが不適切で、何にも適用されていません)。

  4. すべてのポリシーで緊急アクセス用アカウントを除外する — クラウド専用の緊急用アカウントを 2 つ用意し、すべてのポリシーから除外して、サインインのたびに監視します。除外リストを文書化し、毎月見直します。 確認方法:Conditional Access Insights workbook に、すべての適用ポリシーで緊急アクセス用アカウントが除外されていることが表示されます。

  5. 必要に応じてセッション制御を設定する — 機密性の高いアプリにはサインイン頻度を設定し、共有デバイスではブラウザーの永続化をブロックし、Exchange/SharePoint にはアプリで適用する制限を設定します。セッション中の監視には Conditional Access App Control を使用します。

  6. ポリシー台帳 — ポリシーの目的、所有者、除外対象、最終レビュー日を記録した台帳(CSV または Sentinel ウォッチリスト)を維持します。これがないと、CA ポリシーの設定は徐々に実態とずれていきます。

ガードレール

  • まずレポート専用モードで確認せずに、すべてのユーザーに新しいポリシーを適用しないでください。 本番環境の CA インシデントのほとんどは、この単一のミスが原因です。
  • 2 つの緊急アクセスアカウントをすべてのポリシーから除外し、サインインのたびに監視してください。 これを怠ると、CA の設定ミスでテナントから締め出される可能性があります。
  • レガシー認証をブロックし、その後 30 日間サインインを監視してください。 まだレガシー認証を使用しているアプリもあります。苦情が届く前に、それらを特定して修正してください。
  • 管理者には、一般的な MFA ではなくフィッシング耐性のある認証強度を設定してください。 グローバル管理者に SMS ベースの MFA を使うのは、2026 年にパスワードを付箋に書いて貼っておくのと同じです。
  • ポリシーを 30 件以上積み重ねないでください。 評価のたびに遅延が発生します。条件が重複するポリシーを統合し、有効なポリシーを 20 件未満に抑えてください。
  • 同僚のアカウントではなく、What If で変更をテストしてください。 What If では実際にサインインせずにポリシーエンジンに対してテストできます。

よくあるアンチパターン

  • 「新しいポリシーをすべてのユーザーに直接オンにする」 - アカウントから締め出されます。最低 7 日間はレポート専用モードにしてください。
  • 「MFA を要求する = フィッシング耐性がある」 - SMS も許可されます。認証強度を使用してください。
  • 「パスワードマネージャーに緊急アクセスアカウントを 1 つだけ保存する」 - 単一障害点になります。ハードウェアキーを使うアカウントを 2 つ用意し、管理を分けてください。
  • 「除外は安全でないので設定しない」 - 緊急アクセスアカウントを除外しないと、CA の設定ミスから復旧できません。
  • 「名前付きの場所でロシア/中国をすべてブロックする」 - 攻撃者は許可されている国のプロキシを使用します。代わりにリスクシグナルとデバイスのコンプライアンスを使用してください。
  • 「ポリシー台帳なしで CA ポリシーを本番環境に適用する」 - 6 か月後には、誰もポリシー 17 が存在する理由を把握していません。

プロンプトの例

  • 新しい Entra テナント向けに、ベースラインとなる 6 つの Conditional Access ポリシーを作成してください。
  • すべての Entra 管理者ロールに、フィッシング耐性のある MFA(FIDO2/WHfB)を要求してください。
  • レガシー認証をブロックし、まだそれを使用しているアプリを報告してください。
  • 新しい「Exchange に準拠デバイスを要求する」ポリシーを、レポート専用モードで安全に展開してください。
  • ユーザーが何度も MFA を求められるのはなぜですか。サインイン頻度を調整してください。
  • すべての CA ポリシーから緊急アクセスアカウントを除外し、それらのサインインをアラートしてください。

Microsoft Learn

コメント