次の方法で共有

Azure Database for MySQL - フレキシブル サーバーのカスタマー マネージド キーを使用したデータ暗号化

  • [アーティクル]

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

Azure Database for MySQL フレキシブル サーバーに対するカスタマー マネージド キーを使用したデータ暗号化を使用すると、保存データの保護に Bring Your Own Key (BYOK) を使用でき、キーとデータの管理における職務の分離を実施できます。 カスタマー マネージド キー (CMK) では、キー ライフサイクル管理 (キーの作成、アップロード、交換、削除)、キーの使用権限、およびキーに対する操作の監査は、お客様の責任であり、お客様がこれらを完全に制御できます。

Note

Azure Key Vault Managed HSM (ハードウェア セキュリティ モジュール) は現在、Azure Database for MySQL フレキシブル サーバー用のカスタマー マネージド キーに対してサポートされています。

メリット

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

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

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

Microsoft Entra ID のマネージド ID は、自動的に割り当てられる ID をプロビジョニングすることで、資格情報をコードに格納するのに代わる手段を Azure サービスに提供します。自動的に割り当てられる ID は、Azure Key Vault (AKV) などの Microsoft Entra 認証をサポートする任意のサービスに対する認証に使用できます。 Azure Database for MySQL フレキシブル サーバーでは、現在、ユーザー割り当てマネージド ID (UMI) のみがサポートされています。 詳細については、Azure の「マネージド ID の種類」を参照してください。

Azure Database for MySQL フレキシブル サーバーの CMK を構成するには、UMI をサーバーにリンクし、使用する Azure キー コンテナーとキーを指定する必要があります。

UMI には、Key Vault への次のアクセス権が必要です。

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

RBAC が有効化されている場合は、UMI に次のロールも割り当てられている必要があります。

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

用語と説明

データ暗号化キー (DEK) :データのパーティションまたはブロックの暗号化に使用される対称 AES256 キー。 データの各ブロックを異なるキーで暗号化することによって、暗号化分析攻撃がより困難になります。 DEK へのアクセスは、特定のブロックを暗号化および復号化するリソース プロバイダーまたはアプリケーション インスタンスで必要になります。 DEK を新しいキーで置き換える場合に、新しいキーを使用して再暗号化する必要があるのは、その関連ブロック内のデータのみです。

キー暗号化キー (KEK) :DEK の暗号化に使用される暗号化キー。 Key Vault を離れることがない KEK では、DEK 自体を暗号化および制御できます。 KEK へのアクセス権を持つエンティティは、DEK を必要とするエンティティとは異なる場合があります。 DEK の復号化には KEK が必要であるため、KEK を削除すると DEK を事実上削除でき、KEK が実際には単一ポイントになります。 KEK で暗号化された DEK は、個別に格納されます。 KEK へのアクセス権を持つエンティティでのみ、これらの DEK の暗号化を解除できます。 詳細については、保存時の暗号化のセキュリティに関するページを参照してください。

しくみ

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 が暗号化解除のためにフレキシブル サーバーから Key Vault に送信されます。

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

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

注意

アクセス許可の変更がキー コンテナーに影響を与えるのに最大 10 分かかる場合があります。 これには、AKV の TDE プロテクターへのアクセス許可の取り消しが含まれます。この概算時間内のユーザーには、まだアクセス許可がある可能性があります。

Azure Database for MySQL フレキシブル サーバーのデータ暗号化を構成するための要件

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

  • キー コンテナーと Azure Database for MySQL フレキシブル サーバー インスタンスは、同じ Microsoft Entra テナントに属している必要があります。 テナント間の Key Vault とフレキシブル サーバーの対話はサポートされている必要があります。 構成の実行後に Key Vault リソースを移動する場合は、データ暗号化を再構成する必要があります。
  • キー コンテナーと Azure Database for MySQL フレキシブル サーバー インスタンスは同じリージョンに存在している必要があります。
  • キー (または Key Vault) を誤って削除した場合にデータの損失を防ぐには、保有期間を 90 日に設定して、キー コンテナーの論理的な削除機能を有効にします。 復旧と消去アクションには、キー コンテナーのアクセス ポリシーで独自のアクセス許可があります。 論理的な削除機能は既定でオフになっていますが、Azure portal を介して、もしくは PowerShell または Azure CLI を使用して有効にすることができます。
  • キー コンテナーの消去保護機能を有効にし、保有期間を 90 日に設定します。 消去保護が有効な場合、削除状態のコンテナーまたはオブジェクトは、保持期間が経過するまで消去できません｡ この機能は、PowerShell または Azure CLI を使用して、論理的な削除を有効にした後でのみ有効にすることができます。

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

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

Note

Azure portal を使用して Azure Database for MySQL フレキシブル サーバーのデータ暗号化を構成する方法の詳細な手順については、Azure Database for MySQL フレキシブル サーバーのデータ暗号化の構成に関するページを参照してください。

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

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

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

Note

  • 同じリージョンのキー コンテナーを使用することをお勧めしますが、必要に応じて、"キー識別子の入力" 情報を指定することで、別のリージョンのキー コンテナーを使用できます。 キー コンテナー マネージド HSM は、MySQL フレキシブル サーバーと同じリージョンに存在する必要があります。

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

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

  • キー コンテナーを削除すると、Azure Database for MySQL フレキシブル サーバー インスタンスはキーにアクセスできなくなり、"アクセス不可" 状態に移行します。 Azure Database for MySQL フレキシブル サーバー インスタンスを "使用可能" にするには、キー コンテナーを回復し、データ暗号化を再検証します。
  • キー コンテナーからキーを削除すると、Azure Database for MySQL フレキシブル サーバー インスタンスはキーにアクセスできなくなり、"アクセス不可" 状態に移行します。 Azure Database for MySQL フレキシブル サーバー インスタンスを "使用可能" にするには、キーを回復し、データ暗号化を再検証します。
  • Azure キー コンテナーに保存されているキーの有効期限が切れると、キーは無効になり、Azure Database for MySQL フレキシブル サーバー インスタンスは "アクセス不可" 状態に移行します。 Azure Database for MySQL フレキシブル サーバー インスタンスを "使用可能" にするには、CLI を使用してキーの有効期限を延長した後、データの暗号化を再検証します。

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

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

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

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

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

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

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

キー コンテナーに保存されているカスタマーのマネージド キーで Azure Database for MySQL フレキシブル サーバー インスタンスが暗号化された後、新しく作成されたサーバーのコピーも暗号化されます。 カスタマー マネージド キーを使用して既にレプリカがある Azure Database for MySQL フレキシブル サーバー インスタンスを暗号化する場合は、そのマネージド ID とキーを追加してそのレプリカを構成することをお勧めします。 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 フレキシブル サーバー インスタンスから、復元または読み取りレプリカの作成プロセスを開始します。
  • 復元またはレプリカ サーバーで、データ暗号化設定のカスタマー マネージド キーを再検証して、Key Vault に格納されているキーへの Get、List、Wrap key および Unwrap key アクセス許可がユーザー マネージド ID に付与されるようにします。

Note

復元の実行時に、ソース サーバーと同じ ID とキーを使用することは必須ではありません。

次のステップ