Microsoft Entra ID 条件付きアクセスと多要素認証によるゼロトラストセキュリティ基盤
アーキテクチャ
Microsoft Entra ID (旧称 Azure AD) の条件付きアクセス (Conditional Access, CA) と多要素認証 (Multi-Factor Authentication, MFA) は、ゼロトラストセキュリティモデルの中核をなす要素です。ユーザーがアプリケーションやリソースにアクセスしようとする際、CAポリシーエンジンがリアルタイムで複数の条件を評価し、適切なアクセス制御を適用します。
以下に、条件付きアクセスとMFAが適用される基本的なフローを図示します。
graph TD
A["ユーザー"] --> B("アクセス要求: アプリ/リソース")
B --> C{"Microsoft Entra ID"}
C --> D{"条件付きアクセス ポリシー評価"}
D -- 条件に一致 --> E{"アクセス要件"}
E -- MFA要求 --> F["ユーザー: MFA実施"]
F --> G{"Microsoft Entra ID: MFA検証"}
G -- 検証成功 --> H["アクセス許可"]
E -- デバイス準拠要求 --> I["デバイス: 準拠状態確認"]
I --> J{"Microsoft Entra ID: 準拠検証"}
J -- 検証成功 --> H
D -- 条件に一致せず or ブロック --> K["アクセス拒否"]
H --> L("アプリケーション/リソース")
このアーキテクチャでは、ユーザーのアイデンティティ、デバイスの状態、場所、アクセスしているアプリケーション、リアルタイムのリスクシグナルなど、多岐にわたるコンテキスト情報を評価し、認証要求を許可、ブロック、または追加の検証（MFA、デバイス準拠）を求めるかを決定します。これにより、従来の境界型セキュリティでは難しかった、よりきめ細やかなアクセス制御を実現します。
設定手順
ここでは、特定のグループのユーザーがクラウドアプリにアクセスする際にMFAを要求する基本的な条件付きアクセスポリシーを、PowerShell (Microsoft Graph SDK) を使用して設定する例を示します。この機能を利用するには、Microsoft Entra ID P1 以上のライセンスが必要です。
Microsoft Graph PowerShell SDK のインストールと接続: 必要に応じてSDKをインストールし、適切な権限で接続します。
# PowerShell GalleryからMicrosoft Graph PowerShell SDKをインストール Install-Module Microsoft.Graph -Scope CurrentUser # Microsoft Graphに接続（Conditional Access.ReadWrite.All 権限が必要） # グローバル管理者または条件付きアクセス管理者ロールを持つアカウントで実行 Connect-MgGraph -Scopes "ConditionalAccess.ReadWrite.All"
ポリシーの定義と作成: 特定のグループ（例: “AzureAdUsers” のObjectID
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）に対して、すべてのクラウドアプリでMFAを要求するポリシーを作成します。# ターゲットとするグループのObjectIDを指定 $groupId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 例: AzureAdUsers グループのObjectID # 条件付きアクセス ポリシーの定義 $policy = @{ displayName = "MFA Required for All Cloud Apps for Specific Group" state = "enabledForReportingButNotEnforced" # まずは「レポート専用モード」で作成し、影響を確認 conditions = @{ users = @{ includeGroups = @($groupId) } applications = @{ includeApplications = @("All") # すべてのクラウドアプリ } clientAppTypes = @("all") # すべてのクライアントアプリタイプ } grantControls = @{ operator = "OR" builtInControls = @("mfa") # MFAを要求 } } # ポリシーの作成 New-MgPolicyConditionalAccessPolicy -BodyParameter $policy | Format-ListstateをenabledForReportingButNotEnforcedに設定することで、ポリシーが適用された場合のログは収集されるものの、実際にはアクセス制御は行われません。これにより、意図しないロックアウトを防ぎ、運用への影響を評価できます。十分な評価の後、enabledに変更してポリシーを有効化します。
アイデンティティと権限境界
- Microsoft Entra ID: アイデンティティプロバイダーとして、ユーザー、グループ、デバイスのアイデンティティ情報を一元的に管理し、認証・認可の中心となります。Microsoft Entra ID P1 ライセンスが条件付きアクセスに、P2 ライセンスがMicrosoft Entra Identity ProtectionによるリスクベースCAなどの高度な機能に必要です。
- ロールベースのアクセス制御 (RBAC): 条件付きアクセスの管理には、グローバル管理者または条件付きアクセス管理者ロールが必要です。最小特権の原則に基づき、専用の「条件付きアクセス管理者」ロールを割り当てることを推奨します。
- 条件付きアクセス (CA): Entra IDテナント内で設定されるポリシーで、前述の通り、認証コンテキストに基づいてアクセスを制御します。
- Microsoft Defender for Identity (MDI): オンプレミスActive Directory環境からの疑わしい行動や脅威を検出します。これらのシグナルはEntra IDと連携され、条件付きアクセスのリスクベースポリシーで利用できます。
- Microsoft Defender for Cloud Apps (MDCA): クラウドアプリへのリアルタイムのセッション制御（例: ダウンロードブロック、監査）や、シャドウITの検出を提供します。MDCAで検出されたリスクレベルを条件付きアクセスのポリシー条件として利用できます。
運用監視
- 可観測性:
- Microsoft Entra管理センター: 「監視と正常性」→「サインインログ」および「監査ログ」で、条件付きアクセスが評価され、MFAが要求されたか、アクセスが許可またはブロックされたかを確認できます。
- 条件付きアクセスレポート: 「監視と正常性」→「条件付きアクセス」→「Insightsとレポート」で、ポリシーの影響度を詳細に分析できます。特に「What If」ツールは、特定のユーザーやシナリオに対してポリシーがどのように適用されるかをシミュレートするのに役立ちます。
- Azure MonitorとLog Analytics: Microsoft Entra IDのログをLog Analyticsワークスペースにエクスポートすることで、高度なKQL (Kusto Query Language) クエリによる分析、カスタムダッシュボードの作成、アラート設定が可能です。
# Log Analyticsで条件付きアクセスログをクエリする例 SigninLogs | where ConditionalAccessStatus == "Success" or ConditionalAccessStatus == "Failure" | project TimeGenerated, UserPrincipalName, AppDisplayName, ConditionalAccessPolicies, ConditionalAccessStatus | order by TimeGenerated desc
- SLA/DR/バックアップ: Microsoft Entra ID自体は99.9%または99.99%のSLAを持ち、地理的に冗長化されたインフラストラクチャで提供されるため、条件付きアクセスポリシーの可用性はEntra IDのそれに準じます。ポリシー設定のバックアップは、IaC (Infrastructure as Code) としてPowerShellスクリプトやJSON定義をGitなどのバージョン管理システムで管理することがDR対策となります。明示的なデータバックアップ機能は提供されていません。
セキュリティ
条件付きアクセスとMFAは、以下の点でセキュリティを大幅に強化します。
- ゼロトラスト原則の実現: 「決して信用せず、常に検証する」というゼロトラストの原則に基づき、アクセス要求ごとに明示的に検証を行います。
- MFAの強制: ユーザー名とパスワードだけでは突破されやすい認証を、多要素認証によって強化します。
- リスクベースのアクセス制御: Microsoft Entra Identity Protection (P2ライセンス) と連携し、異常なサインイン、漏洩した資格情報、感染デバイスなどのリスクシグナルに基づいて、リアルタイムでMFA要求やアクセスブロックを適用できます。
- レガシー認証のブロック: SMTP、IMAP、POP3などのレガシー認証プロトコルはMFAをサポートしないため、条件付きアクセスでブロックすることで、これらのプロトコルを悪用した攻撃を防ぎます。
- デバイス準拠: Microsoft Intune (Endpoint Manager) と連携し、デバイスが企業セキュリティポリシーに準拠している場合にのみアクセスを許可できます。
コスト
条件付きアクセスの主なコストは、Microsoft Entra ID ライセンスです。
- Microsoft Entra ID P1: 基本的な条件付きアクセス機能を利用できます。ユーザー数に基づく月額課金となります。
- Microsoft Entra ID P2: Identity Protectionによるリスクベースの条件付きアクセス、Privileged Identity Management (PIM) などの高度なセキュリティ機能を利用できます。P1よりも高額ですが、より堅牢なセキュリティを提供します。
- Log Analytics: ログの収集と保持には、Log Analyticsワークスペースのデータ取り込み量と保持期間に応じた費用が発生します。
- Microsoft Defender for Cloud Apps (MDCA): セッション制御などの高度な機能を利用する場合、別途MDCAのライセンスが必要となる場合があります。 Microsoft Entra IDのライセンスはユーザー単位のサブスクリプションであり、AzureのVMやストレージのようなリザーブドインスタンスやスケジューリングによるコスト最適化は適用されません。機能要件とセキュリティ要件に基づいて適切なSKUを選択することが重要です。
落とし穴
- 緊急アクセスアカウントの保護: すべてのユーザーにMFAを要求するポリシーなどを作成する際は、管理者がロックアウトされないよう、最低2つの緊急アクセスアカウント（ブレークグラスアカウント） を作成し、条件付きアクセスの対象から除外して厳重に管理してください。
- 広範なポリシーの即時有効化:
すべてのユーザー、すべてのクラウドアプリ、すべての場所にMFAを強制するような広範なポリシーは、事前にレポート専用モードで影響を十分に評価し、段階的に適用してください。意図しないサービス中断やユーザーロックアウトのリスクがあります。 - レガシー認証の考慮: レガシー認証プロトコルをブロックするポリシーを適用する際、社内にこれらのプロトコルを使用する古いアプリケーションやデバイスがないか確認し、必要に応じて除外ポリシーを設定するか、モダン認証への移行を促す必要があります。
- クライアントアプリの指定漏れ: デスクトップアプリ、モバイルアプリ、ブラウザ、VPNクライアントなど、アクセス元となるクライアントアプリの種類（
clientAppTypes）を適切に指定しないと、意図しないアクセス許可や拒否が発生する可能性があります。 - テスト不足: 新しいポリシーを導入する際は、多様なユーザー、デバイス、場所、アプリケーションで徹底的なテストを実施し、期待通りの動作をするか確認することが不可欠です。
まとめ
Microsoft Entra IDの条件付きアクセスと多要素認証は、現代のサイバー脅威から組織のデジタル資産を保護するために不可欠なゼロトラストセキュリティの中核をなします。Entra ID P1/P2ライセンスを基盤とし、ユーザー、デバイス、アプリケーション、場所、リアルタイムリスクといった多角的なコンテキストに基づいてアクセスを制御することで、従来の境界型セキュリティでは困難だった柔軟かつ堅牢なセキュリティを実現します。
設定時には、緊急アクセスアカウントの確保、レポート専用モードでの十分な影響評価とテストを徹底し、最小特権の原則に基づいたロール割り当てを行うことが重要です。運用においては、サインインログや条件付きアクセスレポート、Azure Monitorを活用した継続的な監視と分析により、ポリシーの効果を最大化し、セキュリティ態勢を常に最適化していくことが求められます。適切なライセンス選択と継続的な管理によって、高いセキュリティレベルを維持しつつ、コスト効率も考慮したアイデンティティ管理基盤を構築できます。
