条件付きアクセスと PIM は実際にどのように攻撃を防ぐのか

パスワードポリシーはguessing攻撃を止める。盗まれたセッショントークン、フィッシングされた MFA プロンプト、あるいは 2 年間にわたって Global Administrator 権限を持ったまま放置されているスタンディング管理者アカウントには何もしない。Conditional Access と Privileged Identity Management（PIM）は、Azure AD / Entra ID のこれらのギャップに実際に対処する 2 つのコントロールであり、一緒に機能するときに最も効果的です。

Conditional Access が内部で何をしているのか

Conditional Access はサインイン時に評価される if-this-then-that エンジンです。「if」側（シグナル）にはユーザー/グループメンバーシップ、デバイスコンプライアンス状態、ネットワークロケーション、サインインリスク（Identity Protection から）、アクセスされるアプリケーション、クライアントアプリタイプ（ブラウザ対レガシープロトコル）が含まれます。「then」側（コントロール）には MFA を要求、コンプライアンスデバイスを要求、承認されたクライアントアプリを要求、アクセスを完全にブロック、または利用規約の同意を要求することが含まれます。

ほぼすべてのテナントで重要なポリシーは レガシー認証をブロック することです。POP、IMAP、古い SMTP などのプロトコルは最新の MFA チャレンジをサポートしていないため、credential-stuffing ツールが最初に試すものです。ブロックする前に「Client App = Other clients」でフィルタリングされたサインインログをチェックしてください — しばしば 1 つの古いスキャナーあるいは古い複合機が基本認証で認証しているのが見つかります。

初日から持つ価値がある 2 番目のもの：すべてのユーザーに MFA を要求 し、break-glass アカウントのみの除外グループでスコープを設定すること。MFA を「管理者だけ」にスコープしないでください。侵害された標準ユーザーアカウントは、権限昇格が始まる前に攻撃者が最初の足がかりを得る方法です。

サインインリスク対ユーザーリスク — 異なるシグナル、異なる対応

Identity Protection（Entra ID P2 の一部）は 2 つの個別のリスクスコアを生成し、それらを混同するのは簡単です：

• サインインリスク — この特定の認証試行は異常に見える（不可能な移動、匿名 IP、見慣れないサインインプロパティ）。
• ユーザーリスク — このアカウントは ID 自体に関連する理由でフラグが立てられている（漏洩認証情報がブリーチコーパスで見つかった、確認された侵害活動）。

サインインリスクに対応する Conditional Access ポリシーは通常 MFA でチャレンジすべきです — 本当のユーザーがチャレンジを完了できれば、通す。ユーザーリスクに対応するポリシーはパスワードリセットを強制すべきです。認証情報自体が既に焼かれている場合、MFA だけでは役に立たないため。

スタンディング管理者アクセスがより大きな問題である理由

たとえ隙のない Conditional Access があっても、Global Administrator を永続的に保持するアカウントはディレクトリに見え見えで置かれているターゲットです。これを侵害した誰もが、追加の手順なしで完全なテナントコントロールを継承します。PIM は「永続」の部分を削除します。

PIM により、管理者ロールは有効ではなく 適格 として割り当てられます。ユーザーはロールを明示的にアクティブ化する必要があり、これは必須の正当性、オプションの承認ワークフロー、MFA 再確認、および時間制限されたウィンドウ — 通常 1 ~ 8 時間 — をトリガーします。その後、ロールは自動的に非アクティブ化されます。アカウント所有者を含め、誰も、アクティブに使用していない限り、スタンディング Global Admin を持ちません。

実際に使用可能な最小 PIM 構成

• Helpdesk Administrator より上のすべてのロール：永続ではなく適格。
• Global Administrator と Privileged Role Administrator：単なる自己アクティブ化ではなく、別の管理者の承認が必要。
• アクティブ化 MFA 必須、例外なし。
• 最大アクティブ化期間 4 時間により、本当に別の作業セッションのために人々に再アクティブ化を強制し、これはより清潔な監査ログも生成する。
• すべての適格割り当てに対して 90 日ごとのアクセスレビュー — アカウントは 1 つのプロジェクトのために追加され、その後削除されない。

チームがこれを間違える場所

最も一般的な失敗はポリシー設計ではなく、除外リストです。「MFA をサポートしていないため、これらのユーザーを除外する」というグループが絶えず増大する Conditional Access ポリシーは、最終的にテナントの半分を除外します。除外を永続的なバケットとしてではなく、所有者と削除日を持つバックログアイテムとして追跡してください。

2 番目の失敗は実際にテストされていない break-glass アカウントです。2 つのエマージェンシーアカウント、Conditional Access と PIM から除外され、長いランダムパスワードがオフラインで保存され、任意のサインインでアラート — そして誰かが四半期ごとにそれらにログインして、まだ機能することを確認する必要があります。

Conditional Access と PIM はコンプライアンス監査のためのチェックボックスではありません。それらはフィッシングされた認証情報が面倒なことと完全なテナント侵害の違いです。Blue Team の構築の一部として ID コントロールをマッピングしている場合、Korra Studio の Cloud と Blue Team セグメントは検出側をカバーします — Identity Protection リスクイベントが実際に Sentinel でどのように見えるか、および不可能な PIM アクティブ化パターンでアラートする方法。