Hoe Galera-cluster te beveiligen

Als gedistribueerd databasesysteem vereist Galera Cluster aanvullende beveiligingsmaatregelen in vergelijking met een gecentraliseerde database. Gegevens worden gedistribueerd over meerdere servers of zelfs datacenters misschien. Met aanzienlijke gegevenscommunicatie tussen knooppunten, kan er aanzienlijke blootstelling zijn als de juiste beveiligingsmaatregelen niet worden genomen.

In deze blogpost gaan we in op enkele tips om onze Galera Cluster te beveiligen. Merk op dat deze blog voortbouwt op onze vorige blogpost - Hoe u uw open source-databases kunt beveiligen met ClusterControl.

Firewall &Beveiligingsgroep

De volgende poorten zijn erg belangrijk voor een Galera Cluster:

3306 - MySQL
4567 - Galera communicatie en replicatie
4568 - Galera IST
4444 - Galera SST

Vanaf het externe netwerk is het aan te raden om alleen de toegang tot MySQL-poort 3306 te openen. De andere drie poorten kunnen worden afgesloten vanaf het externe netwerk en staan ze alleen toe voor interne toegang tussen de Galera-knooppunten. Als u een reverse proxy voor de Galera-knooppunten gebruikt, bijvoorbeeld HAProxy, kunt u de MySQL-poort vergrendelen voor openbare toegang. Zorg er ook voor dat de bewakingspoort voor het HAProxy-bewakingsscript is geopend. De standaardpoort is 9200 op de Galera-node.

Het volgende diagram illustreert onze voorbeeldconfiguratie op een Galera-cluster met drie knooppunten, met een HAProxy gericht op het openbare netwerk met de bijbehorende poorten:

Op basis van het bovenstaande diagram zijn de iptables-opdrachten voor databaseknooppunten:

$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 4444 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dports 4567:4568 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 9200 -j ACCEPT

Terwijl op de load balancer:

$ iptables -A INPUT -p tcp --dport 3307 -j ACCEPT

Zorg ervoor dat u uw firewallregels beëindigt met alles weigeren, zodat alleen verkeer zoals gedefinieerd in de uitzonderingsregels is toegestaan. U kunt strenger zijn en de opdrachten uitbreiden om uw beveiligingsbeleid te volgen, bijvoorbeeld door netwerkinterface, bestemmingsadres, bronadres, verbindingsstatus en wat niet toe te voegen.

MySQL Client-Server Encryptie

MySQL ondersteunt encryptie tussen de client en de server. Eerst moeten we het certificaat genereren. Eenmaal geconfigureerd, kunt u gebruikersaccounts afdwingen om bepaalde opties op te geven om met codering verbinding te maken met een MySQL-server.

De stappen vereisen dat u:

Maak een sleutel voor de certificeringsinstantie (ca-key.pem)
Genereer een zelfondertekend CA-certificaat (ca-cert.pem)
Maak een sleutel voor het servercertificaat (server-key.pem)
Genereer een certificaat voor de server en onderteken het met ca-key.pem (server-cert.pem)
Maak een sleutel voor het clientcertificaat (client-key.pem)
Genereer een certificaat voor de klant en onderteken het met ca-key.pem (client-cert.pem)

Wees altijd voorzichtig met de CA-privésleutel (ca-key.pem) - iedereen die er toegang toe heeft, kan deze gebruiken om extra client- of servercertificaten te genereren die als legitiem worden geaccepteerd wanneer CA-verificatie is ingeschakeld. Het komt erop neer dat alle sleutels discreet moeten worden bewaard.

U kunt dan de SSL-gerelateerde variabelen toevoegen onder [mysqld]-richtlijn, bijvoorbeeld:

ssl-ca=/etc/ssl/mysql/ca-cert.pem
ssl-cert=/etc/ssl/mysql/server-cert.pem
ssl-key=/etc/ssl/mysql/server-key.pem

Start de MySQL-server opnieuw om de wijzigingen te laden. Maak dan een gebruiker aan met het REQUIRE SSL statement, bijvoorbeeld:

mysql> GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'192.168.1.100' IDENTIFIED BY 'mySecr3t' REQUIRE SSL;

De gebruiker die is gemaakt met REQUIRE SSL wordt afgedwongen om verbinding te maken met de juiste client-SSL-bestanden (client-cert.pem, client-key.pem en ca-cert.pem).

Met ClusterControl kan client-server SSL-codering eenvoudig worden ingeschakeld vanuit de gebruikersinterface, met behulp van de functie "SSL-codering maken".

Galera-codering

Door versleuteling voor Galera in te schakelen, wordt IST ook versleuteld omdat de communicatie via dezelfde socket verloopt. SST daarentegen moet afzonderlijk worden geconfigureerd, zoals weergegeven in de volgende sectie. Alle knooppunten in het cluster moeten zijn ingeschakeld met SSL-codering en u kunt geen combinatie van knooppunten hebben waarbij sommige SSL-codering hebben ingeschakeld en andere niet. De beste tijd om dit te configureren is bij het opzetten van een nieuw cluster. Als u dit echter op een draaiend productiesysteem moet toevoegen, moet u het cluster helaas opnieuw opstarten en treedt er downtime op.

Alle Galera-knooppunten in het cluster moeten dezelfde sleutel, hetzelfde certificaat en dezelfde CA gebruiken (optioneel). U kunt ook dezelfde sleutel en hetzelfde certificaat gebruiken die zijn gemaakt voor MySQL-client-servercodering, of alleen voor dit doel een nieuwe set genereren. Om encryptie binnen Galera te activeren, moet men de optie en waarde toevoegen onder wsrep_provider_options in het MySQL-configuratiebestand op elk Galera-knooppunt. Beschouw bijvoorbeeld de volgende bestaande regel voor ons Galera-knooppunt:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0;"

Voeg de gerelateerde variabelen toe binnen het aanhalingsteken, gescheiden door een puntkomma:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0; socket.ssl_cert=/etc/mysql/cert.pem; socket.ssl_key=/etc/mysql/key.pem;"

Zie hier voor meer informatie over de SSL-gerelateerde parameters van Galera. Voer deze wijziging uit op alle knooppunten. Stop vervolgens het cluster (één knoop punt tegelijk) en bootstrap vanaf het laatste knoop punt dat is afgesloten. U kunt controleren of SSL correct is geladen door in het MySQL-foutlogboek te kijken:

2018-01-19T01:15:30.155211Z 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.10.61:,192.168.10.62:,192.168.10.63:'
2018-01-19T01:15:30.159654Z 0 [Note] WSREP: SSL handshake successful, remote endpoint ssl://192.168.10.62:53024 local endpoint ssl://192.168.10.62:4567 cipher: AES128-SHA compression:

Met ClusterControl kan Galera Replication-encryptie eenvoudig worden ingeschakeld met behulp van de functie "Create SSL Galera Encryption".

SST-codering

Wanneer SST plaatsvindt zonder codering, wordt de datacommunicatie zichtbaar terwijl het SST-proces aan de gang is. SST is een volledig gegevenssynchronisatieproces van een donor naar een joiner-knooppunt. Als een aanvaller de volledige gegevensoverdracht zou kunnen "zien", zou de persoon een volledige momentopname van uw database krijgen.

SST met codering wordt alleen ondersteund voor mysqldump- en xtrabackup-v2-methoden. Voor mysqldump moet de gebruiker "SSL VEREIST" krijgen op alle knooppunten en de configuratie is vergelijkbaar met de standaard MySQL client-server SSL-codering (zoals beschreven in de vorige sectie). Zodra de client-server-encryptie is geactiveerd, maakt u een nieuwe SST-gebruiker met SSL afgedwongen:

mysql> GRANT ALL ON *.* TO 'sst_user'@'%' IDENTIFIED BY 'mypassword' REQUIRE SSL;

Voor rsync raden we aan om galera-secure-rsync te gebruiken, een drop-in SSL-beveiligd rsync SST-script voor Galera Cluster. Het werkt bijna precies zoals wsrep_sst_rsync behalve dat het de feitelijke communicatie met SSL beveiligt met behulp van socat. Genereer de vereiste client-/serversleutel- en certificaatbestanden, kopieer ze naar alle knooppunten en specificeer de "secure_rsync" als de SST-methode in het MySQL-configuratiebestand om het te activeren:

wsrep_sst_method=secure_rsync

Voor xtrabackup moeten de volgende configuratie-opties zijn ingeschakeld in het MySQL-configuratiebestand onder [sst]-richtlijn:

[sst]
encrypt=4
ssl-ca=/path/to/ca-cert.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

Het opnieuw opstarten van de database is niet nodig. Als dit knooppunt door Galera als donor wordt geselecteerd, worden deze configuratie-opties automatisch opgehaald wanneer Galera de SST start.

SELinux

Security-Enhanced Linux (SELinux) is een toegangscontrolemechanisme dat in de kernel is geïmplementeerd. Zonder SELinux worden alleen traditionele methoden voor toegangscontrole, zoals bestandsrechten of ACL, gebruikt om de bestandstoegang van gebruikers te regelen.

Als de strikte handhavingsmodus is ingeschakeld, wordt standaard alles geweigerd en moet de beheerder een reeks uitzonderingen maken voor de elementen van het systeem die nodig zijn om te kunnen functioneren. Het volledig uitschakelen van SELinux is tegenwoordig een slechte gewoonte geworden voor veel RedHat-gebaseerde installaties.

Afhankelijk van de workloads, gebruikspatronen en processen, is de beste manier om uw eigen SELinux-beleidsmodule te maken die is afgestemd op uw omgeving. Wat je echt moet doen is SELinux in de permissieve modus zetten (alleen loggen zonder afdwingen), en gebeurtenissen activeren die kunnen gebeuren op een Galera-knooppunt zodat SELinux kan loggen. Hoe uitgebreider hoe beter. Voorbeeldevenementen zoals:

Knooppunt starten als donateur of deelnemer
Herstart node om IST te activeren
Gebruik verschillende SST-methoden
Back-up en herstel MySQL-databases met mysqldump of xtrabackup
Binaire logboeken in- en uitschakelen

Een voorbeeld is dat als het Galera-knooppunt wordt bewaakt door ClusterControl en de functie voor het bewaken van query's is ingeschakeld, ClusterControl de logvariabele langzame query's in-/uitschakelt om de langzaam lopende query's vast te leggen. U ziet dus de volgende weigering in de audit.log:

$ grep -e denied audit/audit.log | grep -i mysql
type=AVC msg=audit(1516835039.802:37680): avc:  denied  { open } for  pid=71222 comm="mysqld" path="/var/log/mysql/mysql-slow.log" dev="dm-0" ino=35479360 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

Het idee is om alle mogelijke weigeringen te laten loggen in het auditlogboek, dat later kan worden gebruikt om de beleidsmodule te genereren met behulp van audit2allow voordat u het in SELinux laadt. Codership heeft dit in detail behandeld op de documentatiepagina, SELinux Configuration.

SST-account en privileges

SST is een initieel synchronisatieproces uitgevoerd door Galera. Het brengt een joiner-knooppunt up-to-date met de rest van de leden in het cluster. Het proces exporteert in feite de gegevens van het donorknooppunt en herstelt het op het joiner-knooppunt, voordat de joiner de resterende transacties uit de wachtrij mag inhalen (d.w.z. de transacties die tijdens het synchronisatieproces zijn gebeurd). Er worden drie SST-methoden ondersteund:

mysqldump
rsync
xtrabackup (of xtrabackup-v2)

Voor gebruik van mysqldump SST zijn de volgende rechten vereist:

SELECTEER, WEERGAVE TONEN, TRIGGER, TABELLEN VERGRENDELEN, HERLADEN, BESTAND

We gaan niet verder met mysqldump omdat het waarschijnlijk niet vaak wordt gebruikt in de productie als SST-methode. Daarnaast is het een blokkeringsprocedure voor de donor. Rsync is meestal een tweede keuze na xtrabackup vanwege de snellere synchronisatietijd en minder foutgevoelig in vergelijking met mysqldump. SST-authenticatie wordt genegeerd met rsync, daarom kunt u het configureren van SST-accountprivileges overslaan als rsync de gekozen SST-methode is.

Naast xtrabackup worden de volgende privileges geadviseerd voor standaard back-up- en herstelprocedures op basis van de Xtrabackup-documentatiepagina:

CREER, MAAK TAFELRUIMTE, EVENEMENT, INVOEGEN, TABEL VERGRENDELEN, VERWERKEN, HERLADEN, REPLICATIECLIENT, SELECTEREN, WEERGAVE TONEN, SUPER

Voor het SST-gebruik van xtrabackup zijn echter alleen de volgende privileges van belang:

VERWERKEN, HERLADEN, REPLICATIECLIENT

De GRANT-instructie voor SST kan dus worden geminimaliseerd als:

mysql> GRANT PROCESS,RELOAD,REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY '[email protected]@sTr0nG%%P4ssW0rD';

Configureer vervolgens wsrep_sst_auth dienovereenkomstig in het MySQL-configuratiebestand:

wsrep_sst_auth = sstuser:[email protected]@sTr0nG%%P4ssW0rD

Verleen alleen de SST-gebruiker voor localhost en gebruik een sterk wachtwoord. Vermijd het gebruik van root-gebruiker als het SST-account, omdat dit het root-wachtwoord in het configuratiebestand onder deze variabele zou blootleggen. Bovendien zou het wijzigen of resetten van het MySQL-rootwachtwoord in de toekomst SST verbreken.

MySQL-beveiligingshardening

Galera Cluster is een multi-master replicatie-plug-in voor de InnoDB-opslagengine, die draait op MySQL- en MariaDB-vorken. Daarom zijn de standaard aanbevelingen voor MySQL/MariaDB/InnoDB-beveiliging ook van toepassing op Galera Cluster.

Dit onderwerp is behandeld in talloze blogposts die er zijn. We hebben dit onderwerp ook behandeld in de volgende blogposts:

Tien tips voor het bereiken van MySQL- en MariaDB-beveiliging
ClusterControl-tips en -trucs:uw MySQL-installatie beveiligen
Hoe u uw open source-databases kunt beveiligen met ClusterControl

De bovenstaande blogposts vatten de noodzaak samen van het versleutelen van data in rust en data in transit, het hebben van audit-plugins, algemene beveiligingsrichtlijnen, best practices voor netwerkbeveiliging, enzovoort.

Gebruik een load balancer

Er zijn een aantal database load balancers (reverse proxy) die samen met Galera kunnen worden gebruikt - HAProxy, ProxySQL en MariaDB MaxScale om er enkele te noemen. U kunt een load balancer instellen om de toegang tot uw Galera-knooppunten te regelen. Het is een geweldige manier om de database-workload tussen de database-instances te verdelen en de toegang te beperken, bijvoorbeeld als u een node offline wilt halen voor onderhoud, of als u het aantal geopende verbindingen op de Galera-knooppunten wilt beperken. De load balancer zou in staat moeten zijn verbindingen in de wachtrij te plaatsen en daarom enige bescherming tegen overbelasting te bieden aan uw databaseservers.

ProxySQL, een krachtige database-reverse-proxy die MySQL en MariaDB begrijpt, kan worden uitgebreid met veel handige beveiligingsfuncties, zoals een query-firewall, om aanstootgevende query's van de databaseserver te blokkeren. De queryregels-engine kan ook worden gebruikt om slechte query's te herschrijven naar iets beters/veiliger, of om ze om te leiden naar een andere server die de belasting kan absorberen zonder een van de Galera-knooppunten te beïnvloeden. MariaDB MaxScale is ook in staat om query's te blokkeren op basis van reguliere expressies met zijn Database Firewall-filter.

Een ander voordeel van een load balancer voor uw Galera-cluster is de mogelijkheid om een dataservice te hosten zonder de databaselaag bloot te stellen aan het openbare netwerk. De proxyserver kan worden gebruikt als bastionhost om toegang te krijgen tot de databaseknooppunten in een particulier netwerk. Door het databasecluster te isoleren van de buitenwereld, heeft u een van de belangrijke aanvalsvectoren verwijderd.

Dat is het. Blijf altijd veilig en beschermd.

Hoe Galera-cluster te beveiligen - 8 tips