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

Come proteggere il server ClusterControl

Nel nostro precedente post sul blog, ti abbiamo mostrato come puoi proteggere i tuoi database open source con ClusterControl. Ma che dire del server ClusterControl stesso? Come lo proteggiamo? Questo sarà l'argomento del blog di oggi. Presumiamo che l'host sia destinato esclusivamente all'utilizzo di ClusterControl, senza altre applicazioni in esecuzione su di esso.

Gruppo firewall e sicurezza

Innanzitutto, dovremmo chiudere tutte le porte non necessarie e aprire solo le porte necessarie utilizzate da ClusterControl. Internamente, tra ClusterControl ei server di database, conta solo la porta netcat, dove la porta predefinita è 9999. Questa porta deve essere aperta solo se si desidera archiviare il backup sul server ClusterControl. Altrimenti, puoi chiuderlo.

Dalla rete esterna, si consiglia di aprire l'accesso solo a HTTP (80) o HTTPS (443) per l'interfaccia utente di ClusterControl. Se stai eseguendo la CLI ClusterControl denominata 's9s', l'endpoint CMON-TLS deve essere aperto sulla porta 9501. È anche possibile installare applicazioni relative al database sopra il server ClusterControl, come HAProxy, Keepalived, ProxySQL e simili. In tal caso, devi anche aprire le porte necessarie anche per questi. Fare riferimento alla pagina della documentazione per un elenco di porte per ciascun servizio.

Per impostare le regole del firewall tramite iptables, sul nodo ClusterControl, eseguire:

$ iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 9501 -j ACCEPT
$ iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

Quanto sopra sono i comandi più semplici. Puoi essere più severo ed estendere i comandi per seguire la tua politica di sicurezza, ad esempio aggiungendo l'interfaccia di rete, l'indirizzo di destinazione, l'indirizzo di origine, lo stato della connessione e altro.

Simile all'esecuzione della configurazione nel cloud, il seguente è un esempio di regole del gruppo di sicurezza in entrata per il server ClusterControl su AWS:

Diversi provider di servizi cloud forniscono diverse implementazioni di gruppi di sicurezza, ma le regole di base sono simili.

Crittografia

ClusterControl supporta la crittografia delle comunicazioni a diversi livelli, per garantire che le attività di automazione, monitoraggio e gestione vengano eseguite nel modo più sicuro possibile.

In esecuzione su HTTPS

Lo script di installazione (install-cc.sh) configurerà per impostazione predefinita un certificato SSL autofirmato per l'utilizzo di HTTPS. Se scegli questo metodo di accesso come endpoint principale, puoi bloccare il semplice servizio HTTP in esecuzione sulla porta 80 dalla rete esterna. Tuttavia, ClusterControl richiede ancora un accesso a CMONAPI (un'interfaccia Rest-API legacy) che viene eseguita per impostazione predefinita sulla porta 80 sull'host locale. Se desideri bloccare completamente la porta HTTP, assicurati di modificare l'URL dell'API ClusterControl in Registrazioni cluster pagina per utilizzare invece HTTPS:

Il certificato autofirmato configurato da ClusterControl ha una validità di 10 anni (3650 giorni). Puoi verificare la validità del certificato utilizzando il comando seguente (sul server CentOS 7):

$  openssl x509 -in /etc/ssl/certs/s9server.crt -text -noout
...
        Validity
            Not Before: Apr  9 21:22:42 2014 GMT
            Not After : Mar 16 21:22:42 2114 GMT
...

Tieni presente che il percorso assoluto del file del certificato potrebbe essere diverso a seconda del sistema operativo.

Crittografia client-server MySQL

ClusterControl archivia i dati di monitoraggio e gestione all'interno dei database MySQL sul nodo ClusterControl. Poiché MySQL stesso supporta la crittografia SSL client-server, ClusterControl è in grado di utilizzare questa funzione per stabilire una comunicazione crittografata con il server MySQL durante la scrittura e il recupero dei dati.

A tale scopo sono supportate le seguenti opzioni di configurazione:

  • cmondb_ssl_key - percorso della chiave SSL, per la crittografia SSL tra CMON e il DB CMON.
  • cmondb_ssl_cert - percorso al certificato SSL, per la crittografia SSL tra CMON e il DB CMON
  • cmondb_ssl_ca - percorso verso SSL CA, per la crittografia SSL tra CMON e il DB CMON

Abbiamo trattato i passaggi di configurazione in questo post del blog qualche tempo fa.

C'è un problema però. Al momento della scrittura, l'interfaccia utente di ClusterControl presenta una limitazione nell'accesso a CMON DB tramite SSL utilizzando l'utente cmon. Come soluzione alternativa, creeremo un altro utente di database per ClusterControl UI e ClusterControl CMONAPI chiamato cmonui. Questo utente non avrà SSL abilitato nella sua tabella dei privilegi.

mysql> GRANT ALL PRIVILEGES ON *.* TO 'cmonui'@'127.0.0.1' IDENTIFIED BY '<cmon password>';
mysql> FLUSH PRIVILEGES;

Aggiorna i file di configurazione ClusterControl UI e CMONAPI che si trovano in clustercontrol/bootstrap.php e cmonapi/config/database.php rispettivamente con l'utente database appena creato, cmonui :

# <wwwroot>/clustercontrol/bootstrap.php
define('DB_LOGIN', 'cmonui');
define('DB_PASS', '<cmon password>');
# <wwwroot>/cmonapi/config/database.php
define('DB_USER', 'cmonui');
define('DB_PASS', '<cmon password>');

Questi file non verranno sostituiti quando esegui un aggiornamento tramite il gestore pacchetti.

Crittografia CLI

ClusterControl include anche un'interfaccia a riga di comando chiamata 's9s'. Questo client analizza le opzioni della riga di comando e invia un lavoro specifico al servizio del controller in ascolto sulla porta 9500 (CMON) o 9501 (CMON con TLS). Quest'ultimo è quello consigliato. Lo script di installazione per impostazione predefinita configurerà s9s CLI per utilizzare 9501 come porta endpoint del server ClusterControl.

Controllo dell'accesso basato sul ruolo

ClusterControl utilizza Role-Based Access Control (RBAC) per limitare l'accesso ai cluster e alle rispettive funzionalità di distribuzione, gestione e monitoraggio. Ciò garantisce che siano consentite solo le richieste degli utenti autorizzati. L'accesso alle funzionalità è a grana fine, consentendo di definire l'accesso in base all'organizzazione o all'utente. ClusterControl utilizza un framework di autorizzazioni per definire come un utente può interagire con la funzionalità di gestione e monitoraggio, dopo che è stato autorizzato a farlo.

È possibile accedere all'interfaccia utente RBAC tramite ClusterControl -> Gestione utenti -> Controllo accessi :

Tutte le funzionalità sono autoesplicative, ma se desideri una descrizione aggiuntiva, controlla la pagina della documentazione.

Se hai più utenti coinvolti nell'operazione del cluster di database, si consiglia vivamente di impostare i controlli di accesso per loro di conseguenza. Puoi anche creare più team (organizzazioni) e assegnarli con zero o più cluster.

In esecuzione su porte personalizzate

ClusterControl può essere configurato per utilizzare porte personalizzate per tutti i servizi dipendenti. ClusterControl utilizza SSH come canale di comunicazione principale per gestire e monitorare i nodi in remoto, Apache per servire l'interfaccia utente di ClusterControl e anche MySQL per archiviare i dati di monitoraggio e gestione. Puoi eseguire questi servizi su porte personalizzate per ridurre il vettore di attacco. Le seguenti porte sono le solite destinazioni:

  • SSH:il valore predefinito è 22
  • HTTP:il valore predefinito è 80
  • HTTPS:il valore predefinito è 443
  • MySQL:l'impostazione predefinita è 3306

Ci sono diverse cose che è necessario modificare per eseguire i servizi precedenti su porte personalizzate affinché ClusterControl funzioni correttamente. Ne abbiamo parlato in dettaglio nella pagina della documentazione, Esecuzione su porta personalizzata.

Autorizzazione e proprietà

I file di configurazione di ClusterControl contengono informazioni riservate e devono essere mantenuti discreti e ben protetti. I file devono essere consentiti solo all'utente/gruppo root, senza autorizzazione di lettura ad altri. Nel caso in cui l'autorizzazione e la proprietà siano state impostate in modo errato, il seguente comando aiuta a ripristinarle allo stato corretto:

$ chown root:root /etc/cmon.cnf /etc/cmon.d/*.cnf
$ chmod 700 /etc/cmon.cnf /etc/cmon.d/*.cnf

Per il servizio MySQL, assicurati che il contenuto della directory dei dati MySQL sia consentito al gruppo "mysql" e che l'utente possa essere "mysql" o "root":

$ chown -Rf mysql:mysql /var/lib/mysql

Per ClusterControl UI, la proprietà deve essere consentita all'utente Apache, "apache" per RHEL/CentOS o "www-data" per OS basato su Debian.

La chiave SSH per la connessione agli host del database è un altro aspetto molto importante, poiché contiene l'identità e deve essere conservata con autorizzazioni e proprietà adeguate. Inoltre, SSH non consentirà l'utilizzo di un file di chiave non protetto durante l'avvio della chiamata remota. Verificare che il file della chiave SSH utilizzato dal cluster, all'interno dei file di configurazione generati nella directory /etc/cmon.d/, sia impostato su consentito per osuser solo opzione. Ad esempio, considera osuser è "ubuntu" e il file chiave è /home/ubuntu/.ssh/id_rsa:

$ chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa
$ chmod 700 /home/ubuntu/.ssh/id_rsa

Utilizza una password complessa

Se si utilizza lo script del programma di installazione per installare ClusterControl, si consiglia di utilizzare una password complessa quando richiesto dal programma di installazione. Ci sono al massimo due account che lo script di installazione dovrà configurare (a seconda della configurazione):

  • Password MySQL cmon - Il valore predefinito è 'cmon'.
  • Password root MySQL - Il valore predefinito è 'password'.

È responsabilità dell'utente utilizzare password complesse in questi due account. Lo script di installazione supporta un sacco di caratteri speciali per l'immissione della password, come menzionato nella procedura guidata di installazione:

=> Set a password for ClusterControl's MySQL user (cmon) [cmon]
=> Supported special password characters: [email protected]#$%^&*()_+{}<>?

Verifica il contenuto di /etc/cmon.cnf e /etc/cmon.d/cmon_*.cnf e assicurati di utilizzare una password complessa quando possibile.

Modifica della password MySQL 'cmon'

Se la password configurata non soddisfa i criteri per la password, per modificare la password MySQL cmon, è necessario eseguire diversi passaggi:

  1. Modificare la password all'interno del server MySQL di ClusterControl:

    $ ALTER USER 'cmon'@'127.0.0.1' IDENTIFIED BY 'newPass';
$ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
$ FLUSH PRIVILEGES;

  2. Aggiorna tutte le occorrenze delle opzioni 'mysql_password' per il servizio del controller all'interno di /etc/cmon.cnf e /etc/cmon.d/*.cnf:

    mysql_password=newPass

  3. Aggiorna tutte le occorrenze delle costanti 'DB_PASS' per l'interfaccia utente di ClusterControl all'interno di /var/www/html/clustercontrol/bootstrap.php e /var/www/html/cmonapi/config/database.php:

    # <wwwroot>/clustercontrol/bootstrap.php
define('DB_PASS', 'newPass');
    # <wwwroot>/cmonapi/config/database.php
define('DB_PASS', 'newPass');

  4. Cambia la password su ogni server MySQL monitorato da ClusterControl:

    $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
$ FLUSH PRIVILEGES;

  5. Riavvia il servizio CMON per applicare le modifiche:

    $ service cmon restart # systemctl restart cmon

Verifica se il processo cmon è stato avviato correttamente esaminando /var/log/cmon.log. Assicurati di avere qualcosa come di seguito:

2018-01-11 08:33:09 : (INFO) Additional RPC URL for events: 'http://127.0.0.1:9510'
2018-01-11 08:33:09 : (INFO) Configuration loaded.
2018-01-11 08:33:09 : (INFO) cmon 1.5.1.2299
2018-01-11 08:33:09 : (INFO) Server started at tcp://127.0.0.1:9500
2018-01-11 08:33:09 : (INFO) Server started at tls://127.0.0.1:9501
2018-01-11 08:33:09 : (INFO) Found 'cmon' schema version 105010.
2018-01-11 08:33:09 : (INFO) Running cmon schema hot-fixes.
2018-01-11 08:33:09 : (INFO) Schema auto-upgrade succeed (version 105010).
2018-01-11 08:33:09 : (INFO) Checked tables - seems ok
2018-01-11 08:33:09 : (INFO) Community version
2018-01-11 08:33:09 : (INFO) CmonCommandHandler: started, polling for commands.

Eseguirlo offline

Risorse correlate Annuncio di ClusterControl 1.5.1 - Con crittografia di backup per MySQL, MongoDB e PostgreSQL Conformità PCI per MySQL e MariaDB con ClusterControl Come proteggere i server MySQL/MariaDB

ClusterControl è in grado di gestire la tua infrastruttura di database in un ambiente senza accesso a Internet. Alcune funzionalità non funzionerebbero in quell'ambiente (backup su cloud, distribuzione tramite repository pubblici, aggiornamenti), le funzionalità principali sono presenti e funzionerebbero perfettamente. Puoi anche scegliere di distribuire inizialmente tutto con Internet, quindi interrompere Internet una volta che l'installazione è stata testata e pronta per servire i dati di produzione.

Avendo ClusterControl e il cluster di database isolati dal mondo esterno, hai eliminato uno degli importanti vettori di attacco.

Riepilogo

ClusterControl può aiutare a proteggere il tuo cluster di database ma non viene protetto da solo. I team operativi devono assicurarsi che il server ClusterControl sia protetto anche dal punto di vista della sicurezza.