Oracle гранты на схему

Обновлено: 02.07.2024

Oracle гранты на схему

Не знаю, чем у вас закончилась история с нашим новым пользователем 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. Если что не получится пишите!

Инструкция GRANT советы и хитрости Oracle

Реализация инструкции GRANT в системе Oracle поддерживает огромное количество вариантов и изменений. Синтаксис ее следующий.

[WITH OPTION] [IDENTIFIED BY пароль] [WIТН ADMIN OPTION];

Вы можете присваивать несколько привилегий в одной инструкции, но эти привилегии должны относиться к одному типу (объектные, системные или ролевые).

Например, вы можете предоставить пользователю три объектные привилегии в одной таблице при помощи одной инструкции GRANT, затем при помощи отдельной инструкции назначить две системные привилегии какой-нибудь роли, а в третьей инструкции присвоить пользователю несколько ролей, но нельзя сделать все это в одной инструкции GRANT.

Ниже приводятся параметры инструкции GRANT платформы Oracle.

объект_имя_привилегия

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

ALL [PRIVILEGES]

Присваиваются все доступные привилегии доступа к объекту схемы. Можно применять к таблицам.

ALTER

Предоставляется право изменять существующую таблицу при помощи инструкции ALTER TABLE. Можно применять к таблицам и последовательностям.

DEBUG

Предоставляется право обращаться к таблице при помощи отладчика. Этот доступ применим к любым триггерам таблицы и любой информации о коде SQL, напрямую обращавшемся к таблице. Можно применять к таблицам, представлениям, процедурам, функциям, пакетам, объектам Java и типам.

EXECUTE

Предоставляется право запускать хранимую процедуру, пользовательскую функцию или пакет. Можно применять к процедурам, функциям, пакетам, объектам Java, библиотекам, типам, индексным типам и пользовательским операторам.

INDEX

Предоставляется право создавать индексы по таблице.

(ON COMMIT REFRESH QUERY REWRITE>

Предоставляется привилегия создавать материализованные представления, обновляющиеся после транзакции (refresh-on-commit), или создавать материализованное представление для переписывания запросов к указанной таблице. Применяется только к материализованным представлениям.

Предоставляется привилегия читать и записывать файлы в директорию, указанную с помощью полного пути к директории операционной системы. Поскольку система Oracle имеет возможность сохранять файлы за пределами базы данных, серверный процесс Oracle должен быть запущен пользователем, имеющим привилегии доступа к указанным директориям. Вы можете включить в Oracle при помощи этого механизма систему обеспечения безопасности на уровне отдельных пользователей. Обратите внимание, что предложение WRITE можно использовать только с внешней таблицей, например файлом журнала или файлом ошибок.

REFERENCES

Предоставляется право определять ограничения, обеспечивающие ссылочную целостность. Можно использовать в таблицах.

(SELECT | INSERT | UPDATE DELETE>

Предоставляется право выполнять соответствующие команды SQL применительно к указанному объекту схемы. Можно использовать в таблицах, представлениях, последовательностях (только SELECT) и материализованных представлениях (только SELECT). Отметьте, что вы должны предоставить привилегию SELECT тому пользователю или роли, которому требуется привилегия DELETE. Вы можете назначать привилегии на уровне столбцов, включив в инструкцию, после имени объекта, заключенный в скобки список столбцов. Это возможно только при предоставлении объектных привилегий INSERT, REFERENCES или UPDATE в таблице или представлении.

UNDER

Предоставляется право создавать представления-потомки указанного представления. Используется только с представлениями и типами.

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

Указанная системная привилегия Oracle назначается одному или нескольким пользователям или ролям. Например, вы можете предоставлять такие привилегии, как CREATE TRIGGER или ALTER USER. В обоих случаях предоставление системной привилегии наделяет пользователя или роль правом выполнять команду с соответствующим именем. Полный список системных привилегий приводится в 3.2 ниже в этом разделе.

роль

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

CONNECT, RESOURCE и DBA

Предлагаются для обратной совместимости с предыдущими версиями Oracle.

Не используйте эти роли в текущей и более новых версиях Oracle, поскольку в будущем их поддержка может быть прекращена.

DELETEJOA TALOGJROLE, EXECUTEJJA TALOGJROLE и SELECT_СА TALOGJ.OLE

Пользователи, которым присвоена эта роль, могут удалять, выполнять и отбирать данные из словарных представлений и пакетов.

EXP_FULL_DATABASE и IMP_FULL_DATABASE

Пользователи, которым присвоена эта роль, могут запускать утилиты импорта и экспорта.

AQJJSERJROLE и AQ_ADMINISTRATORJROLE

Пользователи, которым присвоена эта роль, могут использовать или администрировать такую функциональность Oracle, как Advanced Queuing.

SNMPAGENT

Присваивается только Oracle Enterprise Manager и Intelligent Agent.

RECOVERY_CATA LOGO WNER

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

HS_ADMIN_ROLE

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

ON имя_схемы

Пользователю или роли предоставляется привилегия доступа к объекту схемы. К объектам базы данных относятся: таблицы, представления, последовательности, хранимые процедуры, пользовательские функции, пакеты, материализованные представления, пользовательские типы, библиотеки, индексные типы, пользовательские операторы или синонимы всех этих объектов. Если имя схемы не будет указано, будет подразумеваться схема текущего пользователя. Платформа Oracle также поддерживает два ключевых слова для особых случаев.

Дополнительная информация по теме

Некоторые советы и методы использования инструкции INSERT в базах данных на платформе Oracle

Правила и методы использования инструкции FETCH в базах данных на платформе Oracle

Способы и методы использования инструкции DELETE в базах данных на платформе Oracle

Некоторые советы и методы использования инструкции GRANT в базах данных на платформе DB2

GRANT, предоставления разрешения на схему (Transact-SQL)

Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.

Аргументы

permission
Разрешение на работу со схемой, которое может быть предоставлено. Список разрешений см. в подразделе «Примечания» далее в этом разделе.

ON SCHEMA :: schema _name
Схема, на работу с которой предоставляется разрешение. Квалификатор области :: является обязательным.

database_principal
Участник, которому предоставляется разрешение. Это может быть:

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

GRANT OPTION
Показывает, что участнику будет дана возможность предоставлять указанное разрешение другим участникам.

AS granting_principal
Указывает участника, от которого участник, выполняющий данный запрос, наследует право на предоставление разрешения. Это может быть:

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

Remarks

Сочетание разрешений ALTER и REFERENCE в некоторых случаях может позволить просматривать данные или выполнять несанкционированные функции. Пример: Пользователь с разрешением ALTER на таблицу и разрешением REFERENCE на функцию может создавать вычисляемый столбец на основе функции и в результате — выполнять ее. В этом случае пользователю также требуется разрешение SELECT на вычисляемый столбец.

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

Разрешение схемы	Содержится в разрешении схемы	Содержится в разрешении базы данных
ALTER	CONTROL	ALTER ANY SCHEMA
CONTROL	CONTROL	CONTROL
CREATE SEQUENCE	ALTER	ALTER ANY SCHEMA
DELETE	CONTROL	DELETE
EXECUTE	CONTROL	EXECUTE
INSERT	CONTROL	INSERT
REFERENCES	CONTROL	REFERENCES
SELECT	CONTROL	SELECT
TAKE OWNERSHIP	CONTROL	CONTROL
UPDATE	CONTROL	UPDATE
VIEW CHANGE TRACKING	CONTROL	CONTROL
VIEW DEFINITION	CONTROL	VIEW DEFINITION

Пользователь с разрешением ALTER на схему может при помощи цепочки владения получить доступ к защищаемым сущностям других схем, включая такие сущности, к которым пользователю явно запрещен доступ. Это происходит потому, что цепочка владения обходит проверки разрешений на объекты, к которым выполняется обращение, когда они принадлежат участнику, владеющему объектами, которые на них ссылаются. Пользователь с разрешением ALTER на схему может создавать процедуры, синонимы и представления, принадлежащие владельцу схемы. Эти объекты получат доступ (через цепочку владения) к данным других схем, принадлежащих владельцу схемы. По возможности следует избегать предоставления разрешения ALTER на схему, если ее владельцу принадлежат также другие схемы.

Например, эта проблема может возникнуть в следующих сценариях. Предполагается, что у пользователя U1 есть разрешение ALTER на схему S1. Пользователю U1 запрещен доступ к объекту таблицы T1 в схеме S2. Схемы S1 и S2 принадлежат одному и тому же владельцу.

У пользователя U1 есть разрешения CREATE PROCEDURE на базу данных и EXECUTE на схему S1. Поэтому пользователь U1 может создать хранимую процедуру, а затем получить доступ к запрещенному объекту T1 из этой хранимой процедуры.

У пользователя U1 есть разрешения CREATE SYNONYM на базу данных и SELECT на схему S1. Поэтому пользователь U1 может создать в схеме S1 синоним для запрещенного объекта T1, а затем получить доступ к этому объекту с помощью синонима.

У пользователя U1 есть разрешения CREATE VIEW на базу данных и SELECT на схему S1. Поэтому пользователь U1 может создать в схеме S1 представления для запроса данных из запрещенного объекта T1, а затем получить доступ к этому объекту с помощью представления.

Разрешения

Объект, предоставляющий разрешение (или участник, указанный параметром AS), должен иметь либо само разрешение, выданное с помощью параметра GRANT OPTION, либо разрешение более высокого уровня, которое неявно включает предоставляемое.

Если используется параметр AS, налагаются следующие дополнительные требования.

AS granting_principal	Необходимо дополнительное разрешение
пользователь базы данных;	Разрешение IMPERSONATE для пользователя, членство в предопределенной роли базы данных db_securityadmin, членство в предопределенной роли базы данных db_owner или членство в предопределенной роли сервера sysadmin.
пользователь базы данных, сопоставленный с именем входа Windows;	Разрешение IMPERSONATE для пользователя, членство в предопределенной роли базы данных db_securityadmin, членство в предопределенной роли базы данных db_owner или членство в предопределенной роли сервера sysadmin.
пользователь базы данных, сопоставленный с группой Windows;	Членство в группе Windows, членство в предопределенной роли базы данных db_securityadmin, членство в предопределенной роли базы данных db_owner или членство в предопределенной роли сервера sysadmin.
пользователь базы данных, сопоставленный с сертификатом;	Членство в предопределенной роли базы данных db_securityadmin, членство в предопределенной роли базы данных db_owner или членство в предопределенной роли сервера sysadmin.
пользователь базы данных, сопоставленный с асимметричным ключом;	Членство в предопределенной роли базы данных db_securityadmin, членство в предопределенной роли базы данных db_owner или членство в предопределенной роли сервера sysadmin.
Пользователь базы данных, не сопоставленный ни с одним участником на уровне сервера	Разрешение IMPERSONATE для пользователя, членство в предопределенной роли базы данных db_securityadmin, членство в предопределенной роли базы данных db_owner или членство в предопределенной роли сервера sysadmin.
роль базы данных;	Разрешение ALTER на роль, членство в предопределенной роли базы данных db_securityadmin, предопределенной роли базы данных db_owner или предопределенной роли сервера sysadmin.
Роль приложения	Разрешение ALTER на роль, членство в предопределенной роли базы данных db_securityadmin, предопределенной роли базы данных db_owner или предопределенной роли сервера sysadmin.

Владельцы объектов могут предоставлять разрешения на объекты, которыми они владеют. Участники, имеющие разрешение CONTROL на защищаемый объект, могут предоставлять разрешение на этот защищаемый объект.

Участники, которым предоставлено разрешение CONTROL SERVER, такие как члены предопределенной роли сервера <legacyBold>sysadmin</legacyBold>, могут предоставлять любое разрешение на любой защищаемый объект сервера. Участники, получившие разрешение CONTROL на базу данных, такие как члены предопределенной роли базы данных db_owner, могут предоставлять любое разрешение на любой защищаемый объект в базе данных. Владельцы разрешения CONTROL, связанного со схемой, могут предоставлять любые разрешения на работу с любыми объектами, содержащимися в данной схеме.

Предоставьте все на определенной схеме в БД для групповой роли в PostgreSQL

используя PostgreSQL 9.0, у меня есть групповая роль под названием "персонал" и я хотел бы предоставить все (или некоторые) привилегии этой роли в таблицах в определенной схеме. Ни одна из следующих работ

члены " персонала "по-прежнему не могут выбрать или обновить отдельные таблицы в схеме" foo " или (в случае второй команды) в любую таблицу в базе данных если Я даю все на этой конкретной таблице.

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

обновление: понял это с помощью аналогичный вопрос serverfault.com.

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

(но обратите внимание, что ALL TABLES подразумевает вид и внешняя таблицы).

жирным выделено мной. serial столбцы реализуются с помощью nextval() на последовательности как столбец по умолчанию и,со ссылкой на руководство:

для последовательностей, эта привилегия позволяет использовать currval и nextval функции.

так что если есть serial столбцы, вы также хотите предоставить USAGE (или ALL PRIVILEGES ) on последовательности

Примечание: столбцы идентификаторов в Postgres 10 или более поздней версии используйте неявные последовательности, которые не требуют дополнительных привилегий. (Подумайте об обновлении serial столбцы.)

а как же новая объекты?

это устанавливает привилегии для объектов, созданных в будущем автоматически-но не для ранее существующих объектов.

привилегии по умолчанию:только применяется к объектам, созданным целевым пользователем ( FOR ROLE my_creating_role ). Если это предложение опущено, оно по умолчанию текущий пользователь выполняет ALTER DEFAULT PRIVILEGES . Чтобы быть явным:

обратите внимание также, что все версии pgAdmin III имеют тонкий баг и дисплей привилегии по умолчанию в области SQL, даже если они не применяются к текущей роли. Будьте уверены, чтобы отрегулировать FOR ROLE предложение вручную при копировании сценария SQL.

Консервативно

если вы хотите быть более консервативным, чем предоставление "всех привилегий", вы можете попробовать что-то вроде этого.

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

доступ к схемы

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

вы не заметите это требование при первом использовании Postgres. По умолчанию каждая база данных имеет первую схему с именем public . И каждому пользователю по умолчанию автоматически были предоставлены права "использования" для этой конкретной схемы. При добавлении дополнительной схемы необходимо явно разрешить использование права.

фрагмент Postgres doc:

для схем разрешает доступ к объектам, содержащимся в указанной схеме (при условии, что также выполняются собственные требования к привилегиям объектов). По существу, это позволяет получателю гранта "искать" объекты в схеме. Без этого разрешения все еще можно увидеть имена объектов, например, путем запроса системных таблиц. Кроме того, после отзыва этого разрешения существующие бэкэнды возможно, есть операторы, которые ранее выполняли этот поиск, поэтому это не полностью безопасный способ предотвращения доступа к объекту.

для более подробного обсуждения см. Вопрос,что грант использование на схеме точно делать?. Обратите особое внимание на ответ by Postgres expert Крейг Рингер.

Существующие Объекты Против Будущего

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

АУДИТ ПОЛЬЗОВАТЕЛЕЙ ORACLE БАЗЫ ДАННЫХ ШТАТНЫМИ СРЕДСТВАМИ

12.01.2021 | Иван Огурцов, г. Санкт-Петербург |

Добрый день! Сегодняшняя статья посвящена аудиту пользователей в БД. Все примеры работают на БД 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 представления, которые показывают наглядную картину по аудиту пользователей, а также доступы к критичным объектам БД. В дальнейшем можно настроить систему алертов, которая бы при наступлении определённого события оповещала заинтересованных сотрудников любым доступным в вашей организации способом, например:

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

2021 год

GRANT

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

Команда GRANT используется для назначения привилегий пользователям.

Синтаксис команды GRANT:

Синтаксис команды GRANT

system_priv — системная привилегия
role — роль: набор соответствующих полномочий, которые администратор может коллективно предоставлять пользователям и другим ролям.
user — пользователь
PUBLIC — привилегия передается всем пользователям
WITH ADMIN OPTION — если предоставлены системные полномочия или роли, то параметр позволяет пользователю передать полномочие или роль другим пользователям или ролям

Пример 1

Предположим, пользователь Р1 является владельцем таблицы Student и нужно передать пользователю Р2 право на формулирование запросов к этой таблице:

GRANT SELECT ON Student TO P2;

Пример 2

Для передачи прав на другие привилегии синтаксис тот же самый. Пользователь Р1, являющийся владельцем таблицы Student, может разрешить пользователю Р2 вводить строки в нее:

GRANT INSERT ON Student TO P2;

Пример 3

Передача привилегий не ограничивается передачей единственной привилегии единственному пользователю с помощью одной команды GRANT. Допустимы списки привилегий и/или пользователей с элементами, разделенными запятыми:

GRANT SELECT, INSERT ON Student TO P2;

GRANT SELECT, INSERT ON Student TO P2, Р3;

Пример 4

Можно разрешить пользователю изменять значения любого или всех столбцов таблицы:

GRANT UPDATE ON Student TO P2;

GRANT UPDATE (Fam,Ball) ON Student TO P2;

Пример 5

Если необходимо предоставить кому-то все полномочия на конкретный объект, используется ключевое слово ALL:

GRANT ALL ON Student ТО Р2;

Пример 6

Когда передаются привилегии с атрибутом PUBLIC, который относится к пользователям, а не к привилегиям, то все пользователи получают их автоматически. Чаще всего это применяется для привилегии SELECT для определенных таблиц или представлений, которые нужно предоставить каждому пользователю для рассмотрения. Разрешить каждому пользователю просматривать таблицу Student можно следующей командой:

GRANT SELECT ON Student TO PUBLIC;

Пример 7.

Иногда создатель таблицы хочет, чтобы другие пользователи имели право передавать привилегии на эту таблицу. Это можно сделать с помощью предложения WITH GRANT OPTION. Если пользователь Р1 желает, чтобы пользователь Р2 имел право передавать полномочия на работу с таблицей Student другим пользователям, то он должен передать пользователю Р2 привилегию на выполнение соответствующих команд:

GRANT SELECT, INSERT ON Student ТО Р2 WITH GRANT OPTION;

Как GRANT привилегий к ROLE на Oracle SCHEMA

Как я могу предоставить некоторые привилегии a ROLE на всех таблицах a SCHEMA?
Я написал этот код, но в SQLDeveloper он выдает ошибку.

Что не так в этом коде?

2 ответа

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

У меня есть пользователь admin, который имеет права администратора и по умолчанию oracle XE user hr. Пользователь admin создал таблицу CAR, роль S и предоставил этой роли SELECT на таблице CAR. Затем администратор предоставил роль S пользователю hr. Но когда hr пытается select * from admin.car .

CREATE SCHEMA -это один оператор для создания нескольких объектов, вам нужно удалить точки с запятой. Кроме того, CREATE SCHEMA поддерживает только таблицы, представления и гранты. Вам нужно будет удалить CREATE ROLE и CREATE USER из инструкции. Вот пример из руководства :

Чтобы предоставить SELECT для всех таблиц, вам понадобится динамический SQL, как это:

Используйте приведенный ниже код:-

СОЗДАНИЕ ТАБЛИЧНОГО ПРОСТРАНСТВА dwtblspc ПРОТОКОЛИРОВАНИЕ ФАЙЛА ДАННЫХ 'D:\oraclexe\app\oracle\oradata\XE\DWTBLSPC.DBF' SIZE 300M АВТОЭКСТЕНД НА СЛЕДУЮЩЕМ 1048K MAXSIZE UNLIMITED;

Надеюсь, это поможет.

Oracle гранты на схему

Репутация: нет
Всего: 1

Код

GRANT SELECT ON TABLE1 TO FUSER;
GRANT SELECT ON VIEW1 TO FUSER;

Код

GRANT SELECT ON SYSADM.DOC TO FUSER;

Код

GRANT SELECT ON ANY TABLE TO FUSER;

И, о чудо! FUSER, наконец-то получил доступ к VIEW1. В связи с этим два вопроса: что это за ошибка, т.е. каких прав и на что ему не хватало? И как быть, т.к. давать этому юзеру такие полномочия ну совсем не резон?

Репутация: нет
Всего: 1

Код

GRANT ALL PRIVILEGES TO FADMIN;

Репутация: 37
Всего: 161

Репутация: нет
Всего: 1

И еще, как это загнать в роль, если с ролью это не работает?

Репутация: 37
Всего: 161

Я не смог воспроизвести указанную вами ситуацию у себя. Дать грант на вью, выбирающую из таблицы другой схемы, с правами без грант опшин, мне оракл не дал 11.2.03

Объекты схемы (в вашем случае - вью) работают от прав владельца, не роли. Т.е. для того, чтобы создать вью надо дать пользователю(не роли) грант на табицу. Соответственно чтобы грант был передаваем, он должен отдаваться с грант опшн.

Репутация: нет
Всего: 1

Цитата

Странно, у меня жонглирование с правами проходило весьма филантропно. 11.2.0.1.0. Ладно, спишем на железную логику Oracle.

Цитата

Репутация: 37
Всего: 161

Я не понимаю что ставит вас в тупик.
Пользователям давайте через роль. А объектам схемы нужен прямой грант (если он не authid current user).

Ваши пользователи же не будут создавать объекты схемы - так? Прав, данных через роль им должно хватить.

Репутация: 37
Всего: 161

Подумав, кажется я начал догадываться

Есть понятие пользователь, есть понятие схема данных. В оракле эти понятия несколько смешаны виду того, что схема определяется пользователем - владельцем схемы. Для того, чтобы пользователь получил доступ к объекту схемы другого пользователя, ему достаточно привелегии, данной чрез роль. Если пользователь является владелецем схемы и его схема должна ссылаться на объекты чужой схемы, пользователю должны быть даны права на объект напрямую, т.к. объекты схемы работают от имени владельца схемы.

Репутация: нет
Всего: 1

Репутация: 37
Всего: 161

Еще раз повторяю, для пользователя - владельца, отдавайте прямой грант виз грант опшин.
Пользователям-пользователям, назначайте привелегию на вью через роль

Вероятно вы видите не логичным, т.к. отдаете гранты из под sysdba и у вас котлеты мешаются с мухами.
Если вы будете отдавать привелегии из под пользоватя SYSADM, вы не сможете отдать привелегию на вью пользователя MASTER1 пока он вам не даст привелегию ее читать. Вы можете отдать лишь привлегию на чтение своих таблиц.
Пользователь же MASTER1 может определить роль и наделить ее привелегиями, необходимыми для того, чтобы пользователи могли получить доступ к объектам его схемы. Если эти пользователи не будут создавать свои объекты схемы, этого будет достаточно.

Репутация: нет
Всего: 1

Цитата

Еще раз повторяю, для пользователя - владельца, отдавайте прямой грант виз грант опшин.

Репутация: 37
Всего: 161

У вас что - несчетное количество схем? Обычно это не так и проблемы, в общем, не составляет.

Репутация: нет
Всего: 1

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

Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Zloxa, LSD.

[ Время генерации скрипта: 0.1391 ] [ Использовано запросов: 21 ] [ GZIP включён ]

Oracle права на схему

К слову сказать, в чем мы далее и убедимся. Для того, чтобы запросы пользователей могли создавать временные сегменты в табличном пространстве TEMP, им не нужны квоты на дисковое пространство. Попробуем создать пользователя! Запускайте SQL*Plus с пользователем SYS или SYSTEM пароли администраторов смотрите в шаге 5! Из всего выше сказанного, запишем вот такую конструкцию:

Здесь мы создаем пользователя (схему) DUMMY с паролем DUMB и позволяем ему резвится на 100 Мб пространства USERS и еще немного выделяем из пространства TEMP. Получаем в результате:

Ок! Пользователь (схема) создан. Наверное, можно уже подключится и начать создавать объекты! Пробуем!

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

Даем пользователю право создавать сессию с сервером:

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

Дадим такой запрос к представлению DBA_USERS:

Вот теперь он может не только создавать эти объекты, но и изменять их! А, что если пользователю необходимо будет удалить какой-либо объект или удалить записи из таблиц? Тогда нужно добавить права на удаление объектов БД вот так:

Уфф! Ну вот теперь кажется все! Пользователь действительно полноценный и может работать! Помните в шаге 6 мы с вами это уже проделывали, но тогда я не вдавался в подробности, так как было не до того! А, вот теперь давайте разберемся более детально и продолжим далее.

По умолчанию аккаунт не имеет никаких прав в БД Oracle. Невозможно даже создать подключения без назначенных прав. И даже после получения прав на подключения, аккаунт не может сделать ничего полезного (или опасного) без получения соответсвующих прав. Права назначаются с помощью команды GRANT и убираются с помощью команды REVOKE. Дополнительные директивы команды используются для разрешения аккаунта делится правами которые у него есть с другими пользователями. По умолчанию только аккаунта администратора (SYS и SYSTEM) владеют правами назначения прав. Пользователь который назначает права другому пользователю называется grantor когда получатель прав – grantee. Права разбиты на две группы: системные права, которые грубо говоря позволяют пользователю совершать действия влияющие на словарь данных, и права над объектами, которые позволяют пользователю совершать действия влияющие на данные.

Системные права

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

CREATESESSION – права на подключения. Без этих прав вы даже не сможете подключиться к БД
RESTRICTEDSESSION – Если БД запущена с директивой STARTUPRESTRICT или применялась команда ALTERSYSTEMENABLERESTRICTEDSESSION, то только пользователи с этими правами смогут подключаться к БД
ALTERDATABASE – разрешает выполнять команды влияющие на физические структуры
ALTERSYSTEM – разрешает изменять параметры экземпляра и структуры памяти
CREATETABLESPACE – вместе с ALTERTABLESPACE и DROPTABLESPACE позволяют пользователю управлять табличными пространтсвами
CREATETABLE – позволяет gratee создавать таблицы в своей схеме; включает возможность создавать, изменять и удалять таблицы, выполнять команды DML и select и управлять индексами
GRANTANYOBJECTPRIVILEGE – позволяет grantee управлять правами объектов которые ему не принаджлежат, но не даёт прав ему самому
CREATEANYTABLE – grantee может создавать таблицы которые принадлежат другим аккаунтам
DROPANYTABLE – grantee позволяется удалять таблицы которые принадлежат другим аккаунтам
INSERTANYTABLE, UPDATEANYTABLE, DELETEANYTABLE – даёт grantee право выполнять DML команды над объектами которые ему не принадлежат
SELECTANYTABLE – Даёт право grantee выполнять SELECT к любмы таблицам.

Синтаксис для назначения прав

GRANT privilege [,privilege…] TO username;

После создания аккаунта, обычно назначаются права часто используемые пользователями кто вовлечён в разработку приложения

grant create session, alter session,

create table, create view, create synonym, create cluster,

create database link, create sequence,

create trigger, create type, create procedure, create operator

Эти права позволяют подключаться и настраивать сессию, создавать объекты и хранить PL/SQL объекты. Объекты могут быть созданы только в схеме аккаунта; нет прав к схемам других аккаунтов. Также создание объектов ограничивается лмимитами табличных пространств.

Другим вариантом назначения прав будет назначение grantee доступа для переназначения прав другим аккаунтам. Например

grant create table to scott with admin option;

grant create table to jon;

Выполнение этих команд позволит SCOTT создавать таблицы в совей схеме, и выполнять команду GRANT. SCOTT даёт права пользователю JON создавать таблицы – но JON сможет создавать таблицы только в схеме JON. На рисунке 6-5 показаны права пользователя в Database Control; ту же информацию можно получить выполнив запрос к представлению DBA_SYS_PRIVS.

Если системные разрешения были отозваны, все действия которые вы выполнили пока у вас были права остаются в силе. Если у вас были права с ADMIN OPTION то у всех пользователей которым вы назначили права – права остаются, несмотря на то что у вас права отозвали. Не остаётся записей кто именно назначил системные привилегии, таким образом невозможно забрать права CASCADE как показано на рисунке 6-6

Revocation of a system privilege will not cascade (unlike

revocation of an object privilege).

Права ANY дают доступ ко всем объектам в БД. Таким образом

grant select any table to scott

позволить аккаунту SCOTT выполнять запрос SELECT ко всем таблицам во всех схемах БД. Такое назначение прав считается дурным тоном и ANY права назначаются только DBA.

In fact, ANY is not as dangerous now as with earlier releases. It no longer

includes tables in the SYS schema, so the data dictionary is still protected. But

ANY should still be used with extreme caution, as it removes all protection

from user tables.

Объектные права

Объектные права дают доступ к выполнению команд DML и SELECT к соответствующим объектам и выполнению PL/SQL объектов. Эти права не существуют для объектов в схеме аккаунта; если у пользователя есть системные права CREATE TABLE – это значит что он может выполнять SELECT и DML запросы к таблицам которые он создал без дополнительных прав.

The ANY privileges, that grant permissions against objects in

every user account in the database, are not object privileges—they are

Объектные права применяются к разным группам объектов

GRANT privilege ON [schema.]object TO username [WITH GRANT OPTION];

grant select on store.customers to scott;

Можно использовать ALL чтобы применить права для всех операций, или использовать конкретное указание столбца таблицы или представления.

grant select on store.orders to scott;

grant update (order_status) on store.orders to scott;

grant all on store.regions to scott;

Эти команды позволят аккаунту SCOTT выполнять запрос SELECT ко всем столбцам таблицы ORDERS в схеме STORE но обновлять данные только в одном столбце. Также у аккаунта SCOTT есть доступ ко всем операциям к таблице REGIONS. На рисунке 6-7 отображается результат назначения прав при просмотре в Database Control

Granting privileges at the column level is often said to be bad practice

because of the massive workload involved. If it is necessary to restrict peoples’

access to certain columns, creating a view that shows only those columns will

often be a better alternative.

Использование директивы WITH GRANT OPTION позволит пользователю передавать свои права другим аккаунта. Оракл хранит информацию о том кто и кому дал доступ на объектном уровне; это позволяет отзывать права учитывая эту информацию. Рассмотрим пример

grant select on customers to sales with grant option;

grant select on store.customers to webapp with grant option;

grant select on store.customers to scott;

revoke select on customers from sales;

После выполнения этих команд, ни у пользователя SALES ни у пользователя WEBAPP ни у пользователя SCOTT нет прав на выполнение команд SELECT к таблице STORE.CUSTOMERS.

Revocation of an object privilege will cascade (unlike revocation of

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

Дополнительная информация по теме

GRANT, предоставления разрешения на схему (Transact-SQL)

Аргументы

Remarks

Разрешения

Предоставьте все на определенной схеме в БД для групповой роли в PostgreSQL

а как же новая объекты?

Консервативно

доступ к схемы

Существующие Объекты Против Будущего

АУДИТ ПОЛЬЗОВАТЕЛЕЙ ORACLE БАЗЫ ДАННЫХ ШТАТНЫМИ СРЕДСТВАМИ

GRANT

Как GRANT привилегий к ROLE на Oracle SCHEMA

2 ответа

Похожие вопросы:

Oracle гранты на схему

Oracle права на схему

Системные права

Объектные права

Системные полномочия:

Объектыные полномочия: