Pull to refresh

Comments 32

Извините, но создавать БД просто «create database 'TESTDB';» без указания параметров аукнется.
Вопрос создания БД с различными параметрами выходит за рамки этой статьи, поэтому указан самый простой, тестовый пример. Основной упор сделан на демонстрацию возможностей использования шифрования БД.

Delphi, C++ Builder, Firebird… извиняюсь, конечно, но как будто статья из 2004.

У молодежи всегда складывается впечатление, что технологии, которые запустились раньше их трудовой карьеры — дикое устаревшее старье :) Про то, что цикл жизни ERP и прочего энтерпрайза составляет лет 20, мало кто знает.
Любого студента ИБ на первом курсе учат:
1. Опишите модель угроз!

Без этого — зачем всё вышеизложенное?
От кого защищаемся? Если от легального пользователя приложения, что ему мешает в WinDBG поставить breakpoint на ф-цию SetKey и немедленно получить ключ?

Пока не вижу пользы, одно только прожигание электроэнергии клиента и сервера на бесполезное шифрование.
Что касаемо модели угроз, то можно просто сослаться на ряд стандартов безопасности, в которых явно идет речь о защите данных в БД (HIPAA, ISO/IEC 27001, FERPA, PCI-DSS).

Вот ссылка на презентацию, где есть об этом информация.

Но статья скорее ориентирована просто на описание пошагового применения и предполагает, что тот кому это применение применимо в его модели, то вот так вот это можно сделать.

По поводу: «От кого защищаемся?» — в статье есть слова: "… использует некий справочник (условно с конфиденциальными данными), который как обновляемый доступен по ссылке в глобальной сети. Его может СКАЧАТЬ КТО УГОДНО, но при этом расшифровать и работать с ним сможет только наше приложение." — вроде понятно, что угрозой является свободный доступ к файлу в глобальной сети. Защищаем данные от свободного доступа к ним, и, в этом конкретном описании, никак не от легального пользователя приложения.

Можно конечно спорить по поводу применимости такого решения, но это было самым простым из того, что можно было продемонстрировать.
То есть сценарий, когда порт СУБД выставлен наружу в сеть.
Но в этом случае есть защита логином/паролем + шифрование соединения, появившееся в FB 3.

Пока это выглядит как слой дополнительный защиты. С одной стороны, перестраховка от неизвестных уязвимостей FB. С другой стороны, такой подход в безопасности как «вроде оно уже защищено, но давайте на всякий случай добавим ещё один слой» — не приветствуется.
Да нет, тут не имелось ввиду использования СУБД с доступом из глобальной сети. Просто показано, что файл с БД можно не опасаясь хранить где-угодно.
Или сценарий, когда по HTTP выставлен файл БД (очень странный сценарий для БД)?
В этом случае, достаточно положить в 7z-архив с паролем, и не городить столько сложностей.
Мне стала интересна ваша полемика. Хочу добавить немного слов в защиту автора. Современные СУБД Enterprise уровня (Oracle DB Ent., Oracle MySQL Ent., Microsoft SQLServer Ent., даже MongoDB) обладают такой функцией, как TDE (transparent data encryption), которая подразумевает прозрачное шифроврование табличного пространства. Эти все навороты направлены на удовлетворене неких требований HIPAA, PCI-DSS. Думаю, что если попросить автора подготовить отдельную статью по поводу разбора угроз, которые покрываются данным решением, будет корректнее.
«Рубится» относительно корретности предложенного примера, соглашусь, что он не сильно удачный :-)
Могу предложить более удачный:
  • вы разработчик грфического редактора, у которого есть некие фильтры, которые красиво преобразуют вашу картинку
  • параметры этих фильтров храняться в шифрованной БД (она может быть, как локальной, так и развернутой на выделенном сервере)
  • ключ шифрования, как-то привязан к вашему коду активации графического редактора


Теперь, что получается… что только авторизованный пользователь приложения пользуется этим приложением и конкуренты не смогут «легко» украсть эти параметры.
Теперь, что получается… что только авторизованный пользователь приложения пользуется этим приложением и конкуренты не смогут «легко» украсть эти параметры.
Купить одну копию приложения никак нельзя? ))
Купить одну копию приложения никак нельзя? ))

Вопрос в том, что купить как раз и можно! Вот только значения коэфциентов, хранящиеся в БД получить нельзя, т.к. пользователь легитимно владеющий Графическим редактором не может получить доступ к содержимому БД, т.е. к коэфициентам.

То есть алгоритм запускается на машине пользователя, «секретные коэффициенты» находятся в памяти, но получить их нельзя, потому что недостаточно навыков реверс-инженеринга, так?

Тут можно сказать, что и алгоритм заполучить нельзя, потому что исходников программы нет ))

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

Приятно общаться с человеком, который готов "сражаться" за свое мнение :-)
Вопрос reverse-engineering действительно актуален, и здесь даже очень серьезные компании с огромными финансовыми и человеческими ресурсами ничего не могут сделать, т.к. сложность защиты от reverse-engineering достаточно высока.
Идея которая эксплуатируется у автора полностью аналогична решению TBD от Oracle DB, Microsoft SQLServer, MongoDB, Oracle MySQL Enterprise и позволяет лишь существенно усложнить задачу reverse-engineering, не более того.
Насколько мне не изменяет память, то сложность этой задачи (защиты от reverse-engineering) определяется механизмами защиты в ОС (Windows или Linux).


Теперь по поводу примера прикладного применения в графическом редакторе с коэффициентами: я видел преподов, которые на глаз определяли правильность коэффициентов в матрицы 20х20 фильтра для картинки на лабораторной работе… Возможность их интерпретации думаю существуют :-)


Предлагаю остановиться на том, что та же HIPAA (я не поленился нашел о чем говорит автор) https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act
там есть в разделе: Technical Safeguards


Information systems housing PHI must be protected from intrusion. When information flows over open networks, some form of encryption must be utilized. If closed systems/networks are utilized, existing access controls are considered sufficient and encryption is optional.

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

Предлагаю остановиться на том, что та же HIPAA
When information flows over open networks, some form of encryption must be utilized. If closed systems/networks are utilized, existing access controls are considered sufficient and encryption is optional.
Это значит, что предложенная в статье разработка не нужна для соответствия процитированным требованиям. Встроенного в FB 3.0 Wire Encryption уже достаточно.
Ключевым является безопасное хранение файла БД с доступом к данным только из определённого приложения. 7z архив же нужно будет распаковать/расшифровать и данные (то ли локально, то ли на сервере под властью сисадминов) будут храниться опять же открыто.
Опять же, от кого защищаемся? От сисадминов?
Или от злоумышленника, имеющему доступ к серверу? Если он имеет доступ администратора, он перехватит ключи из памяти. А если не имеет такого доступа, достаточно настроить запрет чтения файла.
Опять же, не забываем, что мы сейчас обсуждаем демонстрационный пример. И тут всё максимально просто. Вокруг этого можно много чего городить.

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

Разбирать детали реализации слишком долго и можно написать об этом целую статью. Поэтому кратко по поводу перехвата на сервере ключа (в случае хранения БД на отдельном сервере):
  • клиентская часть на сервере недоступна, т.е. модуль активации принимающий ключ находится удалённо;
  • ключ передаётся в зашифрованном виде с помощью сессионных ключей (об этом в статье было);
  • ключ на серверном процессе извлекается именно во время процесса шифрования и это происходит в рамках динамического создания объекта для каждой сессии;
  • ключ даже в алгоритм шифрования передается в маскируемом виде и даже получение в маскируемом виде ключа, без наших ноу-хау ничего не даст;
  • запрет на чтение, это обычный саботаж и для этого используются административные способы, — например доступ к серверу для администрирования не единолично, а комиссионное.
И мы не защищаемся, а защищаем хранимые данные как личное имущество.
Примерно так я и написал выше — ничего принципиально нового нет, добавляется ещё один уровень защиты, который добавляет нервотрёпки взломщику, но не закрывает какие-то векторы атаки, если они были открыты.

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

Ясно, что криптомодуль взаимодействует с СУБД через публичные API, их и надо атаковать.

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

Да ещё проще, если сделать бекап через gbak, gbk-файл будет незашифрованным.

Вся инфраструктура сама всё сделает. Всё равно, что «взломать» truecrypt обычной командой copy с зашифрованного диска на незашифрованный.

запрет на чтение, это обычный саботаж и для этого используются административные способы, — например доступ к серверу для администрирования не единолично, а комиссионное.
Это интересно, но для Windows Server я таких решений не знаю.
С открытыми исходниками FB, админу даже ничего реверсить и внедряться не надо. Достаточно собрать особую сборку сервера, которая после прохождения авторизации по некоторому сигналу отключится от одного сокета и подключится к другому, где её будет ждать gbak.
Согласно, официальной документации, архитектура Firebird 3 поддерживает плагины. Сторонние разработчики, используя предоставленное API Firebird, могут реализовывать собственные плагины. В отличии от Firebird, разработанные плагины – third party и могут иметь закрытый исходный код.

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

Но следует иметь в виду, что шифрование БД – это только один из необходимых элементов системы защиты информации. Если администратор имеет все необходимые ключи, пароли и полномочия для получения данных и модификации конфигурации системы – то одним лишь шифрованием сложно обойтись – требуется комплексный подход, который включает как технические, так и организационные меры.
Вопрос в том, можно ли достичь той же степени безопасности только орг. мерами.
UFO just landed and posted this here
Головная боль как раз в том, что доступ к БД есть у всякого по сути, благодаря известным всем паролям.
Тогда gbak, можно с другой машины, и получаем нешифрованную БД
UFO just landed and posted this here
Что бы сделать бекап вначале придется расшифровать БД, не так ли?
Я может не понял это высказывание:
доступ к БД есть у всякого по сути, благодаря известным всем паролям
То есть это надо внедрить квалифицированного взломщика внутрь сети. А не просто скопировать файл на флешку или переслать его через почту.
Копируй базу вместе с клиентским приложением, и из него можно наколупать пароли.
UFO just landed and posted this here
Давно пользуюсь этой СУБД в своих проектах, пока не подводила… Замечу, что ядро разработчиков составляют ребята из России. Наверное многие будут говорить о наиболее популярных СУБД MySQL, PostgreSql и другие, но следует заметить, что для каждой задачи следует подбирать соответствующие инструменты…
Я вот знаю, что компания RedSoft использует свой клон Firebird под названием RedDatabase. И используется в целом ряде федеральных агентств и служб. И все познается в сравнении.
Предложу redmanmale попробовать Firebird 3.0, а вдруг понравится.

Много лет писал под FB, потом сменил работу, проекты, теперь в основном MSSQL, иногда MySQL. Ну что сказать, до сих пор вспоминаю IBExpert, невероятно удобный в сравнении с SSMS. Да и PSQL против T-SQL выигрывает просто на голову в логичности и возможностях языка.


Но у FB (по крайней мере до 2.5, на котором я закончил) были серьезные проблемы с масштабированием. Нельзя было просто взять докинуть ресурсов на сервер и дальше ворочать многогигабайтную базу сложной структуры. Как с этим дела в 3.0?

Признаюсь честно, что приходиться работать с БД под управлением СУБД Firebird 2.5.2 и СУБД Firebird 3.0.1 с размером от 1 ГБ и не более 10 ГБ. Сложность БД не очень, но содержит много BLOB (сертификаты, запрос на сертификаты, списки отозванных сертификатов и дельты списков отозванных сертификатов).
Поведение предсказуемое на RAID 1+0 на SAS 6G. Для пущей уверенности используем SSD.
ребята из IBExpert делают регулярную рассылку, где они тестируют конфигурации и показывает каким должен быть сервер для каких типов БД и с каким числом подключений.

Я не хочу сказать, что эта СУБД — панацея. Просто есть можество задач, где он себя показывает отлично!

Я вот почитал по СУБД Firebird 3.0.1, так у них действиетльно в архитектуре есть именно специализированные плагины для полного закрытия информации при работе с СУБД. Подобных решений я не нашел MySQL Community, PostgreSql… тем более, что нформацию, которую так нужно защищать не так и много…
думаю, Firebird найдет и здесь свою нишу :-)
Обратил внимание, что не ответил на ваш вопрос относительно масштабирования.
Есть платная надстройка называется HQBird. Лично ей не пользовался, но отзывы достойные.
Sign up to leave a comment.

Articles