(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 Personal Edition Named User Plus License
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
AutoCAD - mobile app Premium CLOUD Commercial New Single-user ELD Annual Subscription
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Мастерская программиста
Программирование на Visual С++
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Сайт инструмент (1)
Я бывший программист пользовался 1 сайтом проверенным он мне действительно помог я блогодоря...
 
Где взять лицензионный ключ для AllFusion Process Modeler (BPwin) 7? (5)
Выручайте!!! где найти ключ, ужасно срочно нужна программа. заранее спасибо!
 
работа на дому! (5)
Доброго времени суток дорогие друзья. Многоуровневый маркетинг окончательно признан...
 
Регистрация на Oracle.com (4)
Сразу прошу прощения за тупой вопрос, но вчера зарегался на oracle.com (чтоб 9i слить себе...
 
Ищу кодера (2)
Добрый день! Ищу кодера который сможет сделать копии сайтов. Сколько будет стоить скопировать...
 
 
 



    
rambler's top100 Rambler's Top100