Безпека для розробників додатків, які виконують PL / SQL роботу в Oracle

Як ви вирішуєте відсутність привілеїв рівня схеми в Oracle? Архітектура безпеки Oracle добре працює для програм, які потребують лише привілеїв рівня об'єкта, і вона добре працює для DBA, які потребують обмежень. Однак, мабуть, в архітектурі є великий проріз для програмістів, які займаються розробкою за допомогою додатка на передньому кінці та PL / SQL в декількох схемах. Ось кілька моїх варіантів із їхніми недоліками:

1. Змусити кожного програміста робити розробку за власною схемою. DBA надаватиме привілеї для об'єктного рівня програмістам, які їх потребують. Будь-яка розробка пакету повинна здійснюватися DBA. Основним недоліком є ​​те, що програмісти будуть використовувати базу даних як бітове відшкодування на шкоду продуктивності бази даних. Я хочу, щоб програмісти розвивалися в базі даних, але цей метод сильно відлякує це.

2. Дайте кожному програмісту ім'я користувача / пароль для схеми десятка або близько того, для чого вони повинні розвиватися. Надайте цій схемі програми дозвіл на створення процедур, таблиць тощо. Деякі недоліки цього підходу полягають у тому, що програмістам доводиться підтримувати декілька входів і є рідко входили в систему як самі. Розробка схресної схеми також складна.

3. Надайте програмістам привілеї аутентифікації проксі для кожної схеми, для якої потрібно зробити розробку. Це дозволяє їм увійти в систему як самі, не надаючи їм інших привілеїв, крім привілеїв проксі. До недоліків можна віднести програмістів, які мають підтримувати окремі з'єднання для кожної схеми, для якої він є проксі-сервером, розробка крос-схеми є більш громіздкою, оскільки з'єднання потрібно постійно змінювати, а пакети, що використовують посилання загальнодоступної бази даних з пройденою автентифікацією, не збиратимуться всередині проксі-з'єднань.

4. Надайте кожному програмісту пільги DBA. - Мінусом тут є безпека. Жоден програміст схеми не може бути захищений від будь-якої схеми, і будь-який програміст може представити себе за будь-якого іншого програміста (DBA).

Здається, відсутній варіант надання кожному програмісту SELECT / INSERT / CREATE / тощо. привілеї схеми, в якій вони потребують розробки. Вони увійшли, як самі, щоб виконувати свою роботу, використовуючи одне з'єднання. Нові об’єкти в схемі, до якої вони мають доступ, негайно доступні.

Я щось пропускаю? Як ви поводитесь із прикладними програмістами, які займаються розробкою PL / SQL?

Ще в ті часи, коли я працював в магазині Oracle, у нас був специфічний сервер "dev" (розробка), який мав різні обмеження безпеки, ніж сервер "prod" (виробництво). Розробники могли робити все необхідне, і тоді ми передамо DBA необхідні сценарії, щоб застосувати їх до виробничого сервера.

У випадку з нашими критичними системами (SCT Banner, для відстеження класів та студентів та Oracle Financials) також існували "тестові" та "насінні" сервери. Тест був для тестування прийняття користувачем, перш ніж матеріали мігрували з розробника на продукт "seed" була інсталяцією програмного забезпечення на складі, тому, якщо ми знайдемо помилку, ми могли б перевірити, чи це щось, що ми ввели або прийшли від програмного забезпечення SCT або Oracle.

Використовуйте ролі для асоціації колекцій об'єктів, а потім надайте доступ до ролей

Заява GRANT дозволяє DBA:

Об'єктні привілеї для певного об'єкта для користувачів, ролей та PUBLIC. У таблиці 18-2 перераховані привілеї об'єкта та операції, які вони авторизують.

Оскільки привілеї об’єктів можуть бути надані ролі, надати роль доступу до всіх таблиць на схемі порівняно просто:

sql> золотник privs.sql
sql> select 'grant select on scott.' || table_name || ' to role_select; ' з dba_tables, де owner = 'SCOTT';
sql> @ privs.sql
sql> надайте role_select Джону, Саму, Пітеру;

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

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

Редагувати -

За даними GRANT , CREATE TABLEпільга:

Створіть таблицю в схемі отримувача.

Таким чином, даючи їм створити таблицю, змінити таблицю тощо .. від правильного користувача, вони повинні мати доступ до схеми цього користувача, як якщо б він був відповідним користувачем.