Sikkerhed er et af de vigtigste aspekter ved at køre en database. Uanset om du er udvikler eller DBA, hvis du administrerer databasen, er det dit ansvar at beskytte dine data og beskytte dem mod enhver form for uautoriseret adgang. Den uheldige kendsgerning er, at mange organisationer ikke beskytter deres data, som vi har set fra den nye bølge af MongoDB ransomware-angreb i september 2017. Vi havde tidligere udgivet en blog om, hvordan man sikrer MongoDB-databaser.
I dette blogindlæg vil vi se på, hvordan du sikrer dine databaser ved hjælp af ClusterControl. Alle de funktioner, der er beskrevet her, er tilgængelige i version 1.5.1 af ClusterControl (udgivet den 23. december 2017). Bemærk venligst, at nogle funktioner kun er tilgængelige for visse databasetyper.
Sikkerhedskopikryptering
ClusterControl 1.5.1 introducerede en ny funktion kaldet backup-kryptering. Alle krypterede sikkerhedskopier er markeret med et låseikon ved siden af:
Du kan bruge denne funktion på alle sikkerhedskopieringsmetoder (mysqldump, xtrabackup, mongodump, pg_dump) understøttet af ClusterControl. For at aktivere kryptering skal du blot slå "Aktiver kryptering" til, når du planlægger eller opretter sikkerhedskopien. ClusterControl genererer automatisk en nøgle til at kryptere sikkerhedskopien. Den bruger AES-256 (CBC) krypteringsalgoritme og udfører krypteringen i farten på målserveren. Den følgende kommando viser et eksempel på, hvordan ClusterControl udfører en mysqldump backup:
$ mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --no-create-info --no-data --triggers --routines --events --single-transaction --skip-comments --skip-lock-tables --skip-add-locks --databases db1 | gzip -6 -c | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-094508-e0bc6ad658e88d93.tmp | socat - TCP4:192.168.55.170:9999'Du vil se følgende fejl, hvis du forsøgte at dekomprimere en krypteret sikkerhedskopi uden at dekryptere den først med den rigtige nøgle:
$ gunzip mysqldump_2018-01-03_175727_data.sql.gz
gzip: mysqldump_2018-01-03_175727_data.sql.gz: not in gzip formatNøglen er gemt i ClusterControl-databasen og kan hentes fra filen cmon_backup.metadata for et bestemt sikkerhedskopieringssæt. Det vil blive brugt af ClusterControl, når der udføres restaurering. Kryptering af sikkerhedskopier anbefales stærkt, især når du vil sikre dine sikkerhedskopier offsite, f.eks. at arkivere dem i skyen.
MySQL/PostgreSQL klient-serverkryptering
Udover at følge de anbefalede sikkerhedstrin under implementeringen, kan du øge pålideligheden af din databasetjeneste ved at bruge klient-server SSL-kryptering. Ved at bruge ClusterControl kan du udføre denne handling med et simpelt peg og klik:
Du kan derefter hente de genererede nøgler og certifikater direkte fra ClusterControl-værten under
Databasereplikeringskryptering
Replikeringstrafik inden for en Galera-klynge kan aktiveres med blot ét klik. ClusterControl bruger en 2048-bit standardnøgle og certifikat genereret på ClusterControl-knuden, som overføres til alle Galera-knuderne:
En klynge genstart er nødvendig. ClusterControl udfører en rullende genstartsoperation og tager én node ad gangen. Du vil se et grønt låseikon ved siden af databaseserveren (Galera angiver Galera Replication-kryptering, mens SSL angiver klient-server-kryptering) i Hosts-gitteret på siden Oversigt, når kryptering er aktiveret:
Alle nøgler og certifikater kan administreres direkte under Key Management, som beskrevet længere nede.
Nøglestyring
Alle de genererede nøgler og certifikater kan administreres direkte fra ClusterControl UI. Nøglestyring giver dig mulighed for at administrere SSL-certifikater og nøgler, der kan leveres på dine klynger:
Hvis certifikatet er udløbet, kan du blot bruge brugergrænsefladen til at generere et nyt certifikat med korrekt nøgle og Certificate Authority (CA), eller importere en eksisterende nøgle og certifikat til ClusterControl-værten.
Sikkerhedsrådgivere
Rådgivere er miniprogrammer, der kører i ClusterControl. De udfører specifikke opgaver og giver råd om, hvordan man løser problemer inden for områder som ydeevne, sikkerhed, logstyring, konfiguration, lagerplads og andre. Hver rådgiver kan planlægges som et cron-job og køre som en selvstændig eksekverbar i ClusterControl-brugergrænsefladen. Det kan også køres via ClusterControl 's9s' kommandolinjeklient.
ClusterControl muliggør to sikkerhedsrådgivere til MySQL-baserede systemer:
- Adgang fra enhver vært ('%') - Identificerer alle brugere, der bruger en joker-vært fra mysql-systemtabellen, og lader dig have mere kontrol over, hvilke værter der kan oprette forbindelse til serverne.
- Tjek antallet af konti uden adgangskode - Identificerer alle brugere, der ikke har en adgangskode i mysql-systemtabellen.
Til MongoDB har vi følgende rådgivere:
- MongoDB-godkendelse aktiveret - Tjek, om MongoDB-instansen kører med godkendelsestilstand aktiveret.
- Tjek af autorisation - Tjek, om MongoDB-brugere er autoriserede med en for tilladende rolle til adgangskontrol.
For flere detaljer om, hvordan ClusterControl udfører sikkerhedstjekket, kan du se rådgiverens JavaScript-lignende kildekode under
Flere netværksgrænseflader
At have flere NIC'er på databaseværterne giver dig mulighed for at adskille databasetrafik fra administrationstrafik. Et netværk bruges af databasenoderne til at kommunikere med hinanden, og dette netværk er ikke eksponeret for noget offentligt netværk. Det andet netværk bruges af ClusterControl til administrationsformål. ClusterControl er i stand til at implementere en sådan multinetværksopsætning. Overvej følgende arkitekturdiagram:
For at importere ovenstående databaseklynge til ClusterControl, skal man angive databaseværternes primære IP-adresse. Derefter er det muligt at vælge administrationsnetværket såvel som datanetværket:
ClusterControl kan også arbejde i et miljø uden internetadgang, hvor databaserne er totalt isoleret fra det offentlige netværk. De fleste af funktionerne vil fungere fint. Hvis ClusterControl-værten er konfigureret med internet, er den også i stand til at klone databaseleverandørens lager til de internetløse databaseservere. Bare gå til
Spejlingen kan tage omkring 10 til 20 minutter afhængigt af internetforbindelsen, du vil se det nye element på listen senere. Du kan derefter vælge dette lager i stedet, når du skalerer eller installerer en ny klynge, uden at databaseværterne behøver at have nogen internetforbindelse (bemærk, at operativsystemets offline-lager også skal være på plads).
MySQL-brugerstyring
MySQL privilegiesystemet sikrer, at alle brugere kun kan udføre de operationer, de har tilladelse til. Tildeling er kritisk, da du ikke ønsker at give alle brugere fuld adgang til din database, men du skal have, at brugerne har de nødvendige tilladelser til at køre forespørgsler og udføre daglige opgaver.
ClusterControl giver en interaktiv brugergrænseflade til at administrere databaseskemaer og privilegier. Det forener konti på alle MySQL-servere i klyngen og forenkler bevillingsprocessen. Du kan nemt visualisere databasebrugerne, så du undgår at lave fejl.
Som du kan se på ovenstående skærmbillede, nedtonede ClusterControl unødvendige privilegier, hvis du kun vil give en bruger til en database (shopdb). "Kræver SSL?" er kun aktiveret, hvis klient/server SSL-krypteringen er aktiveret, mens afkrydsningsfelterne for administrationsprivilegier er fuldstændig deaktiveret, hvis en specifik database er defineret. Du kan også inspicere den genererede GRANT-sætning i bunden af guiden for at se den erklæring, som ClusterControl vil udføre for at oprette denne bruger. Denne hjælper ser ret simpel ud, men oprettelse af brugere og tildeling af privilegier kan være udsat for fejl.
ClusterControl giver også en liste over inaktive brugere for alle databasenoder i klyngen, der viser de konti, der ikke er blevet brugt siden sidste servergenstart:
Dette advarer administratoren om unødvendige konti, der findes, og som potentielt kan skade serveren. Det næste trin er at bekræfte, om konti ikke længere er aktive, og du kan blot bruge "Drop valgt bruger" for at fjerne dem. Sørg for, at du har nok databaseaktivitet til at sikre, at den liste, der genereres af ClusterControl, er nøjagtig. Jo længere serverens oppetid er, jo bedre.
Hold dig altid opdateret
Til produktionsbrug anbefales det stærkt, at du installerer de databaserelaterede pakker fra leverandørens lager. Stol ikke på standardoperativsystemlageret, hvor pakkerne normalt er forældede. Hvis du kører i et klyngemiljø som Galera Cluster eller endda MySQL-replikering, har du altid valget mellem at patche systemet med minimal nedetid.
ClusterControl understøtter automatisk rullende mindre versionsopgradering til MySQL/MariaDB med et enkelt klik. Bare gå til
Større versionsopgraderinger (f.eks. fra MySQL 5.6 til MySQL 5.7) er med vilje ikke automatiseret. Større opgraderinger kræver normalt afinstallation af de eksisterende pakker, hvilket er en risikabel opgave at automatisere. Omhyggelig planlægning og test er nødvendig for sådanne slags opgraderinger.
Databasesikkerhed er et vigtigt aspekt af at køre din database i produktion. Ud fra alle de hændelser, vi ofte læser om i nyhederne (og der er sikkert mange andre, der ikke bliver offentliggjort), er det tydeligt, at der er grupper, der har travlt derude med dårlige hensigter. Så sørg for, at dine databaser er godt beskyttet.