Azure Key Vault のカスタマー マネージド キーを使った透過的なデータ暗号化に関する一般的なエラー

  • [アーティクル]

適用対象: Azure SQL データベース Azure SQL Managed Instance Azure Synapse Analytics

この記事では、Azure Key Vault のカスタマー マネージド キーで Transparent Data Encryption (TDE) を使用するように構成されたデータベースがアクセスできなくなる原因となった、Azure Key Vault キーのアクセスに関する問題を特定して解決する方法について説明します。

Note

Microsoft Entra ID は以前に Azure Active Directory(Azure AD)として知られていました。

はじめに

Azure Key Vault のカスタマー マネージド キーを使用するように TDE が構成されている場合、データベースをオンラインに保つには、この TDE 保護機能への継続的なアクセスが必要です。 論理 SQL サーバーかマネージド インスタンスが Azure Key Vault のカスタマー マネージド TDE 保護機能にアクセスできなくなった場合、データベースでは該当するエラー メッセージが表示されてすべての接続の拒否が始まり、Azure portal でその状態が Inaccessible になります。

最初の 30 分以内に基になっている Azure Key Vault のキー アクセスの問題が解決されると、データベースは自動修復され、自動的にオンラインになります。 つまり、間欠的および一時的なネットワーク停止のシナリオでは、ユーザーによる対応は必要なく、データベースは自動的にオンラインになります。 ほとんどの場合、基になっている Key Vault のキー アクセスの問題を解決するには、ユーザーによる対応が必要です。

アクセスできないデータベースがもう必要ない場合は、すぐに削除してコストを抑えることができます。 Azure Key Vault キーへのアクセスが復元され、データベースがオンラインに戻るまで、データベースに対する他のすべての操作は許可されません。 カスタマー マネージド キーで暗号化されたデータベースにアクセスできない間は、サーバーで TDE のオプションをカスタマー マネージド キーからサービス マネージド キーに変更することもできません。 これは、TDE 保護機能へのアクセス許可が取り消されているときに、データを不正アクセスから保護するために必要です。

データベースにアクセスできない期間が 30 分を超えると、自動修復は行われなくなります。 この期間の後に必要な Azure Key Vault のキー アクセスが復元された場合は、キーへのアクセスを手動で再検証して、データベースをオンラインに戻す必要があります。 この状況でデータベースをオンラインに戻す場合は、データベースのサイズによってはかなり時間がかかることがあります。 データベースがオンラインに戻ると、フェールオーバー グループ、PITR 履歴、タグなどの以前に構成した設定は失われます。 そのため、基になっている Key Vault のキー アクセスの問題にできる限り早く気付き、対処できるように、アクション グループを使用して通知システムを実装することをお勧めします。

データベースにアクセスできなくなる原因となる一般的なエラー

Key Vault による TDE を使用しているときに発生する問題のほとんどは、次の構成ミスのいずれかが原因です。

キー コンテナーが使用できない、または存在しない

  • キー コンテナーが誤って削除された。
  • Azure Key Vault に対してファイアウォールが構成されたが、そこで Microsoft サービスへのアクセスが許可されていない。
  • 間欠的なネットワーク エラーのために、キー コンテナーを使用できない。

キー コンテナーへのアクセス許可がない、またはキーが存在しない

  • キーが誤って削除された、無効にされた、またはキーの有効期限が切れた。
  • サーバーのマネージド ID (システム割り当てまたはユーザー割り当て) が誤って削除された。
  • サーバーが別のサブスクリプションに移動された。 サーバーが別のサブスクリプションに移動された場合は、新しいマネージド ID (システム割り当てまたはユーザー割り当て) をサーバーに割り当てる必要がある。
  • サーバーのマネージド ID に付与されているキーのアクセス許可が十分ではない (取得、ラップ、ラップ解除のアクセス許可が含まれていない)。
  • サーバーのマネージド ID に対するアクセス許可が、キー コンテナーから取り消された。

一般的なエラーの識別と解決

このセクションでは、最も一般的なエラーに対するトラブルシューティング手順の一覧を示します。

サーバー ID がない

エラー メッセージ

401 AzureKeyVaultNoServerIdentity - サーバーでサーバー ID が正しく構成されていません。 サポートにお問い合わせください。

検出

次のコマンドレットかコマンドを使って、サーバーに ID が割り当てられていることを確認します。

軽減策

次のコマンドレットまたはコマンドを使用して、サーバー用のユーザー割り当てマネージド ID またはシステム割り当てマネージド ID を構成します。

Azure portal では、キー コンテナーに移動してから、[アクセス ポリシー] に移動します。 以下の手順を実行します。

  1. [新規追加] ボタンを使用して、前の手順で作成したサーバーの AppId を追加します。
  2. 次の主要なアクセス許可を割り当てます: Get、Wrap、Unwrap

詳細については、「サーバーに Azure Active Directory (Azure AD) ID を割り当てる」をご覧ください。

重要

Key Vault を使用した TDE の初期構成後に Azure SQL Database の論理サーバー または Azure SQL Managed Instance が新しい Microsoft Entra テナントに移動された場合は、このマネージド ID 構成を新しいテナントで再実行する必要があります。

キー コンテナーがない

エラー メッセージ

"503 AzureKeyVaultConnectionFailed - Azure Key Vault への接続の試みが失敗したため、サーバーでの操作を完了できませんでした"

検出

キー URI とキー コンテナーを識別するには:

  1. 次のコマンドレットかコマンドを使用して、特定のサーバー インスタンスのキー URI を取得します。

  2. キー URI を使用して、キー コンテナーを識別します。

    • Azure PowerShell: $MyServerKeyVaultKey 変数のプロパティを検査して、キー コンテナーの詳細を取得できます。

    • Azure CLI: キー コンテナーの詳細について、返されるサーバー暗号化プロテクターを検査します。

軽減策

キー コンテナーを使用できることを確認します。

  • キー コンテナーが使用可能で、サーバーがアクセス権を持つことを確認します。
  • キー コンテナーがファイアウォールの背後にある場合は、Microsoft サービスによるキー コンテナーへのアクセスを許可するチェック ボックスがオンになっていることを確認します。
  • キー コンテナーが誤って削除された場合は、最初から構成を完了する必要があります。

キーがない

エラー メッセージ

"404 ServerKeyNotFound - The requested server key was not found on the current subscription." (404 ServerKeyNotFound - 要求されたサーバー キーは、現在のサブスクリプションで使用できません。)

"409 ServerKeyDoesNotExists - The server key does not exist." (409 ServerKeyDoesNotExists - サーバー キーは存在しません。)

検出

キー URI とキー コンテナーを識別するには:

  • 「キー コンテナーがない」のコマンドレットまたはコマンドを使用して、論理 SQL Server インスタンスに追加されたキー URI を識別します。 コマンドを実行すると、キーの一覧が返されます。

軽減策

TDE プロテクターが Key Vault に存在することを確認します。

  1. キー コンテナーを識別した後、Azure portal でそのキー コンテナーに移動します。
  2. キー URI によって識別されたキーが存在することを確認します。

キーの期限切れ

エラー メッセージ

サーバー <server_name> には、RBAC ポリシーまたは Azure Key Vault のアクセス許可 (Get、WrapKey、UnwrapKey) に対する Key Vault Crypto Service Encryption のユーザーアクセス許可が必要です。 ID <akv_key> でサービス プリンシパルに欠落しているアクセス許可を付与します。 キーがアクティブであり、有効期限が切れていないか無効で、キーのアクティブ化日が現在の日付より後に設定されていることを確認し、信頼されたMicrosoft サービスが該当する場合はファイアウォールをバイパスできることを確認します。

検出

キー コンテナーの期限切れキー識別するには:

  • Azure portal を使用して、[キー コンテナー] サービス メニュー >[オブジェクト]>[キー] に移動し、キーの有効期限を確認します。
  • PowerShell コマンド Get-AzKeyVaultKey を使用します。
  • Azure CLI コマンド az keyvault key show コマンドを使用します。

軽減策

  • キー コンテナー キーの満了日を確認して、キーの有効期限が切れているかどうかを確認します。
  • キーの満了日を延長します。
  • [キーの再検証] オプションを選択し、次のうち 1 つを選択して、データベースをオンラインに戻します。
    • 既存のキーを再試行します。
    • [バックアップ キー] を選択します。

詳細については、「Inaccessible TDE 保護機能を参照してください。

Note

キーは、エラーに対処するための十分な時間を確保するために、有効期限よりも指定された日数だけ前にローテーションされる必要があります。 詳細については、「キー コンテナー用の Azure Policy 組み込み定義」を参照してください。

アクセス許可がない

エラー メッセージ

"401 AzureKeyVaultMissingPermissions - The server is missing required permissions on the Azure Key Vault." (401 AzureKeyVaultMissingPermissions - サーバーには Azure Key Vault に必要なアクセス許可がありません。)

検出

キー URI とキー コンテナーを識別するには:

  • 「キー コンテナーがない」のコマンドレットまたはコマンドを使用して、論理 SQL Server インスタンスによって使用されるキー コンテナーを識別します。

軽減策

サーバーにキー コンテナーへのアクセス許可と、キーにアクセスするための正しいアクセス許可があることを確認します。

  • Azure portal で、キー コンテナー > [アクセス ポリシー] の順に移動します。 サーバーのマネージド ID (システム割り当てまたはユーザー割り当て) を検索します。
  • サーバーの ID が存在する場合、それが、取得、キーのラップ、キーのラップ解除のキー アクセス許可を持っていることを確認します。
  • サーバーの ID が存在しない場合は、[新規追加] ボタンを使って、それを追加します。

アクティビティ ログから TDE の状態を取得する

Azure Key Vault のキー アクセスの問題によるデータベースの状態を監視できるように、Azure Resource Manager の URL に基づいて、以下のイベントがリソース ID のアクティビティ ログに記録されます。

Note

キー コンテナーのアクセス問題が発生してから、イベントがアクティビティ ログに表示されるまで、少なくとも 15 分から 30 分かかる場合があります。

サービスが Azure Key Vault のキーにアクセスできなくなったときのイベント

Azure SQL Database

EventName: MakeDatabaseInaccessible

状態: 開始済み

説明: サーバー {server_name} 上のデータベース {database_name} は Azure Key Vault のキーにアクセスできなくなり、現在、アクセス不可の状態に移行しています。

Azure SQL Managed Instance

EventName: MakeManagedDbInaccessible

状態: 開始済み

説明: マネージド サーバー {server_name} 上のデータベース {database_name} は Azure Key Vault のキーにアクセスできなくなり、現在、アクセス不可の状態に移行しています。

30 分以内に問題が解決されず、Azure Key Vault のキー アクセスを手動で検証する必要がある場合のイベント

Azure SQL Database

EventName: MakeDatabaseInaccessible

状態: 成功

説明: データベースはアクセスできない状態であり、ユーザーは Azure Key Vault のエラーを解決し、再検証キーを使用して Azure Key Vault のキーへのアクセスを再確立する必要があります。

Azure SQL Managed Instance

EventName: MakeManagedDbInaccessible

状態: 成功

説明: マネージド サーバー {server_name} 上のデータベース {database_name} はアクセスできない状態であり、ユーザーは Azure Key Vault のキーへのアクセスを再確立する必要があります。

Azure Key Vault のキー アクセスの再検証が成功し、データベースがオンラインに戻ったときのイベント

Azure SQL Database

EventName: MakeDatabaseAccessible

状態: 開始済み

説明: Azure Key Vault のキーへのアクセスが再確立され、サーバー {server_name} 上のデータベース {database_name} にアクセスできるようにする操作を開始しました。

Azure SQL Managed Instance

イベント名: MakeManagedDatabaseAccessible

状態: 開始済み

説明: Azure Key Vault のキーへのアクセスが再確立され、マネージド サーバー {server_name} 上のデータベース {database_name} にアクセスできるようにする操作を開始しました。

データベースが正常にオンラインに戻ったときのイベント

Azure SQL Database

EventName: MakeDatabaseAccessible

状態: 成功

説明: Azure Key Vault のキーへのアクセスが再確立され、サーバー {server_name} 上のデータベース {database_name} がオンラインになりました。

Azure SQL Managed Instance

イベント名: MakeManagedDatabaseAccessible

状態: 成功

説明: Azure Key Vault のキーへのアクセスが再確立され、マネージド サーバー {server_name} 上のデータベース {database_name} がオンラインになりました。

Azure Key Vault のキー アクセスの再検証が失敗したときのイベント

Azure SQL Database

EventName: MakeDatabaseAccessible

状態: 失敗

説明: Azure Key Vault のキーへのアクセスが再確立され、サーバー {server_name} 上でデータベース {database_name} にアクセスできるようにする操作に失敗しました。

Azure SQL Managed Instance

イベント名: MakeManagedDatabaseAccessible

状態: 失敗

説明: Azure Key Vault のキーへのアクセスが再確立され、マネージド サーバー {server_name} 上でデータベース {database_name} にアクセスできるようにする操作に失敗しました。

関連するコンテンツ

  • Azure Resource Health について学習する。
  • 電子メール/SMS/プッシュ/音声、ロジック アプリ、Webhook、ITSM、Automation Runbook などの設定に基づいて、通知とアラートを受け取るアクション グループを設定します。