Come proteggere gli accessi non autorizzati nel caso in cui il server DB venga compromesso?

In effetti, tutto ciò che sta facendo l'hacker sta cambiando le password degli utenti. Ciò consentirebbe all'utente malintenzionato di accedere agli account di quegli utenti. Per quanto riguarda la protezione da questo, non sono sicuro che dovresti preoccuparti. Se qualcuno ha accesso in lettura / scrittura al tuo DB, sei praticamente affondato. È necessario proteggere da qualcuno che ottiene l'accesso in lettura / scrittura al DB, in primo luogo, non cercare di impedire a qualcuno che ha accesso in scrittura semplicemente cambiando la password di qualcuno.

Questo è un po 'come chiedersi, se qualcuno irrompe nella tua casa, come puoi impedirgli di aprire il frigo e rubare la tua birra?

La tua domanda può essere parafrasata come:

Come impedisci a qualcuno che ha accesso di modificare i dati dalla modifica dei dati?

Il primo passo è garantire che solo le persone che si prevede abbiano accesso abbiano accesso. Si tratta di buone pratiche di gestione delle password e di verifica dell'account (per coloro che sono attesi ad un certo punto di accedere) mentre si prevengono persone a cui non si intende accedere, patch regolari, ispezioni di codice e test delle penne.

Ma non puoi impedire al tuo amministratore di sistema di impazzire (a parte buoni stipendi e condizioni di lavoro, ecc.) e non puoi mai dimostrare che il tuo sistema è completamente sicuro. Ma ci sono ancora cose che puoi fare per prevenire o contenere tale attività.

La classica app web a 3 livelli ha un account di servizio sul livello applicazione che si collega al database. Ho visto spesso (e in passato scritto) app in cui questo account ha accesso in lettura / scrittura a tutte le tabelle contenenti i dati da manipolare. La limitazione delle operazioni di lettura e scrittura a record specifici mediante l'utilizzo di procedure memorizzate fornisce una certa attenuazione.

Un approccio complementare consiste nel rendere l'autenticazione dal livello applicazione al database dipendente dalle credenziali fornite dall'utente finale piuttosto che considerare semplicemente la convalida delle credenziali dell'utente come test del gateway. Nel modo più semplice, gli utenti finali verrebbero creati come utenti del database e l'applicazione memorizzerebbe le proprie credenziali ogni volta che è necessario connettersi. Tuttavia, questo approccio presenta problemi di scalabilità, in particolare con Oracle, che presenta un processo di autenticazione piuttosto loquace, con il risultato che la maggior parte delle app su Oracle riutilizza le connessioni persistenti. In assenza di ulteriori controlli, significa anche che le password degli utenti finali vengono archiviate in testo chiaro anziché solo la password di servizio in chiaro (ma esistono soluzioni a questo).

L'altro pezzo importante del puzzle, dopo aver fatto tutto il possibile per prevenire un incidente, è il rilevamento: Catturare gli identificatori del client (indirizzo IP) quando vengono modificati i dati importanti: catturare le query e il DML che viene inviato a quel database e verificandolo: distribuendo i dati honeypot / canary

Penso che non sia possibile - se hanno il controllo del server App, possono correggerlo per ignorare completamente il controllo della password.

Il punto di hashing è rendere più difficile passare da un database trapelato per accedere agli account online. Inoltre, è più difficile estrarre qualsiasi password condivisa dagli utenti tra i servizi.

Se hanno la capacità di alterare solo il database live (e non il server dell'app), un "pepe" aggiunto all'hash potrebbe impedire che sostituiscano l'hash con il proprio.

Lo scenario che descrivi è molto peggiore di quello che l'hacker potrebbe semplicemente sostituire le password degli utenti con le proprie, se possono modificare il codice dell'applicazione possono fare tutto ciò che vogliono. Con il riutilizzo della password sarei anche preoccupato che le password in chiaro fossero esposte.

Se non puoi più fidarti del codice della tua applicazione, allora hai già perso completamente. L'unica cosa che rimane da fare è cancellarla da orbita .

Modifica: Dal momento che l'attaccante non può modificare il codice dell'applicazione non sarà in grado di rubare le password in chiaro, ma dal momento che possono probabilmente fare la maggior parte delle cose l'app permette modificando direttamente il database non sembra valsa la pena di impedirgli di sostituire le password anche se fosse possibile.

Monitoraggio della sicurezza

È possibile distribuire strumenti in grado di monitorare tutto all'interno di un database e creare avvisi quando un utente modifica le informazioni o esegue script all'interno del database, la maggior parte di questi strumenti segnalerà l'istante di un accesso utente al database e ogni script e procedura modifica / esegui durante il suo tempo all'interno.

Ricorda che l'amministratore del database può accedere al database ma le informazioni / tabelle / script devono essere limitate completamente.

Come può essere protetto?

Implementa diversi approcci o procedure per l'accesso di qualsiasi dipendente al tuo database e l'escissione di script e procedure.

Il tuo DB Admin ha accesso al tuo database, ma l'accesso che tu concedi non è per il DB completo, solo per scopi specifici focalizzati principalmente nella manutenzione.

Può chiedere a Information Security le credenziali per un altro utente all'interno del DB con ancora più opzioni disponibili, ma a seconda della criticità di tali opzioni, è possibile definire più processi.

• Molte approvazioni di persone diverse per consentire l'accesso.
• Qualcuno della sicurezza rimarrà con te mentre stai facendo il tuo compito.
• Punti di ripristino dal punto in cui inizi a lavorare con il superutente
• Le password sono solo un uso e vengono eliminate una volta usate

Le risposte sopra sono corrette - se hanno accesso al server DB e al server delle app è in gran parte game over.

Tuttavia, in termini di domande molto specifiche su come cambiare la password di un utente, @TTT lo ha riassunto bene:

Effectively, all the attacker is doing is changing users' passwords. This would enable the attacker to login to those users' accounts.

Questo è molto vero

As for how you protect against this, I'm not sure you should bother.

C'è una possibile protezione qui: implementa l'autenticazione a due fattori! Non protegge il DB in alcun modo, ma significa che non è sufficiente cambiare la password per poter accedere come tale utente.

Ora, probabilmente non sarebbe d'aiuto in questa situazione: se avessero pieno accesso al server app e al server DB, probabilmente potrebbero disabilitare il 2FA o cambiarlo in qualcosa controllato dall'hacker. Ma in termini di protezione da qualcuno che modifica gli hash delle password (la lettura più stretta della domanda originale), questo ti proteggerebbe in una certa misura. Nota che sia l'attaccante che l'utente reale finirebbero per essere bloccati (uno conosceva la password, l'altro avrebbe potuto rispondere alla sfida dei due fattori), quindi sarebbe comunque di disturbo.

Naturalmente, ci sono altri motivi migliori per implementare la 2FA ("migliore" nel senso che proteggono da più probabili vettori di attacco - quelli che non sono già "game over")

Non ho capito esattamente quale sia la tua intenzione di rilasciare un nuovo hash nel campo appropriato. E anche io non posso dirvi come è in generale, poiché ci sono molti sistemi db che gestiscono diversamente password, userdata o crittografia. Le seguenti opzioni sono disponibili per il sistema db con cui lavoro (postgresql):

• la password è lato client con hash e non sarà chiara sul server
• la password diventa salata per ogni connessione per impedire di catturare l'hash e utilizzarlo per ulteriori sessioni
• crittografia basata su certificato
• la solita crittografia dei dati a livello di colonna o file system
• la crittografia lato client impedisce che qualsiasi dato raggiunga il server non crittografato

Con queste precauzioni dovrebbe essere ben protetto. Ma ciò dipende dal database e dal client (l'app web) che non hai specificato.