Безопасность для разработчиков приложений, выполняющих PL / SQL в Oracle


13

Как вы справляетесь с отсутствием привилегий уровня схемы в Oracle? Архитектура безопасности Oracle хорошо работает для приложений, которым требуются только привилегии уровня объекта, и хорошо работает для администраторов баз данных, которым нужно мало ограничений. Однако в архитектуре, похоже, есть большая дыра для программистов, занимающихся разработкой с использованием интерфейсного приложения и PL / SQL в нескольких схемах. Вот некоторые из моих вариантов с их недостатками:

  1. Заставьте каждого программиста делать разработку в своей собственной схеме. Администратор баз данных предоставит привилегии уровня объекта программистам, которые в них нуждаются. Любая разработка пакета должна выполняться администратором базы данных. Основным недостатком является то, что программисты будут использовать базу данных как небольшой сегмент в ущерб производительности базы данных. Я хочу, чтобы программисты развивались в базе данных, но этот метод сильно обескуражил бы это.

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

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

  4. Дайте каждому программисту привилегии администратора БД. - Недостатком здесь является безопасность. Ни один программист не может быть исключен из любой схемы, и любой программист может выдать себя за любого другого программиста (DBA).

Кажется, отсутствует опция для предоставления каждому программисту SELECT / INSERT / CREATE / etc. привилегии для схемы, в которой они нуждаются для разработки. Они входят в систему сами, чтобы выполнить свою работу, используя одно соединение. Новые объекты в схеме, к которым они имеют доступ, сразу же становятся доступны.

Я что-то пропустил? Как вы относитесь к программистам приложений, которые занимаются разработкой PL / SQL?


3
+1 отличный вопрос - это, в сочетании с отсутствием интегрированного контроля исходного кода, является серьезной проблемой для Oracle в многопользовательской среде.
СкоттЧер

Ответы:


11

В те времена, когда я работал в магазине Oracle, у нас был специальный сервер 'dev' (разработка), который имел другие ограничения безопасности, чем сервер 'prod' (производство). Разработчики могли делать все, что им нужно, а затем мы передавали необходимые сценарии администратору базы данных для применения к производственному серверу.

В случае с нашими критически важными системами (SCT Banner, для отслеживания классов и студентов, а также Oracle Financials) были также «тестовые» и «начальные» серверы. Тест был для пользовательского приемочного тестирования, прежде чем материал мигрировал из dev в prod; «seed» - это стандартная установка программного обеспечения, поэтому, если мы найдем ошибку, мы сможем проверить, было ли это то, что мы ввели или пришли от SCT или программного обеспечения Oracle.


+1 С нашей базой данных общего пользования разработчики работают над самыми разными проектами, поэтому принцип наименьших привилегий не даст им полного доступа даже к серверу разработки. ( en.wikipedia.org/wiki/Principle_of_least_privilege )
Ли Риффель

@Leigh - я, наверное, должен был уточнить ... по большей части dev-сервер попал под то, что у вас было # 1, а не # 4
Joe

1
Я помню, как клонировали базы данных DEV из Production, а затем сложные гранты, позволяющие разработчикам работать без ограничений. В конце концов, каждому разработчику было проще предоставить собственную базу данных и доступ к БД. Затем будет передавать изменения в Dev с помощью цикла выпуска. Теперь должно быть проще с виртуализацией.
Sumnibot

@Sumnibot - проще установить поддержку, создать резервную копию и т. Д. Отдельную базу данных для каждого разработчика, чем предоставлять им разрешения!?! В дополнение к времени, необходимому для обновления каждого из них, может показаться, что затраты на лицензирование будут значительными, или вы не предоставили им корпоративную версию?
Ли Риффель

1
Не содержит конкретного ответа для меня.
Michael-O

3

Используйте роли, чтобы связать коллекции объектов, а затем предоставить доступ к ролям

Оператор GRANT позволяет администратору базы данных:

Объектные привилегии для конкретного объекта для пользователей, ролей и PUBLIC. В таблице 18-2 перечислены привилегии объектов и операции, которые они авторизуют.

Поскольку объектные привилегии могут быть предоставлены роли, относительно легко предоставить доступ к роли всем таблицам в схеме:

sql> spool privs.sql
sql> select 'grant select on scott.' || имя_таблицы || ' to role_select; ' из dba_tables, где owner = 'SCOTT';
SQL> @ privs.sql
sql> Предоставить роль ролью Джон, Сэм, Питер;

Это в сочетании с GRANT CREATE TABLEвыдачей соответствующей схеме-пользователю роли означает, что разработчики могут выбирать и создавать таблицы. Он не идеален, поскольку созданная таблица требует повторного запуска сценария, но WITH GRANT OPTIONпредполагает, что каждый разработчик может затем предоставить доступ к созданной таблице соответствующей роли.

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

Редактировать --

Согласно ГРАНТУ , CREATE TABLEпривилегия:

Создайте таблицу в схеме грантополучателя.

Таким образом, предоставляя им создание таблицы, изменение таблицы и т. Д. От правильного пользователя, они должны иметь возможность доступа к схеме этого пользователя, как если бы они были подходящим пользователем.


Я видел методологию, на которую вы ссылались, без особого успеха; Тем не менее, я считаю, что вы правы, что это можно сделать с помощью всестороннего тестирования. Проблема в том, что это позволяет разработчикам выбирать доступ только для таблиц. Предоставление создания таблицы напрямую или через роль дает им только права на создание таблицы в их собственной схеме. Они по-прежнему не могут создавать таблицы, процедуры, пакеты, триггеры или любые другие объекты в любой схеме, кроме своей собственной, или вы считаете, что они должны создавать объекты только в своей собственной схеме даже в процессе разработки?
Ли Риффель

@Leigh Обновлено с подробностями.
Брайан Баллсун-Стэнтон

Это просто не то, как работает Oracle. Попробуйте это: создать пользователя u1, идентифицированного как «ThisIsMy1Password»; создать пользователя u2, идентифицированного как «ThisIsMy1Password»; предоставить dba для u1; Грант подключиться к u2; connect u1 / "ThisIsMy1Password" @db; предоставить создать таблицу для u2; connect u2 / "ThisIsMy1Password" @db; создать таблицу u1.t1 (c1 varchar2 (10)); Последний шаг терпит неудачу с недостаточными привилегиями.
Ли Риффель
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.