Entra IDとは：M365の「鍵」を管理するID基盤
Entra ID（エントラ アイディー）とは、Microsoft 365のすべてのサービスへのアクセスを管理するIDおよびアクセス管理（IAM）サービスです。2023年7月、Microsoftは旧名称「Azure Active Directory（Azure AD）」をEntra IDに改名しました。機能の本質は変わっていませんが、名称変更に伴ってドキュメントや管理画面も順次更新されているため、情シス担当者は両方の呼称に慣れておくことが重要です。
Entra IDが提供する主な機能は次のとおりです。
- 認証（Authentication）：ユーザーが本人であることを確認する（パスワード・MFA・パスワードレス認証）
- 認可（Authorization）：どのリソースに・どのような権限でアクセスできるかを制御する
- IDの管理：ユーザーアカウント・グループ・サービスアカウント・ゲストアカウントの管理
- 条件付きアクセス：アクセス要求の状況（場所・デバイス・リスクレベル）に応じた制御
- 特権ID管理（PIM）：管理者権限の一時的な付与と監査
Entra IDはM365のすべてのサービス——Teams・SharePoint・Exchange Online・OneDrive・Microsoft Defender——の認証基盤として機能します。つまり、Entra IDの設定に問題があれば、これらすべてのサービスへの不正アクセスを招くリスクがあります。
Entra IDは「M365の鍵束」と考えてください。鍵束を管理する仕組みが不十分であれば、どれだけ個々のドアを堅固にしても意味がありません。M365セキュリティの強化はEntra IDから始まります。
なぜEntra IDの設定が重要か：侵害されると何が起きるか
Entra IDへの不正アクセスや設定ミスがどれほど深刻な影響をもたらすかを、具体的に考えてみましょう。
シナリオ1：グローバル管理者アカウントが侵害された場合
グローバル管理者（Global Administrator）は、Entra IDのすべての設定変更・ユーザー管理・ライセンス管理ができる最上位の権限です。このアカウントが攻撃者に奪われた場合、攻撃者は次のことが可能になります。
- すべてのユーザーのパスワードリセット
- 新たな管理者アカウントの作成
- 監査ログの削除・改ざん
- MFAの設定変更・無効化
- M365全サービスへのアクセス
数時間以内に組織のデータを完全に掌握される可能性があります。
シナリオ2：条件付きアクセスポリシーに抜け穴がある場合
「海外IPからのアクセスをブロックする」という条件付きアクセスポリシーを設定していても、特定のグループがポリシーの対象から除外されていた場合、そのグループのユーザーアカウントが侵害されると海外からの不正アクセスが通り抜けてしまいます。
シナリオ3：レガシー認証プロトコルが有効なまま
Entra IDはパスワードのみで認証できる古いプロトコル（基本認証）をサポートしていますが、これらはMFAを迂回できます。攻撃者がパスワードスプレー攻撃（多数のアカウントに共通パスワードを試す手法）でパスワードを入手した場合、MFAを設定していても突破されてしまいます。
Microsoftの報告によれば、レガシー認証プロトコルへの攻撃は依然として多く、レガシー認証をブロックするだけでアカウント侵害のリスクを大幅に低減できることが示されています。
Entra IDの設定は、M365の全体的なセキュリティ体制と密接に関連しています。M365アセスメントの全体像については、M365セキュリティアセスメントとは？専門家が確認する10の重要設定もあわせてご覧ください。
Entra IDセキュリティ設定チェックリスト：10項目
以下のチェックリストを使って、自組織のEntra IDの設定状況を確認してください。各項目に「設定済み」「未設定」「要確認」の3段階で評価することをおすすめします。
チェック1：MFA（多要素認証）の有効化状況
確認すべき内容：
- すべてのユーザーにMFAが強制されているか
- グローバル管理者・特権ロールを持つアカウントに必ずMFAが適用されているか
- MFAの方法として認証アプリ（Microsoft Authenticator）が主要手段として設定されているか
- SMS・音声通話のみのMFA設定になっていないか（SIMスワップ攻撃のリスクあり）
- セキュリティの既定値群（Security Defaults）またはMFAポリシーが有効か
よくある問題：
「MFAを有効化している」という認識はあるが、実際には特定のユーザーグループが対象外になっているケースが多数見られます。特に「IT作業の利便性のため」という理由で除外された管理者アカウントや、古くから存在するサービスアカウントが抜け漏れになりがちです。
推奨設定：
条件付きアクセスポリシーで「すべてのユーザー・すべてのアプリケーション」に対してMFAを要求するポリシーを設定します。除外ユーザーは緊急アクセスアカウント2つのみに限定し、その除外も定期的に見直します。
チェック2：条件付きアクセスポリシーの設定
確認すべき内容：
- 条件付きアクセスポリシーが「レポートのみ」モードではなく「有効」になっているか
- すべての管理者に対してMFAを要求するポリシーが存在するか
- 信頼できないデバイス（Intune未登録・準拠していないデバイス）からのアクセスを制限するポリシーがあるか
- 高リスクサインインに対してMFAまたはパスワード変更を要求するポリシーがあるか
- ポリシーの「除外」設定が最小限になっているか
よくある問題：
条件付きアクセスを設定したものの、「テスト中」として「レポートのみ」モードのままになっているポリシーが多数放置されているケースがあります。また、過去の担当者が設定した「特定のIPを信頼済みにする」設定が古いまま残っており、すでに使用されていないIPが引き続き除外されているケースも見られます。
推奨設定：
Microsoftが公開している条件付きアクセスの「おすすめポリシー」（推奨テンプレート）を参考に、少なくとも以下のポリシーを有効化します。
- 管理者に対するMFA要求
- すべてのユーザーに対するMFA要求（除外：緊急アクセスアカウントのみ）
- レガシー認証のブロック
- 高リスクユーザーへのパスワード変更要求
チェック3：特権アカウント（グローバル管理者）の最小化
確認すべき内容：
- グローバル管理者の数が4人以下になっているか（推奨：2〜4人）
- グローバル管理者アカウントには日常業務に使用しない専用アカウントを使っているか
- グローバル管理者アカウントにMFAが必ず適用されているか
- グローバル管理者アカウントがM365以外のサービス（Google、SNSなど）と同じパスワードになっていないか
- グローバル管理者以外の作業は、より権限の限定されたロール（Exchange管理者・SharePoint管理者など）で実施しているか
よくある問題：
組織の規模が拡大するにつれて、便宜上グローバル管理者を付与したアカウントが増えていくケースが典型的な問題です。10名以上のグローバル管理者が存在する組織では、そのうちの1名が侵害されるリスクが大幅に高まります。
また、グローバル管理者アカウントを日常業務（メール閲覧・Teams・SharePoint）にも使用しているケースは、フィッシング攻撃などで高権限アカウントが直接侵害されるリスクがあり、非常に危険です。
推奨設定：
最小特権の原則（Principle of Least Privilege）に従い、各担当者に必要最低限のロールのみを付与します。グローバル管理者は2〜4名の専用アカウントに限定し、日常業務は一般ユーザーアカウントで行います。
チェック4：PIM（Privileged Identity Management）の活用
確認すべき内容：
- Entra ID P2またはMicrosoft Entra IDのライセンスでPIMが利用可能か
- 特権ロール（グローバル管理者・SharePoint管理者・Exchange管理者など）がPIMによる「資格のある割り当て（Eligible Assignment）」で管理されているか
- PIMによる権限昇格時にMFAと申請理由の入力が要求されているか
- 権限昇格の有効期間が適切に設定されているか（例：最大8時間）
- 特権ロールの使用履歴がPIMの監査ログで確認できるか
PIMとは：
PIM（Privileged Identity Management）は、管理者権限を「常時付与」するのではなく「必要なときだけ一時的に昇格させる」仕組みです。たとえばグローバル管理者権限が必要な作業がある場合、担当者がPIMで申請・承認を経て1〜8時間だけ権限を有効化し、作業後は自動的に権限が失効します。
これにより、管理者アカウントが侵害されても、攻撃者が高権限を悪用できる時間窓が極めて小さくなります。
よくある問題：
PIMを利用できるライセンスを持っているにもかかわらず、設定が複雑という理由で導入を後回しにしているケースが多く見られます。
チェック5：パスワードポリシー・セルフサービスパスワードリセット
確認すべき内容：
- パスワードの有効期限を「無制限」に設定しているか（MFAと組み合わせた場合、定期的な変更よりも強固）
- パスワード禁止リスト（banned password list）が有効になっているか
- セルフサービスパスワードリセット（SSPR）が有効になっているか
- SSPRの認証方法として安全な方法（認証アプリ・電話・セキュリティキー）が設定されているか
- SSPRが管理者アカウントにも適用されているか、または管理者アカウントは別の手順で対応しているか
推奨設定について：
Microsoftは2023年以降、定期的なパスワード変更の強制（90日ごとの変更など）を非推奨としています。理由は、頻繁な変更を強制すると「Pass1234」→「Pass1235」のように予測しやすいパターンが生まれるためです。MFAを有効化した上で、パスワードの有効期限を「無制限」にする設定が現在の推奨です。
「パスワードを定期的に変更させていれば安全」という考え方は、現在のセキュリティ標準では否定されています。NISTのSP 800-63Bでも、定期的なパスワード変更の強制は推奨されていません。MFAとパスワード禁止リストの組み合わせがより効果的です。
チェック6：ゲストユーザーのアクセス制限
確認すべき内容：
- ゲストユーザーの一覧が定期的に棚卸しされているか
- 不要になったゲストアカウントが削除されているか
- ゲストユーザーが参照できるユーザー情報の範囲が制限されているか
- ゲストユーザーを招待できるユーザーの範囲が制限されているか（全員が招待できる状態になっていないか）
- アクセスレビュー（Access Review）機能が設定されており、定期的なゲストアカウントの棚卸しが自動化されているか
よくある問題：
プロジェクト期間中に招待した外部業者のゲストアカウントが、プロジェクト終了後も削除されずに残っているケースは非常によく見られます。ゲストユーザーは、招待したユーザーが退職した後でも有効なまま残り続けることがあり、誰も管理していないアカウントが蓄積されていく問題が生じます。
チェック7：外部コラボレーション設定
確認すべき内容：
- 外部コラボレーション設定で、ゲスト招待を許可する範囲が適切に制限されているか
- 「特定のドメインのみを許可（またはブロック）」する設定が実装されているか
- Teamsの外部アクセス（フェデレーション）で許可するドメインが限定されているか
- ゲストユーザーがEntra IDポータルや管理画面にアクセスできない設定になっているか
- B2B直接接続（B2B direct connect）機能の利用が管理されているか
外部コラボレーション設定の確認方法：
Entra ID管理センター（entra.microsoft.com）で「外部 ID」→「外部コラボレーション設定」から確認できます。デフォルト設定では組織内の全ユーザーがゲストを招待できる状態になっているため、少なくとも「メンバーユーザーおよびゲスト招待元として割り当てられたユーザーがゲストを招待できる」以下のレベルに制限することを推奨します。
チェック8：サインインリスクポリシー・ユーザーリスクポリシー
確認すべき内容：
- Entra ID Identity Protectionのリスクポリシーが有効になっているか（Entra ID P2ライセンス必要）
- サインインリスク（中〜高）の場合にMFAを要求するポリシーが設定されているか
- ユーザーリスク（高）の場合にパスワードの変更を要求するポリシーが設定されているか
- リスク検出のアラートが通知されるように設定されているか
- リスクのあるサインインレポートを定期的に確認しているか
リスクポリシーとは：
Entra ID Identity Protectionは、機械学習を使って「リスクの高いサインイン」や「侵害されている可能性のあるユーザー」を自動的に検出する機能です。たとえば「短時間に異なる国からのサインイン（不可能なトラベル）」「匿名IPアドレスからのアクセス」「漏洩した認証情報リストとの一致」などをリアルタイムで検知します。
これらのリスク検出に連動して、自動的にMFAを要求したりアカウントをブロックしたりするポリシーを設定することで、インシデントへの自動応答が可能になります。
Entra ID Identity ProtectionはEntra ID P2ライセンス（またはMicrosoft 365 E5）が必要です。現在のライセンスで利用可能かどうかを確認した上で、利用できる場合は必ず有効化することを推奨します。
チェック9：監査ログ・サインインログの保存設定
確認すべき内容：
- 監査ログが有効になっているか
- サインインログの保存期間がライセンスに応じて最大化されているか（P1/P2：30日、Microsoft Sentinel連携：長期保存可能）
- 管理者操作の変更（ロール付与・ポリシー変更）が監査ログに記録されているか
- ログをSIEMまたはLog Analyticsに転送して長期保存する設定があるか
- 重要な操作（グローバル管理者付与・条件付きアクセス変更）に対するアラートが設定されているか
よくある問題：
Entra IDのサインインログのデフォルト保存期間は、ライセンスによって異なりますが最長30日です。インシデントの調査には過去3ヶ月分のログが必要になることが多く、デフォルトの保存期間では調査の手がかりが消えてしまうケースがあります。
Microsoft Sentinelや外部SIEMへのログ転送を設定することで、長期間のログを保持し、過去に遡った調査を可能にします。
チェック10：レガシー認証プロトコルのブロック
確認すべき内容：
- レガシー認証プロトコル（基本認証：IMAP・POP3・SMTP AUTH・EWS・古いバージョンのActiveSync）がブロックされているか
- 条件付きアクセスポリシーでレガシー認証クライアントからのアクセスをブロックするポリシーが有効になっているか
- Exchange Onlineで基本認証が無効化されているか（Microsoftは2023年に基本認証を廃止済みだが、一部の設定が残っている場合がある）
- レガシー認証を使用しているアプリや機器が存在しないか事前に確認できているか
なぜレガシー認証をブロックすべきか：
レガシー認証プロトコルはMFAをサポートしていません。つまり、MFAを設定していても、攻撃者がレガシー認証プロトコルを使って接続を試みると、パスワードだけで認証が通ってしまいます。
Microsoftの調査によれば、パスワードスプレー攻撃の99%以上がレガシー認証プロトコルを標的にしているとされており、ブロックの効果は絶大です。
移行時の注意点：
レガシー認証をブロックする前に、社内の旧機器（多機能プリンターのメール送信機能、古い基幹システムのメール連携など）がレガシー認証を使用していないかを確認することが重要です。事前確認なしにブロックすると、業務システムが停止するリスクがあります。
上記10項目の設定状況を網羅的に確認し、リスクの優先度付けと改善ロードマップを提供するM365アセスメントサービスをご提供しています。まずは無料相談からどうぞ。
「設定済みのつもりが抜け穴になっているケース」の具体例
実際のM365アセスメントで発見される典型的な設定ミスを紹介します。
ケース1：MFAを設定したのに管理者だけ除外されていた
「全ユーザーにMFAを適用するポリシーを設定した」という組織で調査したところ、ポリシーの除外グループに「IT管理者グループ」が含まれており、最も権限の高いユーザーがMFAなしでログインできる状態になっていたケースです。
「IT担当者が作業のたびにMFAの手間がかかる」という理由で設定された除外でしたが、これは最もリスクの高いアカウントを無防備にするという致命的な問題を生んでいます。
ケース2：3年前の退職者が「ゲスト」として残っていた
外部委託先として招待したコンサルタントが、契約終了後もゲストユーザーとして残っており、SharePointの特定サイトにアクセスできる状態が3年間続いていたケースです。本人はすでにその企業に在籍しておらず、アカウントの管理者（招待した社員）も退職していたため、誰も気づかない状態でした。
ケース3：「テスト用」の条件付きアクセスポリシーが本番に昇格されていなかった
新しい条件付きアクセスポリシーを設定する際、「業務影響を確認するためにレポートのみモードで稼働させる」という手順は正しいアプローチです。しかし確認が完了した後、「有効」モードへの切り替えを忘れたまま放置され、セキュリティポリシーが機能していなかったケースがあります。
管理センターのGUI上では「ポリシーが存在する」と見えるため、担当者が設定済みと誤認しがちです。
ケース4：サービスプリンシパルに過剰な権限が付与されていた
アプリケーション開発時に作成したサービスプリンシパル（アプリID）に、開発・テスト時に付与した「グローバル管理者相当の権限」が本番運用後もそのまま残っていたケースです。そのサービスプリンシパルのシークレットキーが漏洩した場合、組織全体に影響が及ぶリスクがありました。
ケース5：緊急アクセスアカウントの管理が不十分だった
条件付きアクセスポリシーを「すべてのユーザー」に適用する際、MFAが使えなくなった緊急時に備えて「緊急アクセスアカウント（Break Glass Account）」を条件付きアクセスの除外に設定することは、Microsoftも推奨する正しい実践です。しかしこの緊急アクセスアカウントのパスワードが担当者の個人PCのメモ帳に保存されており、退職後に引き継ぎされていなかったケースがありました。
緊急アクセスアカウントは物理的なセキュリティで保管（印刷して金庫に保管など）し、定期的にアクセス可能かを確認することが重要です。
上記のような「設定したつもりが機能していない」状態の発見には、実際に設定を操作・試行する専門家の調査が有効です。管理センターのGUI上の確認だけでは、こうした抜け穴を見つけることが難しいケースがあります。
Entra IDセキュリティ設定の優先度マトリクス
すべての設定を同時に対応することが難しい場合、以下の優先度に従って対応することを推奨します。
優先度 | チェック項目 | 対応の難易度 | リスク低減効果 |
|---|---|---|---|
最優先 | MFAの全ユーザー強制 | 低〜中 | 非常に高い |
最優先 | レガシー認証のブロック | 中（事前確認要） | 非常に高い |
最優先 | グローバル管理者の最小化 | 低 | 高い |
高 | 条件付きアクセスポリシーの整備 | 中〜高 | 高い |
高 | ゲストアカウントの棚卸し | 低 | 中〜高い |
中 | PIMの導入 | 中（ライセンス要） | 高い |
中 | Identity Protectionリスクポリシー | 中（ライセンス要） | 高い |
中 | 監査ログの長期保存設定 | 中 | インシデント対応力向上 |
中 | パスワードポリシーの見直し | 低 | 中程度 |
中 | 外部コラボレーション設定の制限 | 低〜中 | 中程度 |
まずは「最優先」の3項目から着手し、組織のリスクを迅速に低減することをおすすめします。
M365全体のセキュリティとEntra IDの関係
Entra IDの設定は、M365の他のサービスのセキュリティと密接に連動しています。Entra IDが堅固であっても、SharePointの共有設定やExchange Onlineのメール転送ルールに問題があれば、情報漏洩のリスクは残ります。
M365全体のセキュリティを体系的に評価したい場合は、Entra ID単体のチェックリストにとどまらず、M365セキュリティアセスメントとして包括的に確認することが重要です。
M365セキュリティアセスメントとは？専門家が確認する10の重要設定では、Entra IDを含むM365全サービスのセキュリティ評価の全体像と、専門家に依頼する際の選定基準・費用感を詳しく解説しています。
また、M365はクラウドサービスのひとつであり、AWSやAzureなど他のクラウドサービスとの統合環境を運用している場合は、クラウド全体の設定リスクを把握することも重要です。クラウド設定ミスによるセキュリティリスクと対策：AWS・Azure実例と確認ポイントもご参照ください。
Entra IDの設定評価から始めるM365セキュリティ強化を、AEVUSの専門家がサポートします。Yahoo! JAPAN・三井住友カードなど国内主要企業への実績をもとに、自社の環境に合った改善提案を提供します。
よくある質問（FAQ）
Q1. Entra IDとAzure ADは別のサービスですか？
Entra IDは、Azure Active Directory（Azure AD）の名称変更後の新名称です。2023年7月に改名されましたが、機能・管理画面・APIの基本的な仕組みに変更はありません。現在Microsoftのドキュメントでは「Entra ID」に統一されつつありますが、社内の既存ドキュメントでは「Azure AD」という表記が混在していることが多く、両方の名称を知っておく必要があります。
Q2. セキュリティの既定値群（Security Defaults）と条件付きアクセスはどちらを使うべきですか？
セキュリティの既定値群はMicrosoft 365の無料または低コストのライセンス向けに設計されたシンプルなセキュリティ設定で、MFAの強制・レガシー認証のブロックなどを一括で有効化します。条件付きアクセスはEntra ID P1以上のライセンスで利用でき、より細かい設定が可能です。条件付きアクセスを使用している場合はセキュリティの既定値群を無効化する必要があります。一般的に、中規模以上の企業には条件付きアクセスの使用を推奨します。
Q3. PIMの導入にはどのライセンスが必要ですか？
PIM（Privileged Identity Management）の利用にはEntra ID P2ライセンス（またはMicrosoft Entra ID P2、Microsoft 365 E5など）が必要です。P1ライセンスのみでは利用できません。現在のライセンス状況を確認し、PIMが利用できるライセンスへの移行を検討することをおすすめします。
Q4. Entra IDの設定変更は業務に影響しますか？
設定変更の内容によって異なります。たとえばMFAの強制は、対象ユーザーが初回サインイン時に認証方法を登録する手順が発生するため、事前に周知・案内することが重要です。レガシー認証のブロックは、古い機器やシステムが影響を受ける可能性があるため、事前の棚卸しと影響確認が必須です。設定変更の計画段階から専門家に相談することで、業務影響を最小化できます。
Q5. Entra IDの設定確認に使えるツールはありますか？
Microsoftが提供する「Entra ID推奨事項」（管理センター内）、「セキュア スコア」、「Identity Secure Score」が自社での確認に役立ちます。また、CIS（Center for Internet Security）が公開しているMicrosoft 365のセキュリティベンチマーク（CIS Microsoft 365 Foundations Benchmark）は、より詳細な確認項目と評価基準を提供しており、専門家によるアセスメントのベースラインとしても使用されます。
Q6. Entra IDに限らず、Microsoft 365全体のセキュリティを一度に評価してもらえますか？
はい、AEVUSのM365アセスメントサービスでは、Entra IDを含むExchange Online・SharePoint・Teams・Microsoft Defenderの設定を包括的に評価します。Entra IDの設定は全体の基盤ですが、他のサービスと組み合わせた評価によって初めて全体のリスクを把握できます。
Q7. 設定を見直した後、どのくらいの頻度で再確認すべきですか？
Microsoftは機能の追加・変更を頻繁に行うため、設定内容が変化する可能性があります。また組織内の変化（人員の入れ替え・新規サービスの導入・業務プロセスの変更）によっても設定の見直しが必要になります。少なくとも半年〜1年に一度の定期的な確認と、重要な変更があった際の随時確認を組み合わせることを推奨します。
Entra IDが認証・認可を担うAPIエンドポイントについては、ID側の設定だけでなくAPI脆弱性診断でAPI実装側の脆弱性も検査することを推奨します。OAuth2.0のトークン検証やスコープ管理の不備は、Entra IDの設定だけでは防ぎきれません。
まとめ
この記事では、Entra ID（旧Azure AD）のセキュリティ設定について次の内容を解説しました。
- Entra IDとは：M365全体のID・アクセス管理基盤。旧名Azure Active Directoryから2023年に改名
- 設定が重要な理由：Entra IDが侵害されるとM365全サービスへの不正アクセスが可能になる
- チェックリスト10項目：MFA・条件付きアクセス・特権アカウント・PIM・パスワードポリシー・ゲストアクセス・外部コラボレーション・リスクポリシー・監査ログ・レガシー認証ブロック
- よくある抜け穴：「設定したつもりが除外されていた」「テスト用ポリシーが有効化されていなかった」「退職者のゲストアカウントが残っていた」などのケース
- 優先度の考え方：まずMFAの全適用・レガシー認証ブロック・グローバル管理者の最小化から着手する
Entra IDの設定は、一度確認して終わりではありません。組織の変化・Microsoftの機能更新・新たな脅威の出現に合わせて、継続的に見直していくことが重要です。
AEVUSでは、Yahoo! JAPAN・Nikon・三井住友カード・森トラスト・双日など国内主要企業へのセキュリティサービス提供実績を持つ専門家が、Entra IDを含むM365アセスメントを担当します。「自社のEntra ID設定が適切かどうか確認したい」という段階からの相談も無料でお受けしています。
