Oracle как посмотреть права пользователя
Загрузка. Пожалуйста,
подождите.
Репутация: нет
Всего: нет
Репутация: 12
Всего: 26
В смысле доступные? Не врубился в вопрос.
Slackware 12.2 | Linux 2.6.27 | Fluxbox 1.1.1 | Wmii 3 | Opera 9.63--
Oracle это не только способ отмывания денег, но и вполне себе преличная база данных.
Репутация: нет
Всего: нет
Репутация: 12
Всего: 26
Не всё так просто, на самом деле. Проблема в том, что права в оракл это комклексное понятие, поэтому там помойка. Примерно как Windows со всеми эти группами и наследованиями.
Реальные эффективные права текущей сессии можно посмотреть в session_privs.
Права пользователя разделяются на системные (user_sys_prev), объектные (user_tab_privs) и колоночные (user_col_privs). Кроме того добавляет гемороя то, что существуют ещё так называемые роли. Эта ерунда очень похожа по своему действию на группу. Ты грантуешь что-нить какой-нить роли, а потом даёшь эту роль куче пользователей. Соответственно с этим связанны таблички типа dba_role_privs.
В общем всё надёжно просто и по индуски. Вот тут пара скриптов, которые это разруливают. Дерзай.
З.Ы. Ну и для неосведомлёных. Раз есть user_sys_prev, значит есть и dba_sys_prev. Первая покажет только данные о текущем пользователе, вторая обо всех. Но нужна роль dba.
Slackware 12.2 | Linux 2.6.27 | Fluxbox 1.1.1 | Wmii 3 | Opera 9.63--
Oracle это не только способ отмывания денег, но и вполне себе преличная база данных.
Данный раздел предназначен для обсуждения проблем с Oracle Database, другие продукты Oracle здесь не обсуждаются. Просьба при создании темы, придерживаться следующих правил:
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Zloxa, LSD.
[ Время генерации скрипта: 0.1300 ] [ Использовано запросов: 21 ] [ GZIP включён ]
При установке Oracle по умолчанию создаются два пользователя/схемы - SYS и SYSTEM. Я написал "пользователя/схемы" потому, что при создании нового пользователя для него создается одноименная схема. Не сразу понятно чем понятие "пользователь" отличается от понятия "схема". Чтобы понять представьте пользователя Windows (Unix). Пользователь имеет имя ИмяПользователя и принадлежащую ему папку - C:\Users\ИмяПользователя ( /home/ИмяПользователя ). Так вот пользователь Oracle аналогичен пользователю Windows, а схема - аналогична папке пользователя. Точно так же как у пользователя Windows, у пользователя Oracle есть набор прав. Так же как папка пользователя Windows содержит различные файлы, также и схема Oracle содержит различные объекты - таблицы, последовательности, триггеры и др. Если продолжать аналогию, то пользователей SYS и SYSTEM можно считать Администратором Windows или root-пользователем Unix. Они имеют неограниченные права. И работать под ними не рекомендуется. По-этому сначала нужно создать еще одного пользователя.
1. Создание пользователя и предоставление ему прав
Создадим пользователя, например fiftin :
Мы создали пользователя fiftin с паролем 123456 . Он не имеет абсолютно никаких прав. Вы даже не сможете под ним зайти:
Для наделения пользователя правами существует команда GRANT . Например дадим права пользователю fiftin на вход:
Если теперь вы попробуете подключиться как пользователь fiftin у вас это получится. Но это все что разрешено пользователю fiftin. Наделим пользователя правами администратора:
Теперь вы можете подцепиться к БД под fiftin'ом как админ:
Создадим таблицу:
Вставим данные:
2. Права на создание таблиц
Создадим еще одного пользователя - test:
Дадим ему права:
Теперь пользователь test может подключаться и создавать таблицы. Попробуем создать таблицу (не забудьте зайти под test'ом):
Получаем ошибку:
Почему так? Оказывается для того чтобы обычный пользователь (не админ) мог что-либо создать в БД, ему нужно выделить для этого место. Зайдем снова под fiftin'ом и выполним команду:
Этой командой мы выделяем пользователю test 50Мб под его нужды. Попробуйте теперь зайти под пользователем test и создать таблицу и у вас получится.
Основы Oracle 18c - 19c часть 8 - права доступа, роли, учетные записи
Приведем наиболее часто используемые:
CREATE SESSION – право подключения к БД
ALTER DATABASE – право изменения БД
CREATE TABLESPACE – право создавать табличное пространтсво
ALTER TABLESPACE – право изменять табличное пространтсво
DROP TABLESPACE – право удалять табличное пространтсво
CREATE TABLE – право создавать, изменять, удалять таблицы в своей схеме
INSERT ANYTABLE – право добавлять данные в таблиц, которые не принадлежат учетной записи
UPDATE ANYTABLE – право изменять данные в таблиц, которые не принадлежат учетной записи
DELETE ANYTABLE – право удалять данные в таблиц, которые не принадлежат учетной записи
SELECT ANYTABLE – право выборки данных из таблиц, которые не принадлежат учетной записи
Синтаксис назначения прав:
GRANT privilege [,privilege…] TO User_Name;
Пример создания учетной записи (схемы) User_Name
С паролем User_Pass
Разрешаем занимаемое пространство в 10мб. от пространства по умолчанию USERS
CREATE USER User_Name IDENTIFIED BY User_Pass
DEFAULT TABLESPACE USERS QUOTA 10M ON USERS;
Пример, назначение всех основных привилегий для учетной записи:
GRANT CREATE SESSION, ALTER SESSION,
CREATE TABLE, CREATE VIEW, CREATE TRIGGER, CREATE PROCEDURE,
CREATE CLUSTER, CREATE DATABASE LINK,
CREATE SYNONYM, CREATE SEQUENCE, CREATE TYPE, CREATE OPERATOR
TO User_Name ;
В примере выше разрешено подключаться, настраивать сессию, создавать объекты в БД
Создавать объекты разрешено только в схеме аккаунта
Отсутствуют права к схемам других аккаунтов
Пример предоставления табличного пространства USERS по умолчанию для учетной записи User_Name:
ALTER USER User_Name DEFAULT TABLESPACE USERS
Создание ролей, учетных записей, пароля, связь ролей и учетных записей
Предоставление привилегий
Синтаксис:
GRANT privilege ON [schema.]object TO username [WITH GRANT OPTION];
Информация о имеющихся привилегиях
Отмена, удаление привилегий, ролей, четных записей
Полномочия – это право на выполнение конкретного типа SQL-оператора или на доступ к объекту базы данных, принадлежащему другому пользователю. В базе данных Oracle необходимо явно предоставить пользователю полномочия для выполнения любых действий, включая подключение к базе данных или выборку, изменение и обновление данных в любой таблице, кроме собственной.
Существуют два основных типа полномочий Oracle: системные полномочия и объектные полномочия. Для предоставления пользователям как системных, так и объектынх полномочий служит оператор GRANT.
Системные полномочия:
Системные полномочия позволяют пользователю выполнить конкретное действие в базе данных либо действие с любым объектом схемы, конкретного типа. Хороший пример первого типа системных полномочий – полномочия, которые позволяют подключаться к базе данных, носящие название полномочий CONNECT. Другими полномочиями этого типа являются полномоичия CREATE TABLESPACE, CREATE USER, DROP USER и ALTER USER.
Второй класс системных полномоичий предоставляет пользователям право на выполнение операций, которыевлияют на объекты в любой схеме. Примерами этого типа системных полномочий служат ANALYZE ANY TABLE, GRANT ANY PRIVILEGE, INSERT ANY TABLE, DELETE ANY TABLE и т.п. Системные полномочия являются очень мощным средством и выдача их не тому пользователю может оказать разруши тельное влияние на базу данных.
Ниже перечислены некоторые наиболее часто используемые полномочия базы данных Oracle:
- ADVISOR
- ALTER DATABASE
- ALTER SYSTEM
- AUDIT SYSTEM
- CREATE DATABASE LINK
- CREATE TABLE
- CREATE ANY INDEX
- CREATE SESSION
- CREATE TABLESPACE
- CREATE USER
- DROP USER
- INSERT ANY TABLE
Пример:
Объектыные полномочия:
Объектыне полномочия – это полномочия по отношению к различным типам объектов базы данных. Объектыные полномочия дают пользователю возможность выполнять действия с конкретной таблицей, представлением, материализованным представлением, последовательностью, процедурой, функцией или пакетом. Следовательно, всем пользователям базы данных нужны объектные полномочия.
Для выдачи объектных полномочий можно использовать следующие SQL-операторы.
Добрый день! Сегодняшняя статья посвящена аудиту пользователей в БД. Все примеры работают на БД Oracle, но используемые алгоритмы и срезы проверок, вероятно, есть во всех распространенных базах, просто немного иначе реализуются.
Перед нами была поставлена задача оценки активности пользователей БД с точки зрения информационной безопасности, а именно проверки ролей, привилегий, периода доступа к БД и иных метрик, которыми наделяются пользователи БД при предоставлении доступа.
Итак, какие задачи мы поставили перед собой (сразу отмечу, что в качестве уникального ключа мы выбрали логин пользователя в Oracle, и далее обогащали логины различными системными атрибутами, при этом сохраняя его уникальность):
- Установить связь «пользователь Oracle – ПК», с которых производилась авторизация в Oracle конкретными пользователями;
- Обозначить период активности пользователя в БД, в т.ч. флаг активности в текущем году;
- Проверить привилегии пользователя – в Oracle это звучит как Role privileges и System privileges.
Также была задача выявить все возможные действия для каждого объекта БД каждым пользователем, но сохранить уникальность пользователя не удавалось: оборотной стороной медали была потеря наглядности данных, поэтому мы решили создать отдельное представление.
Итак, начну с последнего и наиболее простого с точки зрения реализации пункта – мониторинга привилегий пользователей на каждый объект БД. Для создания этого представления хватило системной таблицы dba_tab_privs, в которой содержатся все пользователи и их полномочия, а также те, кто выдал эти полномочия. Итак, запустим следующий код:
Результат этого кода показывает, к каким объектам БД (OWNER, TABLE_NAME, TYPE) имеет доступ конкретный пользователь (GRANTEE), и какие полномочия у него есть для работы с каждым объектом БД (PRIVS_TO_OBJECT_BD):
Иными словами, суть представления – показать доступные действия пользователя для каждого объекта БД (в данном случае связка Пользователь БД + Объект БД – уникальна).
Отлично, двигаемся дальше. Теперь рассмотрим код для сбора различных системных атрибутов по каждому пользователю БД. Ввиду сложности кода разобьём его на составные части (для удобства выделим связанные атрибуты в SQL-блоки “with”). Так, сначала определимся с перечнем пользователей, по которым будем собирать аналитику. В нашем случае мы исключили пользователей, которые в качестве default_tablespace используют системные пространства БД:
Данный код использует системное представление dba_users и собирает некоторые атрибуты, например, текущий статус пользователя (открыт/заблокирован/…), дату блокировки пользователя, а также профайл пользователя (администратор/пользователь/технологическая учетная запись):
Так, список ключей уникален, теперь будем обогащать эту таблицу атрибутами из других системных таблиц, исходя из задачи. О них далее.
Добавим данные по авторизациям пользователей в БД. Для этого немного преобразуем системное представление dba_audit_session. Ввиду того, что изначально в представлении перечень пользователей БД неуникален, воспользуемся функцией listagg для сбора однотипных метрик пользователя в один кортеж. Для справки: функция listagg таблицу вида:
Преобразует в вид:
С помощью этой функции получаем уникальность пользователей БД, а значит готовы обогащать этими данными первоначальный список пользователей. Исходный код по авторизациям пользователей в БД выглядит так:
Результат исполнения кода:
Обратите внимание, дополнительно оконная sql-функция считает количество ПК, с которых осуществлялся вход под выбранным пользователем (атрибут PC_CNT).
Результат исполнения запроса:
Далее, выделим права каждого пользователя, для этого используем 2 таблицы Oracle DB: dba_role_privs и dba_tab_privs:
И второй код, для dba_tab_privs:
В столбце CNT_ROLE_PRIVELEGES – количество ролей каждого пользователя. Здесь можно отследить критичные. Например, для нас возможность пользователя просматривать содержимое всех таблиц на сервере – недопустима, поэтому все роли “select any table” были заменены на “select table”, что позволяет выводить содержимое только созданных пользователем таблиц. В принципе готово, осталось собрать все блоки “with” в одно представление с помощью конструкции JOIN:
Результат итогового представления (для наглядности показан в виде single record view):
Таким образом созданы 2 представления, которые показывают наглядную картину по аудиту пользователей, а также доступы к критичным объектам БД. В дальнейшем можно настроить систему алертов, которая бы при наступлении определённого события оповещала заинтересованных сотрудников любым доступным в вашей организации способом, например:
Да и в целом, инструменты, представленные в статье, частично готовы решать задачу оптимизации места на сервере за счет оценки активности пользователей. То есть, если у вас есть логины, которые последний раз заходили в БД несколько лет назад – то, вероятно, можно очищать их персональное пространство. Тема оценки активности использования объектов БД – уже совсем другая задача.
Читайте также: