Как посмотреть гранты oracle

Обновлено: 07.07.2024

Полномочия – это право на выполнение конкретного типа 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.

Grant Privileges для таблиц

Вы можете предоставить пользователям различные привилегии к таблицам. Эти привилегии могут быть любой комбинацией SELECT, INSERT, UPDATE, DELETE, REFERENCES, ALTER, INDEX, или другие.

Синтаксис

Синтаксис для предоставления привилегий для таблицы в Oracle/PLSQL:

privileges
Привилегии для назначения. Это может быть любое из следующих значений:

Привилегии Описание
SELECT Возможность выполнения SELECT на таблице
INSERT Возможность выполнения INSERT на таблице
UPDATE Возможность выполнения UPDATE на таблице
DELETE Возможность выполнения DELETE на таблице
REFERENCES Возможность создавать CONSTRAINT, который ссылается на таблицу.
ALTER Возможность выполнять оператор ALTER TABLE, чтобы изменить описание таблицы.
INDEX Возможность создавать INDEX таблице с помощью оператора CREATE INDEX.
ALL Все привилегии для таблицы

object
наименование объекта базы данных, которому вы предоставляете привилегии. В случае предоставления привилегий таблице, это должно быть название таблицы.
user
Имя пользователя, которому будет предоставлена эта привилегия.

Пример

Рассмотрим некоторые примеры, предоставления привилегий для таблиц в Oracle.
Например, если вы хотите предоставить SELECT, INSERT, UPDATE и DELETE привилегии на таблицу с наименованием suppliers для user с именем trizor , то нужно выполнить следующие GRANT предложение:

Не знаю, чем у вас закончилась история с нашим новым пользователем DUMMY, а у меня он все же остался. Если кто-то из вас создал своего пользователя, то можете воспользоваться своим. А, вот сейчас давайте поговорим о том, как могут взаимодействовать разные схемы БД. И как это все возможно осуществить. Запускайте SQL*Plus и подключайтесь пользователем DUMMY (если вы его все-таки пристрелили, реанимируйте его согласно шагу 101). А теперь, находясь в схеме DUMMY дайте такой запрос:

Неудача "ORA-00942: таблица или представление пользователя не существует"! Говорит само за себя. Теперь попробуем:

В чем же причина? Да просто у пользователя DUMMY нет прав производить чтение из таблицы схемы MILLER! Как его предоставить? Очень просто. Подключаемся к схеме MILLER:

А теперь записываем следующее:

Меняем подключение на DUMMY:

Снова повторяем запрос вот так, чтобы было меньше столбцов:

Получаем в результате:

  • system_privilege - предоставляемое системное полномочие.
  • role - предоставляемая роль.
  • TO - определяет пользователей или роли, которым предоставляются системные полномочия.
  • PUBLIC - указывает что, системные полномочия определяемые администратором предоставляются всем пользователям.
  • WITH ADMIN OPTION - позволяет получившему системные полномочия или роль предоставлять их в дальнейшем другими пользователям или ролям. Такое решение в частности включает и возможность изменение или удаления роли.

Давайте посмотрим какие системные полномочия могут предоставляться. Основных операций в языке DDL три - это CREATE, ALTER, DROP.

  • ALTER DATABASE - Позволяет изменять саму БД.
  • ALTER USER - Позволяет изменять пользователя и его параметры (пароль, профиль, роль и т.д.)
  • ALTER PROFILE - Позволяет изменять профили.
  • ALTER TABLESPACE - Позволяет изменять табличные пространства.
  • ALTER ANY PROCEDURE - Разрешает изменение любой хранимой функции процедуры или пакета в любой схеме.
  • ALTER ANY ROLE - Разрешает изменение любой роли БД.
  • ALTER ANY SEQUENCE - Разрешает изменение любой последовательности в БД.
  • ALTER ANY TABLE - Разрешает изменение любой таблицы или вида в схеме БД.
  • ALTER ANY TRIGGER - Позволяет разрешать, запрещать компилировать любой триггер в любой схеме БД.
  • ALTER ANY INDEX - Разрешает изменение любого индекса в любой схеме.

Группа CREATE:

Позволяет создавать в любой схеме соответствующий объект:

Позволяет создавать в конкретной схеме соответствующий объект:

Удаление объектов в любой схеме, а так же очистка таблиц:

Удаление объектов в схеме:

И еще полезные системные привилегии:

Вот далеко не полный список системных привилегий, которые предоставляются оператором GRANT. Для начала я думаю хватит. А дальше все зависит от вас. Давайте теперь рассмотрим предоставление объектных привилегий. Здесь все выглядит вот так:

object_privilege - предоставляемая привилегия - одна из:

COLUMN - определяет столбец таблицы или вида, на который распространяется предоставляемая привилегия.

ON - определяет объект (таблицу, вид, и т.д.)

TO - указывает кому предоставляется привилегия.

WITH ADMIN OPTION - позволяет имеющему эту привилегию предоставлять их в дальнейшем другими пользователям или ролям.

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

Например, чтобы изъять привилегию на выборку из таблицы SALESREPS для схемы DUMMY введите следующее находясь в схеме MILLER:

Получим примерно следующее:

Вот таким образом применяя операторы GRANT и REVOKE, можно строить взаимоотношение схем и строить политику доступа к объектам БД. Попробуйте создать в новом пользователе несколько объектов и разрешить обращаться к ним из схемы MILLER. Если что не получится пишите!

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

Перед нами была поставлена задача оценки активности пользователей БД с точки зрения информационной безопасности, а именно проверки ролей, привилегий, периода доступа к БД и иных метрик, которыми наделяются пользователи БД при предоставлении доступа.

Итак, какие задачи мы поставили перед собой (сразу отмечу, что в качестве уникального ключа мы выбрали логин пользователя в Oracle, и далее обогащали логины различными системными атрибутами, при этом сохраняя его уникальность):

  1. Установить связь «пользователь Oracle – ПК», с которых производилась авторизация в Oracle конкретными пользователями;
  2. Обозначить период активности пользователя в БД, в т.ч. флаг активности в текущем году;
  3. Проверить привилегии пользователя – в 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 представления, которые показывают наглядную картину по аудиту пользователей, а также доступы к критичным объектам БД. В дальнейшем можно настроить систему алертов, которая бы при наступлении определённого события оповещала заинтересованных сотрудников любым доступным в вашей организации способом, например:

Да и в целом, инструменты, представленные в статье, частично готовы решать задачу оптимизации места на сервере за счет оценки активности пользователей. То есть, если у вас есть логины, которые последний раз заходили в БД несколько лет назад – то, вероятно, можно очищать их персональное пространство. Тема оценки активности использования объектов БД – уже совсем другая задача.

Читайте также: