Защита данных Firebird

[olegy123]

Я делал так:
Многоточечное приложение: каждый клиент TCP должен авторизоваться. Если авторизация прошла успешно, клиенту(TThread) присваивается ID базы, но не пересылается ему. Тем самым клиент вообще не знает своего ID в БД.
Клиент делает запрос в виде JSON данных. Сервис запрашивает в БД добавляя ID в запрос и отдает JSON ответ. Если у клиент Android - там это все нативно...

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

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

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

[Hyper]

olegy123, Могут ли получить к украденной базе доступ на другом ПК (если украдут базу) при таком решении?

Кстати, вопрос, сам сервер Firebird будет "светить" своим портом наружу, как "заизолировать" его, чтобы принимал только локальные подключения, во внешний мир будет выходить только шлюз.
UPD: про изоляцию нашел - bind-adress надо в конфиге прописать.

[olegy123]

Существует localhost 127.0.0.1
пакеты не идут наружу, порты его не видны другим хостам.
Firebird может быть embedded.

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

Могут ли получить к украденной базе доступ на другом ПК (если украдут базу) при таком решении?

Непонял.
Если снаружи будет один порт [шлюза] который работает по особому протоколу.
Ну например может при авторизации особым образом давать уровень привилегий.. который позволяет устанавливать уровень запросов.
допустим [Гость] запускает нить в котором прописано только просмотр состояний, кол-во запросов за сегодняшний день. Нить подключает класс в котором есть только данный функционал [TClientGuest]..
[Пользователь] уже может добавлять объекты - к нити подключается другой класс [TClientUser] который имеет метод Insert
и так далее..
[Суперадминистратор] вообще может контролировать сами нити... видеть подключения и их принудительно отключать..
даже чат можно между ними сделать..

Добавлено спустя 3 минуты 45 секунд:
У меня был один проект - GPS навигаторы.
Задача была такая: авторизовать много видов навигаторов и получать с них данные -> обобщать данные и сохранять в БД.

[Hyper]

olegy123, кстати, как Вы сделали шлюз? Клиент передает шлюзу сформированные SQL-запросы или собственные?
т.е. например, не

Код: Выделить всё

CREATE TABLE "Таблица" ('№' INTEGER PRIMARYKEY, 'Столбец 1' VARCHAR);

а вместо этого,например,

Код: Выделить всё

gateway_new_table(*структура*);

+ шифруется весь этот запрос.

Непонял.
Если снаружи будет один порт [шлюза] который работает по особому протоколу.

Имелся ввиду физический доступ к файлу базы, что тогда можно предпринять для защиты?

[olegy123]

https://ru.wikipedia.org/wiki/%D0%A2%D1 ... 1%80%D0%B0

Я выбрал JSON формат данных как самый простой. и в случае перехода на Web не надо было переписывать сервис.
Клиент подключился к сервису, Сервис создал для него обслуживающий TThread. клиент обязан за 30 сек. авторизоваться. Иначе TThread глушил Socket и завершался сам.
Клиент авторизовался - теперь он мог посылать JSON запросы и получать JSON ответы.
типа так:
запрос {table:"Таблица",{command:Insert,{"№":123,"Столбец 1":"текст"}}}
ответ {result:0}.. 0 - нет ошибок

можно было составные запросы посылать в {{table:"Таблица",{command:Insert,{"№":123,"Столбец 1":"текст"}}},{table:"Таблица",{command:Select}},{table:"Таблица2",{command:delete,id:13234}}}


Теоретически можно сделать даже прокcирование/VPN канал

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

Имелся ввиду физический доступ к файлу базы, что тогда можно предпринять для защиты?

Какой уровень доуступа и безопасности планируется..
Если нужно защитить FirebirdSQL от внешних клуцхакеров, а для клиентов секретов нет - то решить можно штатными средствами операционных систем: правилами брандмауэров, фильтрацией IP/портов, организации VPN каналов.

Если Вы опасаетесь клиентов, чтобы они не узнали название таблиц, чтобы не могли подключить какой нибудь SQLExplorer и выкачать все данные, опасаетесь SQL инъекций - то для них можно организовать свой протокол. который сервис приложение будет обрабатывать ваш протокол, работать с БД и отсылать результаты.

[Vadim]

RedBase, интересно, она доступна для частных лиц?

Немножко не так. У них там есть две версии - бесплатная и платная. Различий между коммерческой\корпоративной и частной эксплуатацией нет. Регистрируетесь - скачиваете бесплатную версию. на почту Вам будут время от времени махонькую рекламку присылать, но всё в пределах разумного. Не будет техподдержки. Кое-какие фишки отсутствуют, но что именно - надо у разработчиков узнавать. Я в своё время её потестировал ради интереса - обычный FireBird.

Я читал доки по Firebird и не совсем понял, если зашифровать даже плагином, то поиск отпадает?

Я шифрование не тестировал. Если судить по общему описанию, шифрование-дешифрование ведётся в клиентском приложении. Это наталкивает на мысль, что в этом случае для работающего сервера БД все тексты в базе останутся полнейшей загадкой. Впрчем, моему мнению на этот счёт доверять не стоит, это всего лишь предположение.
------------------------
Кстати, а почему бы просто не хранить базу на шифрованном разделе? Даже если свистнут комп или винт с базой, придётся изрядно попотеть, в том числе и финансово. Окупится ли в таком случае возня?
Вообще, если речь пошла о защите данных, надо в обязательном порядке составлять список угроз для этих данных, а потом уже строго по списку решать, как устранять каждую угрозу. Вот мы тут зациклились на шифровании, а ведь никакое шифрование не спасёт от инсайдеров.

[Hyper]

Я выбрал JSON формат данных как самый простой.

При передаче данных от клиента к шлюзу JSON шифруете?

Какой уровень доступа и безопасности планируется..

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

чтобы не могли подключить какой нибудь SQLExplorer и выкачать все данные, опасаетесь SQL инъекций

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

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

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

[ENERGIX]

С точки зрения программиста:
А что, если пойти более простым путем? Так как информация попадает под закон, произвести обезличивание персональных данных - раскидав их по базам. Хранить отдельно ФИО, историю медкарты, клиентов базы и пароли. Сделать блоб-поля с шифрованием, там где это необходимо. Смените стандартные пароли доступа на свои к каждой базе. В итоге имеем несколько баз, которые даже умыкнув с сервера - не собрать в кучу для ясности данных. Ну а доступ из клиента на ваш вкус, хоть двухфакторный, хоть по ключу(закрытый+открытый), вариантов море.
С точки зрения безопасника:
Сервер должен быть выделенный, требования к хранению данных и помещению есть в доступе. Охранка, решетка на окна, ключи под охраной и человек, ответственный за хранение, архивирование и защиту от утечек. Доступ закрыт для посторонних. Работа только через сеть, доступ через алиас сервера и базы, порт нестандартный в настройках конфига базы, шары закрыты, остальные порты закрыты - разве не такие правила для работы с ПДН?
P.S. Я просто знаком с медицинской тематикой, такие вещи мы писали с 2005 года, затем просто подгоняли под законодательство и стандарты.

[olegy123]

Я выбрал JSON формат данных как самый простой.

При передаче данных от клиента к шлюзу JSON шифруете?

там андройд-клиенты и вэб-сервер. Все их обрабатывал один сервис.
Технически включить HTTPS или OpenSSL слой или закрывать отдельные данные - не составляет труда.

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

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

Это же класика.

Проблема в другом - если вдруг кто-то захочет им настроить ПК (эдакие местные "спецы") и захотят слить базу, чтобы получили бред вместо данных.

Это не решается системно. Сначала нужно определить, что хотите закрыть - можно даже на уровне таблиц View/Procedure/Function ограничить доступ к данным.. т.е. клиенты не смогут увидеть реальные данные, только обработанные. Тем самым "спецы" увидят только то, что видят ваши клиенты.

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

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

Зачем шифровать базу, если для клиентов нет физического доступа к самим файлам?

Вот если вы передаете клиенту базу, с которой он работает - и вам обязательно нужно закрыть.. то этот вопрос пока не решается на 100%. Хотя AMD выпускает процессор который, судя по описанию позволяет "закрыть" данные от внешнего чтения даже через ОЗУ, хотя у меня вопрос как доставить ключи в процессор, можно ли их перехватить?.. Появится ли эмулятор процессора?
А пока только хардкор - только аппаратный ключ, с виртуальной машиной наподобие Denuvo.

[DYUMON]

Блин не проще давать человеку бумажку с данными, а он будет заходить в специальное помещение и там забивать данные в комп?

[ENERGIX]

Блин не проще давать человеку бумажку с данными, а он будет заходить в специальное помещение и там забивать данные в комп?

Ерничаем? Электронная история болезни - довольно сложная проблема. Регистратура(приемное отделение) - это раз, экономисты(ОМС, ДМС, контроль страховыми компаниями) - это два, лечащий врач(+ глав.врач, выписка) - три, инструментальные исследования(диагностика и т.д.) - четыре, выписка лекарств(склад аптеки и т.д.) - пять, статистика (место врача-статиста) - шесть. На каждом этапе, куда не плюнь - жесткое соблюдение ПДН...Так что эти вопросы волнуют многих. А стебаться - может каждый.

[DYUMON]

Я не ерничаю. Я отлично знаком с этой темой. Работалв поликлиннике 3 года. Приходилось писать софт для медицины. Но когда начинал , то не было такой пррблеммы с защитой персональных данных. А потом государство решило внедрить единую медицинскую систему. Мис барс. И проблемы с персональными данными стали их головной болью. Теперь у каждого врача для входа в систему есть свой электронный ключ. Которым он в будущем будет подписывать записи в медицинской карте.

[Hyper]

Блин не проще давать человеку бумажку с данными, а он будет заходить в специальное помещение и там забивать данные в комп?

Добрый день! Шифрование и небольшая паранойя - не моя прихоть, а заказчика ))
Проблема в защите БД заключается лишь в том, что пока не купили сервер, а программа нужна сейчас. Сервер проще было бы оградить от всяких угроз.
А так как не купили сервер, сервер БД работает на рабочей станции, за которой сидит администрация.
Но тут риск того, что они таки подцепят какой-нибудь троян, а еще похлеще - radmin, и база сольётся.
Этот вопрос в данный момент решаю, например, настроить права доступа к папкам и файлам.

olegy123 , Добрый день! У меня возник вопрос. Начал писать шлюз и думаю - с клиента на шлюз отправить данные можно, а вот обратно - на клиент, чтобы заполнить TDBGrid? Если, например, нужно выполнить

Код: Выделить всё

SELECT * FROM "Имя_Таблицы";

На шлюзе формировать TDataSet?

ENERGIX , Добрый день! Над этим вопросом я тоже думал. В будущем купят отдельный сервер, а там уж Linux я настрою и права доступа к файлам.

[DYUMON]

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

[serbod]

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

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