Согласно, официальной документации, архитектура Firebird 3 поддерживает плагины. Сторонние разработчики, используя предоставленное API Firebird, могут реализовывать собственные плагины. В отличии от Firebird, разработанные плагины – third party и могут иметь закрытый исходный код.
Используя предоставленные возможности, можно разработать плагины, которые помогают защищать БД, например, используя шифрование. В этом случае шифруются данные в файле БД. Если этот файл каким-то образом попадает в руки злоумышленника – то данные в нем в зашифрованном виде.
Но следует иметь в виду, что шифрование БД – это только один из необходимых элементов системы защиты информации. Если администратор имеет все необходимые ключи, пароли и полномочия для получения данных и модификации конфигурации системы – то одним лишь шифрованием сложно обойтись – требуется комплексный подход, который включает как технические, так и организационные меры.
Опять же, не забываем, что мы сейчас обсуждаем демонстрационный пример. И тут всё максимально просто. Вокруг этого можно много чего городить.
И мы не защищаемся, а защищаем хранимые данные как личное имущество. А защищать своё имущество можно по-разному, — можно просто дома хранить (но при этом мы дверь таки запираем), а можно и в банке в надёжном сейфе. И везде злоумышленник может преуспеть. Всё сводится к отношению стоимости затрат к стоимости желаемого.
Разбирать детали реализации слишком долго и можно написать об этом целую статью. Поэтому кратко по поводу перехвата на сервере ключа (в случае хранения БД на отдельном сервере):
клиентская часть на сервере недоступна, т.е. модуль активации принимающий ключ находится удалённо;
ключ передаётся в зашифрованном виде с помощью сессионных ключей (об этом в статье было);
ключ на серверном процессе извлекается именно во время процесса шифрования и это происходит в рамках динамического создания объекта для каждой сессии;
ключ даже в алгоритм шифрования передается в маскируемом виде и даже получение в маскируемом виде ключа, без наших ноу-хау ничего не даст;
запрет на чтение, это обычный саботаж и для этого используются административные способы, — например доступ к серверу для администрирования не единолично, а комиссионное.
Ключевым является безопасное хранение файла БД с доступом к данным только из определённого приложения. 7z архив же нужно будет распаковать/расшифровать и данные (то ли локально, то ли на сервере под властью сисадминов) будут храниться опять же открыто.
Что касаемо модели угроз, то можно просто сослаться на ряд стандартов безопасности, в которых явно идет речь о защите данных в БД (HIPAA, ISO/IEC 27001, FERPA, PCI-DSS).
Вот ссылка на презентацию, где есть об этом информация.
Но статья скорее ориентирована просто на описание пошагового применения и предполагает, что тот кому это применение применимо в его модели, то вот так вот это можно сделать.
По поводу: «От кого защищаемся?» — в статье есть слова: "… использует некий справочник (условно с конфиденциальными данными), который как обновляемый доступен по ссылке в глобальной сети. Его может СКАЧАТЬ КТО УГОДНО, но при этом расшифровать и работать с ним сможет только наше приложение." — вроде понятно, что угрозой является свободный доступ к файлу в глобальной сети. Защищаем данные от свободного доступа к ним, и, в этом конкретном описании, никак не от легального пользователя приложения.
Можно конечно спорить по поводу применимости такого решения, но это было самым простым из того, что можно было продемонстрировать.
Вопрос создания БД с различными параметрами выходит за рамки этой статьи, поэтому указан самый простой, тестовый пример. Основной упор сделан на демонстрацию возможностей использования шифрования БД.
Используя предоставленные возможности, можно разработать плагины, которые помогают защищать БД, например, используя шифрование. В этом случае шифруются данные в файле БД. Если этот файл каким-то образом попадает в руки злоумышленника – то данные в нем в зашифрованном виде.
Но следует иметь в виду, что шифрование БД – это только один из необходимых элементов системы защиты информации. Если администратор имеет все необходимые ключи, пароли и полномочия для получения данных и модификации конфигурации системы – то одним лишь шифрованием сложно обойтись – требуется комплексный подход, который включает как технические, так и организационные меры.
И мы не защищаемся, а защищаем хранимые данные как личное имущество. А защищать своё имущество можно по-разному, — можно просто дома хранить (но при этом мы дверь таки запираем), а можно и в банке в надёжном сейфе. И везде злоумышленник может преуспеть. Всё сводится к отношению стоимости затрат к стоимости желаемого.
Разбирать детали реализации слишком долго и можно написать об этом целую статью. Поэтому кратко по поводу перехвата на сервере ключа (в случае хранения БД на отдельном сервере):
Вот ссылка на презентацию, где есть об этом информация.
Но статья скорее ориентирована просто на описание пошагового применения и предполагает, что тот кому это применение применимо в его модели, то вот так вот это можно сделать.
По поводу: «От кого защищаемся?» — в статье есть слова: "… использует некий справочник (условно с конфиденциальными данными), который как обновляемый доступен по ссылке в глобальной сети. Его может СКАЧАТЬ КТО УГОДНО, но при этом расшифровать и работать с ним сможет только наше приложение." — вроде понятно, что угрозой является свободный доступ к файлу в глобальной сети. Защищаем данные от свободного доступа к ним, и, в этом конкретном описании, никак не от легального пользователя приложения.
Можно конечно спорить по поводу применимости такого решения, но это было самым простым из того, что можно было продемонстрировать.