(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Как организовать двойную парольную защиту данных в 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

Привилегия CREATE TABLE появилась в рамках прежнего, продолжающего свою работу, сеанса пользователя ADAM.

Еще одно свойство, повышающее потребительское качество роли, заключается в том, что Oracle позволяет ввести для ролей внешнее управление, когда включаться или выключаться они смогут операционной системой или службой имен. Для этого роли должны создаваться с помощью соответственно двух специальных указаний:

  • CREATE ROLE имя_роли IDENTIFIED EXTERNALLY
  • CREATE ROLE имя_роли IDENTIFIED GLOBALLY AS

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

Ссылки по теме



 Распечатать »
 Правила публикации »
  Обсудить материал в конференции Oracle »
Написать редактору 
 Рекомендовать » Дата публикации: 08.07.2005 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Oracle Database Standard Edition 2 Named User Plus License
Oracle Database Personal Edition Named User Plus Software Update License & Support
Oracle Database Standard Edition 2 Processor License
Oracle Database Personal Edition Named User Plus License
Panda Antivirus Pro - ESD версия - на 1 устройство - (лицензия на 1 год)
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Реестр Windows. Секреты работы на компьютере
Вопросы и ответы по MS SQL Server
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Как выбрать матрас (5)
Подскажите как правильно выбрать матрас и на что в целом следует обратить внимание на ваш...
 
работа на дому! (7)
Доброго времени суток дорогие друзья. Многоуровневый маркетинг окончательно признан...
 
Актуальные зеркала букмекерских контор (4)
Бетторы не всегда доверяют зеркалам БК, а зря, потому что эти «запасные аэродромы» запускают...
 
Ставки на спорт через зеркало БК Пинакл (1)
Актуальное зеркало букмекерской конторы Пинакл https://superbet.guru/pinacle-mirror/ всегда...
 
Аналоги виагры (2)
Если мужчине, по каким либо причинам, не подходит виагра, существуют качественные аналоги...
 
 
 



    
rambler's top100 Rambler's Top100