Microsoft Entra ID：セキュリティチームが知っておくべきこと

Microsoft Entra ID（旧称 Azure Active Directory（Azure AD））は、Microsoft 365、Azure、そして数千にのぼる接続された SaaS アプリケーションを支えるアイデンティティおよびアクセス管理サービスです。貴社が Microsoft 製品を利用している場合、Entra ID はほぼ確実に「誰がサインインできるか」「何にアクセスできるか」を決定するシステムです。

この中核的な役割のため、Microsoft 環境において最も重要で、かつ狙われやすい領域の一つです。攻撃者は日常的に、侵害された資格情報、OAuth の同意（コンセント）悪用、そしてセッションハイジャックを使って Entra ID を経由しながら移動します。つまり、正しい設定ができていることは、設定を用意していることと同じくらい重要だということです。

このガイドでは、Entra ID とは何か、その仕組み、6つの中核となるセキュリティ機能、8つのハードニング優先事項、そしてハイブリッド環境においてネイティブ ツールでは不十分な点を解説します。

Microsoft Entra ID とは？

Microsoft Entra ID は、Microsoft のクラウド アイデンティティおよびアクセス管理（IAM） サービスです。これは、組織の Microsoft 365 環境、Azure リソース、および接続されたサードパーティ アプリケーションに誰がサインインできるか、また入った後に何が許可されるかを制御する仕組みです。

このプラットフォームは、シングル サインオン（SSO）、多要素認証（MFA）、条件付きアクセス、ライフサイクル管理、ユーザー、デバイス、アプリケーションのためのアイデンティティ保護を扱います。組織は、OAuth、SAML、および OpenID Connect を通じて、数千もの SaaS アプリケーションと接続します。

Microsoft は、より幅広いアイデンティティ ポートフォリオの拡大の一環として、Azure AD を Microsoft Entra ID にリブランディングしました。名称は変わりましたが、中核となるサービスは同じです。これまで Azure AD を管理してきた場合、すでに Entra ID を運用していることになります。

注： Entra ID は Azure AD の名称を置き換えたものであり、オンプレミスの Active Directory を置き換えたわけではありません。両者は別個の製品で、多くの Microsoft 環境では両方が運用されています。さらに Microsoft Entra Connect により、両者の間でアイデンティティが同期されます。このようなハイブリッド構成では、セキュリティチームが、異なるアーキテクチャと異なる攻撃面を持つ 2 つの相互に連携したシステムを保護していることになります。

Microsoft Entra ID はどのように動作しますか？

大まかに言うと、Entra ID はユーザーと、ユーザーがアクセスする必要のあるアプリケーションの間に位置します。誰かが Microsoft 365、Azure リソース、または接続された SaaS アプリケーションにサインインしようとすると、Entra ID が認証（authentication）と認可（authorization）の判断を担当します。

ユーザーがアクセスを要求するたびに、Entra ID はそのユーザーの身元を確認します（パスワード、MFA、または FIDO2 パスキーのようなパスワードレス方式）。その後、アクセスを許可するかブロックするかを判断する前に、Conditional Access のポリシーを評価します。

これらのポリシーでは、デバイスの準拠状況、場所、アプリケーションの機密性、および Identity Protection からのリアルタイムなリスクシグナルを考慮できます。

オンプレミスの Active Directory と Entra ID を併用している組織では、Microsoft Entra Connect が 2 つの環境間でユーザーの身元、グループ メンバーシップ、資格情報を同期します。つまり、オンプレミス AD でプロビジョニングされたユーザーは、別個のクラウド ID を維持することなく、Entra ID を通じてクラウド リソースに対して認証できます。

Entra ID は、大規模なアプリケーション統合もサポートしています。サードパーティの SaaS アプリケーションはテナントに登録し、フェデレーション認証のために OAuth 2.0 や SAML 2.0 のようなプロトコルを使用します。これにより、各アプリが自分のユーザー データベースを管理することなく、数百のアプリにまたがってシングル サインオン体験が機能します。

Microsoft Entra ID における中核となるセキュリティと IAM 機能

セキュリティ チームは Entra ID のすべての機能を把握する必要はありません。しかし、6 つの能力領域がセキュリティ態勢に直接影響します。

• 認証と MFA: Entra ID は、SSO、パスワード ベースの認証、そしてパスワードレスのオプションをサポートします。FIDO2 パスキー、Windows Hello for Business、証明書ベースの認証などが含まれます。MFA は、従来のユーザーごとの設定ではなく Conditional Access ポリシーを通じて強制されます。フィッシング耐性のある方法（パスキーと FIDO2 キー）は、特権アカウントにおいて優先すべきです。
• 条件付きアクセス： これは Entra ID のアクセス アーキテクチャの中心にあるポリシー エンジンです。アクセスを許可するか、ブロックするか、または追加の制御を求める前に、ユーザーの身元、デバイスの準拠状況、場所、アプリケーションの機密性、リアルタイムのリスク シグナルを評価します。
• ID 保護： ID 保護は Microsoft のシグナルを使用して、リスクのあるサインインとリスクのあるユーザーを検出し、そのシグナルを条件付きアクセスにフィードして自動応答を行うことができます。
• Privileged Identity Management (PIM)： PIM は、特権ロールに対するジャストインタイムの有効化、承認ワークフロー、時間制限付きの割り当て、そして特権昇格（privilege escalation）に対する必須の正当化を提供します。目的は、常駐の管理者アクセスを取り除き、特権アカウントが侵害されるのを待つだけの状態にならないようにすることです。
• Microsoft Entra ID ガバナンス： この ID ガバナンス ソリューションは、自動化された joiner-mover-leaver ワークフロー、構成可能な有効期限を備えたアクセス パッケージ、定期的なアクセス認証キャンペーンによってアクセスのライフサイクルを管理し、孤立したアカウントや権限のじわじわした増加（privilege creep）を最小限に抑えます。
• 監視と連携： Entra ID は、監査ログ、サインイン ログ、リスク データを API 経由で Microsoft Sentinel、Microsoft Defender for extended detection and response（XDR）、およびサードパーティのセキュリティ情報・イベント管理（SIEM）プラットフォームにストリーミングします。

これらの機能の多くには、Entra ID P2 または Entra ID Governance のライセンスが必要です。ベースまたは P1 のライセンスを利用している組織では、Identity Protection と PIM がないため、アイデンティティのセキュリティ態勢が大きく制限されます。

セキュリティ チーム向け Microsoft Entra ID のベストプラクティス 8選

ここでは、セキュリティ チームが優先すべき 8 つの実践を紹介します。

1. フィッシング耐性のある認証を強制する

標準 MFA はもう十分ではありません。パスワードスプレー（password spraying）のキャンペーンは、引き続きアカウントを大規模に侵害しており、アドバーサリー・イン・ザ・ミドル（adversary-in-the-middle、AiTM）のフィッシングキットは正当な SSO フローをハイジャックしてセッショントークンを盗み、MFA を完全に回避することができます。

SMTP AUTH、POP3、IMAP4 などのレガシー・プロトコルは、認証経路によって Conditional Access をまったくスキップしてしまうため、事態をさらに悪化させます。

優先すべきは、特権アカウントをまずフィッシング耐性のある方法に移行することです。例：FIDO2 パスキー、Windows Hello for Business、または証明書ベースの認証。

Conditional Access の認証強度コントロールを使ってこれを強制し、組織全体でレガシーの認証プロトコルをブロックしてください。残りのすべてのユーザーに対する標準 MFA は「目標」ではなく「最低限」の前提です。

2. PIM と最小権限で特権ロールを強化する

すべての常設の Global Admin アカウントは、常にアクセスを許す「招待状」です。いずれかが侵害されると、攻撃者は権限を昇格し、バックドアを作成し、誰も気づく前にセキュリティポリシーを変更できます。

Privileged Identity Management (PIM) は、常設のアクセス権を「必要なときだけ（just-in-time elevation）」に置き換えることで、この露出を解消します。管理者は必要になったときにアクセスを申請し、承認ワークフロー、時間制限のあるセッション（最大8時間は組織にとって妥当な上限の目安）、および有効化時の必須 MFA を利用します。

PIM に加えて、被害範囲（blast radius）を小さく保ちましょう：

• Global Administrator の割り当てを最小限にし、スコープ付きのロールを使用して、管理者が業務に必要な権限だけを持つようにします。
• クラウド専用の break-glass アカウントを2つ維持し、いかなるサインイン活動に対してもアラートを設定します。
• 特権ロールの割り当てを毎月見直してください。

PIM と最小特権により、攻撃者が到達できる範囲が減ります。次のステップは、特権の有無にかかわらず、そもそも誰がアクセスできるようになる条件を制御することです。

3. 条件付きアクセス（Conditional Access）ポリシーを設計し、継続的に最適化する

条件付きアクセス（Conditional Access）は、他のすべての Entra ID セキュリティ制御を機能させるポリシー エンジンです。ポリシーに抜けがあると、下流側で補うことはできません。

まずはベースラインのカバレッジから始めましょう：

• すべてのユーザーに MFA を必須にする
• リスクの高いサインインをブロックする
• 管理ポータルを保護する

次に、ゲストアクセス、高価値アプリケーション、管理されていないデバイスに対して、シナリオ別のルールを重ねます。

まず新しいポリシーはレポート専用（report-only）モードで展開し、強制適用（enforcement）する前に What-If ツールで影響をシミュレーションします。さらに、アプリケーションのタグ付けを行って、統合された各アプリが少なくとも 1 つのポリシーでカバーされるようにしてください。

ポリシードリフトは、ポリシーが欠落していることよりも大きなリスクです。 一時的なグループ除外、取り消されないテスト例外、認証要件への場当たり的な変更はすべて、保護されていないアクセス経路を生み出し、静かに蓄積していきます。

監査ログは、承認されていない主体によるポリシー変更がないか監視する必要があります。また、Conditional Access のカバレッジは少なくとも四半期ごとに見直してください。

4. Identity Protection を有効化し、リスク対応を自動化する

Identity Protection はリスクのあるサインインやリスクのあるユーザーを検出しますが、自動化された対応がない検出は単なるノイズです。 Identity Protection のシグナルが、強制的にアクションを取る Conditional Access ポリシーと連携していない場合、侵害されたアカウントはアクティブなまま維持され、アラートは誰も十分に素早く確認できないキューに積み上がっていきます。

解決策は、Identity Protection のシグナルを直接“施行（enforcement）”に結び付けることです。 Conditional Access を設定して、中程度のリスクのサインインでは MFA を必須にし、高リスクのユーザーには安全なパスワード再設定を強制してください。

そこから、サインインログ、監査ログ、リスクイベントを SIEM にストリーミングして、セキュリティ運用センター（SOC）が「不可能な移動（impossible travel）」、レガシー認証の試行、特権昇格パターンに対する検出ルールを作成できるようにします。自動化された強制とSOCレベルの可視性を組み合わせることで、検出と対応のギャップを埋めます。

5. アプリの登録と OAuth 同意（OAuth consent）を制御する

OAuth 同意（OAuth consent）は、Entra ID における最も見落とされがちな持続（永続化）メカニズムの 1 つです。Mail.Read を何年も前に付与されたアプリは、誰かが明示的に取り消さない限り、そのアクセス権を無期限に保持します。また、多くの組織ではエンタープライズ アプリの権限を定期的に見直すプロセスがありません。

攻撃対象領域は、古い付与（stale grants）にとどまりません。脅威アクターはデバイスコードの認可フロー（device code authorization flows）を悪用し、ユーザーを騙して攻撃者の代わりに正規の Microsoft ログイン ページで認証させることで、MFA を回避するアクセス トークンを付与させています。

このリスクを減らすには、セルフサービスの同意（self-service consent）を制限するか無効化し、承認なしにユーザーがテナント全体の権限を付与できないようにします。

高い特権（high-privilege）の権限要求には、必ず管理者の同意（admin consent）ワークフローを要求し、アプリの登録は管理者に限定し、サービスプリンシパル（service principals）およびエンタープライズ アプリの権限を毎月確認してください。定期的に見直さないと、付与されたあらゆる権限が、攻撃者が引き継げる可能性のある持続化（persistence）メカニズムになり得ます。

6. ゲストおよび B2B アクセスを統制する

ゲスト アカウントは作成が簡単で、忘れられやすいため、ほとんどの Entra ID テナントではガバナンス上の抜け（gap）になりがちです。ガバナンスがされていないゲストはすべて、セキュリティ チームがプロビジョニングしておらず、存在を把握していない可能性がある“身元（identity）”であり、誰かが積極的に削除するまでアクセスが永続してしまいます。

この強化は、誰がゲストを招待できるかを制限し、すべてのゲスト ユーザーに MFA を必須にすることから始めます。各ゲスト アカウントには、継続的なアクセスの正当性を説明・証明する責任を持つ社内オーナーを割り当てるべきです。

テナント間のアクセス ポリシーは、外部の identity が到達できる範囲を制御することで、もう1つの層を追加します。また、定期的なアクセス レビューによって、そうしなければ無期限に放置されてしまう非アクティブなアカウントを見つけられます。

責任の所在、MFA 要件、そして定期的なレビューを組み合わせることで、ゲストアクセスが見落とされる盲点にならないようにできます。

7. Entra ID を identity threat detection and response (ITDR) と SOC モニタリングに統合する

アイデンティティのシグナルは、他のテレメトリと相関付けることで、はるかに価値が高くなります。疑わしいサインインだけでは、それが誤検知の可能性もあります。そこで、同じサインインを、横方向の移動を示すエンドポイントのデータや、異常なデータ転送を示すネットワークログと組み合わせると、高い確度の調査対象となります。

この相関付けには、Entra ID のサインインログ、監査ログ、そして Identity Protection のリスクシグナルを SIEM または XDR プラットフォームに取り込む必要があります。また、アイデンティティのイベントは、エンドポイントやネットワークのデータと併せて、インシデント対応のランブックにも含めるべきです。

このようにすることで、アイデンティティに基づくアラートが発報されたときに、SOC は切り離されたツール間を行き来せずに、範囲と影響を評価するための文脈（コンテキスト）を持てます。

8. Entra ID のセキュリティ態勢を定期的に評価する

定期的な態勢レビューは、大規模なセキュリティ施策の合間に蓄積される設定上の問題を見つけられます。設定ドリフトは、単体では無害に見える小さな変更を積み重ねることで発生します。たとえば、正当性が失われた後も残り続ける Conditional Access の除外、幅広い権限を持つテスト用アプリの登録、またはプロジェクト終了後も長期間有効な特権ロールの割り当てなどが考えられます。

放置すると、前の7つのステップで構築した態勢が徐々に損なわれます。Microsoft Secure Score は便利な継続指標を提供しますが、唯一の評価メカニズムであるべきではありません。

Center for Internet Security（CIS）Benchmarks と定期的な手動レビューで補完し、各コントロール領域のリスクプロファイルに合う頻度（ペース）を設計してください：

• 特権ロールの割り当ておよび OAuth の同意付与：毎月。
• ゲストアクセスと B2B の設定：ボリュームに応じて毎月または四半期ごと。
• 条件付きアクセス（Conditional Access）ポリシー：四半期ごと。テナントに大きな変更があった場合は、その後に必要に応じた臨時レビューを実施します。

この8つの優先事項により、Entra ID 環境は大幅に強化されます。ただし、設定が適切に行われているテナントにも限界はあります。ネイティブ機能がどこまで対応できるのかを理解することは、設定を正しく行うことと同じくらい重要です。

Microsoft Entra ID で解決できないこと（そして追加で必要になる領域）

Entra ID は幅広くカバーしていますが、すべてを網羅するようには設計されていません。ハイブリッド環境では、次の3つのギャップが一貫してよく見られます。

• オンプレミス環境および非 Microsoft システム： Entra ID には、DCSync、Golden Ticket、または Kerberos 悪用のようなオンプレミス Active Directory の攻撃ベクターに対する可視性がありません。ドメインコントローラーの保護、ハイブリッド同期サーバーのセキュリティ、およびオンプレミスでの特権昇格検知はすべて、その範囲外です。
• データのセキュリティとガバナンス： Entra ID はアイデンティティとアクセスを管理します。特にオンプレミスのファイルサーバーや非 Microsoft のリポジトリにまたがって、機密データを分類したり、ファイル単位のアクセスパターンを監視したり、データ損失防止（DLP）ポリシーを強制したりすることはできません。もしコンプライアンス要件に「機密データがどこに保存されており、誰がアクセスしているか」を把握することが含まれる場合、それは別の機能です。
• クロスプラットフォーム ITDR： Entra ID の Identity Protection は、Microsoft エコシステム内における認証時のリスクシグナルをカバーします。認証後の横方向への移動、オンプレミスの AD 攻撃チェーン、非 Microsoft のアイデンティティソース間での相関分析には、専用の ITDR ツールが必要です。

規制のある環境やハイブリッド環境では、実用的なアーキテクチャとして、Entra ID をアイデンティティのコントロールプレーンとし、可視性、保持（retention）、およびクロス-Netwrix Strongpoint が提供しないものを補うための独立したツールを組み合わせるのが現実的です。

Netwrix は Microsoft Entra ID をどのように補完するのか

Netwrix は、Entra ID のネイティブ ツールが残してしまうギャップを埋めます。特に、オンプレミス AD の可視性、長期の監査ログ保管、およびアイデンティティのリスクをデータ露出（データへの曝露）に結び付ける点においてです。これらのギャップは、より良い Entra ID の設定だけでは解決できません。追加のツールが必要です：

• Entra ID と併せてオンプレミス AD まで可視化できる（どちらか一方だけではなく）
• ネイティブのログ保存期間（上限）を超えて維持できる監査ログ保管
• アイデンティティの露出がデータの露出につながることを結び付けるリスクの文脈（コンテキスト）
• 監査人が実際に受け入れるコンプライアンスの証拠

それが、すでに手一杯のセキュリティチームに複雑さを追加することなく、Netwrix が埋めるギャップです。

Netwrix 1Secure は、プロビジョニングのためのインフラを用意することなく、Microsoft 365 とハイブリッド ID 環境の可視性を提供します。Entra ID では、1Secure がログオン アクティビティを追跡し、特権の昇格を明らかにし、クラウドおよびオンプレミスの Active Directory の両方にまたがるアクセス許可の変更を、ほぼリアルタイムの同期で監視します。

リスク評価ダッシュボードは、過剰な特権、危険なアカウント設定、アクセス権が残ったままの休眠アカウント、そして侵害時に被害範囲を拡大させる誤設定を可視化します。AI ベースの是正（リメディエーション）推奨により、チームは「まず何を直すべきか」を優先順位付けできます。

Netwrix Auditor は、規制産業向けにコンプライアンス重視の監査を提供します。30 分で導入でき、レポートは数時間以内に利用可能です。Auditor は Entra ID、Active Directory、ファイル サーバー、Exchange にわたる監査証跡を提供します。

監査ログに対するインタラクティブな検索により、調査担当者はハイブリッド環境全体で「誰が何に、いつアクセスしたのか」を回答できます。さらに、ネイティブの Entra ID ログ保持期間を大きく超える長期の監査履歴を提供します。

Entra ID と Microsoft 365 環境内での特権アクセスのために、Netwrix Privilege Secure はジャストインタイムのプロビジョニングにより、常駐の管理者権限を削除し、監査証跡用のセッション記録を提供します。

Netwrix のデモを予約する Entra ID が開けたままになっている可視性とガバナンスのギャップを、どれだけ早く埋められるかを確認してください。