Навигация:  Быстрый старт > Фундаментальные объекты > Данные > Шифрование данных

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

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

Зашифровать данные, как правило, не составляет никакого труда. Алгоритмы шифрования хорошо известны и многие из них реализованы в операционной системе (например, AES). Гораздо сложнее придумать, как защитить ключ, которым эти данные зашифрованы. Ведь если «положить» его рядом с зашифрованными данными, то надёжной защиты не получится. Для решения этой задачи в MS SQL Server применяется специальная иерархия ключей. В контексте Transparent Data Encryption иерархия строится следующим образом:

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

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

 

 

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

 

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

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

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

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

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

 

Настройка TDE

Чтобы зашифровать базу данных с помощью Transparent Data Encryption, нужно выполнить следующие шаги:

 

 

 

 

 

 

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

 

 

 

 

 

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

 

 

 

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

 

 

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

0 — Database Encryption Key не создан.

1 — Database Encryption Key создан, но база данных не зашифрована.

2 — Выполняется первоначальное шифрование.

3 — База данных зашифрована.

4 — Идет смена ключа.

5 — Идет расшифровка.

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

 

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

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

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

 

Шифрование файлов данных

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

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

 

Шифрование журнала транзакций

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

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

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

 

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

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

 

Как включение TDE отразится на скорости работы приложения?

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

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

Статистические данные влияния TDE на производительность, представленные Microsoft в статье «Database Encryption in SQL Server 2008 Enterprise Edition» на MSDN:

«Влияние TDE на приложения с точки зрения производительности некритично. В исследованиях, где использовались данные и нагрузка от TPC-C тестов, влияние TDE на производительность оказалось в пределах 3-5% и могло бы быть еще меньше, если бы большая часть данных умещалась в оперативной памяти. Шифрование в TDE сильно нагружает процессор, что порождается операциями ввода/вывода. Поэтому серверы с низким уровнем ввода/вывода и низким уровнем потребления CPU будут менее всего страдать от TDE. Напротив, производительность приложений, сильно нагружающих CPU и порождающих большой объем ввода/вывода, будет страдать от TDE заметно сильнее, на уровне 28%».

 

Анализ результатов и выводы

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

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

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