Sådan sikrer du Galera Cluster

Som et distribueret databasesystem kræver Galera Cluster yderligere sikkerhedsforanstaltninger sammenlignet med en centraliseret database. Data distribueres på tværs af flere servere eller endda datacentre måske. Med betydelig datakommunikation, der foregår på tværs af noder, kan der være betydelig eksponering, hvis de passende sikkerhedsforanstaltninger ikke træffes.

I dette blogindlæg skal vi se på nogle tips til, hvordan du sikrer vores Galera-klynge. Bemærk, at denne blog bygger på vores tidligere blogindlæg - Sådan sikrer du dine Open Source-databaser med ClusterControl.

Firewall- og sikkerhedsgruppe

Følgende porte er meget vigtige for en Galera Cluster:

3306 - MySQL
4567 - Galera-kommunikation og replikering
4568 - Galera IST
4444 - Galera SST

Fra det eksterne netværk anbefales det kun at åbne adgang til MySQL port 3306. De tre andre porte kan lukkes ned fra det eksterne netværk, og giver dem kun mulighed for intern adgang mellem Galera noderne. Hvis du kører en omvendt proxy, der sidder foran Galera-noderne, for eksempel HAProxy, kan du låse MySQL-porten fra offentlig adgang. Sørg også for, at overvågningsporten for HAProxy-overvågningsscriptet er åben. Standardporten er 9200 på Galera-knuden.

Følgende diagram illustrerer vores eksempelopsætning på en Galera-klynge med tre knudepunkter, med en HAProxy vendt mod det offentlige netværk med dets relaterede porte:

Baseret på ovenstående diagram er iptables-kommandoerne for databasenoder:

$ 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

Mens du er på belastningsbalanceren:

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

Sørg for at afslutte dine firewallregler med deny all, så kun trafik som defineret i undtagelsesreglerne er tilladt. Du kan være strengere og udvide kommandoerne for at følge din sikkerhedspolitik - for eksempel ved at tilføje netværksgrænseflade, destinationsadresse, kildeadresse, forbindelsestilstand og hvad ikke.

MySQL Client-Server Kryptering

MySQL understøtter kryptering mellem klienten og serveren. Først skal vi generere certifikatet. Når den er konfigureret, kan du gennemtvinge brugerkonti til at angive visse muligheder for at forbinde med kryptering til en MySQL-server.

Trinnene kræver, at du:

Opret en nøgle til Certificate Authority (ca-key.pem)
Generer et selvsigneret CA-certifikat (ca-cert.pem)
Opret en nøgle til servercertifikat (server-key.pem)
Generer et certifikat til serveren og signer det med ca-key.pem (server-cert.pem)
Opret en nøgle til klientcertifikat (client-key.pem)
Generer et certifikat til klienten, og underskriv det med ca-key.pem (client-cert.pem)

Vær altid forsigtig med CA's private nøgle (ca-key.pem) - alle med adgang til den kan bruge den til at generere yderligere klient- eller servercertifikater, der vil blive accepteret som legitime, når CA-verifikation er aktiveret. Den nederste linje er, at alle nøgler skal holdes diskrete.

Du kan derefter tilføje de SSL-relaterede variabler under [mysqld]-direktivet, for eksempel:

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

Genstart MySQL-serveren for at indlæse ændringerne. Opret derefter en bruger med REQUIRE SSL-sætningen, for eksempel:

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

Brugeren oprettet med REQUIRE SSL vil blive tvunget til at oprette forbindelse til de korrekte klient-SSL-filer (client-cert.pem, client-key.pem og ca-cert.pem).

Med ClusterControl kan klient-server SSL-kryptering nemt aktiveres fra brugergrænsefladen ved hjælp af funktionen "Opret SSL-kryptering".

Galera-kryptering

Aktivering af kryptering for Galera betyder, at IST også bliver krypteret, fordi kommunikationen sker via den samme socket. SST skal på den anden side konfigureres separat som vist i næste afsnit. Alle noder i klyngen skal være aktiveret med SSL-kryptering, og du kan ikke have en blanding af noder, hvor nogle har aktiveret SSL-kryptering, og andre ikke. Det bedste tidspunkt at konfigurere dette på er, når du opsætter en ny klynge. Men hvis du har brug for at tilføje dette på et kørende produktionssystem, bliver du desværre nødt til at genstarte klyngen, og der vil være nedetid.

Alle Galera-noder i klyngen skal bruge samme nøgle, certifikat og CA (valgfrit). Du kan også bruge den samme nøgle og det samme certifikat, der er oprettet til MySQL-klient-server-kryptering, eller du kan kun generere et nyt sæt til dette formål. For at aktivere kryptering inde i Galera, skal man tilføje indstillingen og værdien under wsrep_provider_options inde i MySQL-konfigurationsfilen på hver Galera-node. Overvej f.eks. følgende eksisterende linje for vores Galera-node:

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

Tilføj de relaterede variabler i citatet, afgrænset af et semikolon:

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

For mere info om Galeras SSL-relaterede parametre, se her. Udfør denne ændring på alle noder. Stop derefter klyngen (en node ad gangen) og start fra den sidste node, der lukkede ned. Du kan kontrollere, om SSL er indlæst korrekt ved at se i MySQL-fejlloggen:

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:

Med ClusterControl kan Galera-replikeringskryptering nemt aktiveres ved hjælp af funktionen "Opret SSL Galera-kryptering".

SST-kryptering

Når SST sker uden kryptering, afsløres datakommunikationen, mens SST-processen er i gang. SST er en fuld datasynkroniseringsproces fra en donor til en joiner node. Hvis en angriber var i stand til at "se" den fulde datatransmission, ville personen få et komplet øjebliksbillede af din database.

SST med kryptering understøttes kun for mysqldump og xtrabackup-v2 metoder. For mysqldump skal brugeren have "KRÆV SSL" på alle noder, og konfigurationen ligner standard MySQL klient-server SSL-kryptering (som beskrevet i det foregående afsnit). Når klient-server-krypteringen er aktiveret, skal du oprette en ny SST-bruger med SSL håndhævet:

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

Til rsync anbefaler vi at bruge galera-secure-rsync, et drop-in SSL-sikret rsync SST-script til Galera Cluster. Det fungerer næsten nøjagtigt som wsrep_sst_rsync bortset fra at det sikrer den faktiske kommunikation med SSL ved hjælp af socat. Generer den nødvendige klient/servernøgle og certifikatfiler, kopier dem til alle noder og angiv "secure_rsync" som SST-metoden i MySQL-konfigurationsfilen for at aktivere den:

wsrep_sst_method=secure_rsync

For xtrabackup skal følgende konfigurationsmuligheder være aktiveret i MySQL-konfigurationsfilen under [sst]-direktivet:

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

Genstart af database er ikke nødvendig. Hvis denne node er valgt af Galera som donor, vil disse konfigurationsmuligheder blive opfanget automatisk, når Galera starter SST.

SELinux

Sikkerhedsforbedret Linux (SELinux) er en adgangskontrolmekanisme implementeret i kernen. Uden SELinux bruges kun traditionelle adgangskontrolmetoder såsom filtilladelser eller ACL til at kontrollere brugernes filadgang.

Som standard, med streng håndhævelsestilstand aktiveret, bliver alt nægtet, og administratoren er nødt til at lave en række undtagelsespolitikker til de elementer i systemet, der kræver for at fungere. At deaktivere SELinux helt er blevet en almindelig dårlig praksis for mange RedHat-baserede installationer i dag.

Afhængig af arbejdsbelastninger, brugsmønstre og processer er den bedste måde at skabe dit eget SELinux-politikmodul, der er skræddersyet til dit miljø. Det, du virkelig skal gøre, er at indstille SELinux til permissiv tilstand (kun logning uden håndhævelse), og udløse hændelser, der kan ske på en Galera-node, så SELinux kan logge. Jo mere omfattende jo bedre. Eksempler på begivenheder som:

Starter node som donor eller joiner
Genstart node for at udløse IST
Brug forskellige SST-metoder
Sikkerhedskopier og gendan MySQL-databaser ved hjælp af mysqldump eller xtrabackup
Aktiver og deaktiver binære logfiler

Et eksempel er, hvis Galera-knuden overvåges af ClusterControl og forespørgselsovervågningsfunktionen er aktiveret, vil ClusterControl aktivere/deaktivere den langsomme forespørgselslogvariabel for at fange de langsomt kørende forespørgsler. Således vil du se følgende afvisning i 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

Ideen er at lade alle mulige afvisninger blive logget ind i revisionsloggen, som senere kan bruges til at generere politikmodulet ved hjælp af audit2allow før den indlæses i SELinux. Codership har dækket dette i detaljer på dokumentationssiden, SELinux Configuration.

SST-konto og privilegier

SST er en indledende synkroniseringsproces udført af Galera. Det bringer en joiner-node ajour med resten af medlemmerne i klyngen. Processen eksporterer grundlæggende dataene fra donor-knuden og gendanner dem på joiner-noden, før joineren får lov til at indhente de resterende transaktioner fra køen (dvs. dem, der skete under synkroniseringsprocessen). Tre SST-metoder understøttes:

mysqldump
rsync
xtrabackup (eller xtrabackup-v2)

Til brug af mysqldump SST kræves følgende privilegier:

VÆLG, VIS VISNING, TRIGGER, LÅS TABELLER, GENINDLÆS, FIL

Vi kommer ikke videre med mysqldump, fordi det sandsynligvis ikke ofte bruges i produktionen som SST-metode. Derudover er det en blokeringsprocedure på donoren. Rsync er normalt et foretrukket andet valg efter xtrabackup på grund af hurtigere synkroniseringstid og mindre fejltilbøjelig sammenlignet med mysqldump. SST-godkendelse ignoreres med rsync, derfor kan du springe over at konfigurere SST-kontorettigheder, hvis rsync er den valgte SST-metode.

Når du flytter sammen med xtrabackup, anbefales følgende privilegier til standard sikkerhedskopierings- og gendannelsesprocedurer baseret på Xtrabackup-dokumentationssiden:

CREATE, CREATE TABLESPACE, EVENT, INSERT, LOCK TABLE, PROCESS, RELOAD, REPLICATION CLIENT, SELECT, SHOW VIEW, SUPER

Men for xtrabackups SST-brug er det kun følgende privilegier, der betyder noget:

BEHANDLER, GENINDLÆS, REPLIKATIONSKLIENT

Således kan GRANT-opgørelsen for SST minimeres som:

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

Konfigurer derefter wsrep_sst_auth i overensstemmelse hermed i MySQL-konfigurationsfilen:

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

Giv kun SST-brugeren til localhost og brug en stærk adgangskode. Undgå at bruge root-bruger som SST-kontoen, fordi det ville afsløre root-adgangskoden inde i konfigurationsfilen under denne variabel. Plus, at ændre eller nulstille MySQL root-adgangskoden ville bryde SST i fremtiden.

MySQL sikkerhedshærdning

Galera Cluster er et multi-master replikeringsplugin til InnoDB storage engine, som kører på MySQL og MariaDB gafler. Derfor gælder standard MySQL/MariaDB/InnoDB sikkerhedshærdende anbefalinger også for Galera Cluster.

Dette emne er blevet dækket i adskillige blogindlæg derude. Vi har også dækket dette emne i følgende blogindlæg:

Ti tips til, hvordan man opnår MySQL- og MariaDB-sikkerhed
ClusterControl Tips &Tricks:Sikring af din MySQL-installation
Sådan sikrer du dine Open Source-databaser med ClusterControl

Ovenstående blogindlæg opsummerer nødvendigheden af at kryptere hvilende data og data under transport, have revisionsplugins, generelle sikkerhedsretningslinjer, bedste praksis for netværkssikkerhed og så videre.

Brug en Load Balancer

Der er en række database load balancere (reverse proxy), som kan bruges sammen med Galera - HAProxy, ProxySQL og MariaDB MaxScale for at nævne nogle af dem. Du kan konfigurere en belastningsbalancer til at kontrollere adgangen til dine Galera-noder. Det er en fantastisk måde at fordele databasens arbejdsbyrde på mellem databaseinstanserne, samt begrænse adgangen, f.eks. hvis du vil tage en node offline til vedligeholdelse, eller hvis du vil begrænse antallet af forbindelser, der åbnes på Galera-knuderne. Belastningsbalanceren bør være i stand til at sætte forbindelser i kø og derfor give en vis overbelastningsbeskyttelse til dine databaseservere.

ProxySQL, en kraftfuld database reverse-proxy, som forstår MySQL og MariaDB, kan udvides med mange nyttige sikkerhedsfunktioner som forespørgselsfirewall, for at blokere stødende forespørgsler fra databaseserveren. Forespørgselsregler-motoren kan også bruges til at omskrive dårlige forespørgsler til noget bedre/sikkert, eller omdirigere dem til en anden server, som kan absorbere belastningen uden at påvirke nogen af Galera-knuderne. MariaDB MaxScale er også i stand til at blokere forespørgsler baseret på regulære udtryk med dets Database Firewall-filter.

En anden fordel ved at have en belastningsbalancer til din Galera Cluster er evnen til at være vært for en datatjeneste uden at udsætte databaselaget for det offentlige netværk. Proxyserveren kan bruges som bastionvært for at få adgang til databasenoderne i et privat netværk. Ved at have databaseklyngen isoleret fra omverdenen, har du fjernet en af de vigtige angrebsvektorer.

Det er det. Vær altid sikker og beskyttet.

Sådan sikrer du Galera Cluster - 8 tips