Организация управления правами доступа в современных субд oracle10g и ms sql server 2008

Вид материала

Содержание

1.2 Представления, защищающие базу данных
Таблица 1.5. Представление DBA_SYS_PRIVS Столбец Описание
Таблица 5.8. Представление DBA_TABS_PRIVS Столбец Описание

Подобный материал:

1 2 3 4 5

1.2 Представления, защищающие базу данных

Эти представления позволяют управлять защищенной областью (security domain) – набором атрибутов, определяющих пределы разрешенных пользователям действий, квоты выделяемой дисковой памяти и ресурсы.

Таблица 1.1. Представления DBA_, используемые для защиты базы данных

Представление	Описание
DBA_PROFILES	Все профили и их ограничения
DBA_ROLES	Все роли, существующие в базе данных
DBA_ROLES	Все роли, существующие в базе данных
DBA_ROLE_PRIVS	Роли, назначенные пользователям и другим ролям
DBA_SYS_PRIVS	Системные привилегии, предоставленные пользователям и ролям
DBA_TAB_PRIVS	Все разрешения (grants) на объекты базы данных
DBA_USERS	Информация обо всех пользователях базы данных
DBA_TS_QUOTAS	Квоты в табличных пространствах для всех пользователей

1.2.1 DBA_USERS

аблица 1.2. Представление DBA_USER

Столбец	Описание
USERNAME	Имя пользователя
USER_ID	Идентификационный номер пользователя
PASSWORD	Пароль в зашифрованном виде
ACCOUNT_STATUS	Показывает состояние учетной записи: заблокирована, действительна или разблокирована
LOCK_DATE	Дата блокировки учетной записи (если Учетная запись заблокирована)
EXPIRY_DATE	Дата, после которой учетная запись становится недействительной
DEFAULT_TABLESPACE	Табличное пространство по умолчанию для данных
TEMPORARY_TABLESPACE	Табличное пространство по умолчанию для временных сегментов
CHEATED	Дата создания пользователя
PROFILE	Имя профиля ресурсов пользователя
INITIAL_RSRC_CONSUMER_GROUP	Группа потребителей ресурсов, в которую изначально входит пользователь
EXTERNAL_NAME	Внешнее имя пользователя

Рассмотрим столбцы, используемые чаще всего. Название Username говорит само за себя — это имя учетной записи, под которым пользователь входит в базу данных. Имя пользователя может состоять из букв алфавита, цифр, специальных символов — подчеркивания (_), знака доллара ($) или знака номера (#). Столбец User_ID содержит уникальный идентификатор пользователя, состоящий из цифр от 0 до 9. Но и в столбце Username также должно содержаться уникальное (правда, уже алфавитно-цифровое) значение. Когда пользователь создает объект и при этом не указывает табличное пространство, в котором этот объект создается, Oracle создаст его в табличном пространстве, которое было назначено по умолчанию (Default_Tablespace).

Столбец Temporary_Tablespace содержит имя табличного пространства для пользователя, которое Oracle использует в тех случаях, когда для выполнения оператора SQL необходимо произвести сортировку.

Столбец Password содержит зашифрованные значения паролей для учетных записей. Создадим пользователя с именем RACHEL:

-> Create user RACHEL identified by TEST default tablespace USERS temporary tablespace TEMP;

User created.

Столбец Асcount_Status сообщает, имеют ли пользователи доступ к своим учетным записям, и если нет, то почему. Lock_Date содержит дату блокировки учетной записи, вызванной серией неудачных попыток ввода пароля (количество попыток устанавливается в профиле пользователя). Expiry_Date — это дата стечения срока действия пароля. Перед принудительной сменой пароля можно установить период отсрочки, на протяжении которого пользователи смогут входить по старому паролю. Два оставшихся столбца в представлении DBA_USERS – это Created, содержащий дату создания учетной записи, и Profile, в котором указан профиль, используемый при проверке ограничений ресурсов для данного пользователя.

1.2.2 DBA_ROLES

Представление DBA_ROLES содержит информацию обо всех определенных в базе данных ролях. При создании базы данных в версиях 9 и 10 Oracle создает несколько стандартных ролей. Столбцы этого представления перечислены в таблице 1.3.

Т

аблица 1.3. Представление DBA_ROLES

Столбец	Описание
ROLE	Имя роли
PASSWORD_REQUIRED	Показывает, требуется ли пароль для разрешения роли

До Oracle6 пользователям можно было присвоить только три роли:

CONNECT Позволяет пользователю обращаться к базе данных

RESOURCE Дает пользователю возможность создавать объекты и использовать пространство в базе данных

DBA Позволяет выполнять любые действия в базе данных

Фактически это были даже не роли, а наборы привилегий, хранившиеся в ядре Oracle, которые можно было предоставлять пользователям. Настоящие, роли появились в Oracle6. Начиная с Oracle7, администратор получил возможность комбинировать группы системных и объектных привилегий, а также создавать нестандартные роли, отвечающие потребностям приложений.

Роли CONNECT, RESOURCE и DBA Oracle сохраняет для обратной совместимости, но не гарантирует, что они будут присутствовать всегда. Предопределенные роли могут меняться от версии к версии, поэтому, как и для самих представлений DBA_, нужно всегда проверять, какие роли были добавлены, а какие удалены.

Необходимо помнить, что вместе с ролью RESOURCE пользователь получает привилегию unlimited tablespace, которая позволяет создавать объекты не только в табличном пространстве по умолчанию, но и в других табличных пространствах, причем без какой-либо квоты. Квота (quota) — это объем пространства, которое может быть выделено пользователю в табличном пространстве.

Столбец Password_Required показывает, должен ли вводиться пароль, когда пользователь или приложение разрешает роль. Если пароль необходим, он указывается в команде set role. Из этого правила есть одно исключение. Если роль, требующая пароля, назначена пользователю как роль по умолчанию, она будет автоматически разрешена при входе пользователя в базу данных, и ему не нужно будет вводить пароль. Может быть более одной роли по умолчанию, но все они должны быть назначены как части одного оператора SQL. Увидеть роли, разрешенные в текущем сеансе, можно с помощью следующего SQL-оператора:

select * from SESSION_ROLES;

Чтобы создать роль, нужно иметь либо привилегию create role, либо роль, которой была предоставлена эта привилегия/Роль создается следующим образом:

create role TESTROLE;

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

grant CREATE ROLE to TESTROLE;

Grant succeeded.

Если теперь назначить роль TESTROLE какому-либо пользователю, он сможет создавать роли в базе данных.

1.2.3 DBA_ROLE_PRIVS

В предыдущем разделе было показано, как определить, какие роли существуют в базе данных. Представление DBA_ROLE_PRIVS расскажет, каким пользователям (или ролям) и с какими административными привилегиями были назначены эти роли. Столбцы этого представления перечислены в таблице 1.4.

Т

аблица 1.4. Представление DBA_ROLE_PRIVS

Столбец	Описание
GRANTEE	Имя получателя роли — пользователя или другой роли
GRANTED_ROLE	Имя назначенной роли
ADMIN_OPTION	Показывает, что роль была назначена с опцией ADMIN
DEFAULT_ROLE	Показывает, что роль назначена пользователю как роль по умолчанию

Чтобы вновь созданную роль можно было использовать, ее необходимо назначить пользователю или другой роли. Представление DBA_ROLE__PRIVS позволяет увидеть, кому какие роли были назначены. Столбец Grantee содержит имя пользователя или роли, которые получили возможность доступа к роли. Роли нельзя назначать по кругу. Это означает, что если вы создали роли CLERK и MANAGER, а затем назначили роль CLERK роли MANAGER, то уже нельзя назначить роль MANAGER роли CLERK, поскольку в этом случае роль MANAGER будет ссылаться сама на себя. Столбец Granted_Role полностью аналогичен столбцу Role представления DBA_ROLES. Столбец Admin_Option показывает, может ли пользователь, получивший роль, назначать ее другим, а столбец Default_Role показывает, будет ли данная роль автоматически разрешена при входе пользователя в базу данных.

Чтобы увидеть, какие роли были назначены пользователю и будут ли они автоматически разрешены, можно ввести следующий запрос:

select Grantee, Granted_Role, Default_Role from DBA_ROLE_PRIVS where Grantee not in ('SYS'.'SYSTEM') order by Grantee;

Если нужно посмотреть, назначались ли кому-нибудь роли, требующие пароля, достаточно соединить таблицы DBA_ROLES и DBA_ROLE_PRIVS:

select Grantee, Granted_Role from DBA_ROLES a, DBA_ROLE_PRIVS D where a.Role = b.Granted_Role and a.Password_Required='YES';

1.2.4 DBA_SYS_PRIVS

Представление DBA_SYS_PRIVS показывает, какие привилегии системного уровня были предоставлены пользователям или ролям. Такие привилегии позволяют манипулировать средой базы данных, создавая, удаляя или изменяя объекты. Столбцы этого представления перечислены в таблице 1.5.

Таблица 1.5. Представление DBA_SYS_PRIVS

Столбец Описание

GRANTEE Имя получателя привилегии — пользователя или роли

PRIVILEGE Системная привилегия

ADMIN_OPTION Показывает, что роль была предоставлена с опцией

ADMIN.

Следует проверять количество и типы системных привилегий в каждой новой версии базы данных. С добавлением новых возможностей появляются и новые привилегии, позволяющие ими управлять.

Для того, чтобы узнать какие системные привилегии были даны пользователю или роли необходимо выполнить следующий SQL-запрос:

select * from DBA_SYS_PRIVS where Grantee = 'имя_пользователя(роли)';

1.2.5 DBA_TAB_PRIVS

Представление DBA_TAB_PRIVS (см. таблицу 5.8) дает информацию обо всех привилегиях на все объекты базы данных.

Таблица 5.8. Представление DBA_TABS_PRIVS

Столбец Описание

GRANTEE Пользователь, которому предоставлен доступ

OWNER Владелец объекта

TABLE_NAME Имя объекта

GRANTOR Пользователь, который разрешает доступ

PRIVILEGE Привилегия на таблицу

GRANTABLE Показывает, может ли привилегия предоставляться другому пользователю

H

IERARCHY Привилегия предоставляется с опцией иерархичности
(hierarchy)

Глядя на сочетание "TAB" в имени представления, можно подумать, что оно содержит информацию только о табличных привилегиях. Однако на самом деле здесь представлена информация о правах доступа ко всем объектам в базе данных. Объект — это то, чем может владеть пользователь. Хотя привилегии можно предоставить на большинство объектов, существует несколько исключений. Индексы, триггеры и синонимы считаются объектами, но к ним нельзя обращаться непосредственно. Если вы получили доступ к таблице, то автоматически будете иметь доступ к ее индексам и триггерам. Oracle запускает триггер, если он относится к выполняемому над таблицей действию, и при необходимости модифицирует индекс таблицы или осуществляет к нему доступ. Синоним — это просто псевдоним, поэтому для его использования привилегии не требуются.

Столбец Grantee ссылается на пользователя, которому была выдана данная привилегия. Owner — это владелец самого объекта. Table_Name содержит имя объекта, a Grantor - это пользователь, который предоставляет привилегию. Привилегия представляет собой право доступа, и столбец Grantable показывает, может ли пользователь, получивший привилегию, передать ее кому-либо еще. Поскольку владелец объекта может передавать другому пользователю право предоставления доступа к объекту, для прослеживания всей этой цепочки необходимы оба столбца — Owner и Grantor.

Один из лучших способов защитить базу данных — это потратить немного времени на то, чтобы разобраться, какие привилегии в действительности нужны каждой из групп пользователей, а затем построить и предоставить роли, обеспечивающие именно такой доступ и ничего более. Конечно, проще всего предоставить всем пользователям привилегии grant all to public на все объекты, но все-таки это не выход.

Предоставляя пользователю привилегию с параметром with grant option, важно помнить, что если владелец таблицы впоследствии отменит эту привилегию для первого пользователя, то ее потеряют и все остальные пользователи.

Blog