Наконец-то дописал.

http://www.ibase.ru/devinfo/ib-encrypt.htm

В сумме на написание, редактирование и тестирование ушло примерно четверо суток.

Вопросы?

Гаджимурадов РустамЛично я во всей статье обратил внимание только на картинку диаграмму, которая во-первых, не очень
показательна, а во-вторых, лично я ей не очень поверил.
ты думаешь я поверил? во-первых, я там написал про результаты на предыдущем железе. А во-вторых, почему-то у базы с шифрованием столбца в этот раз скорость была почти как на нешифрованной базе. Проверял несколько раз.

Гаджимурадов РустамНе знаю почему, но страница в IE и FF отличается.
в смысле? в тексте plain html, проще некуда, у меня в IE 10 и FF 27 все практически одинаково.

Симонов Денис Сложилось впечатления что с процессом шифрования они там перемудрили или не довели до ума.
гм, например?

hvladкак долго выполняется расшифровывание при cascade и наличие большого кол-ва зашифрованных данных ?

без понятия, не тестировал. Поскольку шифрование столбца выполнялось 0 секунд, включая commit, я несколько раз последовательно шифровал и дешифровал, при этом выходило время от 3х минут до 20. Это на одном и том же столбце STREET.NAME, где записей 800к и размер таблицы 98мб.
Быстрее всего, конечно, идет шифрование-дешифрование всей базы, там это занимает 10-20 секунд (опять же, 136мб).
Также я понятия не имею, смогут-ли пользователи работать с таблицей (и индексом) в момент шифрования/дешифрования.
По идее эти операции должны быть "монопольными".

чувствую, что надо будет по производительности потестировать базу хотя бы размером 2-3 гига. Впрочем, нерегулярность результатов измерений меня повергает в печаль. Я не понимаю, откуда эта нерегулярность берется.

p.s. спасибо, поправил.

Симонов Денисзачем нужен отдельный пользователь SYSDSO и почему созданием SEP не может заниматься SYSDBA?
я не в курсе модели, которую они использовали. У меня почему-то такого вопроса не возникло (не знаю, почему).

Симонов Денисиз статьи это только когда отдельный столбец шифруется, а не вся БД
разумеется. когда страницы шифруются, проблем с индексами нет.

Симонов ДенисКстати там сетевой трафик шифруется?
да, есть, это отдельно от шифрования БД, никак не связано. Можно использовать, а можно использовать другое, все что угодно. Я в общем это упомянул тут
http://interbase.blogspot.ru/2012/05/interbase.html
но лучше читать об этом в OpGuide.pdf.

Симонов Денис,
а по поводу индексов на шифрованных столбцах - да, адъ. Надо будет числа проверить.
Кстати, DS говорил, что знает, почему это (про 8 байт). Я че-то забыл.

Симонов Денисили всё же запрос был такой
нет, именно count.
для К выдал 1, для Кр выдал 0, для Кра выдал 0, и так далее. я же там написал. может непонятно, но я хотел сделать компактнее.

Причем, я еще пару запросов дал, для starting with 'n' где n - один символ, where срабатывает не как starting with, а как
field = 'n'

Правильно ищет только для 8, 16 символов (и непонятно, почему для 17).

Симонов Дениспосле поиска по ключу индекса проверяется ещё и соответствуют ли найденные записи тем что извлекаются из таблицы.
в смысле? при поиске по ключу строится массив номеров записей, и эти записи выводятся. ничего больше не проверяется (при данных запросах), кроме видимости версий. С чего бы IB или FB проверять содержимое столбца, если оно и так соответствует ключу?

Симонов Денис,

насчет проверки при выборке, возможно, я погорячился, например, если мы делаем Execute, потом меняем все записи, а потом начинаем делать fetchAll. Если не проверять, то мы увидим уже совсем не то, что хотели. Так что проверять надо...

Симонов Денис зачем нужен отдельный пользователь SYSDSO и почему созданием SEP не может заниматься SYSDBA?
я вспомнил, почему воспринял это как естественное.
В одной серьезной конторе
1. ключи от серверной были только у охраны, давать ключи они никому не имели права
2. серверную мог открывать только охранник
3. охранник не имел права заходить в серверную
4. охранник мог пускать в серверную только явно перечисленных в приказе лиц.
соответственно, эти лица к ключам доступ не имели.
Возможно, там было еще сложнее, например, две двери (так и было), внешнюю мог открыть только охранник, внутреннюю - только допущенное лицо своим ключом.

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

так что SYSDSO - это примерно такой же охранник. В MS SQL - многоуровневая система ключей. В других не смотрел.

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

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

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

Гаджимурадов Рустам"Прикинувшись" им. Или "став" им.
да, 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, без него оно невозможно. В статье все по шагам расписано, в самом начале.