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

2021-10-05

重要

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 インスタンス

システム生成証明書は、TDE コマンドで使用するために SQL Server ポッドにインストールされます。システム管理証明書の名前付け標準は TDECertificate + timestamp。たとえば、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 コンポーネントはコントローラーにデプロイされ、既定のキーと証明書のセットが生成されます。
SQL Server は TDE を有効にして展開され、証明書はコントローラーによってインストールされます。
HDFS 用の Hadoop KMS は、暗号化操作のためにビッグデータクラスター KMS と対話するように構成されています。 HDFS 暗号化ゾーンが構成され、使用できる状態になります。

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

SQL Server ビッグデータクラスター CU8 以降の新しい展開を実行する場合、または CU9 に直接アップグレードする場合は、他の手順は必要ありません。

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

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

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

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

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

他の手順は不要です。

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

注意事項

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

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

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

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

SOP0128という名前の Azure Data Studio Operational Notebook の実行 - ビッグデータクラスターで HDFS 暗号化ゾーンを有効 にして構成を実行します。
以下の説明に従って、スクリプトを実行します。

必要条件：

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

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

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

スクリプトの実行要件:

どちらのスクリプトも同じディレクトリに配置する必要があります。
kubectl Kubernetes の PATH 設定ファイルはフォルダー $HOME/.kube にあります。

このスクリプトには、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 ビッグデータクラスターとは