SQL Server 2016 Always Encrypted: легко внедрить, сложно взломать

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

Стандартный подход к обеспечению безопасности заключается в шифровании данных на сервере и использовании протокола HTTPS с поддержкой SSL для защиты данных при транспортировке. Однако что, если бы мы могли еще больше повысить уровень безопасности, используя HTTPS и отправляя данные в зашифрованном формате по линии связи только для расшифровки данных на клиентах, имеющих действительные сертификаты? Такой подход значительно усложнил бы традиционную атаку «человек посередине» (MITM).

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

В этой статье описывается, как настроить и использовать Always Encrypted, и ее рекомендуется прочитать всем, кто отправляет важные данные по общедоступным линиям связи, даже если они защищены с помощью SSL.

Концепция Always Encrypted

Always Encrypted — это технология шифрования на стороне клиента, которую Microsoft представила в SQL Server 2016. Always Encrypted обеспечивает автоматическое шифрование данных не только при записи, но и при чтении утвержденным приложением. В отличие от прозрачного шифрования данных, которое шифрует данные и файлы журнала на диске в режиме реального времени, но позволяет считывать данные любым приложением, запрашивающим данные, Always Encrypted требует, чтобы ваше клиентское приложение использовало драйвер с поддержкой Always Encrypted для связи с база данных. С помощью этого драйвера приложение безопасно передает зашифрованные данные в базу данных, которые впоследствии могут быть расшифрованы только приложением, имеющим доступ к ключу шифрования. Любое другое приложение, запрашивающее данные, также может получить зашифрованные значения, но это приложение не может использовать данные без ключа шифрования, что делает данные бесполезными. Из-за этой архитектуры шифрования экземпляр SQL Server никогда не видит незашифрованную версию данных.

В настоящее время единственными драйверами с поддержкой Always Encrypted являются поставщик данных .NET Framework для SQL Server, для которого требуется установка .NET Framework версии 4.6 на клиентском компьютере и драйвер JDBC 6.0. Вероятно, со временем это изменится, но это официальные требования Always Encrypted по состоянию на апрель 2017 года.

Но зачем нам эта технология? Есть несколько веских причин, по которым следует использовать Always Encrypted:

• Безопасность . Данные всегда должны быть в безопасности. Теперь, когда SSL скомпрометирован, Always Encrypted заполняет пробел еще одним уровнем защиты транспортного конвейера.
• Регуляторная поддержка — данные должны быть зашифрованы и защищены от посторонних глаз администраторов баз данных в соответствии со все большим количеством отраслевых норм, в первую очередь в финансовой и телекоммуникационной отраслях. Это описано в стандарте PII («Информация, позволяющая установить личность»), в которой говорится, что такие вещи, как номера кредитных карт, номера социального страхования, имена и адреса, должны быть защищены, иначе владелец данных может быть серьезно наказан.

Как использовать постоянное шифрование

Использование Always Encrypted требует небольшой подготовки на сервере базы данных, на котором хранятся зашифрованные таблицы. Подготовка состоит из двух этапов:

• Создайте определение главного ключа столбца
• Создайте ключ шифрования столбца

Главный ключ столбца

Итак, что такое главный ключ столбца?

Главный ключ столбца — это сертификат, хранящийся в хранилище сертификатов Windows (используется в демо-версии как вариант хранения сертификата), сторонний аппаратный модуль безопасности (общее название сторонних решений для установки, управления и использования сертификаты) или Azure Key Vault (облачное решение Microsoft для управления сертификатами).

Приложение, которое шифрует данные, использует главный ключ столбца для защиты различных ключей шифрования столбцов, которые обрабатывают шифрование данных в столбцах таблицы базы данных. Использование хранилищ сертификатов из SQL Server, которые иногда называют Enterprise Key Manager , требует использования SQL Server Enterprise Edition.

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

Вы можете создать определение главного ключа столбца с помощью графического интерфейса в среде SQL Server Management Studio (SSMS) или с помощью T-SQL. В SSMS подключитесь к экземпляру базы данных SQL Server 2016, в котором вы хотите использовать Always Encrypted для защиты таблицы базы данных.

Создание и использование главных ключей столбцов

В обозревателе объектов перейдите сначала к базе данных, затем к Security, а затем разверните папку Always Encrypted Keys, чтобы отобразить две ее подпапки, как показано на следующих рисунках:

Чтобы создать главный ключ столбца, щелкните правой кнопкой мыши папку Column Master Keys и выберите New Column Master Key . В диалоговом окне New Column Master Key столбца введите имя главного ключа столбца, укажите, следует ли хранить ключ в хранилище сертификатов текущего пользователя или локального компьютера или в хранилище ключей Azure, а затем выберите сертификат в списке. Если сертификатов нет или вы хотите использовать новый самозаверяющий сертификат, нажмите кнопку « Generate Certificate », а затем нажмите « OK ». На этом шаге создается самозаверяющий сертификат и загружается в хранилище сертификатов текущей учетной записи пользователя, на которой работает SSMS.

Примечание. Эти действия следует выполнять на доверенном компьютере, а не на компьютере, на котором размещен экземпляр SQL Server. Таким образом, данные остаются защищенными в SQL Server, даже если хост-компьютер скомпрометирован.

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

Инструкции по экспорту и импорту сертификатов для вашей операционной системы можно найти по следующим URL-адресам:

• Экспорт сертификатов
  • Windows 7 и Windows Server 2008 R2
  • Windows 8 и Windows Server 2012
  • Windows 8.1 и Windows Server 2012 R2
  • Windows 10 и Windows Server 2016
• Импорт сертификатов
  • Windows 7 и Windows Server 2008 R2
  • Windows 8 и Windows Server 2012
  • Windows 8.1 и Windows Server 2012 R2
  • Windows 10 и Windows Server 2016

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

Ключ шифрования столбца

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

Чтобы создать ключ шифрования столбца, с помощью Object Explorer подключитесь к экземпляру базы данных, перейдите к базе данных, затем к Security и разверните папку Always Encrypted Keys . Щелкните правой кнопкой мыши Column Encryption Keys и выберите New Column Encryption Key . В диалоговом окне « New Column Encryption Key » введите имя нового ключа шифрования, выберите « Column Master Key Definition » в раскрывающемся списке и нажмите « OK ». Теперь вы можете использовать ключ шифрования столбца в определении новой таблицы.

Создание таблицы с зашифрованными значениями

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

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

Типы шифрования SQL Server 2016

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

Во-первых, будет ли этот столбец использоваться для поиска значений или просто для возврата этих значений?

Если столбец будет использоваться для поиска, столбец должен использовать тип детерминированного шифрования , который допускает операции равенства. Однако существуют ограничения на поиск данных, зашифрованных с помощью функции Always Encrypted . SQL Server 2016 поддерживает только операции равенства, которые включают в себя « equal to », not equal to », joins (которые используют равенство) и используют значение в предложении GROUP BY . Любой поиск с использованием LIKE не поддерживается. Кроме того, сортировка данных, зашифрованных с помощью Always Encrypted , должна выполняться на уровне приложения, поскольку SQL Server будет сортировать на основе зашифрованного значения, а не расшифрованного.

Если столбец не будет использоваться для поиска записей, в нем следует использовать рандомизированный тип шифрования. Этот тип шифрования более надежен, но он не поддерживает операции поиска, объединения или группировки.

Создание таблицы с зашифрованными столбцами

При создании таблиц вы используете обычный синтаксис CREATE TABLE с некоторыми дополнительными параметрами в определении столбца. В синтаксисе ENCRYPTED WITH для оператора CREATE TABLE используются три параметра.

Первым из них является параметр ENCRYPTION_TYPE , который принимает значение RANDOMIZED или DETERMINISTIC . Второй — это параметр ALGORITHM , который принимает только значение RAEAD_AES_256_CBC_HMAC_SHA_256 . Третий параметр — это COLUMN_ENCRYPTION_KEY , который является ключом шифрования, который вы используете для шифрования значения.

 CREATE TABLE [dbo].[Customers] ( [CustomerId] [int] IDENTITY(1,1), [TaxId] [varchar](11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL, [FirstName] [nvarchar](50) NULL, [LastName] [nvarchar](50) NULL, [MiddleName] [nvarchar](50) NULL, [Address1] [nvarchar](50) NULL, [Address2] [nvarchar](50) NULL, [Address3] [nvarchar](50) NULL, [City] [nvarchar](50) NULL, [PostalCode] [nvarchar](10) NULL, [State] [char](2) NULL, [BirthDate] [date] ENCRYPTED WITH (ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL PRIMARY KEY CLUSTERED ([CustomerId] ASC) ON [PRIMARY] ); GO

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

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

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

Всегда зашифрованная производительность

Производительность всегда является ключевым фактором, особенно в этом случае, когда мы добавляем накладные расходы на шифрование к обычному трафику базы данных. Лучшим сайтом для тестирования производительности является SQL Performance, на котором проверялось выполнение запросов и использование диска в различных сценариях:

Поскольку при процессах шифрования и дешифрования необходимо выполнять работу ЦП и жесткого диска, очевидно, что это влияет на объем используемого дискового пространства и продолжительность запросов. Поскольку это влияет на вашу среду — ЦП, ОЗУ и характеристики диска — вам следует проверить, не создаст ли это проблему в рабочей среде.

Примечание. Если вы хотите узнать больше об оптимизации производительности Microsoft SQL Server, ознакомьтесь с одной из наших предыдущих статей «Как настроить Microsoft SQL Server для повышения производительности».

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

Что нужно сделать, чтобы правильно внедрить Always Encrypted в устаревший код?

Одна из приятных особенностей функции Always Encrypted в SQL Server 2016 заключается в том, что приложения, уже использующие хранимые процедуры, ORM или параметризованные команды T-SQL, не должны требовать никаких изменений приложения для использования Always Encrypted, если только уже не используются операции, не связанные с равенством. Приложения, которые строят операторы SQL как динамический SQL в приложении и выполняют эти команды непосредственно в базе данных, должны быть изменены, чтобы использовать параметризацию своих запросов, рекомендуемую передовую практику безопасности для всех приложений, прежде чем они смогут воспользоваться преимуществами функции Always Encrypted.

Еще одним изменением, необходимым для работы Always Encrypted, является добавление атрибута строки подключения к строке подключения приложения, подключающегося к базе данных: Column Encryption Setting=enabled .

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

Следовательно, .NET Framework предоставляет новый метод для объекта SqlConnection с именем SqlCommandColumnEncryptionSetting , который имеет три возможных значения:

• Disabled — столбцы или параметры Always Encrypted, которые можно использовать для запросов, выполняемых с помощью этого объекта соединения, отсутствуют.
• Enabled — столбцы и/или параметры Always Encrypted используются для запросов, которые выполняются с использованием этого объекта соединения.
• ResultSet — параметры Always Encrypted отсутствуют. Однако выполнение запросов с использованием этого объекта подключения возвращает столбцы, зашифрованные с помощью Always Encrypted.

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

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

Всегда ли шифрование стоит усилий?

Краткий ответ? Определенно да!

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

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

Однако, если только они не являются препятствием для вашей среды и у вас есть приложение, которое распространяется за пределами внутренней сети вашей компании, практически нет причин не использовать Always Encrypted.