SQL Server ビッグ データ クラスターのキー バージョン

適用対象: SQL Server 2019 (15.x)

重要

Microsoft SQL Server 2019 ビッグ データ クラスターのアドオンは廃止されます。 SQL Server 2019 ビッグ データ クラスターのサポートは、2025 年 2 月 28 日に終了します。 ソフトウェア アシュアランス付きの SQL Server 2019 を使用する既存の全ユーザーはプラットフォームで完全にサポートされ、ソフトウェアはその時点まで SQL Server の累積更新プログラムによって引き続きメンテナンスされます。 詳細については、お知らせのブログ記事と「Microsoft SQL Server プラットフォームのビッグ データ オプション」を参照してください。

この記事では、HDFS および SQL Server キーのキー管理とキー ローテーションのための SQL Server ビッグ データ クラスターでのキー バージョンの使用方法について詳しく説明します。 この記事には、バージョンにカスタマーのキーを組み込む方法に関する詳細が含まれています。

SQL Server ビッグ データ クラスターのセキュリティ保護に関する一般的な情報については、「SQL Server ビッグ データ クラスターのセキュリティの概念」を参照してください。

保存時の暗号化機能の構成と使用については、次のガイドを参照してください。

• 保存時の暗号化の概念と構成ガイド
• SQL Server ビッグ データ クラスター HDFS 暗号化ゾーンの使用ガイド
• SQL Server ビッグ データ クラスターの保存時の Transparent Data Encryption (TDE) の使用ガイド

HDFS キー

HDFS で保存時の暗号化を使用する場合、次の概念が関係します。

• 暗号化ゾーン (EZ): 暗号化ゾーンは、キーに関連付けられている HDFS 内のフォルダーです。 このフォルダー内のすべてのファイルが暗号化されます。 SQL Server ビッグ データ クラスターの既定のプロビジョニング済み EZ は、"securelake" と呼ばれます。
• 暗号化ゾーン キー (EZ キー): 名前付き対称キー。 SQL Server ビッグ データ クラスターでプロビジョニングされた既定のシステム マネージドの場合は、"securelakekey" となります。 暗号化ゾーン キーは、Hadoop KMS (キー マネージメント サーバー) を使用して管理されます。これは、SQL Server ビッグ データ クラスターの名前ノード ポッド内で実行されます。 EZ キーは、controldb に格納されているメイン暗号化キーによってさらに保護されます (以下のセクションで説明します)。 EZ キーは、メイン暗号化キーの公開部分をフェッチすることによって Hadoop KMS で暗号化され、暗号化解除要求はコントロール プレーンに送信されます。
• 暗号化されたデータ暗号化キー: 暗号化ゾーン内のすべてのファイルは、そのファイルに対して生成されるデータ暗号化キー (DEK) によって暗号化されます。 DEK が作成されると、データと共に保持されます。 DEK を保持するために、まず暗号化ゾーン キーによって暗号化され、その後、データと共に保持されます。 DEK はファイルごとにランダムに生成され、対称 DEK の強度は EZ キーの強度と同じになります。

次の図は、DEK によってファイルがどのように保護されているか、および DEK が EZ キー securelakekey によってどのように保護されているかを示しています。

SQL Server キー

システム マネージドのメイン暗号化キーと HDFS EZ キーは、controldb 内に格納されます。これには、controldb-<#> という名前が付けられます (例: controldb-0)。 詳細については、「ビッグ データ クラスターに展開されるリソース」を参照してください。

SQL Server データベースは、データベース暗号化キー (DEK) とも呼ばれる対称キーによって暗号化されます。 DEK は、暗号化された形式でデータベースと共に保持されます。 DEK 保護機能は、''証明書'' または ''非対称キー'' にすることができます。 DEK 保護機能を変更するには、ALTER DATABASE ENCRYPTION KEY ステートメントを使用します。 SQL Server の非対称キーには、コントロール プレーン内のキーへの URL リンクを含むメタデータがあります。 そのため、データベース暗号化キー (DEK) の暗号化とその解除のすべての操作は、コントローラー内で行われます。 SQL Server には公開キーが格納されますが、それは非対称キーを特定するためだけのものであり、公開キーを使用して暗号化されることはありません。

SQL Server ビッグ データ クラスターのメイン暗号化キー

SQL Server ビッグ データ クラスター コントロール プレーンで、暗号化ゾーン キーを保護する場合や、SQL Server で非対称キーをプロビジョニングする場合、メイン暗号化キーの概念が存在します。 2 つのメイン暗号化キーがあり、1 つは SQL Server 用で、もう 1 つは HDFS 用です。 この概念により、SQL Server ビッグ データ クラスター コントロール プレーンでは、メイン暗号化キーをクラスターの外部にも配置できるようになります。 メイン暗号化キーのプロパティは次のとおりです。

1. メイン暗号化キーは非対称の RSA キーです。
2. メイン暗号化キーは、SQL Server マスター インスタンス用に 1 つと、HDFS 用にもう 1 つ作成されます。
3. メイン暗号化キーに対応する公開キーは常に、コントローラー データベース (controldb) に格納されます。 秘密キーは、システム マネージドのメイン暗号化キーのコントローラー データベースに格納されます。 ハードウェア セキュリティ モジュール (HSM) または他の外部プロバイダーからの暗号化キーの場合、秘密キーはコントローラー データベース内に格納されません (外部キーのアプリケーションによって秘密キーが提供される場合を除く)。 しかし、秘密キーは controldb 内で必要とされず、SQL Server ビッグ データ クラスターには秘密キー マテリアルは必要ありません。
4. メイン暗号化キーの公開キーを使用した暗号化操作は、コントローラー自体の内部で実行できます。また、Hadoop KMS によってローカルで暗号化を実行できるように、コントローラーで Hadoop KMS に公開キーを配布することもできます。 暗号化解除の操作は、HSM などの外部キー プロバイダーによって処理されることが想定されます。 この設計では、非対称キーの機密性の高い部分を、クラスター外部に保持し、カスタマーの保護対象にしておくことができます。 これにより、カスタマー構成キーの SQL Server ビッグ データ クラスター エコシステムで、すべてのデータの暗号化を解除するための暗号化のルートを利用できなくなります。

異なるキーのストレージ保護

HDFS ファイルおよび SQL Server 用の DEK は、DEK で保護されるデータと共に格納されます。 DEK は、HDFS EZ キーまたは SQL Server 内の非対称キーによってそれぞれ保護されます。

メタデータを持つ SQL Server 内の非対称キーには、コントロール プレーンのキーの URL が含まれます。 SQL Server には、非対称キーの公開キーのみが格納され、コントロール プレーンのキーとの関連付けが行われます。

controldb 内のキーのストレージは、controldb の列暗号化キーによって保護されます。 controldb にはクラスターに関する機密情報が格納されます。そのすべての機密情報は、controldb 内の SQL Server の列暗号化キーによって保護され、Kubernetes シークレットに格納されているパスワードによってさらに保護されます。 詳細については、Kubernetes のシークレットに関するドキュメントを参照してください。

保護の概要を下図に示します。 まず、HDFS EZ キーのストレージ保護を示します。

メイン暗号化キーのストレージ保護は次のようになります。

キーの交換

HDFS 暗号化ゾーンのキー

SQL Server ビッグ データ クラスターが Active Directory と共にデプロイされると、HDFS は、securelakekey で保護された securelake という既定の暗号化ゾーンを使用してプロビジョニングされます。 例では既定値を使用しますが、新しいゾーンとキーは azdata を使用してプロビジョニングできます。 securelakekey は、コントロール プレーンに格納されている HDFS のメイン暗号化キーによって保護されます。 SQL 2019 CU9 以降では、HDFS の EZ キーのローテーションに azdata を使用できます。 EZ キーのローテーションによって、新しいキー マテリアルが "securelakekey" と同じ名前で生成されますが、キー マテリアルを指す新しいバージョンのキーが使用されます。 HDFS の新しい暗号化操作 (ファイルの書き込みなど) の場合、EZ では常に EZ に関連付けられている最新バージョンのキーが使用されます。 古いバージョンのキーによって保護されている EZ 内のファイルの場合は、すべてのファイルを最新バージョンの EZ キーで保護できるように、azdata bdc hdfs encryption-zone reencrypt コマンドを使用できます。

/securelake に配置された file2 というファイルについて考えてみます。 以下は保護チェーンを示しています。

securelakekey は、azdata bdc hdfs key roll -n securelakekey を使用して新しいバージョンにローテーションできます。 このローテーションでは、ファイルを保護する DEK の再暗号化は行われません。 Hadoop キーのローテーションにより、新しいキー マテリアルが生成され、最新バージョンのメイン暗号化キーによって保護されます。 次の図は、securelakekey のローテーション後のシステムの状態を示しています。

暗号化ゾーン内のファイルが、ローテーションされた securelakekey で保護されていることを確認するには、azdata bdc hdfs encryption-zone -a start -p /securelake を実行します。

次の図は、暗号化ゾーンの再暗号化後のシステムの状態を示しています。

SQL Server

SQL Database を保護するキーは DEK です。これを再生成することができます。 再生成のプロセスによって、データベース全体が再暗号化されます。

メイン暗号化キーのローテーション

Note

SQL Server 2019 CU10 より前では、メイン暗号化キーをローテーションする方法がありませんでした。 SQL Server 2019 CU10 以降では、メイン暗号化キーのローテーションを可能にする azdata コマンドが公開されています。

メイン暗号化キーは RSA 2048 ビットのキーです。 メイン暗号化キーのローテーションでは、キーのソースに応じて、次のいずれかの操作が行われます。

1. メイン キーをシステム マネージド キーにローテーションする要求が行われた場合は、新しいキーを作成します。 システム マネージド キーは非対称キーであり、コントローラー内に生成されて格納されます。
2. 外部から提供されるキーへの参照を作成します。その場合、非対称の秘密キーがカスタマー アプリケーションによって管理されます。 カスタマー アプリケーションには秘密キーは必要ありませんが、提供されるアプリケーションの構成に基づいて秘密キーを取得する方法が認識されている必要があります。

メイン キーのローテーションでは何も再暗号化されません。 その後、SQL Server および HDFS キーは、次のようにローテーションする必要があります。

• メイン キーがローテーションされた後、SQL Server データベースの DEK 保護機能を、作成されたメイン キーの新しいバージョンにローテーションする必要があります。
• HDFS にも同様の概念が適用されます。 HDFS キーがローテーションされると、新しいマテリアルが最新バージョンのメイン キーによって暗号化されます。 古いバージョンの EZ キーはそのままになります。 HDFS EZ キーがローテーションされた後、EZ キーに関連付けられている暗号化ゾーンを再暗号化して、最新の EZ キー バージョンで再暗号化する必要があります。

HDFS のメイン キー ローテーション

次の図は、HDFS のメイン暗号化キーをローテーションするプロセスを示しています。 まず、HDFS の初期状態を示します。

メイン暗号化キーは、azdata bdc kms set –key-provider SystemManaged を使用してローテーションされます (コマンドを実行すると、コントロール プレーン内で異なるキーである場合でも、SQL と HDFS の両方に対してメイン暗号化キーがローテーションされることに注意してください)。azdata bdc kms コマンドを使用した後は、次のようになります。

新しいバージョンの HDFS メイン暗号化キーを使用する場合は、azdata bdc hdfs key roll コマンドを使用できます。これにより、システムが次の状態になります。 securelakekey をローテーションした後は、このようになります。

securelakekey をローテーションすると、新しいバージョンの securelakekey が作成され、メイン暗号化キーによって保護されます。 securelake 内のファイルが securelakekey@2 で暗号化されているのを確認するには、securelake 暗号化ゾーンを再暗号化する必要があります。 暗号化ゾーンを再暗号化した後は、次のようになります。

SQL Server のメイン キー ローテーション

SQL Server のメイン暗号化キーは、SQL Server マスター インスタンスのマスター データベースにインストールされます。

次の図は、SQL Server のメイン暗号化キーをローテーションするプロセスを示しています。

SQL Server ビッグ データ クラスターの新規インストール時に、SQL Server で非対称キーはプロビジョニングされません。 初期状態の SQL Server では、データベースは証明書を使用して暗号化される場合があります。しかし、SQL Server マスター インスタンス管理者によってこの側面が制御されます。

メイン暗号化キーは、azdata bdc kms set –key-provider SystemManaged を使用してローテーションされます (コマンドを実行すると、コントロール プレーン内で異なるキーである場合でも、SQL と HDFS の両方に対してメイン暗号化キーがローテーションされる (存在しない場合は、作成される) ことに注意してください)。

非対称キーは、次の T-SQL クエリと sys.asymmetric_keys システム カタログ ビューを使用して確認できます。

USE master;
select * from sys.asymmetric_keys;

非対称キーは、"tde_asymmetric_key_" という名前付け規則で表示されます。 その後、SQL Server 管理者は、ALTER DATABASE ENCRYPTION KEY を使用して、DEK の保護機能を非対称キーに変更できます。 たとえば、次の T-SQL コマンドを使用します。

USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;

これで、非対称キーを使用するように DEK 保護機能が変更されました。

azdata bdc kms set コマンドが再実行された場合、SQL Server の非対称キーでは、"tde_asymmetric_key_" という形式で sys.asymmetric_keys に別のエントリが示されます。 この azdata コマンドを使用して、SQL Server データベースの DEK 保護機能を再度変更できます。

カスタマー指定のキー

SQL Server ビッグ データ クラスターで外部キーを取り込む機能を使用すると、メイン暗号化キーにより、カスタマーがデプロイするアプリケーションを使用して公開キーがフェッチされます。 HDFS キーがローテーションされ、使用されると、HDFS キーの暗号化を解除するための呼び出しがコントロール プレーンに送信されて、その後、カスタマーによって指定されたキー識別子を使用してアプリケーションにリダイレクトされます。 SQL Server の場合、暗号化要求は、コントロール プレーンによって送信され、実行されます。これは公開キーがあるためです。 SQL からの DEK の暗号化解除要求もコントロール プレーンに送信され、その後、KMS アプリケーションにリダイレクトされます。

次の図では、コントロール プレーンで外部キーを構成する場合の操作について説明します。

キーがインストールされた後、異なるペイロードの暗号化と解読は、メイン暗号化キーによって保護されます。 この保護はシステム マネージド キーと似ていますが、コントロール プレーンにルーティングされる暗号化解除呼び出しが KMS プラグイン アプリにルーティングされる点が異なります。 この KMS プラグイン アプリによって、HSM や別の製品などの適切な場所に要求がルーティングされます。

関連項目

• SQL Server ビッグ データ クラスター のセキュリティの概念
• SQL Server ビッグ データ クラスターを構成する
• ビッグ データ クラスターに関する FAQ