Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в России, Европе и США

Бесплатная поддержка и администрирование

Оплата российскими и международными картами

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

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

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

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...