Azure Key Vault を使用して Azure Cosmos DB アカウント用にクロステナントのカスタマーマネージドキーを構成する

[アーティクル]
08/15/2024

適用対象: NoSQL MongoDB Cassandra Gremlin Table

Azure Cosmos DB アカウントに格納されるデータは、Microsoft によって管理されるサービスマネージドキーを使って自動的かつシームレスに暗号化されます。ただし、顧客が管理するキーを使って暗号化の第 2 のレイヤーを追加できます。このようなキーは、カスタマーマネージドキー (または CMK) と呼ばれます。カスタマーマネージドキーは、Azure Key Vault のインスタンスに格納されます。

この記事では、Azure Cosmos DB アカウントを作成するときにカスタマーマネージドキーを使って暗号化を構成する手順について説明します。このクロステナントのシナリオの例では、Azure Cosmos DB アカウントは、サービスプロバイダーと呼ばれる独立系ソフトウェアベンダー (ISV) によって管理されるテナントに存在します。 Azure Cosmos DB アカウントの暗号化に使われるキーは、顧客が管理する別のテナントのキーコンテナーに存在します。

クロステナントのカスタマーマネージドキーについて

Azure でサービスとしてのソフトウェア (SaaS) オファリングを構築している多くのサービスプロバイダーは、顧客に独自の暗号化キーを管理するオプションを提供したいと考えています。カスタマーマネージドキーを使用すると、サービスプロバイダーは、サービスプロバイダーの顧客によって管理され、サービスプロバイダーからアクセスできない暗号化キーを使用して、顧客のデータを暗号化できます。 Azure では、サービスプロバイダーの顧客は Azure Key Vault を使って、独自の Microsoft Entra テナントとサブスクリプションで暗号化キーを管理できます。

サービスプロバイダーが所有し、サービスプロバイダーのテナントに存在する Azure プラットフォームサービスとリソースでは、暗号化/暗号化解除操作を実行するために、顧客のテナントからキーにアクセスする必要があります。

次の図は、サービスプロバイダーとその顧客にまたがるクロステナントの CMK ワークフローでフェデレーション ID を使用した保存時のデータ暗号化を示しています。

上の例では、独立したサービスプロバイダーのテナント ("テナント 1") と顧客のテナント ("テナント 2") の、2 つの Microsoft Entra テナントがあります。 "テナント 1" は Azure プラットフォームサービスをホストし、"テナント 2" は顧客のキーコンテナーをホストします。

サービスプロバイダーによって、"テナント 1" 内にマルチテナントアプリケーションの登録が作成されます。ユーザー割り当てマネージド ID を使用して、このアプリケーションにフェデレーション ID 資格情報が作成されます。次に、アプリの名前とアプリケーション ID が顧客と共有されます。

適切なアクセス許可を持つユーザーは、顧客テナント "テナント 2" にサービスプロバイダーのアプリケーションをインストールします。次にユーザーは、インストールされているアプリケーションに関連付けられているサービスプリンシパルに、顧客のキーコンテナーへのアクセス権を付与します。顧客はまた、暗号化キー (カスタマーマネージドキー) をキーコンテナーに格納します。顧客は、キーの場所 (キーの URL) をサービスプロバイダーと共有します。

これでサービスプロバイダーには次の情報があります。

顧客のテナント内にインストールされ、カスタマーマネージドキーへのアクセスが許可されている、マルチテナントアプリケーションのアプリケーション ID。
マルチテナントアプリケーション上の資格情報として構成されたマネージド ID。
顧客のキーコンテナー内のキーの場所。

この 3 つのパラメーターを使用して、サービスプロバイダーは "テナント 2" のカスタマーマネージドキーで暗号化できる "テナント 1" 内の Azure リソースをプロビジョニングします。

上記のエンドツーエンドソリューションを 3 つのフェーズに分割しましょう。

サービスプロバイダーは ID を構成します。
顧客は、サービスプロバイダーのマルチテナントアプリに対し、Azure Key Vault 内の暗号化キーへのアクセス権を付与します。
サービスプロバイダーは、CMK を使用して Azure リソース内のデータを暗号化します。

フェーズ 1 の操作は、ほとんどのサービスプロバイダーアプリケーションに対して 1 回限りの設定となります。フェーズ 2 とフェーズ 3 の操作は、顧客ごとに繰り返されます。

フェーズ 1 - サービスプロバイダーが Microsoft Entra アプリケーションを構成する

Step	説明	Azure RBAC の最小ロール	Microsoft Entra RBAC の最小ロール
1.	新しいマルチテナント Microsoft Entra アプリケーションの登録を作成するか、既存のアプリケーションの登録から始めます。 Azure portal、Microsoft Graph API、Azure PowerShell、または Azure CLI を使用して、アプリケーション登録のアプリケーション ID (クライアント ID) をメモします	なし	アプリケーション開発者
2.	ユーザー割り当てマネージド ID を作成します (フェデレーション ID 資格情報として使用されます)。 Azure portal / Azure CLI / Azure PowerShell/ Azure Resource Manager テンプレート	マネージド ID 共同作成者	なし
3.	アプリケーションの ID を借用できるように、アプリケーションのフェデレーション ID 資格情報としてユーザー割り当てマネージド ID を構成します。 Graph API リファレンス/ Azure portal/ Azure CLI/ Azure PowerShell	なし	アプリケーションの所有者
4.	アプリケーション名とアプリケーション ID を顧客と共有し、顧客がアプリケーションをインストールして承認できるようにします。	なし	なし

サービスプロバイダーに関する考慮事項

Microsoft Entra アプリケーションの作成に Azure Resource Manager (ARM) テンプレートを使用することは推奨されていません。
同じマルチテナントアプリケーションを使用して、"テナント 2"、"テナント 3"、"テナント 4" など、複数のテナント内のキーにアクセスすることができます。各テナントでは、アプリケーション ID は同じだがオブジェクト ID は異なるアプリケーションの独立したインスタンスが作成されます。したがって、このアプリケーションの各インスタンスは個別に承認されます。この機能に使用されるアプリケーションオブジェクトを使用して、すべての顧客間でアプリケーションをパーティション分割する方法を検討します。
- 1 つのアプリケーションで使用できるフェデレーション ID 資格情報は最大 20 個なので、サービスプロバイダーはフェデレーション ID を顧客間で共有する必要があります。フェデレーション ID の設計に関する考慮事項と制限について詳しくは、「外部 ID プロバイダーを信頼するようにアプリを構成する」をご覧ください。
サービスプロバイダーが顧客ごとに 1 つのアプリケーションオブジェクトを使用するシナリオもまれにありますが、この場合は、すべての顧客で大規模にアプリケーションを管理するための多額のメンテナンスコストが必要になります。
サービスプロバイダーテナント内では、発行者の確認を自動化することはできません。

フェーズ 2 - 顧客がキーコンテナーへのアクセスを承認する

手順	説明	最小特権の Azure RBAC ロール	最小特権の Microsoft Entra ロール
1.	推奨: アプリにサインインするようにユーザーを送信します。ユーザーがサインインできる場合は、アプリのサービスプリンシパルがテナントに存在します。 Microsoft Graph、Microsoft Graph PowerShell、Azure PowerShell、または Azure CLI を使用して、サービスプリンシパルを作成します。管理者の同意 URL を作成し、アプリケーション ID を使用してサービスプリンシパルを作成するためのテナント全体にわたる同意を付与します。	なし	アプリケーションをインストールするアクセス許可を持つユーザー
2.	カスタマーマネージドキーとして使用されるキーと Azure キーコンテナーを作成します。	キーコンテナーを作成するには、ユーザーに Key Vault Contributor ロールを割り当てる必要がありますキーコンテナーにキーを追加するには、ユーザーに Key Vault Crypto Officer ロールを割り当てる必要があります	なし
3.	Key Vault Crypto Service Encryption User ロールを割り当てることで、同意したアプリケーション ID に、Azure キーコンテナーへのアクセス権を付与します	Key Vault Crypto Service Encryption User ロールをアプリケーションに割り当てるには、ユーザーアクセス管理者ロールが割り当てられている必要があります。	なし
4.	キーコンテナーの URL とキー名を、SaaS オファリングのカスタマーマネージドキー構成にコピーします。	なし	なし

Note

CMK を使用した暗号化のためにマネージド HSM へのアクセスを承認するには、こちらのストレージアカウントの例を参照してください。マネージド HSM を使用したキーの管理の詳細については、「Azure CLI を使用してマネージド HSM を管理する」を参照してください

サービスプロバイダーの顧客に関する考慮事項

顧客テナント "テナント 2" で、管理者は、管理者以外のユーザーがアプリケーションをインストールできないようにポリシーを設定できます。これらのポリシーによって、管理者以外のユーザーがサービスプリンシパルを作成できないようにすることができます。そのようなポリシーを構成した場合は、サービスプリンシパルを作成するアクセス許可を持ったユーザーの関与が必要になります。
Azure Key Vault へのアクセスは、Azure RBAC またはアクセスポリシーを使用して承認できます。キーコンテナーへのアクセスを許可する場合は、キーコンテナーのアクティブなメカニズムを使用するようにしてください。
Microsoft Entra アプリケーションの登録には、アプリケーション ID (クライアント ID) が使用されます。アプリケーションがテナントにインストールされると、サービスプリンシパルが作成されます。サービスプリンシパルでは、アプリ登録と同じアプリケーション ID が共有されますが、独自のオブジェクト ID が生成されます。アプリケーションにリソースへのアクセスを承認するには、サービスプリンシパル Name または ObjectID プロパティの使用が必要になる場合があります。

フェーズ 3 - サービスプロバイダーがカスタマーマネージドキーを使用して Azure リソース内のデータを暗号化する

フェーズ 1 と 2 が完了すると、サービスプロバイダーは、顧客のテナント内のキーとキーコンテナーと ISV のテナント内の Azure リソースを使用して、Azure リソース上の暗号化を構成できます。サービスプロバイダーは、その Azure リソースでサポートされているクライアントツール、ARM テンプレート、または REST API を使用して、クロステナントのカスタマーマネージドキーを構成できます。

クロステナントのカスタマーマネージドキーを構成する

このセクションでは、クロステナントのカスタマーマネージドキー (CMK) を構成し、顧客データを暗号化する方法について説明します。 Tenant2 のキーコンテナーに格納されている CMK を使用して、Tenant1 のリソース内の顧客データを暗号化する方法について説明します。 Azure portal、Azure PowerShell、または Azure CLI を使用できます。

Azure portal にサインインして、次の手順を実行します。

サービスプロバイダーが ID を構成します

次の手順は、サービスプロバイダーのテナント Tenant1 のサービスプロバイダーによって実行されます。

サービスプロバイダーが新しいマルチテナントアプリ登録を作成します

新しいマルチテナント Microsoft Entra アプリケーションの登録を作成するか、既存のマルチテナントアプリケーションの登録から始めることができます。既存のアプリケーション登録から始める場合は、アプリケーションのアプリケーション ID (クライアント ID) をメモします。

新しい登録を作成するには、次の手順に従います。

検索ボックスで Microsoft Entra ID を検索します。 Microsoft Entra ID 拡張機能を見つけて選びます。
左ウィンドウで、[管理] > [アプリの登録] を選択します。
[+ 新規登録] を選択します。
アプリケーションの登録の名前を指定して、[任意の組織ディレクトリ内のアカウント (任意の Microsoft Entra ディレクトリ - マルチテナント)] を選びます。
[登録] を選択します。
アプリケーションの ApplicationId/ClientId を メモします。

サービスプロバイダーは、ユーザー割り当てマネージド ID を作成します

フェデレーション ID 資格情報として使用されるユーザー割り当てマネージド ID を作成します。

検索ボックスで「マネージド ID」を検索します。 マネージド ID 拡張機能を見つけて選択します。
[+ 作成] を選択します。
マネージド ID のリソースグループ、リージョン、名前を指定します。
[Review + create](レビュー + 作成) を選択します。
デプロイが成功したら、ユーザー割り当てマネージド ID の Azure ResourceId をメモします。この ID は [プロパティ] にあります。次に例を示します。

/subscriptions/tttttttt-0000-tttt-0000-tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ConsotoCMKDemoUA

サービスプロバイダーは、ユーザー割り当てマネージド ID をアプリケーションのフェデレーション資格情報として構成します

アプリケーションの ID を借用できるように、アプリケーションのフェデレーション ID 資格情報としてユーザー割り当てマネージド ID を構成します。

[Microsoft Entra ID] > [アプリの登録] > 自分のアプリに移動します。
[証明書とシークレット] を選択します。
[フェデレーション資格情報] を選択します。
[資格情報の追加] を選択します。
[フェデレーション資格情報のシナリオ] で、[カスタマーマネージドキー] を選択します。
[マネージド ID の選択] をクリックします。ウィンドウからサブスクリプションを選択します。 [マネージド ID] で、[ユーザー割り当てマネージド ID] を選択します。 [選択] ボックスで、先ほど作成したマネージド ID を検索し、ウィンドウの下部にある [選択] をクリックします。
[資格情報の詳細] で、資格情報の名前と説明 (省略可能) を指定し、[追加] を選択します。

Azure PowerShell を使用して ISV のテナントを構成するには、最新の Az モジュールをインストールします。 PowerShell のインストールの詳細については、PowerShellGet を使用した Windows への Azure PowerShell のインストールに関する記事を参照してください。

Azure PowerShell をローカルで使用する場合は、次のようにします。
- Az PowerShell モジュールの最新バージョンをインストールします。
- Connect-AzAccount コマンドレットを使用して、Azure アカウントに接続します。
Azure Cloud Shell を使用する場合は、次のようにします。
- 詳細については、Azure Cloud Shell の概要に関するページを参照してください。

サービスプロバイダーが ID を構成します

次の手順は、サービスプロバイダーのテナント Tenant1 のサービスプロバイダー (ISV) によって実行されます。

サービスプロバイダーが Azure にサインインします

Azure PowerShell で、ISV のテナントにサインインし、アクティブなサブスクリプションを ISV のサブスクリプションに設定します。

$isvTenantId="<isv-tenant-id>"
$isvSubscriptionId="<isv-subscription-id>"

# Sign in to Azure in the ISV's tenant.
Connect-AzAccount -Tenant $isvTenantId
# Set the context to the ISV's subscription.
Set-AzContext -Subscription $isvSubscriptionId

サービスプロバイダーが新しいマルチテナントアプリ登録を作成します

Tenant1 でマルチテナントの登録済みアプリケーションの名前を選び、Azure portal でマルチテナントアプリケーションを作成します。

マルチテナントアプリケーションに対して指定した名前が、Tenant2 でアプリケーションを識別するために顧客によって使われます。アプリのオブジェクト ID とアプリケーション ID をメモします。これらの値は、後続のステップで必要になります。

$multiTenantAppName="<multi-tenant-app>"
$multiTenantApp = New-AzADApplication -DisplayName $multiTenantAppName `
    -SignInAudience AzureADMultipleOrgs

# Object ID for the new multi-tenant app
$objectId = $multiTenantApp.Id
# Application (client) ID for the multi-tenant app
$multiTenantAppObjectId = $multiTenantApp.AppId

サービスプロバイダーは、ユーザー割り当てマネージド ID を作成します

ISV のテナントにサインインしてから、フェデレーション ID の資格情報として使われるユーザー割り当てマネージド ID を作成します。新しいユーザー割り当てマネージド ID を作成するには、Microsoft.ManagedIdentity/userAssignedIdentities/write アクションを含むロールが割り当てられている必要があります。

$isvRgName="<isv-resource-group>"
$isvLocation="<location>"
$userIdentityName="<user-assigned-managed-identity>"

# Create a new resource group in the ISV's subscription.
New-AzResourceGroup -Location $isvLocation -ResourceGroupName $isvRgName

# Create the new user-assigned managed identity.
$userIdentity = New-AzUserAssignedIdentity -Name $userIdentityName `
    -ResourceGroupName $isvRgName `
    -Location $isvLocation `
    -SubscriptionId $isvSubscriptionId

サービスプロバイダーは、ユーザー割り当てマネージド ID をアプリケーションのフェデレーション資格情報として構成します

アプリケーションの ID を借用できるように、アプリケーションのフェデレーション ID 資格情報としてユーザー割り当てマネージド ID を構成します。

PowerShell からフェデレーション ID 資格情報を構成するには、まず Az.Resources モジュールのバージョン 6.3.0 以降をインストールします。

New-AzADAppFederatedCredential -ApplicationObjectId $multiTenantApp.Id `
    -Name "MyFederatedIdentityCredential" `
    -Audience "api://AzureADTokenExchange" `
    -Issuer "https://login.microsoftonline.com/<tenant-id>/v2.0" `
    -Subject $userIdentity.PrincipalId `
    -Description "Federated Identity Credential for CMK"

Azure Cloud Shell で Bash 環境を使用します。詳細については、「Azure Cloud Shell の Bash のクイックスタート」を参照してください。
CLI リファレンスコマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。
- ローカルインストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。認証プロセスを完了するには、ターミナルに表示される手順に従います。その他のサインインオプションについては、Azure CLI でのサインインに関するページを参照してください。
- 初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。拡張機能の詳細については、Azure CLI で拡張機能を使用する方法に関するページを参照してください。
- az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。最新バージョンにアップグレードするには、az upgrade を実行します。

サービスプロバイダーが ID を構成します

次の手順は、サービスプロバイダーのテナント Tenant1 のサービスプロバイダーによって実行されます。

サービスプロバイダーが Azure にサインインします

Azure にサインインして Azure CLI を使用します。

az login

サービスプロバイダーが新しいマルチテナントアプリ登録を作成します

Tenant1 でマルチテナントアプリケーションの名前を選び、Azure portal でマルチテナントアプリケーションを作成します。

マルチテナントアプリケーションに対して指定した名前が、Tenant2 でアプリケーションを識別するために顧客によって使われます。アプリのアプリケーション ID (またはクライアント ID)、アプリのオブジェクト ID、アプリのテナント ID をコピーします。これらの値は、次の手順で使用します。

multiTenantAppName="<multi-tenant-app>"
multiTenantAppObjectId=$(az ad app create --display-name $multiTenantAppName \
    --sign-in-audience AzureADMultipleOrgs \
    --query id \
    --output tsv)

multiTenantAppId=$(az ad app show --id $multiTenantAppObjectId --query appId --output tsv)

サービスプロバイダーは、ユーザー割り当てマネージド ID を作成します

isvSubscriptionId="<isv-subscription-id>"
isvRgName="<isv-resource-group>"
isvLocation="<location>"
userIdentityName="<user-assigned-managed-identity>"

az group create --location $isvLocation \
    --resource-group $isvRgName \
    --subscription $isvSubscriptionId

principalId=$(az identity create --name $userIdentityName \
    --resource-group $isvRgName \
    --location $isvLocation \
    --subscription $isvSubscriptionId \
    --query principalId \
    --out tsv)

サービスプロバイダーは、ユーザー割り当てマネージド ID をアプリケーションのフェデレーション資格情報として構成します

az ad app federated-credential create メソッドを実行して、アプリにフェデレーション ID 資格情報を構成し、外部 ID プロバイダーとの信頼関係を作成します。

フェデレーション ID 資格情報の audience 値として api://AzureADTokenExchange を使用します。詳細については、API リファレンスを参照してください。

# Create a file named "credential.json" with the following content.
# Replace placeholders in angle brackets with your own values.
{
    "name": "MyFederatedIdentityCredential",
    "issuer": "https://login.microsoftonline.com/<tenantID>/v2.0",
    "subject": "<user-assigned-identity-principal-id>",
    "description": "Federated Identity Credential for CMK",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}

az ad app federated-credential create --id $multiTenantAppObjectId --parameters credential.json

サービスプロバイダーがアプリケーション ID を顧客と共有する

マルチテナントアプリケーションのアプリケーション ID (クライアント ID) を見つけて、顧客と共有します。

顧客がサービスプロバイダーのアプリにキーコンテナー内のキーへのアクセスを許可する

次の手順は、顧客のテナント Tenant2 の顧客によって実行されます。顧客は Azure portal、Azure PowerShell、または Azure CLI を使用できます。

手順を実行するユーザーは、アプリケーション管理者、クラウドアプリケーション管理者、グローバル管理者などの特権ロールを持つ管理者である必要があります。

Azure portal にサインインして、次の手順を実行します。

顧客が顧客テナントにサービスプロバイダーアプリケーションをインストールする

サービスプロバイダーの登録済みアプリケーションを顧客のテナントにインストールするには、登録済みアプリからのアプリケーション ID で、サービスプリンシパルを作成します。サービスプリンシパルは、次のいずれかの方法で作成できます。

Microsoft Graph、Microsoft Graph PowerShell、Azure PowerShell、または Azure CLI を使用して、サービスプリンシパルを手動で作成します。
管理者の同意 URL を作成し、サービスプリンシパルを作成するためのテナント全体にわたる同意を付与します。 AppId を指定する必要があります。

顧客がキーコンテナーを作成する

キーコンテナーを作成するには、ユーザーのアカウントに Key Vault Contributor ロール、またはキーコンテナーの作成を許可する別のロールを割り当てる必要があります。

Azure portal メニューまたは [ホーム] ページで、[+リソースの作成] を選択します検索ボックスに「Key Vaults」と入力します。結果の一覧から [キーコンテナー] を選択します。 [キーコンテナー] ページで、[作成] を選択します。
[基本] タブで、サブスクリプションを選択します。 [リソースグループ] で、[新規作成] を選択し、リソースグループ名を入力します。
キーコンテナーの一意の名前を入力します。
リージョンと価格レベルを選択します。
新しいキーコンテナーの消去保護を有効にします。
[アクセスポリシー] タブで、[アクセス許可モデル] に [Azure ロールベースのアクセス制御] を選びます。
[確認および作成] 、 [作成] の順に選択します。

キーコンテナーの名前と URI を記録しておきます。キーコンテナーにアクセスするアプリケーションは。この URI を使う必要があります。

詳細については、「クイックスタート - Azure portal を使用して Azure キーコンテナーを作成する」を参照してください。

顧客は、Key Vault Crypto Officer ロールをユーザーアカウントに割り当てます

この手順により、暗号化キーを作成できるようになります。

キーコンテナーに移動し、左側のウィンドウから [アクセスの制御 (IAM)] を選択します。
[このリソースへのアクセス権の付与] で [ロールの割り当ての追加] を選択します。
Key Vault Crypto Officer を検索して選択します。
[メンバー] タブで、[ユーザー、グループ、またはサービスプリンシパル] を選択します。
[メンバー] を選択し、ユーザーアカウントを検索します。
[レビューと割り当て] を選択します。

顧客が暗号化キーを作成する

暗号化キーを作成するには、ユーザーのアカウントに Key Vault Crypto Officer ロール、またはキーの作成を許可する別のロールを割り当てる必要があります。

Key Vault のプロパティページで、[キー] を選択します。
[Generate/Import](生成/インポート) を選択します。
[キーの作成] 画面で、キーの名前を指定します。他の値は既定値のままにしておきます。
［作成］ を選択します
キー URI をコピーします。

顧客がサービスプロバイダーアプリケーションにキーコンテナーへのアクセスを許可する

キーコンテナーにアクセスできるように、Azure RBAC ロール Key Vault Crypto Service Encryption User をサービスプロバイダーの登録済みアプリケーションに割り当てます。

キーコンテナーに移動し、左側のウィンドウから [アクセスの制御 (IAM)] を選択します。
[このリソースへのアクセス権の付与] で [ロールの割り当ての追加] を選択します。
[Key Vault Crypto Service Encryption User] を検索して選択します。
[メンバー] タブで、[ユーザー、グループ、またはサービスプリンシパル] を選択します。
[メンバー] を選択し、サービスプロバイダーからインストールしたアプリケーションのアプリケーション名を検索します。
[レビューと割り当て] を選択します。

これで、キーコンテナーの URI とキーを使用して、カスタマーマネージドキーを構成できます。

Azure PowerShell を使用してクライアントのテナントを構成するには、最新の Az モジュールをインストールします。 PowerShell のインストールの詳細については、PowerShellGet を使用した Windows への Azure PowerShell のインストールに関する記事を参照してください。

Azure PowerShell をローカルで使用する場合は、次のようにします。
- Az PowerShell モジュールの最新バージョンをインストールします。
- Connect-AzAccount コマンドレットを使用して、Azure アカウントに接続します。
Azure Cloud Shell を使用する場合は、次のようにします。
- 詳細については、Azure Cloud Shell の概要に関するページを参照してください。

顧客が Azure にサインインする

Azure PowerShell で、顧客のテナントにサインインし、アクティブなサブスクリプションを顧客のサブスクリプションに設定します。

$customerTenantId="<customer-tenant-id>"
$customerSubscriptionId="<customer-subscription-id>"

# Sign in to Azure in the customer's tenant.
Connect-AzAccount -Tenant $customerTenantId
# Set the context to the customer's subscription.
Set-AzContext -Subscription $customerSubscriptionId

顧客が顧客テナントにサービスプロバイダーアプリケーションをインストールする

サービスプロバイダーのマルチテナントアプリケーションのアプリケーション ID を受け取ったら、サービスプリンシパルを作成して、テナント Tenant2 にアプリケーションをインストールします。

キーコンテナーを作成する予定のテナントで、次のコマンドを実行します。

$customerRgName="<customer-resource-group>"
$customerLocation="<location>"
$multiTenantAppId="<multi-tenant-app-id>" # appId value from Tenant1 

# Create a resource group in the customer's subscription.
New-AzResourceGroup -Location $customerLocation -ResourceGroupName $customerRgName

# Create the service principal with the registered app's application ID (client ID).
$servicePrincipal = New-AzADServicePrincipal -ApplicationId $multiTenantAppId

顧客がキーコンテナーを作成する

キーコンテナーを作成するには、顧客のアカウントに Key Vault Contributor ロール、またはキーコンテナーの作成を許可する別のロールを割り当てる必要があります。

$kvName="<key-vault>"

$kv = New-AzKeyVault -Location $customerLocation `
    -Name $kvName `
    -ResourceGroupName $customerRgName `
    -SubscriptionId $customerSubscriptionId `
    -EnablePurgeProtection `
    -EnableRbacAuthorization

顧客は、Key Vault Crypto Officer ロールをユーザーアカウントに割り当てます

Key Vault Crypto Officer ロールをユーザーアカウントに割り当てます。この手順により、ユーザーはキーコンテナーと暗号化キーを作成できるようになります。次の例では、現在サインインしているユーザーにロールを割り当てます。

$currentUserObjectId = (Get-AzADUser -SignedIn).Id

New-AzRoleAssignment -RoleDefinitionName "Key Vault Crypto Officer" `
    -Scope $kv.ResourceId `
    -ObjectId $currentUserObjectId

顧客が暗号化キーを作成する

$keyName="<key-name>"

Add-AzKeyVaultKey -Name $keyName `
    -VaultName $kvName `
    -Destination software

顧客がサービスプロバイダーアプリケーションにキーコンテナーへのアクセスを許可する

Azure RBAC ロール Key Vault Crypto Service Encryption User を、上記で作成したサービスプリンシパル経由でサービスプロバイダーの登録済みアプリケーションに割り当てて、キーコンテナーにアクセスできるようにします。

New-AzRoleAssignment -RoleDefinitionName "Key Vault Crypto Service Encryption User" `
    -Scope $kv.ResourceId `
    -ObjectId $servicePrincipal.Id

これで、キーコンテナーの URI とキーを使用して、カスタマーマネージドキーを構成できます。

Azure Cloud Shell で Bash 環境を使用します。詳細については、「Azure Cloud Shell の Bash のクイックスタート」を参照してください。
CLI リファレンスコマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。
- ローカルインストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。認証プロセスを完了するには、ターミナルに表示される手順に従います。その他のサインインオプションについては、Azure CLI でのサインインに関するページを参照してください。
- 初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。拡張機能の詳細については、Azure CLI で拡張機能を使用する方法に関するページを参照してください。
- az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。最新バージョンにアップグレードするには、az upgrade を実行します。

顧客が Azure にサインインする

Azure にサインインして Azure CLI を使用します。

az login

顧客が顧客テナントにサービスプロバイダーアプリケーションをインストールする

サービスプロバイダーのマルチテナントアプリケーションのアプリケーション ID を受け取ったら、次のコマンドを使用して、テナント Tenant2 にアプリケーションをインストールします。アプリケーションをインストールすると、テナントにサービスプリンシパルが作成されます。

キーコンテナーを作成する予定のテナントで、次のコマンドを実行します。

# Create the service principal with the registered app's application ID (client ID)
multiTenantAppId="<multi-tenant-app-id>"
az ad sp create --id $multiTenantAppId --query id --out tsv

顧客がキーコンテナーを作成する

customerSubscriptionId="<customer-subscription-id>"
customerRgName="<customer-resource-group>"
customerLocation="<location>"
kvName="<key-vault>"

az group create --location $customerLocation \
    --name $customerRgName

az keyvault create --name $kvName \
    --location $customerLocation \
    --resource-group $customerRgName \
    --subscription $customerSubscriptionId \
    --enable-purge-protection true \
    --enable-rbac-authorization true

顧客は、Key Vault Crypto Officer ロールをユーザーアカウントに割り当てます

この手順により、キーコンテナーと暗号化キーを作成できるようになります。

currentUserObjectId=$(az ad signed-in-user show --query id --output tsv)

kvResourceId=$(az keyvault show --resource-group $customerRgName \
    --name $kvName \
    --query id \
    --output tsv)

az role assignment create --role "Key Vault Crypto Officer" \
    --scope $kvResourceId \
    --assignee-object-id $currentUserObjectId

顧客が暗号化キーを作成する

keyName="<key-name>"
az keyvault key create --name $keyName --vault-name $kvName

顧客がサービスプロバイダーアプリケーションにキーコンテナーへのアクセスを許可する

Azure RBAC ロール Key Vault Crypto Service Encryption User を、上記で作成したサービスプリンシパル経由でサービスプロバイダーの登録済みアプリケーションに割り当てて、登録済みアプリケーションからキーコンテナーにアクセスできるようにします。

servicePrincipalId=$(az ad sp show --id $multiTenantAppId --query id --output tsv)

az role assignment create --role "Key Vault Crypto Service Encryption User" \
    --scope $kvResourceId \
    --assignee-object-id $servicePrincipalId

これで、キーコンテナーの URI とキーを使用して、カスタマーマネージドキーを構成できます。

異なるテナントのキーで暗号化される新しい Azure Cosmos DB アカウントを作成する

ここまでは、サービスプロバイダーのテナントでマルチテナントアプリケーションを構成しました。また、顧客のテナントにアプリケーションをインストールし、キーコンテナーとキーを構成しました。次に、サービスプロバイダーのテナントに Azure Cosmos DB アカウントを作成し、顧客のテナントのキーを使ってカスタマーマネージドキーを構成できます。

カスタマーマネージドキーを使って Azure Cosmos DB アカウントを作成するときは、顧客が使ったキーにアクセスできることを確認する必要があります。シングルテナントのシナリオでは、Azure Cosmos DB のプリンシパルにキーコンテナーへの直接アクセス権を付与するか、特定のマネージド ID を使います。クロステナントのシナリオでは、キーコンテナーは顧客によって管理される別のテナントにあるため、キーコンテナーへの直接アクセスに依存できなくなります。この制約のために、前のセクションでは、クロステナントアプリケーションを作成し、アプリケーション内にマネージド ID を登録して、顧客のキーコンテナーにアクセスできるようにしました。このマネージド ID を、クロステナントアプリケーション ID と組み合わせて、クロステナント CMK の Azure Cosmos DB アカウントを作成するときに使います。詳しくは、この記事の「フェーズ 3 - サービスプロバイダーがカスタマーマネージドキーを使用して Azure リソース内のデータを暗号化する」セクションをご覧ください。

キーコンテナーで新しいバージョンのキーが使用できるようになるたびに、Azure Cosmos DB アカウントでそれが自動的に更新されます。

Azure Resource Manager JSON テンプレートを使用する

次の特定のパラメーターを使って ARM テンプレートをデプロイします。

注意

Azure Resource Manager テンプレートのいずれかでこのサンプルを再作成している場合は、2022-05-15 の apiVersion を使ってください。

パラメーター	説明	値の例
`keyVaultKeyUri`	サービスプロバイダーのキーコンテナーに存在するカスタマーマネージドキーの識別子。	`https://my-vault.vault.azure.com/keys/my-key`
`identity`	マネージド ID を Azure Cosmos DB アカウントに割り当てる必要があることを指定するオブジェクト。	`"identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}`
`defaultIdentity`	マネージド ID のリソース ID と、マルチテナント Microsoft Entra アプリケーションのアプリケーション ID の組み合わせ。	`UserAssignedIdentity=/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e`

3 つのパラメーターが構成されたテンプレートセグメントの例を次に示します。

{
  "kind": "GlobalDocumentDB",
  "location": "East US 2",
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity": {}
    }
  },
  "properties": {
    "locations": [
      {
        "locationName": "East US 2",
        "failoverPriority": 0,
        "isZoneRedundant": false
      }
    ],
    "databaseAccountOfferType": "Standard",
    "keyVaultKeyUri": "https://my-vault.vault.azure.com/keys/my-key",
    "defaultIdentity": "UserAssignedIdentity=/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e"
  }
}

重要

この機能は、Azure PowerShell、Azure CLI、または Azure portal ではまだサポートされていません。

新しい Azure Cosmos DB アカウントを作成するとき、特定のバージョンのキーバージョンでカスタマーマネージドキーを構成することはできません。キー自体を、バージョンと末尾の円記号を付けないで渡す必要があります。

カスタマーマネージドキーの取り消しや無効化については、Azure Key Vault での Azure Cosmos DB アカウント用のカスタマーマネージドキーの構成に関する記事をご覧ください。

次の方法で共有

Azure Key Vault を使用して Azure Cosmos DB アカウント用にクロステナントのカスタマー マネージド キーを構成する

クロステナントのカスタマー マネージド キーについて

フェーズ 1 - サービス プロバイダーが Microsoft Entra アプリケーションを構成する

サービス プロバイダーに関する考慮事項

フェーズ 2 - 顧客がキー コンテナーへのアクセスを承認する

サービス プロバイダーの顧客に関する考慮事項

フェーズ 3 - サービス プロバイダーがカスタマー マネージド キーを使用して Azure リソース内のデータを暗号化する

クロステナントのカスタマー マネージド キーを構成する

サービス プロバイダーが ID を構成します

サービス プロバイダーが新しいマルチテナント アプリ登録を作成します

サービス プロバイダーは、ユーザー割り当てマネージド ID を作成します

サービス プロバイダーは、ユーザー割り当てマネージド ID をアプリケーションのフェデレーション資格情報として構成します

サービス プロバイダーがアプリケーション ID を顧客と共有する

顧客がサービス プロバイダーのアプリにキー コンテナー内のキーへのアクセスを許可する

顧客が顧客テナントにサービス プロバイダー アプリケーションをインストールする

顧客がキー コンテナーを作成する

顧客は、Key Vault Crypto Officer ロールをユーザー アカウントに割り当てます

顧客が暗号化キーを作成する

顧客がサービス プロバイダー アプリケーションにキー コンテナーへのアクセスを許可する

異なるテナントのキーで暗号化される新しい Azure Cosmos DB アカウントを作成する

Azure Resource Manager JSON テンプレートを使用する

関連項目

フィードバック

その他のリソース

Azure Key Vault を使用して Azure Cosmos DB アカウント用にクロステナントのカスタマーマネージドキーを構成する

クロステナントのカスタマーマネージドキーについて

フェーズ 1 - サービスプロバイダーが Microsoft Entra アプリケーションを構成する

サービスプロバイダーに関する考慮事項

フェーズ 2 - 顧客がキーコンテナーへのアクセスを承認する

サービスプロバイダーの顧客に関する考慮事項

フェーズ 3 - サービスプロバイダーがカスタマーマネージドキーを使用して Azure リソース内のデータを暗号化する

クロステナントのカスタマーマネージドキーを構成する

サービスプロバイダーが ID を構成します

サービスプロバイダーが新しいマルチテナントアプリ登録を作成します

サービスプロバイダーは、ユーザー割り当てマネージド ID を作成します

サービスプロバイダーは、ユーザー割り当てマネージド ID をアプリケーションのフェデレーション資格情報として構成します

サービスプロバイダーがアプリケーション ID を顧客と共有する

顧客がサービスプロバイダーのアプリにキーコンテナー内のキーへのアクセスを許可する

顧客が顧客テナントにサービスプロバイダーアプリケーションをインストールする

顧客がキーコンテナーを作成する

顧客は、Key Vault Crypto Officer ロールをユーザーアカウントに割り当てます

顧客がサービスプロバイダーアプリケーションにキーコンテナーへのアクセスを許可する