Шифрование и дешифрование базы данных Access. Что следует понимать и помнить при использовании TDE

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

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

Мы уже публиковали обзор средств шифрования , поэтому необходимо напомнить следующее:

1. В обзоре рассматривались «универсальные» криптосистемы, работа которых в большей степени не зависит от платформы.

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

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

Учитывая все вышесказанное, возникает закономерный вопрос: нет ли более простого решения? Можно ли пожертвовать универсальностью решения в пользу производительности, удобства, безопасности, учитывая специфику работы с информацией в конкретной организации?

Допустим, в компании используется ERP, CRM или учетная система, данные которых необходимо защищать. Любая из этих систем не привязана к какой-то определенной СУБД и у нас есть свобода выбора. Тогда стоит обратить внимание на систему управления базами данных Microsoft SQL Server. Компания Microsoft стала больше уделять внимания безопасности в своих продуктах – и вот что это нам принесло на сегодняшний день.

Шифрование баз данных средствами MS SQL Server

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

В Microsoft SQL Server 2012 функции шифрования были улучшены и расширены. Для увеличения надежности криптозащиты и уменьшения нагрузки на систему применяется специальная иерархия ключей.

1. Каждой базы данных шифруется при помощи специального ключа – Database Encryption Key.

2. Database Encryption Key шифруется сертификатом, который создан в базе данных Master.

3. Сертификат базы данных Master шифруется ее главным ключом.

4. Главный ключ БД Master шифруется главным ключом службы Service Master Key.

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

Наглядно схема работы с зашифрованной базой данных выглядит следующим образом:

Рисунок 1 - Схема работы с зашифрованной базой данных

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

Так, база данных защищается более быстрым симметричным шифрованием, которое, при учете больших объемов информации, предпочтительнее. В свою очередь, ассиметричному шифрованию подвергаются ключи шифрования базы, размер которых несоизмеримо мал, но критичность их защиты выше. Использование такого подхода, на серверах с низким уровнем ввода/вывода, низким потреблением процессорного времени и оперативной памятью, достаточной для хранения больших массивов информации, влияет на производительность на 3-5% при включении TDE. Серверы с меньшим объемом ОЗУ, чьи приложения нагружают ЦПУ и систему ввода/вывода, будут страдать на 28%, что достигается асинхронным выполнением процедур SQL (распараллеливание процессов).

Что следует понимать и помнить при использовании TDE

При включении функции Transparent Data Encryption для любой пользовательской базы происходит следующее:

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

Также следует отметить, что Transparent Data Encryption (TDE) не заменяет криптографические возможности SQL Server 2005. Шифрование в MS SQL Server 2005 работает на уровне значений и столбцов, а Transparent Data Encryption (TDE) – на уровне базы данных – на более высоком уровне. Данное решение не защитит от системного администратора или администратора SQL Server, но идеально противостоит краже или изъятию самой базы данных.

Но что же делать, если соединение между сервером СУБД и клиентом не может считаться доверительным? Информация, которой они обмениваются, может быть перехвачена, «подслушана» или подменена – ведь рассмотренные средства не защищают сетевые соединения, а дополнительная организация шифрованных каналов, особенно проприетарных, влечет за собой дополнительные расходы производительности и финансов.

Шифрование соединения средствами MS SQL Server

Если возможность прозрачного шифрования появилась лишь в SQL Server 2008, то защита соединения между сервером и клиентом известна еще со времен SQL Server 7.0. К релизу 2012 она претерпела значительные доработки. Если раньше, для передачи конфиденциальных данных использовался протокол SSL, то теперь пакеты «оборачиваются» в его логическое продолжение – протокол TLS.

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

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

Подводя итоги

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

Системная интеграция. Консалтинг

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

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

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

В этой статье

Обзор

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

Новая функция шифрования действует только в отношении баз данных в формате ACCDB.

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

При шифровании баз данных, созданных в более ранних версиях Access (MDB-файлов), или применении к ним паролей используются соответствующие функции из Access 2003.

Шифрование базы данных с помощью пароля

В этом разделе описано, как создать пароль и применить к базе данных Access рабочего стола.

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

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

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

Открытие и расшифровка базы данных

Напоминание. Обязательно запомните пароль. Забытый пароль невозможно восстановить.

О шифровании соединений в InterBase изложено . В этой статье описано только шифрование базы данных и/или столбцов таблиц.

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

Обзор шагов шифрования

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

1. Включение EUA

EUA является первым средством, которое позволяет защититься от ситуации "украли файл с базой", т. к. если пароль SYSDBA в базе будет не masterkey, то его придется или подбирать, или как-то хакать hex-editor-ом (не пробовал). Но, как минимум, это уже хоть какая-то защита от "чайников".

Итак, берем какую-нибудь тестовую базу, которую не жалко в случае ошибки, и в случае чего можно удалить или пересоздать. База должна быть создана не менее чем в InterBase 2009 (где впервые было сделано шифрование БД), но эту версию уже можно считать устаревшей, поэтому я настаиваю на XE или XE3 (для экспериментов можно взять Developer Edition, если ее у вас ее еще нет - выбираем InterBase XE3 (11.0.3.655) 32-bit Developer Edition - Windows, English или InterBase XE3 (11.0.3.655) 64-bit Developer Edition - Windows, English). Иначе часть описываемых функций у вас может не заработать. Шифрование включается для каждой БД отдельно.

Внимание! Теоретически, все выполняемые ниже действия можно сделать "мышекликаньем" в IBConsole. Однако, как показывает практика, IBConsole глючит, поэтому операции, относящиеся к шифрованию БД, в IBConsole выполнять опасно. Отчасти поэтому, а в основном для того, чтобы вы лучше поняли смысл действий, все команды приведены в виде SQL. Выполнять их можно в любом инструменте - isql, IBExpert, SQL Manager, и т. д.

Логинимся под SYSDBA, включаем в базе EUA

ALTER DATABASE ADD ADMIN OPTION

ALTER USER SYSDBA SET PASSWORD "sss"

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

Разлогиниваемся, проверяем - пароль masterkey больше не работает, используем sss - ок, подключились.

Примечание. С этого момента "вернуть" пароль masterkey подменой admin.ib или переносом базы на другой сервер не получится. То есть, получится, но только отключением EUA, для чего нужно будет знать новый пароль SYSDBA.

2. Создание пользователя SYSDSO

CREATE USER SYSDSO SET PASSWORD "ooo"

1. создания системного пароля шифрования (System Encryption Password или SEP)
2. создания ключей шифрования
3. выдачи прав другим пользователям на использование созданных ключей шифрования для шифрования базы данных или столбцов таблиц

3. Создание System Encryption Password

Создаем SEP для базы

ALTER DATABASE SET SYSTEM ENCRYPTION PASSWORD "aaa"

Внимание! При генерации System Encryption Password (SEP) используется информация, специфичная для текущего компьютера. Поэтому на этой машине далее при доступе к БД указывать SEP не требуется (хотя такое требование можно включить), а при переносе БД на другой компьютер никто без указания пароля SEP к базе подключиться не сможет . Можно указывать пароль SEP в параметрах коннекта (isc_dbp_system_encrypt_password), но это доступно только компонентам прямого доступа (типа IBX, FIBPlus, FireDAC, ...). Либо, можно указать SEP в переменных среды ОС (переменная ISC_SYSTEM_ENCRYPT_PASSWORD). Поэтому, если администратор переносит БД на другой сервер, то лучше сделать так - SYSDSO должен залогиниться к базе на новом сервере, используя свой пароль и старый SEP, и создать новый SEP. Новый SEP будет привязан уже к этому компьютеру, и остальным пользователям указывать его при коннекте не потребуется.
Для мобильных платформ с использованием IBLite, где подобные операции проводить как минимум неудобно, нужно явно указывать SEP при подключении к локальной БД.

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

Пример параметров для IBX.IBDatabase (или других компонент прямого доступа) с нашими паролями

user_name=SYSDBA
password=sss
lc_ctype=WIN1251

system_encrypt_password=aaa

Protocol=TCPIP
Server=myserver
Database=c:\data\ibxes.ib
User_Name=SYSDBA
Password=sss
SEPassword=aaa
DriverID=IB

Внимание! При выборе других (кроме упомянутых FireDAC и IBX) компонент доступа к InterBase/IBLite при использовании шифрования необходимо проверить, поддерживают ли они передачу параметра для пароля SEP. Если нет, часть функций, описанных в статье, вы использовать не сможете. Например, dbExpress такого параметра не имеет, а значит как минимум в отношении зашифрованных баз данных на мобильных платформах его использовать нельзя.

SEP может иметь длину до 255 символов.

Убрать SEP (сделать это может только SYSDSO) можно командой

ALTER DATABASE SET NO SYSTEM ENCRYPTION PASSWORD

4. Создание ключей для шифрования БД и/или столбцов

Тем не менее, для проверки будет достаточно DES. Напомню, что шифровать можно как базу целиком, так и отдельные столбцы, поэтому я на всякий случай создам 3 разных ключа шифрования - один буду использовать для базы, и два для столбцов. Физически эти ключи не отличаются. Логинимся под SYSDSO, выполняем команды

CREATE ENCRYPTION db_des for DES
CREATE ENCRYPTION kname_des for DES
CREATE ENCRYPTION sname_des for DES

create encryption key-name
]

Length - можно использовать только для AES, указывая длину ключа 128, 192 или 256 бит. 128 по умолчанию для AES.

Password - только для ключей, которыми шифруют столбцы, или используют для backup/restore. Можно использовать для дополнительной аутентификации при расшифровке зашифрованных столбцов. Для доступа к такому столбцу нужно или иметь право пользоваться ключом, с помощью которого зашифрован столбец, или знать пароль ключа и перед чтением зашифрованных данных выдать команду

set password "password" for column table.column_name

Pad - при random padding одинаковые значения могут давать разный результат шифрования. Null по умолчанию.

Description - комментарий к этому ключу - для чего предназначен и т. п.

Внимание! Включение init-vector random или pad random делают невозможным создание индекса по зашифрованному столбцу, при попытке проиндексировать такой столбец сервер выдаст ошибку. Нужно отметить, что и без init-vector и pad с поиском по индексированным зашифрованным столбцам не все хорошо, об этом будет дальше.

Чтобы удалить ключ шифрованиия, нужно выполнить команду

DROP ENCRYPTION имя_ключа

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

5. Выдача прав на использование ключей шифрования

GRANT ENCRYPT ON ENCRYPTION db_des to SYSDBA;
GRANT ENCRYPT ON ENCRYPTION kname_des to SYSDBA;
GRANT ENCRYPT ON ENCRYPTION sname_des to SYSDBA;

Отобрать выданное право на использование ключа можно командой

REVOKE ENCRYPT ON ENCRYPTION FROM SYSDBA

Тестовая база данных

ALTER TABLE KLADR ADD CONSTRAINT PK_KLADR PRIMARY KEY (CODE);
CREATE INDEX BY_K_NAME ON KLADR (NAME);
ALTER TABLE STREET ADD CONSTRAINT PK_STREET PRIMARY KEY (CODE);
CREATE INDEX BY_S_NAME ON STREET (NAME);

1. IBXES.IB - подготовленная к шифрованию база, незашифрованная
2. IBXESD.IB - зашифрованная БД
3. IBXESC.IB - база, в которой зашифрованы только строковые столбцы
4. IBXESDC.IB - зашифрованная БД с зашифрованными столбцами

Тестовый компьютер

• Процессор: AMD Phenom II X6 1075T
• Материнская плата: Gigabyte GA-970A-UD3
• Память: 16Gb, DDR3
• Видеокарта: GeForce GTX 760
• Операционная система: Windows 7 Ultimate 64 bit
• Диск с базой: RAID 1, 2x Seagate ST2000DM001-1CH164 (2Tb, SATA 3).
• RAID организован чипсетом матплаты, включен кэш Read Ahead и Write Back, для дисков включен NCQ и кэш записи.

6.1 Шифрование базы

ALTER DATABASE ENCRYPT DB_DES

То есть, шифруем ее ключом db_des.

В результате выполнения операции

Prepare time = 0ms
Execute time = 10s 265ms
Current memory = 69 980 400
Max memory = 72 140 480
Memory buffers = 8 192
Reads from disk to cache = 16 992
Writes from cache to disk = 10 992
Fetches from cache = 17 143

Определить, зашифрована база или нет, можно вызовом

gstat -h ibxes.ib

При этом строка Attributes будет содержать флаг encrypted (если не зашифрована - этот флаг отсутствует). Для баз, где зашифрованы только столбцы, такая информация не выводится.

Чтобы дешифровать базу (привести в исходное состояние) нужно выполнить

ALTER DATABASE DECRYPT

6.2 Шифрование столбцов

Внимание! В документации по InterBase слово decrypt используется в двух смыслах - как для операции, противоположной encrypt, так и для чтения зашифрованных данных. Для исключения путаницы далее я использую следующие слова: дешифрование - процесс, обратный шифрованию; расшифровка - процесс чтения зашифрованных данных.

Шифруем столбец STREET.NAME

ALTER TABLE STREET ALTER NAME ENCRYPT SNAME_DES

1625218 record(s) was(were) updated in STREET
1625218 record(s) was(were) deleted from STREET
1625218 record(s) was(were) inserted into STREET

А может и не выдать. Причины такого поведения не очень понятны. Кроме того, в таблице STREET на самом деле 812609 записей, т. е. в 2 раза меньше, чем в данном выводе. Один раз вместо 1625218 вышло 2437827, что в 3 раза больше.

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

Performance info ------
Prepare time = 0ms
Execute time = 16ms
Current memory = 70 035 744
Max memory = 72 140 480
Memory buffers = 8 192
Reads from disk to cache = 0
Writes from cache to disk = 0

Шифрование и дешифрование столбца, поскольку являются операциями alter table, увеличивают счетчик метаданных таблицы (счетчик форматов).

Как уже было сказано выше, если в базе данных зашифрованы только столбцы, а сама база данных не зашифрована, то в выводе gstat -h это никак не отражается. Увидеть признак "зашифрованности" столбца можно только в столбце RDB$ENCRYPTION_ID таблицы RDB$RELATION_FIELDS. В нем хранится код (порядковый номер) ключа шифрования из таблицы RDB$ENCRYPTIONS. Незашифрованные столбцы в этом поле содержат NULL.

Что интересно, для незашифрованного столбца можно выполнить дешифрование, и это займет упомянутое выше время. Вероятно, сервер некорректно обрабатывает null в rdb$encryption_id. К счастью, данные при таком псевдо-дешифровании не портятся.

Для зашифрованных столбцов функции MIN, MAX, BETWEEN и ORDER BY не смогут использовать индекс, поскольку в ключи индекса будут построены по зашифрованным данным (см. дальше).

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

ALTER TABLE STREET ALTER NAME DECRYPT

Значение по умолчанию при расшифровке

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

ALTER TABLE STREET ALTER COLUMN NAME DECRYPT DEFAULT ""

Если столбец дешифруется, то DECRYPT DEFAULT автоматически удаляется.

Проблема с поиском по индексу

Поиск без этого индекса, или по незашифрованному столбцу, проблем не имеет. Например, запрос

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

1 0 0 0 0 0 0 61 0 0 0 0 0 0 0 55 55

То есть, совершенно невразумительные результаты. С одной стороны, прослеживается некая "кратность 8", с другой стороны, непонятно, почему поиск по 1 символу выдал 1 (а не 76732), а по 17ти - выдал не 0, а то же, что и по 16ти.

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

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

6.3 Шифрование и базы, и столбцов

7. Выдача прав на чтение зашифрованных столбцов

CREATE USER TEST SET PASSWORD "test"

Дадим пользователю обычные права на чтение таблицы

GRANT SELECT ON STREET TO TEST

До тех пор, пока мы не будем выбирать столбец NAME, все будет хорошо. Однако, если мы напишем

select * from street

Или при явном перечислении выбираемых столбцов укажем NAME, то может быть два варианта:

1. получим сообщение

no permission for decrypt access to column NAME by user TEST
если для столбца не было задано DECRYPT DEFAULT

1. получим пустую строку вместо значений NAME, если для NAME было задано DECRYPT DEFAULT ""

GRANT DECRYPT (NAME) ON STREET TO TEST

Отобрать права можно командой

REVOKE DECRYPT (NAME) ON STREET FROM TEST

Производительность

select count(*) from street s

Результат получился примерно таким:

Здесь слева - время выполнения запроса в секундах. Надо сказать, что на чуть более старом процессоре (и другом железе) отличие получилось более существенным, хотя картина повторилась, например, если нешифрованную базу взять за 1, то зашифрованная была медленнее в 2.2 раз, столбец в 2 раза, и база+столбец - в 3.7 раз. На текущем компьтере максимальная разница не превысила 1.5 раз.

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

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

Backup

gbak: ERROR: -encrypt and -sep switches required to back up encryptions

gbak: ERROR: encryption DB_DES is not password-protected

CREATE ENCRYPTION dbackup for DES password "bbb"

И затем дать право использовать этот ключ тому, кто будет делать бэкап-рестор

GRANT ENCRYPT ON ENCRYPTION dbackup to SYSDBA;

Encrypt key_name

А при ресторе указывается пароль для этого ключа

Decrypt key_password

Таким образом, правильная команда

gbak -b n:\db\ibxe.ib n:\db\ibxe.ibk -user SYSDBA -pass sss -sep ""aaa"" -encrypt dbackup -se service_mgr -v

Обратите внимание на пароль для -sep - он указан в одинарных и снаружи еще и в двойных кавычках.

Restore

gbak -с n:\db\ibxe.ibk n:\db\ibxe.ib -user SYSDBA -pass masterkey -eua_u SYSDBA -eua_p sss -sep ""aaa"" -decrypt bbb -se service_mgr -v

Внимание! Каким-то образом по мере экспериментов у меня получилось сделать restore, только в самом конце вылезла ошибка про логин и пароль, а в базе не было ни EUA, ни пользователя SYSDSO, и так далее. Скорее всего, какой-то глюк.

Дополнения

• Для получения статистики БД (gstat -r ... или через Services API) даже на этом же компьютере почему-то требуется указание System Encryption Password. Для этого gstat имеет дополнительную опцию -sep
• Как выяснилось, SYSDBA не может сделать ничего "от имени" SYSDSO - попытки создать ключи, удалить ключи, выдать им гранты или напрямую редактировать системные таблицы в этом отношении будут выдавать ошибки типа

data security owner privilege required to encrypt or decrypt.
data security officer privilege required to modify encryption password
action cancelled by trigger (2) to preserve data integrity.
no permission for delete/write access to table RDB$ENCRYPTIONS by user SYSDBA

и т. д.
Однако, SYSDBA может выполнить единственную негативную операцию в отношении SYSDSO - это DROP USER SYSDSO. Как минимум, с целью создать этого пользователя заново с известным SYSDBA паролем, и далее манипулировать ключами "от имени SYSDSO.
Предполагается, что это баг .

• Если остались непонятные моменты - читайте Data Definition Guide, Глава 13, Encrypting Your Data . Это файл datadef.pdf в каталоге установки InterBase. Документация поставляется во всех дистрибутивах InterBase - Developer Edition, Trial, Server, и так далее. В крайнем случае, datadef.pdf (и другие книги, при необходимости), можно скачать .
• Если у вас есть вопросы по статье или предложения по тестированию зашифрованных баз, присылайте их на с темой "шифрование в InterBase".

Благодарности

Базит Фарук

Сообщения о потерях и несанкционированном доступе к конфиденциальным данным появляются все чаще, а значит безопасность баз данных - весьма актуальная проблема для многих компаний. Организации, в чьих базах данных хранится конфиденциальная информация, должны соблюдать требования многочисленных законодательных актов, в том числе Грэмма-Лича-Блайли (GLBA), директивы защиты данных ЕС (EUDPD), акта о преемственности и подотчетности медицинского страхования (HIPAA), стандарта безопасности данных индустрии платежных карт (PCI DSS) и закона Сарбейнса-Оксли (SOX). Эти законы требуют шифрования конфиденциальной информации на уровне базы данных и операционной системы. , как и другие распространенные коммерческие системы управления базами данных, располагает множеством вариантов шифрования, в том числе на уровне ячеек, базы данных и файлов через Windows, а также на транспортном уровне. Эти варианты шифрования обеспечивают безопасность информации на уровне базы данных и операционной системы. Кроме того, они снижают вероятность несанкционированного раскрытия конфиденциальных сведений, даже если поражены инфраструктура или база данных . После описания модели шифрования я рассмотрю возможности шифрования, реализованные в , а также способы шифрования конфиденциальной информации, сохраненной в базах данных .

Модель шифрования SQL Server

Теперь мы можем приступить к шифрованию данных. Для этого необходимо сначала открыть симметричный ключ, только что созданный с помощью команды OPEN SYMMETRIC KEY, за которой следует имя симметричного ключа. Затем вы указываете, что нужно расшифровать его с использованием заданного асимметричного ключа. Программный код выглядит следующим образом:

USE GO OPEN SYMMETRIC KEY MySymmetricKey DECRYPTION BY ASYMMETRIC KEY MyAsymmetricKey WITH PASSWORD = "StrongPa$$w0rd!" GO

После выполнения этого кода направьте запрос в представление sys.openkeys, чтобы убедиться, что ключ открыт:

USE GO SELECT * FROM .

Будут получены результаты, аналогичные показанным на рисунке 2. Наконец, необходимо ввести несколько номеров кредитных карт в таблицу CreditCardInformation, запустив код из листинга 2 . Затем направьте запрос к таблице CreditCardInformation:

USE GO SELECT * FROM .[ CreditCardInformation]

Как показано на рисунке 3, все данные в столбце CreditCardNumber представлены в двоичном формате. С помощью функции DECRYPTBYKEY можно просмотреть зашифрованные данные:

USE GO SELECT CONVERT((32), DECRYPTBYKEY(CreditCardNumber)) AS FROM . GO

Результаты показаны на рисунке 4.

Демонстрация 2. Во второй демонстрации данные шифруются с использованием асимметричного ключа, но на этот раз симметричный ключ шифруется сертификатом. Для этого выполните код из листинга 3 . Сначала создается сертификат с помощью инструкции CREATE CERTIFICATE. Затем создается симметричный ключ, шифруемый сертификатом. Наконец, открыв симметричный ключ, код вставляет три строки в таблицу CreditCardInformation.

Преимущества и недостатки шифрования на уровне ячеек

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

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

Прозрачное шифрование данных

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

Прозрачное шифрование данных шифрует базы данных в реальном времени, по мере внесения записей в файлы (*.mdf) базы данных и файлы (*.ldf) журнала транзакций. Записи также шифруются в реальном времени во время резервного копирования базы данных, а затем формируются моментальные снимки. Данные шифруются перед записью на диск и расшифровываются перед извлечением. Процесс полностью прозрачен для пользователя или приложения, поскольку выполняется на уровне SQL Server Service.

Листинг 1. Программный код для создания ключей для демонстрации 1

USE GO - Создание асимметричного ключа, зашифрованного - парольной фразой StrongPa$$w0rd! CREATE ASYMMETRIC KEY MyAsymmetricKey WITH ALGORITHM = RSA_2048 ENCRYPTION BY PASSWORD = "StrongPa$$w0rd!" GO - Создание симметричного ключа, зашифрованного - асимметричным ключом. CREATE SYMMETRIC KEY MySymmetricKey WITH ALGORITHM = AES_256 ENCRYPTION BY ASYMMETRIC KEY MyAsymmetricKey GO

Листинг 2. Программный код для заполнения таблицы CreditCardInformation

USE GO DECLARE @SymmetricKeyGUID AS SET @SymmetricKeyGUID = KEY_GUID("MySymmetricKey") IF (@SymmetricKeyGUID IS NOT NULL) BEGIN INSERT INTO . VALUES (01, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-1234-8765-4321")) INSERT INTO . VALUES (02, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-8765-8765-1234")) INSERT INTO . VALUES (03, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-1234-1111-2222")) END TRUNCATE TABLE .

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

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

USE GO - Создание сертификата. CREATE CERTIFICATE WITH SUBJECT = "Самозаверяющий сертификат для шифрования симметричного ключа." - Создание симметричного ключа, зашифрованного - сертификатом. CREATE SYMMETRIC KEY WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE - Открытие симметричного ключа. OPEN SYMMETRIC KEY DECRYPTION BY CERTIFICATE - Усечение таблицы CreditCardInformation. TRUNCATE TABLE . - Вставка данных в таблицу. DECLARE @SymmetricKeyGUID AS SET @SymmetricKeyGUID = KEY_GUID("SymmetricKeyEncryptedWithCert") IF (@SymmetricKeyGUID IS NOT NULL) BEGIN INSERT INTO . VALUES (01, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-1234-8765-4321")) INSERT INTO . VALUES (02, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-8765-8765-1234")) INSERT INTO . VALUES (03, ENCRYPTBYKEY(@SymmetricKeyGUID, N"9876-1234-1111-2222")) END