Il cloud ibrido può essere un ottimo modo per aggiungere flessibilità alle tue implementazioni on-premise esistenti. Come abbiamo discusso in diversi blog, il cloud pubblico può essere un'ottima aggiunta al tuo data center, assicurandoti di poter facilmente scalare per gestire il carico, ridurre i tuoi investimenti ed essere utilizzato per implementare procedure di ripristino di emergenza. La sicurezza è un altro aspetto su cui devi riflettere quando pianifichi di costruire tali sistemi. In questo post del blog parleremo di alcune considerazioni sulla sicurezza per le distribuzioni di MariaDB nel cloud ibrido.
Connettività
VPN
La parte principale di ogni infrastruttura ibrida è la rete. Dopotutto, stiamo parlando di due ambienti, locale, on-premise e un cloud pubblico, che devono essere connessi e formare un'unica entità. La connessione deve essere crittografata. Come affrontarlo, ci sono molti modi per farlo.
Uno di questi sarebbe l'utilizzo di una soluzione resa disponibile dal provider di servizi cloud:la maggior parte di essi dispone di una sorta di opzione di connettività disponibile. Può essere AWS Direct Connect se ti capita di integrarti con Amazon Web Services. Se prevedi di utilizzare Google Cloud, le soluzioni sono discusse sul seguente sito Web:https://cloud.google.com/hybrid-connectivity. In breve, esiste un numero significativo di diverse opzioni che variano dall'integrazione VPN hardware alla configurazione del peering BGP.
Dall'altro lato dello spettro, abbiamo soluzioni software VPN. OpenVPN o un tipo simile di software può essere utilizzato per configurare una connessione di rete sicura e crittografata tra il tuo data center e il cloud pubblico. In tal caso è necessaria un'istanza separata in esecuzione nel cloud pubblico che verrà utilizzata per il server VPN. L'utilizzo di VPN software ti consente di scegliere la soluzione più adatta alle tue esigenze e che si adatta meglio al tuo ambiente.
Firewall
I database non dovrebbero mai essere accessibili da reti esterne. È fondamentale creare l'ambiente in modo che il livello del database sia raggiungibile solo dal set limitato di host. Esattamente cosa è richiesto e come farlo, sta a te decidere. Una configurazione tipica consisterebbe in un livello di database protetto a cui è possibile accedere solo dal livello proxy e, se necessario, dovrebbe essere implementato una sorta di jump host se necessario per attività di automazione e amministrazione.
I server delle applicazioni non dovrebbero avere accesso diretto al database, non è necessario. Tutto ciò che l'applicazione dovrebbe fare è connettersi al servizio di bilanciamento del carico. I servizi di bilanciamento del carico dovrebbero essere in grado di connettersi al database. Un sistema di bilanciamento del carico come ProxySQL è perfettamente in grado di eseguire la suddivisione in lettura/scrittura e di inviare letture e scritture ai nodi del database corretti. L'applicazione dovrebbe essere in grado di connettersi a ProxySQL e il resto sarà gestito dal proxy:autenticazione del database, modellamento del traffico, distribuzione del traffico tra numerose repliche che potresti avere. Tutti gli accessi non necessari dovrebbero essere limitati. Gruppi di sicurezza, firewall:questi sono gli strumenti che desideri utilizzare per proteggere il tuo ambiente.
In breve, l'accesso agli host del database dovrebbe essere consentito solo sulle porte richieste. Per MariaDB sarà, ovviamente, una porta utilizzata per il database ma anche altre porte se necessario:potresti avere una sorta di esportatore o agente installato. Per Galera, dovresti aprire le porte per la comunicazione all'interno del cluster. Potresti anche voler avere una porta aperta per le connessioni SSH. Idealmente, limitare l'accesso in base all'host; solo un insieme limitato di host può accedere a una determinata porta. Ad esempio, la porta del database potrebbe essere accessibile dagli altri nodi del database, localhost e livello proxy. Non è necessario tenerlo aperto per altri nodi. I nodi del tuo database potrebbero anche trovarsi su una sottorete separata, assicurando che la sicurezza sia ancora più stretta.
Per quanto riguarda le porte, le migliori pratiche sarebbero cambiarle dalle impostazioni predefinite a qualcos'altro. Idealmente, qualcosa di casuale. La modifica della porta SSH da 22 a 2222 o della porta MariaDB da 3306 a 33306 può aiutare a evitare alcuni degli attacchi automatizzati, ma è comunque possibile capire se qualcuno sta cercando attivamente di entrare nella tua rete. Se vuoi una maggiore sicurezza, puoi semplicemente andare avanti con alcuni valori casuali. Imposta SSH su 5762 e MariaDB su 24359. È molto probabile che nessuno sia in grado di indovinarli. Imposta i timeout TCP in modo che le scansioni delle porte siano molto lunghe e costose e questo aumenterà sicuramente le tue possibilità.
SSL
Oltre a VPN e firewall, dovresti assicurarti che il traffico del tuo database sia crittografato tramite SSL.
Idealmente, proteggerai sia le connessioni frontend (dai sistemi di bilanciamento del carico) che la comunicazione tra i nodi del database (che si tratti di replica o trasferimento intra-cluster nei cluster Galera). ClusterControl può aiutarti ad abilitare queste opzioni con pochi clic.
Tutto quello che devi fare è lasciare che ClusterControl crei nuovi certificati o utilizzi uno di quelli esistenti - puoi importare il tuo certificato se vuoi. Avere SSL abilitato garantisce che il traffico del database non sarà leggibile nemmeno da qualcuno che ha ottenuto l'accesso alla tua rete.
Sicurezza database
Naturalmente, la rete non è l'unico aspetto importante della sicurezza. Sì, è fondamentale, soprattutto nell'ambiente cloud ibrido, ma ci sono anche altri aspetti molto importanti. Uno di questi è il controllo di accesso incorporato in MariaDB.
Controllo dell'accesso basato sui ruoli per MariaDB
MariaDB viene fornito con una serie di strumenti per garantire che l'accesso al database sia gestito correttamente e limitato ovunque sia richiesto. La prima linea di autenticazione è costituita dagli utenti. Tutti e tutto ciò che è autorizzato ad accedere a MariaDB dovrebbe utilizzare un utente assegnato per connettersi al database. Tali utenti avranno una password corretta:puoi abilitare la convalida della password in MariaDB per assicurarti che le password siano sufficientemente forti. Idealmente, limiteresti l'host di accesso dell'utente solo ai nomi host o agli IP dei sistemi di bilanciamento del carico:questo dovrebbe sempre essere il modo in cui gli utenti si connettono al database. Per alcuni utenti amministrativi, potresti voler mantenere l'accesso a localhost, se necessario. Oltre a imporre la corretta sicurezza della password, puoi configurare la scadenza della password entro un certo periodo di tempo o imporre la rotazione della password agli utenti. Come puoi immaginare, una corretta politica di rotazione delle password è qualcosa che vorresti aver implementato.
Ogni utente in MariaDB può avere più privilegi assegnati. I privilegi possono essere assegnati a diversi livelli:livello globale, livello database, livello tabella o persino livello colonna. La migliore pratica consiste nel concedere un insieme limitato di privilegi agli utenti possibile. Se l'utente richiede solo l'accesso a una tabella particolare, concediglielo. Non è necessario che quell'utente acceda ad altre tabelle per non parlare di altri schemi. È possibile definire diritti di accesso abbastanza dettagliati utilizzando un ampio set di privilegi che è possibile concedere agli utenti. Si va dai diritti di lettura, aggiornamento o eliminazione dei dati attraverso i privilegi di gestione del database fino al privilegio "super" che consente all'utente di eseguire azioni come la gestione dei thread di replica e bypassare l'impostazione di sola lettura.
Inoltre, MariaDB è dotato di ruoli:per semplificare la gestione degli utenti è possibile definire ruoli con un determinato insieme di privilegi concessi e quindi assegnare tali ruoli agli utenti. Tali utenti erediteranno le sovvenzioni relative al ruolo a cui sono stati assegnati, semplificando la gestione delle sovvenzioni su larga scala:invece di modificare le assegnazioni per più utenti, puoi assegnarli a un ruolo specifico e quindi gestire tutti i loro privilegi tramite alterando i privilegi concessi al ruolo a cui sono stati assegnati.
Dovresti anche assicurarti di non avere utenti preesistenti senza una password assegnata o con un insieme troppo ampio di privilegi. Tale audit di sicurezza dovrebbe essere eseguito di tanto in tanto, assicurando che tu sia consapevole dei potenziali rischi per la sicurezza e che tu possa pianificare di agire su di essi.
Registro di controllo
Se il tuo database viene fornito con un registro di controllo, proprio come fa MariaDB, dovresti considerare di usarlo per tenere traccia delle azioni che stanno accadendo nel database. Il registro di controllo ti aiuterà a farlo. Con esso abilitato sarai in grado di tracciare anche i dettagli come quale utente ha eseguito quale query. Se ti capita di utilizzare ClusterControl puoi abilitare l'audit log solo con un paio di clic:
Per riassumere questo blog, ci sono un paio di cose che dovresti considerare quando progetti una distribuzione MariaDB nell'ambiente cloud ibrido. Alcuni di essi sono strettamente correlati al modo in cui è progettato l'ambiente, altri sono praticamente correlati al tipo di database che utilizzi e il fatto che utilizzi il cloud ibrido non cambia molto. Ciò che è veramente importante è garantire che il database sia adeguatamente protetto:questo è l'obiettivo finale, indipendentemente dall'ambiente.
