次の方法で共有

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

  • [アーティクル]

適用対象: Azure Database for MySQL - シングル サーバー

重要

Azure Database for MySQL シングル サーバーは廃止パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、Azure Database for MySQL シングル サーバーの現状に関するページを参照してください

Azure Database for MySQL のカスタマーマネージド キーによるデータ暗号化では、保存データの保護に Bring Your Own Key (BYOK) を使用できます。 また、組織でキーとデータの管理における職務の分離を実装することもできます。 カスタマーマネージド暗号化を使用する場合、キーのライフサイクル、キーの使用アクセス許可、およびキーに対する操作の監査については、お客様の責任となり、お客様が完全に制御できます。

Azure Database for MySQL のカスタマーマネージド キーによるデータ暗号化は、サーバーレベルで設定されます。 特定のサーバーについては、キー暗号化キー (KEK) と呼ばれる、カスタマーマネージド キーを使用して、サービスによって使用されるデータ暗号化キー (DEK) を暗号化します。 KEK は、顧客が所有する、カスタマーマネージド Azure Key Vault インスタンスに格納される非対称キーです。 キー暗号化キー (KEK) とデータ暗号化キー (DEK) については、この記事の後半で詳しく説明します。

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

注意

この機能は、General Purpose およびメモリ最適化価格レベルで使用できる "General Purpose ストレージ v2 (最大 16 TB をサポート)" ストレージでのみサポートされます。 詳細については、ストレージの概念に関するセクションを参照してください。 その他の制限事項については、「制限事項」セクションを参照してください。

メリット

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

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

用語と説明

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

キー暗号化キー (KEK) :DEK の暗号化に使用される暗号化キー。 Key Vault を離れることがない KEK では、DEK 自体を暗号化および制御できます。 KEK へのアクセス権を持つエンティティは、DEK を必要とするエンティティとは異なる場合があります。 D の複合化には KEK が必要であるため、KEK を削除することにより DEK を効率的に削除できる有効な単一ポイントになります。

KEK で暗号化された DEK は、個別に格納されます。 KEK へのアクセス権を持つエンティティでのみ、これらの DEK の暗号化を解除できます。 詳細については、保存時の暗号化のセキュリティに関するページを参照してください。

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

MySQL サーバーで DEK の暗号化のために Key Vault に格納されているカスタマーマネージド キーを使用する場合、Key Vault 管理者がサーバーに次のアクセス権を付与します。

  • get:Key Vault 内のキーの公開部分とプロパティを取得します。
  • wrapKey:DEK を暗号化できるようにします。 暗号化された DEK は Azure Database for MySQL に格納されます。
  • unwrapKey:DEK の暗号化を解除できるようにします。 Azure Database for MySQL でデータを暗号化または復号化するには、暗号化解除された DEK が必要となります

Key Vault 管理者は、後で監査できるように、Key Vault の監査イベントのログ記録を有効にすることもできます。

Key Vault に格納されているカスタマーマネージド キーを使用するようにサーバーが構成されている場合、暗号化のためにサーバーから DEK が Key Vault に送信されます。 Key Vault から暗号化された DEK が返され、ユーザー データベースに格納されます。 同様に、必要に応じて、保護された DEK が暗号化解除のためにサーバーから Key Vault に送信されます。 ログ記録が有効になっている場合、監査者は Azure Monitor を使用して Key Vault の監査イベント ログを確認できます。

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

Key Vault を構成するための要件を以下に示します。

  • Key Vault と Azure Database for MySQL は、同じ Microsoft Entra テナントに属している必要があります。 テナント間の Key Vault とサーバーの対話はサポートされていません。 後で Key Vault リソースを移動する場合は、データ暗号化を再構成する必要があります。
  • キー (または Key Vault) を誤って削除した場合にデータの損失を防ぐには、保有期間を 90 日に設定して、キー コンテナーの論理的な削除機能を有効にします。 保有期間が明示的に 90 日以下に設定されていない限り、論理的に削除されたリソースは、既定で 90 日間保持されます。 復旧と消去のアクションには、Key Vault のアクセス ポリシーに関連付けられた独自のアクセス許可があります。 論理的な削除機能は既定ではオフになっていますが、PowerShell または Azure CLI を介して有効にすることができます (Azure portal を介して有効にできないことに注意してください)。
  • 保有期間を 90 日に設定して、キー コンテナーの消去保護機能を有効にします。 消去保護は、論理的な削除が有効な場合にのみ有効にすることができます。 これは Azure CLI または PowerShell を使用して有効にできます。 消去保護が有効な場合、削除状態のコンテナーまたはオブジェクトは、保持期間が経過するまで消去できません｡ 論理的に削除されたこれらのコンテナーとオブジェクトはまだ回復可能で、アイテム保持ポリシーに確実に従うことができます。
  • Azure Database for MySQL に対し、その一意のマネージド ID を使用して、get、wrapKey、および unwrapKey アクセス許可による Key Vault へのアクセスを付与します。 Azure portal では、MySQL でのデータ暗号化を有効にすると、一意の "サービス" ID が自動的に作成されます。 Azure portal を使用する場合の詳細な手順については、MySQL のデータ暗号化の構成に関するページを参照してください。

カスタマーマネージド キーを構成するための要件を以下に示します。

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

推奨事項

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

  • Key Vault でリソース ロックを設定して、この重要なリソースを削除できるユーザーを制御し、誤削除や許可されていない削除を防ぎます。
  • すべての暗号化キーの監査およびレポートを有効にします。 Key Vault で提供されるログは、他のセキュリティ情報およびイベント管理ツールに簡単に挿入できます。 Azure Monitor Log Analytics は、既に統合されているサービスの一例です。
  • DEK のラップおよびラップ解除操作のアクセスを高速化するために、Key Vault と Azure Database for MySQL が同じリージョンにあることを確認します。
  • Azure KeyVault をプライベート エンドポイントと選択されたネットワークのみにロックダウンし、信頼された Microsoft サービスのみがリソースを保護できるようにします。

カスタマーマネージド キーを構成する場合の推奨事項は次のとおりです。

  • カスタマーマネージド キーのコピーを安全な場所に保管するか、エスクロー サービスにエスクローします。

  • Key Vault でキーを生成する場合は、初めてキーを使用する前に、キーのバックアップを作成します。 バックアップは Key Vault にのみ復元できます。 バックアップ コマンドの詳細については、「Backup-AzKeyVaultKey」を参照してください。

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

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

  • データ暗号化が有効になっている Azure Database for MySQL 単一サーバーに対してポイントインタイム リストア サーバーを作成すると、新しく作成されたサーバーは "アクセス不可" 状態になります。 これは Azure portal または CLI から修正できます。
  • データ暗号化が有効になっている Azure Database for MySQL 単一サーバーに対して読み取りレプリカを作成すると、レプリカ サーバーは "アクセス不可" 状態になります。 これは Azure portal または CLI から修正できます。
  • KeyVault を削除すると、Azure Database for MySQL 単一サーバーはキーにアクセスできなくなり、"アクセス不可" 状態に移行します。 Key Vault を復旧し、データ暗号化を再検証して、サーバーを "使用可能" にします。
  • KeyVault のキーを削除すると、Azure Database for MySQL 単一サーバーはキーにアクセスできなくなり、"アクセス不可" 状態に移行します。 キーを復旧し、データ暗号化を再検証して、サーバーを "使用可能" にしてください。
  • Azure KeyVault に格納されているキーの有効期限が切れると、キーは無効になり、Azure Database for MySQL 単一サーバーは "アクセス不可" 状態に移行します。 CLI を使用してキーの有効期限を延長した後、データの暗号化を再検証して、サーバーを "使用可能" にします。

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

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

  • サーバーからキー コンテナーの get、wrapKey、および unwrapKey のアクセス許可を取り消す。
  • キーを削除する。
  • Key Vault を削除する。
  • Key Vault のファイアウォール規則を変更する。
  • Microsoft Entra ID でサーバーのマネージド ID を削除する。

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

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

  • Azure Resource Health:カスタマー キーにアクセスできなくなったアクセス不可のデータベースでは、データベースへの最初の接続が拒否された後、"アクセス不可" と表示されます。

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

  • アクション グループ:必要に応じて通知とアラートを送信するように、これらのグループを定義します。

Key Vault 内の顧客のマネージド キーを使用して復元およびレプリケートする

Key Vault に格納されている顧客のマネージド キーで Azure Database for MySQL が暗号化された後、新しく作成されたサーバーのコピーも暗号化されます。 この新しいコピーは、ローカルまたは geo リストア操作を使用するか、読み取りレプリカを使用して作成することができます。 しかし、暗号化のための新しい顧客のマネージド キーを反映するように、コピーを変更することはできます。 カスタマーマネージド キーが変更された場合、最新のキーを使用してサーバーの古いバックアップが開始されます。

復元または読み取りレプリカの作成中にカスタマー マネージド データの暗号化を設定する際の問題を回避するには、ソースおよび復元またはレプリカ サーバーでこれらの手順に従うことが重要です。

  • ソース Azure Database for MySQL から、復元または読み取りレプリカの作成プロセスを開始します。
  • 新しく作成されたサーバー (復元またはレプリカ) は、アクセス不可状態のままにしておきます。これは、その一意の ID に Key Vault へのアクセス許可がまだ付与されていないためです。
  • 復元またはレプリカ サーバーで、データ暗号化設定のカスタマーマネージド キーを再検証して、Key Vault に格納されているキーへのラップおよびラップ解除アクセス許可が新しく作成されたサーバーに付与されるようにします。

制限事項

Azure Database for MySQL の場合、カスタマー マネージド キー (CMK) を使用した保存データの暗号化のサポートには、いくつかの制限があります。

  • この機能のサポートは、General Purpose および Memory Optimized 価格レベルに限定されています。

  • この機能は、汎用ストレージ v2 (最大 16 TB) をサポートしているリージョンとサーバーでのみサポートされています。 最大 16 TB のストレージをサポートする Azure リージョンの一覧については、こちらのドキュメントにあるストレージのセクションを参照してください

    Note

    • 汎用ストレージ v2 をサポートしている Azure リージョンで作成されたすべての新しい MySQL サーバーで、カスタマー マネージド キーによる暗号化のサポートを利用できます。 ポイント イン タイム リストア (PITR) サーバーまたは読み取りレプリカは、理論上 ' 新規 ' には該当しません。
    • プロビジョニングされたサーバーによって汎用ストレージ v2 がサポートされているかどうかを検証するには、ポータルの [価格レベル] ブレードにアクセスして、プロビジョニング済みのサーバーでサポートされる最大ストレージ サイズを確認します。 スライダーを最大 4 TB まで動かすことができる場合、お使いのサーバーは汎用ストレージ v1 上にあり、カスタマー マネージド キーを使用した暗号化はサポートされません。 ただし、データは常にサービス マネージド キーを使用して暗号化されます。

  • RSA 2048 暗号化キーを使用した暗号化のみがサポートされています。

次のステップ