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 マネージド ハードウェア セキュリティ モジュール (HSM) をデプロイし、Azure Database for PostgreSQL フレキシブル サーバー インスタンスで使用される暗号化キーを格納するように構成する必要があります。
このモードは、サーバーの作成時にのみ選択可能です。 サーバーの有効期間は、あるモードから別のモードに変更することはできません。
データの暗号化を実現するために、Azure Database for PostgreSQL では 保存データに Azure Storage 暗号化が使用されます。 CMK を使用する場合、Blob Storage および Azure Files のデータを暗号化および復号化するためのキーは、お客様自身で提供および管理していただく必要があります。 これらのキーは、Azure Key Vault または Azure Key Vault マネージド ハードウェア セキュリティ モジュール (HSM) に格納する必要があります。 詳細については、「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 のデータ暗号化を構成するための要件の一覧を次に示します。
- Key Vault と Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、同じ Microsoft Entra テナントに属している必要があります。 テナント間の Key Vault とサーバーの対話はサポートされていません。 後で 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 に、次の方法でキーへのアクセス権を付与します。
- 推奨: Azure Key Vault は、RBAC アクセス許可モデルで構成し、マネージド ID に Key Vault Crypto Service Encryption User ロールを割り当てる必要があります。
- レガシ: Azure Key Vault が アクセス ポリシーのアクセス許可モデルで構成されている場合は、マネージド ID に次のアクセス許可を付与します。
- get: Key Vault 内のキーのプロパティと公開部分を取得します。
- list: Key Vault に格納されているキーを一覧表示して反復処理します。
- wrapKey: データ暗号化キーを暗号化します。
- unwrapKey: データ暗号化キーを復号化します。
- データ暗号化キーの暗号化に使用されるキーは、非対称の RSA または RSA-HSM のみです。 サポートされているキー サイズは、2,048、3,072、4,096 です。 セキュリティを強化するため、4096 ビットのキーを使用することをお勧めします。
- キーのアクティブ化の日付と時刻 (設定する場合) は、過去の日付と時刻にする必要があります。 有効期限の日付と時刻 (設定する場合) は、後で指定する必要があります。
- キーは、"有効" 状態になっている必要があります。
- Key Vault に既存のキーをインポートする場合は、サポートされているファイル形式 (
.pfx、.byok、または.backup) で提供します。
CMK キーバージョンの更新
CMK は、キーの手動ローテーションと更新、または Key Vault での手動または自動キーローテーションの後にキーバージョンの自動更新を使用して構成できます。
詳細については、「サーバーのプロビジョニング時にカスタマー マネージド キーでデータ暗号化を構成する」を参照してください。
Important
キーを新しいバージョンにローテーションする際は、再暗号化を正常に完了するために、古いキーを利用可能な状態に保っておく必要があります。 ほとんどの再暗号化は 30 分以内に完了しますが、古いキー バージョンへのアクセスを無効にする前に、少なくとも 2 時間は待機することを推奨します。
キーの手動ローテーションと更新
手動のキー更新で CMK を構成する場合は、Key Vault の手動または自動キーローテーションの後に、Azure Database for PostgreSQL フレキシブル サーバー インスタンスのキー バージョンを手動で更新する必要があります。 キーが更新されるまで、サーバーは古いバージョンを使用し続けます。 このモードをプロビジョニングするには、バージョン GUID を含むキー URI を指定してください。 たとえば、「 https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version> 」のように入力します。 最近までは、これが唯一の選択肢でした。
キーを手動でローテーションする場合や、AKV がローテーション ポリシーに従って自動的にローテーションする場合には、PostgreSQL インスタンスの CMK プロパティを毎回更新する必要がありました。 この方法は、オペレーターにとってエラーが発生しやすく、特に Key Vault の自動ローテーション機能を使用する場合には、ローテーション処理のためにカスタム スクリプトが必要になることがありました。
キー バージョンの自動更新
キー バージョンの自動更新を有効にするには、バージョン指定のないキー URI を使用してください。 これにより、キーをローテーションした後でも、PostgreSQL インスタンスの CMK バージョン プロパティを更新する必要がなくなります。 PostgreSQL は新しいキー バージョンを自動的に検出し、データ暗号化キーを再暗号化します。 これは、特に Key Vault の自動ローテーション機能と併用することで、キー ライフサイクル管理を大幅に簡素化できます。
ARM、Bicep、Terraform、Azure PowerShell、または Azure CLI を使用して構成する場合は、キー URI からバージョン GUID を省略してください。
ポータルでチェック ボックスをオンにすると、対話型の選択や URI の検証時に、UI がバージョン GUID を表示しないよう制御されます。
推奨事項
データ暗号化のためにカスタマー マネージド キーを使用している場合、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 portal で新しい 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 を使用する必要があることを認識できるように、フレキシブル サーバー インスタンス プロパティ用に Azure Database を更新します。
- Azure Key Vault (AKV) でキーを操作する適切なアクセス許可がこの ID に与えられていることを確認します。
- サーバーがキーを再検証するまで、約 1 時間待ちます。
Important
削除した ID と同じ名前で新しい Entra ID を作成しただけでは、マネージド ID 削除からの復旧とはなりません。
カスタマー マネージド キーと geo 冗長ビジネス継続性機能でのデータ暗号化の使用
Azure Database for PostgreSQL では、レプリカや geo 冗長バックアップなどの高度なデータ復旧機能がサポートされています。 CMK とこれらの機能を使用してデータ暗号化を設定するための要件には、CMK を使用したデータ暗号化の基本的な要件に加えて、以下のものがあります。
- geo 冗長バックアップ暗号化キーは、geo 冗長バックアップが格納されているリージョンに存在する必要がある Key Vault インスタンスに作成する必要があります。
- 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 は、同じリージョンに作成する必要があります。
制限事項
Azure Database for PostgreSQL フレキシブル サーバー インスタンスでカスタマー マネージド キーを構成するための現在の制限事項を次に示します。
- カスタマー マネージド キー暗号化は、既存の Azure Database for PostgreSQL フレキシブル サーバー インスタンスの更新としてではなく、新しいサーバーの作成時にのみ構成できます。 代わりに CMK 暗号化を使用して、PITR バックアップを新しいサーバーに復元できます。
- カスタマー マネージド キー暗号化を構成した後、システム マネージド キーに戻すことはできません。 元に戻す場合は、システム マネージド キーを使用してデータ暗号化を構成した新しいサーバーに復元する必要があります。
- 暗号化キーを格納する予定の Azure Key Vault マネージド HSM のインスタンスまたは Azure Key Vault のインスタンスは、フレキシブル サーバー用 Azure Database のインスタンスが作成されているのと同じリージョンに存在する必要があります。