sql >> Database teknologi >  >> RDS >> Mysql

Databasesikkerhed - Backup-kryptering under transport og hvile

Sikring af dine data er en af ​​de vigtigste opgaver, som vi bør prioritere. Fremkomsten af ​​regler, der kræver overholdelse af sikkerheden, såsom GDPR, HIPAA, PCI DSS eller PHI, kræver, at dine data skal opbevares sikkert eller overføres via ledningen.

I ClusterControl værdsætter vi vigtigheden af ​​sikkerhed og tilbyder en række funktioner til at sikre databaseadgang og lagrede data. En af dem er at sikre dine databasesikkerhedskopier, både i hvile og under transport. In-transit er, når sikkerhedskopien overføres via internettet eller netværket fra kilden til dens destination, mens hviletid er, når data gemmes på vedvarende lagring. I denne blog viser vi dig, hvordan du kan bruge ClusterControl til at kryptere dine backupdata i hvile og under transport.

Kryptering under transport

Når du administrerer sikkerhedskopier gennem ClusterControl, administreres brug af mysqldump eller Percona Xtrabackup/Mariabackup som standard uden kryptering, når de overføres over ledningen. Brug af TLS/SSL til kryptering af datatransmission understøttes dog af MySQL/MariaDB/Percona Server, det samme gør Percona Xtrabackup, som tilbyder SSL-muligheder, når kommandoen påkaldes.

ClusterControl aktiverer SSL som standard, når du implementerer en klynge, men den har ikke kontrol til at skifte øjeblikkeligt og gøre dine data krypteret over ledningen under oprettelse af backup. Du kan tjekke vores tidligere blogs for den manuelle tilgang ved hjælp af ClusterControl, når du opretter din klynge eller bruger den gammeldags måde at manuelt opsætte TLS/SSL i MySQL.

I ClusterControl, når du implementerer en klynge, kan du kontrollere sikkerhedsfanen eller dette ikon .

Ved at klikke på -knappen giver dig mulighed for at erstatte det certifikat, som i øjeblikket bruges eller implementeres af ClusterControl under implementeringen af ​​din nyligt klargjorte klynge. Du kan tjekke denne blog "Opdateret:Bliv en ClusterControl DBA - SSL Key Management and Encryption of MySQL Data in Transit", hvor vi viste, hvordan vi håndterer nøglerne. Grundlæggende kan du gå gennem venstre navigation af ClusterControl og klikke på "Nøglestyring".

Nedenfor er et eksempel på nøglestyring, hvor du kan oprette og importere dine eksisterende nøgler.

Når du opretter en sikkerhedskopi ved hjælp af mysqldump som din logiske sikkerhedskopi, for at kryptere dine data, skal du sørge for, at du har dine SSL-indstillinger indstillet i overensstemmelse hermed.

Hvad er det næste?

Da vi har vores oprettede certifikater, er vi nødt til at aktivere og konfigurere SSL i overensstemmelse hermed. For at sikre dette kan du tjekke via ClusterControl eller mysql kommandoprompt. Se billeder nedenfor:

eller du kan også tjekke under fanen Ydelse og klikke på DB-variabler som vist nedenfor:

Bemærk, at det kan tage lidt tid at udfylde under Ydeevne -> DB-variabler. Så hvis du vil tjekke manuelt, kan du bruge mysql kommandoprompt ligesom nedenfor:

At definere din ssl_cipher kan tilføje mere sikkerhedshærdning. Der er en liste over cipher suite, hvis du kører SHOW GLOBAL STATUS SOM ‘Ssl_cipher_list’\G eller tjekker her. En chifferpakke er en kombination af godkendelses-, kryptering- og meddelelsesgodkendelseskode (MAC) algoritmer. Disse bruges under forhandling af sikkerhedsindstillinger for en TLS/SSL-forbindelse samt til sikker overførsel af data.

Da ClusterControl vil køre mysqldump lokalt ind i den vært, tilføjer følgende parametre (se nedenfor) i din MySQL-konfigurationsfil (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) vil kryptere alle handlinger til SQL-dump. Se nedenfor:

[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
host=127.0.0.1
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pem

Du kan prøve at overvåge ved hjælp af tcpdump, og du kan se nedenfor sammenlignet med et ukrypteret vs krypteret lag ved hjælp af TLS.

Med TLS/SSL:

Uden TLS/SSL:

Når du bruger Percona XtraBackup eller Mariabackup under ClusterControl, er der ingen TLS/SSL-understøttelse på nuværende tidspunkt, når backup overføres over netværket. Den bruger socat, som dybest set bare åbner en port ind i en anden node som et kommunikationsmiddel.

f.eks.

[21:24:46]: 192.168.10.20: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | socat - TCP4:192.168.10.200:9999 ) 2>&1.
[21:24:46]: 192.168.10.20: The xtrabackup version is 2.4.12 / 2004012.
[21:24:46]: 192.168.10.20:3306: Checking xtrabackup version.
[21:24:46]: 192.168.10.20: Streaming backup to 192.168.10.200
[21:24:46]: 192.168.10.200: Netcat started, error log is in '192.168.10.200:/tmp/netcat.log'.
[21:24:43]: 192.168.10.200: Starting socat -u tcp-listen:9999,reuseaddr stdout > /home/vagrant/backups/BACKUP-71/backup-full-2018-11-12_132443.xbstream.gz 2>/tmp/netcat.log.

Hvis du har brug for et sikkert lag under transport, kan du gøre dette manuelt ved at bruge --ssl* muligheder under kommandokald. Tjek her for Percona XtraBackup-manualen for mere info. Vi anbefaler stadig at få dit certifikat/nøgle fra en registreret certifikatmyndighed.

Alternativt kan du ved hjælp af ClusterControl kryptere dine data inden afsendelse via netværket, de pakker der sendes er ikke rå, men krypterede data. Selvom krypteringen er afhængig af hvile, vil vi diskutere dette i næste afsnit.

Kryptering i hvile

I ClusterControl har du, når du opretter din backup, mulighed for at gøre dine data krypteret. Se nedenfor:

Når den er krypteret, vil ClusterControl bruge "Advance Encryption Standard" AES-256-CBC. Se eksempelloggen nedenfor:

[22:12:49]: 192.168.10.30: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-002471-32758-24c456ca6b087837.tmp | socat - TCP4:192.168.10.200:9999 ) 2>&1.

Hvis du gemmer din backup i skyen, for eksempel med AWS S3, tilbyder S3 tre forskellige tilstande for serverside-kryptering (SSE). Disse er SSE-S3, SSE-C eller SSE-KMS. Amazon har fantastiske SSE-funktioner at tilbyde, som håndterer kryptering af data i hvile. Du kan starte her, som tackler, hvordan S3 bruger AWS KMS. Hvis du flytter din backup til et volumen eller blokbaseret lager, har AWS også EBS-kryptering ved hjælp af AWS KMS. Du kan tjekke her for mere information om dette.

Microsoft Azure har også fede funktioner, når du håndterer data i hvile. Tjek siden om "Azure Storage Service Encryption for data at rest". Azure håndterer nøglerne i deres Azure Key Vault, det samme som AWS KMS. For Google-kryptering til hvilende data kan du tjekke her.

Når du gemmer data backups on-prem, kan du bruge LUKS (Linux Unified Key Setup) med en kombination af crypt eller dmcrypt. Jeg vil ikke diskutere dette på denne blog, men dette er en god kilde at se på:MySQL Encryption at Rest - Part 1 (LUKS). For mere information om diskkryptering er denne ArchLinux-side "Diskkryptering" en god kilde til at starte .

Vigtigst af alt, mens dine data er blevet krypteret i hvile og under transport, skal du altid kontrollere, at din backup virker. En sikkerhedskopi, der ikke er testet, er ikke en sikkerhedskopi, hvis den ikke virker, når der er behov for gendannelse. Lagring af din sikkerhedskopi, mens den er krypteret, skal dekrypteres uden problemer, og dine nøgler skal derfor opbevares privat og på den sikreste måde som muligt. Derudover tilføjer kryptering til dine data, såsom InnoDB-kryptering eller SST (for Galera), mere sikkerhed, men vi vil ikke dække disse i denne blog.

Konklusion

Kryptering af backup-data i hvile og under transport er vitale komponenter for overholdelse af PHI, HIPAA, PCI DSS eller GDPR, for at sikre, at følsomme data transmitteret over ledningen eller gemt på diske ikke kan læses af nogen bruger eller applikation uden en gyldig nøgle. Nogle overholdelsesbestemmelser såsom PCI DSS og HIPAA kræver, at hvilende data krypteres gennem hele dataens livscyklus.

Her viser vi, hvordan ClusterControl tilbyder disse muligheder til slutbrugeren. Overholdelse er dog en stor opgave, der berører mange forskellige områder. Reglerne bliver også opdateret jævnligt, og processer/værktøjer skal også opdateres i overensstemmelse hermed. Vi forbedrer løbende forskellige områder i ClusterControl for at lette overholdelse. Vi vil gerne høre dine tanker om dette, og hvordan vi kan forbedre os.


  1. MySQL-datakilden vises ikke i Visual Studio

  2. ProxySQL:Alle Severalnines-ressourcerne

  3. Oracle Database 21c til Linux-platforme

  4. Sådan får du UTC-værdi for SYSDATE på Oracle