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

重要

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)。

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

  1. 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 ビッグ データ クラスターの詳細については、次の概要を参照してください。