MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Come proteggere i database open source con ClusterControl

La sicurezza è uno degli aspetti più importanti dell'esecuzione di un database. Che tu sia uno sviluppatore o un DBA, se gestisci il database, è tua responsabilità salvaguardare i tuoi dati e proteggerli da qualsiasi tipo di accesso non autorizzato. Il fatto sfortunato è che molte organizzazioni non proteggono i propri dati, come abbiamo visto dalla nuova ondata di attacchi ransomware MongoDB nel settembre 2017. In precedenza avevamo pubblicato un blog su come proteggere i database MongoDB.

In questo post del blog, daremo un'occhiata a come proteggere i tuoi database utilizzando ClusterControl. Tutte le funzionalità qui descritte sono disponibili nella versione 1.5.1 di ClusterControl (rilasciata il 23 dicembre 2017). Tieni presente che alcune funzionalità sono disponibili solo per determinati tipi di database.

Crittografia backup

ClusterControl 1.5.1 ha introdotto una nuova funzionalità denominata crittografia di backup. Tutti i backup crittografati sono contrassegnati dall'icona di un lucchetto accanto:

È possibile utilizzare questa funzionalità su tutti i metodi di backup (mysqldump, xtrabackup, mongodump, pg_dump) supportati da ClusterControl. Per abilitare la crittografia, attiva semplicemente l'opzione "Abilita crittografia" durante la pianificazione o la creazione del backup. ClusterControl genera automaticamente una chiave per crittografare il backup. Utilizza l'algoritmo di crittografia AES-256 (CBC) ed esegue la crittografia al volo sul server di destinazione. Il comando seguente mostra un esempio di come ClusterControl esegue un backup di mysqldump:

$ mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --no-create-info --no-data --triggers --routines --events --single-transaction --skip-comments --skip-lock-tables --skip-add-locks --databases db1 | gzip -6 -c | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-094508-e0bc6ad658e88d93.tmp | socat - TCP4:192.168.55.170:9999'

Vedresti il ​​seguente errore se provassi a decomprimere un backup crittografato senza prima decrittografarlo con la chiave corretta:

$ gunzip mysqldump_2018-01-03_175727_data.sql.gz
gzip: mysqldump_2018-01-03_175727_data.sql.gz: not in gzip format

La chiave è archiviata all'interno del database ClusterControl e può essere recuperata dal file cmon_backup.metadata per un particolare set di backup. Verrà utilizzato da ClusterControl durante l'esecuzione del ripristino. Si consiglia vivamente di crittografare i backup, soprattutto quando si desidera proteggere i backup fuori sede, ad esempio archiviandoli nel cloud.

Crittografia client-server MySQL/PostgreSQL

Oltre a seguire i passaggi di sicurezza consigliati durante la distribuzione, puoi aumentare l'affidabilità del servizio di database utilizzando la crittografia SSL client-server. Utilizzando ClusterControl, puoi eseguire questa operazione con un semplice puntamento e clic:

È quindi possibile recuperare le chiavi e i certificati generati direttamente dall'host ClusterControl in /var/lib/cmon/ca percorso per stabilire connessioni sicure con i client del database. Tutte le chiavi e i certificati possono essere gestiti direttamente in Gestione chiavi, come descritto più avanti.

Crittografia della replica del database

Il traffico di replica all'interno di un cluster Galera può essere abilitato con un solo clic. ClusterControl utilizza una chiave predefinita a 2048 bit e un certificato generato sul nodo ClusterControl, che viene trasferito a tutti i nodi Galera:

È necessario un riavvio del cluster. ClusterControl eseguirà un'operazione di riavvio in sequenza, occupando un nodo alla volta. Vedrai un'icona a forma di lucchetto verde accanto al server del database (Galera indica la crittografia Galera Replication, mentre SSL indica la crittografia client-server) nella griglia Host della pagina Panoramica una volta abilitata la crittografia:

Tutte le chiavi e i certificati possono essere gestiti direttamente in Gestione chiavi, come descritto più avanti.

Gestione delle chiavi

Tutte le chiavi ei certificati generati possono essere gestiti direttamente dall'interfaccia utente di ClusterControl. La gestione delle chiavi ti consente di gestire i certificati SSL e le chiavi di cui è possibile eseguire il provisioning sui tuoi cluster:

Se il certificato è scaduto, puoi semplicemente utilizzare l'interfaccia utente per generare un nuovo certificato con la chiave e l'autorità di certificazione (CA) appropriate oppure importare una chiave e un certificato esistenti nell'host ClusterControl.

Consulenti per la sicurezza

Gli advisor sono miniprogrammi eseguiti in ClusterControl. Svolgono attività specifiche e forniscono consigli su come affrontare problemi in aree quali prestazioni, sicurezza, gestione dei registri, configurazione, spazio di archiviazione e altro. Ciascun advisor può essere pianificato come un processo cron ed eseguito come eseguibile autonomo all'interno dell'interfaccia utente di ClusterControl. Può anche essere eseguito tramite il client della riga di comando ClusterControl 's9s'.

ClusterControl abilita due consulenti di sicurezza per i sistemi basati su MySQL:

  • Accesso da qualsiasi host ('%') - Identifica tutti gli utenti che utilizzano un host con caratteri jolly dalla tabella di sistema mysql e ti consente di avere un maggiore controllo su quali host sono in grado di connettersi ai server.
  • Controlla il numero di account senza password - Identifica tutti gli utenti che non hanno una password nella tabella di sistema di mysql.

Per MongoDB, abbiamo i seguenti consulenti:

  • Autenticazione MongoDB abilitata:verifica se l'istanza MongoDB è in esecuzione con la modalità di autenticazione abilitata.
  • Verifica autorizzazione:verifica se gli utenti MongoDB sono autorizzati con un ruolo troppo permissivo per il controllo degli accessi.

Per maggiori dettagli su come ClusterControl esegue i controlli di sicurezza, puoi guardare il codice sorgente simile a JavaScript dell'advisor in Gestisci -> Developer Studio . Puoi vedere i risultati dell'esecuzione dalla pagina Advisors:

Interfacce di rete multiple

La presenza di più NIC sugli host del database consente di separare il traffico del database dal traffico di gestione. Una rete viene utilizzata dai nodi del database per comunicare tra loro e questa rete non è esposta ad alcuna rete pubblica. L'altra rete è utilizzata da ClusterControl, per scopi gestionali. ClusterControl è in grado di distribuire tale configurazione multi-rete. Considera il seguente diagramma di architettura:

Per importare il cluster di database sopra in ClusterControl, è necessario specificare l'indirizzo IP primario degli host di database. Successivamente, oltre alla rete dati, è possibile scegliere la rete di gestione:

ClusterControl può funzionare anche in un ambiente senza accesso a Internet, con i database totalmente isolati dalla rete pubblica. La maggior parte delle funzionalità funzionerà perfettamente. Se l'host ClusterControl è configurato con Internet, è anche in grado di clonare il repository del fornitore di database per i server di database senza Internet. Vai su Impostazioni (menu in alto) -> Repository -> Crea nuovo repository e impostare le opzioni per adattarsi all'ambiente del server di database di destinazione:

Il mirroring può richiedere da 10 a 20 minuti a seconda della connessione Internet, vedrai il nuovo elemento nell'elenco più avanti. È quindi possibile selezionare questo repository quando si ridimensiona o si distribuisce un nuovo cluster, senza che gli host del database dispongano di alcuna connessione a Internet (si noti che anche il repository offline del sistema operativo dovrebbe essere attivo).

Gestione utenti MySQL

Il sistema di privilegi MySQL garantisce che tutti gli utenti possano eseguire solo le operazioni a cui sono autorizzati. La concessione è fondamentale in quanto non si desidera concedere a tutti gli utenti l'accesso completo al database, ma è necessario che gli utenti dispongano delle autorizzazioni necessarie per eseguire query ed eseguire attività quotidiane.

ClusterControl fornisce un'interfaccia utente interattiva per gestire gli schemi ei privilegi del database. Unifica gli account su tutti i server MySQL nel cluster e semplifica il processo di concessione. Puoi visualizzare facilmente gli utenti del database, così eviti di commettere errori.

Come puoi vedere nello screenshot sopra, ClusterControl ha disattivato i privilegi non necessari se vuoi solo concedere un utente a un database (shopdb). "Richiedi SSL?" è abilitato solo se la crittografia SSL client/server è abilitata mentre le caselle di controllo dei privilegi di amministrazione sono totalmente disabilitate se è definito un database specifico. È inoltre possibile esaminare l'istruzione GRANT generata nella parte inferiore della procedura guidata per visualizzare l'istruzione che ClusterControl eseguirà per creare questo utente. Questo helper sembra piuttosto semplice, ma la creazione di utenti e la concessione di privilegi può essere soggetta a errori.

ClusterControl fornisce anche un elenco di utenti inattivi per tutti i nodi di database nel cluster, mostrando gli account che non sono stati utilizzati dall'ultimo riavvio del server:

Questo avverte l'amministratore della presenza di account non necessari che potrebbero potenzialmente danneggiare il server. Il passaggio successivo è verificare se gli account non sono più attivi e puoi semplicemente utilizzare l'opzione "Rimuovi utente selezionato" per rimuoverli. Assicurarsi di disporre di un'attività di database sufficiente per garantire che l'elenco generato da ClusterControl sia accurato. Più lungo è il tempo di attività del server, meglio è.

Rimani sempre aggiornato

Per l'uso in produzione, si consiglia vivamente di installare i pacchetti relativi al database dal repository del fornitore. Non fare affidamento sul repository del sistema operativo predefinito, dove i pacchetti sono generalmente obsoleti. Se stai utilizzando un ambiente cluster come Galera Cluster o anche MySQL Replication, hai sempre la possibilità di applicare patch al sistema con tempi di inattività minimi.

ClusterControl supporta l'aggiornamento automatico in sequenza delle versioni secondarie per MySQL/MariaDB con un solo clic. Vai su Gestisci -> Aggiornamenti -> Aggiorna e scegli la versione principale appropriata per il tuo cluster in esecuzione. ClusterControl eseguirà quindi l'aggiornamento, su un nodo alla volta. Il nodo verrà arrestato, quindi il software verrà aggiornato e quindi il nodo verrà riavviato. Se un nodo non riesce a eseguire l'aggiornamento, il processo di aggiornamento viene interrotto e l'amministratore viene avvisato. Gli aggiornamenti devono essere eseguiti solo quando c'è il minor traffico possibile sul cluster.

Gli aggiornamenti delle versioni principali (ad es. da MySQL 5.6 a MySQL 5.7) non sono intenzionalmente automatizzati. Gli aggiornamenti importanti di solito richiedono la disinstallazione dei pacchetti esistenti, che è un'attività rischiosa da automatizzare. Un'attenta pianificazione e test è necessaria per questo tipo di aggiornamenti.

La sicurezza del database è un aspetto importante dell'esecuzione del database in produzione. Da tutti gli incidenti di cui leggiamo spesso nei telegiornali (e probabilmente ce ne sono molti altri che non vengono pubblicizzati), è chiaro che ci sono gruppi indaffarati là fuori con cattive intenzioni. Quindi, assicurati che i tuoi database siano ben protetti.