Il mio DBA Oracle ha bisogno dell'accesso root?

Il mio collega Oracle DBA richiede l'accesso come root sui nostri server di produzione .
Sta sostenendo che ne ha bisogno per eseguire alcune operazioni come il riavvio del server e alcune altre attività.

Non sono d'accordo con lui perché gli ho impostato un utente / gruppo Oracle e un gruppo dba a cui appartiene l'utente Oracle. Tutto funziona senza intoppi e senza che il DBA abbia attualmente l'accesso root.
Penso anche che tutte le attività amministrative come il riavvio pianificato del server debbano essere eseguite dall'amministratore appropriato (l'amministratore di sistema nel nostro caso) per evitare qualsiasi tipo di problema relativo a un malinteso delle interazioni dell'infrastruttura.

Vorrei input da amministratori di sistema e Oracle DBA - C'è qualche buona ragione per un Oracle DBA di avere accesso root in un ambiente di produzione ?

Se il mio collega ha davvero bisogno di questo livello di accesso, lo fornirò, ma ho abbastanza paura di farlo a causa di problemi di sicurezza e integrità del sistema.

Non sto cercando vantaggi / svantaggi, ma piuttosto consigli su come dovrei prendere per affrontare questa situazione.

• Chi installa Oracle sui server?
  Se è il DBA hanno bisogno dell'accesso root. Se è l'amministratore di sistema, il DBA no.

• Chi viene chiamato a tarda notte quando il server di database è inattivo?
  Se non riesci a garantire che gli amministratori di sistema siano disponibili 24 ore su 24, 7 giorni su 7, potresti voler fornire l'accesso root al DBA.

Ricorda che se il tuo DBA ha già accesso alla shell come utente normale (con o senza alcuni comandi, può essere eseguito tramite sudo; con o senza essere chroot) è abbastanza per confondere il server (un cattivo che ruba il suo account può bombardare , supera ulimit inviando spam, rilascia il database, ...).

Per tutte queste ragioni, penso che in un mondo ideale i DBA non debbano avere accesso root ; ma nel mondo reale, dovrebbero almeno essere in grado di ottenerlo in caso di emergenza.

In generale, e non specifico dei DBA, chiunque richieda l' rootaccesso senza fornire una motivazione valida è:

1. Qualcuno che non sa cosa sta facendo.
2. Arrogante e poco collaborativo.
3. Entrambi i precedenti.

Ora, potrebbero esserci dei veri motivi per cui hanno bisogno rootdell'accesso per gestire il loro compito, ma di nuovo se non possono spiegare il perché e metterlo per iscritto, non vorrei occuparmene. I professionisti che si occupano di server comprendono e rispettano i confini. I colpi caldi che sanno abbastanza da mettersi nei guai credono che le regole si applichino a tutti tranne che a loro.

Nei casi in cui ho dovuto litigare con persone come questa, ho insistito sul fatto che il tempo fosse programmato in anticipo in modo da poter essere sul server con loro per gestire i problemi quando si presentano. E questo ha effettivamente funzionato bene.

Un'altra alternativa, che potrebbe non essere pratica, è quella di creare un clone esatto del server in questione e fornirli root accesso su quello. Assicurati di cambiare la password in qualcosa di specifico per loro, ovviamente. Lascia che faccia esplodere una scatola di sviluppo isolata.

Ma in generale, se sei tu quello che verrà chiamato a tarda notte per ripulire un casino che questo ragazzo potrebbe creare, allora hai tutto il diritto di dire di no a una richiesta generale di rootaccesso.

Teoricamente i DBA possono funzionare senza i privilegi di root, ma è PITA per entrambe le parti. È praticamente impossibile definire un elenco di comandi accessibili tramite sudo.

Dare i privilegi di root ai DBA se:

• non vuoi essere svegliato nel bel mezzo della notte, solo per riavviare il server
• vuoi una gestione degli incidenti rapida e fluida
• se il server è dedicato solo al server DB

I DBA hanno generalmente bisogno di privilegi di root per: aggiustamenti dei parametri del kernel (sysctl), manipolazione dell'archiviazione, investigazione dei problemi.

L'audizione corretta garantisce condizioni di funzionamento migliori rispetto alle regole di sicurezza rigorosamente definite. Se hai implementato il controllo, puoi sempre chiedere perché hanno fatto / cambiato qualcosa. Se non si dispone del controllo, non si dispone comunque della sicurezza.

MODIFICATO

Questo è un elenco di requisiti Oracle comuni su standalone (installazioni non cluster)

• Parametri del kernel

  • Memoria (configurazione di pagine grandi / enormi, RAM condivisa (ipcs), RAM non scambiabile (bloccata)
  • relativi alle reti (dimensioni della finestra di invio / ricezione, keepalive TCP)
  • relativo all'archiviazione (numero di file aperti, IO asincrono)

  Potrebbero esserci circa 15-20 parametri sysctl. Per ognuno di essi, Oracle fornisce un valore consigliato o un'equazione. Per alcuni parametri l'equazione consigliata può cambiare nel tempo (aync io) o in alcuni casi Oracle ha fornito più di un'equazione per lo stesso parametro.

• Archiviazione: le regole udev di Linux non garantiscono i nomi dei dispositivi persistenti all'avvio. Pertanto Oracle ha fornito driver e strumenti del kernel (AsmLib). Ciò consente di "etichettare" le partizioni fisiche come root e quindi è possibile visualizzare queste etichette durante la gestione dell'archiviazione del database
• Indagine sul problema:
  • Quando il database si arresta in modo anomalo perché non può aprire più handle di file, l'unica soluzione è aumentare il limite del kernel, eseguire 'sysctl -p' e quindi avviare il DB.
  • Inoltre, quando si riscontra che la RAM fisica è troppo frammentata e il database non può allocare pagine di grandi dimensioni, l'unica opzione è riavviare il server.
  • (DCD) - rilevamento di connessioni morte. Ad esempio su AIX netstat non stampa PID. L'unico modo per accoppiare una connessione TCP con PID è il debugger del kernel.
  • colpo d'occhio (qualcosa come top su HP-UX) richiede i privilegi di root
  • varie indagini a livello di Veritas
  • e molti altri ancora

Sta a te decidere quanto tempo "sprecherai" fino a quando il problema non sarà risolto. Volevo solo sottolineare che la forte separazione dei ruoli può essere molto costosa in alcuni casi. Quindi, invece di aumentare la "sicurezza", concentrarsi sulla riduzione di rischi e pericoli. Quale non è lo stesso. Strumenti come ttysnoop o shell spy ti permettono di "registrare" l'intera sessione ssh, garantendo quindi innegabilità. Questo può servire meglio di sudo.

Sono un DBA Oracle e la mia risposta è, normalmente DBA non ha bisogno dell'accesso root. Ma un DBA RAC? sicuramente ha bisogno dell'accesso root per gestire CRS, house cleaning e tutto il resto.

Questa domanda nasce da un'epoca in cui i sistemi erano molto più semplici e i processi del sistema operativo rispetto al database erano definiti e identificabili separatamente. Le funzioni e le responsabilità di amministrazione del sistema e amministrazione del database erano molto distinte. Con gli ambienti IT di oggi e, in particolare, con i server di database di oggi, questi compiti e responsabilità, il più delle volte, tendono a sovrapporsi. L'amministratore di sistema fa la dovuta diligenza per limitare l'accesso "root" rispetto alla "gestione del rischio".

Con le richieste odierne di "alta disponibilità" e "risoluzione immediata" per i problemi che sorgono con i nostri sistemi di database RAC, gli amministratori di sistema e gli amministratori di database servono le loro comunità aziendali funzionali, lavorando insieme come una squadra. Non ci dovrebbero essere problemi di "fiducia", poiché entrambe le parti hanno un interesse acquisito a mantenere i server di database RAC online quasi il 100% delle volte. Ricorda, il DBA ha già accesso alla shell come amministratore del database (con o senza alcuni comandi che può eseguire tramite sudo; con o senza chroot), quindi ovviamente il DBA è un agente "fidato". Quindi, in realtà la domanda dovrebbe essere: "Perché il DBA Oracle non ha bisogno di accesso?"

Il DBA di oggi ha assunto ulteriori responsabilità per il server di database, in cui un server di database è membro di un Oracle Real Application Cluster (RAC) e utilizza Oracle Automatic Storage Management (ASMLIB) per presentare l'archiviazione condivisa tra i database RAC. La gestione del CCR e dell'ASM da parte del DBA allevia l'amministratore di sistema già sovraccarico di lavoro, che dovrebbe essere un gradito contributo al gruppo / team STS.

E, come affermato da ibre5043, "... in alcuni casi può essere molto costosa la separazione dei ruoli. Quindi, invece di aumentare la" sicurezza ", l'attenzione sulla riduzione del rischio e dei pericoli. Che non è la stessa cosa. Strumenti come ttysnoop o shell spia ti permettono "registrare" l'intera sessione ssh, quindi garantiscono innegabile. Questo può servire meglio di sudo ". Inoltre, dovresti chiedere chi sta monitorando gli SSA.

Se i server utilizzano software Oracle Grid Infrastructure come CRS, RAC o Oracle Restart, molti dei servizi di database critici vengono eseguiti come root e molti dei file di configurazione del database critici sono di proprietà di root. È una caratteristica di progettazione intrinseca del software. Se questa è una violazione delle vostre politiche, le politiche devono essere riviste.

Il DBA richiederà l'accesso come root per amministrare queste funzionalità. Teoricamente potresti chiedergli un elenco dei comandi che si aspetta che vengano eseguiti in Sudo, ma la risposta sarà un elenco molto lungo. Dai un'occhiata a $ GRID_HOME / bin per un elenco di tutti i file binari che il DBA potrebbe utilizzare su base regolare. Se stanno eseguendo attività di patch (che dovrebbero essere), l'elenco potrebbe allungarsi ancora di più.

Ho appena presentato una domanda simile. In realtà la ragione per cui un amministratore di sistema non vuole dare il privilegio di radice, è quella della responsabilità e responsabilità che penso.

Ma se questa è la causa, il DBA dovrebbe essere anche l'unico e solo amministratore di sistema. E il motivo è semplice. Se è necessario separare responsabilità e responsabilità, l'amministratore di sistema può SEMPRE essere anche il DBA. Può impersonare l'account Oracle, può entrare nel database come SYSDBA e fare qualunque cosa, senza la necessità della password SYS o SYSTEM.

Quindi, a mio avviso, se è necessaria la separazione di amministratori di sistema e DBA, a causa di responsabilità e responsabilità, l'unica causa logica è che anche il server dovrebbe essere gestito dal DBA e non dal amministratore di sistema. Il server e il database dovrebbero essere nel complesso responsabili del DBA, che dovrebbe anche avere una certa conoscenza dell'amministrazione del sistema.

Se il server viene utilizzato per più dell'hosting del database e vi è questa necessità di responsabilità e responsabilità separate, ciò significa problemi. Ma se il server viene utilizzato solo per l'hosting del database, non vedo alcun motivo per cui il DBA non dovrebbe avere il privilegio di root, tenuto conto della miriade di casi di cui avrebbe bisogno anche lui.

Personalmente vorrei porre la domanda al contrario. Perché l'amministratore di sistema ha il privilegio di root su un server di database dedicato? In effetti, la sua specialità sarebbe richiesta in molti meno casi, rispetto a quella del DBA (con il privilegio di root).

L'accesso root è richiesto per l'installazione e il patching della griglia Oracle. Non c'è modo di aggirarlo. Se esistesse un modo per concedere un accesso root temporaneo a un DBA per tali esigenze, sarebbe l'ideale.