freepascal.ru

Добрый день! Возник вопрос о защите данных СУБД Firebird.
Понимаю, такой вопрос рассматривался в интернете не раз, но ничего путного нет, только ответы в стиле сменить СУБД и т.п.

Есть многопользовательская медицинская база данных, в ней несколько таблиц. Нужно защитить сам файл базы данных и/или же шифровать отдельные столбцы.
Плагин шифрования
У Firebird есть пример плагина шифрования - https://github.com/FirebirdSQL/firebird/blob/master/examples/dbcrypt/cryptDb.pas
Но, увы, я этот пример не понял, разве что шифрование там сверхпримитивное для примера - XOR, а платные плагины стоят очень дорого.
Какие будут идеи насчёт плагина?
Шифрование на клиенте
В Гугле находил идею, что можно шифровать данные на клиенте, но тут возник вопрос:
Например, имеются 2 пользователя. Один может получать доступ ко всем таблицам, другой - только к определенным. Пароли разные, если, к примеру, брать MD5 пароля пользователя за ключ шифрования, а раз ключи получатся разные - то другой клиент не расшифрует столбцы.
И еще нюанс с поиском - шифрованные данные.
Шифрованный контейнер
Например, VeraCrypt, но клиенты не захотят каждый раз вводить пароль для открытия виртуального диска и придется ставить автоматический вход. И тут есть еще вопрос - когда контейнер открыт, данные можно легко скопировать, ведь они уже и не шифрованы.

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

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

а так, как ни крути надо учить базу шифровать.

sts, приветствую! Защитить от кражи хотя бы сам файл БД и данные в ней.
Шифровать всю БД просто пока не представляю как, хотя об этом тоже думал.

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

Против лома нет приема. Если данные у клиента и они их смотрят в виде базы - ничто не помешает стянуть.
Есть только два решения:
1. Доступ через сервис/сетевую базу, скрывающую лишнее от конченого клиента.
2. Использовать зашифрованную базу (нечитаемую на уровне клиента/стандартных утилит), но при этом имеющую доступ на уровне приложения.

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

sts, Firebird запущен как сервис. Баз данных несколько, просто говорил про одну, т.к. думал, что если пойму принцип защиты одной БД, то смогу и остальные защитить.
Если шифрование не лучшее решение, то какое? Потому что с многопользовательскими БД раньше не работал.
И да, сервер Firebird будет запущен на рабочей станции, т.к. заказчики программы пока не купили отдельный сервер.

wavebvg, понятно, что невзламываемого не бывает, именно, что просто осложнить слив базы. И все из-за того, что клиенты пока не купили отдельный сервер. На отдельном сервере было бы попроще - Linux туда, и шифрованный раздел. А так пока один рабочий ПК и выполняет роль сервера.

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

Добавлено спустя 3 минуты 51 секунду:
Значит сервер, это лучше. значит надо попытаться написать плагин, надо смотреть апи

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

sts, тогда сейчас посмотрю API Firebird, связанное с шифрованием и попробую что-то сделать с плагином, если получится.

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

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

Hyper писал(а):sts, приветствую! Защитить от кражи хотя бы сам файл БД и данные в ней.
Шифровать всю БД просто пока не представляю как, хотя об этом тоже думал.

Смотри, у самой БД простая функция - вставка/изменения/удаление записи. И поиск по этим данным.
На сколько я понял нужно шифровать данные. Но для самой БД данные должны быть прозрачными? Или закрытыми?
Т.е. сама БД может оперировать открытыми данными или нужно чтобы они были и для БД закрытыми?

Добавлено спустя 4 минуты 12 секунд:

sts писал(а):Добавлено спустя 3 минуты 51 секунду:
Значит сервер, это лучше. значит надо попытаться написать плагин, надо смотреть апи

В 3.0 они основательно переработали с шифрованием, но это для клинта<->клиент. Сама база для движка должна прозрачной.
Читал про шифрование на лету.
Но все это для удаленки.
Если вы собираетесь использовать локально то там нужны уже другие фокусы..

Добавлено спустя 3 минуты 17 секунд:

sts писал(а):тобишь идея такая,
(БД) пользователь подключается к серверу.
плагин как-то получает пароль или вернее хеш пароля
лезет в ту таблицу, пользователь - ключ, расшифровывает ключ
сохраняет этот ключ в контексте сессии
и в дальнейшем использует его для расшифровки "чувствительных данных", ну или всего

Все можно сделать просто - бд хранит Blob зашифрованную запись. А на стороне клиента(ов) должны быть ключи(симитричные/асимитричные) которые читают этот блоб. Тогда даже движок не будет знать что там.

olegy123 писал(а):В 3.0 они основательно переработали с шифрованием, но это для клинта<->клиент.

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

Добавлено спустя 7 минут 28 секунд:
Кстати, есть российский форк Firebird, называется RedBase, там встроенная система гостовская система шифрования и, что самое вкусное для работы с полнотекстовыми базами - встроена система полнотекстового поиска, в FireBird её нет.

sts,

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

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

olegy123, приветствую! Сама база для движка может быть прозрачной.

Если вы собираетесь использовать локально то там нужны уже другие фокусы.

База везде будет удалённой, кроме одного ПК, на котором будет крутиться и сервер базы, и клиент, потому что отдельного сервера пока нет.

Vadim, приветствую! Про форк Firebird - RedBase, интересно, она доступна для частных лиц? И модель распространения - бесплатно?
Посмотрел на сайте - вроде про купить ничего не сказано, но требует регистрации для скачивания базы.

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

Это не проблема, создан мощный класс для обработки данных, так сказать, с универсальными функциями.
Саму программу писал с такой архитектурой, чтобы можно было кое-что заменять, расширять, убирать.
Я читал доки по Firebird и не совсем понял, если зашифровать даже плагином, то поиск отпадает? Если так, то тоже не вариант, т.к. поиск нужен.
Firebird Database Encryption

А ведь судя по вопросу, клиентское приложение уже готово и работает.

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

Hyper писал(а):База везде будет удалённой, кроме одного ПК, на котором будет крутиться и сервер базы, и клиент, потому что отдельного сервера пока нет.

Тогда подойдет обычная трехзвенка.. [клиент] <-> [программный шлюз] <-> [База данных]
где [программный шлюз] - может вообще искажать представление о данных, аутентификацию проводить хоть через Q-code..
Любой Web сервис на этом сторится: HTTP+PHP+MySQL, [программный шлюз]=>[HTTP+PHP]

Hyper писал(а):На отдельном сервере было бы попроще - Linux туда, и шифрованный раздел. А так пока один рабочий ПК и выполняет роль сервера.

Если возможности компа позволяют, запустите это на виртуалке, хоть на виртуалбоксе.

Тогда подойдет обычная трехзвенка.. [клиент] <-> [программный шлюз] <-> [База данных]
где [программный шлюз] - может вообще искажать представление о данных, аутентификацию проводить хоть через Q-code..

Хм, хорошая идея. Шлюз выполнить в виде сервиса Windows. Приватный ключ - на сервере, публичный - у клиентов.
У меня была идея, может показаться странной, сделать эдакий сервис, который блокирует доступ к файлу базы всем, кроме Firebird.
Но вопрос с файлом базы остается опять, так сказать, защита от утечек (100% защиты нет, главное, усложнить процесс), т.к. на ПК, где сервер и клиент, могут подхватить троян )