Comments 32
Delphi, C++ Builder, Firebird… извиняюсь, конечно, но как будто статья из 2004.
1. Опишите модель угроз!
Без этого — зачем всё вышеизложенное?
От кого защищаемся? Если от легального пользователя приложения, что ему мешает в WinDBG поставить breakpoint на ф-цию SetKey и немедленно получить ключ?
Пока не вижу пользы, одно только прожигание электроэнергии клиента и сервера на бесполезное шифрование.
Вот ссылка на презентацию, где есть об этом информация.
Но статья скорее ориентирована просто на описание пошагового применения и предполагает, что тот кому это применение применимо в его модели, то вот так вот это можно сделать.
По поводу: «От кого защищаемся?» — в статье есть слова: "… использует некий справочник (условно с конфиденциальными данными), который как обновляемый доступен по ссылке в глобальной сети. Его может СКАЧАТЬ КТО УГОДНО, но при этом расшифровать и работать с ним сможет только наше приложение." — вроде понятно, что угрозой является свободный доступ к файлу в глобальной сети. Защищаем данные от свободного доступа к ним, и, в этом конкретном описании, никак не от легального пользователя приложения.
Можно конечно спорить по поводу применимости такого решения, но это было самым простым из того, что можно было продемонстрировать.
Но в этом случае есть защита логином/паролем + шифрование соединения, появившееся в FB 3.
Пока это выглядит как слой дополнительный защиты. С одной стороны, перестраховка от неизвестных уязвимостей FB. С другой стороны, такой подход в безопасности как «вроде оно уже защищено, но давайте на всякий случай добавим ещё один слой» — не приветствуется.
В этом случае, достаточно положить в 7z-архив с паролем, и не городить столько сложностей.
«Рубится» относительно корретности предложенного примера, соглашусь, что он не сильно удачный :-)
Могу предложить более удачный:
- вы разработчик грфического редактора, у которого есть некие фильтры, которые красиво преобразуют вашу картинку
- параметры этих фильтров храняться в шифрованной БД (она может быть, как локальной, так и развернутой на выделенном сервере)
- ключ шифрования, как-то привязан к вашему коду активации графического редактора
Теперь, что получается… что только авторизованный пользователь приложения пользуется этим приложением и конкуренты не смогут «легко» украсть эти параметры.
Теперь, что получается… что только авторизованный пользователь приложения пользуется этим приложением и конкуренты не смогут «легко» украсть эти параметры.Купить одну копию приложения никак нельзя? ))
Купить одну копию приложения никак нельзя? ))
Вопрос в том, что купить как раз и можно! Вот только значения коэфциентов, хранящиеся в БД получить нельзя, т.к. пользователь легитимно владеющий Графическим редактором не может получить доступ к содержимому БД, т.е. к коэфициентам.
Тут можно сказать, что и алгоритм заполучить нельзя, потому что исходников программы нет ))
И из нешифрованной БД нельзя получить коэффициенты, потому что в таблицах одни числа и никаких пояснений ))
Приятно общаться с человеком, который готов "сражаться" за свое мнение :-)
Вопрос 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Это значит, что предложенная в статье разработка не нужна для соответствия процитированным требованиям. Встроенного в FB 3.0 Wire Encryption уже достаточно.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.
Или от злоумышленника, имеющему доступ к серверу? Если он имеет доступ администратора, он перехватит ключи из памяти. А если не имеет такого доступа, достаточно настроить запрет чтения файла.
И мы не защищаемся, а защищаем хранимые данные как личное имущество. А защищать своё имущество можно по-разному, — можно просто дома хранить (но при этом мы дверь таки запираем), а можно и в банке в надёжном сейфе. И везде злоумышленник может преуспеть. Всё сводится к отношению стоимости затрат к стоимости желаемого.
Разбирать детали реализации слишком долго и можно написать об этом целую статью. Поэтому кратко по поводу перехвата на сервере ключа (в случае хранения БД на отдельном сервере):
- клиентская часть на сервере недоступна, т.е. модуль активации принимающий ключ находится удалённо;
- ключ передаётся в зашифрованном виде с помощью сессионных ключей (об этом в статье было);
- ключ на серверном процессе извлекается именно во время процесса шифрования и это происходит в рамках динамического создания объекта для каждой сессии;
- ключ даже в алгоритм шифрования передается в маскируемом виде и даже получение в маскируемом виде ключа, без наших ноу-хау ничего не даст;
- запрет на чтение, это обычный саботаж и для этого используются административные способы, — например доступ к серверу для администрирования не единолично, а комиссионное.
И мы не защищаемся, а защищаем хранимые данные как личное имущество.Примерно так я и написал выше — ничего принципиально нового нет, добавляется ещё один уровень защиты, который добавляет нервотрёпки взломщику, но не закрывает какие-то векторы атаки, если они были открыты.
∙ клиентская часть на сервере недоступна, т.е. модуль активации принимающий ключ находится удалённо;Ой, сколько сложных наворотов, но хакер всегда идёт самым простым и прямым путём.
∙ ключ передаётся в зашифрованном виде с помощью сессионных ключей (об этом в статье было);
∙ ключ на серверном процессе извлекается именно во время процесса шифрования и это происходит в рамках динамического создания объекта для каждой сессии;
∙ ключ даже в алгоритм шифрования передается в маскируемом виде и даже получение в маскируемом виде ключа, без наших ноу-хау ничего не даст;
Ясно, что криптомодуль взаимодействует с СУБД через публичные API, их и надо атаковать.
Внедриться в любой процесс FB, в котором есть сессия авторизованного юзера со всеми ключами, остановить выполнение текущего запроса, запустить ф-цию FB, которая читает страницу с диска (на уровне уже после шифрования). Повторить для каждой страницы БД, записать результат в файл.
Да ещё проще, если сделать бекап через gbak, gbk-файл будет незашифрованным.
Вся инфраструктура сама всё сделает. Всё равно, что «взломать» truecrypt обычной командой copy с зашифрованного диска на незашифрованный.
запрет на чтение, это обычный саботаж и для этого используются административные способы, — например доступ к серверу для администрирования не единолично, а комиссионное.Это интересно, но для Windows Server я таких решений не знаю.
Используя предоставленные возможности, можно разработать плагины, которые помогают защищать БД, например, используя шифрование. В этом случае шифруются данные в файле БД. Если этот файл каким-то образом попадает в руки злоумышленника – то данные в нем в зашифрованном виде.
Но следует иметь в виду, что шифрование БД – это только один из необходимых элементов системы защиты информации. Если администратор имеет все необходимые ключи, пароли и полномочия для получения данных и модификации конфигурации системы – то одним лишь шифрованием сложно обойтись – требуется комплексный подход, который включает как технические, так и организационные меры.
Головная боль как раз в том, что доступ к БД есть у всякого по сути, благодаря известным всем паролям.Тогда gbak, можно с другой машины, и получаем нешифрованную БД
Что бы сделать бекап вначале придется расшифровать БД, не так ли?Я может не понял это высказывание:
доступ к БД есть у всякого по сути, благодаря известным всем паролям
То есть это надо внедрить квалифицированного взломщика внутрь сети. А не просто скопировать файл на флешку или переслать его через почту.Копируй базу вместе с клиентским приложением, и из него можно наколупать пароли.
Я вот знаю, что компания RedSoft использует свой клон Firebird под названием RedDatabase. И используется в целом ряде федеральных агентств и служб. И все познается в сравнении.
Предложу redmanmale попробовать Firebird 3.0, а вдруг понравится.
Много лет писал под FB, потом сменил работу, проекты, теперь в основном MSSQL, иногда MySQL. Ну что сказать, до сих пор вспоминаю IBExpert, невероятно удобный в сравнении с SSMS. Да и PSQL против T-SQL выигрывает просто на голову в логичности и возможностях языка.
Но у FB (по крайней мере до 2.5, на котором я закончил) были серьезные проблемы с масштабированием. Нельзя было просто взять докинуть ресурсов на сервер и дальше ворочать многогигабайтную базу сложной структуры. Как с этим дела в 3.0?
Поведение предсказуемое на RAID 1+0 на SAS 6G. Для пущей уверенности используем SSD.
ребята из IBExpert делают регулярную рассылку, где они тестируют конфигурации и показывает каким должен быть сервер для каких типов БД и с каким числом подключений.
Я не хочу сказать, что эта СУБД — панацея. Просто есть можество задач, где он себя показывает отлично!
Я вот почитал по СУБД Firebird 3.0.1, так у них действиетльно в архитектуре есть именно специализированные плагины для полного закрытия информации при работе с СУБД. Подобных решений я не нашел MySQL Community, PostgreSql… тем более, что нформацию, которую так нужно защищать не так и много…
думаю, Firebird найдет и здесь свою нишу :-)
Есть платная надстройка называется HQBird. Лично ей не пользовался, но отзывы достойные.
Шифрование БД под управлением Firebird 3.0