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

2025-04-17

適用対象: NoSQL MongoDB Gremlin テーブル

新しい Azure Cosmos DB アカウントを作成する際、保存データに暗号化の第 2 レイヤーを適用するためのカスタマーマネージドキーを有効にする機能は、しばらく前から一般向けに提供されています。この方向性をもう一歩進めるための自然なステップとして、今回、既存の Azure Cosmos DB アカウントに対して CMK を有効にする機能が追加されました。

これは、CMK を有効にするためにデータを新しいアカウントに移行することを不要にする機能であり、お客様のセキュリティとコンプライアンス体制の強化に役立ちます。

CMK を有効にすると、アカウント内のすべての既存データを暗号化する非同期のバックグラウンドプロセスが開始されます。一方、新しい受信データは永続化の前に暗号化されます。この非同期の操作が成功するのを待つ必要はありません。有効化のプロセスには未使用/スペアの RU が使用されるため、読み取り/書き込みワークロードに影響はありません。アカウントが暗号化された後の容量計画については、こちらのリンクを参照してください。

既存のアカウントに対して CMK を有効にし、作業を開始する

重要

前提条件のセクションを十分に確認してください。これらの前提条件は重要な考慮事項です。

前提条件

新しいアカウントに対してカスタマーマネージドキー (CMK) を構成する際に必要とされる前提条件の手順は、すべて、既存のアカウントに対して CMK を有効にする作業にも当てはまります。こちらの手順を参照してください

注意

Azure Cosmos DB アカウントで暗号化を有効にすると、ドキュメントの ID にわずかなオーバーヘッドが追加され、ドキュメント ID の最大サイズは 1,024 バイトではなく 990 バイトに制限されることに注意してください。 ID が 990 バイトを超えるドキュメントがアカウントにある場合、それらのドキュメントが削除されるまで暗号化プロセスは失敗します。

アカウントが準拠しているかどうかを確認するには、ここでホストされている提供されたコンソールアプリケーションを使用してアカウントをスキャンできます。 API が選択されているに関係なく、'sqlEndpoint' アカウントプロパティのエンドポイントを使用していることを確認します。

この移行中にサーバー側の検証を無効にする場合は、サポートにお問い合わせください。

既存のアカウントに対して CMK を有効にする手順

既存のアカウントに対して CMK を有効にするには、keyVaultKeyUri プロパティに Key Vault キー識別子を設定する ARM テンプレートを使用してアカウントを更新します。これは、新しいアカウントに対して CMK を有効にする場合と同様です。この手順は、以下のペイロードを指定して PATCH 呼び出しを発行することで実行できます。

    {
        "properties": {
        "keyVaultKeyUri": "<key-vault-key-uri>"
        }
    }

CMK を有効化するこの CLI コマンドの出力は、データの暗号化が完了するまで待機状態になります。

    az cosmosdb update --name "testaccount" --resource-group "testrg" --key-uri "https://keyvaultname.vault.azure.net/keys/key1"

継続的バックアップまたは分析ストアアカウントを使用する既存の Azure Cosmos DB アカウントに対して CMK を有効にする手順

継続的バックアップとポイントインタイムリストアが有効になっている既存のアカウントに対して CMK を有効にする場合は、いくつかの追加の手順を実行する必要があります。以下の手順 1 から手順 5 までを実行した後、既存のアカウントに対して CMK を有効にする手順を実行してください。

Cosmos アカウントへのマネージド ID の構成 Azure Cosmos DB アカウントの Microsoft Entra ID を使用してマネージド ID を構成

Cosmos アカウントを更新し、既定の ID を、前の手順で追加したマネージド ID を指すように設定します

システムマネージド ID の場合:

az cosmosdb update--resource-group $resourceGroupName --name $accountName --default-identity "SystemAssignedIdentity"

ユーザーマネージド ID の場合:

az cosmosdb update -n $sourceAccountName -g $resourceGroupName --default-identity "UserAssignedIdentity=/subscriptions/00000000-0000-0000-0000-00000000/resourcegroups/MyRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyID"

こちらのドキュメントに従って Keyvault を構成します
前の手順で設定した既定の ID 用のアクセスポリシーを keyvault に追加します
cosmos アカウントを更新して keyvault uri を設定します。この更新では、アカウントで CMK を有効にすることがトリガーされます
```
az cosmosdb update --name $accountName --resource-group $resourceGroupName --key-uri $keyVaultKeyURI  
```

既知の制限事項

既存の Azure Cosmos DB for Apache Cassandra アカウントでの CMK の有効化はサポートされていません。
CMK の有効化は Cosmos DB アカウントレベルでのみ実行でき、コレクションレベルでは実行できません。
具体化されたビューとすべてのバージョンと削除の変更フィードモードが有効になっている既存のアカウントに対して、CMK を有効にすることはサポートされていません。
CMK を有効にする前に、990 バイトを超える大きな ID を持つドキュメントがアカウントに含まれていないことを必ず確認してください。そうでない場合は、暗号化後にサポートされる最大 1,024 バイトの制限が原因でエラーが発生します。
既存のデータに対する暗号化処理の進行中は、コントロールプレーンのアクション ("add region" など) がブロックされます。暗号化が完了すると、この種のアクションのブロックは直ちに解除され、使用可能になります。

生成された暗号化の進捗を監視する

既存のアカウントに対して CMK を有効にすると、すべての既存データを暗号化する非同期のバックグラウンドタスクが開始されます。このため、CMK を有効にするための REST API 要求に対する応答には、"Azure-AsyncOperation" URL が含まれています。 GET 要求を使用してこの URL をポーリングすると、操作全体の状態が返され、最終的に成功します。このメカニズムの詳細については、こちらの記事を参照してください。

Cosmos DB アカウントは引き続き使用でき、非同期操作が成功するのを待たずにデータを書き込み続けることができます。 CMK を有効化する CLI コマンドは、データの暗号化が完了するまで待機状態になります。

既存の Cosmos DB アカウントが CMK に対して使用できるようにするには、スキャンを実行して、アカウントに "大きな ID" が含まれていないことを確認する必要があります。"Large ID" は、長さが 990 文字を超えるドキュメント ID です。このスキャンは CMK 移行に必須であり、Microsoft によって自動的に実行されます。このプロセス中に、エラーが表示される場合があります。

エラー: (InternalServerError) CMK 移行のためのドキュメントスキャンで予期しないエラーが発生しました。操作をやり直してください。

スキャンプロセスが、コレクションにプロビジョニングされたRUを超えるRUを使用してしまい、その結果として429エラーが発生する場合に、このエラーが起こります。この問題の解決策は、RU を一時的に大幅に増加させることです。または、こちらでホストされているコンソールアプリケーションを利用して、コレクションをスキャンすることもできます。

注意

この移行中にサーバー側の検証を無効にする場合は、サポートにお問い合わせください。検証を無効にすることは、大きな ID がないことを確認する場合にのみお勧めします。暗号化中に大きな ID が検出された場合、プロセスは Large ID ドキュメントがアドレス指定されるまで停止します。

不明点については、Microsoft サポートにお問い合わせください。

よく寄せられる質問

暗号化操作の所要時間は、どの程度ですか?

CMK の有効化によって開始される非同期操作の所要時間は、未使用 RU が十分にあるかどうかによって異なります。 CMK の有効化はピーク時間帯を避けて実行することをお勧めします。また、状況によっては、暗号化を迅速に進めるために前もって RU を増やしておくことをお勧めします。また、所要時間の長短は、データサイズの大小に直接関係します。

ダウンタイムに備える必要がありますか?

CMK を有効にすると、すべてのデータを暗号化する非同期のバックグラウンドプロセスが開始されます。この非同期の操作が成功するのを待つ必要はありません。 Azure Cosmos DB アカウントは使用でき、読み取り、書き込みのどちらも実行できます。ダウンタイムを設ける必要はありません。

CMK がトリガーされた後で RU を増やすことはできますか?

CMK をトリガーする前に、RU を増やすることをお勧めします。 CMK がトリガーされると、暗号化が完了するまで一部のコントロールプレーン操作がブロックされます。このブロックにより、CMK がトリガーされると、ユーザーが RU を増やできなくなる可能性があります。

既存の Cosmos DB アカウントを CMK に対して使用できるようにするために、前に示した既知の制限のいずれかに対処するため、大きな ID のスキャンが Microsoft によって自動的に必ず行われます。このプロセスでは追加の RU も消費されるため、エラー 429 を回避するために RU を大幅に増やすることをお勧めします。

CMK がトリガーされた後に、暗号化を元に戻したり無効にしたりする方法はありますか?

CMK を使用したデータ暗号化のプロセスがトリガーされた後は、元に戻すことはできません。

既存のアカウントに対して CMK を使用した暗号化を有効にすると、データサイズや読み取り/書き込みはその影響を受けますか?

お察しのとおり、CMK を有効にするとデータサイズはわずかに大きくなり、追加の暗号化/復号化処理に対応するために RU 消費量もわずかに増加します。

CMK を有効にする前にデータをバックアップすることが推奨されますか?

CMK を有効にしたことでデータが失われる心配はありません。

定期的なバックアップ処理で作成された古いバックアップは暗号化されますか?

いいえ古い定期的なバックアップは暗号化されません。 CMK を有効にした後に新しく作成されるバックアップは暗号化されます。

継続的バックアップを有効にした既存アカウントに対しては、どのように動作しますか?

CMK を有効にすると、継続的バックアップに関しても暗号化が有効になります。 CMK を有効にすると、それ以降に復元されるすべてのアカウントで CMK が有効になります。

PITR を有効にしたアカウントに対して CMK を有効にした後、それ以前の、CMK が無効だった頃のアカウントの状態を復元すると、どうなりますか?

この場合、復元されたターゲットアカウントに対して CMK が明示的に有効になります。その理由は以下のとおりです。

アカウントで CMK が有効になると、CMK を無効にすることはできません。
この動作は、定期的なバックアップを使用した CMK 対応アカウントの現在の復元設計に合わせて調整されています

CMK の移行中にユーザーがキーを取り消した場合は、どうなりますか?

CMK 暗号化がトリガーされると、キーの状態チェックが行われます。その時点で Azure Key Vault 内のキーが良好な状態であれば、暗号化が開始され、以後はキーの再チェックなしでプロセス完了まで続行されます。キーが取り消された場合や、Azure Key Vault が削除されることや使用不可になることがあった場合にも、暗号化プロセスは成功します。

既存の実運用アカウントに対して CMK 暗号化を有効にすることはできますか?

はい。前提条件のセクションを十分に確認してください。まずは、すべてのシナリオを非運用アカウントでテストすることをお勧めします。慣れてきたら運用アカウントを検討することができます。

Azure Cosmos DB アカウントを別のテナントに移行するにはどうすればよいですか?

Cosmos DB アカウントでカスタマーマネージドキーが有効になっている場合、そのアカウントはテナント間のカスタマーマネージドキーアカウントの場合にのみ移行できます。詳細については、 Azure Key Vault を使用して Azure Cosmos DB アカウントのテナント間カスタマーマネージドキーを構成する方法に関するガイドを参照してください。

警告

移行後は、元のテナント間の関係を維持するために、Azure Cosmos DB アカウントと Azure Key Vault を別々のテナントに保持することが重要です。 Cosmos DB アカウントの移行が完了するまで、Key Vault キーが保持されていることを確認します。

次のステップ

Azure Cosmos DB でのデータの暗号化について学習します。
独自のキーを使用して 2 番目の暗号化レイヤーを追加する場合の詳細な手順については、カスタマーマネージドキーに関する記事を参照してください。
Azure セキュリティセンターで Microsoft 認定資格を調べる。

次の方法で共有

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