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

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

Важно отметить, что в мире действуют различные отраслевые стандарты. Мы остановимся в первую очередь на стандартах, опубликованных Национальным институтом стандартов и технологий (NIST) США, но важно понимать, что в данной области работают и другие организации по стандартам, такие как Международная организация по стандартизации (ISO) и Американский национальный институт стандартов (ANSI). Между опубликованными стандартами существуют некоторые различия, но во многом они взаимосвязаны и пересекаются. Мы сосредоточимся на стандартах, общих для различных органов по стандартизации, поскольку многим компаниям необходимо соответствовать разнообразным международным стандартам.

Стандарты шифрования

В 2001 году Национальный институт стандартов и технологий работал с международной группой специалистов по криптографии и безопасности. Все вместе они оценили алгоритмы шифрования и в итоге остановились на алгоритме Rijndael («Рэндал») в качестве стандарта AES. На сегодня AES также принят ISO и другими международными организациями стандартизации. Институт NIST опубликовал этот стандарт как Federal Information Processing Standard 197, или FIPS-197.

AES — предпочтительный вариант для шифрования неактивных данных. Он представляет собой часть широко применяемых интернет-протоколов, в которых операции с асимметричным ключом сочетаются с операциями с симметричным ключом. AES — симметричный блочный шифр, в котором используются 128-разрядные блоки и поддерживаются ключи различных размеров (128, 192 и 256 разрядов). В большинстве новых реализаций алгоритма AES применяются 256-разрядные ключи для более надежной защиты.

Пользователям Microsoft SQL Server следует выбрать алгоритм AES при шифровании баз данных SQL Server методами TDE и CLE. Существуют и другие стандартные методы, такие как Triple DES, однако для лучшего соответствия требованиям рекомендуется использовать AES.

Стандарты для диспетчера ключей шифрования

NIST именует системы управления ключами шифрования «криптографическими модулями» и применяет к ним федеральный стандарт обработки информации 140-2 (FIPS140-2, Security Requirements for Cryptographic Modules). Помимо продвижения этого стандарта NIST предоставляет программы сертификации и оценки через добровольную аккредитацию лабораторий National Voluntary Laboratory Accreditation Program (NVLAP). Это означает, что системы управления ключами шифрования могут быть формально сертифицированы на соответствие стандарту FIPS140-2. Все профессиональные системы управления ключами оценены в рамках программы NVLAP, и пользователям Microsoft SQL Server следует ориентироваться на этот уровень соответствия.

Системы управления ключами шифрования могут оцениваться по стандарту FIPS140-2, но из этого автоматически не следует, что поставщик программного обеспечения с решением TDE для SQL Server также использует проверенный сервер ключей. Обязательно обратитесь на сайт NIST, чтобы убедиться в соответствии поставщика решений управления ключами стандарту FIPS140-2.

Стандарты для безопасных интерфейсов управления ключами

Проверка NIST FIPS140-2 сервера ключей свидетельствует о соответствии важному отраслевому стандарту криптографии, но она не информирует о том, как клиентские приложения обмениваются данными и взаимодействуют с сервером ключей. Протокол KMIP (Key Management Interoperability Protocol) обеспечивает стандарт такого интерфейса. Протокол KMIP продвигается через группу стандартизации OASIS в техническом комитете KMIP.

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

Спецификация EKM (Extensible Key Management) Microsoft SQL Server появилась раньше стандарта KMIP и не реализует этот стандарт. Реализация интерфейса с системой управления ключами — обязанность каждого поставщика решений управления ключами. Однако KMIP важен для пользователей SQL Server, поскольку другим службам базы данных и приложений, возможно, потребуются службы управления ключами.

Стандарты для безопасных соединений управления ключами

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

  • библиотеки программного обеспечения, предоставляемые поставщиками;
  • безопасное соединение TLS.

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

Протокол OASIS KMIP определяет безопасный интерфейс TLS с диспетчером ключей, для которого не требуется библиотек программного обеспечения от поставщика. Вместо этого система на стороне клиента использует стандартный для Интернета протокол TLS, чтобы установить безопасное соединение. Иногда такое соединение называют управляемым без агента. На сегодня почти все профессиональные системы управления ключами совместимы с протоколом KMIP и используют для этого соединения безопасный сеанс TLS, управляемый без агента.

Пользователи Microsoft SQL Server, применяющие прозрачное шифрование данных (TDE) или шифрование на уровне столбцов (CLE), зависят от библиотек ПО, предоставляемых поставщиком управления ключами. Интерфейс SQL Server появился раньше, чем спецификация KMIP. Обратите внимание, что в решении от поставщика также может использоваться безопасный интерфейс TLS с диспетчером ключей.

Резюме по стандартам SQL Server

Пользователям Microsoft SQL Ser­ver рекомендуется задействовать стандартные методы шифрования и системы управления ключами, соответствующие отраслевым стандартам. Под этим подразумевается использование стандартного алгоритма AES для шифрования TDE или CLE, а также решения для управления ключами шифрования, соответствующего стандартам FIPS140-2 и KMIP. Реализация шифрования и управления ключами на основе отраслевых стандартов обеспечивает соответствие широко применяемым отраслевым нормативным актам.

Поддержка платформы

Пользователи Microsoft SQL Server часто запускают приложения в сложных средах, охватывающих локальный центр обработки данных, платформы размещения, центры обработки данных VMware, «облачную» базу данных SQL Server как службу и полноценные «облачные» платформы инфраструктуры как службы. Гибридные комбинации этих платформ скорее правило, чем исключение, и это увеличивает сложность ИТ-стратегии. В случае с шифрованием SQL Server важно понимать, где реализована поддержка сервера базы данных, а где — серверы управления ключами шифрования.

Хрупкость традиционной модели

В условиях массового перехода на виртуальные центры обработки данных с использованием VMware и других технологий виртуализации в традиционных пользовательских центрах обработки данных по-прежнему размещаются многочисленные приложения SQL Server. Некоторые из них обрабатывают конфиденциальные данные, которые компании не желают публиковать в Интернете, или важные объекты интеллектуальной собственности, которые не должны покидать центр обработки данных, чтобы соответствовать правительственным требованиям, или приложения, пока не перенесенные на виртуальные или «облачные» платформы. Независимо от причин размещения приложений SQL Server в центре обработки данных, стратегия шифрования должна соответствовать особенностям этой среды. Во многих отношениях это самая удобная среда для развертывания шифрования и управления ключами SQL Server. Почти все поставщики решений управления ключами шифрования для SQL Server поддерживают традиционное развертывание центра обработки данных.

Локальная инфраструктура VMware

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

Первая трудность — обеспечить поддержку поставщиком шифрования SQL Server на сервере Windows в виртуальной среде VMware. Не все поставщики решений TDE и CLE для SQL Server поддерживают среду VMware и наиболее распространенные версии VMware.

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

Хостируемая инфраструктура VMware

Несколько поставщиков услуг хостинга и поставщиков «облачных» служб поддерживают полное развертывание VMware. В первую очередь можно вспомнить Rackspace и IBM SoftLayer, но в этой области действует и много других поставщиков услуг. Они предлагают полный набор приложений VMware как часть развертывания, и этот способ может быть привлекательным для пользователей SQL Server, желающих заменить локальную инфраструктуру VMware «облачной». В большинстве случаев локальная инфраструктура VMware может быть реплицирована в размещенной среде. Это означает, что решения шифрования SQL Server и управления ключами также легко переместить.

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

«Облако» (AWS, AZURE и др.)

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

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

У пользователей версии Enterprise возникают еще более серьезные трудности при управлении ключами шифрования для SQL Server. «Облачные» платформы не всегда располагают гибкими функциями управления ключами шифрования, и проблема сохранности ключей (имеет ли поставщик «облачных» услуг доступ к ключам шифрования) может быть очень сложной. Почти во всех случаях служба управления ключами, предоставляемая «облачной» платформой, доступна логически или физически сотрудникам поставщика «облачных» служб. Обязательно убедитесь, что выбранное вами решение управления ключами в «облаке» соответствует требованиям нормативных актов, подходам к администрированию и управлению рисками.

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

Гибридный вариант

Как отмечалось выше, пользователям SQL Server Enterprise обычно свойственно сочетание локальных и размещенных или «облачных» приложений. Этим приложениям часто необходимо интегрировать обмен данными. Не составляет особого труда реализовать шифрование SQL Server на любой из перечисленных выше платформ, но безупречная интеграция управления ключами на разных платформах может оказаться сложной задачей. Интерфейсы традиционных аппаратных модулей безопасности часто отличаются от большинства более современных виртуальных или «облачных» диспетчеров ключей. В таких случаях очень трудно автоматизировать общий доступ к ключам и политикам доступа к ключам. Кроме того, порой невозможно реализовать функции непрерывности бизнеса, такие как резервное копирование/восстановление и отработка отказа. Полезно убедиться, что поставщик средств управления ключами может легко интегрировать разнородные платформы.

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

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

Большинство пользователей SQL Server вполне обоснованно перешли к виртуальным центрам обработки данных с использованием технологий VMware.

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

Лицензирование

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

Документация

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

Обучение

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

Поддержка клиентов

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

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