Che cosa può fare un utente malintenzionato se conosce le credenziali del mio database?

Supponendo che

• Sei sicuro al 100% che il tuo server di database accetti solo connessioni locali.
• Sei sicuro al 100% che l'autore dell'attacco non abbia accesso all'ambiente locale da cui sono consentite le connessioni.
• Sei sicuro al 100% che l'applicazione che utilizza il database sia al sicuro.
• Sei sicuro al 100% che quelle credenziali non vengano utilizzate per qualcos'altro direttamente o indirettamente correlato al sistema.

Quindi, non c'è alcun problema nel loro essere esposti.

Naturalmente, come puoi vedere, queste sono ipotesi molto grandi. Se sei disposto a scommettere, vai avanti e lascia che le credenziali siano esposte. Se no (non lo farei), quindi lavora nel modo migliore possibile sulla tua sicurezza, e mantengono segrete quelle credenziali.

Se non può accedere al database, le credenziali sono prive di significato. È come avere una chiave per una porta che si trova all'interno di un bunker militare custodito nascosto in una remota posizione nel deserto del Gobi. La chiave è utile solo se puoi ottenere alla porta.

Detto questo, sarebbe una pessima pratica lasciare che le tue credenziali si perdessero in questo modo. Se sospetti che siano compromessi, vai a cambiarli.

Finché il server DB è correttamente protetto e le credenziali sono correttamente collegate a indirizzi IP a cui non ha accesso, allora non può fare nulla con loro, ma rimuove un livello di protezione e se trova un modo per accedere al DB, quindi si hosed.

Questo è chiamato difesa in profondità. Diversi meccanismi prevengono un compromesso, tuttavia se si sospetta che un livello venga compromesso, si è meno sicuri finché non si corregge il compromesso.

In pratica, quasi tutti i database sql (MsSql, MySql, Oracle ecc.) hanno la capacità di eseguire comandi del sistema operativo. Quindi, se l'utente malintenzionato conosce la password del DB, può eseguire comandi OS su una macchina DB. Se il processo che esegue il tuo motore db ha privilegi elevati, allora l'attaccante può prendere il controllo dell'intera macchina. Oltre questo è limitato al tuo immaginario. Ad esempio:

• È in grado di attaccare altri computer nella rete dalla macchina db.
• Se si utilizza la virtualizzazione, è possibile estendere l'attacco al motore della VM e altri sistemi operativi sull'ambiente virtuale possono essere compromessi.
• Raccogli dati sensuali molto importanti per i futuri attacchi di social engineering.
• Prendere i nomi degli account utente e le password e provarli per altri sistemi di informazione sulla propria organizzazione. Le persone usano per lo più lo stesso strong? password su più sistemi.
• Ascolta il traffico nella tua rete e annota i dati importanti.
• Inserisci un trojan o una backdoor per accesso futuro ecc.

Che cosa puoi fare per proteggerti anche se l'hacker conosce la tua password db:

• È possibile limitare i privilegi dell'account utente db. Non dimenticare che a volte l'utente malintenzionato può aumentare i suoi privilegi sulla macchina tramite exploit speciali che utilizzano vulnerabilità sul tuo sistema operativo.
• Disabilita le capacità di esecuzione shell del server DB (ma principalmente gli account utente db hanno il privilegio di abilitarlo di nuovo)
• Limita i privilegi del processo del motore db. La maggior parte delle volte gli attacchi SQL injection hanno successo a causa dell'errata installazione dei server db. Soprattutto l'installazione di MsSql consente di impostare facilmente gli account admin come proprietario del processo db.
• Isolare la tua macchina db dalla rete. Consenti solo le richieste in arrivo. Hai bisogno di farlo con una macchina firewall esterna. Ricorda che l'attaccante ha accesso al sistema operativo in modo che possa attivarlo se lo si limita da DB Server.
• Proteggi gli account dei tuoi utenti tramite hashing (con un sale ovviamente) e se la tua risorsa CPU è disponibile proteggi i dati sensibili con la crittografia simmetrica a livello di applicazione.

Questa non è una lista completa. Può essere più grande.