Тестирование работы «прозрачного» (TDE) шифрования 1С на базе СУБД MSSQL 2022

В данном материале мы рассмотрим работу TDE шифрования на базе MS SQL 2022. Основная цель статьи:

• Используя тест ADPEX в демо базе 1С проверить работу технологии TDE.

Дополнительная цель статьи:

• Как выполнить подбор оборудования для использования технологии TDE.

Глава 1. Тестовый стенд.

Часть 1. Аппаратная часть

Аппаратная часть:

• Supermicro X9DRT-P*
• 2 x Intel Xeon E5-2667v2 3,3 – 4.0 GHz, each 8 Core.
• ОЗУ 512 ГБ DDR3
• Хранилище RAID 10, Intel DC S4610 1.92 Tb

*В рамках исследования мы сознательно взяли устаревшую платформу, чтобы увидеть разницу в работе ПО, без поправки на “быстрое” железо. Тесты дисковой подсистемы: Тест проводился с использованием Crystal Disk Mark. Параметры “NVME SSD” файлом 32 ГБ:

Часть 2. Программная часть

1. Платформа 1С предприятие 8.3.22.2283.
2. Конфигурации:

В рамках тестирования мы используем стандартный шаблон “полный” на 33 пользователя. Данный шаблон проходит 4 итерации, начиная с 40 пользователей на первой и 120 пользователей на последней. Пример окна «Настройки запуска»:

Часть 3. Виртуальные мощности.

Аппаратный Сервер приложений 1С и баз данных – WIndows Server 2019 Standart.

Глава 2. Общая Методика тестирования

В рамках данной статьи мы применяем методику анализа используя абсолютные и относительные значения погрешности. Описание методики определения погрешностей:

1. Определяются идеальные условия испытаний (в нашем случае – это аппаратный сервер с ролями сервера 1С и MS SQL 2022, с активным режимом TCP).
2. Производим расчет абсолютной погрешности.

Проводим замер целевых значений:

1. Проводим замер тестов АПДЕКС используя связки 1С + MsSQL 2022 на аппаратном сервере. Конфигурация теста Апдекс – тест “полный”, число пользователей 40\80\120.
2. Замеры проводим три раза, результаты вносим в таблицу.

Примечание: Тест 1С:КИП(АПДЕКС) В основе методики АПДЕКС лежит набор инструментов 1С КИП. В данном случае использовался весь функционал методологии. Используются стандартная демонстрационная база ERP с сайта 1С. Стандартная методология АПДЕКС использует прогрессивную шкалу от 0 до 1, где 1 – это замечательный результат, а 0 – неудовлетворительный. Требуется указать целевое значение параметра производительности той или иной операции, создать сценарии и запустить тест.

Глава 3. Оптимизации

Часть 1. Оптимизации аппаратной части

Перед работой с носителем были произведены твики биоса. В данном случае необходимо было вручную выставить или режим “Max Performance” в расширенных настройках CPU или полностью отключить энергосбережение в режиме “Custom”. Стандартный режим “Max Performance”: Примечание:

• Стандартный режим производительности. Получаем турбобуст до 4.0 ГЦ при минимальных нагрузках.
• 3600 MHz (5 и больше ядер)
• 3700 MHz (4 ядра)
• 3800 MHz (3 ядра)
• 3900 MHz (2 ядра)
• 4000 MHz (1 ядро)

Или выставить настройки на скриншоте ниже: Расширенный режим: Примечание:

• Данные настройки применимы только к материнским платам серии X9. В других случаях настройки индивидуальны.
• При применении режима Custom по итогу мы получим фиксированную частоту в 3.3 Ггц на всех ядрах в постоянном режиме.

Часть 2. Оптимизации программной части. Сервер 1С

• Выставляем параметры электропитания Windows в положение “Высокая производительность”.

Часть 3. Оптимизации программной части. MS SQL сервер

• • Используем нашу статью для установки MS SQL 2022.
  • Используем материалы с сайта ИТС 1С для тюнинга БД.

Данных инструкций будет достаточно для базовой настройки SQL сервера.

Часть 4. Включение «прозрачного» шифрования Transparent Data Encryption (TDE)

Описание технологии. Функция прозрачного шифрования данных выполняет шифрование и дешифрование ввода-вывода в реальном времени для файлов данных и журналов. Шифрование использует ключ шифрования базы данных (DEK). Загрузочная запись базы данных хранит ключ для доступности во время восстановления. DEK — это симметричный ключ, защищенный сертификатом, который хранится в базе данных сервера master или асимметричным ключом, защищенным модулем EKM. Описание технологии TDE хорошо описано в официальном блоге компании Microsoft. Мы дадим комментарий некоторым особенностям этой инструкции. Если провести анализ данной цитаты, то становится понятно, что, теоретически, если злоумышленник получит права администратора к активному серверу, то проведя копирование данных базы непосредственно из оперативной памяти возможно получить незашифрованные данные. И хотя в блоге компании Microsoft прямо не упоминаются потери производительности при включении TDE, мы нашли некоторые упоминания, что потеря составляет от 3 до 5 процентов, а в некоторых исследованиях до 28%. Проверим эту теорию нагрузочными испытаниями. Если говорить про детали теста, то в рамках нашего исследования мы не будем генерировать новые таблицы и ввод новых данных, основа исследования это операции проведения, перепроведения и чтения из БД, что удовлетворяет принципам шифрования TDE. Включение шифрования:

• Шаг 1 – создание мастер ключа USE master go CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘пароль’.
• Шаг 2 – создание сертификата CREATE CERTIFICATE DEK_EncCert WITH SUBJECT = ‘DEK Encryption Certificate’.
• Шаг 3 – создание бэкапа сертификата и ключа BACKUP CERTIFICATE DEK_EncCert TO FILE =’C:\certs\DEK_EncCert.cert’ WITH PRIVATE KEY( FILE = ‘C:\certs\DEK_EncCert.prvk’, ENCRYPTION BY PASSWORD = ‘пароль’ );BACKUP MASTER KEY TO FILE = ‘C:\certs\master_key.bak’ ENCRYPTION BY PASSWORD = ‘пароль’.
• Шаг 4 – создание в БД Database Encryption Key (DEK) USE MySecretDB go CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE DEK_EncCert.
• Шаг 5 – включение шифрования для базы ALTER DATABASE ERP SET ENCRYPTION ON.
• Шаг 6 – Проверка статуса шифрования SELECT DB_NAME(database_id), encryption_state, percent_complete FROM sys.dm_database_encryption_keys.

После выполнения последней команды мы получили таблицу вида: Основные статусы данного меню:

• 0 – Database Encryption Key (DEK) не создан.
• 1 – Database Encryption Key (DEK) создан, но база данных не зашифрована.
• 2 – Выполняется первоначальное шифрование.
• 3 – База данных зашифрована.
• 4 – Идет смена ключа.
• 5 – Идет расшифровка.

На этом процесс активации TDE завершен.

Глава 4. Тестирование.

Часть 1. Тест Апдекс

1. Значение апдекс на эталонном сервере.
2. Значения Апдекс при включении шифрования.
3. Процентное отношение производительности Апдекс к эталонным значениям аппаратного сервера с учетом погрешности (меньше лучше).

   Нагрузка процессора с отключенным TDE.

   

   Нагрузка процессора с включенным TDE.

   

Выводы:

• В рамках нашего тестирования значения при активации шифрования и деактивации практически не изменились.

Часть 2. Тест Апдекс. Дополнительные испытания

В 1 части нашего исследования мы не заметили никаких весомых изменений в производительности нашего тестового стенда. Потому провели несколько дополнительных испытаний. MS SQL сервер стремится загрузить всю базу в оперативную память, а принцип работы TDE подразумевает, что данные в памяти уже расшифрованы. Зная , что наш объем базы составляет 9,2 ГБ мы уменьшили ОЗУ, выделяемую под SQL сервер до 3х ГБ, пытаясь “заставить” сервер баз данных активнее работать с операциями чтения/записи. Детальные данные отчета публиковать не будем, ввиду того, что отличий от первой части теста, кроме увеличения времени выполнения операции мы не заметили. Удивительного ничего нет, зная, что под SQL выделено 3гб ОЗУ. Что интересно, на 40 и 80 пользователей, база MS SQL корректно выполнила тест на столь малом объеме ОЗУ. Результаты теста ухудшились в сторону более долгого времени выполнения, но повышенную нагрузку на CPU мы не заметили. Время жизни страницы увеличилось, процент попадания в кеш уменьшился, но не до критических значений.

Глава 5. Выводы

Основная тема статьи В рамках нашего тестирования мы наглядно увидели, что технология TDE не оказывает влияния на производительность системы в идеальных условиях. Мы думаем это связано с рядом факторов:

1. База данных полностью была выгружена в ОЗУ. А как мы знаем, в ОЗУ база не шифруется.
2. Мы имели достаточный запас мощности по CPU и дисковой подсистеме. Пики загрузки CPU были от 40 до 60%.
3. Много кэшированных данных, долгое время жизни страницы. В среднестатистической базе 1С , в целом, ситуация похожая. Львиная доля операций в 1С – это типовые операции, которые регулярно попадают в кеш.
4. В демо базе от 1С нет сверхтяжелых и долгих запросов, с которыми бы не справился наш демо стенд.

В сети есть довольно старые исследования данной технологии, в том числе и зарубежные, в которых наглядно видна довольно серьезная потеря производительности. Эта потеря достигалась за счет тяжелых запросов на операции записи и чтения, вплоть до сотен тысяч строк единовременно. Внимательный читатель может задать вопрос – Почему вы так же не сделали? Отвечаем – А зачем? Да, действительно, при ручном создании тяжелых запросов мы точно увидим рост нагрузки CPU и возможно увеличение время чтения/записи с дискового массива. Но приближает ли нас этот тест к реальным показателям работы? Мы думаем, что нет. Потому и выбрали в качестве испытуемого демо базу от 1С, а не полностью синтетические тесты. Дополнительные цели статьи Для того что бы компании выбрать аппаратную часть под TDE шифрование мы бы предложили несколько вариантов:

1. Создать тест ADPDEX под свои бизнес процессы. Это не быстрый процесс, но самый надежный.
2. Если база приближена к типовой и вы уверены, что проблемы с кодом если и есть, то минимальны, то вполне возможно провести активацию шифрования на продакшн системе ( с принятием рисков конечно же). Сам процесс шифрования базы 10 гб на нашем железе занял не более 3 минут. Расшифровка также около 3х минут. Главное не потерять ключ и сертификат.