次の方法で共有

セキュリティで保護されたエンクレーブが設定された Always Encrypted の一般的な問題をトラブルシューティングする

  • [アーティクル]

適用対象: SQL Server 2019 (15.x) 以降 - Windows のみ Azure SQL データベース

この記事では、セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用して Transact-SQL (TSQL) ステートメントを実行するときに、発生する可能性のある一般的な問題を特定して解決する方法について説明します。

セキュリティで保護されたエンクレーブを使用してクエリを実行する方法の詳細については、「セキュリティで保護されたエンクレーブを使用して Transact-SQL ステートメントを実行する」を参照してください。

データベース接続エラー

セキュリティで保護されたエンクレーブを使用してステートメントを実行するには、Always Encrypted を有効にし、データベース接続の構成証明プロトコルと、該当する場合は構成証明 URL を指定する必要があります。詳細については、「セキュリティで保護されたエンクレーブを使用してステートメントを実行するための前提条件」を参照してください。 ただし、構成証明 URL を指定しても、Azure SQL Database のデータベースまたはターゲットである SQL Server インスタンスがセキュリティで保護されたエンクレーブをサポートしていない場合、または正しく構成されていない場合、接続は失敗します。

Microsoft Azure Attestation 使用時の構成証明エラー

Note

このセクションは、Intel SGX エンクレーブがある Azure SQL Database にのみ適用されます。

クライアント ドライバーから Azure SQL 論理サーバーに実行対象の T-SQL ステートメントが送信される前に、次のエンクレーブ構成証明ワークフローがドライバーによって Microsoft Azure Attestation を使用してトリガーされます。

  1. クライアント ドライバーから Azure SQL 論理サーバーに、データベース接続で指定された構成証明 URL が渡されます。
  2. エンクレーブ、そのホスティング環境、およびエンクレーブ内で実行されているコードに関する証拠が Azure SQL 論理サーバーによって収集されます。 次に、サーバーから構成証明 URL で参照されている構成証明プロバイダーに、構成証明要求が送信されます。
  3. 構成証明プロバイダーによって、構成されたポリシーに照らした証拠の検証と、Azure SQL 論理サーバーに対する構成証明トークンの発行が行われます。 構成証明プロバイダーによって、構成証明トークンが秘密キーを使用して署名されます。
  4. Azure SQL 論理サーバーからクライアント ドライバーに構成証明トークンが送信されます。
  5. クライアントは、指定された構成証明 URL で構成証明プロバイダーに接続して公開キーを取得し、構成証明トークン内の署名を検証します。

構成の誤りにより、上記のワークフローのさまざまな手順でエラーが発生する可能性があります。 一般的な構成証明エラー、その根本原因、および推奨されるトラブルシューティング手順は次のとおりです。

  • Azure SQL 論理サーバーから、構成証明 URL で指定された Azure Attestation (上記のワークフローの手順 2) の構成証明プロバイダーに接続できません。 次の原因が含まれます。
    • 構成証明 URL が正しくないか、不完全である。 詳細については、「構成証明ポリシーの構成証明 URL を確認する」を参照してください。
    • 構成証明プロバイダーが誤って削除された。
    • 構成証明プロバイダーに対してファイアウォールが構成されたが、そこで Microsoft サービスへのアクセスが許可されていない。
    • 間欠的なネットワーク エラーのために、構成証明プロバイダーを使用できない。
  • Azure SQL 論理サーバーに、構成証明プロバイダーに構成証明要求を送信する権限がありません。 構成証明プロバイダーの管理者によって、データベース サーバーが構成証明リーダー ロールに追加されていることを確認します。
  • 構成証明ポリシーの検証が失敗する (上記のワークフローの手順 3)。
    • 正しくない構成証明ポリシーが根本原因と考えられます。 Microsoft 推奨のポリシーを使用していることを確認してください。 詳細については、「構成証明プロバイダーの作成と構成」を参照してください。
    • また、セキュリティ違反によってサーバー側のエンクレーブが侵害された結果として、ポリシーの検証が失敗する場合もあります。
  • クライアント アプリケーションから構成証明プロバイダーに接続できず、(手順 5 で) 公開署名キーを取得できない。 次の原因が含まれます。
    • アプリケーションと構成証明プロバイダーの間にファイアウォールを構成すると、接続がブロックされる可能性があります。 ブロックされた接続のトラブルシューティングを行うには、構成証明プロバイダーの OpenId エンドポイントに接続できることを確認します。 たとえば、アプリケーションをホストしているコンピューターから OpenID エンドポイントに Web ブラウザーを使用して接続できるかどうかを確認します。 詳細については、「Metadata Configuration - Get」を参照してください。

ホスト ガーディアン サービス使用時の構成証明エラー

Note

このセクションは、SQL Server 2019 (15.x) 以降にのみ適用されます。

クライアント ドライバーは、実行のために T-SQL ステートメントを SQL Server に送信する前に、ホスト ガーディアン サービス (HGS) を使用して次のエンクレーブ構成証明ワークフローをトリガーします。

  1. クライアント ドライバーによって SQL Server t が呼び出されて、構成証明が開始されます。
  2. エンクレーブ、そのホスティング環境、およびエンクレーブ内で実行されているコードに関する証拠が SQL Server によって収集されます。 SQL Server は、SQL Server をホストしているマシンが登録されている HGS インスタンスから正常性証明書を要求します。 詳細については、「ホスト ガーディアン サービスにコンピューターを登録する」を参照してください。
  3. HGS によって証拠が検証され、SQL Server. に対して正常性証明書が発行されます。 HGS により、秘密キーを使用して正常性証明書が署名されます。
  4. SQL Server からクライアント ドライバーに正常性証明書が送信されます。
  5. HGS 公開キーを取得するために、データベース接続用に指定された構成証明 URL でクライアント ドライバーから HGS への接続が行われます。 正常性証明書の署名がクライアント ドライバーによって検証されます。

構成の誤りにより、上記のワークフローのさまざまな手順でエラーが発生する可能性があります。 一般的ないくつかの構成証明エラー、その根本原因、および推奨されるトラブルシューティング手順を次に示します。

  • 間欠的なネットワーク エラーのために、SQL Server から HGS に接続できない (上記のワークフローの手順 2)。 接続の問題をトラブルシューティングするには、SQL Server コンピューターの管理者が、そのコンピューターから HGS コンピューターに接続できることを確認する必要があります。
  • 手順 3 の検証が失敗する。 検証の問題をトラブルシューティングするには:
    • SQL Server コンピューターの管理者がクライアント アプリケーション管理者と協力して、クライアント側の構成証明 URL で参照されているインスタンスと同じ HGS インスタンスに SQL Server コンピューターが登録されていることを確認する必要があります。
    • SQL Server コンピュータの管理者は、「Step 5: Confirm the host can attest successfully」の手順に従って、SQL Server コンピュータが正常に証明できることを確認する必要があります。
  • クライアント アプリケーションから HGS に接続して公開署名キーを取得することができない (手順 5)。 次のような原因が考えられます:
    • アプリケーションと構成証明プロバイダーの間にある、いずれかのファイアウォールの構成によって、接続がブロックされる可能性があります。 アプリをホストしているコンピューターから HGS コンピューターに接続できることを確認します。

インプレース暗号化のエラー

このセクションでは、インプレース暗号化のために ALTER TABLE/ALTER COLUMN を使用する場合に、(前のセクションで説明した構成証明のエラーに加えて) 発生する可能性のある一般的なエラーを示します。 詳細については、「セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用して列の暗号化をインプレースで構成する」を参照してください。

  • データの暗号化、暗号化の解除、または再暗号化に使用しようとしている列暗号化キーが、エンクレーブに対応していない。 インプレース暗号化の前提条件の詳細については、「前提条件」を参照してください。 エンクレーブ対応キーをプロビジョニングする方法の詳細については、「エンクレーブ対応キーをプロビジョニングする」を参照してください。
  • データベース接続に対して Always Encrypted とエンクレーブ計算を有効にしていません。 「セキュリティで保護されたエンクレーブを使用してステートメントを実行するための前提条件」を参照してください。
  • ALTER TABLE/ALTER COLUMN ステートメントで暗号化操作をトリガーし、列のデータ型を変更するか、現在の照合順序コード ページとは異なるコード ページを使用して照合順序を設定しています。 暗号化操作をデータ型または照合順序ページの変更と組み合わせることはできません。 この問題を解決するには、個別のステートメントを使用します (データ型または照合順序コード ページを変更するために 1 つのステートメント、およびインプレース暗号化のために別のステートメント)。

セキュリティで保護されたエンクレーブを使用した機密 DML クエリ実行時のエラー

このセクションでは、セキュリティで保護されたエンクレーブを使用して機密 DML クエリを実行するときに、(前のセクションで説明した構成証明のエラーに加えて) 発生する可能性のある一般的なエラーを示します。

次のステップ

関連項目