Azure AD条件付きアクセス実践ガイド

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure AD条件付きアクセス実践ガイド

Azure Active Directory（Azure AD）は、2023年7月11日（JST）にMicrosoft Entra ID（以下、Entra ID）に名称変更されましたが、条件付きアクセスは現代のIDセキュリティ戦略において不可欠な機能であり続けています。本ガイドでは、Entra IDの条件付きアクセス（Conditional Access: CA）について、そのアーキテクチャから具体的な設定手順、運用監視、セキュリティの考慮事項、コスト最適化、そしてよくある落とし穴までを詳細に解説します。

1. アーキテクチャ

条件付きアクセスは、Entra IDのコア機能の一つであり、特定の条件に基づいてリソースへのアクセスを許可またはブロックするポリシーベースのアクセス制御メカニズムです。ゼロトラストの原則（「決して信用せず、常に検証する」）を実現するための重要な要素となります。

1.1. 条件付きアクセスの評価フロー

ユーザーがクラウドアプリケーションやリソースへのアクセスを試行すると、Entra IDは認証要求を受け取ります。その後、Entra IDに設定された条件付きアクセス ポリシーが評価され、その結果に基づいてアクセスが許可されるか、多要素認証（MFA）やデバイス準拠などの追加の制御が要求されるか、またはアクセスがブロックされます。

graph TD
    A["ユーザーがリソースにアクセス"] --> B{"サインイン要求を受信"};
    B --> C{"Entra ID認証"};
    C --> D{"条件付きアクセス ポリシー評価"};
    D --|ポリシーの条件| E("ユーザー/グループ, クラウドアプリ, デバイス, 場所, リスクレベル, クライアントアプリ, 認証セッション");
    E --|条件が全て一致する場合| F{"アクセス制御の適用"};
    F --|アクセスを許可| G("多要素認証, デバイス準拠, ハイブリッドEntra参加済みデバイス, 承認済みクライアントアプリ, セッション制御");
    F --|アクセスをブロック| H["アクセスを拒否"];
    G --|制御が満たされた場合| I["アクセスを許可"];
    G --|制御が満たされない場合| H;

図1: 条件付きアクセス ポリシー評価のフローチャート

1.2. アイデンティティと権限境界

  • Microsoft Entra ID: 条件付きアクセス ポリシーを格納し、評価する主要なアイデンティティプロバイダーです。

  • Entra IDロール: 条件付きアクセス ポリシーの「割り当て」セクションで、特定の管理者ロール（例: 全体管理者、条件付きアクセス管理者）を持つユーザーを対象にできます。

  • 条件付きアクセス: ユーザー、デバイス、場所、アプリケーション、サインインリスクなどの条件に基づいてアクセスを制御する境界を定義します。

  • Microsoft Defender for Cloud Apps (MDCA): セッション制御（リアルタイムアクセス制御）を提供し、条件付きアクセス ポリシーと連携して、クラウドアプリ内の活動を監視・制御します。

  • Microsoft Defender for Endpoint: デバイスの準拠状態をEntra IDに報告し、条件付きアクセス ポリシーでデバイス準拠を条件とすることができます。

2. 設定手順

条件付きアクセスの設定には、Entra ID Premium P1またはP2ライセンスが必要です。ここでは、Azure Portalでの基本的な設定と、自動化のためのスクリプト例を紹介します。

2.1. 前提条件

  • Entra ID Premium P1またはP2ライセンス

  • 条件付きアクセス管理者または全体管理者のロールを持つアカウント

2.2. Azure Portalでのポリシー作成例（管理者へのMFA要求）

最も一般的なシナリオの一つとして、「すべての管理者ロールを持つユーザーがサインインする際にMFAを要求する」ポリシーを作成します。

  1. Azure Portal (portal.azure.com) にサインインします。

  2. 「Microsoft Entra ID」 > 「セキュリティ」 > 「条件付きアクセス」を選択します。

  3. 「新しいポリシー」をクリックします。

  4. 名前: 「管理者向けMFA必須」などのわかりやすい名前を入力します。

  5. 割り当て:

    • ユーザー: 「ユーザーとグループ」を選択し、「ディレクトリロール」タブで「すべての管理者ロール」を選択します。緊急アクセスアカウントは必ず「除外」に追加してください。

    • ターゲットリソース: 「クラウドアプリまたはアクション」を選択し、「すべてのクラウドアプリ」を選択します。

  6. 条件: 環境に応じて設定します（例: 「場所」で信頼できない場所からのアクセスを除外）。

  7. アクセス制御:

    • 許可: 「アクセスを許可」を選択し、「多要素認証を要求する」にチェックを入れます。

  8. ポリシーを有効にする: 「レポート専用」モードで作成し、影響を監視した後に「オン」に切り替えることを強く推奨します。

2.3. Azure CLIまたはMicrosoft Graph APIによるポリシー管理

IaC (Infrastructure as Code) のアプローチとして、CLIやGraph APIを用いてポリシーを管理できます。以下は、既存の条件付きアクセス ポリシーを有効化する例です。

Azure CLIでポリシーの状態を更新 この例では、my-policy-idというIDを持つ既存のポリシーの状態を「有効」に更新します。

# Azure CLIにログイン

az login

# 条件付きアクセス ポリシーのIDを検索 (例: az ad conditional-access policy list --query "[?displayName=='管理者向けMFA必須'].id")


# 例として、取得したポリシーIDをここに設定

POLICY_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# ポリシーの状態を有効に更新

az ad conditional-access policy update \
  --id $POLICY_ID \
  --state "enabled"

echo "ポリシー $POLICY_ID が有効化されました。"

入力: Azure CLIのログイン情報、既存ポリシーのID。 前提: azコマンドがインストールされ、ログイン済みであること。 出力: ポリシーの更新結果メッセージ。 計算量: 定数時間 O(1)。 メモリ: 最小限。

Microsoft Graph API (PowerShell) でポリシーの状態を更新 PowerShellスクリプトでGraph APIを呼び出し、特定のポリシーを有効にします。

# Microsoft Graphモジュールがインストールされていない場合はインストール


# Install-Module Microsoft.Graph -Scope CurrentUser

# Connect-MgGraph -Scopes "ConditionalAccessPolicy.ReadWrite.All"


# 管理者権限を持つアカウントでログインし、必要な権限を付与してください。

$policyDisplayName = "管理者向けMFA必須" # 更新したいポリシーの表示名
$policyId = (Get-MgConditionalAccessPolicy -Filter "displayName eq '$($policyDisplayName)'").Id

if (-not $policyId) {
    Write-Host "指定された表示名のポリシーが見つかりません: $($policyDisplayName)"
    exit
}

$policyUpdate = @{
    state = "enabled" # "enabled", "disabled", "enabledForReportingButNotEnforced" (レポート専用)
}

Update-MgConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -BodyParameter $policyUpdate

Write-Host "ポリシー $($policyDisplayName) ($($policyId)) が有効化されました。"

# 必要に応じて接続を切断


# Disconnect-MgGraph

入力: policyDisplayName変数で指定されたポリシー表示名。 前提: Microsoft.Graph PowerShellモジュールがインストールされ、Connect-MgGraphでConditionalAccessPolicy.ReadWrite.Allスコープで接続済みであること。 出力: ポリシーの更新結果メッセージ。 計算量: 定数時間 O(1) (API呼び出しのオーバーヘッドを除く)。 メモリ: 最小限。

3. 運用監視

効果的な条件付きアクセス運用には、継続的な監視と評価が不可欠です。

3.1. サインインログと監査ログ

  • サインインログ: Entra IDのサインインログは、各サインイン試行に対してどの条件付きアクセス ポリシーが適用されたか、およびその結果（許可、ブロック、MFA要求など）を詳細に記録します。これにより、ポリシーが意図どおりに機能しているか、または予期せぬブロックが発生していないかを確認できます。

  • 監査ログ: ポリシーの作成、変更、削除などの管理操作は監査ログに記録されます。

3.2. What Ifツール

Azure Portalの条件付きアクセスには「What If」ツールが用意されており、特定のユーザーが特定の条件でサインインした場合に、どのポリシーが適用され、どのような結果になるかを事前にシミュレーションできます。これにより、ポリシーを有効にする前の影響評価が容易になります。

3.3. レポート専用モード

新規ポリシーや変更したポリシーは、すぐに適用せずに「レポート専用」モードでデプロイすることを強く推奨します。このモードではポリシーが適用されることはありませんが、ログには「もし適用されていたら」の結果が記録されます。これにより、本番環境への影響を評価し、潜在的な問題を特定できます。

3.4. SLAとDR/バックアップ

  • SLA: 条件付きアクセス機能自体に個別のSLAはありませんが、Entra IDの月間アップタイムSLA (99.9%) に準拠します。

  • DR/バックアップ: 条件付きアクセス ポリシーはEntra IDの構成の一部としてMicrosoftによって管理され、グローバルに冗長化されています。ユーザー側での明示的なバックアップは不要ですが、設定をコードとしてエクスポートし、Gitなどのバージョン管理システムで管理することで、変更履歴の追跡や回復性を高めることができます。

4. セキュリティ

条件付きアクセスは、Entra IDセキュリティの中核をなす機能であり、多層防御戦略の要となります。

4.1. ゼロトラスト原則の実践

「すべてのアクセス要求は、場所、デバイス、ユーザーリスク、リソース感度など、可能な限り多くのデータポイントに基づいて信頼が検証されるまで、暗黙的に信頼すべきではない」というゼロトラストモデルを実装します。

4.2. Identity Protectionとの連携

Entra ID Premium P2ライセンスでは、Entra ID Identity Protectionが提供するユーザーリスクおよびサインインリスクの検出結果を条件として、条件付きアクセス ポリシーを動的に適用できます。例えば、「高リスクのサインインの場合、アクセスをブロックする」といったポリシーを設定可能です。

4.3. セッション制御とアプリケーション制御

Microsoft Defender for Cloud Apps (MDCA) と連携することで、条件付きアクセス ポリシーで「セッション制御」を付与できます。これにより、承認されていないファイルのダウンロードブロックや、機密データを含むコンテンツのコピー＆ペースト制限など、リアルタイムでのアプリケーション内操作を制御できます。

5. コスト

条件付きアクセスの利用には、Entra ID Premium P1またはP2ライセンスが必要です。

  • Entra ID Premium P1: 大部分の条件付きアクセス機能を利用できます。ユーザーベースのライセンスであり、ユーザー数に応じた月額費用が発生します。

  • Entra ID Premium P2: P1の機能に加えて、Entra ID Identity Protectionのすべての機能（ユーザーリスクおよびサインインリスクの検出、MFA登録ポリシーなど）が含まれます。リスクベースの条件付きアクセスにはP2ライセンスが必要です。

コスト最適化: 組織に必要なセキュリティレベルと予算を考慮し、適切なライセンスティアを選択することが重要です。特にリスクベースのポリシーが必要ない場合はP1、より高度な保護が必要な場合はP2を選択します。

6. 落とし穴とベストプラクティス

6.1. 管理者アカウントのロックアウト

最も一般的な落とし穴は、すべての管理者アカウントが条件付きアクセス ポリシーによってロックアウトされることです。

  • 緊急アクセスアカウントの除外: 少なくとも2つの「緊急アクセスアカウント」を作成し、すべての条件付きアクセス ポリシーから必ず除外してください。これらのアカウントは厳重に管理し、緊急時のみ使用します。

  • テストと段階的導入: 新規ポリシーは必ず「レポート専用」モードでテストし、影響を十分に評価してから有効化してください。

6.2. 複雑すぎるポリシー

多数のポリシーや複雑な条件を設定しすぎると、管理が困難になり、意図しないアクセスブロックやセキュリティホールが生じる可能性があります。

  • シンプルな設計: 各ポリシーは単一の目的を持つように設計します。

  • 最小限のポリシーセット: 可能な限り少ないポリシーで要件を満たすようにします。

6.3. レガシー認証への対応

条件付きアクセスは、パスワードハッシュ同期やパススルー認証など、現代的な認証プロトコルに最適化されています。レガシー認証プロトコル（POP3, IMAP4, SMTPなど）を使用しているクライアントは、MFAが適用できないなどの問題が発生する可能性があります。

  • レガシー認証のブロック: セキュリティを高めるため、条件付きアクセス ポリシーでレガシー認証をブロックすることを検討してください。

7. まとめ

Entra ID条件付きアクセスは、進化し続けるサイバー脅威から組織のデジタル資産を保護するための強力なツールです。適切な計画、設定、継続的な監視を行うことで、ゼロトラストセキュリティモデルを効果的に実装し、ユーザーエクスペリエンスを損なうことなくセキュリティを強化できます。本ガイドが、貴社のEntra ID環境における条件付きアクセスの実践に役立つことを願っています。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました