Het beveiligen van uw gegevens is een van de belangrijkste taken waaraan we prioriteit moeten geven. De opkomst van regelgeving die naleving van de beveiliging vereist, zoals AVG, HIPAA, PCI DSS of PHI, vereist dat uw gegevens veilig worden opgeslagen of via de kabel worden verzonden.
Bij ClusterControl hechten we veel waarde aan beveiliging en bieden we een aantal functies om databasetoegang en opgeslagen gegevens te beveiligen. Een daarvan is het beveiligen van uw databaseback-ups, zowel in rust als onderweg. In-transit is wanneer de back-up via internet of netwerk wordt overgedragen van de bron naar de bestemming, terwijl in rust de gegevens worden opgeslagen op permanente opslag. In deze blog laten we u zien hoe u ClusterControl kunt gebruiken om uw back-upgegevens in rust en onderweg te versleutelen.
Encryptie tijdens transport
Bij het beheren van back-ups via ClusterControl, wordt het gebruik van mysqldump of Percona Xtrabackup/Mariabackup standaard beheerd zonder codering bij verzending via de draad. Het gebruik van TLS/SSL voor de codering van gegevensoverdracht wordt echter ondersteund door MySQL/MariaDB/Percona Server, evenals Percona Xtrabackup, dat SSL-opties biedt bij het aanroepen van de opdracht.
ClusterControl schakelt SSL standaard in wanneer u een cluster implementeert, maar het heeft niet de controle om direct over te schakelen en uw gegevens over de draad te versleutelen tijdens het maken van back-ups. U kunt onze eerdere blogs bekijken voor de handmatige aanpak met ClusterControl bij het maken van uw cluster of de ouderwetse manier om TLS/SSL handmatig in MySQL in te stellen.
Wanneer u in ClusterControl een cluster implementeert, kunt u het tabblad Beveiliging of dit pictogram controleren:
.
Klikken op de Met de knop 
kunt u het certificaat vervangen dat momenteel wordt gebruikt of geïmplementeerd door ClusterControl tijdens de implementatie van uw nieuw ingerichte TROS. U kunt deze blog "Updated:Word ClusterControl DBA - SSL Key Management and Encryption of MySQL Data in Transit" raadplegen, waarin we hebben laten zien hoe we met de sleutels omgaan. In principe kunt u door de linkernavigatie van ClusterControl gaan en op "Sleutelbeheer" klikken.
Hieronder ziet u een voorbeeld van sleutelbeheer waarin u uw bestaande sleutels kunt maken en importeren.
Wanneer u een back-up maakt met mysqldump als uw logische back-up, moet u ervoor zorgen dat uw SSL-opties dienovereenkomstig zijn ingesteld om uw gegevens te versleutelen.
Wat nu?
Omdat we onze gemaakte certificaten hebben, moeten we SSL dienovereenkomstig inschakelen en instellen. Om dit te garanderen, kunt u dit controleren via ClusterControl of mysql-opdrachtprompt. Zie onderstaande afbeeldingen:
of je kunt ook kijken onder het tabblad Prestaties en op DB-variabelen klikken, zoals hieronder te zien is:
Houd er rekening mee dat het enige tijd kan duren om te vullen onder de Prestaties -> DB-variabelen. Dus als u handmatig wilt controleren, kunt u de mysql-opdrachtprompt gebruiken zoals hieronder:
Het definiëren van uw ssl_cipher kan meer beveiligingsverharding toevoegen. Er is een lijst met coderingssuites als u SHOW GLOBAL STATUS LIKE 'Ssl_cipher_list'\G uitvoert of hier kijkt. Een coderingssuite is een combinatie van algoritmen voor authenticatie, codering en berichtauthenticatiecode (MAC). Deze worden gebruikt tijdens het onderhandelen over beveiligingsinstellingen voor een TLS/SSL-verbinding en voor de veilige overdracht van gegevens.
Aangezien ClusterControl mysqldump lokaal op die host uitvoert, voegt u de volgende parameters (zie hieronder) toe aan uw MySQL-configuratiebestand (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) versleutelt alle acties voor SQL-dump. Zie hieronder:
[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.pemJe kunt proberen te monitoren met tcpdump en je kunt hieronder zien in vergelijking met een niet-versleutelde versus versleutelde laag met TLS.
Met TLS/SSL:
Zonder TLS/SSL:
Bij gebruik van Percona XtraBackup of Mariabackup onder ClusterControl is er op dit moment geen TLS/SSL-ondersteuning wanneer de back-up via het netwerk wordt verzonden. Het gebruikt socat die in feite gewoon een poort naar een ander knooppunt opent als communicatiemiddel.
bijv.
[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.Als u tijdens het transport een beveiligde laag nodig heeft, kunt u dit handmatig doen met --ssl*-opties tijdens het aanroepen van de opdracht. Bekijk hier de Percona XtraBackup handleiding voor meer info. We raden u toch aan om uw certificaat/sleutel te verkrijgen bij een geregistreerde certificeringsinstantie.
Als alternatief kunt u met ClusterControl uw gegevens versleutelen voordat ze via het netwerk worden verzonden. De verzonden pakketten zijn geen onbewerkte maar versleutelde gegevens. Hoewel de codering afhankelijk is van in-rest, zullen we dit in de volgende sectie bespreken.
Encryptie in rust
In ClusterControl heeft u bij het maken van uw back-up de mogelijkheid om uw gegevens versleuteld te maken. Zie hieronder:
Bij versleuteling gebruikt ClusterControl de "Advance Encryption Standard" AES-256-CBC. Zie het voorbeeldlogboek hieronder:
[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.Als u uw back-up in de cloud opslaat, bijvoorbeeld met AWS S3, biedt S3 drie verschillende modi van server-side encryptie (SSE). Dit zijn SSE-S3, SSE-C of SSE-KMS. Amazon heeft geweldige SSE-functies te bieden die de versleuteling van gegevens in rust verwerken. U kunt hier beginnen, waarin wordt uitgelegd hoe S3 AWS KMS gebruikt. Als u uw back-up naar een volume of blokgebaseerde opslag verplaatst, heeft AWS ook EBS-codering met behulp van AWS KMS. Je kunt hier kijken voor meer informatie hierover.
Microsoft Azure heeft ook coole functies bij het verwerken van gegevens in rust. Bekijk de pagina over "Azure Storage Service Encryption for data at rest". Azure verwerkt de sleutels in hun Azure Key Vault, hetzelfde als AWS KMS. Voor Google-versleuteling voor gegevens in rust kunt u hier kijken.
Wanneer u gegevensback-ups op locatie opslaat, kunt u LUKS (Linux Unified Key Setup) gebruiken met een combinatie van crypt of dmcrypt. Ik zal hier niet over praten op deze blog, maar dit is een goede bron om naar te kijken:MySQL Encryption at Rest – Part 1 (LUKS). Voor meer informatie over schijfversleuteling is deze ArchLinux-pagina "Schijfversleuteling" een geweldige bron om te beginnen.
Het belangrijkste is dat, hoewel uw gegevens in rust en onderweg zijn versleuteld, u altijd moet controleren of uw back-up werkt. Een back-up die niet is getest, is geen back-up als deze niet werkt wanneer herstel nodig is. Het ook versleuteld opslaan van uw back-up moet zonder problemen worden ontsleuteld, dus uw sleutels moeten privé en op de meest veilige manier worden opgeslagen. Bovendien voegt het toevoegen van versleuteling aan uw gegevens, zoals InnoDB-versleuteling of SST (voor Galera), meer veiligheid toe, maar we behandelen deze niet in deze blog.
Conclusie
Het versleutelen van back-upgegevens in rust en onderweg zijn essentiële componenten voor naleving van PHI, HIPAA, PCI DSS of AVG, om ervoor te zorgen dat gevoelige gegevens die via de kabel worden verzonden of op schijven worden opgeslagen, niet leesbaar zijn voor een gebruiker of toepassing zonder een geldige sleutel. Sommige nalevingsvoorschriften, zoals PCI DSS en HIPAA, vereisen dat gegevens in rust gedurende de hele levenscyclus van gegevens worden versleuteld.
Hier laten we zien hoe ClusterControl deze mogelijkheden biedt aan de eindgebruiker. Naleving is echter een enorme taak, die veel verschillende gebieden raakt. Regelgeving wordt ook regelmatig bijgewerkt en processen/tools moeten ook dienovereenkomstig worden bijgewerkt. We verbeteren continu verschillende gebieden in ClusterControl om naleving te vergemakkelijken. We horen graag uw mening hierover en hoe we dit kunnen verbeteren.