保存時の暗号化の概念と構成ガイド

[アーティクル]
03/21/2023

重要

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

Microsoft SQL Server 2019 CU8 以降のビッグデータクラスターでは、保存時の暗号化機能を使用して、プラットフォームに保存されるすべてのデータをアプリケーションレベルで暗号化できます。このガイドでは、ビッグデータクラスター用の保存時の暗号化機能セットの概念、アーキテクチャ、構成について説明します。

SQL Server ビッグデータクラスターでは、データは次の場所に保存されます。

SQL Server マスターインスタンス。
HDFS。記憶域プールと Spark で使用されます。

SQL Server ビッグデータクラスターのデータを透過的に暗号化するためのアプローチは 2 つあります。

ボリューム暗号化。 Kubernetes プラットフォームは、このアプローチをサポートしています。これは、ビッグデータクラスター展開のベストプラクティスです。この記事では、ボリュームの暗号化については説明しません。 SQL Server ビッグデータクラスターに使用されるボリュームを適切に暗号化する方法については、Kubernetes プラットフォームまたはアプライアンスのドキュメントを参照してください。
アプリケーションレベルの暗号化。このアーキテクチャは、データがディスクに書き込まれる前に、そのデータを処理するアプリケーションによるデータの暗号化を示します。ボリュームが公開されている場合、攻撃者は、復元先のシステムも同じ暗号化キーで構成されていない限り、データ成果物を他の場所に復元することはできません。

SQL Server ビッグデータクラスターの保存時の暗号化機能セットは、SQL Server および HDFS コンポーネントのアプリケーションレベルの暗号化の主要シナリオをサポートしています。

この機能では、次の機能が提供されます。

保存時のシステム管理の暗号化。この機能は、CU8 以降で使用できます。
保存時のユーザー管理の暗号化は、Bring Your Own Key (BYOK) とも呼ばれます。 SQL Server 2019 CU8 では、サービス管理統合が導入されました。 SQL Server 2019 CU11 以降では、外部キープロバイダー統合が導入されています。

詳細については、「SQL Server ビッグデータクラスターでのキーのバージョン」を参照してください。

重要な定義

SQL Server ビッグデータクラスターキー管理サービス (KMS)

SQL Server ビッグデータクラスターの保存時の暗号化機能セットのキーと証明書を管理する、コントローラーでホストされるサービス。このサービスは、次の機能をサポートしています。
- 保存時の暗号化に使用されるキーと証明書のセキュリティで保護された管理と格納。
- Hadoop KMS の互換性。 KMS は、ビッグデータクラスター上の HDFS コンポーネントのキー管理サービスとして機能します。
- SQL Server Transparent Data Encryption (TDE) 証明書の管理。
システムマネージドキー

ビッグデータクラスター KMS サービスは、SQL Server と HDFS のすべてのキーと証明書を管理します
ユーザー定義キー

ビッグデータクラスター KMS によって管理されるユーザー定義キー。一般に、Bring Your Own Key と呼ばれます。 SQL Server ビッグデータクラスターでは、SQL Server と HDFS の両方のコンポーネントで暗号化に使用されるキーのカスタム定義がサポートされています。ビッグデータクラスター KMS は、これらのキーを管理します。

注意事項

SQL Server マスターインスタンスは、SQL Server の TDE 機能を継承します。ただし、カスタムキーをファイルからポッドに手動で読み込み、SQL Server に登録して、TDE に使用するシナリオは、サポートされていません。ビッグデータクラスター KMS は、これらのキーを管理しません。この状況では、データベースを読み取ることができなくなる場合があります。外部から提供されるキーを正しく使用するには、この記事で説明されている "外部プロバイダー" 機能を使用します。
外部プロバイダー

暗号化操作を委任するために、ビックデータクラスターの KMS と互換性のある外部キーソリューションがサポートされています。この機能は、SQL Server 2019 CU11 以降でサポートされています。この機能を有効にすると、暗号化のルートキーがビッグデータクラスターコントローラーの外部でホストされます。

SQL Server ビッグデータクラスターでの保存時の暗号化

ビッグデータクラスター KMS コントローラーサービスにより、SQL Server と HDFS の両方で保存時のデータ暗号化を実現するために、システムマネージドキーと外部プロバイダー制御キーがサポートされます。

これらのキーと証明書は、サービスによって管理されます。この記事では、サービスとやり取りする方法についての操作ガイダンスを提供します。

この機能セットにより、ビッグデータクラスター KMS コントローラーサービスが導入され、SQL Server と HDFS の両方で保存時にデータを暗号化するためのシステムマネージドキーと証明書が提供されます。これらのキーと証明書は、サービスによって管理されます。この記事では、サービスとやり取りする方法についての操作ガイダンスを提供します。

SQL Server のインスタンスは、確立された Transparent Data Encryption (TDE) 機能を使用します。
HDFS は、各ポッド内のネイティブ Hadoop KMS を使用して、コントローラーのビッグデータクラスター KMS とやり取りします。このアプローチにより HDFS 暗号化ゾーンが有効になり、HDFS でセキュリティで保護されたパスを使用できます。

SQL Server インスタンス

システムによって生成された証明書は、SQL Server ポッドにインストールされ、TDE コマンドで使用されます。システム管理の証明書の名前付け標準は timestamp + TDECertificate です。たとえば、TDECertificate2020_09_15_22_46_27 のようにします。
マスターインスタンスのビッグデータクラスターでプロビジョニングされたデータベースとユーザーデータベースは、自動的には暗号化されません。データベース管理者は、インストールされている証明書を使用して任意のデータベースを暗号化できます。
コンピューティングプールと記憶域プールは、システム生成の証明書を使用して自動的に暗号化されます。
データプールの暗号化は、T-SQL の EXECUTE AT コマンドを使用すれば技術的には可能ですが、現時点では推奨されておらず、サポートされていません。この手法を使用してデータプールデータベースを暗号化することは有効ではない場合があり、必要な状態で暗号化が行われない可能性があります。また、このアプローチでは、次のリリースに対して互換性のないアップグレードパスが作成されます。
SQL Server キーのローテーションは、標準の T-SQL 管理コマンドを使用して実現されます。詳細については、「SQL Server ビッグデータクラスターの保存時の Transparent Data Encryption (TDE) の使用ガイド」を参照してください。
暗号化の監視は、既存の標準の TDE 用 SQL Server DMV で行われます。
TDE 対応データベースのバックアップとクラスターへの復元がサポートされています。
高可用性がサポートされています。 SQL Server のプライマリインスタンス上のデータベースが暗号化されると、その後、そのデータベースのセカンダリレプリカもすべて暗号化されます。

HDFS 暗号化ゾーン

HDFS の暗号化ゾーンを有効にするには、Active Directory 統合が必要です。
システム生成のキーは、Hadoop KMS でプロビジョニングされます。キー名は securelakekey です。 CU8 では、既定のキーは 256 ビットであり、256 ビットの AES 暗号化がサポートされています。
既定の暗号化ゾーンは、/securelake という名前のパス上にある上記のシステム生成キーを使用してプロビジョニングされます。
ユーザーは、このガイドで説明されている特定の手順を使用して、他のキーと暗号化ゾーンを作成できます。ユーザーは、キーを作成するときに、128、192、または 256 のキーサイズを選択できます。
HDFS 暗号化ゾーンのキーのローテーションは、azdata を使用して実現されます。詳細については、「SQL Server ビッグデータクラスター HDFS 暗号化ゾーンの使用ガイド」を参照してください。
暗号化ゾーンの上に HDFS 階層をマウントすることはサポートされていません。

保存時の暗号化の管理

次の一覧に、保存時の暗号化の管理機能を示します。

SQL Server TDE 管理は、標準の T-SQL コマンドを使用して実行されます。
HDFS 暗号化ゾーンと HDFS キーの管理は、azdata コマンドを使用して実行されます。
次の管理機能は、操作ノートブックを使用して実行されます。
- HDFS キーのバックアップと復旧
- HDFS キーの削除

構成ガイド

SQL Server ビッグデータクラスターを新しく展開する間に、CU8 以降では、保存時の暗号化が既定で有効になって構成されます。これは次のことを意味します。

ビッグデータクラスター KMS コンポーネントがコントローラーに展開され、キーと証明書の既定セットが生成されます。
TDE がオンになった状態で SQL Server が展開され、コントローラーによって証明書がインストールされます。
暗号化操作についてビッグデータクラスター KMS とやり取りするように HDFS の Hadoop KMS が構成されます。 HDFS 暗号化ゾーンが構成され、使用できるようになります。

前のセクションで説明した要件と既定の動作が適用されます。

SQL Server ビッグデータクラスター CU8 以降を新しく展開する場合、または CU9 に直接アップグレードする場合、他の手順は不要です。

アップグレードのシナリオ

既存のクラスターでは、アップグレードプロセスによって、まだ暗号化されていないユーザーデータに対して新しい暗号化や再暗号化は適用されません。この動作は仕様であり、コンポーネントごとに次の問題を考慮する必要があります。

SQL Server
- SQL Server マスターインスタンス。アップグレードプロセスは、マスターインスタンスデータベースとインストールされている TDE 証明書には影響しません。アップグレードプロセスの前に、データベースと手動でインストールした TDE 証明書をバックアップすることをお勧めします。また、ビッグデータクラスターの外部にこれらの成果物を保存することをお勧めします。
- コンピューティングと記憶域プール。これらのデータベースは、システムで管理され、揮発性であり、クラスターのアップグレード時に再作成されて自動的に暗号化されます。
- データプール。データプールの SQL Server インスタンス部分のデータベースには、アップグレードによる影響はありません。
HDFS

アップグレードプロセスにより、暗号化ゾーンの外部にある HDFS ファイルやフォルダーは処理されません。

CU8 以前から CU9 へのアップグレード

他の手順は不要です。

CU6 以前から CU8 へのアップグレード

注意事項

SQL Server ビッグデータクラスター CU8 にアップグレードする前に、データの完全バックアップを実行してください。

暗号化ゾーンは構成されません。 Hadoop KMS コンポーネントは、ビッグデータクラスター KMS を使用するように構成されません。アップグレード後に HDFS 暗号化ゾーンを構成して有効にするには、次のセクションの手順に従います。

CU8 へのアップグレード後に HDFS 暗号化ゾーンを有効にする

クラスターを CU8 (azdata upgrade) にアップグレード済みで、HDFS 暗号化ゾーンを有効にしたい場合、2 つのオプションがあります。

SOP0128 - ビッグデータクラスターで HDFS 暗号化ゾーンを有効にするという名前の Azure Data Studio 操作ノートブックの実行。
以下の説明に従いスクリプトを実行する。

要件:

Active Directory 統合クラスター。
AD モードで構成され、クラスターにログインしている Azure Data CLI (azdata)。

次の手順に従い、暗号化ゾーンをサポートするようにクラスターを再構成します。

azdata でアップグレードを実行した後、次のスクリプトを保存します。

スクリプトの実行要件:

両方のスクリプトが同じディレクトリ内に存在する必要があります。
$HOME/.kube フォルダーにある Kubernetes の PATH 構成ファイルでの kubectl。

このスクリプトには、run-key-provider-patch.sh という名前を付ける必要があります。

#!/bin/bash

if [[ -z "${BDC_DOMAIN}" ]]; then
  echo "BDC_DOMAIN environment variable with the domain name of the cluster is not defined."
  exit 1
fi

if [[ -z "${BDC_CLUSTER_NS}" ]]; then
  echo "BDC_CLUSTER_NS environment variable with the cluster namespace is not defined."
  exit 1
fi

kubectl get configmaps -n test

diff <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py) <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | python -m json.tool)

diff <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py) <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | python -m json.tool)

# Replace the config maps.
#
kubectl replace -n $BDC_CLUSTER_NS -o json -f <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py)

kubectl replace -n $BDC_CLUSTER_NS -o json -f <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py)

# Restart the pods which need to have the necessary changes with the core-site.xml
kubectl delete pods -n $BDC_CLUSTER_NS nmnode-0-0
kubectl delete pods -n $BDC_CLUSTER_NS storage-0-0
kubectl delete pods -n $BDC_CLUSTER_NS storage-0-1

# Wait for sometime for pods to restart
#
sleep 300

# Check for the KMS process status.
#
kubectl exec -n $BDC_CLUSTER_NS -c hadoop nmnode-0-0 -- bash -c 'ps aux | grep kms'
kubectl exec -n $BDC_CLUSTER_NS -c hadoop storage-0-0 -- bash -c 'ps aux | grep kms'
kubectl exec -n $BDC_CLUSTER_NS -c hadoop storage-0-1 -- bash -c 'ps aux | grep kms'

このスクリプトには、updatekeyprovider.py という名前を付ける必要があります。

#!/usr/bin/env python3

import json
import re
import sys
import xml.etree.ElementTree as ET
import os

class CommentedTreeBuilder(ET.TreeBuilder):
    def comment(self, data):
        self.start(ET.Comment, {})
        self.data(data)
        self.end(ET.Comment)

domain_name = os.environ['BDC_DOMAIN']

parser = ET.XMLParser(target=CommentedTreeBuilder())

core_site = 'core-site.xml'
j = json.load(sys.stdin)
cs = j['data'][core_site]
csxml = ET.fromstring(cs, parser=parser)
props = [prop.find('value').text for prop in csxml.findall(
    "./property/name/..[name='hadoop.security.key.provider.path']")]

kms_provider_path=''

for x in range(5):
    if len(kms_provider_path) != 0:
        kms_provider_path = kms_provider_path + ';'
    kms_provider_path = kms_provider_path + 'nmnode-0-0.' + domain_name

if len(props) == 0:
    prop = ET.SubElement(csxml, 'property')
    name = ET.SubElement(prop, 'name')
    name.text = 'hadoop.security.key.provider.path'
    value = ET.SubElement(prop, 'value')
    value.text = 'kms://https@' + kms_provider_path + ':9600/kms'
    cs = ET.tostring(csxml, encoding='utf-8').decode('utf-8')

j['data'][core_site] = cs

kms_site = 'kms-site.xml.tmpl'
ks = j['data'][kms_site]

kp_uri_regex = re.compile('(<name>hadoop.kms.key.provider.uri</name>\s*<value>\s*)(.*)(\s*</value>)', re.MULTILINE)

def replace_uri(match_obj):
    key_provider_uri = 'bdc://https@hdfsvault-svc.' + domain_name
    if match_obj.group(2) == 'jceks://file@/var/run/secrets/keystores/kms/kms.jceks' or match_obj.group(2) == key_provider_uri:
        return match_obj.group(1) + key_provider_uri + match_obj.group(3)
    return match_obj.group(0)

ks = kp_uri_regex.sub(replace_uri, ks)

j['data'][kms_site] = ks
print(json.dumps(j, indent=4, sort_keys=True))

適切なパラメーターを指定して run-key-provider-patch.sh を実行します。

外部プロバイダーの構成

前のセクションで説明したように、SQL Server 2019 CU8 以降のビッグデータクラスターの展開では、システムマネージドキーにより保存時の暗号化機能が既定で有効になります。 SQL Server と HDFS の暗号化のルートキーをセキュリティで保護するために外部キープロバイダーを有効にするには、「SQL Server ビッグデータクラスターでの外部キープロバイダー」を参照してください。

次の手順

SQL Server ビッグデータクラスターでのキーバージョンの使用方法の詳細については、「SQL Server ビッグデータクラスターでのキーバージョン」を参照してください。

SQL Server ビッグデータクラスターの保存時の暗号化を効果的に使用する方法の詳細については、次の記事を参照してください。

SQL Server ビッグデータクラスターの詳細については、次の概要を参照してください。

SQL Server 2019 ビッグデータクラスターとは

次の方法で共有

保存時の暗号化の概念と構成ガイド

重要な定義

SQL Server ビッグデータクラスターでの保存時の暗号化

SQL Server インスタンス

HDFS 暗号化ゾーン

保存時の暗号化の管理

構成ガイド

アップグレードのシナリオ

CU8 以前から CU9 へのアップグレード

CU6 以前から CU8 へのアップグレード

CU8 へのアップグレード後に HDFS 暗号化ゾーンを有効にする

外部プロバイダーの構成

次の手順

フィードバック

その他のリソース

次の方法で共有

保存時の暗号化の概念と構成ガイド

重要な定義

SQL Server ビッグ データ クラスターでの保存時の暗号化

SQL Server インスタンス

HDFS 暗号化ゾーン

保存時の暗号化の管理

構成ガイド

アップグレードのシナリオ

CU8 以前から CU9 へのアップグレード

CU6 以前から CU8 へのアップグレード

CU8 へのアップグレード後に HDFS 暗号化ゾーンを有効にする

外部プロバイダーの構成

次の手順

フィードバック

その他のリソース

SQL Server ビッグデータクラスターでの保存時の暗号化