Поделиться через


Основные понятия шифрования неактивных данных и рекомендации по настройке

Важно!

Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, а программное обеспечение будет по-прежнему поддерживаться с помощью SQL Server накопительных обновлений до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.

Начиная с Кластеров больших данных Microsoft SQL Server 2019 CU8, доступна функция шифрования неактивных данных, с помощью которой можно обеспечить шифрование на уровне приложения для всех данных, хранящихся на платформе. В этом руководстве описаны основные понятия, архитектура и конфигурация для функции шифрования неактивных данных в Кластерах больших данных.

Кластеры больших данных SQL Server хранят данные в следующих расположениях:

  • Главный экземпляр SQL Server.
  • HDFS. Используется пулом носителей и Spark.

Существует два возможных подхода для прозрачного шифрования данных в Кластерах больших данных SQL Server:

  • Шифрование тома. Платформа Kubernetes поддерживает этот подход. Рекомендуется использовать для развертываний Кластеров больших данных. В этой статье не рассматривается шифрование томов. Инструкции по правильному шифрованию томов, которые будут использоваться для Кластеров больших данных SQL Server, см. в документации по платформе или устройству Kubernetes.
  • Шифрование на уровне приложения. Эта архитектура относится к шифрованию данных приложением, обрабатывающим данные перед их записью на диск. Если тома незащищенные, злоумышленник не сможет восстановить артефакты данных в других местах, пока для целевой системы не будут настроены одинаковые ключи шифрования.

Набор функций шифрования неактивных данных кластеров больших данных SQL Server поддерживает основной сценарий шифрования на уровне приложения для компонентов SQL Server и HDFS.

Функция предоставляет следующие возможности:

  • Управляемое системой шифрование неактивных данных. Это возможно только в CU8.
  • Неактивное шифрование, управляемое пользователем, также известно как создание собственных ключей (BYOK). Интеграция, управляемая службой, появилась в SQL Server 2019 CU8. Интеграция внешнего поставщика ключей появилась в SQL Server 2019 CU11+.

Дополнительные сведения см. в статье Версии ключей в Кластеры больших данных SQL Server.

Основные определения

  • Служба управления ключами кластеров больших данных SQL Server (KMS)

    Размещенная контроллером служба, ответственная за управление ключами и сертификатами для функции шифрования неактивных данных для Кластеров больших данных SQL Server. Служба поддерживает следующие функции:

    • Безопасное управление и хранение ключей и сертификатов, используемых для шифрования неактивных данных.
    • Совместимость для службы управления ключами с Hadoop. KMS выступает в качестве службы управления ключами для компонента HDFS в Кластерах больших данных.
    • Управление сертификатами SQL Server прозрачного шифрования данных (TDE).
  • Ключи, управляемые системой

    Служба KMS Кластеров больших данных управляет всеми ключами и сертификатами для SQL Server и HDFS.

  • Пользовательские ключи

    Пользовательские ключи, которыми будет управлять служба KMS Кластеров больших данных, также называются собственными ключами (BYOK). Платформа "Кластеры больших данных" SQL Server поддерживает пользовательское определение ключей, которые будут использоваться для шифрования как в SQL Server, так и в HDFS. Платформа "Кластеры больших данных" KMS управляет этими ключами.

    Внимание!

    Главный экземпляр SQL Server наследует функцию прозрачного шифрования данных (TDE) SQL Server. Однако загрузка пользовательских ключей вручную из файлов в модули pod, их регистрация в SQL Server и использование для TDE не поддерживается. Платформа "Кластеры больших данных" KMS не будет управлять этими ключами. Такая ситуация может привести к тому, что базы данных не получится прочитать. Чтобы правильно использовать внешние ключи, прибегните к функции "Внешние поставщики", как описано в этой статье.

  • Внешние поставщики

    Для делегирования операций шифрования поддерживаются внешние решения для работы с ключами, совместимые с KMS Кластеров больших данных. Эта функция поддерживается в SQL Server 2019 CU11 и более поздних версий. Если эта функция включена, корневой ключ шифрования размещается вне контроллера Кластеров больших данных.

Шифрование неактивных данных в кластерах больших данных SQL Server

Служба контроллера KMS Кластеров больших данных обеспечивает поддержку управляемых системой ключей и ключей, управляемых внешними поставщиками, для шифрования неактивных данных как в SQL Server, так и в HDFS.

Эти ключи и сертификаты управляются службой. В этой статье содержатся операционные рекомендации по взаимодействию со службой.

В наборе функций появляется служба контроллера управления ключами Кластеров больших данных, с помощью которой можно предоставлять управляемые системой ключи и сертификаты для шифрования данных в SQL Server и HDFS. Эти ключи и сертификаты управляются службой. В этой статье содержатся операционные рекомендации по взаимодействию со службой.

  • Экземпляры SQL Server используют установленную функцию прозрачного шифрования данных (TDE).
  • HDFS использует собственные службы управления Hadoop в каждом модуле, чтобы взаимодействовать со службой управления ключами управления Кластеров больших данных на контроллере. Этот подход включает зоны шифрования HDFS, которые обеспечивают безопасные пути в HDFS.

Экземпляры SQL Server

  • На объекты pod SQL Server устанавливается созданный системой сертификат, который будет использоваться с командами TDE. Стандартом именования сертификатов, управляемым системой, является TDECertificate + timestamp. Например, TDECertificate2020_09_15_22_46_27.
  • Подготовленные базы данных и пользовательские базы данных главного экземпляра службы Кластеров больших данных не шифруются автоматически. Администраторы могут использовать установленный сертификат для шифрования любой базы данных.
  • Пул вычислений и пул носителей автоматически шифруются с помощью созданного системой сертификата.
  • Шифрование пула данных, хотя и технически возможно при использовании команд T-SQL EXECUTE AT, в настоящее время не рекомендуется и не поддерживается. Использование этого метода для шифрования баз данных пула данных может быть неэффективным, а шифрование может не произойти в нужном состоянии. В результате его выполнения также создается несовместимый путь обновления к следующим выпускам.
  • Смена ключей SQL Server осуществляется с помощью стандартных команд администрирования T-SQL. Дополнительные сведения см. в статье Руководство по использованию шифрования неактивных данных (TDE) в Кластерах больших данных SQL Server.
  • Мониторинг шифрования происходит через существующие стандартное динамическое административное представление SQL Server для TDE.
  • Поддерживается резервное копирование и восстановление базы данных с поддержкой TDE в кластере.
  • Поддерживается высокий уровень доступности Если база данных на основном экземпляре SQL Server шифруется, то все вторичные реплики базы данных также шифруются.

Зоны шифрования HDFS

  • Интеграция Active Directory требуется для включения зон шифрования для HDFS.
  • Созданный системой ключ подготавливается в системе управления ключей Hadoop. Имя ключа — securelakekey. В CU8 ключ по умолчанию — 256 бит, и мы поддерживаем 256-разрядное шифрование AES.
  • Зона шифрования по умолчанию подготавливается с помощью указанного выше ключа, созданного системой, в пути с именем /securelake.
  • Пользователи могут создавать другие ключи и зоны шифрования, используя конкретные инструкции, приведенные в этом разделе. Пользователи могут выбрать размер ключа 128, 192 или 256 во время создания ключа.
  • Смена ключей зон шифрования HDFS осуществляется с помощью azdata. Дополнительные сведения см. в статье Рекомендации по использованию зон шифрования HDFS в Кластерах больших данных SQL Server.
  • Подключение по уровням HDFS вверху зоны шифрования не поддерживается.

Администрирование шифрования неактивных данных

Ниже перечислены возможности администрирования шифрования неактивных данных.

  • Управление функцией TDE в SQL Server осуществляется с помощью стандартных команд T-SQL.
  • Управление зонами шифрования HDFS и ключами HDFS осуществляется с помощью команд azdata.
  • Следующие функции администрирования выполняются с помощью операционных записных книжек:
    • резервное копирование и восстановление ключей HDFS;
    • удаление ключей HDFS.

Руководство по настройке

Во время новых развертываний кластеров больших данных SQL Server, CU8 и последующих, шифрование неактивных данных будет включено и настроено по умолчанию. Это означает:

  • Компоненты службы управления ключами Кластеров больших данных разворачивается в контроллере и создает набор ключей и сертификатов по умолчанию.
  • SQL Server разворачивается с включенным TDE, а сертификаты устанавливает контроллер.
  • Служба управления ключами Hadoop (для HDFS) настраивается для взаимодействия с сервером Кластеров больших данных для операций шифрования. Зоны шифрования HDFS настроены и готовы к использованию.

Применяются требования и поведение по умолчанию, описанные в предыдущем разделе.

При новом развертывании Кластеров больших данных SQL Server с накопительным пакетом обновления 8 или более поздней версии либо обновлении напрямую до накопительного пакета обновления 9 никаких других действий не требуется.

Варианты обновления

При обновлении существующих кластеров новое или повторное шифрование не применяется к пользовательским данным, которые ранее не были зашифрованы. Такое поведение предусмотрено специально, и для каждого компонента необходимо учитывать следующие особенности:

  • SQL Server

    • Главный экземпляр SQL Server. Процесс обновления не повлияет на базы данных главного экземпляра и установленные сертификаты TDE. Перед обновлением рекомендуется создать резервную копию баз данных и установленных вручную сертификатов TDE. Мы также рекомендуем хранить эти артефакты вне кластера больших данных.
    • Пул вычисления и хранения. Эти базы данных являются управляемыми системой, временными, создаются повторно и автоматически шифруются при обновлении кластера.
    • Пул данных. Обновление не влияет на базы данных в экземплярах SQL Server, входящих в пул данных.
  • HDFS

    В процессе обновления не будут затронуты файлы и папки HDFS, расположенные вне зон шифрования.

Обновление с версии накопительного пакета обновления 8 или более ранней до версии 9

Больше никаких действий не требуется.

Обновление с версии накопительного пакета обновления 6 или более ранней до версии 8

Внимание!

Перед обновлением до кластера больших данных SQL Server CU8 выполните полное резервное копирование ваших данных.

Зоны шифрования не будут настроены. Компонент службы управления ключами Hadoop не будет настроен для использования службы управления ключами Кластеров больших данных. Чтобы настроить и включить зоны шифрования HDFS после обновления, следуйте инструкциям в следующем разделе.

Включение зон шифрования HDFS после обновления до накопительного пакета обновления 8

Если вы обновили кластер до накопительного пакета обновления 8 (azdata upgrade) и хотите включить зоны шифрования HDFS, у вас есть два варианта:

  • выполнение операционной записной книжки Azure Data Studio с именем SOP0128 — включение зон шифрования HDFS в кластерах больших данных для настройки;
  • Запустите скрипты, как описано ниже.

Требования

  • встроенный кластер Active Directory;
  • Azure Data CLI (azdata) настроенный и зарегистрированный в кластере в режиме AD.

Выполните эту процедуру, чтобы перенастроить кластер с поддержкой зон шифрования.

  1. После выполнения обновления, используя azdata, сохраните следующие скрипты.

    Требования к выполнению сценариев:

    • Оба скрипта должны находиться в одном каталоге.
    • kubectl в файле конфигурации PATH для Kubernetes в папке $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 см. в следующем обзоре: