Řešení 1:
-
Kdo instaluje Oracle na servery?
Pokud je to DBA, potřebují přístup root. Pokud je to sysadmin, DBA ne. -
Komu se volá pozdě v noci, když je databázový server mimo provoz?
Pokud nemůžete zajistit dostupnost systémových administrátorů 24 hodin denně, 7 dní v týdnu, možná budete chtít udělit rootovi přístup k DBA.
Mějte na paměti, že pokud váš DBA již má přístup k shellu jako běžný uživatel (s některými příkazy nebo bez nich může spouštět pomocí sudo; s chrootováním nebo bez něj), stačí to na to, aby se se serverem zapletl (zloduch, který mu ukradne účet, může způsobit bombu , překročit ulimit odesílání spamu, zahodit databázi, ...).
Ze všech těchto důvodů si myslím, že v ideálním světě by DBA neměli mít přístup root; ale ve skutečném světě by je měli mít alespoň vždy schopni získat v případě nouze.
Řešení 2:
Obecně – a ne konkrétně pro správce databází – kdokoli, kdo požaduje root přístup bez udání platného důvodu je buď:
- Někdo, kdo neví, co dělá.
- Arogantní a nespolupracující.
- Obě výše uvedené.
Nyní mohou existovat skutečné důvody, proč potřebují root přístup ke zvládnutí jejich úkolu, ale pokud opět nedokážou vysvětlit proč a napsat to písemně, nejednal bych s nimi. Profesionálové, kteří se zabývají servery, chápou a respektují hranice. Žhaví střelci, kteří vědí dost na to, aby se dostali do problémů, věří, že pravidla platí pro všechny kromě nich.
V případech, kdy jsem se musel potýkat s lidmi, jako je tento, jsem trval na tom, aby byl čas naplánován předem, abych s nimi mohl být na serveru a řešit problémy, jakmile nastanou. A to vlastně fungovalo dobře.
Další alternativou – která nemusí být praktická – je vytvořit přesný klon příslušného serveru a dát mu root přístup k tomu. Nezapomeňte změnit heslo na něco specifického pro ně. Nechte je vyhodit do vzduchu izolovanou vývojovou krabici.
Obecně ale platí, že pokud jste to vy, komu zavolají pozdě v noci uklidit nepořádek, který by ten chlap mohl vytvořit, pak máte plné právo odmítnout paušální žádost o root přístup.
Řešení 3:
Teoreticky mohou DBA pracovat bez root priv, ale je to PITA pro obě strany. Je prakticky nemožné definovat seznam příkazů, které mají být přístupné přes sudo .
Dejte správcům databází root priv, pokud:
- nechcete být probuzeni uprostřed noci, jen abyste restartovali server
- chcete rychlou a hladkou správu incidentů
- pokud je váš server vyhrazen pouze pro DB server
DBA obvykle potřebují priv root pro:úpravy parametrů jádra (sysctl), manipulaci s úložištěm, vyšetřování problémů.
Správný auditing zajišťuje lepší podmínky běhu než přísně definovaná bezpečnostní pravidla. Pokud máte auditování implementováno, můžete se vždy zeptat, proč něco udělali/změnili. Pokud nemáte auditování, stejně nemáte zabezpečení.
UPRAVENO
Toto je seznam běžných požadavků Oracle na samostatné (neklastrované instalace)
-
Parametry jádra
- Související s pamětí (konfigurace velkých/velkých stránek, sdílená RAM (ipcs), nevyměnitelná (uzamčená) RAM)
- související se sítěmi (velikost okna pro odesílání/příjem, TCP keepalive)
- související s úložištěm (počet otevřených souborů, asynchronní IO)
Může existovat asi 15-20 parametrů sysctl. Pro každý z nich Oracle poskytuje doporučenou hodnotu nebo rovnici. U některých parametrů se může doporučená rovnice v průběhu času měnit (aync io) nebo v některých případech Oracle poskytl více než jednu rovnici pro stejný parametr.
- Storage:Pravidla udev pro Linux nezaručují trvalé názvy zařízení při spouštění. Proto Oracle poskytl ovladač jádra a nástroje (AsmLib). To vám umožní "označit" fyzické oddíly jako root a pak tyto štítky uvidíte při správě databázového úložiště
- Vyšetřování problému:
- Když databáze havaruje, protože nemůže otevřít více popisovačů souborů, jediným řešením je zvýšit limit jádra, spustit 'sysctl -p' a poté spustit DB.
- Také když zjistíte, že fyzická RAM je příliš fragmentovaná a databáze nemůže alokovat velké stránky, pak jedinou možností je restartovat server.
- (DCD) – detekce mrtvého připojení. Například na AIX netstat netiskne PID. Jediný způsob, jak spárovat TCP spojení s PID, je kernel debugger.
- glance (něco jako top na HP-UX) vyžaduje práva root
- různá šetření na úrovni Veritas
- a mnoho dalších
Je na vás, abyste se rozhodli, kolik času „ztratíte“, než se problém vyřeší. Jen jsem chtěl poukázat na to, že silné oddělení rolí může být v některých případech velmi drahé. Takže místo zvyšování „bezpečnosti“ se zaměřte na snižování rizik a nebezpečí. Což není totéž. Nástroje jako ttysnoop nebo shell spy vám umožňují "nahrát" celou ssh relaci, takže poskytují nepopiratelnost. To může sloužit lépe než sudo.