Hur man säkrar Galera Cluster - 8 tips

Som ett distribuerat databassystem kräver Galera Cluster ytterligare säkerhetsåtgärder jämfört med en centraliserad databas. Data distribueras över flera servrar eller till och med datacenter kanske. Med betydande datakommunikation som sker över noder, kan det bli betydande exponering om lämpliga säkerhetsåtgärder inte vidtas.

I det här blogginlägget kommer vi att titta på några tips om hur du säkrar vårt Galera-kluster. Observera att den här bloggen bygger på vårt tidigare blogginlägg - Hur du säkrar dina databaser med öppen källkod med ClusterControl.

Brandvägg och säkerhetsgrupp

Följande portar är mycket viktiga för ett Galera-kluster:

• 3306 - MySQL
• 4567 - Galera-kommunikation och replikering
• 4568 - Galera IST
• 4444 - Galera SST

Från det externa nätverket rekommenderas att endast öppna åtkomst till MySQL-port 3306. De övriga tre portarna kan stängas ner från det externa nätverket, och tillåter dem endast för intern åtkomst mellan Galera-noderna. Om du kör en omvänd proxy som sitter framför Galera-noderna, till exempel HAProxy, kan du låsa MySQL-porten från allmän tillgång. Se också till att övervakningsporten för HAProxy-övervakningsskriptet är öppen. Standardporten är 9200 på Galera-noden.

Följande diagram illustrerar vår exempelinställning på ett Galera-kluster med tre noder, med en HAProxy vänd mot det offentliga nätverket med tillhörande portar:

Baserat på diagrammet ovan är iptables-kommandona för databasnoder:

$ 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

Medan på lastbalanseraren:

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

Se till att avsluta dina brandväggsregler med deny all, så endast trafik som definieras i undantagsreglerna är tillåten. Du kan vara strängare och utöka kommandona för att följa din säkerhetspolicy - till exempel genom att lägga till nätverksgränssnitt, destinationsadress, källadress, anslutningstillstånd och vad inte.

MySQL klient-serverkryptering

MySQL stöder kryptering mellan klienten och servern. Först måste vi generera certifikatet. När du väl har konfigurerat kan du tvinga användarkonton att ange vissa alternativ för att ansluta med kryptering till en MySQL-server.

Stegen kräver att du:

1. Skapa en nyckel för certifikatutfärdare (ca-key.pem)
2. Skapa ett självsignerat CA-certifikat (ca-cert.pem)
3. Skapa en nyckel för servercertifikat (server-key.pem)
4. Skapa ett certifikat för servern och signera det med ca-key.pem (server-cert.pem)
5. Skapa en nyckel för klientcertifikat (client-key.pem)
6. Generera ett certifikat för klienten och signera det med ca-key.pem (client-cert.pem)

Var alltid försiktig med CA:s privata nyckel (ca-key.pem) - alla som har tillgång till den kan använda den för att generera ytterligare klient- eller servercertifikat som kommer att accepteras som legitima när CA-verifiering är aktiverad. Summan av kardemumman är att alla nycklar måste hållas diskreta.

Du kan sedan lägga till de SSL-relaterade variablerna under [mysqld]-direktivet, till exempel:

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

Starta om MySQL-servern för att ladda ändringarna. Skapa sedan en användare med REQUIRE SSL-satsen, till exempel:

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

Användaren som skapats med REQUIRE SSL kommer att tvingas ansluta till rätt klient-SSL-filer (client-cert.pem, client-key.pem och ca-cert.pem).

Med ClusterControl kan klient-server SSL-kryptering enkelt aktiveras från användargränssnittet med funktionen "Skapa SSL-kryptering".

Galera-kryptering

Aktivering av kryptering för Galera innebär att IST också kommer att krypteras eftersom kommunikationen sker via samma socket. SST, å andra sidan, måste konfigureras separat som visas i nästa avsnitt. Alla noder i klustret måste vara aktiverade med SSL-kryptering och du kan inte ha en blandning av noder där vissa har aktiverat SSL-kryptering, och andra inte. Den bästa tiden att konfigurera detta är när du skapar ett nytt kluster. Men om du behöver lägga till detta på ett körande produktionssystem måste du tyvärr starta om klustret och det kommer att bli stillestånd.

Alla Galera-noder i klustret måste använda samma nyckel, certifikat och CA (valfritt). Du kan också använda samma nyckel och certifikat som skapats för MySQL klient-serverkryptering, eller generera en ny uppsättning endast för detta ändamål. För att aktivera kryptering inuti Galera måste man lägga till alternativet och värdet under wsrep_provider_options i MySQL-konfigurationsfilen på varje Galera-nod. Tänk till exempel på följande befintliga linje för vår Galera-nod:

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

Lägg till de relaterade variablerna i citatet, avgränsade med semikolon:

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

För mer information om Galeras SSL-relaterade parametrar, se här. Utför denna modifiering på alla noder. Stoppa sedan klustret (en nod i taget) och starta från den sista noden som stängdes av. Du kan kontrollera om SSL är korrekt laddat genom att titta i MySQL-felloggen:

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 enkelt aktiveras med funktionen "Skapa SSL Galera-kryptering".

SST-kryptering

När SST sker utan kryptering, exponeras datakommunikationen medan SST-processen pågår. SST är en fullständig datasynkroniseringsprocess från en donator till en joiner-nod. Om en angripare kunde "se" hela dataöverföringen, skulle personen få en fullständig ögonblicksbild av din databas.

SST med kryptering stöds endast för metoderna mysqldump och xtrabackup-v2. För mysqldump måste användaren ges "REQUIRE SSL" på alla noder och konfigurationen liknar standard MySQL klient-server SSL-kryptering (som beskrivits i föregående avsnitt). När klient-serverkrypteringen är aktiverad skapar du en ny SST-användare med SSL påtvingat:

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

För rsync rekommenderar vi att du använder galera-secure-rsync, ett drop-in SSL-säkrat rsync SST-skript för Galera Cluster. Det fungerar nästan exakt som wsrep_sst_rsync förutom att den säkrar den faktiska kommunikationen med SSL med hjälp av socat. Generera de nödvändiga klient-/servernyckel- och certifikatfilerna, kopiera dem till alla noder och ange "secure_rsync" som SST-metoden i MySQL-konfigurationsfilen för att aktivera den:

wsrep_sst_method=secure_rsync

För xtrabackup måste följande konfigurationsalternativ vara aktiverade 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

Omstart av databasen är inte nödvändig. Om denna nod väljs av Galera som donator, kommer dessa konfigurationsalternativ att hämtas automatiskt när Galera initierar SST.

SELinux

Säkerhetsförbättrad Linux (SELinux) är en åtkomstkontrollmekanism implementerad i kärnan. Utan SELinux används endast traditionella åtkomstkontrollmetoder såsom filbehörigheter eller ACL för att kontrollera användarnas filåtkomst.

Som standard, med strikt tillämpningsläge aktiverat, nekas allt och administratören måste göra en rad undantagspolicyer till de delar av systemet som krävs för att fungera. Att inaktivera SELinux helt och hållet har blivit en vanlig dålig praxis för många RedHat-baserade installationer nuförtiden.

Beroende på arbetsbelastning, användningsmönster och processer är det bästa sättet att skapa din egen SELinux policymodul skräddarsydd för din miljö. Vad du verkligen behöver göra är att ställa in SELinux på tillåtande läge (endast loggning utan att verkställa), och utlösa händelser som kan hända på en Galera-nod för SELinux att logga. Ju mer omfattande desto bättre. Exempelhändelser som:

• Startar nod som givare eller ansluter
• Starta om noden för att utlösa IST
• Använd olika SST-metoder
• Säkerhetskopiera och återställ MySQL-databaser med mysqldump eller xtrabackup
• Aktivera och inaktivera binära loggar

Ett exempel är om Galera-noden övervakas av ClusterControl och frågeövervakningsfunktionen är aktiverad, kommer ClusterControl att aktivera/inaktivera den långsamma frågeloggvariabeln för att fånga de långsamma körande frågorna. Således skulle du se följande förnekelse 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

Tanken är att låta alla möjliga avslag loggas in i granskningsloggen, som senare kan användas för att generera policymodulen med audit2allow innan du laddar den i SELinux. Codership har täckt detta i detaljer på dokumentationssidan, SELinux Configuration.

SST-konto och rättigheter

SST är en initial synkroniseringsprocess som utförs av Galera. Det ger en joiner-nod uppdaterad med resten av medlemmarna i klustret. Processen exporterar i princip data från donatornoden och återställer den på joinernoden, innan joinern tillåts komma ikapp de återstående transaktionerna från kön (dvs de som hände under synkroniseringsprocessen). Tre SST-metoder stöds:

• mysqldump
• rsync
• xtrabackup (eller xtrabackup-v2)

För mysqldump SST-användning krävs följande privilegier:

• VÄLJ, VISA VY, TRIGGER, LÅS TABELLER, LADDA OM, FIL

Vi kommer inte gå längre med mysqldump eftersom det förmodligen inte används ofta i produktionen som SST-metod. Dessutom är det en blockerande procedur på givaren. Rsync är vanligtvis ett föredraget andraval efter xtrabackup på grund av snabbare synkroniseringstid och mindre felbenägen jämfört med mysqldump. SST-autentisering ignoreras med rsync, därför kan du hoppa över att konfigurera SST-kontoprivilegier om rsync är den valda SST-metoden.

När du flyttar tillsammans med xtrabackup, rekommenderas följande privilegier för standardprocedurer för säkerhetskopiering och återställning baserat på Xtrabackup-dokumentationssidan:

• SKAPA, SKAPA TABLESPACE, HÄNDELSE, INFOGA, LÅS TABELL, BEHANDLA, LADDA OM, REPLIKATIONSKLIENT, VÄLJ, VISA VY, SUPER

Men för xtrabackups SST-användning är det bara följande privilegier som är viktiga:

• BEHANDLA, LADDA OM, REPLIKATIONSKLIENT

Således kan GRANT-satsen för SST minimeras som:

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

Konfigurera sedan wsrep_sst_auth i enlighet med MySQL-konfigurationsfilen:

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

Ge endast SST-användaren för localhost och använd ett starkt lösenord. Undvik att använda root-användare som SST-konto, eftersom det skulle exponera root-lösenordet i konfigurationsfilen under denna variabel. Dessutom skulle ändra eller återställa MySQL root-lösenordet bryta SST i framtiden.

MySQL-säkerhetshärdning

Galera Cluster är en multi-master replikering plugin för InnoDB lagringsmotor, som körs på MySQL och MariaDB gafflar. Därför gäller standardrekommendationer för MySQL/MariaDB/InnoDB säkerhetshärdning även för Galera Cluster.

Detta ämne har behandlats i många blogginlägg där ute. Vi har också behandlat detta ämne i följande blogginlägg:

• Tio tips om hur man uppnår MySQL- och MariaDB-säkerhet
• ClusterControl Tips &Tricks:Säkra din MySQL-installation
• Hur du säkrar dina databaser med öppen källkod med ClusterControl

Ovanstående blogginlägg sammanfattar nödvändigheten av att kryptera data i vila och data under överföring, ha granskningsplugin, allmänna säkerhetsriktlinjer, bästa praxis för nätverkssäkerhet och så vidare.

Använd en lastbalanserare

Det finns ett antal databaslastbalanserare (omvänd proxy) som kan användas tillsammans med Galera - HAProxy, ProxySQL och MariaDB MaxScale för att nämna några av dem. Du kan ställa in en lastbalanserare för att kontrollera åtkomsten till dina Galera-noder. Det är ett utmärkt sätt att fördela databasarbetsbelastningen mellan databasinstanserna, samt begränsa åtkomsten, t.ex. om du vill ta en nod offline för underhåll, eller om du vill begränsa antalet öppnade anslutningar på Galera-noderna. Lastbalanseraren bör kunna köa anslutningar och därför ge visst överbelastningsskydd till dina databasservrar.

ProxySQL, en kraftfull databas omvänd proxy som förstår MySQL och MariaDB, kan utökas med många användbara säkerhetsfunktioner som frågebrandvägg, för att blockera stötande frågor från databasservern. Frågereglermotorn kan också användas för att skriva om dåliga frågor till något bättre/säkrare, eller omdirigera dem till en annan server som kan absorbera belastningen utan att påverka någon av Galera-noderna. MariaDB MaxScale kan också blockera frågor baserade på reguljära uttryck med dess databasbrandväggsfilter.

En annan fördel med en lastbalanserare för ditt Galera-kluster är möjligheten att vara värd för en datatjänst utan att exponera databasnivån för det offentliga nätverket. Proxyservern kan användas som bastionsvärd för att få tillgång till databasnoderna i ett privat nätverk. Genom att ha databasklustret isolerat från omvärlden har du tagit bort en av de viktiga attackvektorerna.

Det är allt. Var alltid säker och skyddad.