セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用する列でインデックスを作成して使用する
適用対象: 
SQL Server 2019 (15.x) 以降 - Windows のみ Azure SQL データベース
この記事では、セキュリティで保護されたエンクレーブが設定された Always Encrypted でエンクレーブ対応の列暗号化キーを使用して暗号化された列で、インデックスを作成して使用する方法について説明します。
セキュリティで保護されたエンクレーブが設定された Always Encrypted では、以下がサポートされています。
- 決定論的暗号化とエンクレーブ対応キーを使用して暗号化された列でのクラスター化インデックスと非クラスター化インデックス。
- そのようなインデックスは、暗号化テキストに基づいて並べ替えられます。 このようなインデックスに対する特別な考慮事項はありません。 決定論的な暗号化と、エンクレーブ対応ではないキーを使用して暗号化された列のインデックスと同じように、管理および使用できます (Always Encrypted と同様)。
- ランダム化された暗号化とエンクレーブ対応キーを使用して暗号化された列での非クラスター化インデックス。
- インデックス データ構造 (B ツリー) のキー値は暗号化され、プレーンテキスト値に基づいて並べ替えられます。 詳細については、「エンクレーブ対応列のインデックス」を参照してください。
Note
この記事の残りでは、ランダム化された暗号化とエンクレーブ対応キーを使用して暗号化された列での非クラスター化インデックスについて説明します。
ランダム化された暗号化とエンクレーブ対応の列暗号化キーを使用する列のインデックスには、プレーンテキストに基づいて並べ替えられている暗号化された (暗号化テキスト) データが含まれるため、SQL Server エンジンでは、次のようなインデックスの作成、更新、検索に関連するすべての操作に対して、エンクレーブを使用する必要があります。
- インデックスの作成または再構築。
- (インデックス付け/暗号化された列が含まれる) テーブルの行の挿入、更新、または削除。インデックスのインデックス キーの挿入または削除がトリガーされます。
- インデックスの整合性のチェックが含まれる
DBCCコマンドの実行。たとえば、DBCC CHECKDB (Transact-SQL) や DBCC CHECKTABLE (Transact-SQL)。 - SQL Server でインデックスへの変更を元に戻す必要がある場合の、データベースの復旧 (たとえば、SQL Server が失敗して再起動した後) (詳細については後述)。
上記のすべての操作では、インデックス付き列の列暗号化キーがエンクレーブに保持されている必要があります。 キーは、インデックス キーの暗号化解除に必要です。 一般に、エンクレーブでは、2 つの方法のいずれかで列暗号化キーを取得できます。
- クライアント アプリケーションから直接。
- 列暗号化キーのキャッシュから。
クライアントによって直接提供された列暗号化キーでインデックス付け操作を呼び出す
このインデックス付け操作の呼び出し方法が動作するためには、インデックスに対する操作をトリガーするクエリを発行するアプリケーションで (SQL Server Management Studio (SSMS) などのツールを含む)、次のことが必要です。
- データベース接続で Always Encrypted とエンクレーブ計算の両方が有効になっているデータベースに接続します。
- アプリケーションは、インデックス付き列の列暗号化キーを保護している列マスター キーにアクセスできる必要があります。
SQL Server エンジンで、アプリケーションのクエリが解析されて、クエリを実行するためには暗号化された列のインデックスを更新する必要があることがわかった場合、セキュリティで保護されたチャネル経由でエンクレーブに必要な列暗号化キーを解放するようにクライアント ドライバーに対して指示されます。 これは、インデックスを使用しない他のクエリの処理で、列暗号化キーをエンクレーブに提供するために使用されるのとまったく同じメカニズムです。 たとえば、インプレース暗号化や、パターン マッチングと範囲比較を使用するクエリなどです。
この方法は、Always Encrypted とエンクレーブ計算が有効になっているデータベースに既に接続されているアプリケーションに対し、暗号化された列でのインデックスの存在を透過的にするのに便利です。 アプリケーション接続では、クエリ処理にエンクレーブを使用できます。 列にインデックスを作成した後、アプリ内のドライバーでは、インデックス付け操作のためにエンクレーブに列暗号化キーが透過的に提供されます。 インデックスを作成すると、アプリケーションでエンクレーブに列暗号化キーを送信する必要があるクエリの数が増える場合があります。
この方法を利用するには、「セキュリティで保護されたエンクレーブを使用して Transact-SQL ステートメントを実行する」に示されているセキュリティで保護されたエンクレーブを使って、ステートメントを実行するための一般的なガイダンスに従います。
この方法の使用方法の詳細な手順については、「チュートリアル: ランダム化された暗号化を使用したエンクレーブ対応列でのインデックスの作成と使用」を参照してください。
キャッシュされた列暗号化キーを使用してインデックス付け操作を呼び出す
エンクレーブ計算を必要とするクエリの処理のため、クライアント アプリケーションからエンクレーブに列暗号化キーが送信されると、エンクレーブでは内部キャッシュに列暗号化キーがキャッシュされます。 このキャッシュはエンクレーブ内に存在し、外部からアクセスすることはできません。
同じユーザーまたは異なるユーザーによって使用される、同じクライアント アプリケーションまたは別のクライアント アプリケーションで、必要な列暗号化を直接提供せずに、インデックスに対する操作がトリガーされると、エンクレーブではキャッシュ内の列暗号化キーが検索されます。 その結果、クライアント アプリケーションでキーを提供しなくても、インデックスに対する操作は成功します。
このインデックス付け操作呼び出し方法が動作するためには、アプリケーションで接続の Always Encrypted を有効にしないでデータベースに接続する必要があり、エンクレーブの内部キャッシュで必要な列暗号化キーを使用できる必要があります。
この操作呼び出し方法は、インデックスに関連しない他の操作については、列暗号化キーが必要ないクエリに対してのみサポートされます。 たとえば、暗号化列を含むテーブルに INSERT ステートメントを使用して行を挿入するアプリケーションでは、暗号化列にインデックスがあるかどうかに関係なく、接続文字列で Always Encrypted を有効にしてデータベースに接続する必要があり、キーにアクセスできる必要があります。
この方法は次の場合に便利です。
ランダム化された暗号化を使用するエンクレーブ対応の列でのインデックスの存在を、プレーンテキストのキーとデータにアクセスできないアプリケーションとユーザーに対して透過的にする。
暗号化された列でインデックスを作成しても、既存のクエリが壊れないことを保証する。 キーにアクセスできる必要がない暗号化列が含まれるテーブルに対するクエリをアプリケーションで発行している場合、DBA がインデックスを作成した後も、アプリケーションはキーにアクセスできない状態で引き続き実行できます。 たとえば、暗号化された列が含まれる Employees テーブルに対して次のクエリを実行するアプリケーションについて考えてみます。 DBA は、暗号化された列にインデックスを作成していません。
DELETE FROM [dbo].[Employees] WHERE [EmployeeID] = 1; GOAlways Encrypted とエンクレーブ計算が有効になっていない接続でアプリケーションがクエリを送信した場合、クエリは成功します。 クエリでは、暗号化された列に対してどのような計算もトリガーされません。 DBA が暗号化された列でインデックスを作成した後は、クエリにより、インデックスからのインデックス キーの削除がトリガーされます。 この場合は、エンクレーブで列暗号化キーが必要です。 しかし、データ所有者がエンクレーブに対して列暗号化キーを提供している限り、アプリケーションでは同じ接続を通してこのクエリを引き続き実行できます。
インデックスを管理するときの役割の分離を実現します。それにより、DBA は、機密データにアクセスできなくても、暗号化列のインデックスを作成および変更できます。
ヒント
sp_enclave_send_keys (Transact-SQL) を使用すると、インデックスに使用されるすべてのエンクレーブ対応列暗号化キーをエンクレーブに簡単に送信し、キー キャッシュを設定することができます。
この方法の使用方法の詳細な手順については、「チュートリアル: ランダム化された暗号化を使用したエンクレーブ対応列でのインデックスの作成と使用」を参照してください。