2005 г.
Как организовать двойную парольную защиту данных в Oracle
Владимир Пржиялковский,
преподаватель технологий Oracl
В основе регламентации
доступа к данным в Oracle лежит парольная защита. В наиболее
распространенном случае для работы с данными в своей схеме пользователь Oracle обязан указать пароль. Однако пароль пользователя – всего-навсего
один эшелон защиты. Пароль иногда можно подсмотреть, или ненамеренно
сообщить другому лицу. А можно ли ввести дополнительную защиту, затрудняющую несанкционированный доступ ? Ответ
положителен: с помощью такого понятия, как «роль».
Введение
В основе регламентации доступа к данным в Oracle лежит парольная защита. В наиболее
распространенном случае для работы с данными в своей схеме пользователь Oracle обязан указать
пароль. Хотя Oracle и предоставляет возможность упрочнить парольную
защиту специальными средствами («профиль»), пароль пользователя все равно остается лишь одним эшелоном защиты. Пароль иногда можно подсмотреть, или ненамеренно сообщить другому
лицу. А можно ли ввести дополнительную защиту, затрудняющую несанкционированный доступ ?
В некоторых прикладных системах, например, используется практика «раздвоенного» пароля. Подключиться к системе могут лишь
одновременно два физических лица: один знает одну часть пароля, а другой – другую.
Хотя вероятность сговора двоих остается, риск несанкционированного
доступа существенно снижается. Можно ли в Oracle
организовать «раздвоение» пароля или что-то подобное ?
Оказывается, можно: посредством «роли». Роль известна
специалистам по Oracle тем, что позволяет технологично организовать групповую передачу
пользователям привилегий (полномочий) для работы с объектами в БД. Это удобно, а иногда практически
безальтернативно, например если пользователей Oracle заведено много. Реже замечаются два других
свойства роли:
(а) возможность
«активизировать» и «отключать» роль, приписанную пользователю, во время работы сеанса связи с СУБД и
(б) возможность иметь
собственный пароль.
Применение этих двух свойств в совокупности и позволяет организовать второй эшелон парольной защиты
объектов, хранимых в базе. Для этого надо лишь выдать пользователю привилегии не напрямую, а через роль. Ниже рассматривается пример, поясняющий эту
идею.
Пример
Рассмотрим пример. Создадим пользователя ADAM и снабдим его
единственным полномочием подключения к СУБД.
Создадим роль, защищенную паролем, и припишем ее новому пользователю:
CONNECT / AS SYSDBA
CREATE USER adam IDENTIFIED BY eva;
GRANT CREATE SESSION TO adam;
CREATE ROLE tablecreator IDENTIFIED BY say123;
GRANT tablecreator TO adam;
Проверка:
SQL> CONNECT adam/eva
Connected.SQL> SELECT * FROM session_roles;
ROLE
------------------------------
TABLECREATOR
Переведем роль (только
ее) в изначально отключенное состояние:
CONNECT / AS SYSDBA
ALTER USER adam DEFAULT ROLE ALL EXCEPT tablecreator;
Конструкция DEFAULT ROLE допускает указание
также просто ALL, NONE
или же явного перечисления ролей, которые мы хотим сделать изначально активными
для всех сеансов пользователя. В
конкретном примере с равным успехом можно было указать DEFAULT ROLE NONE,
просто приведенный вариант более типичен на практике.
Снова проверка:
SQL> CONNECT adam/eva
Connected.
SQL> SELECT * FROM session_roles;
no rows selected
SQL> SET ROLE tablecreator IDENTIFIED BY say123;
Role set.
SQL> SELECT * FROM session_roles;
ROLE
------------------------------
TABLECREATOR
Теперь для возможности
реально создавать таблицы пользователь ADAM обязан не только указать собственный пароль при
подключении к СУБД, но и указать еще один пароль для активации роли.
Фирма Oracle рекомендует
создавать для отдельных видов приложений отдельные роли (хотя бы и составные,
то есть включающие в свой состав какие-нибудь другие роли) и распоряжаться ими
способом, указанным выше. Если
приложение будет активизировать роль самостоятельно, то человек, запускающий
приложение, может пароля роли и не знать, а знания одного только
пароля пользователя Oracle окажется недостаточным для работы с базой данных вне приложения, например,
из SQL*Plus. С другой стороны мы вовсе не
обязаны извещать, приложение, употребляющее пароль роли для ее активации, о
пароле пользователя: теперь он может
быть указан отдельно человеком, устанавливающим соединение с СУБД. Технику такого подхода можно проработать и
развить далее.
Динамика роли и другие полезные потребительские качества
Дополнительным доводом в
пользу употребления роли (неважно, защищенной паролем, или нет) является
возможность с ее помощью динамически менять объем полномочий пользователя в
процессе его работы. Простой пример доказывает это. Продолжим работу под
именем ADAM:
SQL> SELECT * FROM session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
SQL> HOST sqlplus / AS SYSDBA
.......................................................
.......................................................
Connected to:
Oracle Database 10g Enterprise Edition................
With the Partitioning, Oracle Label Security,.........
SQL> GRANT CREATE TABLE TO tablecreator;
Grant succeeded.
SQL> EXIT
Disconnected from Oracle Database 10g................
With the Partitioning, Oracle Label Security,........
SQL> /
PRIVILEGE
----------------------------------------
CREATE SESSION
CREATE TABLE
TABLE появилась в рамках
прежнего, продолжающего свою работу, сеанса пользователя ADAM.
Еще одно свойство,
повышающее потребительское качество роли, заключается в том, что Oracle позволяет ввести
для ролей внешнее управление, когда включаться или выключаться они смогут
операционной системой или службой имен.
Для этого роли должны создаваться с помощью соответственно двух
специальных указаний:
- CREATE ROLE имя_роли IDENTIFIED EXTERNALLY
- CREATE ROLE имя_роли IDENTIFIED GLOBALLY AS …
В первом случае парольная
защита роли перекладывается на ОС, а во втором на службу имен. Наполнение же роли полномочиями (правами
совершать действия в БД) в любом случае регулируется внутри БД.