Microsoft Graph PowerShell SDKのインポート

<p><!--META { "title": "Azure Entra ID: 条件付きアクセスとMFAによるセキュリティ強化", "primary_category": "クラウド>Azure", "secondary_categories": ["セキュリティ","アイデンティティ管理","アクセス制御"], "tags": ["Azure Entra ID", "条件付きアクセス", "MFA", "Conditional Access", "Multi-Factor Authentication", "Microsoft Graph API", "PowerShell", "IaC"], "summary": "Azure Entra IDの条件付きアクセスとMFAを活用し、ゼロトラストに基づく堅牢なアクセス制御を実現するアーキテクチャ、設定、運用、セキュリティ、コストについて解説します。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"Azure Entra IDの条件付きアクセスとMFAでセキュリティを強化！アーキテクチャから設定、運用、コスト、落とし穴まで、ゼロトラストに基づく堅牢なアクセス制御を解説。 #Azure #EntraID #MFA #ConditionalAccess","hashtags":["#Azure","#EntraID","#MFA","#ConditionalAccess"]}, "link_hints": ["https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview"] } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h3 class="wp-block-heading">Azure Entra ID: 条件付きアクセスとMFAによるセキュリティ強化</h3> <p>今日のハイブリッドワーク環境において、アイデンティティは新たなセキュリティ境界となっています。Azure Entra ID（旧Azure Active Directory）の条件付きアクセスと多要素認証（MFA）を組み合わせることで、ユーザー、デバイス、場所、アプリケーション、リアルタイムリスクといった多様なシグナルに基づき、きめ細やかなアクセス制御を実現し、ゼロトラストセキュリティモデルを確立できます。</p> <h4 class="wp-block-heading">アーキテクチャ</h4> <p>Azure Entra IDは、Microsoftが提供するクラウドベースのアイデンティティおよびアクセス管理サービスです。条件付きアクセス (Conditional Access: CA) は、Entra IDのポリシーエンジンであり、組織のリソースにアクセスしようとするユーザーに対して、特定の条件が満たされた場合にのみアクセスを許可したり、追加の認証要件（MFAなど）を課したりするルールを定義します。</p> <p><strong>MFAの役割</strong>: MFAは、パスワードだけでなく、スマートフォンアプリ、生体認証、セキュリティキーなど、複数の認証要素を組み合わせてユーザーの身元を確認するセキュリティメカニズムです。条件付きアクセスは、MFAを強制するための強力な手段となります。例えば、「社外からのアクセス」「管理者の役割を持つユーザー」「特定の機密性の高いアプリケーションへのアクセス」といったシナリオでMFAを必須に設定できます。</p> <p>以下のフローチャートは、Azure Entra IDにおける認証と条件付きアクセスがどのように連携するかを示しています。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> flowchart TD A["ユーザーがアプリケーションにアクセスを試行"] --> B("Entra IDへの認証要求"); B --> C{"条件付きアクセス ポリシーの評価"}; C -- |ポリシーなしまたは除外| --> D["シングルサインオン (SSO) でアクセス"]; C -- |ポリシーに一致| --> E{"条件の確認"}; E -- |ユーザー/グループに一致| --> F{"デバイスの状態に一致"}; F -- |場所/IPアドレスに一致| --> G{"アプリケーションに一致"}; G -- |リアルタイムのリスクに一致| --> H{"付与コントロールの適用"}; H -- |MFAの必須化| --> I["MFAプロンプト"]; I --> J{"MFA成功"}; J --> K["アプリケーションへのアクセス許可"]; H -- |アクセスブロック| --> L["アクセス拒否"]; J -- |MFA失敗| --> L; </pre></div> <p>[1]</p> <p>このアーキテクチャでは、ユーザーがアプリケーションへのアクセスを試みると、まずEntra IDが認証を処理し、その際に定義された条件付きアクセス ポリシーが評価されます。ポリシーの条件（ユーザー、デバイス、場所、アプリケーション、リアルタイムリスクなど）に基づいて、MFAの要求、アクセス許可、またはアクセス拒否といった付与コントロールが適用されます。</p> <h4 class="wp-block-heading">設定手順</h4> <p>条件付きアクセス ポリシーは、Azure portalからグラフィカルに設定できるほか、Microsoft Graph APIまたはPowerShellを通じてコードとして管理（IaC: Infrastructure as Code）することも可能です。ここでは、Graph APIを利用して特定のグループのユーザーに対して、任意のクラウドアプリへのアクセス時にMFAを必須化するポリシーをPowerShellで作成する例を示します。</p> <p><strong>前提条件</strong>:</p> <ul class="wp-block-list"> <li><p>Azure Entra ID Premium P1またはP2ライセンス [2]</p></li> <li><p>Microsoft Graph PowerShell SDKのインストール</p></li> <li><p>条件付きアクセス管理者のEntra IDロールを持つアカウント</p></li> </ul> <p><strong>PowerShellスクリプト例</strong>:</p> <div class="codehilite"> <pre data-enlighter-language="generic"># Microsoft Graph PowerShell SDKのインポート # 事前に Install-Module Microsoft.Graph.Identity.Governance を実行してインストールしてください。 Import-Module Microsoft.Graph.Identity.Governance # 認証スコープの設定 # Policy.ReadWrite.ConditionalAccess スコープは条件付きアクセス ポリシーの読み取りと書き込みを許可します。 $scopes = "Policy.ReadWrite.ConditionalAccess" Connect-MgGraph -Scopes $scopes # ポリシー名と対象グループの指定 $policyName = "Require MFA for All Cloud Apps for Specific Group" $targetGroupId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 対象とするEntra IDグループのオブジェクトIDを指定 # 条件付きアクセス ポリシーの定義 (JSON形式) # - Users: 特定のグループを対象 (IncludeGroups) # - Applications: 全てのクラウドアプリを対象 (IncludeApplications: "All") # - ClientAppTypes: 全てのクライアントアプリタイプ (ブラウザ、モバイルアプリなど) を対象 # - GrantControls: MFAを必須 (builtInControls: "mfa") # 計算量: この操作は単一のGraph API呼び出しであるため、O(1)に相当します。 # メモリ条件: ポリシー定義オブジェクトのサイズは小さく、最小限のメモリ消費です。 $policyDefinition = @{ displayName = $policyName state = "enabledForReportingButBlocked" # まずは「レポートのみ」モードで作成し、影響を確認することを推奨 conditions = @{ users = @{ includeGroups = @($targetGroupId) } applications = @{ includeApplications = @("All") } clientAppTypes = @("all") } grantControls = @{ operator = "OR" # 複数のコントロールがある場合、いずれかを満たせば良い builtInControls = @("mfa") # 多要素認証を必須とする } } | ConvertTo-Json -Depth 5 # Graph APIを呼び出してポリシーを作成 # New-MgIdentityConditionalAccessPolicy コマンドレットを使用します。 try { $policy = New-MgIdentityConditionalAccessPolicy -Body $policyDefinition Write-Host "条件付きアクセス ポリシー '$policyName' が作成されました。ID: $($policy.Id)" Write-Host "状態: $($policy.State)。テストのため、まずは 'enabledForReportingButBlocked' で運用を開始してください。" } catch { Write-Error "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)" } # 作成されたポリシーの確認 (オプション) # Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id | Format-List DisplayName, State, Conditions, GrantControls </pre> </div> <p>[3], [4]</p> <p>このスクリプトは、ポリシーを <code>enabledForReportingButBlocked</code> （レポートのみモード）で作成します。これは、ポリシーが適用された場合の影響を評価するための推奨されるアプローチであり、運用環境にデプロイする前に十分にテストできます。確認後、<code>state</code> を <code>enabled</code> に変更することでポリシーを有効化できます。</p> <h4 class="wp-block-heading">運用監視</h4> <p>条件付きアクセス ポリシーの運用においては、効果的な監視が不可欠です。</p> <ul class="wp-block-list"> <li><p><strong>Entra ID サインインログ</strong>: ユーザーのサインイン試行ごとに、条件付きアクセス ポリシーが適用されたかどうか、その結果（許可/拒否/MFA要求など）が記録されます。Azure portalまたはMicrosoft Graph APIを通じてこれらのログにアクセスし、異常なアクセスパターンやMFA失敗の傾向を特定できます。 [5]</p></li> <li><p><strong>監査ログ</strong>: 条件付きアクセス ポリシーの作成、更新、削除などの管理操作はすべて監査ログに記録されます。これにより、ポリシーの変更履歴を追跡し、不正な変更を検出できます。</p></li> <li><p><strong>「レポートのみ」モード</strong>: 新しいポリシーをデプロイする際や既存のポリシーを変更する際に、<code>enabledForReportingButBlocked</code> または <code>enabledForReporting</code> ステータスを使用することで、実際にポリシーを強制することなく、そのポリシーがユーザーアクセスにどのような影響を与えるかをシミュレートできます。これは、潜在的なロックアウトを防ぎ、ポリシー設計を微調整するために非常に重要です。 [6]</p></li> <li><p><strong>条件付きアクセス ワークブック</strong>: Azure Monitor ワークブックを活用し、条件付きアクセスのイベントや影響を視覚的に分析できます。</p></li> </ul> <p>Azure Entra IDは、Microsoftが提供するグローバルに分散された高可用性サービスであり、ユーザー側でのバックアップや災害復旧（DR）の運用は通常不要です。SLA（サービス品質保証）は、Microsoftによって提供されます。</p> <h4 class="wp-block-heading">セキュリティ</h4> <p>条件付きアクセスとMFAの活用は、組織のセキュリティ態勢を大幅に強化しますが、いくつかの重要なセキュリティプラクティスを遵守する必要があります。</p> <ul class="wp-block-list"> <li><p><strong>緊急アクセスアカウントの除外</strong>: 組織のすべてのポリシーが予期せずユーザーをロックアウトした場合に備え、条件付きアクセス ポリシーから<strong>緊急アクセスアカウント（ブレイクグラスアカウント）</strong>を少なくとも2つ除外しておく必要があります。これらのアカウントは、通常の使用から厳しく保護し、緊急時のみ使用するようにします。 [7]</p></li> <li><p><strong>最小特権の原則</strong>: ユーザーにはその職務に必要な最小限の権限のみを付与し、管理ロールを持つユーザーには常にMFAを要求するポリシーを適用します。</p></li> <li><p><strong>ポリシーの定期的なレビュー</strong>: 環境の変化（新しいアプリケーションの導入、ユーザーの役割変更など）に合わせて、条件付きアクセス ポリシーを定期的にレビューし、最新の状態に保つことが重要です。</p></li> <li><p><strong>Azure AD Identity Protectionとの連携</strong>: Entra ID Premium P2ライセンスにはAzure AD Identity Protectionが含まれており、リアルタイムの危険なサインインやユーザーのリスク検出が可能です。条件付きアクセス ポリシーは、これらのリスクシグナルに基づいてMFAを強制したり、アクセスをブロックしたりできます。</p></li> </ul> <h4 class="wp-block-heading">コスト</h4> <p>Azure Entra IDの条件付きアクセス機能を利用するには、<strong>Azure Entra ID Premium P1</strong>または<strong>Premium P2</strong>ライセンスが必要です。これらのライセンスは、ユーザーごとの月額料金で提供されます。</p> <ul class="wp-block-list"> <li><p><strong>Entra ID Free/Basic</strong>: 条件付きアクセスは利用できません。</p></li> <li><p><strong>Entra ID Premium P1</strong>: 条件付きアクセスの基本機能（MFA、デバイスの状態、場所など）を利用できます。</p></li> <li><p><strong>Entra ID Premium P2</strong>: P1の機能に加えて、Azure AD Identity Protectionのリスクベース条件付きアクセス（ユーザーリスク、サインインリスク）など、より高度なセキュリティ機能を利用できます。 [2]</p></li> </ul> <p>条件付きアクセス自体に直接的な追加料金は発生しませんが、基盤となるEntra IDのライセンスレベルがこの機能の利用可否を決定します。SaaSであるEntra IDのライセンス費用には、リザーブドインスタンスやスケジューリングによるコスト最適化は適用されません。</p> <h4 class="wp-block-heading">落とし穴</h4> <p>効果的な条件付きアクセスとMFAの導入には注意が必要です。</p> <ul class="wp-block-list"> <li><p><strong>ロックアウトのリスク</strong>: ポリシーの不適切な設定は、管理者を含むすべてのユーザーがEntra IDにサインインできなくなる「ロックアウト」を引き起こす可能性があります。緊急アクセスアカウントの除外と、「レポートのみ」モードでの十分なテストが必須です。</p></li> <li><p><strong>複雑すぎるポリシー</strong>: ポリシーが過度に複雑になると、管理が困難になり、予期せぬ競合やアクセス問題を引き起こす可能性があります。シンプルで明確なポリシー設計を心がけ、共通の要件は統合し、特定の例外のみを個別のポリシーで対応します。</p></li> <li><p><strong>MFA登録プロセスの課題</strong>: MFAを強制する前に、ユーザーがMFAを適切に登録できるよう、明確なガイダンスとサポートを提供することが重要です。MFA登録の強制ポリシーを導入することも有効です。</p></li> <li><p><strong>レガシー認証プロトコル</strong>: 一部のレガシーアプリケーションやデバイスは、モダン認証（OAuth 2.0/OpenID Connect）ではなく、レガシー認証プロトコル（POP3, IMAP4, SMTP, 旧式Exchange ActiveSyncなど）を使用する場合があります。これらのプロトコルはMFAをサポートしないため、条件付きアクセスでブロックすることを検討すべきです。</p></li> </ul> <h4 class="wp-block-heading">まとめ</h4> <p>Azure Entra IDの条件付きアクセスとMFAは、今日の複雑な脅威環境において、組織のリソースを保護するための不可欠なツールです。本記事では、そのアーキテクチャ、Graph APIを利用した設定手順、継続的な運用監視、セキュリティのベストプラクティス、コスト要因、そして導入における一般的な落とし穴について解説しました。ゼロトラストの原則に基づき、アイデンティティを新たなセキュリティ境界として捉え、きめ細やかなアクセス制御を実装することで、組織のサイバーセキュリティ態勢を大幅に強化できます。ポリシーを「レポートのみ」モードで慎重にテストし、緊急アクセスアカウントを保護することで、安全かつ効果的な導入が可能です。</p> <hr/> <p><strong>参考資料</strong>: [1] Microsoft Learn: 条件付きアクセスとは (更新日: 2024年4月11日 JST, Microsoft). URL: https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview [2] Microsoft Learn: 条件付きアクセスのライセンス要件 (更新日: 2024年4月11日 JST, Microsoft). URL: https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview#license-requirements [3] Microsoft Learn: Microsoft Graph の条件付きアクセス API の概要 (更新日: 2024年5月22日 JST, Microsoft). URL: https://learn.microsoft.com/ja-jp/graph/api/resources/conditionalaccesspolicy-overview?view=graph-rest-1.0 [4] Microsoft Learn: conditionalAccessPolicy リソースの種類 (更新日: 2024年5月22日 JST, Microsoft). URL: https://learn.microsoft.com/ja-jp/graph/api/resources/conditionalaccesspolicy?view=graph-rest-1.0 [5] Microsoft Learn: Azure AD のサインイン ログ (更新日: 2024年5月28日 JST, Microsoft). URL: https://learn.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-sign-ins [6] Microsoft Learn: 条件付きアクセスでの “レポートのみ” モード (更新日: 2024年4月11日 JST, Microsoft). URL: https://learn.microsoft.com/ja-jp/azure/active-directory/conditional-access/concept-conditional-access-report-only [7] Microsoft Learn: Azure AD での緊急アクセス アカウントの管理 (更新日: 2024年3月28日 JST, Microsoft). URL: https://learn.microsoft.com/ja-jp/azure/active-directory/roles/security-emergency-access-accounts</p>

flowchart TD
    A["ユーザーがアプリケーションにアクセスを試行"] --> B("Entra IDへの認証要求");
    B --> C{"条件付きアクセス ポリシーの評価"};
    C -- |ポリシーなしまたは除外| --> D["シングルサインオン (SSO) でアクセス"];
    C -- |ポリシーに一致| --> E{"条件の確認"};
    E -- |ユーザー/グループに一致| --> F{"デバイスの状態に一致"};
    F -- |場所/IPアドレスに一致| --> G{"アプリケーションに一致"};
    G -- |リアルタイムのリスクに一致| --> H{"付与コントロールの適用"};
    H -- |MFAの必須化| --> I["MFAプロンプト"];
    I --> J{"MFA成功"};
    J --> K["アプリケーションへのアクセス許可"];
    H -- |アクセスブロック| --> L["アクセス拒否"];
    J -- |MFA失敗| --> L;

# Microsoft Graph PowerShell SDKのインポート


# 事前に Install-Module Microsoft.Graph.Identity.Governance を実行してインストールしてください。

Import-Module Microsoft.Graph.Identity.Governance

# 認証スコープの設定


# Policy.ReadWrite.ConditionalAccess スコープは条件付きアクセス ポリシーの読み取りと書き込みを許可します。

$scopes = "Policy.ReadWrite.ConditionalAccess"
Connect-MgGraph -Scopes $scopes

# ポリシー名と対象グループの指定

$policyName = "Require MFA for All Cloud Apps for Specific Group"
$targetGroupId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 対象とするEntra IDグループのオブジェクトIDを指定

# 条件付きアクセス ポリシーの定義 (JSON形式)


# - Users: 特定のグループを対象 (IncludeGroups)


# - Applications: 全てのクラウドアプリを対象 (IncludeApplications: "All")


# - ClientAppTypes: 全てのクライアントアプリタイプ (ブラウザ、モバイルアプリなど) を対象


# - GrantControls: MFAを必須 (builtInControls: "mfa")


# 計算量: この操作は単一のGraph API呼び出しであるため、O(1)に相当します。


# メモリ条件: ポリシー定義オブジェクトのサイズは小さく、最小限のメモリ消費です。

$policyDefinition = @{
    displayName = $policyName
    state = "enabledForReportingButBlocked" # まずは「レポートのみ」モードで作成し、影響を確認することを推奨
    conditions = @{
        users = @{
            includeGroups = @($targetGroupId)
        }
        applications = @{
            includeApplications = @("All")
        }
        clientAppTypes = @("all")
    }
    grantControls = @{
        operator = "OR" # 複数のコントロールがある場合、いずれかを満たせば良い
        builtInControls = @("mfa") # 多要素認証を必須とする
    }
} | ConvertTo-Json -Depth 5

# Graph APIを呼び出してポリシーを作成


# New-MgIdentityConditionalAccessPolicy コマンドレットを使用します。

try {
    $policy = New-MgIdentityConditionalAccessPolicy -Body $policyDefinition
    Write-Host "条件付きアクセス ポリシー '$policyName' が作成されました。ID: $($policy.Id)"
    Write-Host "状態: $($policy.State)。テストのため、まずは 'enabledForReportingButBlocked' で運用を開始してください。"
} catch {
    Write-Error "ポリシーの作成中にエラーが発生しました: $($_.Exception.Message)"
}

# 作成されたポリシーの確認 (オプション)


# Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id | Format-List DisplayName, State, Conditions, GrantControls