Шифрование в SQL Server

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Шифрование в SQL Server- использование технологии шифрования для преобразования информации, хранящейся в базе данных (БД), в шифротекст, что делает её прочтение невозможным для лиц, не обладающих ключами шифрования. В SQL Server можно шифровать соединения, данные и хранимые процедуры. Шифрование[1] — это способ сокрытия исходного смысла сообщения или другого документа, обеспечивающей искажение его первоначального содержимого. Преобразование обычного, понятного содержимого в код называется кодированием. При этом подразумевается, что имеется взаимное однозначное соответствие между символами текста и кода — в этом и заключается основополагающее отличие кодирования от шифрования. Часто кодирование и шифрование ошибочно принимают за одно и тоже, забыв о том, что для восстановления закодированного сообщения, достаточно знать правило замены, в то время как для расшифровки уже зашифрованного сообщения помимо знания правил шифрования, требуется ключ к шифру. Под ключом в данном случае подразумевается конкретное секретное состояние параметров алгоритмов шифрования и дешифрования[2].

Иерархия шифрования[править | править код]

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

Каждый уровень иерархии шифрования шифрует слой под ним и отображает наиболее распространенные конфигурации шифрования. Доступ к началу иерархии обычно защищен паролем[4] .


Так же стоит учитывать следующие принципы[5]:

  • Для лучшей производительности шифруйте данные с помощью симметричных ключей вместо сертификатов или асимметричных ключей.
  • Главные ключи базы данных защищены главным ключом службы[6]. Главный ключ службы создается программой установки SQL Server и шифруется с помощью API защиты данных Windows (DPAPI)
  • Возможны и другие иерархии шифрования, устанавливающие дополнительные слои.
  • Модуль Extensible Key Management (EKM[3]) содержит симметричные или асимметричные ключи вне SQL Server.
  • Прозрачное шифрование данных (TDE[7]) должно использовать симметричный ключ, называемый ключом шифрования базы данных, который защищен либо сертификатом, защищенным главным ключом базы данных master database, либо асимметричным ключом, хранящимся в EKM.
  • Главный ключ службы и все главные ключи базы данных являются симметричными ключами.

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

Функции Transact-SQL[править | править код]

Отдельные элементы могут быть зашифрованы при вставке или обновлении с использованием функций Transact-SQL.[8]

Асимметричные ключи[править | править код]

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

Симметричные ключи[править | править код]

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

Сертификаты[править | править код]

Сертификат открытого ключа, обычно называемый сертификатом, является оператором с цифровой подписью, который связывает значение открытого ключа с личностью человека, устройства или службы, которая содержит соответствующий закрытый ключ. Сертификаты выдаются и подписываются центром сертификации (ЦС). Объект, который получает сертификат от ЦС, является субъектом этого сертификата[2] . Как правило, сертификаты содержат следующую информацию:

  • Открытый ключ субъекта
  • Идентификационные данные субъекта, такие как имя и адрес электронной почты
  • Время, в течение которого сертификат считается действительным
  • Информация об эмитенте.
  • Цифровая подпись эмитента.

Основное преимущество сертификатов заключается в том, что они освобождают хосты от необходимости поддерживать набор паролей для отдельных субъектов. Вместо этого хост просто устанавливает доверие к эмитенту сертификата, который затем может подписать неограниченное количество сертификатов. Когда хост, такой как защищенный веб-сервер, назначает эмитента доверенным корневым органом, хост неявно доверяет политикам, которые эмитент использовал для установления привязок сертификатов, которые он выдает. По сути, хост доверяет тому, что эмитент проверил идентичность субъекта сертификата.[4] Хост назначает эмитента в качестве доверенного корневого центра, помещая самозаверяющий сертификат эмитента, который содержит открытый ключ эмитента, в хранилище сертификатов доверенного корневого центра сертификации на главном компьютере. Промежуточные или подчиненные центры сертификации являются доверенными, только если они имеют действительный путь сертификации от доверенного корневого центра сертификации. Самозаверяющие сертификаты, созданные SQL Server, соответствуют стандарту X.509 и поддерживают поля X.509 v1.[2]

Прозрачное шифрование данных (TDE)[править | править код]

Прозрачное шифрование данных (TDE)[7] шифрует файлы данных SQL Server, базы данных SQL Azure и Azure Synapse Analytics (SQL DW), известные как шифрование данных в состоянии покоя. Для обеспечения безопасности базы данных можно принять ряд мер предосторожности, таких как разработка защищенной системы, шифрование конфиденциальных ресурсов и создание брандмауэра вокруг серверов баз данных. Однако в случае кражи физического носителя злоумышленник может просто восстановить или присоединить базу данных и просмотреть её. Одним из решений является шифрование конфиденциальных данных в базе и защита ключей, используемых для шифрования с помощью сертификата. Это не позволяет никому без ключей использовать данные, но этот вид защиты должен быть запланирован заранее.[2]

Реализация Microsoft[править | править код]

TDE выполняет шифрование и расшифровку данных и файлов журналов в режиме реального времени.[7] При шифровании используется ключ шифрования базы данных (DEK), который хранится в загрузочной записи базы данных для обеспечения доступности во время восстановления. DEK — это симметричный ключ, защищенный с помощью сертификата, хранящегося в главной базе данных сервера, или асимметричного ключа, защищенного модулем EKM. TDE защищает данные «в состоянии покоя», то есть данные и файлы журналов. Это дает возможность соблюдать многие законы, правила и руководящие принципы, установленные в различных отраслях промышленности. Так же позволяет разработчикам ПО шифровать данные с использованием алгоритмов шифрования AES и 3DES без изменения существующих приложений.

Реализация Oracle[править | править код]

TDE применяется для файлов БД на уровне столбцов. Для таблицы, содержащей выбранные к шифрованию столбцы, создаётся симметричный ключ шифрования, защищённый главным ключом, который хранится в безопасном месте за пределами БД, называемом бумажником (англ. Wallet). Зашифрованные ключи таблиц содержатся в словаре данных (англ. Data Dictionary)[10].

Выбор алгоритма шифрования[править | править код]

Шифрование является одним из нескольких способов защиты, доступных администратору. Алгоритмы шифрования определяют преобразования данных, которые не могут быть легко отменены неавторизованными пользователями. SQL Server позволяет администраторам и разработчикам выбирать один из нескольких алгоритмов, включая DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES и 256-bit AES. При выборе алгоритма шифрования следует учитывать следующие принципы[11] :

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

Разъяснения относительно алгоритмов DES: DESX был неправильно назван. Симметричные ключи, созданные с помощью ALGORITHM = DESX, фактически используют шифр TRIPLE DES с 192-битным ключом. Алгоритм DESX не предусмотрен. Эта функция находится в режиме обслуживания и может быть удалена в будущей версии Microsoft SQL Server. Избегайте использования этой функции в новых разработках и планируйте модифицировать приложения, которые в настоящее время используют эту функцию. Симметричные ключи, созданные с помощью ALGORITHM = TRIPLE_DES_3KEY, используют TRIPLE DES с 192-битным ключом. Симметричные ключи, созданные с ALGORITHM = TRIPLE_DES, используют TRIPLE DES с 128-битным ключом.[4]

Ключи шифрования базы данных[править | править код]

В SQL Server ключи шифрования включают в себя сочетание открытых, закрытых и симметричных ключей, которые используются для защиты конфиденциальных данных.[5] Симметричный ключ создается во время инициализации SQL Server при первом запуске экземпляра SQL Server. Ключ используется SQL Server для шифрования конфиденциальных данных, хранящихся в SQL Server. Открытый и закрытый ключи создаются операционной системой и используются для защиты симметричного ключа. Пара открытого и закрытого ключей создается для каждого экземпляра SQL Server, который хранит конфиденциальные данные в базе данных. SQL Server имеет два основных приложения для ключей: главный ключ службы (SMK), созданный на экземпляре SQL Server и для него, и главный ключ базы данных (DMK), используемый для базы данных.[4]

Главный ключ службы (SMK)[править | править код]

Главный ключ службы[6] является корнем иерархии шифрования SQL Server. SMK генерируется автоматически при первом запуске экземпляра SQL Server и используется для шифрования пароля связанного сервера, учётных данных и главного ключа базы данных. SMK шифруется с помощью ключа локального компьютера с помощью API защиты данных Windows (DPAPI). DPAPI использует ключ, полученный из учётных данных Windows, учётной записи службы SQL Server и учётных данных компьютера. Главный ключ службы может быть расшифрован только учётной записью службы, под которой он был создан, или участником, имеющим доступ к учётным данным компьютера. Главный ключ службы может быть открыт только той учётной записью службы Windows, под которой он был создан, или принципалом, имеющим доступ как к имени учётной записи службы, так и к её паролю.[4] SQL Server использует алгоритм шифрования AES для защиты главного ключа службы (SMK) и главного ключа базы данных (DMK). AES — более новый алгоритм шифрования, чем 3DES, используемый в более ранних версиях.

Главный ключ базы данных (DMK)[править | править код]

Главный ключ базы данных [6] — это симметричный ключ, который используется для защиты закрытых ключей сертификатов и асимметричных ключей, присутствующих в базе данных. Он также может использоваться для шифрования данных, но имеет ограничения по длине, которые делают его менее практичным для данных, чем использование симметричного ключа. Чтобы включить автоматическое дешифрование главного ключа базы данных, копия ключа шифруется с помощью SMK. Он хранится как в базе данных, в которой он используется, так и в базе данных главной системы. Копия DMK, хранящаяся в базе данных главной системы, автоматически обновляется при каждом изменении DMK.[2] Однако это значение по умолчанию можно изменить с помощью параметра DROP ENCRYPTION BY SERVICE MASTER KEY в инструкции ALTER MASTER KEY. DMK, который не зашифрован главным ключом службы, должен быть открыт с помощью оператора OPEN MASTER KEY и пароля.

Управление SQL Server и ключами базы данных[править | править код]

Управление ключами шифрования состоит из создания новых ключей базы данных, создания резервной копии ключей сервера и базы данных, а также определения того, когда и как восстановить, удалить или изменить ключи[4]. Для управления симметричными ключами можно использовать средства, входящие в состав SQL Server, чтобы выполнить следующие действия:

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

Always Encrypted[править | править код]

Always Encrypted [12] — это функция, предназначенная для защиты конфиденциальных данных, таких как номера кредитных карт или национальные идентификационные номера (например, номера социального страхования США), хранящихся в базе данных SQL Azure или базах данных SQL Server. Always Encrypted позволяет клиентам шифровать конфиденциальные данные внутри клиентских приложений и никогда не раскрывать ключи шифрования для компонента Database Engine (базы данных SQL или SQL Server). В результате Always Encrypted обеспечивает разделение между теми, кто владеет данными и может их просматривать, и теми, кто управляет данными, но не должен иметь доступа. Обеспечивая доступ локальных администраторов баз данных, операторов облачных баз данных или других высокопривилегированных неавторизованных пользователей к зашифрованным данным, Always Encrypted позволяет клиентам уверенно хранить конфиденциальные данные вне их прямого контроля. Это позволяет организациям хранить свои данные в Azure и разрешать делегирование локального администрирования базы данных третьим сторонам или сокращать требования к разрешению безопасности для своих сотрудников DBA. Always Encrypted делает шифрование прозрачным для приложений.[6] Драйвер с поддержкой Always Encrypted, установленный на клиентском компьютере, достигает этого за счет автоматического шифрования и дешифрования конфиденциальных данных в клиентском приложении. Драйвер шифрует данные в конфиденциальных столбцах перед передачей данных в компонент Database Engine и автоматически перезаписывает запросы, чтобы сохранить семантику приложения. Аналогично, драйвер прозрачно расшифровывает данные, хранящиеся в зашифрованных столбцах базы данных, содержащихся в результатах запроса.[2]

Динамическая маскировка данных[править | править код]

Динамическое маскирование данных (DDM[5] ) ограничивает доступ к конфиденциальным данным, маскируя их непривилегированным пользователям. Он может быть использован для значительного упрощения проектирования и кодирования безопасности в вашем приложении.

Динамическое маскирование данных[6] помогает предотвратить несанкционированный доступ к конфиденциальным данным, позволяя клиентам указывать, сколько конфиденциальных данных следует раскрывать с минимальным воздействием на прикладной уровень. DDM может быть настроен в определённых полях базы данных, чтобы скрыть конфиденциальные данные в результирующих наборах запросов. С DDM данные в базе данных не изменяются. Динамическое маскирование данных легко использовать с существующими приложениями, поскольку в результатах запроса применяются правила маскирования. Многие приложения могут маскировать конфиденциальные данные без изменения существующих запросов.

Центральная политика маскирования данных действует непосредственно на чувствительные поля в базе данных. Назначьте привилегированных пользователей или роли, которые имеют доступ к конфиденциальным данным. DDM имеет функции полной и частичной маскировки, а также случайную маску для числовых данных. Простые команды Transact-SQLопределяют маски и управляют ими.[8] Например, сотрудник службы поддержки колл-центра может идентифицировать абонентов по нескольким цифрам их номера социального страхования или номера кредитной карты. Номера социального страхования или номера кредитных карт не должны быть полностью предоставлены сотруднику службы поддержки.[2] Можно определить правило маскирования, которое маскирует все, кроме последних четырёх цифр, любого номера социального страхования или номера кредитной карты в наборе результатов любого запроса. В другом примере, используя соответствующую маску данных для защиты данных, позволяющих установить личную информацию (PII), разработчик может запрашивать производственные среды для устранения неполадок, не нарушая правил соответствия.

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

Примечания[править | править код]

  1. ↑ | SQL Server Encryption. Дата обращения: 9 декабря 2019. Архивировано 15 февраля 2020 года.
  2. ↑ 1 2 3 4 5 6 7 8 SQL Server. Эффективная работа
  3. ↑ 1 2 Extensible Key Management
  4. ↑ 1 2 3 4 5 6 | Шифрование в базах данных SQL Server. Дата обращения: 9 декабря 2019. Архивировано 8 декабря 2019 года.
  5. ↑ 1 2 3 Microsoft SQL Server eBook (недоступная ссылка)
  6. ↑ 1 2 3 4 5 6 MS SQL Server 2005 для администраторов
  7. ↑ 1 2 3 4 Transparent Data Encryption
  8. ↑ 1 2 | ПРОСТО О TRANSACT-SQL. Дата обращения: 22 декабря 2019. Архивировано 22 декабря 2019 года.
  9. ↑ 1 2 | Handbook of Applied Cryptography. Дата обращения: 22 декабря 2019. Архивировано 3 февраля 2021 года.
  10. ↑ | Transparent Data Encryption. Дата обращения: 22 декабря 2019. Архивировано 13 декабря 2019 года.
  11. ↑ | Choose an Encryption Algorithm
  12. ↑ Always Encrypted

Литература[править | править код]

  • Bob Beauchemin: SQL Server 2012 Security Best Practices — Operational and Administrative Tasks
  • Алексей Вишнев: Microsoft SQL Server. Эффективная работа
  • Ростислав Михеев: MS SQL Server 2005 для администраторов

Ссылки[править | править код]

Источник — https://ru.wikipedia.org/w/index.php?title=Шифрование_в_SQL_Server&oldid=135321067