mcpField
E
entra-id

entra-id

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

entra-id について

管理者向けの Microsoft Entra ID アイデンティティ管理スキルです。テナント基盤、ハイブリッド ID、認証、アプリのガバナンスを扱い、安全な基本構成と各種 ID 管理策の計画を支援します。

主な機能

  1. 01テナントと ID モデルの計画
  2. 02ハイブリッド ID 同期の設定
  3. 03フィッシング耐性のある認証計画
  4. 04アプリと同意の管理
  5. 05セルフサービスと緊急用アカウントの設定

活用シーン

  1. 01Entra Cloud Sync を使うハイブリッド ID 設計
  2. 02パスワードからパスキーへの移行計画
  3. 03緊急アクセスアカウントと監視の設定
  4. 04アプリの危険な同意の抑制

インストール

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

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-id

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

詳細

Microsoft Entra ID

Microsoft Entra ID（旧称 Azure Active Directory）は、ユーザー、デバイス、ワークロードを認証するクラウドの ID およびアクセス管理サービスです。ゼロトラストのコントロールプレーンであり、ほかのすべての Microsoft セキュリティ制御が正常な状態を前提とする基盤です。

使用する場面

ID 基盤の確立：テナント、ユーザー／グループ、認証方法、アプリの SSO、オンプレミスの Active Directory とのハイブリッド ID を設定する場合に使用します。これらはすべてクリーンな Entra ID のベースラインを前提とするため、Conditional Access、Identity Protection、PIM を設定する前にこのスキルを使用してください。

リスクベースのサインイン検出（entra-id-protection）、ポリシーの適用（conditional-access-mfa）、ジャストインタイムの管理者ロール（azure-pim）、ライフサイクルワークフロー（entra-id-governance）には、このスキルを使用しないでください。

ID の目的に合った Entra の制御を選ぶ

目的使用するもの備考
オンプレミスの AD ユーザーをクラウドに同期するEntra Cloud Sync（新規の場合に推奨）または Entra Connect SyncCloud Sync は軽量で、サーバーファームは不要です
オンプレミスへのサインインをフェデレーションするAD FS（レガシー）または Pass-Through Authentication新たに AD FS を導入するのは避け、PHS + WHfB を優先してください
パスワードを置き換えるパスキー（FIDO2） > Windows Hello for Business > Microsoft Authenticator のパスワードレス認証フィッシング耐性がある方法のみ
SaaS にシングルサインオンするEnterprise Applications（ギャラリーまたは非ギャラリー）サポートされている場合は OIDC を SAML より優先してください
セルフサービスでパスワードをリセットするクラウドへの書き戻しを有効にした SSPR（ハイブリッド）Entra ID P1 が必要です
リージョン／事業部門に限定した委任管理を行うAdministrative Units最小権限を実現するため、カスタムロールと組み合わせてください
アプリから Microsoft Graph または別の API を呼び出すApp Registration + 委任されたアクセス許可／アプリケーションのアクセス許可リスクの高いスコープには管理者の同意ワークフローを必須にしてください
MFA が機能しない場合に緊急でテナントにアクセスするBreak-glass accounts（クラウドのみのアカウントを 2 つ作成し、CA の対象から除外）ハードウェア FIDO2 のみを使用し、サインインのたびにアラートを送信します

経験則： 2026 年に Microsoft サービスへユーザー名とパスワードを入力しようとしているなら、いったん止めてください。パスキーまたは WHfB に移行しましょう。ID インシデント対応では、パスワードの使い回しとフィッシングが依然として根本原因の第 1 位です。

アプローチ

  1. テナントと ID のモデル — クラウドのみかハイブリッドかを決定します。ユーザー、グループ（割り当て型または動的）、管理単位の命名規則を定義します。既定ではテナントレベルでゲストの招待をブロックし、コラボレーションのシナリオごとに許可します。 確認方法：Get-MgPolicyAuthorizationPolicy で、既定のユーザーに対して allowedToCreateApps = false と表示されることを確認します。管理者の同意ワークフローが有効になっていることを確認します。

  2. ハイブリッド ID — 新規導入では Entra Cloud Sync を選択します（エージェントベースで軽量、切断されたフォレストにも対応）。Entra Connect Sync は、Cloud Sync がまだサポートしていない PHS + 書き戻し機能が必要な場合に限り使用します。新たな AD FS の導入は避けてください。オンプレミスへの依存関係と攻撃対象領域が増えるためです（MDI センサーが必要です）。 確認方法：Get-MgDirectoryOnPremisesSynchronization で同期が正常と表示されることを確認します。パスワードハッシュ同期が有効になっていることを確認します。

  3. 認証方法 — フィッシング耐性のある方法へ移行 — Authentication methods policy（従来の MFA + SSPR 登録ポリシーに代わるもの）で管理します。次の順に展開します：Authenticator（プッシュ通知 + 数字の照合）→ 管理対象デバイスで WHfB → 管理者向けに FIDO2 パスキー → 全体へのパスキー展開。SMS を主要な方法として無効にします。 確認方法：User Registration Details レポートで、90% を超えるユーザーがフィッシング耐性のある方法を少なくとも 1 つ登録していることを確認します。

  4. アプリケーションと同意のガバナンス — 利用可能な場合は、SSO にギャラリーを使用します。管理者の同意ワークフローを有効にし、ユーザーが高リスクのアクセス許可を付与するのではなく、申請できるようにします。Risky Apps レポートを毎月実行します。Graph の最小権限を適用し、アプリの認証情報（シークレット、証明書、フェデレーション ID）を確認します。 確認方法：承認済みリストにないアプリで、Application.ReadWrite.All または Directory.ReadWrite.All に同意済みのものがないことを確認します。

  5. セルフサービスとライフサイクル — ハイブリッドユーザー向けに書き戻しを伴う SSPR を有効にします。My Account / My Apps を設定します。属性に基づくメンバーシップ（部署、国、employeeType）には動的グループを使用します。

  6. 緊急アクセスアカウント — クラウド専用の緊急アクセスアカウントを2 つ作成します。すべての Conditional Access ポリシーから除外します。別々の場所に物理的に保管した FIDO2 ハードウェアキーのみで認証します。Sentinel でサインインのたびにアラートを出します。 確認方法：毎月、それぞれの緊急アクセスアカウントからのサインインテストを実施します。5 分以内にアラートが発報することを確認します。

  7. レガシー認証と脆弱な方法をブロック — Conditional Access（別スキル）を使用して、レガシー認証プロトコル（POP、IMAP、SMTP AUTH、基本認証）をブロックします。SMS / 音声を主要な MFA 方法として無効にします。

ガードレール

  • 緊急アクセスアカウントは極めて重要です。 クラウド専用のアカウントを 2 つ用意し、FIDO2 ハードウェアキーを使用し、すべての CA ポリシーから除外して、サインインのたびに監視します。毎月テストしてください。これを省略すると、CA の設定ミスでテナントにアクセスできなくなる可能性があります。
  • 新たな AD FS の導入は避けてください。 オンプレミスの ID への依存関係となり、攻撃対象領域と保守の負担が増えます。PHS + WHfB で、ほぼすべての要件を満たせます。
  • レガシー認証をブロックしてください。 POP、IMAP、SMTP AUTH、基本認証は MFA を回避します。Conditional Access でブロックし、その後 30 日間サインインログを監視して、まだ使用しているものがないか確認します。
  • アプリの同意を管理してください。 不正な同意の付与は、パスワードのリセット後も攻撃者が侵入状態を維持する手段です。管理者の同意ワークフローを有効にし、Risky Apps レポートを確認してください。
  • 管理者アカウントへの割り当て手段として、グループベースのライセンス割り当てだけを使用しないでください。 グループの同期が停止すると、管理者はライセンスとアクセス権を失います。緊急アクセス用アカウントと tier-0 管理者には直接割り当ててください。
  • 新規構築では Connect Sync より Cloud Sync を優先してください。 より軽量で、サーバーファームが不要であり、障害要因も少なくなります。

よくあるアンチパターン

  • 「MFA に SMS を使っています。これで十分です」 - SMS はフィッシングされやすく、SIM スワップの危険もあります。回復要素としてのみ扱い、決して主要な認証要素として使用しないでください。
  • 「Keepass に緊急用アカウントを 1 つだけ用意しています」 - 単一障害点となり、監査もできません。管理者が分かれたハードウェアキー対応アカウントを 2 つ用意してください。
  • 「以前からそうしてきたので、AD FS によるフェデレーションサインインを使います」 - 2026 年においては、コストとリスクが増加します。特定のフェデレーション要件がない限り、PHS ＋ 条件付きアクセスに移行してください。
  • 「すべてのアクセス許可について、ユーザーによるアプリの同意を許可します」 - テナントにリスクの高い同意済みアプリが増えてしまいます。管理者の同意ワークフローを有効にしてください。
  • 「Administrative Units は気にせず、グローバル管理者を使えばよい」 - 職務分掌が損なわれ、RBAC を迂回することになります。ヘルプデスクと地域管理者の権限を AU に限定してください。
  • 「セキュリティの既定値を無効にしても、1 週間は条件付きアクセスを設定しなくてよい」 - その間、テナントが無防備になります。既定値を無効にする前に、CA ポリシーを有効にしてください。

プロンプトの例

  • Entra Cloud Sync とパスワードハッシュ同期を使用したハイブリッド ID モデルを設計してください。
  • 5,000 人のユーザーをパスワードからパスキーに移行する計画を立ててください。
  • Entra テナントの緊急用アカウントと監視アラートを構成してください。
  • ユーザーを SMS MFA から移行するには、どのような移行手順が必要ですか？
  • Entra ID テナントでの不正な同意の付与を防止してください。
  • ハイブリッド環境向けに、書き戻しを有効にした SSPR を構成してください。
  • 委任管理では、Administrative Units とカスタムロールをどのように使い分けるべきですか？

Microsoft Learn

コメント

Markdown 対応