Контакты
IBSurgeon
Эта страница переведена машинным переводом. Читайте английский оригинал. English

Библиотека IBSurgeon

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

(c) Алексей Ковязин, IBSurgeon, Алекс Пешков, Firebird Project, 2021

Статья основана на материалах семинара «Шифрование баз данных» на конференции Firebird Conference 2019 в Берлине, Германия. В ней описывается, как работает шифрование базы данных Firebird на уровне сервера и на стороне клиента, как настроить шифрование базы данных и как использовать его из различных типов приложений (Delphi, Java, .NET). Примеры в статье основаны на IBSurgeon Firebird Encryption Framework (FEPF), но могут быть адаптированы для большинства существующих реализаций плагинов шифрования.

Содержание:

  1. Зачем нужно шифрование базы данных (и когда оно не нужно)?
  2. Как работает шифрование базы данных Firebird на стороне сервера
  3. Какая часть базы данных шифруется?
  4. Когда страницы данных шифруются?
  5. Как защитить передачу ключей?
  6. Как работает шифрование Firebird на стороне клиента
  7. Нативные приложения
  8. Java-приложения
  9. .NET-приложения
  10. Установка и настройка
  11. Как отслеживать прогресс шифрования
  12. Резюме

1. Зачем нужно шифрование базы данных (и когда оно не нужно)?

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

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

Итак, зачем нужно шифрование базы данных?

  1. Для защиты баз данных с чувствительными/ценными данными от «физического» хищения. Если злоумышленник украдет диск с копией зашифрованной базы данных или каким-либо образом получит копию файла базы данных, прочитать данные из нее без соответствующего ключа будет невозможно, как и использовать программное обеспечение для восстановления, например FirstAID, для извлечения данных. Конечно, это зависит от алгоритма шифрования и вычислительной мощности, но взлом AES256 потребует слишком много времени или слишком дорогих вычислительных ресурсов.
  2. Для защиты базы данных от доступа неавторизованных приложений без ключей шифрования. Примеры:
    • прямой доступ с помощью инструмента разработчика неавторизованным лицом для изменения чувствительной информации (например, денежных транзакций),
    • изменение или кража бизнес-логики (текстов хранимых процедур и триггеров).
  3. Защита баз данных с предварительно заполненными данными от экспорта или доступа неавторизованных приложений.
  4. Правительства недавно ввели законы о защите данных (GDPR/DSVGO в Европе, LGPD в Бразилии и т. д.), которые требуют, среди прочего, более высокого уровня защиты персональных и других чувствительных данных, и шифрование упоминается как одна из адекватных мер защиты.

Когда шифрование базы данных не полезно?

В некоторых случаях лучше использовать возможности безопасности и конфигурации Firebird вместо шифрования базы данных:

  • Для защиты базы данных от физического доступа по сети необходимо настроить сетевой доступ: то есть закрыть сетевые общие папки, поскольку Firebird не требует сетевого общего доступа к файлам базы данных, и ужесточить права безопасности (например, для Linux файлы базы данных должны иметь доступ на чтение и запись только для пользователя «firebird»).
  • Чтобы ограничить доступ к конкретной базе данных для конкретного подмножества пользователей, более простым решением будет настройка отдельной базы данных безопасности.
  • Чтобы ограничить доступ к объектам базы данных (таблицам, хранимым процедурам), необходимо использовать механизмы безопасности Firebird: пользователей, роли и т. д.

Конечно, оба приведенных выше списка неполны, но они дают некоторое представление о том, когда нужно или не нужно шифрование базы данных.

2. Как работает шифрование базы данных Firebird на стороне сервера

Давайте рассмотрим внутренние детали шифрования базы данных Firebird и начнем с серверной части.

2.1. Какая часть базы данных шифруется?

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

Ниже вы можете увидеть рисунок с основными типами данных:

Рисунок 1. Типы страниц базы данных

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

Когда база данных Firebird шифруется, шифруются только страницы с пользовательскими данными: страницы данных, индексы, генераторы и BLOB-объекты:

Рисунок 2. Шифруются только страницы базы данных с пользовательскими данными

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

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

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

2.2. Когда страницы данных шифруются?

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

Рассмотрим детали этого процесса:

Рисунок 3. Когда страницы базы данных шифруются?

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

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

После этого Firebird считывает страницы и помещает их в кэш страниц Firebird (он определяется параметром DefaultDBCachePages в firebird.conf и/или databases.conf или в странице заголовка базы данных).

Затем страницы из кэша выбираются в результирующий набор конкретного SQL-оператора (SELECT в нашем примере).

На рисунке ниже показаны детали:

Рисунок 4. Страницы шифруются между кэшем Firebird и файловым кэшем ОС

Итак, страницы базы данных шифруются в файловом кэше ОС, но поступают в кэш страниц Firebird в незашифрованном виде, и наоборот.

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

На рисунке ниже вы можете увидеть варианты для Windows (DbCrypt.dll) и Linux (libDbCrypt.so):

Рисунок 5. Плагин шифрования (DbCrypt) выполняет шифрование/дешифрование

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

Ответ - существует еще один плагин для управления ключами.

Типичное название для управления ключами - KeyHolder, который служит хранилищем/средством управления ключами для плагина шифрования (DbCrypt). KeyHolder реализует интерфейс для управления ключами, который используется DbCrypt.

Рисунок 6. DbCrypt и KeyHolder

Что означает «управление ключами»?

В простейшем случае DbCrypt может читать ключи из файла на сервере. Файл может быть простым текстовым файлом, который можно спрятать в «секретном» месте или на USB-накопителе, либо может быть зашифрованным файлом (например, с использованием Windows Crypto API или со встроенным внутренним ключом).

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

Code 
Key=Red 0xec,0xa1,0x52,0xf6,0x4d,0x27,0xda,0x93,0x53,0xe5,0x48,0x86,0xb9,0x7d,0xe2,0x8f,0x3b,0xfa,0xb7,0x91,0x22,0x5b,0x59,0x15,0x82,0x35,0xf5,0x30,0x1f,0x04,0xdc,0x75,
Key=Green 0xab,0xd7,0x34,0x63,0xae,0x19,0x52,0x00,0xb8,0x84,0xa3,0x44,0xbd,0x11,0x9f,0x72,0xe0,0x04,0x68,0x4f,0xc4,0x89,0x3b,0x20,0x8d,0x2a,0xa7,0x07,0x32,0x3b,0x5e,0x74,

Когда база данных зашифрована, ее страницы заголовка остаются незашифрованными, чтобы хранить информацию о плагине шифрования и имени ключа, и эту информацию можно увидеть с помощью команды “gstat -h databasename”:

Code 
Database header page information:
....
Creation date    Jan 11, 2017 15:12:20
Attributes       force write, encrypted, plugin DBCRYPT

Variable header data:
 Crypt checksum: MUB2NTJqchh9RshmP6xFAiIc2iI=
 Key hash:       ask88tfWbinvC6b1JvS9Mfuh47c=
 Encryption key name:    RED
 Sweep interval:         0
*END*

DbCrypt может обрабатывать страницы для нескольких баз данных и нескольких ключей:

Рисунок 7. Несколько ключей для нескольких баз данных на одном сервере (т.е. экземпляре Firebird)

Выбор правильного ключа

Часто разработчики задают вопрос: «Как плагин распознает, какой ключ для какой базы данных?» Ответ довольно прост: по имени ключа, которое хранится на странице заголовка базы данных.

Реже, но все же важный вопрос - что если имя ключа будет таким, как записано в заголовке, но значение ключа отличается? Чтобы предотвратить ошибки чтения страниц из-за неправильного ключа, плагин DbCrypt хранит зашифрованную тестовую последовательность (цифры 0…F) в заголовке, и затем, когда ключ активируется, плагин пытается зашифровать образец данных с помощью ключа и сравнить его хэш с сохраненным результатом, чтобы убедиться, что переданное значение ключа действительно корректно для этой конкретной базы данных.

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

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

Для этого нам нужен плагин KeyHolder, чтобы получить ключ от клиентского приложения (которое обычно находится на другом компьютере) через сетевой протокол Firebird.

2.3. Как защитить передачу ключа?

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

Это эквивалентно ситуации, когда злоумышленник имеет доступ к серверу, но не имеет ключей.

Рассмотрим следующие сценарии атак для перехвата ключей на стороне сервера:

  1. Когда злоумышленник создает поддельный плагин шифрования (DBCrypt.dll) и размещает его на сервере, и когда KeyHolder передает ключ, поддельный DbCrypt делает дамп ключа:

Рисунок 8. Атака с поддельным DbCrypt.dll

  1. Когда злоумышленник создает поддельный файл firebird.exe и делает дамп с его помощью:

Рисунок 9. Атака с поддельным firebird.exe

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

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

Эти ключи генерируются в процессе сборки и встроены в конкретную пару плагинов шифрования и управления ключами. Для наилучшей защиты необходимо использовать специально собранные пары DbCrypt/KeyHolder.

Когда DbCrypt и KeyHolder обмениваются ключами, они используют следующий протокол (он упрощен, но идея ясна, я полагаю):

Code 
DbCrypt → KeyHolder:
	Дай мне ключ базы данных с этой солью
KeyHolder:
	Шифрует DbKey открытым ключом, используя соль от DbCrypt
	Передает зашифрованный DbKey в DbCrypt
DbCrypt:
	Расшифровывает DbKey закрытым ключом
	Проверяет корректность соли
	Готов к работе

Более или менее тот же протокол используется для обмена ключами между экземплярами KeyHolder и для обмена ключами между клиентским приложением и KeyHolder.

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

Резюме для серверной части шифрования

  • Шифрование/дешифрование выполняется плагином шифрования базы данных (DbCrypt), страница за страницей, во время обмена данными между файловым кэшем операционной системы и кэшем страниц Firebird
  • Управление ключами может быть реализовано простым способом, когда DbCrypt читает ключи напрямую, но обычно это делается с помощью плагина управления ключами (KeyHolder)

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

3. Как работает шифрование Firebird на стороне клиента

3.1. Нативные приложения

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

Обратите внимание: отсюда и далее «нативный» означает, что такое приложение устанавливает сетевое соединение с сервером с использованием fbclient.dll; обычно такое приложение создано на Delphi, C++, PHP. В отличие от нативных приложений, Java и .NET реализуют собственную версию протокола, они будут рассмотрены ниже.

Процесс подключения:

  1. Клиентское приложение загружает клиентскую библиотеку
  2. fbclient.dll - нативные приложения Windows
  3. libfbclient.so - нативные приложения Linux
  4. Клиентское приложение инициирует подключение, отправляя
  5. Имя пользователя, например, SYSDBA
  6. Пароль, например, masterkey
  7. Путь/алиас базы данных

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

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

Итак, это приводит нас к следующему:

  1. Дополнительный сетевой обход необходим для передачи ключа перед обычным подключением
  2. Передача ключа от клиентского приложения к Firebird требует кодирования с использованием асимметричного шифрования и реализации интерфейса обратного вызова, что может быть довольно сложным. Чтобы упростить эту задачу, поставщики плагинов предоставляют пример кода для подключения или, как во фреймворке плагинов IBSurgeon, создают дополнительную библиотеку fbcrypt.dll/libfbcrypt.so, которая реализует простой в использовании подходящий интерфейс для передачи ключей от клиентского приложения.

Чтобы подключить нативное приложение (которое использует fbclient.dll) к зашифрованной базе данных, необходимо выполнить 3 вызова. Ниже приведён пример на Delphi (упрощённый, без обработки ошибок):

В обработчике события BeforeConnect:

Code 
fbcrypt_init(PAnsiChar(‘C:\Firebird30.bclient.dll’));
fbcrypt_key(‘RED’, ‘0xec,0xa1,0x52,0xf6,...’));
fbcrypt_callback(nil);

 // Затем подключиться как обычно
Database1.Active:=True;

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

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

А как насчёт потокобезопасности в случае многопоточных клиентских приложений?

Позвольте мне напомнить некоторые общие моменты реализации многопоточных клиентских приложений.

Начиная с Firebird 2.5, несколько потоков внутри приложения могут безопасно использовать одно подключение к базе данных, поскольку вся необходимая синхронизация выполняется внутри fbclient.dll.

Однако в этом случае потоки смогут работать с подключением только по одному.

Это нормально для приложений, которым не требуется высокопроизводительный обмен данными с базой данных - если не является проблемой ожидание выполнения SQL-запроса из одного потока, когда другой поток выполняет другой SQL, проще использовать простую модель, когда 1 подключение разделяется между несколькими потоками.

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

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

При каждом подключении клиентская библиотека передаёт ключи от клиента, но это не связано напрямую с потоками в клиентском приложении - ситуация зависит от используемого API.

Как известно, клиентская библиотека Firebird начиная с версии 3.0 предлагает 2 типа API: новый объектно-ориентированный API, основанный на концепции провайдеров, и устаревший isc_ API, реализованный как обходное решение для поддержания совместимости со старыми драйверами Firebird.

Если используется новый объектно-ориентированный клиентский API, достаточно создать провайдер, снабдить его необходимыми ключами, а затем использовать его для новых подключений.

Если используется isc_ клиентский API, для каждого подключения клиентская библиотека создаст свой собственный временный провайдер, который напрямую не виден и не доступен конечному пользователю.

В этом случае ключ передаётся именно из того потока, где вызывается isc_attach_database, и для хранения этого ключа используется локальное хранилище потока.

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

Вызовы передачи ключей (вызовы fbcrypt.dll в примере FEPF) должны выполняться до подключения, в том же потоке, где будет установлено подключение.

Когда мы работаем с множеством баз данных (например, SaaS-веб-сервер с множеством клиентских баз данных), важно помнить, что каждый вызов fbcrypt_key() добавляет ключ в хранилище KeyHolder, связанное с текущим подключением.

Значения ключей должны быть установлены до подключения; после установки подключения значение ключа не может быть изменено.

В случае отсоединения ключи не выгружаются, они будут храниться в памяти до выгрузки fbcrypt.dll.

3.2. Java-приложения

Java-драйвер (JayBird) имеет собственную реализацию (на чистой Java) протокола подключения Firebird. Jaybird 4 (и 3.0.4+) добавляет поддержку обратных вызовов шифрования базы данных Firebird 3 в реализации на чистой Java протокола версии 13.

Из Readme Jaybird 4:

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

Будущие версии Jaybird (вероятно, 5) введут поддержку плагинов для плагинов шифрования базы данных, требующих более сложного обратного вызова.”

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

Например:

Code 
 edConnectionString.setText("jdbc:firebirdsql://localhost/g:/Databases/ODS12/crypt.fdb?lc_ctype=utf8&dbCryptConfig=MyKey:0xec,0xa1,0x52,0xf6,0x4d,0x27,0xda,0x93,0x53,0xe5,0x48,0x86,0xb9,0x7d,0xe2,0x8f,0x3b,0xfa,0xb7,0x91,0x22,0x5b,0x59,0x15,0x82,0x35,0xf5,0x30,0x1f,0x04,0xdc,0x75,");

Также можно указать строку в base64 - из readme:

“ Строки с префиксом base64:: остальная часть строки декодируется из base64 в байты.

Символы заполнения = необязательны, но если они присутствуют, они должны быть допустимыми (то есть: если вы используете заполнение, вы должны использовать правильное количество символов заполнения для длины).

Когда значение в base64 содержит +, оно должно быть экранировано как %2B в JDBC URL. Для обратной совместимости с Jaybird 3 мы не можем переключиться на URL-безопасный вариант base64.“

В реализации IBSurgeon плагина управления ключами такая передача ключа считается более или менее небезопасной: если шифрование сетевого протокола не включено ( кстати, чтобы включить его, установите в firebird.conf WireCrypt=Required и не используйте устаревшую аутентификацию), ключ можно легко обнаружить с помощью анализатора сетевого трафика, такого как WireShark, поэтому для включения передачи ключей таким способом необходимо установить UnsafeClient=true в KeyHolder.conf плагина управления ключами IBSurgeon.

3.3 .NET-приложения

Провайдер Firebird.NET реализует аналогичную схему обмена ключами для зашифрованных баз данных и также требует установки параметра UnsafeClient=true в KeyHolder.conf в FEPF.

Пример .NET строки подключения для зашифрованных баз данных:

Code 
string connectionString =
                "User=SYSDBA;" +
                "Password=masterkey;" +
                "Database=G:\\Databases\\ODS12.RYPT.FDB;" +
                "DataSource=localhost;" +
                "Port=3053;" +
                "Dialect=3;" +
                "Charset=NONE;" +
                "Role=;" +
                "Connection lifetime=15;" +
                "Pooling=true;" +
                "MinPoolSize=0;" +
                "MaxPoolSize=50;" +
                "Packet Size=8192;" +
                "ServerType=0;" +
                 "cryptkey = TXlLZXk6MHhlYywweG…...;";

Вы можете заметить, что ключ шифрования выглядит иначе, чем в примере для нативных приложений и JayBird, это потому, что он является результатом преобразования Base64, поэтому чтобы получить ключ для .NET или Java-приложения, необходимо вычислить base64 из строки:

“MyKey:0xec,0xa1,0x52,0xf6,0x4d,0x27,0xda,0x93,0x53,0xe5,0x48,0x86,0xb9,0x7d,0xe2,0x8f,0x3b,0xfa,0xb7,0x91,0x22,0x5b,0x59,0x15,0x82,0x35,0xf5,0x30,0x1f,0x04,0xdc,0x75,”

и использовать его как параметр для “cryptkey=xxx;” с “;” в конце строки подключения.

4. Установка и настройка

Чтобы включить шифрование базы данных и плагин управления ключами, необходимо указать имя плагина шифрования в файле конфигурации Firebird firebird.conf:

Code 
 KeyHolderPlugin = KeyHolder

Или, альтернативно, в databases.conf, для алиаса зашифрованной базы данных:

Code 
myencrypted = C:\Temp\EMPLOYEE30.MPLOYEE30.FDB { KeyHolderPlugin = KeyHolder }

Затем необходимо проверить, что все файлы, необходимые для плагина, находятся на сервере.

Пример ниже приведён для FEPF от IBSurgeon, но другие плагины более или менее похожи:

в %FirebirdFolder$\plugins

Code 
    • DbCrypt.dll
    • DbCrypt.conf
    • KeyHolder.dll
    • KeyHolder.conf - только для режима отладки!

В %FirebirdFolder$

Code 
    • fbcrypt.dll
    • libcrypto-1_1-x64.dll
    • libssl-1_1-x64.dll
    • firebird.msg

После этого мы можем выполнить тестовое шифрование на сервере. Для этого в isql:

Code 
isql.exe localhost:C:\Temp\EMPLOYEE30.MPLOYEE30.FDB -user SYSDBA -pass masterkey
SQL>alter database encrypt with dbcrypt key red;
SQL> show database;
Database: localhost:C:\Temp\EMPLOYEE30.MPLOYEE30.FDB
….
ODS = 12.0
Database encrypted
Default Character set: NONE

Если вы работаете в Linux, помните, что регистр символов важен, поэтому команда будет:

Code 
alter database encrypt with "DbCrypt" key Red;

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

Для этого мы должны поместить в папку с клиентским приложением следующие файлы:

  • Демо-приложение из FEPF - CryptTest.exe (32bit)
  • Обязательные файлы:
    • fbclient.dll
    • fbcrypt.dll
    • libcrypto-1.1.dll
    • libssl-1.1-x64.dll
  • Необязательные файлы:
    • firebird.conf
    • в plugins
    • ◦ KeyHolder.conf
    • ◦ keyhodler.dll

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

Это обеспечивает прозрачную работу инструментов разработчика Firebird (таких как Firebird SQL Studio, DatabaseWorkbench, IBExpert, FlameRobin, RedExpert и т.д.) и прозрачное использование инструментов командной строки Firebird (gfix.exe, nbackup.exe и т.д.).

5. Как отслеживать прогресс шифрования

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

Чтобы отслеживать процесс шифрования, выполните SQL-запрос из MON$:

Code 
select mon$crypt_page * 100.0 / mon$pages as Percent from mon$database;
commit;

или выполните инструмент gstat со специальным переключателем:

Code 
gstat -e dbname

Database "D:\ENCDB\TESTENCRYPT.FDB"
Gstat execution time Tue Mar 16 11:45:11 2021

Database header page information:
        Flags                   0
        Generation              10697
        System Change Number    3
        Page size               8192
        ODS version             12.0
        Oldest transaction      7053
        Oldest active           7054
        Oldest snapshot         7054
        Next transaction        7054
        Sequence number         0
        Next attachment ID      17834
        Implementation          HW=Intel/i386 little-endian OS=Windows CC=MSVC
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Oct 9, 2019 6:42:31
        Attributes              encrypted, plugin DBCRYPT

    Variable header data:
        Database backup GUID:   {866B4967-ED58-427E-A481-DB9206CEA2ED}
        Crypt checksum: MUB2NTJqchh9RshmP6xFAiIc2iI=
        Key hash:       ask88tfWbinvC6b1JvS9Mfuh47c=
        Encryption key name:    RED
        Database GUID:  {323FE494-1771-4608-E99D-C1B69C84578B}
        *END*

Data pages: total 105, encrypted 105, non-crypted 0
Index pages: total 95, encrypted 95, non-crypted 0
Blob pages: total 0, encrypted 0, non-crypted 0
Generator pages: total 1, encrypted 1, non-crypted 0
Gstat completion time Tue Mar 16 11:45:11 2021

Обратите внимание, что выполнение gstat может занять длительное время.

6. Резюме

  1. Шифрование базы данных Firebird - это мощная функция для защиты информации в базах данных от несанкционированного доступа.
  2. Процесс шифрования требует серверную динамическую библиотеку - плагин шифрования (обычно называемый DbCrypt), и в подавляющем большинстве случаев плагин управления ключами (обычно называемый KeyHolder).
  3. Безопасная и надежная реализация плагинов DbCrypt и KeyHolder должна учитывать наиболее распространенные типы атак.
  4. Для работы с зашифрованной базой данных клиентские приложения должны передавать ключ шифрования.
  5. Установка и настройка плагина шифрования на серверной стороне тривиальна: требуется 1 параметр в firebird.conf/databases.conf и несколько файлов.
  6. Процесс шифрования может быть длительным, он выполняется в отдельном фоновом потоке, прогресс можно отслеживать с помощью вызова MON$ или gstat.

Что дальше?

Мы работаем над детальным тестом производительности шифрования базы данных Firebird. В целом производительность снижается на 4-8%, но это зависит от аппаратного обеспечения и настроек Firebird. Следите за обновлениями!

Свяжитесь с нами:

Пожалуйста, отправляйте свои предложения, опечатки, ошибки и любые вопросы по электронной почте: [email protected]