DSKalugin Алексей Ключников
И снова криптуйте разделы и не давайте ее третьим лицам :)

Я собрался продавать (а не давать) программу с базой.
Поэтому всем будет по балде что я творю у себя на своем сервере :-))
Рассматриваю разные СУБД на предмет встроенных возможностей шифрования информации или надежную защиту паролем

Спасибо
Из всех известных мне, только Sybase ASA поддерживает криптографию по ключу файлов БД и лога, что исключает ее взлом на бинарном уровне, CHECKSUM PAGE для сверки контрольных сумм страниц, а так же держит юзеров в самой БД, что означает невозможность чего то покуралесить в БД, если не известены пароли логинов администраторов и дает возможность отдавать БД в пользование другим лицам с заранее прописанными и запороленными логинами. Соответствующе если в клиентском приложении прописаны логин/пароль/ключ криптографии БД, то не зная их невозможно подключиться к БД и получить ее данные. Дополнительно можно на логин сессии навесить выполнение ХП, которая по параметрам подключения (или еще чему то), будет решать - стоит ли разрешить подключение (а так же выполнить другую работу ... например инициализировать для сессии глобальные переменные), или же дать отлуп сессии.

Есть и плохие стороны у хранения логинов прямо в БД ... если в БД в качестве администратора прописан только DBA, мы "забываем" его пароль или вообще отключаем от права соединения и не имеем бакупов ... то с БД можно прощаться, максимум повезет выгрузить данные, если будет существовать известный нам логин, которому на чтение доступны все таблицы. Могу ошибаться, по моему из других РСУБД никто больше так не умеет, во всяком случае MSSQL/Oracle/Interbase/DB2 точно хранят сами логины не в БД. Однако ASA - сервер коммерческий и Вам придется или включать его цену в цену решения или же искать другие пути защиты Вашей информации.

авторУ постгреса есть суперюзер по умолчанию, обычно это pgsql.
т.е. если вы решли продать свой програмный продукт то ничто не мешает клиенту с правами зайти в БД под пользователем pgsql сделать себе своего пользователя и вообще делать что душе угодно
А можно для БД создать своего owner-а, а встроенному суперюзеру назначить права гостя или вообще запретить доступ к БД ? Не будет ли это являться решением проблемы ?