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

Tech

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

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

Azure AD条件付きアクセス (Conditional Access, 以下CA) は、Microsoft Entra ID (旧Azure AD) のセキュリティ機能を強化し、適切な状況下でのみユーザーにリソースへのアクセスを許可するための強力なツールです。本記事では、クラウドアーキテクトの視点から、CAの実践的な導入、設定、運用監視、セキュリティ、コスト、そして導入時に陥りやすい落とし穴について詳細に解説します。

アーキテクチャ

Azure AD条件付きアクセスは、ユーザーがアプリケーションやサービスにアクセスしようとした際に、リアルタイムでアクセス要求を評価し、定義されたポリシーに基づいてアクセスを許可、制限、またはブロックするメカニズムです。これにより、「誰が、どのデバイスから、どこから、どのようなアプリケーションに、どのような条件でアクセスできるか」を細かく制御できます。

概念的なフローは以下の通りです。

flowchart TD
    User["ユーザーサインイン"] --> |認証リクエスト| EntraID["Microsoft Entra ID"];
    EntraID --> |ポリシー適用| CAPolicy["条件付きアクセス ポリシー"];
    CAPolicy --> Conditions["条件評価
(ユーザー/デバイス/アプリ/場所/リスクなど)"];
    Conditions -- 条件に一致 --> Controls["アクセス制御適用
(MFA/準拠デバイス/セッション)"];
    Conditions -- 条件に不一致 --> Decision["アクセス決定"];
    Controls -- 要件満たす --> Decision;
    Decision -- アクセス許可 --> Access["リソースへのアクセス"];
    Decision -- アクセス拒否 --> User;

アイデンティティと権限境界: Microsoft Entra IDは、ユーザーやデバイス、アプリケーションといったアイデンティティを一元的に管理する基盤です。CAは、このEntra IDによる認証が成功した後、または認証プロセス中に、追加のセキュリティレイヤーとして機能します。

  • Entra ID: ユーザー認証とアイデンティティの管理を行います。

  • ロール: CAポリシーは、特定のEntra IDロール（例: グローバル管理者、Exchange管理者）を持つユーザーをターゲットにできます。これにより、特権アカウントへのアクセスに厳格な条件を課すことが可能です。

  • 条件付きアクセス: Entra IDの認証結果と、ユーザー、デバイス、場所、アプリケーション、サインインリスクなどの追加条件を組み合わせて、アクセスの可否を判断します。これはアクセス時のリアルタイムな判断を担います。

  • Defender for Cloud Apps (MDCA): CAのセッション制御と統合し、クラウドアプリケーションへのアクセスをリアルタイムで監視・制御します。例えば、機密データのダウンロードを禁止したり、セッションを強制的にMFAで再認証させたりできます。

  • Entra ID Identity Protection: ユーザーのリスクやサインインのリスクを検出し、そのリスクシグナルをCAポリシーに連携します。CAはこれらのリスクレベルに基づいて、MFAの強制、パスワードリセット要求、アクセスブロックなどの自動応答を実行できます。

設定手順

ここでは、特定の管理ロールを持つユーザーが、信頼できない場所からMicrosoft管理ポータルにアクセスする際に、多要素認証（MFA）を必須にするCAポリシーをMicrosoft Graph PowerShell SDKを使用して設定する例を示します。これにより、セキュリティ運用の自動化とIaC (Infrastructure as Code) が可能になります。

この機能にはMicrosoft Entra ID Premium P1ライセンスが必要です。

# Graph APIモジュールのインストール (初回のみ)


# Install-Module -Name Microsoft.Graph.Identity.SignIns -Scope CurrentUser

# 認証 (Global Administrator権限が必要)

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

# ポリシー名と説明の定義

$policyDisplayName = "管理者MFA必須ポリシー - 信頼できない場所からM365ポータル"
$policyDescription = "特定の管理ロールを持つユーザーが、信頼できない場所からMicrosoft管理ポータルにアクセスする際にMFAを必須とするポリシー。"

# 除外するユーザー/グループ (ブレイクグラスアカウントなど) を指定する場合


# 例: $excludedUser = (Get-MgUser -UserId "breakglass_user@contoso.com").Id


# $excludedGroups = (Get-MgGroup -DisplayName "Emergency Access Group").Id


# $excludedUsersObject = @{


#    users = @("All") # 全ユーザーを対象とするが、以下で特定のロールに限定


#    excludeUsers = @($excludedUser)


#    excludeGroups = @($excludedGroups)


# }

# 条件の定義


# ターゲットユーザー: グローバル管理者ロール

$adminRole = (Get-MgRoleManagementDirectoryRoleDefinition -Filter "DisplayName eq 'Global Administrator'").Id
$users = @{
    includedUsers = @("None") # 全ユーザーは対象とせず、ロールで指定
    includedRoles = @($adminRole)

    # excludedUsers = @($excludedUser) # 除外ユーザーがある場合

}

# ターゲットアプリケーション: Microsoft Admin Portals (組み込み)

$applications = @{
    includedApplications = @("All") # 全アプリケーションを対象とするが、以下で特定のポータルに限定
    includedUserActions = @() # ユーザーアクションは指定しない
}

# 特定のMicrosoft管理ポータルアプリケーションID


# これらのIDは変更される可能性があるため、Graph APIなどで動的に取得することを推奨

$msAdminPortals = @(
    "00000002-0000-0000-c000-000000000000", # Microsoft Graph
    "c4433395-3d86-455c-b17b-527f311c62f2"  # Microsoft Azure Management

    # 他にもOffice 365 Management, Azure CLIなどがある

)
$applications.includedApplications = $msAdminPortals

# 場所の条件: 信頼されていない場所から


# 信頼できるIPアドレスまたは国/地域を先に設定しておく必要があります。


# https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/location-condition

$locations = @{
    includedLocations = @("All")
    excludedLocations = @("AllTrustedLocations") # 信頼できる場所を事前に構成
}

# デバイス プラットフォーム条件 (任意、今回は設定しない)


# $devicePlatforms = @{


#     includedDevicePlatforms = @("all")


# }

# デバイス状態条件 (任意、今回は設定しない)


# $deviceStates = @{


#     includedDeviceStates = @("all")


# }

# アクセス制御の定義: MFAの付与

$grantControls = @{
    operator = "OR" # いずれかの制御を満たす
    builtInControls = @("mfa")

    # customAuthenticationFactors = @()


    # authenticationStrength = @{} # 認証強度を使う場合

}

# ポリシーオブジェクトの作成

$policy = @{
    displayName = $policyDisplayName
    description = $policyDescription
    state = "enabledForReportingButNotEnforced" # まずはレポート専用モードで有効化
    conditions = @{
        users = $users
        applications = $applications
        locations = $locations

        # devicePlatforms = $devicePlatforms # デバイス プラットフォーム条件を含める場合


        # deviceStates = $deviceStates # デバイス状態条件を含める場合

    }
    grantControls = $grantControls
    sessionControls = $null # セッション制御は今回はなし
}

# 条件付きアクセス ポリシーの作成

try {
    $createdPolicy = New-MgIdentityConditionalAccessPolicy -BodyParameter $policy
    Write-Host "条件付きアクセス ポリシーが作成されました: $($createdPolicy.DisplayName)"
    Write-Host "ID: $($createdPolicy.Id)"
    Write-Host "現在の状態: $($createdPolicy.State) (レポート専用モード)"
}
catch {
    Write-Error "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
}

# 作成したポリシーの更新（例: enabled状態にする場合）


# Set-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $createdPolicy.Id -State "enabled"

# 接続解除

Disconnect-MgGraph

# 出力例:


# 条件付きアクセス ポリシーが作成されました: 管理者MFA必須ポリシー - 信頼できない場所からM365ポータル


# ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx


# 現在の状態: enabledForReportingButNotEnforced (レポート専用モード)

コメント:

  • Connect-MgGraph: Graph APIへの認証と権限スコープの設定。Policy.ReadWrite.ConditionalAccessはポリシーの読み書きに必要な権限です。

  • state = "enabledForReportingButNotEnforced": 重要。ポリシーを最初に「レポート専用」モードで有効化することで、実際のユーザーへの影響なしにポリシーの効果をテストできます。テストと監視の結果に基づいて、"enabled"に変更します。

  • Get-MgRoleManagementDirectoryRoleDefinition: グローバル管理者ロールのIDを動的に取得します。

  • includedApplications: 特定のアプリケーションをターゲットにします。Microsoft管理ポータルのアプリケーションIDは、テナントによって異なる場合があるため、事前に確認するか、Graph APIでアプリケーション名を検索して取得することを推奨します。

  • excludedLocations: 事前に設定した「信頼できる場所」（例: 社内ネットワークのIPアドレス）をここで除外します。

運用監視

CAポリシーの導入後も、その効果を測定し、潜在的な問題を特定するために継続的な監視が不可欠です。

  • Entra ID サインインログ: Microsoft Entra管理センターのサインインログには、すべての認証試行と、それに対して適用されたCAポリシー、およびその結果（許可、拒否、MFA要求など）が詳細に記録されます。これにより、特定のユーザーやアプリケーションに対するポリシーの影響を具体的に確認できます。ログはAzure Monitorにエクスポートして長期保存や詳細な分析が可能です。

  • 条件付きアクセス ポリシーの分析情報とレポート: CAポリシーの「レポート専用」モードを活用し、ポリシーを適用した場合の影響を事前に評価できます。これにより、本番環境への展開前に予期せぬアクセスブロックを防ぎます。

  • Azure Monitor と Log Analytics: Entra IDのサインインログや監査ログをAzure MonitorのLog Analyticsワークスペースにエクスポートすることで、高度なクエリ（Kusto Query Language, KQL）を用いた分析、カスタムダッシュボードの作成、およびアラート設定が可能になります。例えば、特定のCAポリシーによってブロックされたサインインの急増を検出するアラートを設定できます。

SLA / バックアップ / DR: Microsoft Entra IDは、Microsoftによって99.9%の月間稼働率がSLAとして提供されており、CAもこの基盤の上で動作します。CAポリシー自体はEntra IDの設定として管理され、Microsoftがバックエンドで高い可用性と冗長性を提供しているため、個別のバックアップやDR計画は通常不要です。しかし、ポリシー定義の変更履歴を管理するため、Graph APIなどでポリシーを定期的にエクスポートし、Gitなどのバージョン管理システムで管理することはIaCの観点からも推奨されます。

セキュリティ

CAは、IDセキュリティ戦略の中核をなす要素であり、他のMicrosoftセキュリティサービスとの連携により、より堅牢なセキュリティ体制を構築できます。

  • 多要素認証 (MFA) の強制: 最も基本的な利用方法であり、ほとんどの組織で推奨される必須のセキュリティ対策です。CAポリシーにより、ユーザー、場所、アプリケーションなどの条件に基づいてMFAを必須にできます。

  • 準拠デバイスの要求: Microsoft IntuneなどのMDM (モバイルデバイス管理) ソリューションと連携し、デバイスがセキュリティ要件（OSのバージョン、暗号化、ウイルス対策ソフトなど）を満たしている場合にのみアクセスを許可できます。

  • Entra ID Identity Protection との連携: ユーザーリスク、サインインリスクといった検出された脅威シグナルに基づいて、パスワードリセットの要求やアクセスブロックを自動化し、リスクベースのアクセス制御を実現します。

  • Defender for Cloud Apps (MDCA) との連携: リアルタイムセッション制御を通じて、クラウドアプリケーション内での活動（ダウンロード、アップロード、コピー＆ペーストなど）を監視し、ポリシー違反をブロックします。

  • レガシー認証のブロック: Basic認証など、MFAに対応していないレガシー認証プロトコルは攻撃の対象となりやすいため、CAポリシーでブロックすることを強く推奨します。

コスト

Azure AD条件付きアクセスは、Microsoft Entra ID Premium P1またはP2ライセンスの一部として提供されます。

  • Microsoft Entra ID Premium P1: 基本的なCA機能を利用できます。これには、多要素認証の強制、デバイスの状態に基づくアクセス制御、場所に基づく制御などが含まれます。

  • Microsoft Entra ID Premium P2: P1の機能に加えて、Microsoft Entra ID Identity Protection（ユーザーリスクとサインインリスクに基づく条件）やPrivileged Identity Management (PIM) が含まれます。これにより、リスクベースのCAや、Just-In-Timeアクセス許可と連携した高度なCAが可能になります。

ほとんどの企業は、セキュリティ要件に応じてP1またはP2のいずれかをユーザーごとに購入する必要があります。

コスト最適化: CA機能自体に直接的な追加課金はありませんが、ログの保存と分析のためにAzure Monitor Log Analyticsを利用する場合、ログの取り込み量と保存期間に応じてコストが発生します。

  • ログ保持期間の最適化: 必要なコンプライアンス要件と監査要件を満たしつつ、不必要なログを長期間保持しないようにLog Analyticsの保持期間を設定します。

  • 取り込みデータの管理: 必要なログのみをLog Analyticsにエクスポートする設定を検討します。ただし、セキュリティ監視の観点から、サインインログや監査ログは基本的にすべて取得することが推奨されます。

落とし穴

CAの導入はセキュリティを大幅に強化しますが、誤った設定は運用上の大きな障害となり得ます。

  • 過剰な制限: 初期段階で厳しすぎるポリシーを設定すると、ユーザーの生産性が著しく低下し、ヘルプデスクへの問い合わせが急増します。常に「レポート専用」モードでテストし、段階的に適用することが重要です。

  • ブレイクグラスアカウントの欠如: 全ての管理アカウントがCAポリシーの対象となり、何らかの理由でポリシーが機能しなくなった場合、誰もMicrosoft Entra管理センターにアクセスできなくなる可能性があります。少なくとも2つの「ブレイクグラスアカウント」（緊急アクセスアカウント）を用意し、CAポリシーの対象から除外して厳重に保管する必要があります。

  • レポート専用モードの怠慢: ポリシーをいきなり「有効」モードで適用すると、予期せぬユーザーが締め出されるリスクがあります。必ず「レポート専用」モードで影響を評価し、数日から数週間かけてログを監視した後で「有効」に切り替えるべきです。

  • レガシー認証のブロック忘れ: 多くの攻撃が、MFAに対応していないレガシー認証プロトコル（例: POP3, IMAP4, SMTP）を悪用して行われます。CAポリシーでこれらのレガシー認証を積極的にブロックしないと、MFAを強制しても脆弱性が残ります。

  • テスト不足: 特定のユーザーグループやデバイスの種類、アプリケーションに限定してテストを行い、多様なシナリオでの影響を確認せずに全体に適用すると問題が発生しやすいです。

まとめ

Azure AD条件付きアクセスは、現代のIDセキュリティ戦略において不可欠なコンポーネントです。適切な計画と実装により、組織はユーザーの利便性を損なうことなく、クラウド環境のセキュリティ態勢を大幅に強化できます。アーキテクチャの理解、Graph APIを用いた自動化された設定、継続的な運用監視、他のセキュリティサービスとの連携、そしてコストと一般的な落とし穴への注意が、成功の鍵となります。特に、ポリシーの「レポート専用」モードを活用し、ブレイクグラスアカウントを用意するなどのベストプラクティスを遵守することが、安全かつ円滑な導入には不可欠です。

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

コメント

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