Come proteggere il server MySQL in caso di furto dell'hardware

Non vedo come limitare i tempi di accesso di un client abbia molta rilevanza per il problema che stai cercando di risolvere. Stai anche chiudendo la porta per eseguire il servizio su Internet se ti espanderai oltre la tua LAN.

L'aggiunta di un semplice server di riposo fornisce un modo semplice per applicare regole di accesso astratte all'applicazione (in effetti sto cercando di capire perché progettare una soluzione contro hardware specifico piuttosto che modellare l'accesso attorno a un modello basato su cloud , anche se si finisce per implementarlo sul proprio hardware).

Le persone che sono eccessivamente preziose (in particolare nelle piccole società di software) sulla loro proprietà intellettuale sono un tema ricorrente qui e altrove su Internet; minando i tuoi legittimi clienti ma ignorando le vere minacce del furto di proprietà intellettuale. Se la domanda riguarda davvero la sicurezza dei dati scambiati dopo questa stretta di mano bizantina, allora dovresti parlare con qualcuno che capisce questo molto meglio piuttosto che pubblicare una domanda su Internet su qualcosa solo tangenzialmente correlato al vero problema.

The client first provides the key and gets connected to the root account

OMG, no.

Sto davvero cercando di capire il motivo per cui su qualsiasi applicazione dovresti considerare l'utilizzo di root come account di servizio, per non parlare di quello in cui sei così preoccupato per la sicurezza. MySQL ha la possibilità di devolvere le autorizzazioni in modo molto granulare con un meccanismo di separazione dei privilegi.

Qualsiasi controllo applicato tramite iptables, stored procedure o all'interno della logica dell'applicazione di un server REST attivo l'host può essere facilmente aggirato se qualcuno ha il controllo fisico del dispositivo. La crittografia del disco risolve questo problema. Presumo che la tua menzione di post-it e laptop significhi che ti aspetti di dare la passphrase di crittografia del disco a molte persone. Questo è facilmente risolvibile: non dare a nessuno la password. Potresti andare a comprare un prodotto costoso come CyberArk AIM per servire la passphrase su richiesta, ma perché? È banale inserire la passphrase da qualche altra parte e scrivere uno script di shell di 10 righe per recuperare la passphrase tramite SSH / Https (o anche un'altra istanza di MySQL accessibile tramite tunnel) convalidando l'host crittografato utilizzando un certificato keypair / client e applicando il proprio orario / posizione regole nell'host del server passphrase. E il server passphrase dovrebbe risiedere in una posizione fisica diversa per affrontare il modello di minaccia dichiarato.

Se questo sembra simile al tuo modello di server FTP, fai attenzione alla differenza: il server passphrase è altrove e il metodo di autenticazione tra il server mysql e il server passphrase è sicuro. Se qualcuno può rubare il server mysql e un laptop, può rubare il server FTP.

Suggerimento per il tuo problema:

• Assicurati che il fuso orario sia configurato correttamente e che tu esegua ntpdate/ntpd sul tuo computer per mantenere il tempo sincronizzato.
• Applica le regole di iptables in base all'ora e al giorno.

iptables -A INPUT -m time --timestart 07:00 --timestop 19:00 --weekdays Mon,Tue,Wed,Thu,Fri -j ACCEPT

• Per il supporto GeoIP con Linux netfilter vedi: link

In un'altra nota ti suggerisco di abilitare Google Authenticator (notifiche telefono / push) o Yubikey integrato con PAM, per ottenere uno schema di autenticazione a più fattori.

Avere un HDD in chiaro nel server, qualcuno avrà la possibilità di rilevare quali script vengono eseguiti all'avvio e la soluzione di rilevamento degli hashing della stampante verrà aggirata in pochissimo tempo.

Se un server viene fisicamente rubato, spesso viene spento. Se si dispone della crittografia Full HD, che necessita di una chiave da utilizzare quando viene avviata; nessuno sarà in grado di avviare i tuoi servizi; che elimina il rischio che qualcuno estrapoli qualsiasi modulo di dati lì. Abilitare la crittografia completa del disco, sarebbe la mia prima raccomandazione.

Penso che il modello trattato dell'architettura client / server sia intrinsecamente imperfetto; qualcuno potrebbe rubare un laptop, (o avere l'esecuzione di codice in remoto senza dover prendere fisicamente un laptop) estrarre la chiave e avere accesso root al proprio DB MySQL; e anche tutti i dati in là (nomi utente, password / hash, dati dei clienti, ecc ...).

Consiglierei qualche login basato su SSL, in base al quale ogni utente ha la sua coppia di cert (aumenta l'auditing e la responsabilità), e se pensi che ci sia qualche gioco falloso; puoi revocare il certificato. I login SSL sono disponibili all'indirizzo link

Spero che questo aiuti,