次の方法で共有

データの暗号化

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

Azure Database for PostgreSQL のインスタンスで管理されるすべてのデータは、保存時に常に暗号化されています。 このデータには、すべてのシステムとユーザー データベース、一時ファイル、サーバー ログ、先行書き込みログ (write-ahead log) セグメント、バックアップが含まれます。

データの暗号化を実現するために、Azure Database for PostgreSQL - フレキシブル サーバーでは、保存データに対する Azure Storage 暗号化を使用し、Blob Storage と Azure Files サービスのデータを暗号化および復号化するためのキーが提供されます。 これらのキーは、Azure Key Vault または Azure Key Vault Managed Hardware Security Model (HSM) に格納する必要があります。 詳細については、「Azure Storage 暗号化のカスタマー マネージド キー」を参照してください。

Azure Database for PostgreSQL - フレキシブル サーバーは、サービス マネージド キーとカスタマー マネージド キーの 2 つの異なるモードでのデータ暗号化の構成をサポートしています。 構成モードは、サーバー作成時にのみ選択できます。 サーバーの有効期間は、あるモードから別のモードに変更することはできません。

サービス マネージド暗号化キーを使用します。Azure Database for PostgreSQL - フレキシブル サーバーは、キーが保管される Azure Key Vault のプロビジョニングを行い、データが暗号化および復号化されるキーが提供される責任を負います。 また、このサービスは、キーの格納、保護、アクセスの監査、ネットワークの構成、キーの自動交換も行います。

カスタマー マネージド暗号化キーでは、ユーザーがすべての責任を負います。 したがって、独自の 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 フレキシブル サーバーのサービス マネージド キーによるデータ暗号化には、次の利点があります。

  • このサービスは、データ アクセスを自動的かつ完全に制御します。
  • このサービスは、キーのローテーションなど、キーのライフサイクルを自動的かつ完全に制御します。
  • データ暗号化キーの管理を心配する必要はありません。
  • サービス マネージド キーに基づくデータ暗号化は、ワークロードのパフォーマンスに悪影響を与えません。
  • 次の管理を簡略化します:

Azure Database for PostgreSQL フレキシブル サーバーのカスタマー マネージド キーによるデータ暗号化には、次の利点があります。

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

要件

Azure Database for PostgreSQL フレキシブル サーバーのデータ暗号化を構成するための要件を次に一覧表示します。

  • キー コンテナーと 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) で提供します。

推奨事項

データ暗号化のためにカスタマー マネージド キーを使用している場合、Key Vault の構成に関する推奨事項は次のとおりです。

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

Note

[パブリック アクセスを無効にする] を選択し、[信頼された Microsoft サービスがこのファイアウォールをバイパスすることを許可する] を選択した後、ポータルでパブリック アクセスを使用して Key Vault を管理しようとすると、次のようなエラーが表示されることがあります。"ネットワーク アクセスの制御が有効になりました。 このキー コンテナーにアクセスできるのは、許可されたネットワークだけです。"このエラーによりカスタマー マネージド キーのセットアップ中にキーを指定することや、サーバー捜査中に Key Vault からキーをフェッチすることができなくなります。

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

特別な注意事項

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

Key Vault に対する十分なアクセス権を持つユーザーが、次のことを行うことで、キーへのサーバー アクセスを誤って無効にしてしまうことがあります。

  • RBAC ロール Key Vault Crypto Service Encryption User の割り当てを解除するか、Key Vault でキーを取得するために使用される ID からアクセス許可を取り消します。
  • キーを削除する。
  • 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 に格納されたカスタマー マネージド キーを使用してデータ暗号化を構成する場合に、サーバーをオンラインに保つには、このキーへの継続的なアクセスが必要です。 サーバーで Key Vault に保管されたキーにアクセスできなくなった場合、サーバーでは 10 分以内にすべての接続を拒否し始めます。 サーバーで対応するエラー メッセージが発行され、サーバーの状態が "アクセス不可" に変更されます。

サーバーの状態が "アクセス不可" になる可能性のある理由には次のようなものがあります。

  • キーをローテーションし、キーの新しいバージョンを指すように Azure Database for PostgreSQL フレキシブル サーバーのインスタンスを更新し忘れた場合。 インスタンスが指していた古いキーは最終的に期限切れになり、サーバーの状態はアクセス不可になります。 これを回避するには、キーをローテーションするたびに、新しいバージョンを指すようにサーバーのインスタンスも必ず更新します。 これを行うには、az postgres flexible-server update を使用できます。「データ暗号化のキー/ID を変更します。サーバーの作成後にデータ暗号化を有効にすることはできません。これにより、キー/ID のみが更新されます。"代わりに、サービスの Servers - Update REST API を呼び出すこともできます。
  • Key Vault インスタンスを削除すると、Azure Database for PostgreSQL フレキシブル サーバー インスタンスはキーにアクセスできなくなり、"アクセス不可" 状態に移行します。 サーバーを使用可能にするには、Key Vault インスタンスを復旧し、データ暗号化を再検証します。
  • KeyVault からキーを削除すると、Azure Database for PostgreSQL フレキシブル サーバー インスタンスはキーにアクセスできなくなり、"アクセス不可" 状態に移行します。 サーバーを "使用可能" にするには、キーを回復し、データ暗号化を再検証しまます。
  • Key Vault からキーを取得する目的で使用されているマネージド ID を Microsoft Entra ID から削除した場合、あるいは Key Vault Crypto Service Encryption User ロールのある Azure RBAC ロールの割り当てを削除した場合、 Azure Database for PostgreSQL フレキシブル サーバーはそのキーにアクセスできなくなり、アクセス不可状態に移行されます。 サーバーを "使用可能" にするには、ID を復旧し、データ暗号化を再検証します。
  • KeyVault からキーを取得するために使われているマネージド ID からキー コンテナーの list、get、wrapKey、unwrapKey のアクセス ポリシーを取り消すと、Azure Database for PostgreSQL フレキシブル サーバー インスタンスはキーにアクセスできなくなり、"アクセス不可" 状態に移行します。 KeyVault の ID に必要なアクセス ポリシーを追加します。
  • 過度に制限の厳しい Key Vault ファイアウォール規則を設定した場合、Azure Database for PostgreSQL フレキシブル サーバーは Key Vault と通信してキーを取得できません。 Key Vault ファイアウォールを構成するときは、信頼された Microsoft サービスが ファイアウォールをバイパスできるようにするオプションを必ず選択してください。

Note

キーが無効、削除、期限切れ、または到達できない場合、前に説明したように、そのキーを介して暗号化されたデータを持つサーバーは "アクセス不可" になります。 サーバーは、キーを再度有効にするか、新しいキーを割り当てるまで使用できなくなります。

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

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

Microsoft Entra ID で、Key Vault に保存された暗号化キーへのアクセスに使用されたユーザー割り当てマネージド ID が削除された場合は、次の手順に従って復旧する必要があります。

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

重要

削除した 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 は、同じリージョンに作成する必要があります。

カスタマー マネージド キーのローテーションとバージョンレス キー (プレビュー)

予防措置として、定期的に、またはキーが侵害されるたびに、キーを交換することをお勧めします。

Note

ほとんどの企業は、定期的にキーをローテーション (90 日ごとなど) するための外部または内部的な要件があります。 Key Vault で生成されたキーの場合は、Azure Key Vault で暗号化キーの自動ローテーションを構成できます。 自動ローテーションを有効にした場合、この機能を利用するには、Azure Database for PostgreSQL フレキシブル サーバーのデータ暗号化にバージョンレス CMK (プレビュー) を使用する必要があります。

キーを手動でローテーションさせることで、キーが侵害された場合でもデータを保護できます。 キーをローテーションするには、侵害されたキーの新しいキー生成を作成またはインポートします。

  • バージョンレス カスタマー マネージド キー (プレビュー) を使用している場合、サーバーは新しいキーを自動的に選択します。
  • バージョン管理されたキーを使用している場合は、新しいバージョンのキーを使用するように Azure Database for PostgreSQL フレキシブル サーバー インスタンスを更新する必要があります。 その後でのみ、サーバーはデータの暗号化と復号化に新しいキーを使い始めるようになります。

バージョンレス カスタマー マネージド キー (プレビュー)

バージョンレス キーは、Azure Database for PostgreSQL フレキシブル サーバーのデータ暗号化で推奨されます。 これは、前述の主要なローテーション シナリオのいずれにも対応します。 新しいキー バージョンが利用可能になると、サーバーはデータの暗号化と復号化に新しいバージョンのキーを自動的に使用します。

API はバージョンレス キーでも変わりません。 すべてのキー識別子 URI を提供する代わりに、キー識別子のバージョン部分を省略します。 これは、API、Azure CLI、ARM テンプレート、Bicep テンプレートに適用されます。 Azure portal には、バージョンレスを有効にするチェックボックスがあります。ここでは、バージョンレス キー識別子のみの選択を使用できます。

制限事項

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

関連するコンテンツ