предоставление прав SELECT для таблиц, при этом пользователю не нужно указывать владельца при выборе - PullRequest
1 голос
/ 27 апреля 2019

У меня есть несколько таблиц, скажем, Metrics и Results, некоторые из которых содержатся в огромной базе данных, содержащей много конфиденциальной информации. Я установил безопасность, позволяющую определенному приложению просматривать данные в этих таблицах. Мне не нужно изменять их. Всего задействовано около 200-300 таблиц, которые несут информацию, которая является НЕ конфиденциальной.

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

select * from Metrics.

К сожалению, подключение в качестве владельца базы данных также означает, что мой подключенный пользователь может видеть все таблицы, а не только Metrics и также может обновлять Metrics.

Я хотел бы создать нового пользователя, lowprivilege и иметь dba GRANT SELECT METRICS TO lowprivilege.

К сожалению, это означает, что мне нужно квалифицировать владельца таблицы при подключении как lowprivilege:

select * from dbo.Metrics.

Как dba в Oracle может предоставить SELECT для таблицы, если получатель гранта не должен квалифицироваться как владелец таблицы? И пользователь с низкими привилегиями не должен иметь никаких привилегий, кроме выбранных в выбранных таблицах.

вариант 1 - вид:

create view lowprivilege.Metrics as select * from dbo.Metrics

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

вариант 2 - создать синоним:

create or replace lowprivilege.Metrics FOR dbo.Metrics

Может ли dba выполнить это и предоставить SELECT только с помощью этого? Предположим, по крайней мере, версия Oracle 12.

вариант 3 - GRANT SELECT и схема переключения:

GRANT SELECT METRICS TO lowprivilege

но всякий раз, когда lowprivilege подключается, он использует alter session set current_schema=dbo. Обратите внимание, что это должно быть возможно в SQLAlchemy /cx-Oracle.

Кроме того, было бы здорово, если бы dba мог закрыть все, просто DROP USER lowprivilege CASCADE.

Каковы наилучшие способы достижения этого?

Ответы [ 2 ]

3 голосов
/ 27 апреля 2019

Альтернатива № 2 - создать синоним.Это как раз то, для чего нужны синонимы.

grant read on dbo.Metrics to lowprivilege;
create or replace synonym lowprivilege.Metrics FOR dbo.Metrics;

Обратите внимание на использование GRANT READ вместо GRANT SELECT.Пользователь с привилегией SELECT все еще может заблокировать таблицу.READ привилегия предотвращает это.

1 голос
/ 28 апреля 2019

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

alter session set current_schema = HR;

Теперь анализатор SQL сначала проверит схему HR на наличие неквалифицированных имен объектов.

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

grant read on metrics to readonly;

grant readonly to some_app_account;
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...