Considera una rete per un'applicazione web con 1 server web e 1 database MySQL, sia su server fisicamente diversi sia su Linux. Il database memorizza i dati mission critical e questi dati sono e devono essere manipolati dal web server.
Ora, ovviamente, vogliamo assicurarci che vengano apportate solo modifiche autorizzate a questo database. Questo è in gran parte implementato nell'applicazione e una parte viene gestita creando utenti di database con quantità limitate di autorizzazioni.
Tuttavia, permangono lacune con questo approccio. Ad esempio: l'amministratore di sistema non è autorizzato ad apportare modifiche al database in modo indipendente. Né gli ingegneri avrebbero diritti di distribuzione. Ma, ovviamente, sarebbero in grado di farlo catturando le credenziali del database dal server web e accedendo da lì.
Qualsiasi modifica effettuata in questo modo sarebbe fondamentalmente anonima in quanto sarebbe oscurata da molti altri cambiamenti che renderebbero difficile la rilevazione.
È (probabilmente) non fattibile o saggio implementare qualcosa che in realtà impedirà al 100% al sysadmin di essere in grado di apportare modifiche in questo modo. Sysadmin e altri dovrebbero essere in grado di apportare modifiche ai dati e allo schema utilizzando i propri account man mano che l'applicazione viene sviluppata attivamente. Tuttavia, non dovrebbero essere in grado di farlo senza che nessuno se ne accorga.
Ecco alcune possibili strategie per impedire agli addetti ai lavori di modificare i dati in modo anonimo:
-
Implementare la registrazione di controllo sul sistema per segnalare tutti i programmi eseguiti. Questo avrebbe trovato eventuali chiamate dirette a
mysqlcli e forse alcuni script dall'aspetto approssimativo. Qualsiasi modifica eseguita con successo sarebbe ancora difficile da trovare in quanto lo scripting oscurerebbe le modifiche effettive eseguite. -
Utilizza i certificati client sulla connessione al database con frasi di accesso sulla chiave privata. Ciò significa che un amministratore di sistema non è più in grado di riavviare una macchina senza la presenza di un gestore applicazioni. Probabilmente sono necessari altri controlli per proteggere le chiavi in memoria, sysadm essendo root e tutto.
-
Implementare la registrazione di controllo nel database. L'applicazione Web causa una notevole quantità di traffico nel database, pertanto è improbabile che vengano rilevate eventuali modifiche dannose all'utente del database dell'applicazione. Ciò significa che il monitoraggio può essere implementato solo per gli utenti di database interattivi.
-
Utilizza IPTables per bloccare il traffico verso il database all'utente dell'applicazione. Avrebbe almeno creato un audit-trail di sysadmin che diventasse l'utente dell'applicazione (sudo) o che modificasse il firewall per consentire il traffico. Non infallibile, dal momento che qualsiasi modifica apportata utilizzando l'utente del database dell'applicazione sarebbe ancora difficile da trovare.
-
Implementare SELinux per limitare il traffico del database (etichettatura dei pacchetti tramite SECMARK) al dominio dell'applicazione e proteggere ulteriormente la distribuzione e creare catene per impedire / rilevare modifiche non autorizzate. Se sysadmin ha bisogno dell'accesso di rete al database, questo può essere verificato tramite
auditallow, ma l'accesso amministrativo deve avvenire attraverso un altro utente che viene controllato. Eventuali modifiche al sistema o modifiche di SELinux verrebbero segnalate. Questo è ovviamente un cambiamento di alto impatto con molti requisiti extra che richiedono molta conoscenza.
Al di là della semplice fiducia nel sysadmin, in che modo tu ti avvicini a questo? Le cose sopra funzionerebbero? Quali altre cose si potrebbero fare per assicurarsi che un amministratore di sistema o un utente con privilegi simili non possano accedere al database inosservato?