Azure Database for PostgreSQL フレキシブルサーバーにおける保存データの暗号化

フレキシブルサーバー Azure Database for PostgreSQL常にすべての保存データが暗号化されます。このデータには、すべてのシステムデータベースとユーザーデータベース、サーバーログ、先書きログセグメント、バックアップが含まれます。基になるストレージは、Azure Disk Storageのサーバー側暗号化による暗号化を処理します。

サービスマネージドキー (SMK) またはカスタマーマネージドキー (CMK) を使用した保存時の暗号化

Azure Database for PostgreSQL では、保存時のデータ暗号化の 2 つのモード ( サービスマネージドキー (SMK) と カスタマーマネージドキー (CMK) がサポートされています。 Azure Database for PostgreSQL フレキシブルサーバーでは、サービスマネージドキーによるデータ暗号化が既定で有効になっています。このモードでは、データの暗号化に使用される暗号化キーがサービスによって自動的に管理されます。このモードで暗号化を有効または管理するためのアクションを実行する必要はありません。

カスタマーマネージドキー モードでは、ユーザー独自の暗号化キーを使ってデータを暗号化できます。このモードでは、暗号化プロセスをより詳細に制御できますが、暗号化キーを自分で管理する必要もあります。独自の Azure Key Vault または Azure Key Vault Managed Hardware Security Module (HSM) をデプロイし、Azure Database for PostgreSQL フレキシブルサーバーで使用される暗号化キーを格納するように構成する必要があります。

モードは、サーバー作成時にのみ選択できます。サーバーの有効期間中、モードを変更することはできません。

データの暗号化を実現するために、Azure Database for PostgreSQLは保存データのAzure Storage暗号化を使用します。 CMK を使用する場合は、Blob StorageおよびAzure Files サービスのデータを暗号化および復号化するためのキーを提供する必要があります。これらのキーは、Azure Key Vaultまたはマネージドハードウェアセキュリティモジュール (HSM) Azure Key Vault格納する必要があります。詳細については、「Azure Storage 暗号化のカスタマーマネージドキー」を参照してください。

各モード (SMK または CMK) によって提供される利点

Azure Database for PostgreSQL の サービスマネージドキー を使用したデータ暗号化には、次の利点があります。

このサービスは、データアクセスを自動的かつ完全に制御します。
このサービスは、キーのローテーションなど、キーのライフサイクルを自動的かつ完全に制御します。
データ暗号化キーの管理を心配する必要はありません。
サービスマネージドキーに基づくデータ暗号化は、ワークロードのパフォーマンスに悪影響を与えません。
これにより、暗号化キーの管理 (通常のローテーションを含む) と、それらのキーへのアクセスに使用される ID の管理が簡素化されます。

Azure Database for PostgreSQL の カスタマーマネージドキー を使用したデータ暗号化には、次の利点があります。

データアクセスを完全に制御します。キーを削除して、データベースにアクセスできないようにすることができます。
会社のポリシーに合わせてキーのローテーションを含め、キーのライフサイクルを完全に制御します。
すべての暗号キーを Azure Key Vault の独自のインスタンスで一元管理し、整理できます。
カスタマーマネージドキーに基づくデータ暗号化は、ワークロードのパフォーマンスに悪影響を与えません。
セキュリティ責任者、データベース管理者、およびシステム管理者の間での職務の分離を実装できます。

CMK の要件

カスタマーマネージド暗号化キーを使用する場合は、責任を負います。独自のAzure Key VaultまたはAzure Key Vault HSM をデプロイする必要があります。独自のキーを生成またはインポートする必要があります。 Azure Database for PostgreSQL フレキシブルサーバーがキーに対して必要なアクションを実行できるように、Key Vault に必要なアクセス許可を付与する必要があります。 Azure Database for PostgreSQLフレキシブルサーバーがキーにアクセスできるように、キーを保持するAzure Key Vaultのすべてのネットワーク側面を構成する必要があります。キーへのアクセスを監査することもユーザーの責任です。最後に、キーをローテーションし、必要に応じて Azure Database for PostgreSQL フレキシブルサーバーの構成を更新して、ローテーションされたバージョンのキーを参照するようにする必要があります。

ストレージアカウントのカスタマーマネージドキーを構成すると、Azure Storage は、関連するキーコンテナーまたはマネージド HSM 内のカスタマーマネージドキーを使用して、アカウントのルートデータ暗号化キー (DEK) をラップします。ルート暗号化キーの保護は変わりますが、Azure Storage アカウント内のデータは常に暗号化されたままです。データが暗号化されたままであることを保証するために、お客様側で必要となる追加のアクションはありません。カスタマーマネージドキーによる保護はすぐに有効になります。

Azure Key Vault は、クラウドベースの外部キー管理システムです。可用性が高く、FIPS 140 適合のハードウェアセキュリティモジュール (HSM) によって必要に応じてサポートされる、スケーラブルで安全な RSA 暗号化キー向けストレージが提供されます。格納されているキーに直接アクセスすることはできませんが、認可されたエンティティに対する暗号化と解読のサービスが提供されます。 Key Vault では、キーの生成、インポート、またはオンプレミス HSM デバイスからの転送を行うことができます。

次の一覧では、Azure Database for PostgreSQLのデータ暗号化を構成するための要件について説明します。

シングルテナント CMK 構成の場合、Key VaultとAzure Database for PostgreSQLフレキシブルサーバーは、同じMicrosoft Entra テナントに属している必要があります。テナント間のシナリオについては、テナント間のカスタマーマネージドキーに関するページを参照してください。その後、Key Vault リソースを移動するには、データ暗号化を再構成する必要があります。
Key Vault の 削除されたボールトを保持する日数 構成を 90 日に設定します。既存の Key Vault インスタンスをより小さい数値で設定した場合でも、そのまま有効です。ただし、この設定を変更して値を大きくする場合は、新しいKey Vaultインスタンスを作成する必要があります。インスタンスが作成されると、この設定を変更することはできません。
キーまたは Key Vault インスタンスが誤って削除された場合のデータ損失を防ぐために、Key Vault でソフト削除機能を有効にします。 Key Vault は、論理的に削除されたリソースを 90 日間保持します (その間にユーザーが復旧または消去した場合を除く)。復旧と消去のアクションには、Key Vault の RBAC ロールまたはアクセスポリシーのアクセス許可に関連付けられた独自のアクセス許可があります。論理削除機能は、既定では有効です。かなり前にデプロイされた Key Vault がある場合、ソフト削除がまだ無効になっている可能性があります。その場合は、Azure CLIを使用して有効にすることができます。
消去保護を有効にして、削除されたコンテナーおよびコンテナーオブジェクトに必須の保持期間を適用します。
次の方法で、Azure Database for PostgreSQL フレキシブルサーバーのユーザー割り当てマネージド ID にキーへのアクセス権を付与します。
推奨: RBAC アクセス許可モデルを使用してAzure Key Vaultを構成し、マネージド ID に Key Vault Crypto Service Encryption ユーザーロールを割り当てます。
レガシ: Azure Key Vault がアクセスポリシーのアクセス許可モデルで構成されている場合は、マネージド ID に次のアクセス許可を付与します。
get: Key Vault 内のキーのプロパティと公開部分を取得します。
list: Key Vault に格納されているキーを一覧表示して反復処理します。
wrapKey: データ暗号化キーを暗号化します。
unwrapKey: データ暗号化キーを復号化します。
データ暗号化キーの暗号化に使用されるキーは、非対称の RSA または RSA-HSM のみです。サポートされているキーサイズは、2,048、3,072、4,096 です。セキュリティを強化するために 4,096 ビットキーを使用します。
キーのアクティブ化の日付と時刻 (設定する場合) は、過去の日付と時刻にする必要があります。有効期限の日付と時刻 (設定する場合) は、後で指定する必要があります。
キーは、"有効" 状態になっている必要があります。
Key Vault に既存のキーをインポートする場合は、サポートされているファイル形式 (.pfx、.byok、または .backup) で提供します。

CMK キーバージョンの更新

CMK は、手動でのキーローテーションと更新、またはKey Vaultでの手動または自動キーローテーション後の自動キーバージョンの更新に対して構成できます。

詳細については、「サーバーのプロビジョニング中にカスタマーマネージドキーを使用してデータ暗号化を構成する」を参照してください。

Important

キーを新しいバージョンにローテーションする場合は、再暗号化を成功させるために古いキーを使用できるようにします。ほとんどの再暗号化は 30 分以内に行われますが、古いキーバージョンへのアクセスを無効にする前に少なくとも 2 時間待ちます。

キーの手動ローテーションと更新

CMK を手動キー更新で構成している場合は、Key Vault で手動または自動のキーローテーションが行われた後、Azure Database for PostgreSQL フレキシブルサーバーでキーバージョンを手動で更新する必要があります。更新するまで、サーバーは古いキーバージョンを引き続き使用します。このモードをプロビジョニングするには、URI にバージョン GUID を含むキー URI を指定します。たとえば、「 https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version> 」のように入力します。最近まで、このオプションは使用可能な唯一のオプションでした。

キーを手動でローテーションするか、AKV がローテーションポリシーに基づいてキーを自動ローテーションするたびに、PostgreSQL サーバーの CMK プロパティを更新する必要がありました。この方法は、オペレーターにとってエラーが発生しやすく、特に Key Vault の自動ローテーション機能を使用する場合には、ローテーション処理のためにカスタムスクリプトが必要になることがありました。

キーバージョンの自動更新

キーバージョンの自動更新を有効にするには、バージョンレスキー URI を使用します。この方法では、キーのローテーション後に PostgreSQL サーバーで CMK のバージョンプロパティを更新する必要がなくなります。 PostgreSQL は、新しいキーバージョンを自動的に取得し、データ暗号化キーを再暗号化します。このアプローチにより、特にKey Vault自動ローテーションと組み合わせた場合に、主要なライフサイクル管理が大幅に簡素化されます。

Azure Resource Manager、Bicep、Terraform、Azure PowerShell、またはAzure CLIを使用してこのアプローチを実装するには、キー URI からバージョン GUIDを省略します。

ポータルで、このチェックボックスをオンにして、対話型の選択中と URI の検証時にバージョン GUID を抑制するように UI をガイドします。

推奨事項

データ暗号化にカスタマーマネージドキーを使用する場合は、次の推奨事項に従ってKey Vaultを構成します。

Key Vaultにリソースロックを設定して、この重要なリソースが誤って削除または承認されないようにします。
すべての暗号化キーの監査およびレポートを有効にします。 Key Vault が提供するログは、他のセキュリティ情報およびイベント管理 (SIEM) ツールに簡単に挿入できます。 Azure Monitor Log は、既に統合されているサービスの一例です。
[パブリックアクセスを無効にする] と [信頼された Microsoft サービスがこのファイアウォールをバイパスすることを許可する] を選択して、Key Vault をロックダウンします。
キーバージョンの自動更新を有効にします。

注

[パブリックアクセスを無効にする] と [信頼された Microsoft サービスがこのファイアウォールをバイパスできるようにする] を選択した後、ポータル経由でパブリックアクセスを使用して Key Vault を管理しようとすると、次のようなエラーが表示される場合があります: "ネットワークアクセス制御が有効になりました。「許可されたネットワークのみがこのキーコンテナーにアクセスできます」というエラーが表示されても、カスタマーマネージドキーのセットアップ時にキーを指定したり、サーバー操作中に Key Vault からキーを取得したりすることは可能です。

カスタマーマネージドキーのコピーを安全な場所に保管するか、エスクローサービスにエスクローします。
Key Vault でキーを生成する場合は、初めてキーを使用する前に、キーのバックアップを作成します。バックアップは Key Vault にのみ復元できます。

特別な考慮事項

Azure Key Vault からの誤ったキーアクセスの失効

Key Vaultに対する十分なアクセス権を持つユーザーは、次の方法で誤ってキーへのサーバーアクセスを無効にする可能性があります。

RBAC ロール Key Vault Crypto Service Encryption User の割り当てを解除するか、Key Vault でキーを取得するために使用される ID からアクセス許可を取り消します。
キーを削除する。
Key Vault インスタンスを削除する。
Key Vault のファイアウォール規則を変更する。
Microsoft Entra ID でサーバーのマネージド ID を削除する。

Azure Key Vaultに保持されているキーを監視する

データベースの状態を監視し、データ暗号化保護機能へのアクセスの損失に関するアラートを有効にするには、次のAzure機能を構成します。

リソース正常性: CMK へのアクセスを失ったデータベースは、データベースへの最初の接続が拒否された後、アクセス不可として表示されます。
アクティビティログ: お客様によって管理される Key Vault インスタンス内の CMK へのアクセスに失敗すると、アクティビティログにエントリが追加されます。これらのイベントに対してアラートを作成した場合は、できるだけ早くアクセスを再開できます。
アクショングループ: 必要に応じて通知とアラートを受信するように、これらのグループを定義します。

カスタマーマネージドキーを使用して構成されたサーバーのバックアップを復元する

Key Vaultに格納されているカスタマーマネージドキーを使用してAzure Database for PostgreSQLフレキシブルサーバーを暗号化すると、新しく作成されたサーバーコピーも暗号化されます。この新しいコピーは、ポイントインタイムリストア (PITR) 操作を使用するか、読み取りレプリカを使用して作成できます。

読み取りレプリカのバックアップの復元や作成のような操作中に、カスタマーマネージドキーを使用してデータの暗号化を設定する場合は、プライマリサーバーと復元済み/レプリカサーバーで次の手順に従うことで、問題を回避できます。

復元プロセス、またはプライマリ Azure Database for PostgreSQL フレキシブルサーバーから読み取りレプリカを作成するプロセスを開始します。
復元したサーバーまたはレプリカサーバーで、Key Vault へのアクセスに使用するカスタマーマネージドキーとユーザー割り当てマネージド ID を変更できます。新しく作成されたサーバーで割り当てられた ID に、Key Vault で必要なアクセス許可が付与されていることを確認します。
復元後に元のキーを取り消さないでください。現時点では、カスタマーマネージドキーを持つサーバーを別のサーバーに復元した後、キーの失効はサポートされていません。

マネージド HSM

ハードウェアセキュリティモジュール (HSM) は、データの暗号化、データの暗号化解除、デジタル署名の作成、デジタル証明書の作成に使用されるキーを生成、保護、管理することで、暗号化プロセスをセキュリティで保護するのに役立つ改ざんに強いハードウェアデバイスです。 HSM は、FIPS 140 や Common Criteria などの最高のセキュリティ標準に従ってテスト、検証、認定されています。

Azure Key Vault Managed HSM は、フルマネージドの高可用性シングルテナントの標準準拠クラウドサービスです。 FIPS 140-3 検証済み HSM を使用して、クラウドアプリケーションの暗号化キーを保護できます。

カスタマーマネージドキーを使用してAzure ポータルで新しいAzure Database for PostgreSQLフレキシブルサーバーを作成する場合は、Azure Key Vaultの代わりに、キーストアとして Azure Key Vault Managed HSMを選択できます。ユーザー定義の ID とアクセス許可に関する前提条件は、Azure Key Vault の前提条件と同じです (この記事で前述)。 Managed HSM インスタンスを作成する方法、共有 Key Vault ベースの証明書ストアとの利点と違い、およびマネージド HSM にキーをインポートする方法の詳細については、「Azure Key Vault Managed HSM とは?」を参照してください。

カスタマーマネージドキーのアクセス不可状態

Key Vaultに格納されているカスタマーマネージドキーを使用してデータ暗号化を構成する場合、サーバーはオンラインを維持するために、このキーへの継続的なアクセスを必要とします。サーバーがアクセスを失うと、その状態が アクセス不可 に変更され、すべての接続の拒否が開始されます。

サーバーの状態が アクセス不能 になる原因には、次のようなものがあります。

原因	解決策
サーバーが参照するいずれかの暗号化キーに有効期限の日時が設定されており、その日時に達した。	キーの有効期限を延長します。次に、サービスがキーを再検証し、サーバーの状態を自動的に準備完了に切り替えるのを待ちます。サーバーが準備完了状態に戻った場合にのみ、キーを新しいバージョンにローテーションするか、新しいキーを作成し、同じキーの新しいバージョンまたは新しいキーを参照するようにサーバーを更新できます。
キーをローテーションしたのに、キーの新しいバージョンを参照するように Azure Database for PostgreSQL フレキシブルサーバーのインスタンスを更新し忘れた。サーバーが参照していた古いキーは期限切れになり、サーバーの状態は "アクセス不可" になります。	この状況を回避するには、キーをローテーションするたびに、新しいバージョンを参照するようにサーバーのインスタンスも必ず更新します。これを行うには、 `az postgres flexible-server update`を使用して、「データ暗号化のキー/ID を変更する」を説明する例に従います。サーバーの作成後にデータ暗号化を有効にすることはできません。これにより、キー/ID のみが更新されます。"。 API を使用して更新する場合は、サービスのサーバー - 更新エンドポイントを呼び出すことができます。
Key Vault インスタンスを削除すると、Azure Database for PostgreSQL フレキシブルサーバーはキーにアクセスできなくなり、アクセスできない状態に移行します。	Key Vault インスタンスを回復し、サービスがキーの定期的な再検証を実行して、サーバーの状態が自動で "準備完了" になるのを待ちます。
Microsoft Entra ID から、Key Vault に格納されている暗号化キーを取得するために使用されるマネージド ID を削除した。	ID を回復し、サービスがキーの定期的な再検証を実行して、サーバーの状態が自動で "準備完了" になるのを待ちます。
Key Vault のアクセス許可モデルがロールベースのアクセス制御を使用するように構成されていて、いずれかのキーを取得するように構成されているマネージド ID から、Key Vault Crypto Service Encryption User RBAC ロールの割り当てを削除した。	RBAC の役割をマネージド ID にもう一度付与し、サービスがキーの定期的な再検証を実行して、サーバーの状態が自動で "準備完了" になるのを待ちます。別の方法として、Key Vault のロールを別のマネージド ID に付与し、この別のマネージド ID を使用してキーにアクセスするようにサーバーを更新する方法があります。
Key Vault のアクセス許可モデルがアクセスポリシーを使用するように構成されている。 list、get、wrapKey、unwrapKey のいずれかのキーを取得するように構成されているマネージド ID から、これらのいずれかのアクセスポリシーを取り消した。	RBAC の役割をマネージド ID にもう一度付与し、サービスがキーの定期的な再検証を実行して、サーバーの状態が自動で "準備完了" になるのを待ちます。別の方法として、Key Vault の必要なアクセスポリシーを別のマネージド ID に付与し、この別のマネージド ID を使用してキーにアクセスするようにサーバーを更新する方法があります。
Azure Database for PostgreSQL フレキシブルサーバーが Key Vault と通信してキーを取得できないように、過度に制限の厳しい Key Vault ファイアウォール規則を設定します。	Key Vault ファイアウォールを構成するときは、Azure Database for PostgreSQL フレキシブルサーバーがファイアウォールをバイパスできるように、信頼できる Microsoft サービスを許可するオプションを選択してください。

注

キーが無効、削除、期限切れ、または到達できない場合、前に説明したように、そのキーで暗号化されたデータを持つサーバーは "アクセス不可" になります。サーバーの状態は、暗号化キーを再検証できるようになるまで、"準備完了" には変更されません。

一般に、キーが無効、削除、期限切れ、または到達不能になった後、サーバーは 60 分以内に "アクセス不可" になります。キーが使用可能になると、サーバーが再び "準備完了" になるまでに最大 60 分かかることがあります。

マネージド ID の削除からの復旧

Microsoft Entra IDのKey Vaultに格納されている暗号化キーにアクセスするユーザー割り当てマネージド ID を削除する場合は、次の手順に従って復旧します。

ID を回復するか、Entra ID で新しいマネージド ID を作成します。
新しい ID を作成した場合、削除された ID とまったく同じ名前であっても、暗号化キーにアクセスするためにこの新しい ID を使用する必要があることを認識できるように、Azure Database のフレキシブルサーバープロパティを更新します。
Azure Key Vault (AKV) でキーを操作する適切なアクセス許可がこの ID に与えられていることを確認します。
サーバーがキーを再検証するまで、約 1 時間待ちます。

Important

削除した ID と同じ名前で新しい Entra ID を作成しただけでは、マネージド ID 削除からの復旧とはなりません。

カスタマーマネージドキーを使用したデータ暗号化と、地理的に分散された事業継続機能を活用する

Azure Database for PostgreSQL では、レプリカや geo 冗長バックアップなどの高度なデータ復旧機能がサポートされています。 CMK でのデータ暗号化の基本的な要件に加えて、CMK とこれらの機能を使用したデータ暗号化の設定には、次の要件が適用されます。

geo 冗長バックアップが格納されているリージョンに存在する必要があるKey Vault インスタンスに geo 冗長バックアップ暗号化キーを作成する必要があります。
geo 冗長バックアップが有効な CMK サーバーをサポートするための Azure Resource Manager REST API バージョンは、'2022-11-01-preview' です。 Azure Resource Manager テンプレートを使用して、CMK での暗号化と geo 冗長バックアップ機能の両方を使用するサーバーの作成を自動化する場合は、この API バージョンを使用します。
プライマリデータベースの Key Vault インスタンスと geo 冗長バックアップの暗号化キーを保持する Key Vault インスタンスに対して、同じユーザーマネージド ID を使用して認証することはできません。リージョンの回復性を維持するには、geo 冗長バックアップと同じリージョンにユーザーマネージド ID を作成します。
読み取りレプリカデータベースを作成中に CMK で暗号化するように設定した場合、その暗号化キーは、読み取りレプリカデータベースが存在するリージョンの Key Vault インスタンスに存在する必要があります。同じリージョン内のこのKey Vault インスタンスに対して認証を行うには、ユーザー割り当て ID を作成する必要があります。

テナント間カスタマーマネージドキー (CMK) (プレビュー)

テナント間のカスタマーマネージドキーを使用すると、Azure Database for PostgreSQLフレキシブルサーバーとは異なるMicrosoft Entra IDに属するKey Vaultまたは Managed HSM インスタンスに格納されている暗号化キーを使用できます。テナント間 CMK のセットアップには、テナント間の追加の構成と調整が必要です。テナント間のシナリオでは、Azure Database for PostgreSQL リソースは、サービスプロバイダーと呼ばれる独立系ソフトウェアベンダー (ISV) によって管理されるテナントに存在します。 Azure Database for PostgreSQL リソースの暗号化に使用されるキーは、顧客が管理する別のテナントのキーコンテナーに存在します。

設定の概要

ISV テナント上で

マルチテナントアプリケーションを作成する
- アプリケーションのフェデレーション資格情報としてユーザー割り当てマネージド ID を構成します

クライアントテナント上で

マルチテナントアプリケーションをインストールする
既存のキーコンテナーまたはマネージド HSM を作成または使用し、マルチテナントアプリケーションにキーのアクセス許可を付与する
1. 新しいキーを作成するか、既存のキーを使います
2. Azure Key Vault または Azure Managed HSM からキーを取得し、キー識別子を記録する

ISV テナント上で

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

カスタマーマネージドキーを使用して Azure Database for PostgreSQL サーバーを作成する場合は、顧客が使用したキーにアクセスできることを確認する必要があります。シングルテナントのシナリオでは、Azure Database for PostgreSQL サーバーのユーザーマネージド ID に Key Vault へのアクセス権を直接付与します。クロステナントのシナリオでは、Key Vault は顧客が管理する別のテナントにあるため、Key Vault への直接アクセスできることを前提にできなくなります。この制約により、テナント間アプリケーションを作成し、アプリケーション内にマネージド ID を登録して、前のセクションで顧客のキーコンテナーにアクセスできるようにしました。このマネージド ID は、テナント間アプリケーション ID と組み合わせて、Azure Database for PostgreSQL サーバーのクロステナント CMK を作成するときに使用します。

キーコンテナーで新しいバージョンのキーが使用可能になると、Azure Database for PostgreSQL サーバーによって新しいバージョンが自動的に選択されます。

Azure ポータルを使用する

Azure ポータルで新しいAzure Database for PostgreSQL サーバーのテナント間カスタマーマネージドキーを構成するには、次の手順に従います。

リソースの作成Azure Database for PostgreSQLで、Azure ポータルの Security タブを選択し、 Customer マネージドキーを選択します。
ユーザー割り当てマネージド ID として作成された ユーザー割り当てマネージド ID を割り当てます。
アプリケーション名を使用して マルチテナントアプリケーション を割り当てます。
クライアントテナントから取得した顧客の キー識別子 を使用して、 キー選択メソッド に キー識別子 を入力します。

AZURE RESOURCE MANAGER JSON テンプレートと REST API を使用する

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

注

Azure Resource Manager テンプレートのいずれかでこのサンプルを再作成する場合は、apiVersion2025-03-15-privatepreview 以降のバージョンを使用します。

パラメーター	Description	値の例
`primaryKeyUri`	サービスプロバイダーのキーコンテナーに存在するカスタマーマネージドキーの識別子。	`https://my-vault.vault.azure.com/keys/my-key`
`primaryUserAssignedIdentity`	マネージド ID を Azure Database for PostgreSQL フレキシブルサーバーに割り当てる必要があることを指定するオブジェクト。	`"identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}`
`primaryFederatedIdentityClientId`	マルチテナント Microsoft Entra アプリケーションのクライアント ID。	`application-client-id`

3 つのパラメーターが構成された REST API の例を次に示します。

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

要求本文の例:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

キーローテーション用の REST API の例を次に示します。 PATCH の例では、CMK キー URI のみを更新して、サーバーを再作成せずに暗号化キーをローテーションします。

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

要求本文 (キーのローテーションの例):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Important

primaryKeyUri のみを更新する場合でも、要求本文ですべてのデータ暗号化プロパティを指定する必要があります。要求本文に primaryFederatedIdentityClientId を指定しない場合、要求はテナント間以外の CMK 構成として扱われます。

テナント間カスタマーマネージドキー (CMK) プレビューの制限事項

Azure PowerShellとAzure CLIはまだこの機能をサポートしていません。
地理的に分散したバックアップ機能を備えたサーバーの構築と長期保存バックアップ操作の有効化は、現在サポートされていません。
プレビューは現在、次のリージョンでのみサポートされています。
- 米国東部 2
- 米国西部 2
- 米国中部
- オーストラリア南東部
- オーストラリア東部
- 北ヨーロッパ

カスタマーマネージドキー (CMK) の制限事項

Azure Database for PostgreSQL フレキシブルサーバーでカスタマーマネージドキーを構成するための現在の制限事項を次に示します。

カスタマーマネージドキー暗号化は、既存の Azure Database for PostgreSQL フレキシブルサーバーの更新としてではなく、新しいサーバーの作成時にのみ構成できます。代わりに、 CMK 暗号化を使用して PITR バックアップを新しいサーバーに復元できます。
カスタマーマネージドキー暗号化を構成した後、システムマネージドキーに戻すことはできません。元に戻す場合は、システムマネージドキーを使用してデータ暗号化を構成した新しいサーバーに復元する必要があります。
Azure Key Vault Managed HSM のインスタンス、または暗号化キーを格納するAzure Key Vaultのインスタンスは、フレキシブルサーバー用の Azure Database を作成するのと同じリージョンに存在する必要があります。

Azure Database for PostgreSQL でのデータ暗号化を構成する

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-16

Azure Database for PostgreSQL フレキシブル サーバーにおける保存データの暗号化

サービス マネージド キー (SMK) またはカスタマー マネージド キー (CMK) を使用した保存時の暗号化

各モード (SMK または CMK) によって提供される利点

CMK の要件

CMK キーバージョンの更新

キーの手動ローテーションと更新

キー バージョンの自動更新

推奨事項

特別な考慮事項

Azure Key Vault からの誤ったキー アクセスの失効

Azure Key Vaultに保持されているキーを監視する

カスタマー マネージド キーを使用して構成されたサーバーのバックアップを復元する

マネージド HSM

カスタマー マネージド キーのアクセス不可状態

マネージド ID の削除からの復旧

カスタマー マネージド キーを使用したデータ暗号化と、地理的に分散された事業継続機能を活用する

テナント間カスタマー マネージド キー (CMK) (プレビュー)

設定の概要

Azure ポータルを使用する

AZURE RESOURCE MANAGER JSON テンプレートと REST API を使用する

テナント間カスタマー マネージド キー (CMK) プレビューの制限事項

カスタマー マネージド キー (CMK) の制限事項

関連コンテンツ

フィードバック

その他のリソース

Azure Database for PostgreSQL フレキシブルサーバーにおける保存データの暗号化

サービスマネージドキー (SMK) またはカスタマーマネージドキー (CMK) を使用した保存時の暗号化

キーバージョンの自動更新

Azure Key Vault からの誤ったキーアクセスの失効

カスタマーマネージドキーを使用して構成されたサーバーのバックアップを復元する

カスタマーマネージドキーのアクセス不可状態

カスタマーマネージドキーを使用したデータ暗号化と、地理的に分散された事業継続機能を活用する

テナント間カスタマーマネージドキー (CMK) (プレビュー)

テナント間カスタマーマネージドキー (CMK) プレビューの制限事項

カスタマーマネージドキー (CMK) の制限事項