У меня есть несколько таблиц, скажем, 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
.
Каковы наилучшие способы достижения этого?