Архитектура разработки для базы данных Oracle

У нас есть несколько схем, предназначенных для модулей (финансы, запасы, crm и т. д.) в Oracle DB 11gR2. Мы хотим создать такую ​​архитектуру для разработчиков, чтобы:

  1. У разработчиков не будет паролей пользователей-владельцев схемы.
  2. Разработчики будут иметь ограниченный по времени доступ к объектам БД, в зависимости от их уровня, двумя способами:
    • Старшие разработчики высшего уровня будут иметь неограниченные привилегии в конкретной схеме, если они были авторизованы на ограниченный период.
    • Младшие разработчики будут иметь ограниченные привилегии в конкретной схеме, если они были авторизованы на ограниченный период.

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

Спасибо,

Редактировать: у меня есть интуиция, что дело не так ясно. Приведу простой сценарий:

Предположим, что у меня есть схема (пользователь с объектами) с именем «DUMMY», в которой есть таблица с именем «DummyTbl» и функция с именем «DummyFunc». Очевидно, что пользователь «DUMMY» может неограниченно управлять всеми этими объектами, поскольку он является их владельцем. Однако я не хочу, чтобы разработчики использовали общего пользователя «DUMMY», и я хочу, чтобы они входили в базу данных со своим собственным именем пользователя.

Потому что я не могу различать уровень привилегий разработчиков, когда я дал им пароль пользователя «МАКАНА». Все разработчики могут вести себя неограниченно. Напротив, я хочу, чтобы старший разработчик по имени «DummySenior» мог создавать, изменять, выполнять объекты, а также выполнять операции CRUD над «DummyTbl».

Но я хочу, чтобы младший разработчик по имени «DummyJunior» ссылался только на объекты, а не выполнял операции CRUD над таблицами. Самый очевидный способ добиться этого — аккомпанировать ролям. Однако у нас есть несколько проблем с настройкой необходимых ролей (например, если «DummySenior» может создать таблицу в схеме «DUMMY», у него должна быть привилегия «создать любую таблицу».

Однако, когда «DummySenior» имеет эту привилегию, он также может создавать таблицы по схеме «DUMMY2». Это явное нарушение безопасности.)


architecture development-environment schema oracle oracle11gr2
person dante deo    schedule 30.03.2015    source источник
comment
Возможно, это поможет: docs.oracle.com/ cd/B28359_01/сервер.111/b28286/   -  person Dmitriy    schedule 30.03.2015
comment
Вы разрабатываете на серверах, а не на рабочих станциях? Используете ли вы контроль версий? Я пытаюсь понять, почему вы не хотите предоставлять разработчикам полный доступ ко всем объектам.   -  person Jon Heller    schedule 30.03.2015
comment
@dmitry Это не то, что я ищу. Я добавил простой сценарий в вопрос.   -  person dante deo    schedule 31.03.2015
comment
@jon-heller Ответ прост: безопасность.   -  person dante deo    schedule 31.03.2015
comment
@dantedeo Безопасность объектов базы данных можно обеспечить с помощью системы контроля версий. Это более полезно.   -  person Dmitriy    schedule 31.03.2015
comment
@dantedeo Я до сих пор не понимаю, что здесь происходит. Вы пытаетесь спроектировать способ разработки для разработчиков или вы пытаетесь спроектировать ограничения безопасности для разработчиков, устраняющих неполадки в производственной среде?   -  person Jon Heller    schedule 31.03.2015
comment
@ jon-heller На мой взгляд, это одно и то же, не так ли?   -  person dante deo    schedule 31.03.2015
comment
@Dmitry Дмитрий, я не могу сопоставить VCS с моими требованиями. Не могли бы вы объяснить?   -  person dante deo    schedule 31.03.2015
comment
@dantedeo Извините, может быть, я не понял вашего вопроса. База данных приложения состоит из двух частей: пользовательских данных и объектов базы данных (DDL таблиц, процедур, представлений, триггеров и т. д.). Для защиты пользовательских данных от повреждений нужно не допускать разработчиков к рабочему серверу. Создайте экземпляр разработчика и заполните его копией данных или сгенерируйте рандом. Для защиты исходного кода объектов базы данных используйте VCS. Потому что, например, если вы выполните create or replace procedure, будет сложно восстановить предыдущее состояние. VCS поможет вам предотвратить это.   -  person Dmitriy    schedule 31.03.2015
comment
@Dmitry Да, вы не должны понимать мой вопрос. Я полностью согласен с вашей настройкой среды разработки. Однако все приведенные выше сценарии относятся к производственной БД.   -  person dante deo    schedule 31.03.2015
comment
@dantedeo Возможно, здесь не хватает концепции инженера по развертыванию или администратора баз данных, который занимается развертыванием. Обычно (по моему опыту) разработчики работают со 100% доступом к более низким средам, а затем упаковывают и передают развертывание людям с полным доступом к более высоким средам. Это дополнительная работа, но в ней есть разделение обязанностей, которое ищут аудиторы.   -  person Jon Heller    schedule 31.03.2015
comment
@JonHeller Структура, которую я хочу установить, точно такая же, за небольшим исключением. В моем случае старший разработчик верхнего уровня носит шапку инженера по развертыванию с некоторыми ограничениями, описанными выше (т. е. у него не будет пароля схемы).   -  person dante deo    schedule 01.04.2015
comment
вы должны купить 2-й сервер разработки. в любом случае разработчики могут убить производственный сервер одним специальным запросом на отчет.   -  person ibre5041    schedule 01.04.2015

Ответы (1)


arrow_upward
1
arrow_downward

Для старшего разработчика вы можете создать процедуру определения прав, которая просто запускает любую переданную команду. Если предположить, что DUMMY имеет соответствующие привилегии CREATE TABLE/VIEW/..., это фактически дает старшим разработчикам все SELECT ANY привилегии, но только для этой одной схемы.

create or replace procedure dummy.execute_any(p_code in clob) authid definer is
begin
    execute immediate p_code;
end;
/

--For a procedure this powerful, grant it directly to a user.
--That keeps the privilege "obvious", it won't get buried in layers of roles.
grant execute on dummy to senior_developer;

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

--Create and populate role with some lesser object privileges on a schema.
create role junior_developer_role;

begin
    --Repeat this structure for other objects, like sequences.
    for tables in
    (
        select owner, table_name
        from dba_tables
        where owner = 'DUMMY'
    ) loop
        execute immediate 'grant select on '||tables.owner||'.'||tables.table_name||
            ' to junior_developer_role';
    end loop;
end;
/
person Jon Heller    schedule 02.04.2015
comment
Идея создания такой процедуры — умная идея. Однако это требует использования операторов dynamic SQL, а управление dynamic SQL сопряжено со значительными операционными трудностями. - person dante deo; 03.04.2015
comment
Нет, я думаю, ты застрял здесь из-за своей странной политики безопасности. Похоже, вы выбрали очень трудную золотую середину. Везде, где я работал, организация либо имела меньше безопасности (предоставляла доступ всем администраторам баз данных), либо больше (предоставляла права администратора баз данных только небольшому числу администраторов баз данных и давала разработчикам ограниченный доступ или вообще не предоставляла доступа к рабочей среде и другим средам более высокого уровня). Я не вижу простого технического решения этой проблемы. - person Jon Heller; 15.04.2015