Чи потрібен мій Oracle DBA доступ до кореня?

Мій колега Oracle DBA вимагає кореневого доступу на наших виробничих серверах .
Він стверджує, що йому це потрібно для виконання деяких операцій, таких як перезавантаження сервера та деякі інші завдання.

Я не згоден з ним, тому що я встановив йому користувача / групу Oracle та групу dba, де належить користувач Oracle. Все працює безперебійно і без того, щоб DBA в даний час мав кореневий доступ.
Я також думаю, що всі адміністративні завдання, такі як планове перезавантаження сервера, повинен виконувати належний адміністратор (системний адміністратор у нашому випадку), щоб уникнути будь-яких питань, пов’язаних із нерозумінням взаємодії інфраструктури.

Я хотів би отримати інформацію як від sysadmins, так і від Oracle DBA. Чи є якісь вагомі причини для Oracle DBA отримати кореневий доступ у виробничих умовах ?

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

Я не шукаю плюсів та мінусів, а радше щодо того, як мені вжити для вирішення цієї ситуації.

• Хто встановлює Oracle на сервери?
  Якщо це DBA, їм потрібен кореневий доступ. Якщо це sysadmin, DBA не робить.

• Кого викликають пізно вночі, коли сервер бази даних не працює?
  Якщо ви не можете забезпечити доступність системних адміністраторів цілодобово, ви можете надати кореневий доступ до DBA.

Майте на увазі, що якщо у вашої DBA вже є доступ до оболонки як звичайний користувач (з деякими командами або без них, він може працювати через sudo; з або без хроніки), цього достатньо, щоб возитися з сервером (поганий хлопець, що вкрав його рахунок, може розщедрити , перевищити необмежене надсилання спаму, скинути базу даних, ...).

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

Загалом - і не характерно для DBA - кожен, хто вимагає rootдоступу без поважної причини:

1. Хтось не знає, що вони роблять.
2. Нахабні та не співпрацюють.
3. Обидва вищезазначені.

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

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

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

Але взагалі, якщо ви є тим, кого зателефонують пізно вночі, щоб прибрати хаос, який може створити цей хлопець, то ви маєте всі права сказати "ні" запиту на ковдру root.

Теоретично DBA можуть працювати без кореневих приватних даних, але це PITA для обох сторін. Визначити список команд, через які можна отримати доступ, практично неможливо sudo.

Надайте кореневі приватні приватні особи DBA, якщо:

• ви не хочете, щоб вас прокидали посеред ночі, просто перезавантажити сервер
• Ви хочете швидкого та плавного управління інцидентами
• якщо ваш сервер призначений лише для сервера БД

DBA зазвичай потребують кореневих приватних файлів для: коригування параметрів ядра (sysctl), маніпуляції з зберіганням, дослідження проблем.

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

ВИДАЛЕНО

Це перелік загальних вимог Oracle для автономних (некластеризованих установок)

• Параметри ядра

  • Зв'язок із пам'яттю (конфігурація великих / величезних сторінок, спільна оперативна пам'ять (ipcs), незамінна (заблокована) оперативна пам’ять)
  • пов'язані з мережами (розмір вікна надсилання / отримання, збереження TCP)
  • сховище (кількість відкритих файлів, асинхронізація вводу-виводу)

  Може бути близько 15-20 параметрів sysctl. Для кожного з них Oracle надає рекомендоване значення або рівняння. Для деяких параметрів рекомендоване рівняння може змінюватися з часом (aync io) або в деяких випадках Oracle надало більше одного рівняння для одного і того ж параметра.

• Зберігання: Linux udev правила не гарантують завантаження стійких імен пристроїв. Тому Oracle надав драйвер ядра та інструменти (AsmLib). Це дозволяє вам "позначати" фізичні розділи як корінь, а потім ви можете бачити ці мітки під час адміністрування сховища бази даних
• Дослідження проблеми:
  • Коли база даних виходить з ладу, оскільки вона не може відкрити більше файлів, тоді єдине рішення - збільшити ліміт ядра, виконати 'sysctl -p', а потім запустити БД.
  • Крім того, коли ви виявите, що фізична ОЗУ занадто фрагментована і база даних не може виділяти великі сторінки, єдиний варіант - перезавантажити сервер.
  • (DCD) - виявлення мертвих з'єднань. Наприклад, на AIX netstat не друкується PID. Єдиний спосіб з'єднання TCP-з'єднання з PID - це налагодження ядра.
  • погляд (щось на зразок верху на HP-UX) вимагає кореневих приватних даних
  • різні дослідження рівня Veritas
  • та багато інших

Ви самі вирішуєте, скільки часу ви будете "витрачати" до вирішення питання. Я просто хотів зазначити, що сильне розмежування ролей може бути дуже дорогим - це деякі випадки. Тож замість збільшення «безпеки» зосереджуйтесь на зниженні ризику та небезпеки. Що не те саме. Такі інструменти, як ttysnoop або shell-шпигун, дозволяють "записати" весь сеанс ssh, таким чином вони гарантують безперечність. Це може служити краще, ніж судо.

Я DBA Oracle, і моя відповідь така: як правило, DBA не потребує кореневого доступу. Але RAC DBA? безумовно, йому потрібен кореневий доступ для управління CRS, веденням будинків і всім іншим.

Це питання випливає з часів, коли системи були набагато простішими, а операційні системи порівняно з базою даних були окремо визначені та ідентифіковані. Обов'язки та обов'язки адміністрування системи та бази даних були дуже чіткими. У сучасних ІТ-середовищах, зокрема, із сьогоднішніми серверами баз даних, ці обов'язки і обов'язки, частіше за все, часто перетинаються. Системний адміністратор проводить належну ретельність, щоб обмежити доступ до "root" щодо "управління ризиками".

На сьогоднішній день вимоги до «високої доступності» та «негайного усунення» проблем, що виникають із нашими системами баз даних RAC, системні адміністратори та адміністратори баз даних обслуговують їх функціональні бізнес-спільноти, працюючи разом як команда. Не повинно виникнути жодних занепокоєнь щодо "довіри", оскільки обидві сторони зацікавлені у підтримці серверів баз даних RAC в режимі он-лайн майже 100% часу. Майте на увазі, що DBA вже має доступ до оболонки як адміністратор бази даних (з або без деяких команд, які він може запускати через sudo; з чи без вказівки), тому очевидно, що DBA є "довіреним" агентом. Отже, насправді питання повинно бути таким: "Чому Oracle DBA не потребує доступу?"

Сьогоднішня DBA взяла на себе додаткову відповідальність за сервер баз даних, де Сервер баз даних є членом кластера додатків Oracle Real Application (RAC) і використовує Oracle Automatic Storage Management (ASMLIB) для представлення спільного сховища в базі даних RAC. Управління RAC та ASM з боку DBA позбавляє і без того перевантаженого системного адміністратора.

І, як зазначає ibre5043, "... сильне розмежування ролей може бути дуже дорогим - це деякі випадки. Тож замість збільшення" безпеки "фокус на зниженні ризику та небезпек. Що не те саме. Інструменти, такі як ttysnoop або shell-шпигун, дозволяють вам "записати" весь сеанс ssh, таким чином вони надають незаперечність. Це може служити краще, ніж sudo ". Також слід запитати, хто здійснює моніторинг SSA.

Якщо сервери використовують програмне забезпечення інфраструктури Oracle Grid Infrastructure, такі як CRS, RAC або Oracle Restart, багато хто з важливих служб бази даних працює як root, а багато файлів конфігурації критичних баз даних належать root. Це невід'ємна особливість дизайну програмного забезпечення. Якщо це порушення вашої політики, то політику потрібно переглянути.

Для управління ціми функціями DBA буде потрібен кореневий доступ. Теоретично ви можете запитати у нього список команд, які він буде розраховувати на введення в Судо, але відповідь буде дуже довгим списком. Просто подивіться у $ GRID_HOME / bin для списку всіх бінарних файлів, які DBA може використовувати регулярно. Якщо вони виконують виправлення дій (якими вони повинні бути), то список може бути ще довшим.

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

Але якщо це є причиною, DBA має бути також єдиним і єдиним sysadmin. А причина проста. Якщо є необхідність у розділенні підзвітності та відповідальності, систематик може ВИНАГОДНІ бути і БДА. Він може видати себе за обліковий запис oracle, він може входити в базу даних як SYSDBA і робити все, що завгодно, не потребуючи пароля SYS або SYSTEM.

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

Якщо сервер використовується більше, ніж хостинг бази даних, і є ця потреба в окремій відповідальності та підзвітності, це означає неприємності. Але якщо сервер використовується лише для розміщення бази даних, то я не бачу причин, через які DBA не повинен мати привілей на root, враховуючи безліч випадків, які йому також знадобляться.

Особисто я поставив би питання навпаки. Чому sysadmin має привілей на root на виділеному сервері баз даних? Насправді, його спеціальність потребуватиметься в набагато менших випадках, ніж спеціальна група DBA (з кореневою привілеєю).

Кореневий доступ необхідний для встановлення та виправлення сітки Oracle. Не обійтися. Якби існував спосіб надати тимчасовий кореневий доступ до DBA для таких потреб, це було б ідеально.