Il mio DBA Oracle necessita dell'accesso root?

Soluzione 1:

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

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

Tieni presente che se il tuo DBA ha già accesso alla shell come utente normale (con o senza alcuni comandi che può eseguire tramite sudo; con o senza essere sottoposto a chroot) è sufficiente per incasinare il server (un malintenzionato che ruba il suo account può fare fork bomb , superare il limite massimo di invio di spam, eliminare il database, ...).

Per tutti questi motivi, penso che in un mondo ideale i DBA non dovrebbero avere accesso root; ma nel mondo reale dovrebbero almeno essere sempre in grado di ottenerlo in caso di emergenza.

Soluzione 2:

In generale, e non specificamente per i DBA, chiunque richieda root l'accesso senza fornire un motivo valido è:

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

Ora, potrebbero esserci reali motivi per cui hanno bisogno di root accesso per gestire il loro compito, ma ancora una volta se non possono spiegare perché e metterlo per iscritto, non mi occuperei di loro. I professionisti che si occupano di server comprendono e rispettano i confini. I pezzi grossi che sanno abbastanza per finire nei guai credono che le regole si applichino a tutti tranne loro.

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

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

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

Soluzione 3:

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

Assegna privilegi di root agli amministratori di database se:

• non vuoi essere svegliato nel cuore della notte, solo per riavviare il server
• desideri una gestione degli incidenti rapida e agevole
• se il tuo server è dedicato solo per DB server

I DBA di solito hanno bisogno dei privilegi di root per:regolazione dei parametri del kernel (sysctl), manipolazione dell'archiviazione, indagine sui problemi.

Un'audizione corretta garantisce condizioni di esecuzione migliori rispetto a regole di sicurezza rigorosamente definite. Se hai implementato l'auditing, puoi sempre chiedere perché hanno fatto/cambiato qualcosa. Se non hai il controllo, non hai comunque la sicurezza.

MODIFICATO

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

• Parametri del kernel

  • Relativo alla memoria (configurazione di pagine grandi/enormi, RAM condivisa (ipcs), RAM non scambiabile (bloccata))
  • relative alle reti (dimensioni della finestra di invio/ricezione, TCP keepalive)
  • 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.

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

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", concentrati sulla riduzione di rischi e pericoli. Che non è la stessa cosa. Strumenti come ttysnoop o shell spy permettono di "registrare" l'intera sessione ssh, quindi garantiscono l'innegabilità. Questo può servire meglio di sudo.