SQL Server 2008 Transparent Data Encryption (Прозрачное шифрование баз данных)

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

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

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

В Microsoft SQL Server 2008 появилось новое решение для обозначенных выше проблем - это прозрачное шифрование баз данных (Transparent Data Encryption или TDE). TDE позволяет шифровать базы данных целиком. Когда страница данных сбрасывается из оперативной памяти на диск, она шифруется. Когда страница загружается обратно в оперативную память, она расшифровывается. Таким образом, база данных на диске оказывается полностью зашифрованной, а в оперативной памяти нет. Основным преимуществом TDE является то, что шифрование и расшифровка выполняются абсолютно прозрачно для приложений. Следовательно получить преимущества от использования TDE можно для любого приложения, использующего для хранения своих данных Microsoft SQL Server 2008. При этом модификации или доработки приложения не требуется.

К сожалению планируется, что Transparent Data Encryption (TDE) будет доступно только в Enterprise версии SQL сервера (источник).

Иерархия ключей в TDE

В Microsoft SQL Server 2008 Transparent Data Encryption (TDE) используется следующая иерархия ключей:

• Для каждой базы данных, которая шифруется с помощью Transparent Data Encryption (TDE) создается специальный ключ - Database Encryption Key (DEK). Этот ключ используется для шифрования данных.
• Database Encryption Key (DEK) шифруется сертификатом, который должен быть создан в базе данных master.

Далее стандартно:

• Этот сертификат шифруется главным ключом базы данных master.
• Главный ключ базы данных master шифруется главным ключом службы (Service Master Key или SMK)
• Главный ключ службы (SMK) шифруется с помощью DPAPI.

Вся иерархия приведена на следующем рисунке:

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

Решение каких задач по плечу TDE?

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

Для защиты от администраторов Transparent Data Encryption (TDE) так же бессильно. Администратор SQL сервера может шифрование просто отключить. Системный администратор при желании так же сможет найти тысячу и один способ получить доступ к зашифрованным данным (даже если он не является SQL администратором).

Что реально может сделать Transparent Data Encryption (TDE), так это защитить файлы баз данных и резервные копии, в случае их похищения. И это уже неплохо. Если снять копию с файлов активной базы данных не так просто (хотя и возможно), то похищение резервной копии при наличии к ним доступа не представляет никаких проблем (какие могут быть проблемы сунуть носитель с резервной копией в карман).

Но и тут есть свои ограничения. Файлы базы данных и резервные копии будут надежно защищены только, если злоумышленнику не удастся вместе с данными заполучить и ключ. Если ему это удастся, то он без проблем расшифрует секретные данные. Самым слабым звеном тут является главный ключ службы (SMK), который находится на вершине иерархии ключей и который защищается с помощью DPAPI. Об этом я уже писал ранее.

Также следует отметить, что Transparent Data Encryption (TDE) - это не замена тем криптографическим возможностям, которые есть в SQL Server 2005. Если шифрование в SQL Server 2005 работает на уровне значений (колонок) то Transparent Data Encryption (TDE) работает на гораздо более высоком уровне - на уровне базы данных. Задачи, которые решаются с помощью обоих подходов во многом пересекаются, но у каждого из них есть свои преимущества и недостатки. Оба подхода используют одни и те же криптографические алгоритмы (с теми же длинами ключей), так что криптографически оба подхода обеспечивают одинаковый уровень защиты данных.

Настройка

Для того чтобы зашифровать базу данных с помощью Transparent Data Encryption (TDE) нужно выполнить следующие шаги:

1. Создать главный ключ базы данных master (если он не был создан ранее).

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

3. Далее в базе данных, которую мы собираемся шифровать, нужно создать Database Encryption Key (DEK). DEK шифруется сертификатом, который мы создали на предыдущем шаге.

Проверить, что Database Encryption Key (DEK) действительно создан можно с помощью системного представления sys.dm_database_encryption_keys.

4. В этот момент все готово для того, чтобы включить шифрование базы данных. Включаем.

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

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

В столбце encryption_state содержится информация о текущем состоянии базы данных. Согласно SQL Server Books Online (BOL) в контексте Transparent Data Encryption (TDE) база данных может быть в одном из следующих состояний:

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

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

Что именно шифруется?

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

Кроме того, как только на экземпляре SQL сервера включается шифрование хотя бы одной базы данных, то база данных tempdb так же начинает шифроваться. За что "пострадала" база данных tempdb понятно, она может содержать куски секретной информации из шифруемых баз. А вот за что должны "страдать" приложения работающие с другими не зашифрованными базами данных? Их запросы, выполнение которых требует участия базы данных tempdb (большие сортировки, например), очевидно станут выполняться медленнее. Дело видимо в том, что не всегда можно определить источник данных, которые "падают" в tempdb, и по-этому для гарантии шифруется вся база данных tempdb.

Итак, давайте по прядку:

Файлы данных

Когда для базы данных включается шифрование, SQL сервер, как уже упоминалось выше, в отдельном потоке выполняет шифрование всех файлов данных этой БД. Но есть области, которые остаются незашифрованными:

• File Header Page (Page ?:0). Это первая страница, которая присутствует во всех файлах данных.
• Boot Page (Page 1:9) . Эта страница присутствует только в первом файле данных БД и расположена по смещению 0x12000 байт от начала файла.  Именно здесь хранится зашифрованный сертификатом Database Encryption Key (DEK), а так же почти вся информация, которая доступна через системное представление sys.dm_database_encryption_keys. Для отображения содержимого этой страницы (помимо универсальной команды DBCC PAGE) предназначена команда DBCC DBINFO. Но, к сожалению, в CTP5 информацию, относящуюся к TDE, она не возвращает (будем надеяться, что пока).
• Заголовки страниц (первые 0x60 байт каждой страницы) также остаются незашифрованными.

Когда SQL сервер зашифровывает страницу, он устанавливает для нее соответствующий флаг (в поле m_flagBits, которое физически расположено по смещению 4 от начала страницы и занимает 2 байта, устанавливается бит 0x800). Интересно, что мы никогда не увидим этот бит установленным через DBCC PAGE, так как в памяти все страницы расшифрованы (хотя в файле флаг для этой страницы может быть установлен).

Журнал транзакций

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

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

Следующий сценарий демонстрирует эту возможность:

Проверяем, что база данных зашифрована:

 

Делаем резервную копию журнала транзакций (база данных уже зашифрована):

Стираем нашу базу данных, а затем и сертификат, которым мы шифровали ее Database Encryption Key (DEK). Нам это нужно для того, чтобы эмулировать восстановление БД на другом сервере.

Теперь попытаемся восстановить базу данных. Cначала полностью:

Как и следовало ожидать попытка восстановления базы данных закончилась ошибкой. Сертификат, которым зашифрован Database Encryption Key (DEK), более недоступен.

А теперь восстановим базу данных на момент "до включения шифрования", то есть на отметку T1.

Все, доступ к секретным данным мы получили:

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

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

База данных tempdb

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

Полезные ссылки

• "Как взломать SQL Server и как от этого защищаться" доклад Дмитрия Артемова и Сергея Пырина на Платформе 2008 в пересказе Алексея Шуленина (с дополнениями)
• "SQL Server 2008: Transparent data encryption feature - a quick overview" Laurentiu Cristofor

<script src="http://www.google-analytics.com/urchin.js" type=text/javascript> </script> <script type=text/javascript> _uacct = "UA-2408004-1"; urchinTracker(); </script>