Какая СУБД подходит для сохранения схемы частной, даже если она установлена ​​«в дикой природе» - PullRequest
0 голосов
/ 17 марта 2009

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

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

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

Однако, когда я начал исследовать, я узнал, что для PostGreSQL, даже если я устанавливаю базу данных без вывода сообщений и не предоставляю учетные данные пользователю - они могут просто изменить текстовый файл конфигурации (pg_hba.conf). ) и перезапустите сервер, предоставив полный доступ к базе данных без учетных данных.

Защищен ли этот сценарий в других СУБД? Как большинство коммерческих продуктов защищают свои схемы в этом сценарии? Будет ли большинство продуктов использовать встроенные базы данных?


Редактировать: Я предполагаю (возможно, ошибочно), что некоторые продукты полагаются на базы данных, к которым пользователь никогда не обращается напрямую. И я, конечно же, никогда их не вижу, потому что они спроектированы таким образом, что пользователю не нужно - вероятно, использовать встроенную базу данных.

Ответы [ 6 ]

6 голосов
/ 17 марта 2009

Насколько я помню, не существует коммерческих продуктов, которые "защищают" их схемы. От чего вы хотите защитить схему?

Рассмотрим следующие моменты:

  • В конце концов, единственный человек, который может защитить что-либо в СУБД, - это администратор сервера базы данных. И вы хотите, чтобы схема была защищена от этого человека?

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

  • Вам действительно нужно защищать свой реляционный дизайн? Это действительно так интересно? Вы изобрели что-то, что стоит скрывать? Я действительно так не думаю. И я прошу прощения заранее, если у вас есть.


РЕДАКТИРОВАТЬ: Дополнительный комментарий:

Меня не волнует большинство внутренних компонентов базы данных для продуктов, которые я использую. Это еще одна причина, я думаю, что большинство из них не предпринимает никаких действий, чтобы защитить их. Большинство из них не такие интересные.

С одной стороны, я твердо верю, что пользователям не нужно знать или заботиться о внутренностях базы данных. Но на том же уровне, как разработчик, я не думаю, что стоит пытаться защитить их. Скрывать их от пользователя, да. Защищать их от прямого доступа в большинстве случаев нет. И не потому, что я считаю неправильным защищать вашу схему. Это потому, что я думаю, что это очень трудная вещь, и она не стоит вашего времени как разработчика.

Но в конце, как и в любой другой теме, связанной с безопасностью, единственный правильный ответ - о том, какие риски связаны с затратами на реализацию меры безопасности.

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

Но ваш случай может быть другим.

2 голосов
/ 17 марта 2009

Большинство коммерческих продуктов не защищают свои схемы. Они попадают в один из двух лагерей:

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

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

1 голос
/ 23 марта 2009

Какую проблему вы пытаетесь решить? Ничто не может помешать DBA * делать то, что он хочет, со стандартными базами данных, и, как другие отмечают, активно враждебно вмешиваться в специфические для сайта потребности, такие как резервное копирование и обновление базы данных. Самое большее, вы можете зашифровать содержимое вашей базы данных, но даже тогда вам придется предоставить ключ дешифрования для фактического запуска приложения, и мотивированный и враждебный администратор базы данных, вероятно, сможет подорвать его.

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

(*) Администратор базы данных или системный администратор может изменять файлы, такие как pg_hba.conf.

0 голосов
/ 17 октября 2009

Эта идея будет страдать от тех же проблем, что и DRM. Вы не можете запретить доступ определенным, и вы только причините общую боль и страдания своим клиентам. Только не делай этого.

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

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

Если это действительно так важно для вас, вместо этого создайте размещенное приложение.

0 голосов
/ 17 октября 2009

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

0 голосов
/ 17 марта 2009

Как работает большинство коммерческих продуктов защитить свои схемы в этом сценарий

Я не верю, что большинство коммерческих продуктов что-то делают для защиты своих схем.

...