Лабораторная работа

Тема работы: Шифрование БД

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

ИЕРАРХИЯ КЛЮЧЕЙ
Зашифровать данные, как правило, не составляет никакого труда. Алгоритмы шифрования
хорошо известны, и многие из них реализованы в операционной системе (например, AES).
Гораздо сложнее придумать, как защитить ключ, которым эти данные зашифрованы. Ведь если
мы ”положим” его рядом с зашифрованными данными, то мы получим в лучшем случае
обфускацию, но никак не надежную защиту. Для решения этой задачи в SQL Server применяется
специальная иерархия ключей. В контексте 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 Server в любой момент времени получить доступ к ключу, которым
зашифрована БД, а, следовательно, и к зашифрованным данным. И в тоже время, никто другой
получить доступ к этим данным не может. Но к сожалению, это теория, а на практике есть очень
ограниченный список угроз, которым способно противостоять Transparent Data Encryption (TDE). 

РЕШЕНИЕ КАКИХ ЗАДАЧ ПО ПЛЕЧУ TDE?

Если злоумышленник смог получить доступ к защищаемым данным через SQL Server, то
Transparent Data Encryption (TDE) оказывается абсолютно бесполезным. Данные зашифрованы
только на диске, а в памяти – нет. Зашифрованная база данных выглядит для пользователей
абсолютно так же, как и незашифрованная.
Для защиты от администраторов Transparent Data Encryption (TDE) так же бессильно.
Администратор SQL Server может шифрование просто отключить. Системный администратор при
желании также сможет найти тысячу и один способ получить доступ к зашифрованным данным
(даже если он не является администратором SQL Server).
Что реально может сделать Transparent Data Encryption (TDE), так это защитить файлы баз
данных и резервные копии на случай их похищения. И это уже неплохо. Если снять копию с
файлов активной БД не так просто (хотя и возможно), то похищение резервной копии при
наличии к ним доступа не представляет никаких проблем (какие могут быть проблемы сунуть
носитель с резервной копией в карман).
Но и тут есть свои ограничения. Файлы БД и резервные копии будут надежно защищены, только
если злоумышленнику не удастся вместе с данными заполучить и ключ. Если ему это удастся, то
он без проблем расшифрует секретные данные. Самым слабым звеном тут является главный ключ
службы (SMK), который находится на вершине иерархии ключей и который защищается с
помощью DPAPI. Подробнее об этом можно почитать в моем блоге
(http://blogs.gotdotnet.ru/yliberman) в сообщении ”Вся правда о Service Master Key в SQL Server
2005”.
Также следует отметить, что Transparent Data Encryption (TDE) – это не замена тем
криптографическим возможностям, которые есть в SQL Server 2005. Если шифрование в SQL
Server 2005 работает на уровне значений и столбцов (за что часто называется ”cell-level”-
шифрованием), то Transparent Data Encryption (TDE) работает на гораздо более высоком уровне –
на уровне базы данных. Задачи, которые решаются с помощью обоих подходов во многом
пересекаются, но у каждого из них есть свои преимущества и недостатки. Оба подхода
используют одни и те же криптографические алгоритмы (с теми же длинами ключей), так что
криптографически оба подхода обеспечивают одинаковый уровень защиты данных.

ЧТО ИМЕННО ШИФРУЕТСЯ?

Когда для БД включено Transparent Data Encryption (TDE), шифруются как ее файлы данных, так
и ее журнал транзакций.
Кроме того, как только на экземпляре SQL Server включается шифрование хотя бы одной БД,
база данных tempdb также начинает шифроваться. За что "пострадала" база данных tempdb,
понятно, – она может содержать куски секретной информации из шифруемых баз. А вот за что
должны "страдать" приложения, работающие с другими, не зашифрованными базами данных? Их
запросы, выполнение которых требует участия базы данных tempdb (большие сортировки,
например), очевидно, станут выполняться медленнее. Дело, видимо, в том, что не всегда
возможно определить источник данных, которые попадают в tempdb, и поэтому для гарантии она
шифруется целиком.
Разберемся по порядку:
Файлы данных
Когда для базы данных включается шифрование, SQL Server, как уже упоминалось выше, в
отдельном потоке выполняет шифрование всех файлов данных этой БД. Но есть области, которые
остаются незашифрованными:
 File Header Page (Page *:0). Это первая страница, которая присутствует во всех файлах
данных.
 Boot Page (Page 1:9) . Эта страница присутствует только в первом файле данных БД и
расположена по смещению 0x12000 байт от начала файла. Именно здесь хранится
зашифрованный сертификатом Database Encryption Key (DEK), а так же почти вся
информация, которая доступна через системное представление
sys.dm_database_encryption_keys. Для отображения содержимого этой страницы, помимо
универсальной команды DBCC PAGE, предназначена команда DBCC DBINFO (информацию,
относящуюся к TDE она, к сожалению, не возвращает).
 Заголовки страниц (первые 0x60 байт каждой страницы) также остаются
незашифрованными.
Когда SQL Server зашифровывает страницу, он устанавливает для нее соответствующий флаг (в
поле m_flagBits, которое физически расположено по смещению 4 от начала страницы и занимает
2 байта, устанавливается бит 0x800). Интересно, что мы никогда не увидим этот бит
установленным через DBCC PAGE, так как в памяти все страницы расшифрованы (хотя в файле
флаг для этой страницы может быть установлен).
База данных tempdb
Как уже упоминалось ранее, если на сервере включается шифрование хотя бы для одной
пользовательской БД, то база данных tempdb тоже автоматически начинает шифроваться.
Причем ситуация с tempdb напоминает ситуацию с журналами транзакций. Все новые данные,
записываемые в tempdb шифруются, в то время как первоначального шифрования данных,
которые там уже есть, не выполняется. В результате данные, которые уже были в tempdb на
момент включения шифрования, остаются незащищенными. Но в данном случае решить проблему
легко, достаточно перезапустить сервер. В этом случае tempdb будет создана заново, а все
записываемые в нее данные будут шифроваться с самого начала.

Задание на лабораторную работу

Задание 1:
1. Создайте в базе данных симетричный ключ с алгоритмом RSA. Ключ
должен быть защищен паролем
2. Создайте в базе данных копию таблицы. Все данные в ней должны быть
зашифрованы при помощи созданного вами симметричного ключа.
3. Выполните запрос, который бы вернул все данные из зашифрованной таб-
лицы
Проделать аналогичные операции с использованием ассиметричных ключей
и сертификатов.
Задание 2. Зашифруйте БД с помощью прозрачного шифрования. Провести
анализ производительности и трассировку результатов.
Задание 3. Используя https://docs.microsoft.com/ru-ru/sql/relational-
databases/security/encryption/encrypt-a-column-of-data создайте для
таблицы зашифрованный столбец данных.
Задание 4. Используя https://docs.microsoft.com/ru-ru/sql/relational-
databases/security/encryption/always-encrypted-database-engine создать
таблицу с зашифрованными по технологии Always Encryption данными, и
https://docs.microsoft.com/ru-ru/sql/relational-
databases/security/encryption/configure-always-encrypted-using-sql-server-
management-studio просмотреть зашифрованные и расшифрованные
данные.

Требование к каталогу отчета:

Отчет содержит:
1. Тестовые БД;
2. Скрипты всех выполненных операций шифрования
3. Документ со скринами результатов:
o выполнения запросов на чтение зашифрованных и
расшифрованных данных;
o монитора производительности и трассировки процессов.

Ход работы
Шифрование с помощью сертификатов для защиты ключей
Создание сертификата выполняется при помощи команды CREATE
CERTIFICATE. Самый простой вариант этой команды выглядит так:

CREATE CERTIFICATE Cert1

ENCRYPTION BY PASSWORD = '11'
WITH SUBJECT = 'Проверка шифрования',
START_DATE = '02/06/2009'

Обратим внимание, что для создания сертификата нам не требуется

никакой центр сертификации - все необходимые средства уже встроены в
SQL Server.

Параметр ENCRYPTION BY PASSWORD определяет пароль, который

потребуется для расшифровки данных, защищенных сертификатом (для
шифрования данных он не нужен). Если этот параметр пропустить, то
создаваемый сертификат будет автоматически защищен главным ключом
базы данных (Database Master Key). Автоматически этот ключ не создается.
Чтобы получить возможность работать с ним, нужно предварительно его
создать:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'P@ssw0rd';

Кроме пароля, главный ключ базы данных автоматически защищается

также главным ключом службы (Service Master Key). Этот ключ автоматически
генерируется SQL Server в процессе установки. Надо быть очень
внимательным при использовании главного ключа базы данных: если мы
переустановим сервер (а, следовательно, изменится главный ключ службы),
зашифрованные данные могут быть потеряны. Чтобы этого не случилось,
нужно производить регулярное копирование базы данных master или
экспортировать главный ключ службы в файл при помощи команды BACKUP
SERVICE MASTER KEY. Обязательный параметр SUBJECT команды CREATE
CERTIFICATE определяет цель выдачи сертификата.

После того, как сертификат создан, его можно использовать для

шифрования данных. Для этой цели применяется специальная функция
EncryptByCert:

insert into Num_cards

values(1, EncryptByCert(Cert_ID('Cert1'), N'111001') )

insert into Num_cards

values(2, EncryptByCert(Cert_ID('Cert1'), N'111002') )

 insert into Num_cards

values(3, EncryptByCert(Cert_ID('Cert1'), N'111003') )

Для расшифрования используется команда DecryptByCert. Чтобы

расшифровать данные, нужно использовать обыкновенный запрос SELECT:

select convert(nvarchar(50), DecryptByCert(Cert_ID('Cert1'), Cred_ID, N'11') )

from Num_cards

Шифрование ассиметричным ключом

Вначале нужно создать ассиметричный ключ.

CREATE ASYMMETRIC KEY ASymKey1

WITH ALGORITHM = RSA_512

ENCRYPTION BY PASSWORD = '11'

Обратите внимание, что, кроме пароля, здесь требуется указать длину

создаваемого ключа. В нашем распоряжении три варианта: 512, 1024 и 2048
бит.

После этого при помощи созданного ключа можно производить

шифрование данных:

insert into Num_cards

values (1, EncryptByAsymKey(AsymKey_ID('ASymKey1'), N'111001'))

insert into Num_cards

values (2, EncryptByAsymKey(AsymKey_ID('ASymKey1'), N'111002'))

insert into Num_cards values

(3, EncryptByAsymKey(AsymKey_ID('ASymKey1'), N'111003'))

Мы вносим в таблицу 3 записи с одним и тем же ассиметричным ключом

AsymKey1. В результате данные в таблице будут представлены в виде
нечитаемого набора символов.

Для расшифрования воспользуемся функцией DecryptByAsymKey

SELECT Convert(nvarchar(50), DecryptByAsymKey(AsymKey_ID('ASymKey1'),Cred_ID, N'11'))

FROM Num_cards

Шифрование симметричным ключом

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

быстрее, чем при применении асимметричных алгоритмов, поэтому при
работе с большими объемами данных рекомендуется использовать именно
их. Применение симметричных ключей выглядит очень похоже. Правда, есть
и небольшие отличия. Во-первых, при создании симметричного ключа его
можно защищать не только паролем, но и другим симметричным ключом,
асимметричным ключом или сертификатом. Во-вторых, при создании
симметричного ключа вы можете указать один из восьми алгоритмов
шифрования, поддерживаемых SQL Server 2005 (DES, TRIPLE_DES, RC2, RC4,
DESX, AES_128, AES_192, AES_256). Само создание симметричного ключа
может выглядеть так:

CREATE SYMMETRIC KEY SymKey1

WITH ALGORITHM = DES

ENCRYPTION BY PASSWORD = '11'

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

достаточно сделать только один раз в течение сеанса работы пользователя:

OPEN SYMMETRIC KEY SymKey1 DECRYPTION BY

PASSWORD = '11'

Используем созданный ключ для шифрования данных:

insert into Num_cards

values(1, EncryptByKey(Key_GUID('SymKey1'), convert(nvarchar(50),'111001') ))

insert into Num_cards

values(2, EncryptByKey(Key_GUID('SymKey1'), convert(nvarchar(50),'111002') ))

insert into Num_cards

values(3, EncryptByKey(Key_GUID('SymKey1'),
 convert(nvarchar(50),'111003') ))

Обратите внимание, что при расшифровке данных нет необходимости

передавать функции DecryptByKey имя симметричного ключа и пароль. Будут
автоматически подставляться данные открытого ключа при помощи команды
open. Для расшифровки сообщения нужно запустить следующий скрипт:

select convert(nvarchar(50), DecryptByKey(Cred_ID))

from Num_cards

Потому как зашифрованные данные нельзя хранить в столбцах типа int,

char, применяетcя команда convert.

Шифрование паролем

SQL Server позволяет производить шифрование данных также просто при

помощи пароля. Для этого используется функция EncryptByPassPhrase.

В самом простом варианте она принимает только пароль и данные,

которые необходимо зашифровать:

insert into Num_cards

values(4, EncryptByPassPhrase('Password', N'111004'))

Расшифровка производится при помощи функции DecryptByPassphrase:

select

convert(nvarchar(50), DecryptByPassPhrase('Password', Cred_Id))

from Num_cards

Прозрачное шифрование
Порядок включения шифрования:

1. Создать главный ключ

2. Создать или получить сертификат, защищенный главным ключом
3. Создать ключ шифрования базы данных и защитить его с помощью
сертициката
4. Задать ведение шифрование базы данных
  Перейдем к самой реализации:

1) Создание главного ключа шифрования

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPassword#1';
Созданный наш ключ можно увидеть в view:
select * from sys.key_encryptions
 Удалить ключ можно инструкцией:
drop master key

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

BACKUP MASTER KEY TO FILE = 'c:\sqltest2012_masterkey_backup.bak'
ENCRYPTION BY PASSWORD = 'Password1'

 2) Создание сертификата

CREATE CERTIFICATE TDECertificate WITH SUBJECT ='TDE Certificate for DBClients'

Проверка наличия созданного сертификата:
select * from sys.certificates where name='TDECertificate'

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

BACKUP CERTIFICATE TDECertificate
TO FILE = 'c:\sqltest2012_cert_TDECertificate'
WITH PRIVATE KEY
(
FILE = 'c:\sqltest2012SQLPrivateKeyFile',
ENCRYPTION BY PASSWORD = 'Password#3'
);

 3) Создание ключа шифрования в нашей базе данных с использование

нашего сертификата

USE [DBClients]
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE TDECertificate;
 
4) И наконец включаем шифрование для нашей базы данных

ALTER DATABASE [DBClients]
SET ENCRYPTION ON ;
В итоге имеем базу данных с прозрачным шифрованием.

Проверить, что Database Encryption Key (DEK) действительно создан, можно с

помощью системного представления sys.dm_database_encryption_keys.
SELECT DB_NAME(database_id), * FROM sys.dm_database_encryption_keys

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

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

данных. Он выполняется "в фоне" в отдельном потоке. Отследить прогресс
выполнения этой операции можно по столбцу percent_complete уже
упомянутого нами ранее системного представления
sys.dm_database_encryption_keys. Так, если выполнить приведенный ниже
запрос в процессе выполнения первоначального шифрования базы данных,
то мы можем получить, например, следующий результат:
SELECT DB_NAME(database_id), encryption_state, percent_complete FROM
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 Server включается шифрование
хотя бы одной БД, база данных tempdb также начинает шифроваться. За что
"пострадала" база данных tempdb, понятно, – она может содержать куски
секретной информации из шифруемых баз. А вот за что должны "страдать"
приложения, работающие с другими, не зашифрованными базами данных?
Их запросы, выполнение которых требует участия базы данных tempdb
(большие сортировки, например), очевидно, станут выполняться медленнее.
Дело, видимо, в том, что не всегда возможно определить источник данных,
которые попадают в tempdb, и поэтому для гарантии она шифруется
целиком.
Разберемся по порядку:

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

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

Журнал транзакций
В отличие от файлов данных, операция первоначальной шифровки для
журналов транзакций не выполняется. То есть информация о транзакциях,
которая уже есть в журналах транзакций на момент включения шифрования,
остается незащищенной. Шифруется только информация о новых
транзакциях. По крайней мере, такое поведение мы можем наблюдать в
CTP6.
Как следствие, если есть полная резервная копия БД до того как она была
зашифрована, то даже после включения шифрования, можно сделать
резервную копию журнала транзакций уже зашифрованной БД, а потом
восстановить ее на момент, предшествующий шифрованию, и получить
доступ к секретным данным. При этом восстановить такой архив можно без
доступа к ключу (например, на другом сервере).
Следующий сценарий демонстрирует эту возможность:
USE master
go
-- Создаем главный ключ базы данных master
IF(not EXISTS(SELECT * FROM sys.symmetric_keys WHERE name =
'##MS_DatabaseMasterKey##'))
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'My$Strong$Password$123'
go
-- Создаем сертификат, которым будем шифровать DEK
CREATE CERTIFICATE DEK_EncCert WITH SUBJECT = 'DEK Encryption Certificate'
go
-- Создаем базу данных, которую будем шифровать
CREATE DATABASE MySecretDB
go
-- И сразу делаем ее полную резервную копию (секретных данных здесь нет)
BACKUP DATABASE MySecretDB TO DISK = 'c:\temp\MySecretDB.bak' WITH INIT
go
USE MySecretDB
go
-- Создаем таблицу и заполняем ее секретными данными
-- Делаем это в транзакции с меткой T1
BEGIN TRAN T1 WITH MARK

CREATE TABLE dbo.MySecretTable (Data varchar(200) not null)

INSERT dbo.MySecretTable (Data) VALUES ('It is my secret')

COMMIT
go
-- Шифруем базу данных
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE DEK_EncCert
go
ALTER DATABASE MySecretDB SET ENCRYPTION ON
go

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

SELECT DB_NAME(database_id), encryption_state FROM
sys.dm_database_encryption_keys

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

зашифрована):
BACKUP LOG MySecretDB TO DISK = 'd:\temp\MySecretDB.trn'

Стираем нашу базу данных, а затем и сертификат, которым мы шифровали ее

Database Encryption Key (DEK). Нам это нужно для того, чтобы эмулировать
восстановление БД на другом сервере.
USE master
go
DROP DATABASE MySecretDB
go
DROP CERTIFICATE DEK_EncCert
go

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

RESTORE DATABASE MySecretDB FROM DISK = 'd:\temp\MySecretDB.bak' WITH
NORECOVERY
RESTORE LOG MySecretDB FROM DISK = 'd:\temp\MySecretDB.trn'

Как и следовало ожидать, попытка восстановления базы данных закончилась

ошибкой. Сертификат, которым зашифрован Database Encryption Key (DEK),
более недоступен.
Msg 33111, Level 16, State 3, Line 2
Cannot find server certificate with thumbprint
'0x347D263A185EF41D8EB06AE425F7599AD2D0FCC3'.
Msg 3013, Level 16, State 1, Line 2
RESTORE LOG is terminating abnormally.

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

то есть на отметку T1.
RESTORE DATABASE MySecretDB FROM DISK = 'd:\temp\MySecretDB.bak' WITH
NORECOVERY
RESTORE LOG MySecretDB FROM DISK = 'd:\temp\MySecretDB.trn' WITH STOPATMARK
= 'T1'
go
USE MySecretDB
go
-- Запрос к секретным данным
SELECT * FROM dbo.MySecretTable
go

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

Напомню, что сами секретные данные были сброшены в резервную копию
журнала транзакций уже после того, как база данных была зашифрована и
восстановлена без всякого доступа к ключу. На самом деле для того чтобы
увидеть секретные данные, в нашем случае достаточно было открыть в
редакторе файл журнала транзакций (или его резервную копию). Несмотря
на то, что наша база зашифрована, секретные данные в журнале транзакций
остались в открытом виде (шифруются только новые транзакции) (просмотр
журнала транзакций - https://solutioncenter.apexsql.com/ru/%D0%BF
%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80-%D1%81%D0%BE
%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%B3%D0%BE-
ldf-%D1%84%D0%B0%D0%B9%D0%BB%D0%B0/).

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