SQL Server ビッグ データ クラスターでの外部キー プロバイダー
重要
Microsoft SQL Server 2019 ビッグ データ クラスターのアドオンは廃止されます。 SQL Server 2019 ビッグ データ クラスターのサポートは、2025 年 2 月 28 日に終了します。 ソフトウェア アシュアランス付きの SQL Server 2019 を使用する既存の全ユーザーはプラットフォームで完全にサポートされ、ソフトウェアはその時点まで SQL Server の累積更新プログラムによって引き続きメンテナンスされます。 詳細については、お知らせのブログ記事と「Microsoft SQL Server プラットフォームのビッグ データ オプション」を参照してください。
この記事では、キー管理のために SQL Server ビッグ データ クラスターで外部キー プロバイダーを構成する方法の詳細について説明します。
SQL Server ビッグ データ クラスターでのキー バージョンの使用方法の詳細については、「SQL Server ビッグ データ クラスターでのキー バージョン」を参照してください。
保存時の暗号化の構成と使用については、次のガイドを参照してください。
- 保存時の暗号化の概念と構成ガイド
- SQL Server ビッグ データ クラスター HDFS 暗号化ゾーンの使用ガイド
- SQL Server ビッグ データ クラスターの保存時の Transparent Data Encryption (TDE) の使用ガイド
前提条件
- SQL Server 2019 ビッグ データ クラスターのリリース ノート。 CU11 以降が必要です。
- azdata 20.3.5 以降などのビッグ データ ツール。
- Kubernetes 管理者特権を持つ SQL Server ビッグ データ クラスター ユーザー (clusterAdmins ロールのメンバー)。 詳細については、「Active Directory モードでビッグ データ クラスター アクセスを管理する」を参照してください。
- 外部プロバイダー テンプレート アプリケーション。 「SQL Server BDC の保存時の暗号化」を参照してください。
外部プロバイダーを使用したルート キーの暗号化
SQL Server ビッグ データ クラスターで外部キーを取り込む機能を使用すると、メイン暗号化キーにより、お客様が配置するアプリケーションを使用して公開キーがフェッチされます。 HDFS キーがローテーションされるときと使用されるときは、HDFS キーを解読するための呼び出しがコントロール プレーンに送信された後、お客様によって指定されたキー識別子を使用してアプリケーションにリダイレクトされます。 SQL Server の場合、暗号化要求は、コントロール プレーンによって送信され、実行されます。これは公開キーがあるためです。 SQL Server からのデータ暗号化キー (DEK) 解読要求も、コントロール プレーンに送信された後、ハードウェア セキュリティ モジュール (HSM) などの外部プロバイダーとのインターフェイスを持つアプリケーションにリダイレクトされます。
次の図では、コントロール プレーンで外部キーを構成する場合の操作について説明します。
キーがインストールされた後、異なるペイロードの暗号化と解読は、メイン暗号化キーによって保護されます。 この保護はシステム マネージド キーと似ていますが、コントロール プレーンにルーティングされる解読呼び出しがキー管理サービス (KMS) プラグイン アプリにルーティングされる点が異なります。 この KMS プラグイン アプリによって、HSM、Hashicorp Vault、別の製品などの適切な場所に要求がルーティングされます。
構成
提供されるテンプレート アプリケーションは、外部キー プロバイダーとのインターフェイスに使用されるプラグインです。 このアプリケーションは、選択した外部キー プロバイダーとの統合ポイントとして機能するように、カスタマイズしてビッグ データ クラスターに配置する必要があります。
テンプレート アプリケーションには、SoftHSM を使用する標準の PKCS11 プロトコルを使用して、外部プロバイダーの実装と統合する方法の例があります。 また、Azure Key Vault と Hashicorp Vault を使用する例があります。 テンプレート アプリケーションは、参照実装としてそのまま提供されます。
以下のセクションでは、SQL Server データベースと HDFS 暗号化ゾーン用の暗号化のルート キーとして機能するように外部キー プロバイダーを構成するために必要な手順について説明します。
外部キー プロバイダーで RSA 2048 キーを作成する
2,048 ビットの RSA キーを使用して PEM ファイルを作成し、外部キー プロバイダーのキー値ストアにアップロードします。
たとえば、キー ファイルがパス bdc-encryption-secret にある Hashicorp Vault 内の KV ストアに追加され、シークレットの名前を rsa2048 にすることができます。
統合アプリケーションをカスタマイズしてビッグ データ クラスターに配置する
ローカル コンピューターで、kms_plugin_app (ビッグ データ クラスター AppDeploy テンプレート アプリケーション) を含むフォルダーに移動します。
いずれかのテンプレートを選択して、それをシナリオに合わせて調整することで、アプリケーションをカスタマイズします。
- ファイル custom_softhsm.py には、SoftHSM を使用した参照実装が含まれています
- ファイル custom_akv.py には、Azure Key Vault の例が含まれています
- ファイル custom_hcv.py には、HashiCorp Vault の例が含まれています
注意事項
統合ポイントである、関数のコントラクトまたはシグネチャは変更しないでください。 必要に応じて、関数の実装のみを変更します。
上記のテンプレートから作成しているファイルに適宜名前を付けます。 たとえば、custom_softhsm.py を my_custom_integration_v1.py として保存し、カスタマイズを実行します。 この手法は次の手順で重要となります。
app.py は、アプリケーションを読み込むエントリポイントです。 このファイルでは、前の手順のカスタム ファイル名 (.py 拡張子がないもの) を指すように、11 行目を変更する必要があります。 上記の例に従い、次のように変更します。
... import utils from json_objects import EncryptDecryptRequest import custom_softhsm as custom def handler(operation, payload, pin, key_attributes, version): ...
次の値にしてください。
... import utils from json_objects import EncryptDecryptRequest import my_custom_integration_v1 as custom def handler(operation, payload, pin, key_attributes, version): ...
spec.yaml があるフォルダーから、このコマンドを使用してアプリケーションをビッグ データ クラスターに配置します。
azdata app create -s
アプリケーションの配置が完了するまで待ちます。準備完了状態は、このコマンドを使用して確認できます
azdata app list
外部キー プロバイダーを使用するようにビッグ データ クラスターを構成する
AZDATA_EXTERNAL_KEY_PIN
環境変数を設定して、外部キー プロバイダーへのアクセスを許可するトークンを提供します。export AZDATA_EXTERNAL_KEY_PIN=<your PIN/token here>
注意
統合アプリケーションの配置プロセスでは、トークンを使用して外部キー プロバイダーにアクセスします。 ただし、
AZDATA_EXTERNAL_KEY_PIN
変数は、アプリケーションで解釈できるように、ビッグ データ クラスター コントロール プレーンで暗号化されて保存されます。 別の認証メカニズムを使用することもできますが、アプリケーションを変更する必要があります。 使用されている完全な統合ロジックについては、custom*.py Python アプリケーションを調べてください。次の
azdata
コマンド構造を使用して、ビッグ データ クラスターでキーを構成します。 必須パラメーターを特定の実装に変更します。 次の例では、custom2.py によって提供される HashiCorp Vault 構造を使用します。azdata bdc kms update --app-name <YOUR-APP-NAME> --app-version <YOUR-APP-VERSION> \ --key-attributes keypath=<YOUR-KEY-PATH>,vaulturl=http://<YOUR-IP>:<YOUR-PORT>,keyname=<YOUR-KEY-NAME> \ --provider External
--provider External
パラメーター値を使用すると、キー操作用のエンドポイントとして統合アプリケーションを使用するように、ビッグ データ クラスター KMS が構成されます。次のコマンドを使用して、ルート暗号化キーが外部で管理されているキーであることを確認します。
azdata bdc kms show
新しいキーを使用してデータベースと暗号化ゾーンを暗号化する
構成が完了しても、SQL Server データベースと HDFS 暗号化ゾーンは、以前のキー階層によってまだ暗号化されています。 外部で管理されているキーを使用して、明示的に暗号化する必要があります。
SQL Server に、外部で管理されるキーに基づく新しい非対称キーがインストールされます。 それを使用してデータベースを暗号化します。
非対称キーは、次の T-SQL クエリと sys.asymmetric_keys
システム カタログ ビューを使用して確認できます。
USE master;
select * from sys.asymmetric_keys;
非対称キーは名前付け規則 tde_asymmetric_key_<version>
を使用して表示されます。 その後、SQL Server 管理者は、ALTER DATABASE ENCRYPTION KEY を使用して、DEK の保護機能を非対称キーに変更できます。 たとえば、次の T-SQL コマンドを使用します。
USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;
現在の暗号化キーを確認するには、次のコマンドを実行します。
azdata bdc hdfs key describe
暗号化ゾーン キーを保護しているキーのバージョンに関する情報を取得します。
azdata bdc hdfs key describe --name <key name>
新しい外部で管理されるキーに、キーをロールします。
azdata bdc hdfs key roll --name <new key name>
次のコマンドを使用して暗号化を開始します。
azdata bdc hdfs encryption-zone reencrypt –-path <your EZ path> --action start
次のコマンドを使用して、キー階層を確認します。
azdata bdc kms show azdata bdc hdfs key describe