Databassäkerhet - Backup-kryptering under transport och i vila

Att säkra din data är en av de viktigaste uppgifterna som vi bör prioritera. Framväxten av bestämmelser som kräver säkerhetsefterlevnad som GDPR, HIPAA, PCI DSS eller PHI kräver att dina data ska lagras säkert eller överföras via tråden.

I ClusterControl värdesätter vi vikten av säkerhet och erbjuder ett antal funktioner för att säkra databasåtkomst och lagrad data. En av dessa är att säkra dina databassäkerhetskopior, både i vila och under transport. In-transit är när säkerhetskopian överförs via internet eller nätverk från källan till dess destination, medan vila är när data lagras på beständig lagring. I den här bloggen visar vi dig hur du kan använda ClusterControl för att kryptera dina säkerhetskopierade data i vila och under transport.

Kryptering under transport

När du hanterar säkerhetskopior via ClusterControl hanteras mysqldump eller Percona Xtrabackup/Mariabackup som standard utan kryptering när de överförs via tråden. Användning av TLS/SSL för kryptering av dataöverföring stöds dock av MySQL/MariaDB/Percona Server, så även Percona Xtrabackup som erbjuder SSL-alternativ när kommandot anropas.

ClusterControl aktiverar SSL som standard när du distribuerar ett kluster, men det har inte kontrollen att byta direkt och göra dina data krypterade över tråden när säkerhetskopieringen skapas. Du kan kolla in våra tidigare bloggar för det manuella tillvägagångssättet med ClusterControl när du skapar ditt kluster eller använder det gammalmodiga sättet att manuellt ställa in TLS/SSL i MySQL.

I ClusterControl, när du distribuerar ett kluster, kan du kontrollera säkerhetsfliken eller den här ikonen .

Genom att klicka på -knappen låter dig ersätta certifikatet som för närvarande används eller distribueras av ClusterControl under distributionen av din nyligen tillhandahållna klunga. Du kan kolla denna blogg "Uppdaterad:Bli en ClusterControl DBA - SSL Key Management and Encryption of MySQL Data in Transit" för vilken vi visade hur vi hanterar nycklarna. I grund och botten kan du gå igenom vänster navigering av ClusterControl och klicka på "Key Management".

Nedan är ett exempel på nyckelhantering där du kan skapa och importera dina befintliga nycklar.

När du skapar en säkerhetskopia med mysqldump som din logiska säkerhetskopia, för att kryptera dina data, se till att du har dina SSL-alternativ inställda i enlighet därmed.

Vad händer härnäst?

Eftersom vi har våra skapade certifikat måste vi aktivera och ställa in SSL därefter. För att säkerställa detta kan du kontrollera via ClusterControl eller mysql kommandotolk. Se bilderna nedan:

eller så kan du också kolla under fliken Prestanda och klicka på DB-variabler som visas nedan:

Observera att det kan ta lite tid att fylla i under Prestanda -> DB-variabler. Så om du vill kontrollera manuellt kan du använda mysql-kommandotolken precis som nedan:

Att definiera din ssl_cipher kan lägga till mer säkerhetshärdning. Det finns en lista med chiffersviter om du kör SHOW GLOBAL STATUS SOM ‘Ssl_cipher_list’\G eller kolla här. En chiffersvit är en kombination av algoritmer för autentisering, kryptering och meddelandeautentiseringskod (MAC). Dessa används under förhandling av säkerhetsinställningar för en TLS/SSL-anslutning samt för säker överföring av data.

Eftersom ClusterControl kommer att köra mysqldump lokalt i den värden, lägg till följande parametrar (se nedan) i din MySQL-konfigurationsfil (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) kommer att kryptera alla åtgärder för SQL-dump. Se nedan:

[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 försöka övervaka med tcpdump och du kan se nedan jämfört med ett okrypterat kontra krypterat lager med TLS.

Med TLS/SSL:

Utan TLS/SSL:

När du använder Percona XtraBackup eller Mariabackup under ClusterControl, finns det inget TLS/SSL-stöd för närvarande när säkerhetskopiering sänds över nätverket. Den använder socat som i princip bara öppnar en port till en annan nod som ett kommunikationsmedel.

t.ex.

[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.

Om du behöver ett säkert lager under transport, kan du göra detta manuellt med --ssl*-alternativ under kommandoanrop. Kolla in här för Percona XtraBackup-manualen för mer info. Vi rekommenderar fortfarande att du skaffar ditt certifikat/nyckel från en registrerad certifikatutfärdare.

Alternativt kan du med ClusterControl kryptera din data innan du skickar via nätverket, paketen som skickas är inte rådata utan krypterad data. Även om krypteringen är beroende av i vila, kommer vi att diskutera detta i nästa avsnitt.

Kryptering i vila

I ClusterControl, när du skapar din säkerhetskopia, har du möjlighet att göra dina data krypterade. Se nedan:

När den är krypterad kommer ClusterControl att använda "Advance Encryption Standard" AES-256-CBC. Se exempelloggen nedan:

[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.

Om du lagrar din säkerhetskopia i molnet, till exempel med AWS S3, erbjuder S3 tre olika lägen för serversideskryptering (SSE). Dessa är SSE-S3, SSE-C eller SSE-KMS. Amazon har fantastiska SSE-funktioner att erbjuda som hanterar kryptering av data i vila. Du kan börja här som tar itu med hur S3 använder AWS KMS. Om du flyttar din säkerhetskopia till en volym- eller blockbaserad lagring har AWS EBS-kryptering också med AWS KMS. Du kan kolla här för mer information om detta.

Microsoft Azure har även coola funktioner när du hanterar data i vila. Kolla in sidan om "Azure Storage Service Encryption for data at rest". Azure hanterar nycklarna i deras Azure Key Vault, samma som AWS KMS. För Google-kryptering för data i vila kan du kolla här.

När du lagrar säkerhetskopior på plats kan du använda LUKS (Linux Unified Key Setup) med en kombination av crypt eller dmcrypt. Jag kommer inte att diskutera detta på den här bloggen men det här är en bra källa att titta på:MySQL Encryption at Rest – Del 1 (LUKS). För mer information om diskkryptering, är denna ArchLinux-sida "Diskkryptering" en bra källa att börja .

Viktigast av allt, medan din data har krypterats i vila och under transport, verifiera alltid att din säkerhetskopiering fungerar. En säkerhetskopia som inte har testats är inte en säkerhetskopia om den inte fungerar när återställning behövs. Att även lagra din säkerhetskopia medan den är krypterad måste dekrypteras utan problem, därför måste dina nycklar lagras privat och på det säkraste sättet som möjligt. Att lägga till kryptering till dina data, såsom InnoDB-kryptering eller SST (för Galera) ger dessutom mer säkerhet, men vi kommer inte att behandla dessa i den här bloggen.

Slutsats

Kryptering av säkerhetskopieringsdata i vila och under transport är viktiga komponenter för överensstämmelse med PHI, HIPAA, PCI DSS eller GDPR, för att säkerställa att känslig data som överförs över tråden eller sparas på diskar inte är läsbar av någon användare eller applikation utan en giltig nyckel. Vissa efterlevnadsbestämmelser som PCI DSS och HIPAA kräver att data i vila krypteras under hela datans livscykel.

Här visar vi hur ClusterControl erbjuder dessa alternativ till slutanvändaren. Efterlevnad är dock en enorm uppgift som berör många olika områden. Regelverk uppdateras också regelbundet och processer/verktyg behöver också uppdateras därefter. Vi förbättrar kontinuerligt olika områden i ClusterControl för att underlätta efterlevnad. Vi vill gärna höra dina tankar om detta och hur vi kan förbättra.