CSPセキュリティ要件（GDAP）の期限延長に伴うマルチテナント・ガバナンス設計

PowerShellカテゴリを表すパンダのイラスト PowerShell
2026.07.19

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

CSPセキュリティ要件（GDAP）の期限延長に伴うマルチテナント・ガバナンス設計

【導入】

CSPのセキュリティ要件猶予に伴い、DAPからGDAPへの移行と、顧客テナントをセキュアに一元管理するマルチテナント統制を最適化します。

【アーキテクチャ設計】

本アーキテクチャは、MicrosoftがCSP（クラウドソリューションプロバイダー）パートナーに対して義務付けている「GDAP（Granular Delegated Admin Privileges：きめ細かな委任された管理者権限）」への移行と、従来のDAP（Delegated Admin Privileges）の安全な廃止を前提とした、セキュリティおよび統制モデルです。

パートナーテナント側で厳格なMFA（多要素認証）および条件付きアクセスを適用したうえで、顧客テナントに対して「最小特権（Least Privilege）」に基づいたロールベースのアクセス（RBAC）を委任します。また、Microsoft Lighthouseを利用することで、複数顧客のセキュリティ状態を一元監視可能にします。

graph TD
    subgraph PartnerTenant["パートナーテナント（管理側）"]
        PA["パートナー技術者"] -->|1. FIDO2 / Authenticator MFA| CA["条件付きアクセス"]
        CA -->|2. セキュリティグループに所属| SG["技術グループ: 例: Tier 2 サポート"]
    end

    subgraph GDAPConnection["信頼関係境界"]
        SG -->|3. GDAP関係の定義（期間・ロール制限）| GDAP["GDAP リレーションシップ"]
    end

    subgraph CustomerTenant["顧客テナント（被管理側）"]
        GDAP -->|4. 必要最小限のロール割り当て| EntraCustomer["顧客 Entra ID"]
        EntraCustomer -->|5. アクセス制限| Resource["M365 / Azure リソース"]
        MFA_C["顧客の条件付きアクセス"] -->|MFA信頼の有効化| EntraCustomer
    end

    style PartnerTenant fill:#e1f5fe,stroke:#039be5,stroke-width:2px
    style CustomerTenant fill:#efebe9,stroke:#5d4037,stroke-width:2px
    style GDAPConnection fill:#f1f8e9,stroke:#7cb342,stroke-width:2px

【実装・デプロイ手順】

DAPの廃止およびGDAP移行のタイムライン延長期間中に、パートナーはすべての顧客テナントに対してGDAP関係を構築し、割り当てを完了させる必要があります。以下は、Microsoft Graph PowerShellを用いたGDAP関係の自動化と、従来のDAPを廃止・検証するためのスクリプト例です。

1. 必要なPowerShellモジュールのインストールと接続

# 必要なMicrosoft Graphベータ版モジュールのインストール

Install-Module Microsoft.Graph.Beta -Scope CurrentUser -Force

# パートナーセンターの全体管理者または特権ロール管理者として接続

Connect-MgGraph -Scopes "DelegatedAdminRelationship.ReadWrite.All", "Directory.Read.All"

2. GDAPリレーションシップの作成（APIベースのドラフト作成）

顧客テナント（CustomerTenantId）に対して、2年間（730日）有効な、特定ロールを含むGDAPリレーションシップを作成します。

$customerTenantId = "CUSTOMER_TENANT_ID_GUID" # 顧客のテナントID
$relationshipName = "Managed Services GDAP - Tier 2 Support"

# GDAP関係テンプレートの定義（Directory Readers, Service Support Administrators等の役割）

$roles = @(
    @{ @( "directoryRoles/729827e3-9c14-49f7-bb1b-9608f156bbb8" ) }, # Directory Readers
    @{ @( "directoryRoles/3a073c61-4c9d-476a-9293-ee01ca9f0632" ) }  # Service Support Administrator
)

$params = @{
    displayName = $relationshipName
    partnerTenantId = "YOUR_PARTNER_TENANT_ID_GUID"
    customer = @{
        tenantId = $customerTenantId
    }
    privilegedSystemRoles = @()
    duration = "P730D" # 730日間（2年）有効
}

# GDAPリレーションシップの作成

New-MgBetaPartnerDelegatedAdminRelationship -BodyParameter $params

3. 旧DAP（委任された管理者権限）の関係解除

GDAP移行が完了し、動作確認が行われた後、セキュリティリスク低減のために旧DAP接続を削除します。

# 既存のDAP関係（パートナーセンターの契約一覧）から削除対象を特定し廃止する処理


# ※パートナーセンターAPIまたはポータルから実施することを強く推奨

Write-Host "DAPを廃止し、GDAP（Granular）へ完全にシフトするには、パートナーポータルの『顧客』セクションから、該当顧客のDAP接続の削除を選択してください。" -ForegroundColor Yellow

【アイデンティティとセキュリティ】

GDAPの猶予期間が延長されたからといって、セキュリティ移行を遅らせることは推奨されません。GDAPモデルに準拠するための、アイデンティティ設計の核心は以下の通りです。

1. 条件付きアクセス（Conditional Access）の設計

パートナーテナントから顧客テナントにアクセスする際、顧客側テナントの条件付きアクセスポリシーで「クロステナントのMFA信頼」を有効化します。

  • パートナーテナントでのポリシー: パートナーの全技術者に強力な認証（FIDO2 / パスワードレス）を要求。

  • 顧客テナントでのクロステナントアクセス設定: External Identities ＞ クロステナントのアクセス設定 にて、パートナーテナントを登録し、「信頼設定（Trust settings）」で「異種（外部）Entra ID テナントからの多要素認証（MFA）を信頼する」にチェック。これにより、パートナー技術者が顧客テナントに入る際に、再度のMFA登録（二重ログイン摩擦）を回避できます。

2. 最小特権のロール定義

Global Administrator（全体管理者）の委任は原則廃止し、ティアごとに適切なロールのみを付与します。

サポートレベル 推奨される委任ロール
Tier 1 (L1サポート) サービスサポート管理者、ヘルプデスク管理者
Tier 2 (エスカレーション) ユーザー管理者、Exchange管理者、SharePoint管理者
Tier 3 (エンジニア・構築) インフラ管理者、Intune管理者、条件付きアクセス管理者

【運用・コスト最適化】

1. 可観測性（Observability）の一元管理

マルチテナント監査ログを統合管理するため、Azure Lighthouse を利用して顧客テナントの Entra ID 監査ログ および サインインログ を、パートナー側の中央の「Azure Log Analytics ワークスペース」にストリーミングします。これにより、インシデント発生時に単一のクエリ（KQL）でクロステナント解析が可能になります。

// パートナー技術者による顧客テナント内での操作履歴を追跡するKQL例
AuditLogs
| search "DelegatedAdmin" or "GDAP"
| project TimeGenerated, OperationName, TargetResources[0].displayName, InitiatedBy.user.userPrincipalName, Result
| order by TimeGenerated desc

2. コスト最適化の視点

  • 追加ライセンス不要: GDAP機能、Azure Lighthouseの利用自体には追加のライセンス費用は発生しません（※Log Analyticsのデータインジェストコストのみパートナー側または顧客側のいずれかで精算します）。

  • アカウントコストの削減: 顧客テナント個別に作成していた「管理用ローカルアカウント（M365ライセンス割り当てを含むケースがある）」を廃止し、GDAP経由のアイデンティティ統合を行うことで、無駄な顧客ライセンスの消費を排除します。

【まとめ】

GDAPへの完全移行と拡張サービス条件を管理する上での、移行ロードマップにおける3つの注意点：

  1. DAP自動廃止の罠に注意する MicrosoftによるDAPの段階的廃止は継続して進んでおり、猶予期限が一部延長されたとしても「DAPが突然切断されてサポートアクセスができなくなる」リスクは残ります。すべての顧客に対して速やかにGDAPへの移行バッチを実行してください。

  2. クロステナントMFA信頼の不整合を回避する 顧客テナントの「クロステナントアクセス設定」が未設定の場合、パートナー側でMFAを完了していても、顧客テナント側で追加のMFA登録を求められ、運用効率が著しく低下します。顧客側の初期設定を手順化することが必須です。

  3. 有効期限（Duration）の管理を自動化する GDAP関係には最長730日（2年）の有効期限があります。期限が切れると自動的にアクセス権が消滅するため、パートナーセンターのAPIまたはアラート機能を活用し、期限切れ30日前には再申請（Relationship Renewal）を自動通知する運用プロセスを確立してください。

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

コメント

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