セキュア エンクレーブを使用する Always Encrypted

  • [アーティクル]

適用対象: SQL Server 2019 (15.x) 以降 - Windows のみ Azure SQL Database

セキュア エンクレーブを使用する Always Encrypted では、インプレース暗号化と豊富な機密クエリを有効にすることで、Always Encrypted の機密コンピューティング機能が拡張されます。 セキュリティで保護されたエンクレーブを使用した Always Encrypted は、SQL Server 2019 (15.x) 以降と Azure SQL Database で使用できます。

2015 年と SQL Server 2016 (13.x) にAzure SQLデータベースで導入されたAlways Encrypted、機密データの機密性をマルウェアや高い特権を持つ権限のないユーザーから保護します。データベース管理者 (DBA)、コンピューター管理者、クラウド管理者、またはサーバー インスタンス、ハードウェアなどに正当なアクセス権を持っているが、一部またはすべてのユーザーにアクセスできないようにする必要がある 実際のデータの。

この記事で説明されている機能強化を設定しないと、Always Encrypted では、クライアント側でデータを暗号化し、データまたは対応する暗号化キーがデータベース エンジン内でプレーンテキストで表示 "されない" ようにすることで、データが保護されます。 その結果、データベース内の暗号化された列に対する機能が大幅に制限されます。 暗号化されたデータに対してデータベース エンジンで実行できる操作は、等価比較のみです (決定論的暗号化でのみ使用できます)。 暗号化操作 (最初のデータ暗号化や、キーのローテーション) や高度なクエリ (パターン マッチングなど) などの他のすべての操作は、データベース内ではサポートされていません。 ユーザーがクライアント側でこのような操作を実行するには、データベースの外部にデータを移動する必要があります。

"セキュリティで保護されたエンクレーブ" が設定された Always Encrypted では、サーバー側のセキュリティで保護されたエンクレーブ内でプレーンテキストに対する一部の計算を許可することにより、このような制限に対応しています。 セキュリティで保護されたエンクレーブは、データベース エンジン プロセス内のメモリの保護された領域です。 セキュリティで保護されたエンクレーブは、データベース エンジンの他の部分や、ホスティング マシン上の他のプロセスからは、不透明なボックスとして認識されます。 デバッガーを使用しても、外部からエンクレーブ内のデータやコードを表示する方法はありません。 これらの特徴により、セキュリティで保護されたエンクレーブは "高信頼実行環境" になり、データの機密性を損なうことなく、プレーンテキストで暗号化キーと機密データに安全にアクセスできます。

Always Encrypted は、次の図のようにセキュリティで保護されたエンクレーブを使用します。

データ フロー (data flow)

アプリケーションによって送信された Transact-SQL ステートメントを解析するときは、データベース エンジンにより、セキュリティで保護されたエンクレーブを使用する必要がある暗号化されたデータに対する操作がステートメントに含まれているかどうかが判断されます。 そのようなステートメントの場合:

  • クライアント ドライバーにより、操作に必要な列の暗号化キーが (セキュリティで保護されたチャネルを介して) セキュリティで保護されたエンクレーブに送信され、実行するステートメントが送信されます。

  • ステートメントを処理するときは、データベース エンジンにより、暗号化された列に対する暗号化操作または計算が、セキュリティで保護されたエンクレーブに委任されます。 必要に応じて、エンクレーブによりデータが解読され、プレーンテキストで計算が実行されます。

ステートメントの処理の間、データと列暗号化キーのどちらも、セキュリティで保護されたエンクレーブの外部にあるデータベース エンジンにおいて、プレーンテキストで公開されることはありません。

サポートされるクライアント ドライバー

セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用するには、アプリケーションでこの機能をサポートするクライアント ドライバーを使用する必要があります。 エンクレーブ計算とエンクレーブ構成証明を有効にするようにアプリケーションとクライアント ドライバーを構成します (後述の 「セキュリティで保護されたエンクレーブ構成証明 」セクションを参照してください)。 サポートされているクライアント ドライバーの一覧などの詳細については、「Always Encrypted を使用したアプリケーションの開発」を参照してください。

サポートされているエンクレーブ テクノロジ

Always Encryptedでは、次のエンクレーブ テクノロジ (またはエンクレーブの種類) がサポートされています。

データベースで使用できるエンクレーブの種類は、データベースをホストする SQL 製品 (Azure SQL Database と SQL Server) と (Azure SQL Database の場合) データベースの構成によって異なります。

  • SQL Server 2019 (15.x) 以降では、Always Encryptedは VBS エンクレーブをサポートしています。 (Intel SGX エンクレーブはサポートされていません)。

  • Azure SQL Database では、データベースが実行するように構成されているハードウェアに応じて、Intel SGX エンクレーブまたは VBS エンクレーブをデータベースで使用できます。

    • DC シリーズハードウェア構成 (仮想コア購入モデルで使用可能) を使用するデータベースでは、Intel SGX エンクレーブが使用されます。
    • 仮想コア購入モデルで DC シリーズ以外の構成を使用するデータベースと 、DTU 購入モデル を使用するデータベースを VBS エンクレーブを使用するように構成できます。

    重要

    Azure SQL Database の VBS エンクレーブは現在プレビュー段階です。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用されるその他の法律条項については、「Microsoft Azure プレビューの追加使用条件」に記載されています。

    Note

    VBS エンクレーブは、現在、オーストラリア中部、オーストラリア中部 2、韓国中部、韓国南部、アラブ首長国連邦中部、Jio India Central、Jio India West を除く、すべてのAzure SQL データベース リージョンで使用できます。

各エンクレーブの種類によって提供されるレベル保護の重要な情報については、「 セキュリティに関する考慮事項 」セクションを参照してください。

セキュリティで保護されたエンクレーブの構成証明

エンクレーブ構成証明は、悪意のある管理者によるエンクレーブ コードまたはその環境の改ざんを伴う攻撃を検出するのに役立つ多層防御メカニズムです。

エンクレーブ構成証明を使用すると、クライアント アプリケーションは、機密データの処理にエンクレーブを使用する前に、アプリケーションが接続されているデータベースのセキュリティで保護されたエンクレーブとの信頼を確立できます。 構成証明ワークフローでは、エンクレーブが正規の VBS または Intel SGX エンクレーブであり、その内部で実行されているコードは、Always Encrypted用の本物の Microsoft 署名エンクレーブ ライブラリであることを確認します。 構成証明中に、アプリケーション内のクライアント ドライバーとデータベース エンジンの両方が、クライアント指定のエンドポイントを使用して外部構成証明サービスと通信します。

Always Encryptedは、次の 2 つの構成証明サービスのいずれかを使用できます。

アプリケーションのセキュリティで保護されたエンクレーブを使用してAlways Encryptedを有効にするには、アプリケーションのクライアント ドライバーの構成で構成証明プロトコルを設定する必要があります。 構成証明プロトコルの値は、1) クライアント アプリが構成証明を使用するかどうかを決定し、使用する場合は 2) 構成証明サービスの種類を指定します。 次の表は、有効な SQL 製品とエンクレーブ型の組み合わせでサポートされている構成証明プロトコルを示しています。

ホスティング製品 エンクレーブの種類 サポートされている構成証明プロトコル
SQL Server 2019 (15.x) 以降 VBS エンクレーブ HGS、構成証明なし
Azure SQL データベース SGX エンクレーブ (DC シリーズ データベース) Microsoft Azure Attestation
Azure SQL データベース VBS エンクレーブ 構成証明なし

いくつかの重要なポイントを呼び出す必要があります。

  • SQL Server 2019 (15.x) 以降で VBS エンクレーブを構成証明するには、HGS が必要です。 構成証明なしで VBS エンクレーブを使用することもできます (最新のクライアント ドライバーが必要です)。
  • Azure SQL Database の Intel SGX エンクレーブ (DC シリーズ データベース内) では、構成証明は必須であり、Microsoft Azure Attestationが必要です。
  • Azure SQL Database の VBS エンクレーブ (プレビュー段階) では、現在構成証明はサポートされていません。

詳細については、次を参照してください。

用語

エンクレーブ対応キー

セキュリティで保護されたエンクレーブが設定された Always Encrypted では、エンクレーブ対応キーの概念が導入されました。

  • エンクレーブ対応の列マスター キー - データベース内の列マスター キー メタデータ オブジェクトで ENCLAVE_COMPUTATIONS プロパティが指定されている列マスター キー。 列マスター キー メタデータ オブジェクトには、メタデータ プロパティの有効な署名も含める必要があります。 詳細については、「CREATE COLUMN MASTER KEY (Transact-SQL)」を参照してください
  • エンクレーブ対応列暗号化キー: エンクレーブ対応列マスター キーで暗号化された列暗号化キーです。 セキュリティで保護されたエンクレーブ内での計算に使用できるのは、エンクレーブ対応の列暗号化キーだけです。

詳細については、「セキュリティで保護されたエンクレーブが設定された Always Encrypted のキーの管理」を参照してください。

エンクレーブ対応列

エンクレーブ対応列は、エンクレーブ対応列暗号化キーを使用して暗号化されたデータベース列です。

エンクレーブ対応列のための機密コンピューティング機能

セキュリティで保護されたエンクレーブが設定された Always Encrypted の 2 つの主な利点は、インプレース暗号化と豊富な機密クエリです。

インプレース暗号化

インプレース暗号化を使用すると、データをデータベースの外部に移動することなく、セキュリティで保護されたエンクレーブ内でデータベース列の暗号化操作を行うことができます。 インプレース暗号化により、暗号化操作のパフォーマンスと信頼性が向上します。 インプレース暗号化は、ALTER TABLE (Transact-SQL) ステートメントを使用して実行できます。

インプレースでサポートされる暗号化操作は次のとおりです。

  • エンクレーブ対応の列暗号化キーによるプレーンテキストの列の暗号化。
  • 次のことを目的とする、暗号化されたエンクレーブ対応列の再暗号化:
    • 列暗号化キーのローテーション - 新しいエンクレーブ対応列暗号化キーを使用して列を再暗号化します。
    • エンクレーブ対応列の暗号化の種類の変更 (たとえば、決定論的からランダム化に)。
  • エンクレーブ対応列に格納されているデータの解読 (列からプレーンテキスト列への変換)。

暗号化操作に含まれる列暗号化キーがエンクレーブ対応である限り、決定論的とランダム化の両方の暗号化で、インプレース暗号化を使用できます。

機密クエリ

注意

SQL Server 2022 (16.x) では、暗号化された列に対する JOIN、GROUP BY、ORDER BY 操作を使用した機密クエリのサポートが追加されました。

機密クエリは、セキュリティで保護されたエンクレーブ内で実行されるエンクレーブ対応列の操作を伴う DML クエリです。

セキュリティで保護されたエンクレーブでサポートされる操作は次のとおりです。

操作 Azure SQL データベース SQL Server 2022 (16.x) SQL Server 2019 (15.x)
比較演算子 サポートされています サポートされています サポートされています
BETWEEN (Transact-SQL) サポートされています サポートされています サポートされています
IN (Transact-SQL) サポートされています サポートされています サポートされています
LIKE (Transact-SQL) サポートされています サポートされています サポートされています
DISTINCT サポートされています サポートされています サポートされています
結合 サポートされています サポートされています 入れ子になったループ結合のみがサポートされます
SELECT - ORDER BY 句 (Transact-SQL) サポートされています サポートされています サポートされていません
SELECT - GROUP BY- Transact-SQL サポートされています サポートされています サポートされていません

注意

セキュリティで保護されたエンクレーブ内の上記の操作には、ランダム化された暗号化が必要です。 決定論的な暗号化はサポートされていません。 等値比較は、決定論的暗号化を使用して列で使用できる操作のままです。

データベースの互換性レベルは、SQL Server 2022 (160) 以上に設定する必要があります。

Azure SQL Database および SQL Server 2022 (16.x) では、文字列列 (char、) でエンクレーブを使用する機密クエリでは、nchar列にバイナリ コード ポイント (_BIN2) 照合順序または UTF-8 照合順序が使用されている必要があります。 SQL Server 2019 (15.x) では、a_BIN2照合順序が必要です。

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

エンクレーブ対応列でのインデックス

ランダム化された暗号化を使用してエンクレーブ対応列で非クラスター化インデックスを作成することにより、セキュリティで保護されたエンクレーブを使用する機密 DML クエリの実行を高速化できます。

ランダム化された暗号化を使用して暗号化された列のインデックスで、機密データが漏えいしないようにするため、インデックス データ構造 (B ツリー) 内のキーの値は、プレーンテキストの値に基づいて暗号化され、並べ替えられます。 プレーンテキスト値による並べ替えは、エンクレーブ内でのクエリの処理にも役立ちます。 データベース エンジン内のクエリ Executor では、エンクレーブ内での計算のために暗号化された列のインデックスが使われるときに、インデックスを検索して列に格納されている特定の値が探索されます。 各検索には、複数の比較が含まれる場合があります。 クエリ Executor では各比較がエンクレーブにデリゲートされ、エンクレーブでは列に格納されている値と比較対象の暗号化されたインデックス キーの値が復号化されて、プレーンテキストで比較が実行された後、比較の結果が Executor に返されます。

ランダム化された暗号化を使用し、エンクレーブ対応ではない列でのインデックスの作成は、やはりサポートされていません。

決定論的な暗号化を使用する列でのインデックスは、列がエンクレーブ対応かどうかに関係なく、(プレーンテキストではなく) 暗号化テキストに基づいて並べ替えられます。

詳細については、「セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用する列でインデックスを作成して使用する」を参照してください。 データベース エンジンでのインデックス作成のしくみに関する一般的な情報については、「クラスター化インデックスと非クラスター化インデックスの概念」の記事を参照してください。

データベースの回復

SQL Server のインスタンスで障害が発生した場合、そのデータベースは、完了しなかったトランザクションによる変更がデータ ファイルに含まれ状態のままになる可能性があります。 インスタンスが起動されると、データベース復旧と呼ばれるプロセスが実行されます。このプロセスでは、トランザクション ログで見つかったすべての未完了のトランザクションがロールバックされて、データベースの整合性が保持されます。 未完了のトランザクションによってインデックスの変更が行われた場合、それらの変更も元に戻す必要があります。 たとえば、インデックス内の一部のキー値は、削除するか、再挿入する必要があります。

重要

ランダム化された暗号化を使用して暗号化されているエンクレーブ対応の列で最初のインデックスを作成する前に、データベースに対して高速データベース復旧 (ADR) を有効にすることを強くお勧めします。 ADR は Azure SQL Database では既定で有効になっていますが、SQL Server 2019 (15.x) 以降では有効になっていません。

従来のデータベース復旧プロセス (ARIES 復旧モデルに従うもの) では、インデックスに対する変更を元に戻すには、アプリケーションが列の列暗号化キーをエンクレーブに提供するまで SQL Server は待機する必要があり、長くかかることがあります。 高速データベース復旧 (ADR) を使用すると、エンクレーブ内のキャッシュで列暗号化キーを使用できないために遅延する必要がある元に戻す操作の数が、劇的に減少します。 その結果、新しいトランザクションがブロックされる可能性が最小限になり、データベースの可用性が大幅に向上します。 ADR を有効にしても、SQL Server ではやはり古いデータ バージョンのクリーンアップを完了するために列暗号化キーが必要になる場合がありますが、データベースまたはユーザーのトランザクションの可用性に影響を与えないバックグラウンド タスクとして行われます。 列暗号化キーがないためにクリーンアップ操作が失敗したことを示すエラー メッセージが、エラー ログに記録されることがあります。

セキュリティに関する考慮事項

セキュリティで保護されたエンクレーブが設定された Always Encrypted に対しては、次のセキュリティに関する考慮事項が適用されます。

  • VBS エンクレーブは、VM 内の攻撃からデータを保護するのに役立ちます。 ただし、ホストから送信された特権システム アカウントを使用した攻撃からの保護は提供されません。 Intel SGX エンクレーブは、ゲスト OS とホスト OS の両方から発生した攻撃からデータを保護します。
  • エンクレーブ構成証明の使用は、環境で使用できる場合や、データベースをホストしているマシンへの OS レベルの管理者アクセス権を持つユーザーによる攻撃からデータを保護することを懸念している場合に推奨されます。 構成証明を使用する場合は、構成証明サービスとその構成が信頼された管理者によって管理されていることを確認する必要があります。 また、サポートされている構成証明サービスはどちらも異なるポリシーと構成証明モードを提供します。その一部はエンクレーブとその環境の最小限の検証を実行し、テストと開発のために設計されています。 ご利用の構成証明サービスに固有のガイドラインに厳密に従って、運用環境の配置には必ず推奨される構成とポリシーを使うようにしてください。
  • エンクレーブ対応の列暗号化キーでランダム化された暗号化を使用して列を暗号化すると、列による範囲比較のサポートのため、列に格納されたデータの順序がリークする可能性があります。 たとえば、従業員の給与が含まれる暗号化された列にインデックスがある場合、悪意のある DBA はインデックスをスキャンして暗号化された給与の最大値を検索し、給与が最高の個人を特定できます (ユーザーの名前は暗号化されていないものとします)。
  • Always Encrypted を使用して、DBA による不正アクセスから機微なデータを保護する場合は、列マスター キーや列暗号化キーを DBA と共有しないでください。 DBA は、キーに直接アクセスできなくても、エンクレーブ内の列暗号化キーのキャッシュを使用して、暗号化された列のインデックスを管理できます。

事業継続、ディザスター リカバリー、データ移行に関する考慮事項

セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用するデータベース用に高可用性またはディザスター リカバリー ソリューションを構成するときは、すべてのデータベース レプリカでセキュリティで保護されたエンクレーブを使用できることを確認します。 プライマリ レプリカにはエンクレーブを使用できても、セカンダリ レプリカには使用できない場合、セキュリティで保護されたエンクレーブが設定された Always Encrypted の機能を使用しようとするすべてのステートメントは、フェールオーバー後に失敗します。

セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用してデータベースをコピーまたは移行するときは、ターゲット環境でエンクレーブが常にサポートされていることを確認します。 そうでない場合、エンクレーブを使用するステートメントは、コピーや移行されたデータベースで機能しません。

留意する必要のある具体的な考慮事項をいくつか示します。

  • SQL Server

    • Always On 可用性グループを構成するときは、可用性グループ内のデータベースがホストされてい各 SQL Server インスタンスで、セキュリティで保護されたエンクレーブが設定された Always Encrypted がサポートされ、エンクレーブと構成証明が構成されていることを確認します。
    • エンクレーブが構成されていない SQL Server インスタンスで、セキュリティで保護されたエンクレーブが設定された Always Encrypted の機能を使用するデータベースのバックアップ ファイルから復元すると、復元操作は成功し、エンクレーブに依存しないすべての機能が使用可能になります。 しかし、エンクレーブ機能を使用する後続のステートメントは失敗し、ランダム化された暗号化を使用するエンクレーブ対応列のインデックスは無効になります。 エンクレーブが構成されていないインスタンスで、セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用するデータベースをアタッチしたときも、同じようになります。
    • ランダム化された暗号化を使用するエンクレーブ対応列のインデックスがデータベースに含まれる場合は、データベースのバックアップを作成する前に、データベースで高速データベース復旧 (ADR) を有効にします。 ADR では、データベースを復元した後すぐに、インデックスも含めて、データベースを使用できることが保証されます。 詳しくは、「データベース復旧」をご覧ください。

  • Azure SQL Database

    • アクティブ geo レプリケーションを構成するとき、セキュリティで保護されたエンクレーブがプライマリ データベースでサポートされている場合は、セカンダリ データベースでもそうであることを確認します。

SQL Server と Azure SQL Database の両方で、bacpac ファイルを使用してデータベースを移行するときは、bacpac ファイルを作成する前に、ランダム化された暗号化を使用するエンクレーブ対応列のすべてのインデックスを削除する必要があります。

既知の制限事項

「エンクレーブ対応列のための機密コンピューティング機能」で説明したように、セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用すると、インプレース暗号化と、インデックスを使用した豊富な機密クエリがサポートされることで、Always Encrypted のいくつかの制限が対処されます。

「制限事項」に記載されているAlways Encryptedに関するその他のすべての制限は、セキュリティで保護されたエンクレーブを持つAlways Encryptedにも適用されます。

次の制限事項は、セキュリティで保護されたエンクレーブが設定された Always Encrypted に固有のものです。

  • ランダム化された暗号化を使用するエンクレーブ対応の列では、クラスター化インデックスを作成できません。
  • ランダム化された暗号化を使用するエンクレーブ対応列は、主キー列にすることはできません。また、外部キー制約または一意キー制約では参照できません。
  • SQL Server 2019 (15.x) では (この制限は、Azure SQL Database または SQL Server 2022 (16.x) には適用されません)、ランダム化された暗号化を使用したエンクレーブ対応列では、入れ子になったループ結合 (インデックスを使用する場合) のみがサポートされます。 異なる製品間のその他の違いについては、「機密クエリ」を参照してください。
  • インプレース暗号化操作を列メタデータの他の変更と組み合わせることはできません。ただし、同じコード ページ内の照合順序の変更と null 値の許容を除きます。 たとえば、1 つの ALTER TABLE/ALTER COLUMN Transact-SQL ステートメントで列を暗号化、再暗号化、または暗号化解除し、さらに列のデータ型を変更することはできません。 2 つの異なるステートメントを使用します。
  • インメモリ テーブルの列にエンクレーブ対応キーを使用することは、サポートされていません。
  • 計算列を定義する式では、ランダム化された暗号化を使用してエンクレーブ対応列の計算を実行することはできません (計算が「機密クエリ」に一覧表示されているサポート対象の操作に含まれる場合でも)。
  • ランダム化された暗号化を使用するエンクレーブ対応列では、LIKE 演算子のパラメーターでのエスケープ文字はサポートされていません。
  • (暗号化の後でラージ オブジェクトになる) 次のデータ型のいずれかを使用するクエリ パラメーターを持つ LIKE 演算子または比較演算子を含むクエリでは、インデックスは無視され、テーブル スキャンが実行されます。
    • nchar[n]、nvarchar[n] (n が 3967 より大きい場合)。
    • char[n]、varchar[n]、binary[n]、varbinary[n] (n が 7935 より大きい場合)。
  • ツールの制限事項:
    • エンクレーブ対応列マスター キーを格納するためにサポートされるキー ストアは、Windows 証明書ストアと Azure Key Vault のみです。
    • を使用して ALTER TABLE/ALTER COLUMNインプレース暗号化操作をトリガーするには、SSMS または Azure Data Studio のクエリ ウィンドウを使用してステートメントを発行する必要があります。または、ステートメントを発行する独自のプログラムを作成できます。 現在、Set-SqlColumnEncryptionsqlServer PowerShell モジュールのコマンドレットと SQL Server Management Studio のAlways Encrypted ウィザードでは、インプレース暗号化はサポートされていません。 操作に使用される列暗号化キーがエンクレーブ対応の場合でも、暗号化操作のためにデータベースからデータを移動します。

次のステップ

関連項目