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

[アーティクル]
04/11/2024

適用対象: NoSQL MongoDB Cassandra Gremlin Table

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

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

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

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

重要

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

前提条件

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

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

アカウントが準拠しているかどうかを確認するには、ここでホストされている提供されたコンソールアプリケーションを使用してアカウントをスキャンできます。選択されている 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 を有効にする手順を実行してください。

Note

システム割り当て ID と継続的バックアップモードは現在、パブリックプレビュー段階であり、今後変更される可能性があります。継続的バックアップのアカウントに対して CMK を有効にする操作においては、現在、ユーザー割り当てマネージド ID のみがサポートされています。

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

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

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

az cosmosdb update --resource-group $resourceGroupName  --name $accountName  --default-identity "SystemAssignedIdentity=subscriptions/00000000-0000-0000-0000-00000000/resourcegroups/MyRG/providers/Microsoft.ManagedIdentity/ systemAssignedIdentities/MyID"

ユーザーマネージド 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  
```

既知の制限事項

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

有効化の結果実行される暗号化の進行状況を監視する

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

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

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

よく寄せられる質問

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

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

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

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

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

RU を増やす場合は、CMK をトリガーする前に行うことをお勧めします。 CMK がトリガーされた後は、暗号化が完了するまで一部のコントロールプレーン操作がブロックされます。このブロックの影響で、CMK がトリガーされた後には 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 でのデータの暗号化について学習します。
独自のキーを使用して 2 つ目の暗号化レイヤーを追加することもできます。詳細については、カスタマーマネージドキーの記事を参照してください。
Azure Cosmos DB のセキュリティと最新の機能強化の概要については、「Azure Cosmos DB データベースのセキュリティ」を参照してください。
マイクロソフトが取得している認証の詳細については、Azure トラストセンターに関するページを参照してください。

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