We zorgen meestal voor dingen die we waarderen, of het nu een dure smartphone is of de servers van het bedrijf. Data is een van de belangrijkste assets van de organisatie, en hoewel we het niet zien, moet het zorgvuldig worden beschermd. We implementeren data-at-rest-codering om databasebestanden of hele volumes die onze gegevens bevatten te coderen. We implementeren data-in-transit-codering met SSL om ervoor te zorgen dat niemand gegevens kan opsnuiven en verzamelen die via netwerken worden verzonden. Back-ups zijn niet anders. Het maakt niet uit of dit een volledige back-up of incrementele back-up is, het zal ten minste een deel van uw gegevens opslaan. Als zodanig moeten back-ups ook worden gecodeerd. In deze blogpost zullen we enkele opties bekijken die u mogelijk heeft als het gaat om het versleutelen van back-ups. Laten we echter eerst eens kijken hoe u uw back-ups kunt versleutelen en welke toepassingen voor deze methoden kunnen worden gebruikt.
Hoe versleutelt u uw back-up?
Lokaal bestand coderen
Allereerst kun je bestaande bestanden eenvoudig versleutelen. Stel je voor dat je een back-upproces hebt dat al je back-ups op een back-upserver opslaat. Op een gegeven moment besloot je dat het de hoogste tijd was om externe back-upopslag te implementeren voor noodherstel. U kunt daarvoor gebruik maken van S3 of vergelijkbare infrastructuur van andere cloudaanbieders. Natuurlijk wilt u niet-versleutelde back-ups ergens buiten uw vertrouwde netwerk uploaden, daarom is het van cruciaal belang dat u op de een of andere manier back-upversleuteling implementeert. Een zeer eenvoudige methode, waarvoor geen wijzigingen in uw bestaande back-upscripts nodig zijn, is om een script te maken dat een back-upbestand maakt, dit versleutelt en uploadt naar S3. Een van de methoden die u kunt gebruiken om de gegevens te versleutelen, is door openssl te gebruiken:
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordDit zal een nieuw, versleuteld bestand maken, 'backup_file.tar.gz.enc' in de huidige map. Je kunt het later altijd ontsleutelen door het volgende uit te voeren:
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordDeze methode is heel eenvoudig, maar heeft enkele nadelen. De grootste is de schijfruimtevereisten. Bij het versleutelen zoals we hierboven beschreven, moet je zowel een niet-versleuteld als een versleuteld bestand bewaren, met als resultaat dat je een schijfruimte nodig hebt die twee keer zo groot is als het back-upbestand. Afhankelijk van uw vereisten kan dit natuurlijk iets zijn dat u wilt - niet-versleutelde bestanden lokaal bewaren zal de herstelsnelheid verbeteren - het ontsleutelen van de gegevens zal immers ook enige tijd in beslag nemen.
Versleutel back-up on-the-fly
Om te voorkomen dat u zowel versleutelde als niet-versleutelde gegevens moet opslaan, kunt u de versleuteling in een vroeger stadium van het back-upproces implementeren. Dat kunnen we via leidingen. Pipes zijn, kortom, een manier om de gegevens van het ene commando naar het andere te sturen. Dit maakt het mogelijk om een reeks commando's te creëren die gegevens verwerkt. U kunt de gegevens genereren, deze vervolgens comprimeren en versleutelen. Een voorbeeld van zo'n keten kan zijn:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encU kunt deze methode ook gebruiken met xtrabackup of mariabackup. In feite is dit het voorbeeld uit MariaDB-documentatie:
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.encAls je wilt, kun je zelfs proberen om gegevens te uploaden als onderdeel van het proces:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mysecretpassword | tee -a mysqldump.gz.enc | nc 10.0.0.102 9991Als resultaat ziet u een lokaal bestand 'mysqldump.gz.enc' en een kopie van de gegevens wordt doorgesluisd naar een programma dat er iets aan doet. We gebruikten 'nc', die gegevens naar een andere host streamde waarop het volgende werd uitgevoerd:
nc -l 9991 > backup.gz.encIn dit voorbeeld hebben we mysqldump en nc gebruikt, maar je kunt xtrabackup of mariabackup gebruiken en een tool die de stream uploadt naar Amazon S3, Google Cloud Storage of een andere cloudprovider. Elk programma of script dat gegevens op stdin accepteert, kan worden gebruikt in plaats van 'nc'.
Gebruik ingesloten codering
In sommige gevallen heeft een back-uptool ingebouwde ondersteuning voor codering. Een voorbeeld hiervan is xtrabackup, dat het bestand intern kan versleutelen. Helaas ondersteunt mariabackup, hoewel het een afsplitsing van xtrabackup is, deze functie niet.
Voordat we het kunnen gebruiken, moeten we een sleutel maken die zal worden gebruikt om de gegevens te versleutelen. Dit kan gedaan worden door het volgende commando uit te voeren:
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackup kan de sleutel in platte tekstindeling accepteren (met de optie --encrypt-key) of het kan deze uit een bestand lezen (met de optie --encrypt-key-file). Dit laatste is veiliger omdat het doorgeven van wachtwoorden en sleutels als platte tekst aan commando's resulteert in het opslaan in de bash-geschiedenis. Je kunt het ook duidelijk zien op de lijst met lopende processen, wat nogal slecht is:
root 1130 0.0 0.6 65508 4988 ? Ss 00:46 0:00 /usr/sbin/sshd -D
root 13826 0.0 0.8 93100 6648 ? Ss 01:26 0:00 \_ sshd: [email protected]
root 25363 0.0 0.8 92796 6700 ? Ss 08:54 0:00 \_ sshd: vagrant [priv]
vagrant 25393 0.0 0.6 93072 4936 ? S 08:54 0:01 | \_ sshd: [email protected]/1
vagrant 25394 0.0 0.4 21196 3488 pts/1 Ss 08:54 0:00 | \_ -bash
root 25402 0.0 0.4 52700 3568 pts/1 S 08:54 0:00 | \_ sudo su -
root 25403 0.0 0.4 52284 3264 pts/1 S 08:54 0:00 | \_ su -
root 25404 0.0 0.4 21196 3536 pts/1 S 08:54 0:00 | \_ -su
root 26686 6.0 4.0 570008 30980 pts/1 Sl+ 09:48 0:00 | \_ innobackupex --encrypt=AES256 --encrypt-key=TzIZ7g+WzLt0PXWf8WDPf/sjIt7UzCKw /backup/In het ideale geval gebruikt u de sleutel die in een bestand is opgeslagen, maar dan is er een klein probleem waar u rekening mee moet houden.
[email protected]:~# openssl rand -base64 24 > encrypt.key
[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
.
.
.
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
encryption: unable to set libgcrypt cipher key - User defined source 1 : Invalid key length
encrypt: failed to create worker threads.
Error: failed to initialize datasink.Je kunt je afvragen wat het probleem is. Het zal duidelijk worden wanneer we het encrypt.key-bestand openen in een hexadecimale editor zoals hexedit:
00000000 6D 6B 2B 4B 66 69 55 4E 5A 49 48 77 39 42 36 72 68 70 39 79 6A 56 44 72 47 61 79 45 6F 75 6D 70 0A mk+KfiUNZIHw9B6rhp9yjVDrGayEoump.U kunt nu het laatste teken zien dat is gecodeerd met '0A'. Dit is in feite het regelinvoerteken, maar er wordt rekening mee gehouden bij het evalueren van de coderingssleutel. Zodra we het hebben verwijderd, kunnen we eindelijk de back-up uitvoeren.
[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1
xtrabackup: recognized client arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1 --databases-exclude=lost+found --ssl-mode=DISABLED
encryption: using gcrypt 1.6.5
181116 10:11:25 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
181116 10:11:25 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock' as 'backupuser' (using password: YES).
181116 10:11:25 version_check Connected to MySQL server
181116 10:11:25 version_check Executing a version check against the server...
181116 10:11:25 version_check Done.
181116 10:11:25 Connecting to MySQL server host: localhost, user: backupuser, password: set, port: not set, socket: /var/lib/mysql/mysql.sock
Using server version 5.7.23-23-57
innobackupex version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 67108864
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
181116 10:11:25 >> log scanned up to (2597648)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 19 for mysql/server_cost, old maximum was 0
181116 10:11:25 [01] Encrypting ./ibdata1 to /backup/2018-11-16_10-11-25/ibdata1.xbcrypt
181116 10:11:26 >> log scanned up to (2597648)
181116 10:11:27 >> log scanned up to (2597648)
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/server_cost.ibd to /backup/2018-11-16_10-11-25/mysql/server_cost.ibd.xbcrypt
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/help_category.ibd to /backup/2018-11-16_10-11-25/mysql/help_category.ibd.xbcrypt
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/slave_master_info.ibd to /backup/2018-11-16_10-11-25/mysql/slave_master_info.ibd.xbcrypt
181116 10:11:28 [01] ...doneAls resultaat zullen we eindigen met een back-upmap vol met versleutelde bestanden:
[email protected]:~# ls -alh /backup/2018-11-16_10-11-25/
total 101M
drwxr-x--- 5 root root 4.0K Nov 16 10:11 .
drwxr-xr-x 16 root root 4.0K Nov 16 10:11 ..
-rw-r----- 1 root root 580 Nov 16 10:11 backup-my.cnf.xbcrypt
-rw-r----- 1 root root 515 Nov 16 10:11 ib_buffer_pool.xbcrypt
-rw-r----- 1 root root 101M Nov 16 10:11 ibdata1.xbcrypt
drwxr-x--- 2 root root 4.0K Nov 16 10:11 mysql
drwxr-x--- 2 root root 12K Nov 16 10:11 performance_schema
drwxr-x--- 2 root root 12K Nov 16 10:11 sys
-rw-r----- 1 root root 113 Nov 16 10:11 xtrabackup_checkpoints
-rw-r----- 1 root root 525 Nov 16 10:11 xtrabackup_info.xbcrypt
-rw-r----- 1 root root 2.7K Nov 16 10:11 xtrabackup_logfile.xbcryptXtrabackup heeft enkele andere variabelen die kunnen worden gebruikt om de versleutelingsprestaties af te stemmen:
- --encrypt-threads zorgt voor parallellisatie van het coderingsproces
- --encrypt-chunk-size definieert een werkbuffer voor het versleutelingsproces.
Mocht u de bestanden moeten decoderen, dan kunt u daarvoor innobackupex gebruiken met --decrypt optie:
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/Omdat xtrabackup versleutelde bestanden niet opschoont, kunt u ze wellicht verwijderen met de volgende one-liner:
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneBack-up encryptie in ClusterControl
Met ClusterControl zijn versleutelde back-ups slechts één klik verwijderd. Alle back-upmethoden (mysqldump, xtrabackup of mariabackup) ondersteunen encryptie. U kunt allebei ad-hoc een back-up maken of u kunt een planning voor uw back-ups maken.
In ons voorbeeld hebben we een volledige xtraback-up gekozen, we zullen deze op de controller-instantie opslaan.
Op de volgende pagina hebben we de codering ingeschakeld. Zoals gezegd maakt ClusterControl automatisch een encryptiesleutel voor ons aan. Dit is het, wanneer u op de knop "Back-up maken" klikt, wordt een proces gestart.
Nieuwe back-up is zichtbaar in de back-uplijst. Het is gemarkeerd als versleuteld (het slotpictogram).
We hopen dat deze blogpost je enig inzicht geeft in hoe je ervoor kunt zorgen dat je back-ups correct worden versleuteld.