Большой архив статей, книг, документации по программированию, вебдизайну, компьютерной графике, сетям, операционным системам и многому другому
 
<Добавить в Избранное>    <Сделать стартовой>    <Реклама на сайте>    <Контакты>
  Главная Документация Программы Обои   Экспорт RSS E-Books
 
 

   Базы данных -> Oracle -> Как организовать двойную парольную защиту данных в Oracle


Как организовать двойную парольную защиту данных в Oracle

В основе регламентации доступа к данным в 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

В первом случае парольная защита роли перекладывается на ОС, а во втором на службу имен. Наполнение же роли полномочиями (правами совершать действия в БД) в любом случае регулируется внутри БД.

Автор: Владимир Пржиялковский

Ссылки по теме
Так как же восстановить данные таблицы?
Заморочки от Oracle, или знать бы, где упасть
Моделирование групп объектов в Oracle
Не самые известные сведения о внешних ключах
Cегменты отката в СУБД Oracle
 

Компьютерная документация от А до Я - Главная

 

статьи телеграм
 
Интересное в сети
 
10 новых программ
CodeLobster PHP Edition 3.7.2
WinToFlash 0.7.0008
Free Video to Flash Converter 4.7.24
Total Commander v7.55
aTunes 2.0.1
Process Explorer v12.04
Backup42 v3.0
Predator 2.0.1
FastStone Image Viewer 4.1
Process Lasso 3.70.4
FastStone Image Viewer 4.0
Xion Audio Player 1.0.125
Notepad GNU v.2.2.8.7.7
K-Lite Codec Pack 5.3.0 Full


Наши сервисы
Рассылка новостей. Подпишитесь на рассылку сейчас и вы всегда будете в курсе последних событий в мире информационных технологий.
Новостные информеры. Поставьте наши информеры к себе и у вас на сайте появится дополнительный постоянно обновляемый раздел.
Добавление статей. Если вы являетесь автором статьи или обзора на тему ИТ присылайте материал нам, мы с удовольствием опубликуем его у себя на сайте.
Реклама на сайте. Размещая рекламу у нас, вы получите новых посетителей, которые могут стать вашими клиентами.
 
Это интересно
 

Copyright © CompDoc.Ru
При цитировании и перепечатке ссылка на www.compdoc.ru обязательна. Карта сайта.