Azure Database for MySQL のカスタマー マネージド キーを使用したデータ暗号化

Azure Database for MySQL のカスタマー マネージド キーを使用したデータ暗号化を使用すると、保存データ保護のために独自のキー (BYOK) を使用して、キーとデータを管理するための職務の分離を実装できます。 カスタマー マネージド キー (CMK) を使用すると、顧客は次の制御を行います。

• キー ライフサイクル管理 (キーの作成、アップロード、ローテーション、削除)
• キー使用のアクセス許可
• キーに対する操作の監査

カスタマー マネージド キー (CMK) の利点

Azure Database for MySQL のカスタマーマネージド キーによるデータ暗号化には、次の利点があります:

• キーを削除してデータベースにアクセスできないようにすることで、ユーザーがデータアクセスを完全に制御できる
• キーライフサイクルの完全な制御 (企業ポリシーに合わせたキーのローテーションを含む)
• Azure Key Vault または Managed HSM でのキーの一元的な管理と整理
• セキュリティ責任者、DBA、システム管理者の間での職務の分離を実装できる

カスタマー マネージド キーによるデータ暗号化のしくみ

Microsoft Entra ID のマネージド ID は、サービスに対してクライアントを認証するためのより安全な方法を提供します。 CMK 暗号化では、Azure Database for MySQL サーバーのマネージド ID を使用して、CMK を格納する Azure Key Vault に接続します。 現在、Azure Database for MySQL では、Key Vault へのアクセスに対してユーザー割り当てマネージド ID (UAMI) のみがサポートされています。 詳細については、Azure の「マネージド ID の種類」を参照してください。

Azure Database for MySQL の CMK を構成するには、UAMI をサーバーにリンクし、使用する Azure Key Vault とキーを指定する必要があります。

UAMI には、キー ボールトに対して以下のアクセス権が必要です。

• Get: Key Vault 内のキーの公開部分とプロパティを取得します。
• List: Key Vault に格納されているキーのバージョンを一覧表示します。
• Wrap Key: DEK を暗号化できるようにします。 暗号化された DEK は Azure Database for MySQL フレキシブル サーバー インスタンスに格納されます。
• Unwrap Key: DEK の暗号化を解除できるようにします。 Azure Database for MySQL では、データを暗号化または復号化するために、復号化された DEK が必要です。

Azure RBAC が有効になっている場合は、個々のアクセスではなく、UAMI にロールを割り当てる必要があります。

• キー コンテナー暗号化サービス暗号化ユーザー、または次のアクセス許可を持つロール:
  • Microsoft.KeyVault/vaults/keys/wrap/action
  • Microsoft.KeyVault/vaults/keys/unwrap/action
  • Microsoft.KeyVault/vaults/keys/read たとえば "キー コンテナー暗号化サービス暗号化ユーザー"
• マネージド HSM の場合は、Managed HSM 暗号化サービス暗号化ユーザー ロールを割り当てる

CMK を使用したデータ暗号化は、サーバー レベルで設定されます。 特定のサーバーについては、キー暗号化キー (KEK) と呼ばれる CMK を使用して、サービスのデータ暗号化キー (DEK) を暗号化します。 KEK は、顧客が所有する、カスタマー マネージド Azure Key Vault インスタンスに格納される非対称キーです。 Key Vault は、FIPS 140 認定のハードウェア セキュリティ モジュール (HSM) をオプションで使用できる、RSA 暗号化キー向けの、可用性が高くスケーラブルでセキュリティで保護されたストレージです。 Key Vault は、格納されているキーに直接アクセスすることはできませんが、キーを使用して暗号化/復号化サービスを認証されたエンティティに提供します。 インポートされたキー コンテナーは、キーを生成するか、オンプレミスの HSM デバイスからキー コンテナーに転送できます。

Key Vault に格納されている CMK を使用するようにフレキシブル サーバーを構成する場合、暗号化のためにサーバーから DEK が Key Vault に送信されます。 Key Vault から、ユーザー データベースに格納されている暗号化された DEK が返されます。 同様に、フレキシブル サーバーは、必要に応じて暗号化を解除するために、保護された DEK をキー コンテナーに送信します。

ログ記録が有効になったら、監査担当者は Azure Monitor を使用して Key Vault の監査イベント ログを確認できます。 Key Vault 監査イベントのログ記録を有効にするには、「Key Vault 分析情報を使用したキー コンテナー サービスの監視」を参照してください。

Azure Database for MySQL のデータ暗号化を構成するための要件

Key Vault または Managed HSM の構成を試みる前に、次の要件を満たしていることを確認してください。

• Key Vault と Azure Database for MySQL フレキシブル サーバー インスタンスは、同じ Microsoft Entra テナントに属している必要があります。 テナント間の Key Vault とフレキシブル サーバーの対話はサポートされている必要があります。 構成の実行後に Key Vault リソースを移動する場合は、データ暗号化を再構成する必要があります。
• Key Vault と Azure Database for MySQL フレキシブル サーバー インスタンスは同じ Azure リージョンに存在している必要があります。
• キーコンテナーでソフト削除 機能を有効にする
• 消去保護を有効にします。
• 保持期間を 90 日に設定します。
  • 復旧と消去アクションには、Key Vault のアクセス ポリシーで独自のアクセス許可があります。
  • 論理的な削除機能は、既定ではオフになっています。

CMK を構成する前に、必ず次の要件を満たしてください。

• DEK を暗号化するカスタマー マネージド キーは、非対称の RSA/RSA-HSM (Premium SKU のコンテナ－) 2048、3072、または 4096 のみです。
• キーがアクティブ化された日時 (設定する場合) は、過去の日付と時刻にする必要があります。 有効期限は設定しません。
• キーは、"有効" 状態になっている必要があります。
• キーには、保有期間を 90 日に設定した論理的な削除が必要です。 この設定により、必要なキー属性 recoveryLevel が暗黙的に Recoverableに設定されます。
• キーで消去保護が有効になっている必要があります。
• Key Vault に既存のキーをインポートする場合は、サポートされているファイル形式 (.pfx、.byok、.backup) で提供してください。

データ暗号化の構成に関する推奨事項

カスタマー マネージド キーを使用するデータ暗号化を使用するように Key Vault または Managed HSM を構成するときは、次の推奨事項に留意してください。

• Key Vault でリソース ロックを設定して、この重要なリソースを削除できるユーザーを制御し、誤削除や許可されていない削除を防ぎます。
• すべての暗号化キーの監査およびレポートを有効にします。 Key Vault で提供されるログは、他のセキュリティ情報およびイベント管理ツールに簡単に挿入できます。
• カスタマー マネージド キーのコピーを安全な場所に保管するか、エスクロー サービスにエスクローします。
• Key Vault でキーを生成する場合は、初めてキーを使用する前に、キーのバックアップを作成します。 バックアップは Key Vault にのみ復元できます。 バックアップ コマンドの詳細については、「Backup-AzKeyVaultKey」を参照してください。

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

Key Vault で CMK を使用してデータ暗号化を構成する場合、サーバーをオンラインに保つには、このキーへの継続的なアクセスが必要です。 フレキシブル サーバーで Key Vault のカスタマー マネージド キーにアクセスできなくなった場合、サーバーでは 10 分以内にすべての接続を拒否し始めます。 フレキシブル サーバーで対応するエラー メッセージが発行され、サーバーの状態が "アクセス不可" に変更されます。 サーバーは、さまざまな理由でこの状態に達する可能性があります。

キー コンテナーを削除すると、Azure Database for MySQL フレキシブル サーバー インスタンスはキーにアクセスできず、 Inaccessible 状態に移行します。 サーバー インスタンスを Availableするには:

• キー ボールトを復旧します。
• データ暗号化を再検証します。

キー コンテナーからキーを削除すると、Azure Database for MySQL フレキシブル サーバー インスタンスはキーにアクセスできず、 Inaccessible 状態に移行します。 サーバー インスタンスを Availableするには:

• キーを回復 します。
• データ暗号化を再検証します。

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

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

• サーバーからキー コンテナーの "get、list、wrap key、unwrapping key" のアクセス許可を取り消す
• キーを削除する
• キー コンテナーを削除する
• キー コンテナーのファイアウォール規則を変更する
• Microsoft Entra ID でカスタマー マネージド キーを使用したフレキシブル サーバーでの暗号化に使用されるユーザー マネージド ID を削除する

Key Vault でカスタマーマネージド キーを監視する

データベースの状態を監視したり、透過的データ暗号化保護機能アクセスができなくなった場合のアラートを有効にしたりするには、Azure の次の機能を構成します。

• アクティビティ ログ:カスタマーマネージド Key Vault 内のカスタマー キーへのアクセスに失敗すると、アクティビティ ログにエントリが追加されます。 これらのイベントに対してアラートを作成した場合は、できるだけ早くアクセスを再開できます。
• アクション グループ: 必要に応じて通知とアラートを送信するように、これらのグループを定義します。

Key Vault 内のカスタマー マネージド キーを使用したレプリカ作成

Key Vault に格納されている顧客のマネージド キーで Azure Database for MySQL フレキシブル サーバー インスタンスが暗号化された後、新しく作成されたサーバーのコピーも暗号化されます。 既にレプリカを持つカスタマー マネージド キーを使用して Azure Database for MySQL フレキシブル サーバー インスタンスを暗号化する場合は、マネージド ID とキーを追加して 1 つ以上のレプリカを構成することをお勧めします。 Azure Database for MySQL フレキシブル サーバー インスタンスが geo 冗長バックアップを使って構成されているとします。 レプリカは、ID を使用してアクセスでき、サーバーの geo ペア リージョンに存在しているマネージド ID とキーで構成する必要があります。

Key Vault 内のカスタマー マネージド キーを使用した復元

Azure Database for MySQL フレキシブル サーバー インスタンスを復元しようとすると、ユーザー マネージド ID と、復元サーバーを暗号化するキーを選択できます。 Azure Database for MySQL フレキシブル サーバー インスタンスが geo 冗長バックアップを使って構成されているとします。 その場合、マネージド ID と ID がアクセスできるキー、およびサーバーの geo ペア リージョンに存在するキーを使用して、復元サーバーを構成する必要があります。

復元または読み取りレプリカの作成時には、ソース サーバーと復元済み/レプリカ サーバーで次の手順に従う必要があります。

• ソース Azure Database for MySQL フレキシブル サーバー インスタンスから、復元または読み取りレプリカの作成プロセスを開始します。
• 復元/レプリカ サーバーで、データ暗号化設定の CMK を再検証して、キーに対する UAMI アクセス許可を検証します。

関連コンテンツ

• Azure CLI を使用した Azure Database for MySQL - フレキシブル サーバーでのデータ暗号化
• Azure portal を使用した Azure Database for MySQL のデータ暗号化
• 保存時の暗号化のセキュリティ
• Azure Database for MySQL の Microsoft Entra 認証 - フレキシブル サーバー