Шифрование и управление ключами в SQL Server. Часть 1

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

Архитектура шифрования и управления ключами

Во многих приложениях и службах Microsoft реализован интерфейс поставщика доступа, или провайдера (Provider). Этот термин Microsoft обозначает стандартизованную подключаемую архитектуру для сторонних программно-технических компаний, применяемую в целях интеграции и расширения возможностей решений Microsoft. Архитектуры Provider предоставляют сторонним участникам метод регистрации их программных продуктов в приложении Microsoft, после чего приложение будет обращаться к этим программам по мере необходимости. Сторонние программы должны соответствовать правилам использования интерфейса данных и поведения приложения. При правильной реализации интерфейс Provider обеспечивает мощное расширение приложений Microsoft.

Начиная с SQL Server 2008 в базе данных реализован интерфейс Provider для шифрования и управления ключами. Он именуется интерфейсом расширенного управления ключами, Extensible Key Management(EKM) Provider. Программное обеспечение EKM Provider выполняет задачи шифрования и управления ключами как расширение базы данных SQL Server. Архитектура EKM Provider открывает дверь для поставщиков управления ключами, расширяя возможности шифрования за счет функций управления ключами шифрования. Общая схема архитектуры EKM показана на рисунке 1.

Рисунок 1. Блок-схема SQL Server EKM Provider

Каждая версия SQL Server начиная с 2008 располагает полноценной архитектурой EKM Provider. Таким образом клиентам Microsoft и поставщикам управления ключами предоставляется стабильный и прогнозируемый интерфейс. Архитектура EKM — шифрование столбцов и базы данных

Архитектура EKM Provider поддерживает два метода шифрования базы данных:

• шифрование на уровне столбцов Cell Level Encryption (CLE);
• прозрачное шифрование данных Transparent Data Encryption (TDE).

Метод шифрования CLE также известен как шифрование на уровне столбцов. Как видно из названия, шифруются данные в столбце таблицы. Когда новая строка вставляется в таблицу или обновляется столбец в строке, база данных SQL Server вызывает программное обеспечение EKM Provider для шифрования. Когда столбец используется из базы данных через SQL SELECT или другую инструкцию, программа EKM Provider вызывается для расшифровки. На программу EKM Provider возлагается ответственность как за шифрование, так и за управление ключами. Для реализации шифрования на уровне столбцов требуются небольшие изменения в определении столбца SQL.

Прозрачное шифрование данных Transparent Data Encryption (TDE) обеспечивает шифрование всей базы данных и связанных файлов журналов. Все таблицы и представления в базе данных шифруются полностью. Данные шифруются и расшифровываются по мере вставки, обновления и извлечения информации пользователями и приложениями. Как видно из названия, для прозрачного шифрования данных не требуется изменений в приложениях, определениях SQL или запросов. База данных безупречно работает после того, как включается шифрование.

Прозрачное шифрование данных — более простой из двух реализуемых методов шифрования. Далее будет показано, когда полезно использовать TDE, а когда предпочтительно шифрование на уровне столбцов.

Активация поставщика EKM

После установки стороннего программного обеспечения поставщика EKM администратор базы данных SQL Server использует консоль управления SQL Server, чтобы активировать ПО поставщика EKM и применить шифрование к базе данных или столбцам. Активация программного обеспечения поставщика EKM приводит к немедленному шифрованию базы данных, и все дальнейшие операции с данными в базе данных будут связаны с вызовом программного обеспечения поставщика EKM.

Microsoft EKM Provider для локально сохраненных ключей шифрования

Учитывая, что некоторые клиенты SQL Server хотели бы шифровать данные, но не располагают ресурсами или временем для внедрения решения по управлению ключами, компания Microsoft предоставляет встроенный поставщик EKM, который выполняет шифрование, но сохраняет ключи локально в контексте SQL Server. Понимая, что это не оптимальный подход к безопасности, разработчики Microsoft рекомендуют клиентам использовать подходящее решение управления ключами шифрования, которое отделяет ключи шифрования от базы данных SQL Server. Это хороший совет: локально сохраненные ключи шифрования могут быть восстановлены киберпреступниками, а использование внешних систем управления ключами обеспечивает более надежную защиту и лучшее соответствие требованиям законодательства.

Программное обеспечение EKM Provider

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

Версии SQL Server, поддерживающие EKM

Поддержка EKM Provider реализована во всех редакциях SQL Server Enterprise, в том числе Data Warehouse и Business Intelligence. EKM Provider не поддерживается в редакциях SQL Server Standard, Web и Express.

Прозрачное шифрование данных

Большинство клиентов Microsoft, реализующих шифрование в SQL Server, используют метод TDE, так как он проще в реализации. Не требуется никаких изменений в программном коде, а для включения шифрования достаточно нескольких команд из консоли SQL Server. Рассмотрим некоторые характеристики реализации TDE.

Шифрование базы данных

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

Риcунок 2. Блок-схема прозрачного шифрования данных SQL Server

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

Защита симметричного ключа

Когда в базе данных SQL Server включено прозрачное шифрование данных, она формирует симметричный ключ и защищает его с помощью программного обеспечения EKM Provider, предоставленного вашим поставщиком управления ключами. Программа EKM Provider передает симметричный ключ серверу ключей, где он шифруется с использованием ассиметричного ключа. Затем зашифрованный ключ базы данных сохраняется локально на диске в контексте SQL Server.

При запуске экземпляра SQL Server база данных SQL Server вызывает программу EKM Provider, чтобы расшифровать симметричный ключ базы данных и задействовать его в операциях шифрования и расшифровки. Расшифрованный ключ базы данных хранится в защищенной памяти и используется базой данных. Зашифрованная версия ключа базы данных остается на диске. В случае аварийного завершения работы системы единственной версией ключа базы данных будет зашифрованная версия на диске.

Запуск экземпляра SQL Server

При нормальной работе SQL Server не происходит вызова программы EKM Provider и, следовательно, обмена данными с внешним диспетчером ключа. При каждом нормальном перезапуске экземпляра базы данных SQL Server программа EKM Provider будет вызываться, чтобы разблокировать ключ базы данных на сервере ключей. Следует отметить, что на программу EKM Provider возлагается обязанность отрабатывать отказы сети и сервера ключей. Собственно SQL Server не видит соединения с решением управления ключами шифрования. Если программа EKM Provider не может получить ключ шифрования, то попытка запуска SQL Server окончится неудачей. Позже мы рассмотрим проблему непрерывности бизнеса более подробно.

Защита журналов базы данных

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

Просмотр таблиц и индексов

Для некоторых операций SQL над индексами базе данных SQL Server требуется видимость всего индекса столбца. Приведу пример инструкции SELECT следующего вида:

SELECT Customer_Name, Customer_Address
FROM Orders WHERE
   Credit_Card=’4111111111111111’;

Чтобы удовлетворить этот запрос SQL, база данных должна просмотреть каждую строку в таблице Orders. В случае с TDE это означает, что столбец Credit_Card должен быть описан в каждой строке. Аналогичные операции с предложением ORDERBY могут привести к просмотрам таблицы или индекса.

Факторы производительности

Алгоритм TDE хорошо оптимизирован для задач шифрования и восстановления данных и успешно применяется в большинстве реализаций баз данных. По оценкам Microsoft, влияние TDE на производительность составляет от 2 до 4%, и, как мы выяснили, эти оценки соответствуют действительности для большинства наших клиентов. Однако клиентам Microsoft SQL Server с очень крупными базами данных SQL Server следует проявлять осторожность при использовании TDE. Убедитесь, что вы ясно понимаете, как TDE повлияет на использование больших таблиц вашими приложениями. Рекомендуется выполнить пробный проект на очень большой базе данных, чтобы в полной мере оценить влияние шифрования на производительность.

Шифрование на уровне столбцов

Шифрование на уровне столбцов (CLE) — термин Microsoft для обозначения шифрования на уровне столбцов. При использовании CLE способ и временные характеристики обращения SQL Server к программе EKM Provider значительно отличаются от прозрачного шифрования данных. Чтобы правильно выбирать, в каких случаях лучше использовать CLE, а когда — TDE, важно понимать эти различия. Рассмотрим некоторые аспекты реализации CLE.

Зашифрованные столбцы

Шифрование CLE выполняется на уровне столбцов в таблице SQL Server (рисунок 3). Только выбранный для шифрования столбец защищается надежным алгоритмом. Вы можете указать более одного столбца в таблицах для CLE, но следует соблюдать осторожность, чтобы шифрование нескольких столбцов не отразилось на производительности. Использование одного метода шифрования для нескольких столбцов может уменьшить влияние на производительность.

Рисунок 3. Увеличение производительности шифрования CLE с помощью запросов SQL

Благодаря шифрованию на уровне столбцов иногда удается уменьшить влияние шифрования на производительность базы данных SQL Server. EKM Provider вызывается только в том случае, когда столбец должен быть зашифрован или расшифрован, поэтому вы можете уменьшить затраты на шифрование, аккуратно реализуя код приложения базы данных. Если запрос SQL не ссылается на зашифрованный столбец, EKM Provider не будет вызываться для расшифровки. В качестве примера, если применить шифрование CLE к столбцу Credit_Card, этот запрос не вызовет EKM Provider для расшифровки, так как номер кредитной карты в результате запроса не возвращается:

SELECT Customer_Number,
   Customer_Name,
Customer_Address FROM Orders ORDERBY
Customer_Name;

Как мы видим, продуманное использование запросов SQL поможет уменьшить необходимость шифровать и расшифровывать данные столбца.

Изменения в приложении SQL

В отличие от прозрачного шифрования, для реализации шифрования на уровне столбцов необходимо внести изменение в инструкцию SQL. Функции SQL Server encryptbykey и decryptbykey применяются к инструкциям SQL. Ниже приведен пример запроса SQL, который расшифровывает столбец с шифрованием CLE:

select encryptbykey(key_guid(‘my_key’),
   ‘Hello
World’);

Реализация CLE требует изменений в приложении, но выгода оправдывает затраченные дополнительные усилия.

Шифрование и извлечение ключей

Программа EKM Provider вызывается для каждого значения столбца при шифровании и расшифровке. Это приводит к большему числу вызовов EKM Provider по сравнению с прозрачным шифрованием данных. Число вызовов EKM Provider может быть весьма велико, поэтому важно, чтобы функции шифрования и управления ключами EKM Provider были оптимизированы для повышения производительности.

Программа EKM Provider от вашего поставщика управления ключами отвечает за шифрование данных. Для соответствия требованиям важно понимать алгоритм шифрования, используемый для защиты данных. Обратите внимание на то, чтобы в программе EKM Provider был реализован такой стандарт, как Advanced Encryption Standard (AES) или другой признанный в отрасли стандарт шифрования. Для защиты неактивных данных широко используются 128- и 256-разрядные алгоритмы AES. Избегайте программ EKM Provider, в которых применяются нестандартные алгоритмы шифрования.

Кэширование ключей шифрования

При развертывании CLE важно, чтобы программа EKM Provider оптимизировала как шифрование, так и управление ключами. Хорошие программы EKM Provider надежно кэшируют симметричный ключ в контексте SQL Server, чтобы не извлекать ключ при каждом вызове (рисунок 4). Получение ключа шифрования из сервера ключей отнимает время, а множество вызовов для извлечения ключа может отразиться на производительности. Безопасное кэширование — важный фактор, определяющий производительность CLE. Использование интерфейса Microsoft Windows Data Protection Application Program Interface (DPAPI) — обычная мера для защиты кэшированных ключей.

Рисунок 4. Повышение производительности CLE с помощью кэширования ключа

Факторы производительности

При правильной реализации шифрования на уровне столбцов можно сократить влияние шифрования на производительность базы данных SQL Server. Для очень больших таблиц с малым числом шифруемых столбцов выигрыш в производительности может быть значительным, особенно если столбец не столь часто используется в приложениях.

Управление ключами шифрования

Самая трудная часть стратегии шифрования — правильно организовать управление ключами шифрования. Если ключи шифрования не защитить, данные подвергаются риску и не удовлетворяют рекомендациям по безопасности и требованиям соответствия нормативным актам. Для клиентов Microsoft SQL Server, которые уже реализовали прозрачное шифрование данных (TDE) или шифрование на уровне столбцов (CLE), самая распространенная причина неудач при прохождении аудита — плохо организованное управление ключами шифрования. Рассмотрим некоторые характеристики хорошо организованного управления ключами шифрования для SQL Server.

Программы EKM Provider

Как уже отмечалось, поставщики управления ключами должны предоставить программу расширенного управления ключами (EKM Provider), которая устанавливается и регистрируется в базе данных SQL Server, включая шифрование TDE или CLE. Программное обеспечение от поставщика управления ключами устанавливается на экземпляре SQL Server и предоставляет службы как шифрования, так и управления ключами. Администратору базы данных SQL Server не нужно участвовать собственно в извлечении ключа шифрования, это делает программа EKM Provider.

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

Защита ключа шифрования при извлечении обычно обеспечивается безопасным сетевым соединением TLS между программой EKM Provider на SQL Server и устройством или виртуальной машиной диспетчера ключей. К реализации управления ключами в EKM Provider предъявляется много критически важных требований, они будут рассмотрены в отдельной статье.

Отраслевые стандарты управления ключами

Системы управления ключами шифрования представляют собой криптографические модули, выполняющие разнообразные функции. Они подпадают под действие стандартов Национального института стандартов и технологии (NIST), и диспетчеры ключей, вероятно, должны соответствовать стандартам NIST. Соответствующий стандарт NIST для управления ключами шифрования — Федеральный стандарт обработки информации 140–2 (FIPS140–2), «Требования безопасности для криптографических модулей». Решения управления ключами, в которых реализованы стандарты FIPS140–2, обеспечивают создание надежных ключей шифрования, защиту этих ключей от порчи или подмены и шифрование, с большой долей вероятности удовлетворяющее криптографическим стандартам NIST.

В дополнение к стандартам для управления ключами шифрования NIST предоставляет поставщикам метод оценки соответствия их решений стандартам. Решения управления ключами шифрования тестируются сертифицированными лабораториями безопасности. Затем эти решения утверждаются непосредственно организацией NIST. NIST публикует списки решений, прошедших испытания FIPS140–2, и клиентам Microsoft SQL Server следует требовать сертификации любого решения управления ключами, используемого для защиты базы данных.

Перенос локально сохраненных ключей в систему управления ключами

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

К счастью, не составляет труда перенести локально сохраненный ключ шифрования в надежное решение управления ключами. При переносе выполняется перемещение средств защиты ключа базы данных SQL Server в решение управления ключами и расшифровывать базу данных не требуется. Ключ базы данных, который был изначально защищен локальными ключами и сертификатами, помещается под защиту диспетчера ключей. После этого на программу EKM Provider вашего поставщика возлагается ответственность за разблокировку ключа базы данных (TDE) или извлечение симметричного ключа для шифрования на уровне столбцов (CLE).

Протокол Oasis KEY Management Interoperability Protocol (KMIP)

Многие клиенты SQL Server спрашивают о стандарте KMIP для интеграции с диспетчерами ключей. KMIP важен по многим причинам, но он неприменим к интерфейсу Microsoft EKM Provider. Интерфейс EKM Provider предоставляет поставщику решения управления ключами возможность выполнять необходимые криптографические функции на сервере ключей. Эти функции не соответствуют операциям и атрибутам KMIP. Рекомендуется развертывать решения управления ключами, соответствующие стандартам KMIP, но это не обязательное требование для шифрования SQL Server.

Реализация EKM Provider

Подготовка программы поставщика расширенного управления ключами (EKM) может состоять из нескольких этапов, в том числе установки программы EKM Provider, настройки параметров шифрования и управления ключами, установки учетных данных для сервера ключей и, конечно, собственно программы EKM Provider. Программа EKM Provider предоставляется поставщиком управления ключами шифрования. В одних случаях это программное обеспечение поставляется за дополнительную плату, в других — бесплатно. В любом случае программа EKM Provider — специфический элемент используемого вами решения управления ключами шифрования.

Установка EKM Provider

Программа EKM Provider отвечает за прямую интеграцию SQL Server с диспетчером ключей и устанавливается на том сервере, где выполняется SQL Server. Различные поставщики по-разному подходят к процессу установки, но чаще всего обычное приложение установки Windows MSI используется для установки программного обеспечения и начальной настройки параметров EKM Provider. В целях гибкости администрирования среды SQL Server в ходе установки программы EKM Provider процесс шифрования обычно не запускается немедленно, но встречаются различные реализации.

Настройка EKM Provider

После установки программы EKM Provider необходимо настроить параметры использования. В их числе могут быть:

• имя узла или IP-адрес сервера ключей;
• имя узла или IP-адрес одного или нескольких серверов ключей для отработки отказа;
• имя защищенного экземпляра SQL Server;
• учетная запись Windows, с которой будет работать программа EKM Provider;
• расположение учетных данных для сервера ключей;
• отпечаток сертификата HSM, используемого для защиты ключа TDE или пароля;
• параметры ведения журнала состояний приложения;
• лицензионный код для EKM Provider;
• возможно, и другие параметры.

Настройка EKM Provider может быть запущена процессом установки из меню Windows или из командной строки. Правильная настройка программы EKM Provider — необходимый первый шаг для активации шифрования SQL Server через панель управления SQL Server.

Установка и защита учетных данных сервера ключей

Защита учетных данных, используемых для доступа к серверу ключей шифрования — решающий элемент вашей стратегии безопасности. Метод, используемый для защиты учетных данных, реализуется в программе EKM Provider и различается у разных поставщиков. Следует внимательно оценить эту стратегию, чтобы надежно защитить учетные данные и сертификаты в контексте SQL Server. Кибервзломщики часто пытаются заполучить учетные данные сервера ключей, чтобы добраться до защищенных данных. Компрометацию учетных данных сервера ключей следует рассматривать как компрометацию защищенных конфиденциальных данных.

Во многих случаях учетные данные для сервера ключей шифрования основываются на сертификатах PKI. Их можно держать в хранилище сертификатов Windows, получив дополнительную защиту и возможность ведения журнала доступа, обеспечиваемую операционной системой Windows. Избегайте хранить сертификаты, пароли и другие учетные данные в пользовательских каталогах или областях, к которым часто обращаются из административных учетных записей Windows.

Библиотеки программ шифрования

Если вы реализовали прозрачное шифрование данных (TDE) SQL Server, то шифрование базы данных выполняется самой программой SQL Server. EKM Provider защищает симметричный ключ шифрования, используемый TDE, но SQL Server выполняет шифрование (обычно по алгоритму AES) с использованием библиотек шифрования Microsoft. При использовании алгоритма AES производительность TDE обычно достаточно высока. Можно применить алгоритм Triple DES (3DES) для прозрачного шифрования данных SQL Server, но я рекомендую избегать его. Производительность AES выше, и можно ожидать, что он дольше будет использоваться в качестве отраслевого стандарта.

При реализации шифрования на уровне столбцов (CLE) SQL Server шифрование выполняется программой EKM Provider, а не SQL Server. Поэтому важно понимать, как поставщик EKM Provider реализовал шифрование и какая библиотека шифрования используется.

Возможные варианты шифрования

• Использовать собственные библиотеки шифрования Windows.NET.
• Задействовать библиотеки шифрования поставщика, соответствующие отраслевым стандартам, таким как AES и 3DES.
• Применять нестандартные библиотеки шифрования поставщика (не рекомендуется).
• Использовать библиотеки шифрования собственной разработки (не рекомендуется и не соответствует требованиям).

Собственные библиотеки шифрования Microsoft.NET отличаются хорошей производительностью, но следует попытаться оценить производительность библиотек шифрования, отличных от Microsoft. Кроме того, следует избегать нестандартных алгоритмов шифрования, чтобы не нарушить требований нормативных актов.

Настройка отработки отказа сервера ключей EKM Provider

При использовании диспетчера ключей шифрования необходимо уделять особое внимание непрерывности бизнеса, в том числе отработке отказов с высоким уровнем доступности. И вновь уровень доступности при отработке отказа зависит от поставщика, но должен учитываться в архитектуре EKM Provider (рисунок 5). Отработка отказа сервера ключей может быть вызвана различными событиями, такими как:

• сбой сети;
• отказ оборудования сервера ключей;
• распределенная атака типа «отказ в обслуживании» (DDoS);
• отказ кластера SQL Server.

Рисунок 5. Настройка EKM Provider для отработки отказа сервера ключей

Отсутствие доступа к серверу ключей приведет к невозможности SQL Server обрабатывать запросы информации, поэтому чрезвычайно важно, чтобы программа EKM Provider автоматически и своевременно реагировала на отказы сети или сервера. Обратите внимание, что для некоторых программ EKM Provider отказ сетевого сегмента или сервера ключей не означает немедленного прерывания работы приложения SQL Server. Например, шифрование SQL Server TDE взаимодействует с сервером ключей при первом запуске SQL Server. Если экземпляр SQL Server остается активным, временный отказ сетевого соединения не нарушит нормального функционирования SQL Server. Аналогично, если EKM Provider обеспечивает безопасное кэширование ключей, возможно, не произойдет прерывания, связанного с шифрованием на уровне столбцов.

Ведение журнала аудита EKM Provider

Журналы доступа для SQL Server и EKM Provider — критический элемент безопасности SQL Server. Все компоненты SQL Server должны формировать журналы использования и доступа, которые могут быть отправлены в коллекцию журналов или сервер SIEM в реальном времени. Программа EKM Provider должна регистрировать все действия на сервере ключей шифрования. Активный мониторинг с помощью решения SIEM — один из лучших способов защиты. Программа EKM Provider должна поддерживать этот метод защиты от угроз.

Устойчивость к сбоям программы EKM Provider

Наконец, программа EKM Provider должна быть как можно более устойчивой к сбоям. Она должна автоматически восстанавливаться в случае перезапуска базы данных SQL Server, отказа соединения с сервером ключей и других неожиданных событий. Не должно быть необходимости в ручном вмешательстве администратора сети Windows или базы данных.

Непрерывность бизнеса

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

Устойчивость оборудования для управления ключами

Существует много разновидностей систем управления ключами, в том числе аппаратные модули безопасности, подключаемые к сети (HSM), виртуальные машины для VMware и Hyper-V, «облачные» экземпляры для Microsoft Azure, Amazon Web Services (AWS), IBM SoftLayer, Google Compute Engine и других «облачных» платформ, а также мультитенантные решения управления ключами, такие как AWS Key Management Service (KMS) и Azure Key Vault.

Если диспетчер ключей развернут как аппаратное решение, в нем должны быть предусмотрены некоторые меры обеспечения устойчивости:

• жесткие диски в массиве RAID;
• жесткие диски с возможностью горячей замены;
• избыточные источники питания;
• независимые сетевые интерфейсы (NIC);
• звуковая сигнализация.

Аппаратная система управления ключами должна обеспечить максимально надежную защиту от типичных отказов оборудования.

Замена или порча ключей

Системы управления ключами хранят ключи шифрования в энергонезависимых хранилищах данных различных типов, в которых ключи подвержены порче из-за атак или аппаратных отказов либо могут быть подменены в результате атаки. В системах управления ключами следует использовать обычные методы обеспечения целостности, например хеш-код проверки подлинности сообщений Hash-based

MessageAuthenticationCode(HMAC) или похожий алгоритм, для определения типа отказа. Если проверка целостности завершается неудачей, ключи шифрования не следует отправлять пользователю или приложению, а все случаи неудачной проверки отмечать в журнале аудита и системном журнале. Дополнительную проверку целостности базы данных ключей и приложения необходимо выполнить, когда диспетчер ключей приступает к обработке. Раннее обнаружение и карантин слабых ключей шифрования поможет предотвратить порчу данных и даст администратору безопасности возможность восстановить корректное функционирование диспетчера ключей.

Зеркальное отображение ключей и политик доступа в реальном времени

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

Зеркальное отображение в реальном времени также должно обеспечивать освобождение от временных отказов сети. Если зеркальное отображение ключей невозможно из-за разрыва соединения между основным и вспомогательным серверами, то средство зеркального отображения ключа должно выполнить автоматическое восстановление и возобновить зеркальное отображение, когда работа сети будет возобновлена. В результате уменьшается вероятность потери ключей из-за задержки зеркального отображения.

Многие компании развертывают сложные распределенные сети, требующие нескольких вспомогательных серверов ключей. В большинстве случаев для управления ключами используются лишь один рабочий и один вспомогательный сервер ключей, но для хорошего зеркального отображения ключей необходимо, чтобы основной сервер ключей отображался на несколько вспомогательных серверов ключей.

Зеркальное отображение ключей в режиме «активный — активный»

Развивая тему зеркального отображения ключей шифрования и политик доступа, отметим важность полной поддержки системами управления ключами операций восстановления системы с переключением ролей, а это подразумевает динамическое изменение ролей между основным и вспомогательным серверами ключей (рисунок 6). Если основной сервер ключей недоступен, то вспомогательный сервер ключей автоматически начинает выполнять различные функции шифрования ключей. В этой ситуации важно, что вспомогательный сервер ключей становится основным сервером ключей на некоторый период времени. Могут быть созданы новые ключи шифрования, также может измениться состояние существующих ключей, как и политики доступа. Хорошая архитектура зеркального отображения ключей допускает эти изменения перед возвратом на первоначальный основной сервер ключей, когда он вновь становится доступным. Это центральная функция реализаций зеркального отображения в режиме «активный — активный».

Рисунок 6. Зеркальное отображение «активный — активный» для отработки отказа сервера ключей

Мониторинг управления ключами

Системы управления ключами — критический элемент инфраструктуры, поэтому важно развернуть инструменты мониторинга, обеспечив высокий уровень обслуживания. Системы управления ключами должны записывать и передавать системные журналы в решение мониторинга, а система управления ключами должна включить мониторинг с использованием внешних приложений мониторинга. Если сервер ключей становится недоступным, необходимо быстро обнаружить сбой.

Ведение журнала и аудит системы управления ключами

Другой важный объект управления ключами для обеспечения непрерывности бизнеса — продуманная система ведения журналов на сервере управления ключами. Системы управления ключами представляют собой мишени для киберпреступников, и с помощью активного мониторинга журналов системы управления ключами можно обнаружить атаку на ее начальном этапе.

Кроме того, системы управления ключами должны выполнять аудит всего управления и использования политик и ключей шифрования. Хорошее решение управления ключами выполняет аудит всех действий с ключами шифрования — от создания до удаления, всех изменений политик доступа к ключу и всех попыток доступа к ключам со стороны пользователей и приложений. Эти журналы аудита должны быть переданы в коллекцию журналов или решение мониторинга SIEM в реальном времени.

Резервное копирование и восстановление в системе управления ключами

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

Системы управления ключами отличаются от традиционных бизнес-приложений одной важной особенностью: резервное копирование ключей шифрования данных должно выполняться отдельно от ключей шифрования ключа. Необходимо иметь возможность резервного копирования ключей шифрования данных автоматически или по требованию, но следует позаботиться об отдельном резервном копировании и восстановлении ключей шифрования ключа. Это основное требование к системам управления ключами.

Рекомендации по управлению ключами

Защита ключей шифрования от потери — самая важная часть стратегии шифрования, и существует хорошая документация по оптимальным подходам к безопасности при управлении ключами шифрования. Рекомендации по безопасности для управления ключами также приводятся во многих нормативных актах, таких как PCI-DSS и другие.

Разделение ключей шифрования и защищаемых ими данных

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

Перечисленные ниже распространенные приемы дают ненадежную защиту для ключей шифрования SQL Server:

• ключи шифрования хранятся в прикладных программах;
• ключи шифрования хранятся в таблице SQL Server;
• ключи шифрования хранятся в папках на локальном или удаленном сервере Windows;
• ключи шифрования хранятся, защищенные паролем;
• ключи шифрования хранятся локально и защищены прозрачным шифрованием данных (TDE) SQL Server.

Отделение ключей шифрования от защищенных данных затрудняет задачу взломщиков и в значительной степени устраняет угрозу потерь из-за замененных жестких дисков, украденных виртуальных машин или «облачных» образов и потерянных архивных образов.

Разделение обязанностей

Разделение обязанностей, Separation of Duties (SOD) — базовый принцип безопасности в финансовых, медицинских и оборонных приложениях (рисунок 7). В контексте защиты конфиденциальных данных разделение обязанностей позволяет снизить случайную и намеренную потерю конфиденциальных данных своими сотрудниками. В применении к информационным системам разделение обязанностей требует, чтобы лица, создающие ключи шифрования и управляющие ими, не имели доступа к конфиденциальным данным, а те, кто управляет базами данных (администраторы баз данных), не имели доступа к ключам шифрования.

Рисунок 7. Разделение обязанностей

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

Двойной контроль

В рекомендациях NIST для управления ключами роль управления ключами шифрования определена как критически важная часть стратегии безопасности. В системах управления ключами шифрования должен быть предусмотрен двойной контроль. Это означает, что два или более администраторов безопасности перед выполнением какой-либо работы должны пройти проверку подлинности на сервере ключей (рисунок 8). Требование кворума администраторов безопасности для аутентификации снижает вероятность нанесения ущерба или кражи критически важной информации и ключей шифрования персоналом внутри компании.

Рисунок 8. Двойной контроль

Разделение знаний

Поскольку невозможно переоценить важность ключей шифрования для безопасности защищенных данных, эта рекомендация предусматривает, что ни один человек не видит ключа шифрования и не владеет им явным образом. В современных системах управления ключами шифрования эта угроза уменьшается благодаря запрету на экспорт и показ ключей шифрования администраторам и пользователям и отказу от использования паролей в процессе создания ключа (рисунок 9). Если вы используете систему управления ключами, которая создает или экспортирует ключи на основе пароля или явно показывает ключи шифрования администраторам и пользователям, то следует применять управление с разделением знаний.

Рисунок 9. Разделение знаний

SQL Server защищает ключи прозрачного шифрования данных, никогда не сохраняя их в явном виде в экземпляре SQL Server.

Минимальное количество администраторов ключей

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

Многофакторная проверка подлинности

Как любой критический компонент информационной системы управления, системы управления ключами шифрования должны располагать многофакторной (иногда именуемой двухфакторной) проверкой подлинности, чтобы уменьшить вероятность кражи административных учетных данных. Киберпреступники используют несколько методов перехвата важных административных учетных данных, в том числе фишинг, приемы социальной инженерии, memory scraping и т. д. Многофакторная проверка подлинности — важное средство защиты, рекомендуемое для применения в системах управления ключами шифрования.

Физическая безопасность

Элементы физической безопасности также играют важную роль в управлении ключами шифрования, приложениями и устройствами обеспечения безопасности. Среди физических элементов центра обработки данных — замки в серверных комнатах, запираемые шкафы и стойки, видеомониторинг и другие средства. Обеспечить физическую защиту аппаратных модулей управления ключами (HSM) довольно просто, но необходимо и физически контролировать виртуальные среды VMware или Hyper-V, а также «облачные» среды. В «облачных» средах приходится работать с поставщиками «облачных» служб, чтобы надежно защитить виртуальные экземпляры сервера управления ключами.

Замена ключей шифрования данных

Также рекомендуется периодическая замена ключей шифрования данных, обязательная в соответствии с некоторыми нормативными актами, например PCI-DSS. Этот процесс называется сменой ключей (key rotation или key rollover). Ваша система управления ключами может быть полезной, так как позволяет указать криптопериод ключа и автоматически меняет ключ. Конечно, необходимо сохранить старый ключ, чтобы можно было расшифровать данные. Смена ключей шифрования и повторное шифрование конфиденциальных данных — рекомендуемая мера обеспечения безопасности.

Смена ключа шифрования ключей

В правильно организованных системах управления ключами ключи шифрования данных (DEK) защищены отдельными ключами шифрования ключей (KEK). Ключи шифрования ключей используются только для защиты DEK и никогда напрямую для защиты конфиденциальных данных. Ключи шифрования ключей располагаются только в системе управления ключами и не должны покидать эту систему, кроме как будучи частью защищенной резервной копии. Смена KEK происходит, как правило, реже, чем смена DEK, но должна производиться в рамках системы управления ключами.

Проверка подлинности администратора и пользователя

Системы управления ключами предназначены для того, чтобы создавать надежные ключи шифрования и защищать их. Конечно, они должны также позволять использовать ключи шифрования для защиты конфиденциальных данных. Система управления ключами должна обеспечить надежную проверку подлинности для доступа к серверу ключей, а также предусматривать проверку подлинности для использования конкретных ключей шифрования. Обычно это делается с помощью инфраструктуры PKI и взаимной проверки подлинности между клиентами и серверами. Такой подход шире типичной проверки подлинности, которая используется в веб-браузере c безопасным сеансом. Система управления ключами должна обеспечить согласование безопасного сеанса с известным и доверенным клиентом. Для этого большинство систем управления ключами содержит частный центр сертификации и не полагается на общедоступные центры сертификации, чтобы обеспечить высший уровень доверия при проверке подлинности.

Сетевая сегментация

Для критических систем безопасности рекомендуется использовать сетевую сегментацию систем управления ключами и приложениями, которые обращаются к системам управления ключами. Сетевая сегментация достигается через обычную ИТ-инфраструктуру, через управление виртуальной сетью, реализованное в VMware, и на «облачных» платформах с использованием правил сетевой сегментации поставщика «облачных» служб. Дополнительные средства управления сетевым доступом часто можно реализовать в системе управления ключами с помощью правил брандмауэра.

Аудит и ведение журнала

Наконец, все устройства безопасности, в том числе системы управления ключами, должны собирать и передавать журналы аудита и системные журналы на сервер коллекции журналов или решение мониторинга SIEM. Активный мониторинг критически важных приложений и систем безопасности — важный элемент безопасности и рекомендуемый подход. Системы управления ключами должны полностью поддерживать активный мониторинг.

В целом рекомендации по безопасности для систем управления ключами, используемых для защиты данных SQL Server, должны отражать понятные и документированные указания для устройств безопасности. Основной источник рекомендаций — документ Special Publication 800–57, Recommendation for Key Management, подготовленный Национальным институтом стандартов и технологии США. Эти рекомендации должны быть реализованы в вашем решении управления ключами для SQL Server.