Perché l'autenticazione del sistema operativo è considerata scarsa sicurezza per i database Oracle?

Oracle sta deprecando l'autenticazione del sistema operativo secondo la Guida alla sicurezza del database Oracle , che dice

Tenere presente che il parametro REMOTE_OS_AUTHENT è stato deprecato in Oracle Database 11g versione 1 (11.1) e viene mantenuto solo per compatibilità con le versioni precedenti.

Inoltre, la maggior parte delle informazioni e degli strumenti di sicurezza considera l' autenticazione del sistema operativo (esterna) un problema di sicurezza. Sto cercando di capire perché questo è il caso. Ecco alcuni vantaggi che vedo dell'autenticazione del sistema operativo:

1. Senza l'autenticazione del sistema operativo, le applicazioni devono archiviare le password in una varietà di applicazioni, ognuna con il proprio modello di sicurezza e vulnerabilità.
2. L'autenticazione del dominio deve già essere sicura perché, in caso contrario, la sicurezza del database rallenta l'accesso al database, ma non può impedirlo.
3. Gli utenti che devono ricordare solo una password di dominio possono essere creati per creare password di dominio più sicure più facilmente di quanto possano essere fatte per creare password di database ancora meno sicure poiché il numero di database diversi a cui devono connettersi aumenta.

Considera il seguente scenario:

1. Esiste un utente Unix denominato gaiussul server Oracle con autenticazione esterna, quindi in Oracle esiste un utente corrispondente chiamato ops$gaius. Quando ho effettuato l'accesso a una shell, posso anche accedere direttamente al mio schema Oracle e anche i miei lavori cron non hanno bisogno di una password incorporata nello script.
2. L'autenticazione del sistema operativo remoto è consentita, supponendo che la LAN sia sicura al 100% e che i client possano essere considerati attendibili (stessi rlogin/ rshusati per essere normalmente ammessi)
3. Un utente malintenzionato porta il proprio laptop sulla LAN con qualsiasi mezzo, sa che ci lavoro e crea un utente locale sul proprio laptop chiamato gaiused esegue SQL * Plus come tale utente
4. Oracle vede (cioè OSUSERin V$SESSION) is gaiuse registra l'utente remoto comeops$gaius

Questo non è solo ridicolmente facile da spoof, ma mettere sul cappello di mio cinico, Oracle non può fare più soldi vendendo la loro fantasia single sign-on del prodotto ... Che tra l'altro non soddisfare tutti i punti che sollevare il maggior vantaggio di OS -livello auth. Due password migliori di una sono completamente false; la maggior parte delle persone li imposterà comunque allo stesso modo (non esiste alcun meccanismo in Oracle per impedirlo).

Il principio generale è che è estremamente difficile difendersi dal software quando un utente malintenzionato ha accesso fisico. E non fidarti mai del cliente.

Aumenta i singoli punti di errore e amplia la superficie di rischio dei dati.

Un utente malintenzionato che ottiene l'accesso al sistema avrà, con l'autenticazione del sistema operativo, accesso al database. Richiedendo un accesso più sicuro al database, il potenziale attaccante deve aumentare i propri privilegi sul sistema compromesso per ottenere l'accesso root o Oracle, piuttosto che qualsiasi utente.

Questo problema è una funzione dell'accesso esterno al database. Se non vi è accesso esterno e la macchina è completamente protetta, la questione delle autorizzazioni è controversa. Tuttavia, se gli sviluppatori hanno accesso, le autorizzazioni utente a livello di sistema operativo aumentano la portata di potenziali disastri di sicurezza.

Prendi in considerazione l'utilizzo dell'accesso a più livelli per limitare l'ambito delle violazioni della sicurezza e fornire a qualsiasi utente, applicazione o client l'accesso di cui hanno bisogno senza la necessità di creare account a livello di sistema operativo per ogni istanza.

Gaius ha già sottolineato perché l' autenticazione del sistema operativo remoto (al contrario dell'autenticazione del sistema operativo vanilla in cui si consente agli utenti di macchine locali di accedere al database senza specificare una password separata) è relativamente insicura.

Mi aspetto che Oracle si stia muovendo in questa direzione perché vuole incoraggiare le persone a utilizzare gli utenti aziendali (o la suite di gestione delle identità a pieno titolo) piuttosto che gli utenti autenticati del sistema operativo remoto. Gli utenti aziendali hanno gli stessi vantaggi degli utenti autenticati dal sistema operativo remoto, ma Oracle sta effettivamente uscendo e sta colpendo il tuo server Active Directory per autenticare l'utente. Ottieni gli stessi vantaggi dell'accesso singolo senza lasciare il controllo di sicurezza al computer client.

Indichi in particolare l'autenticazione in stile ident, ma vorrei anche sottolineare che altri metodi per legare database o altri accessi agli accessi del sistema operativo sono altrettanto dannosi. (che si tratti di file di password locali, LDAP o qualsiasi altra cosa per l'archiviazione effettiva delle credenziali)

Se si consentono connessioni remote al database (o al server web, o qualsiasi cosa stia facendo l'autenticazione), alcuni sistemi operativi ignoreranno le regole che potrebbero essere impostate per rendere difficile la creazione di account di forza bruta (ad esempio, il blocco degli IP da cui provengono i tentativi falliti; blocco utenti per un periodo dopo un determinato numero di falures, ecc.). Normalmente, queste regole sono legate sshde non al sistema di autenticazione nel suo insieme.

Quindi, se qualcuno dovrebbe essere in grado di connettersi al database / server web / qualunque cosa da remoto, può forzare la password, poiché i database non tendono ad avere gli stessi meccanismi per rallentare i tentativi, quindi entrano quando trovano le credenziali necessarie.