Microsoft Entra Identity Governance を活用したモダンなアクセス管理戦略

Tech

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

Microsoft Entra Identity Governance を活用したモダンなアクセス管理戦略

クラウド環境とハイブリッド環境が混在する現代において、アイデンティティとアクセス管理（IAM）は組織のセキュリティとコンプライアンスの基盤となります。特にMicrosoft 365環境を利用する企業では、Microsoft Entra Identity Governance (旧 Azure AD Identity Governance) が、従業員のデジタルアイデンティティのライフサイクル全体にわたるアクセス権の管理と監査を効率化するための強力なツールとして注目されています。本記事では、Microsoft Entra Identity Governanceを活用したモダンなアクセス管理戦略について、アーキテクチャ、具体的な設定手順、運用監視、セキュリティ、コスト最適化、そして導入における注意点までをクラウドアーキテクトの視点から解説します。

1. Microsoft Entra Identity Governance のアーキテクチャ

Microsoft Entra Identity Governanceは、Microsoft Entra IDを中核とし、ユーザーのアクセス権限のライフサイクルを管理するための複数の機能群で構成されています。これには、Access Reviews（アクセスレビュー）、Entitlement Management（エンタイトルメント管理）、Privileged Identity Management (PIM)（特権ID管理）、Lifecycle Workflows（ライフサイクルワークフロー）などが含まれます。これらの機能は連携し、アクセス権の付与、見直し、削除、そして特権アクセスの管理を自動化・簡素化します。

アーキテクチャの主要コンポーネント:

  • Microsoft Entra ID: すべてのアイデンティティ情報の中心リポジトリ。ユーザー、グループ、アプリケーションなどの情報が一元管理されます。

  • Access Reviews: 特定のリソースやロールへのアクセス権を定期的に見直し、不要なアクセス権を特定・削除するプロセスを自動化します。

  • Entitlement Management: アクセスパッケージを通じて、リソースへのアクセス権の要求、承認、プロビジョニング、およびライフサイクル管理をセルフサービス化します。

  • Privileged Identity Management (PIM): 管理者ロールやAzureリソースへの特権アクセスをJust-In-Time (JIT) 方式で提供し、権限昇格の監視と監査を強化します。

  • Lifecycle Workflows: ユーザーのライフサイクルイベント（入社、異動、退社など）に基づいて、アカウントの作成、グループメンバーシップの変更、アクセスパッケージの割り当て解除などのタスクを自動実行します。

  • Microsoft Graph API: これらのIdentity Governance機能をプログラムで操作し、他のシステムやカスタムワークフローとの統合を可能にします。

このアーキテクチャは、最小特権の原則を徹底し、セキュリティリスクを低減しながら、ユーザーが業務に必要なリソースへ迅速かつ適切にアクセスできる環境を提供することを目指しています。

flowchart TD
    subgraph Identity Governance Core
        A["Microsoft Entra ID"]
        B("Lifecycle Workflows")
        C("Entitlement Management")
        D("Access Reviews")
        E("Privileged Identity Management: PIM")
    end

    U["ユーザー"] --> |アクセス要求| C
    U --> |ロールアクティベート要求| E
    B --> |アカウント管理| A
    C --> |アクセス権付与/削除| A
    D --> |アクセス権レビュー| A
    E --> |一時的な特権ロール付与| A

    A --> |監査ログ出力| F("Microsoft Sentinel / Log Analytics")
    A --> |ポリシー適用| G("条件付きアクセス")

    C --> |アクセスパッケージ| H["Microsoft 365グループ"]
    C --> |アクセスパッケージ| I["SharePointサイト"]
    C --> |アクセスパッケージ| J["SaaSアプリケーション"]

    E --> |リソースへのJITアクセス| K["Azureサブスクリプション"]
    E --> |リソースへのJITアクセス| L["Microsoft Entraロール"]

    G --> |多要素認証要求| U
    F --> |セキュリティ監視| SOC["セキュリティ運用センター"]

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style E fill:#fcf,stroke:#333,stroke-width:2px
    style C fill:#ccf,stroke:#333,stroke-width:2px
    style D fill:#cff,stroke:#333,stroke-width:2px
    style B fill:#fec,stroke:#333,stroke-width:2px

2. 主要機能と設定手順の具体例

2.1. Entitlement Management によるセルフサービスアクセス管理

Entitlement Managementは、アクセスパッケージと呼ばれるリソースの集合体を通じて、ユーザーが自分でアクセス権を要求し、承認ワークフローを経て自動的にプロビジョニングされる仕組みを提供します。

設定手順例: Microsoft Graph PowerShell SDK を使用したアクセスパッケージの作成

この例では、既存のMicrosoft Entraカタログ内に新しいアクセスパッケージを作成し、特定のMicrosoft 365グループのメンバーシップをそのパッケージに含める手順を示します。

# Microsoft Graph PowerShell SDKのインストール（初回のみ）


# Install-Module Microsoft.Graph -Scope CurrentUser

# 認証: EntitlementManagement.ReadWrite.All, Group.Read.All, Application.Read.All などのスコープが必要


# Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All", "Group.Read.All", "Directory.Read.All"

# 1. カタログの取得または作成


# 既存のカタログIDを指定します。ここでは "General Access" という名前のカタログを検索

$catalog = Get-MgEntitlementManagementCatalog -Filter "displayName eq 'General Access'"
if (-not $catalog) {

    # カタログが存在しない場合は作成

    $newCatalogParams = @{
        DisplayName = "General Access"
        Description = "一般的な社内リソースへのアクセスを管理するカタログ"
        IsExternallyVisible = $false # 外部ユーザーに表示しない
    }
    $catalog = New-MgEntitlementManagementCatalog -BodyParameter $newCatalogParams
    Write-Host "新しいカタログ '$($catalog.DisplayName)' が作成されました。ID: $($catalog.Id)"
}
$catalogId = $catalog.Id

# 2. アクセスパッケージの作成

$accessPackageName = "Project Alpha Members Access"
$description = "プロジェクトアルファのメンバーが利用するリソースへのアクセス"
$isHidden = $false # ユーザーがセルフサービスで閲覧可能にするか

$accessPackageParams = @{
    DisplayName = $accessPackageName
    Description = $description
    IsHiddenInNewSelection = $isHidden
    CatalogId = $catalogId
}

$newAccessPackage = New-MgEntitlementManagementAccessPackage -BodyParameter $accessPackageParams
Write-Host "アクセスパッケージ '$($newAccessPackage.DisplayName)' が作成されました。ID: $($newAccessPackage.Id)"

# 3. アクセスパッケージにリソースロールを追加（例: Microsoft 365グループのメンバーシップ）


# 事前に作成済みのMicrosoft 365グループのIDを取得

$targetGroupName = "Project Alpha Development Team"
$targetGroup = Get-MgGroup -Filter "DisplayName eq '$targetGroupName'"
if (-not $targetGroup) {
    Write-Error "グループ '$targetGroupName' が見つかりません。先に作成してください。"
    exit
}
$targetGroupId = $targetGroup.Id

$groupAssignmentParams = @{
    Value = @{
        Id = $targetGroupId
        Type = "Group"
    }
    Role = @{
        Id = "858d4a57-c817-478a-a5c9-c18227b458c2" # このIDは "Member" ロールに対応する組み込みリソースロールID
        DisplayName = "Member"
        Description = "メンバー"
    }
}

New-MgEntitlementManagementAccessPackageResourceRole -AccessPackageId $newAccessPackage.Id -BodyParameter $groupAssignmentParams

Write-Host "アクセスパッケージにグループ '$targetGroupName' のメンバーシップが追加されました。"

# 4. アクセスパッケージにポリシーを追加（例: 組織内の全員が申請可能、承認者なし）


# 実際には承認者やアクセスレビュー設定などを構成します。

$policyDisplayName = "全員が申請可能（承認者なし）"
$policyDescription = "組織内のすべてのユーザーがこのアクセスパッケージを申請できます。"

$policyParams = @{
    DisplayName = $policyDisplayName
    Description = $policyDescription
    AccessPackageId = $newAccessPackage.Id
    RequestorSettings = @{
        EnableTargetsToSelfAdd = $true # ユーザーが自身で要求できる
        ScopeType = "AllExistingDirectoryMembers" # ディレクトリ内のすべてのメンバー
        SpecificDirectoryTargets = @()
    }
    RequestApprovalSettings = @{
        IsApprovalRequired = $false # 承認は不要
    }
    AssignmentReviewSettings = @{
        Is          = $false # アクセスレビューは行わない (必要に応じて $true に設定)
    }
}

New-MgEntitlementManagementAccessPackageAssignmentPolicy -AccessPackageId $newAccessPackage.Id -BodyParameter $policyParams

Write-Host "アクセスパッケージに申請ポリシーが追加されました。"

# 後処理: 接続を解除


# Disconnect-MgGraph

解説: 上記のPowerShellスクリプトは、Microsoft Graph APIを介してEntitlement ManagementのAccess Packageを作成する基本的な流れを示しています。まずカタログを準備し、次に新しいAccess Packageを定義します。その後、特定のMicrosoft 365グループをリソースとして追加し、最後に誰がどのようにそのパッケージを要求できるかを定義するポリシーを設定します。これにより、ユーザーはMy Accessポータルからこのパッケージを要求できるようになります。

2.2. Privileged Identity Management (PIM) による特権アクセスの管理

PIMは、管理者ロールやAzureリソースへの永続的な特権アクセスを最小限に抑え、必要な時にのみ昇格できるJust-In-Time（JIT）アクセスを提供します。

設定手順例: Azure CLI を使用したAzureリソースロールのPIM有効化とアクティベーション

  1. AzureリソースロールのPIM有効化（GUIまたはAzure PowerShell/Graph API）: Azureポータルで、特定のサブスクリプションまたはリソースグループの「アクセス制御 (IAM)」に移動し、「Privileged access」ブレードでPIMを有効にします。ここでロール設定を行い、アクティベーション要件（MFA、承認、期間など）を構成します。 Azure PowerShellでPIMを有効にするには、New-AzPimAzureResourceRoleAssignment や New-AzPimAzureResourceRoleSetting コマンドレットを使用しますが、これにはPIM for Azureリソースの登録や複雑な設定が必要です。 ここでは、アクティベーション手順に焦点を当てます。

  2. Azure CLI を使用したPIMロールのアクティベーション: PIMが設定された「Contributor」ロールを一時的にアクティベートする例です。

    # 1. 認証 (まだログインしていない場合)


# az login

# 2. アクティベートしたいAzureリソースのスコープとロール定義IDを取得


# スコープの例: AzureサブスクリプションID

subscription_id="/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# Contributorロールの定義ID

role_definition_id="b24988ac-6180-42a0-ab88-20f7382dd24c"

# 3. PIMロールのアクティベーション要求を送信


# 必要に応じて、--reason と --duration を指定

az rest --method POST \
        --url "https://graph.microsoft.com/v1.0/me/directory/roleManagement/azureRoles/roleAssignments" \
        --headers "Content-Type=application/json" \
        --body "{ \
            \"roleDefinitionId\": \"$role_definition_id\", \
            \"resourceScope\": \"$subscription_id\", \
            \"requestType\": \"SelfActivate\", \
            \"justification\": \"プロジェクト作業のための一時的なContributorアクセス\", \
            \"duration\": \"PT8H\" \
        }"

# 注: 上記はGraph APIの直接呼び出し例です。Azure CLIのPIMコマンドは現在プレビューまたは限定的です。


# 実際には、Azure CLIの `az ad pim` コマンドが利用できる場合はそちらを推奨します。


# 例（プレビュー機能の場合）：az ad pim role assignment activate --scope $subscription_id --role-definition-id $role_definition_id --reason "緊急対応" --duration 4h

    解説: 上記は、Graph APIを直接呼び出してPIMのロールアクティベーションを要求する例です。roleDefinitionId はAzureの組み込みロールのID、resourceScope はアクティベート対象のリソース（この場合はサブスクリプション全体）を指定します。justification（理由）とduration（期間）は、アクティベーション時の監査情報として重要です。これにより、永続的な特権アクセスを廃止し、セキュリティ体制を大幅に強化できます。

3. 運用監視と可観測性

Identity Governanceの適切な運用には、継続的な監視と可観測性の確保が不可欠です。

  • 監査ログ: Microsoft Entra IDの監査ログは、Identity Governance機能のすべての操作（アクセスレビューの開始、アクセスパッケージの要求/承認、PIMのアクティベーションなど）を記録します。これらはMicrosoft Entra管理センターで確認できるほか、診断設定を通じてAzure Log AnalyticsワークスペースやAzure Storageアカウントにエクスポートできます。

  • Log Analytics: 監査ログをLog Analyticsにエクスポートすることで、Kusto Query Language (KQL) を使用して詳細な分析やカスタムダッシュボードの作成が可能になります。異常なアクティビティ、拒否されたアクセス要求、期限切れのアクセスレビューなどを監視するアラートを設定できます。

  • レポート: Access Reviewsの結果レポート、Entitlement Managementのアクセスパッケージ利用状況レポート、PIMのアクティベーション履歴レポートなどが標準で提供され、コンプライアンス監査やセキュリティレビューに活用できます。

  • SLAとバックアップ/DR: Microsoft Entra ID自体はMicrosoftが管理するグローバルサービスであり、高可用性(HA)と災害復旧(DR)が組み込まれています。ユーザーやグループ、ロールのバックアップは通常不要ですが、Identity Governanceの設定（アクセスパッケージ、レビュー定義など）はMicrosoft Graph APIを通じてエクスポート・インポートすることで、構成のバックアップとバージョン管理を行うことが可能です。

4. セキュリティ強化と権限境界

Identity Governanceは、ゼロトラストの原則に基づき、組織のセキュリティ体制を強化します。

  • 最小特権の原則 (Principle of Least Privilege – PoLP): PIMとEntitlement Managementにより、ユーザーが必要な時に必要なアクセス権のみを持つよう強制し、永続的な広範囲のアクセス権を排除します。

  • 条件付きアクセス (Conditional Access – CA): PIMやEntitlement Managementと連携させ、特権ロールのアクティベーション時やアクセスパッケージへのアクセス時に、多要素認証（MFA）、準拠デバイス、特定の場所からのアクセスなど、追加のセキュリティ要件を強制できます。

  • カスタムセキュリティ属性: Entra IDのカスタムセキュリティ属性と組み合わせて、よりきめ細やかなアクセス制御ポリシーやアクセスレビューの対象設定が可能です。

  • 特権アクセスワークステーション (PAW): 特権IDを使用する管理者は、マルウェアやフィッシング攻撃から保護されたPAWからのみアクセスするようにすることで、攻撃サーフェスを最小限に抑えます。

  • Microsoft Defender for Cloud Apps (MCAS) / Microsoft Defender for Identity: Identity GovernanceのログとこれらのDefender製品の情報を統合することで、異常な挙動や特権昇格後の不審なアクティビティをより高度に検知し、対応することができます。

5. コスト最適化戦略

Microsoft Entra Identity Governanceの機能を利用するには、通常、Microsoft Entra ID P2ライセンスまたはMicrosoft 365 E5ライセンスが必要です。

  • ライセンスコスト:

    • Microsoft Entra ID P2: Access Reviews, Entitlement Management, PIM, Lifecycle Workflows の主要機能が含まれます。ユーザー数に応じたコストがかかります。

    • Microsoft 365 E5: Microsoft Entra ID P2の機能に加えて、Microsoft 365の他のセキュリティ・コンプライアンス機能が含まれるため、包括的なソリューションを求める場合に適しています。

  • 最適化のポイント:

    • 不要なライセンスの削減: Identity Governanceを活用し、不要なユーザーやグループへのアクセス権を定期的に見直すことで、結果的にライセンス数を最適化できる可能性があります。

    • PIMによるライセンス節約の可能性: 一部の特権ロールにおいては、PIMを導入することで、一時的にライセンスを割り当てる運用が可能になる場合もありますが、基本的にはPIMを利用するユーザーにはP2ライセンスが必要です。

    • 管理効率の向上: 手動でのアクセス管理作業を自動化することで、IT管理者の工数を削減し、人件費の最適化に繋がります。

ライセンス計画は、組織のユーザー数、必要な機能、および既存のMicrosoft 365契約を考慮して慎重に評価する必要があります。

6. 導入における落とし穴と対策

Identity Governanceの導入は多大なメリットをもたらしますが、いくつかの課題に直面する可能性があります。

  • 組織文化への適応不足: ユーザーがセルフサービスポータル（My Access）の使用に慣れていない、またはPIMの「Just-In-Time」アクセスに抵抗がある場合があります。

    • 対策: 導入前に十分なユーザー教育とトレーニングを実施し、メリットを明確に伝えることが重要です。ロールアウトは段階的に行い、フィードバックを収集して改善を繰り返します。

  • 複雑な承認ワークフローの設計: Entitlement Managementの承認プロセスが複雑になりすぎると、承認の遅延やユーザーの不満につながります。

    • 対策: 承認ワークフローはできるだけシンプルに保ち、必要に応じて複数段階承認や代替承認者を設定します。定期的にワークフローの効率性を評価し、見直しを行います。

  • 既存システムとの連携課題: Identity GovernanceはMicrosoft Entra IDベースであるため、オンプレミスのシステムや非Microsoftクラウドサービスとの統合には追加の工夫が必要な場合があります。

    • 対策: Microsoft Graph APIやSCIM (System for Cross-domain Identity Management) などの標準プロトコルを活用し、連携計画を慎重に立てます。必要に応じてカスタムコネクタや自動化スクリプトを開発します。

  • アクセスレビュー疲れ (Access Review Fatigue): 頻繁なアクセスレビューは承認者の負担となり、形骸化する恐れがあります。

    • 対策: レビューの頻度と対象範囲を適切に調整します。自動承認ルールや拒否推奨機能、グループ所有者によるレビューなど、レビュープロセスの効率化を図ります。

7. まとめ

Microsoft Entra Identity Governanceは、今日の複雑なIT環境において、組織が効果的なアクセス管理とセキュリティ体制を確立するための不可欠なソリューションです。Access Reviewsによる継続的なアクセス権の監査、Entitlement Managementによるセルフサービス化と自動化、PIMによる特権アクセスの厳格な管理、そしてLifecycle Workflowsによるユーザーライフサイクル管理の自動化は、最小特権の原則を実現し、コンプライアンス要件を満たす上で強力な支援となります。

本記事で解説したアーキテクチャ、具体的な設定手順、運用監視、セキュリティ強化のポイント、コスト最適化戦略、そして導入の落とし穴とその対策を参考に、貴社のセキュリティ戦略にMicrosoft Entra Identity Governanceを組み込むことで、より安全で効率的なデジタルワークプレイスを実現できるでしょう。導入計画を綿密に立て、組織全体で協力しながら、モダンなアクセス管理の実現を目指してください。

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

コメント

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