Гаджимурадов Рустам,

интересно, каким образом? он не может создавать ключи.

мне интересно, почему предположения подаются как утверждения?

Гаджимурадов Рустам"Прикинувшись" им. Или "став" им.
да, SYSDBA создает пользователя SYSDSO, но затем SYSDSO должен поменять пароль, поэтому SYSDBA не сможет ни "прикинуться" ни "стать" SYSDSO.

alter user SYSDSO set password 'ooo'
unsuccessful metadata update.
MODIFY RDB$USERS failed.

Симонов Дениссоздавать то не может, но зато может запросто снести их
из под SYSDBA:
ALTER DATABASE SET NO SYSTEM ENCRYPTION PASSWORD
Error: data security officer privilege required to modify encryption password

DROP encryption sname_aes
Error: data security owner privilege required to encrypt or decrypt.

GRANT ENCRYPT ON ENCRYPTION kname_aes to SYSDBA;
unsuccessful metadata update.
STORE RDB$USER_PRIVILEGES failed in grant.
no current record for fetch operation.
action cancelled by trigger (2) to preserve data integrity.

то есть, SYSDBA не может (!) менять данные в rdb$user_privileges.

попытка прямого удаления ключа из RDB$ENCRYPTIONS
no permission for delete/write access to table RDB$ENCRYPTIONS by user SYSDBA

Так что если вы что то предполагаете, или или попросите это сделать меня, или попробуйте проверить это сами.

кстати, вот что Рустам угадал, что команда
drop user SYSDSO
прошла успешно. а потом можно опять создать SYSDSO с новым паролем. Думаю, это баг.
При этом все изложенное выше (команды и результат) остаются в силе (как при удаленном SYSDSO, так и после его повторного создания).

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

Гаджимурадов РустамНу почему же угадал и почему баг? На мой взгляд, это логично.
Если пользователь вдруг "забыл" пароль - всё теперь, вешаться?
с одной стороны логично, с другой стороны "подмена" пароля не фонтан, фактически дыра в безопасности.

Гаджимурадов РустамЧто пробовать - ну для начала выдать себе недостающие
привилегии на соответствующие таблицы, например.
я уже показал, что это не работает. Могу дополнить

grant select, delete, insert, update on rdb$encryptions to SYSDBA
unsuccessful metadata update.
no S privilege with grant option on table/view RDB$ENCRYPTIONS.

revoke отрабатывает, но ничего не делает, т.к. у них его и так прав нет. Вставить, удалить или поменять запись прямо в RDB$USER_PRIVILEGES SYSDBA не может (no permission for update/write access)

to all - вы не забывайте, что это InterBase, и некоторые базовые вещи от Firebird уже давно отличаются. То, что до сих пор можно в ФБ, не факт, что можно в ИБ

Dimitry SibiryakovДа. Это же азы безопасности.
ну, в случае, который привел Рустам, когда SYSDSO забыл пароль, на ум приходит только одно решение - "пришел лесник, и разогнал всех к чертовой матери".
Возможно, тут должна быть троица.
1. owner, который создает базу
2. sysdba, который создает sysdso
3. sysdso, который создает ключи и дает на них права owner-у .

впрочем, SYSDBA тут и получается в роли того самого "лесника".

Ivan_PisarevskyУтеря ключа должна приводить к потере информации, без вариантов.
я тут ночью подумал, и пришел к такому же выводу. Потому что, например, если база в EUA, т.е. SYSDBA внутри базы, и он забыл пароль, то крандец, к базе он больше не подключится. Можно, конечно, хакнуть это дело hex-editor-ом, но я не пробовал.
А с ИБ и SYSDSO, полагаю, решение должно быть таким
- при включении EUA в rdb$users должен создаваться не только SYSDBA/masterkey, но и SYSDSO/какой-нибудь-пароль, чтобы SYSDSO нельзя было удалить в принципе.
- или, при попытке drop user SYSDSO нужно проверять наличие созданных им объектов, и при их существовании - не давать удалять SYSDSO.

nsclТакже было бы крайне интересно услышать, от какого злоумышленника должно защищать такое встроенное шифрование.
шифрования хотят те, кто распространяет базы-справочники. Стон по этому поводу существует уже лет 10, если не больше.
Именно поэтому предложение про "криптоконтейнер" не катит, и пожалуйста, банальности излагать тут не надо :-)
Про "крэшнуться" уже намекнули. Про быстродействие - по-моему только дурак ждет, что шифрованная база будет работать с той же скоростью, что и не шифрованная. И т.д.

Добавлю, что в ИБ степеней "защиты" несколько.
1. EUA, т.е. SYSDBA в базе. Защищает от кражи базы с SYSDBA/masterkey, или от подмены admin.ib (аналог security?.fdb).
2. после создания SEP, даже без шифрования, база уже "непереносима" на другой комп без знания пароля SEP, даже если известен пароль SYSDBA в базе.
3. собственно, шифрование. Не позволяет кому попало смотреть данные в БД hex-viewer-ом, или при отсутствии прав доступа.

Кстати, один разработчик, который спрашивал про шифрование в ИБ, задал вопрос - " но ведь в приложение данные приходят уже расшифрованными? "
А этот вопрос решается уже клиентским шифрованием - либо вручную, либо вроде это есть в FIBPlus. Некоторые, возможно, предпочли бы зашифровать и выводимые на экран данные, но это уже перебор :-)

Гаджимурадов Рустамkdvя уже показал, что это не работает.
А сам файл подменить?
какой еще файл?

Гаджимурадов РустамНасколько я понимаю, такие справочники и клиентские
шифрования будут подвержены подмене клиента, хотя
это не для малолетних кулхацкеров, такое не все смогут.
Влад уже давно писал, каким должно быть шифрование, и с IB есть тоже пример, и все это весьма сильно отличается от вопроса тех самых "пожелателей шифрования", которые весьма смутно представляют себе, что это такое.

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

Гаджимурадов РустамИли при шифровании только EUA допускается?
шифрование начинается с включения EUA, без него оно невозможно. В статье все по шагам расписано, в самом начале.