1 - потому что предыдущая запись была о шифровании соединений в InterBase, а теперь речь пойдет о шифровании баз. О шифровании соединений, впрочем, говорить больше нечего, т.к. то же самое может быть выполнено другими средствами, совершенно не привязанными к InterBase. Например, аппаратное шифрование, программные средства вроде ZeBeDee, и т.п.
Сразу предупреждаю, что шифрование баз - сложная штука, и если кто-то думает, что можно было бы все это сделать тяп-ляп, то он ошибается.
Первым требованием перед включением шифрования БД является включение в базе Embedded User Authentification. Эта штука появилась еще в InterBase 7.5 в 2005 году, и позволяет проводить аутентификацию пользователей и SYSDBA через саму БД, а не через общий admin.ib для всех баз на сервере.
EUA является первым средством, которое позволяет защититься от "украли файл с базой", т.к. если пароль SYSDBA в базе будет не masterkey, то его придется или подбирать, или как-то хакать hex-editor-ом (не пробовал). Но, как минимум, это уже хоть какая-то защита от чайников.
Полностью и детально шифрование БД описано в документации на InterBase, в Data Definition Guide, Глава 13 (однако!), Encrypting Your Data. Это я к тому, что здесь, все же, идет концептуальное описание, без мелких деталей (иначе пришлось бы растянуть это минимум на 10 постов. Тем не менее, вы можете выполнять приводимое здесь по шагам, разве что с учетом того, что для продолжения вам придется остановиться в ожидании следующего поста :-)
Итак, берем какую-нибудь тестовую базу, которую не жалко в случае ошибки, и в случае чего можно удалить. База должна быть создана не менее чем в InterBase 2009, но эту версию уже можно считать устаревшей, поэтому я настаиваю на XE (для экспериментов можно взять Developer Edition, если ее у вас ее еще нет - выбираем InterBase XE (10.0.4.590) 32-bit Developer Edition - Windows, English или InterBase XE (10.0.4.590) 64-bit Developer Edition - Windows, English). Иначе часть описываемых функций у вас может не заработать. Логинимся от SYSDBA, включаем в базе EUA, как это описано в статье.
ALTER DATABASE ADD ADMIN OPTION
Меняем пароль SYSDBA
ALTER USER SYSDBA SET PASSWORD 'sss'
понятно, что sss и подобные тут просто для того, чтобы не замучил склероз. Предлагаю по мере выполнения действий записывать их в "блокнотик" с цитатами отсюда, или собственными комментариями - получилось, не получилось, и т.п.
Разлогиниваемся, проверяем - пароль masterkey больше не работает, используем sss - ок, подключились.
затем создаем пользователя SYSDSO (его может создать только SYSDBA или владелец БД)
CREATE USER SYSDSO SET PASSWORD 'ooo'
Этот пользователь является "ключником", и не может выполнять никакие другие функции, кроме:
! При генерации System Encryption Password используется информация, специфичная для текущего компьютера. Поэтому, на этой машине далее при доступе к БД SEP не требуется (хотя такое требование можно включить), а при переносе БД на другой компьютер никто без указания пароля SEP залогиниться не сможет. Можно указывать пароль SEP в параметрах коннекта (isc_dbp_system_encrypt_password), но это доступно только компонентам прямого доступа. Либо, можно указать SEP в переменных среды ОС (переменная ISC_SYSTEM_ENCRYPT_PASSWORD). Лучше сделать так - SYSDSO должен залогиниться к базе используя свой пароль и SEP, и создать новый SEP. Новый SEP будет привязан уже к этому компьютеру, и остальным пользователям указывать его при коннекте не потребуется.
Разлогиниваемся, логинимся как SYSDSO, создаем SEP для базы
ALTER DATABASE SET SYSTEM ENCRYPTION PASSWORD 'aaa'
Если есть желание, чтобы даже сейчас, на этом компьютере, пользователям требовалось указывать при коннекте пароль SEP (если ваше приложение позволяет указывать этот пароль помимо обычного пароля. Если нет, они обломаются, и так лучше не делать), то к данной команде можно добавить в конце опцию EXTERNAL.
продолжение.
Сразу предупреждаю, что шифрование баз - сложная штука, и если кто-то думает, что можно было бы все это сделать тяп-ляп, то он ошибается.
Первым требованием перед включением шифрования БД является включение в базе Embedded User Authentification. Эта штука появилась еще в InterBase 7.5 в 2005 году, и позволяет проводить аутентификацию пользователей и SYSDBA через саму БД, а не через общий admin.ib для всех баз на сервере.
EUA является первым средством, которое позволяет защититься от "украли файл с базой", т.к. если пароль SYSDBA в базе будет не masterkey, то его придется или подбирать, или как-то хакать hex-editor-ом (не пробовал). Но, как минимум, это уже хоть какая-то защита от чайников.
Полностью и детально шифрование БД описано в документации на InterBase, в Data Definition Guide, Глава 13 (однако!), Encrypting Your Data. Это я к тому, что здесь, все же, идет концептуальное описание, без мелких деталей (иначе пришлось бы растянуть это минимум на 10 постов. Тем не менее, вы можете выполнять приводимое здесь по шагам, разве что с учетом того, что для продолжения вам придется остановиться в ожидании следующего поста :-)
Итак, берем какую-нибудь тестовую базу, которую не жалко в случае ошибки, и в случае чего можно удалить. База должна быть создана не менее чем в InterBase 2009, но эту версию уже можно считать устаревшей, поэтому я настаиваю на XE (для экспериментов можно взять Developer Edition, если ее у вас ее еще нет - выбираем InterBase XE (10.0.4.590) 32-bit Developer Edition - Windows, English или InterBase XE (10.0.4.590) 64-bit Developer Edition - Windows, English). Иначе часть описываемых функций у вас может не заработать. Логинимся от SYSDBA, включаем в базе EUA, как это описано в статье.
ALTER DATABASE ADD ADMIN OPTION
Меняем пароль SYSDBA
ALTER USER SYSDBA SET PASSWORD 'sss'
понятно, что sss и подобные тут просто для того, чтобы не замучил склероз. Предлагаю по мере выполнения действий записывать их в "блокнотик" с цитатами отсюда, или собственными комментариями - получилось, не получилось, и т.п.
Разлогиниваемся, проверяем - пароль masterkey больше не работает, используем sss - ок, подключились.
затем создаем пользователя SYSDSO (его может создать только SYSDBA или владелец БД)
CREATE USER SYSDSO SET PASSWORD 'ooo'
Этот пользователь является "ключником", и не может выполнять никакие другие функции, кроме:
- создания системного пароля шифрования (SEP)
- создания ключей шифрования
- выдачи прав другим пользователям на использование созданных ключей шифрования для шифрования базы данных или столбцов таблиц
! При генерации System Encryption Password используется информация, специфичная для текущего компьютера. Поэтому, на этой машине далее при доступе к БД SEP не требуется (хотя такое требование можно включить), а при переносе БД на другой компьютер никто без указания пароля SEP залогиниться не сможет. Можно указывать пароль SEP в параметрах коннекта (isc_dbp_system_encrypt_password), но это доступно только компонентам прямого доступа. Либо, можно указать SEP в переменных среды ОС (переменная ISC_SYSTEM_ENCRYPT_PASSWORD). Лучше сделать так - SYSDSO должен залогиниться к базе используя свой пароль и SEP, и создать новый SEP. Новый SEP будет привязан уже к этому компьютеру, и остальным пользователям указывать его при коннекте не потребуется.
Разлогиниваемся, логинимся как SYSDSO, создаем SEP для базы
ALTER DATABASE SET SYSTEM ENCRYPTION PASSWORD 'aaa'
Если есть желание, чтобы даже сейчас, на этом компьютере, пользователям требовалось указывать при коннекте пароль SEP (если ваше приложение позволяет указывать этот пароль помимо обычного пароля. Если нет, они обломаются, и так лучше не делать), то к данной команде можно добавить в конце опцию EXTERNAL.
продолжение.
Комментариев нет:
Отправить комментарий