Offsite back-upopslag zou een cruciaal onderdeel moeten zijn van het noodherstelplan van elke organisatie. De mogelijkheid om gegevens op een aparte fysieke locatie op te slaan, waar ze een catastrofale gebeurtenis kunnen overleven die alle gegevens in uw primaire datacenter vernietigt, zorgt voor het voortbestaan van uw gegevens en de continuïteit van uw organisatie. Een cloudopslagservice is een vrij goede methode om offsite back-ups op te slaan. Het maakt niet uit of u een cloudprovider gebruikt of alleen gegevens naar een extern datacenter kopieert, de back-upversleuteling is in dergelijke gevallen een must. In een van onze vorige blogs hebben we verschillende methoden besproken om uw back-ups te versleutelen. Vandaag zullen we ons concentreren op enkele best practices rond back-upversleuteling.
Zorg ervoor dat uw geheimen veilig zijn
Om uw gegevens te coderen en te decoderen, moet u een soort wachtwoord of sleutel gebruiken. Afhankelijk van de versleutelingsmethode (symmetrisch of asymmetrisch), kan het één geheim zijn voor zowel versleuteling als ontsleuteling, of het kan een openbare sleutel zijn voor versleuteling en een privésleutel voor ontsleuteling. Wat belangrijk is, die moet je veilig bewaren. Als u toevallig asymmetrische codering gebruikt, moet u zich concentreren op de privésleutel, degene die u gaat gebruiken voor het decoderen van back-ups.
U kunt sleutels opslaan in een sleutelbeheersysteem of een kluis - er zijn talloze opties op de markt om uit te kiezen, zoals Amazon's KMS of Hashicorp's Vault. Zelfs als u besluit deze oplossingen niet te gebruiken, moet u toch generieke beveiligingspraktijken toepassen om ervoor te zorgen dat alleen de juiste gebruikers toegang hebben tot uw sleutels en wachtwoorden. Overweeg ook om uw back-upscripts zo voor te bereiden dat u geen sleutels of wachtwoorden in de lijst met lopende processen blootlegt. Plaats ze idealiter in het bestand in plaats van ze als argument door te geven aan sommige commando's.
Overweeg asymmetrische versleuteling
Het belangrijkste verschil tussen symmetrische en asymmetrische codering is dat u bij het gebruik van symmetrische codering voor zowel codering als decodering een enkele sleutel of wachtwoord gebruikt. Dit vereist hogere beveiligingsnormen aan beide kanten van het proces. U moet ervoor zorgen dat de host waarop u de gegevens versleutelt zeer veilig is, aangezien een lek van de symmetrische versleutelingssleutel toegang geeft tot al uw versleutelde back-ups.
Aan de andere kant, als u asymmetrische codering gebruikt, hebt u twee sleutels:de openbare sleutel voor het coderen van de gegevens en de privésleutel voor het decoderen. Dit maakt de zaken zoveel gemakkelijker - u hoeft zich niet echt druk te maken over de openbare sleutel. Zelfs als het zou worden gecompromitteerd, zal het nog steeds geen enkele vorm van toegang tot de gegevens van back-ups toestaan. U hoeft zich alleen te concentreren op de beveiliging van de privésleutel. Het is gemakkelijker - u versleutelt waarschijnlijk dagelijks back-ups (zo niet vaker), terwijl herstel van tijd tot tijd plaatsvindt, waardoor het mogelijk wordt om de privésleutel op een veiligere locatie op te slaan (zelfs op een speciaal fysiek apparaat). Hieronder ziet u een heel snel voorbeeld van hoe u gpg kunt gebruiken om een sleutelpaar te genereren en dit te gebruiken om gegevens te versleutelen.
Eerst moet u de sleutels genereren:
[email protected]:~# gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <[email protected]>"
Real name: Krzysztof Ksiazek
Email address: [email protected]
Comment: Backup key
You selected this USER-ID:
"Krzysztof Ksiazek (Backup key) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.Dit creëerde zowel openbare als privésleutels. Vervolgens wilt u uw openbare sleutel exporteren om te gebruiken voor het versleutelen van de gegevens:
gpg --armor --export [email protected] > mybackupkey.ascVervolgens kunt u het gebruiken om uw back-up te versleutelen.
[email protected]:~# xtrabackup --backup --stream=xbstream | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backupTot slot een voorbeeld hoe u uw primaire sleutel (in dit geval opgeslagen in de lokale sleutelring) kunt gebruiken om uw back-ups te decoderen:
[email protected]:/backup# gpg -d /backup/pgp_encrypted.backup | gunzip | xbstream -x
encryption: using gcrypt 1.6.5
You need a passphrase to unlock the secret key for
user: "Krzysztof Ksiazek (Backup key) <[email protected]>"
4096-bit RSA key, ID E047CD69, created 2018-11-19 (main key ID BC341551)
gpg: gpg-agent is not available in this session
gpg: encrypted with 4096-bit RSA key, ID E047CD69, created 2018-11-19
"Krzysztof Ksiazek (Backup key) <[email protected]>"Draai uw versleutelingssleutels
Het maakt niet uit wat voor soort versleuteling je hebt geïmplementeerd, symmetrisch of asymmetrisch, je moet nadenken over de sleutelrotatie. Allereerst is het erg belangrijk om een mechanisme te hebben om de sleutels te draaien. Dit kan handig zijn in het geval van een inbreuk op de beveiliging en u zou snel de sleutels moeten wijzigen die u gebruikt voor back-upversleuteling en -ontsleuteling. Natuurlijk, in het geval van een inbreuk op de beveiliging, moet u overwegen wat er gaat gebeuren met de oude back-ups die werden versleuteld met gecompromitteerde sleutels. Ze zijn gecompromitteerd, hoewel ze nog steeds nuttig kunnen zijn en vereist zijn volgens de Recovery Point-doelstelling. Er zijn een paar opties, waaronder ze opnieuw versleutelen of verplaatsen naar een niet-gecompromitteerde lokalisatie.
Versnel het versleutelingsproces door het te parallelliseren
Als u een optie heeft om parallellisatie van het coderingsproces te implementeren, overweeg deze dan. De coderingsprestaties zijn meestal afhankelijk van de CPU-kracht, dus als meer CPU-kernen parallel kunnen werken om het bestand te coderen, zou dit moeten resulteren in veel kortere coderingstijden. Sommige coderingstools bieden een dergelijke optie. Een daarvan is xtrabackup, dat een optie heeft om embedded encryptie te gebruiken en het proces parallel te laten lopen.
Waar u naar op zoek bent, zijn de opties "--encrypt-key" of "--encrypt-key-file" die ingesloten codering mogelijk maken. Terwijl u dat doet, kunt u ook "--encrypt-threads" en "--encrypt-chunk-size" definiëren. Ten tweede vergroot de werkbuffer voor versleuteling, de eerste bepaalt hoeveel threads moeten worden gebruikt voor versleuteling.
Dit is natuurlijk slechts een van de oplossingen die u kunt implementeren. U kunt dit bereiken met behulp van shell-tools. Een voorbeeld hieronder:
[email protected]:~# files=2 ; mariabackup --user=root --backup --pass=pass --stream=xbstream |split -b 60M - backup ; ls backup* | parallel -j ${files} --workdir "$(pwd)" 'echo "encrypting {}" ; openssl enc -aes-256-cbc -salt -in "{}" -k mypass > "111{}"'Dit is geenszins een perfecte oplossing, aangezien u van tevoren moet weten hoe groot, min of meer, de back-up zal zijn om deze te splitsen in een vooraf gedefinieerd aantal bestanden dat overeenkomt met het parallellisatieniveau dat u wilt bereiken (als u 2 CPU's wilt gebruiken cores, moet u twee bestanden hebben, als u 4 cores, 4 bestanden enz. wilt gebruiken). Het vereist ook schijfruimte die twee keer zo groot is als de back-up, omdat het eerst meerdere bestanden genereert met behulp van split en vervolgens versleuteling een andere set gecodeerde bestanden creëert. Aan de andere kant, als de grootte van uw dataset acceptabel is en u de coderingsprestaties wilt verbeteren, is dat een optie die u kunt overwegen. Om de back-up te decoderen, moet u elk van de afzonderlijke bestanden decoderen en vervolgens 'cat' gebruiken om ze samen te voegen.
Test uw back-ups
Het maakt niet uit hoe je de back-upversleuteling gaat implementeren, je moet het testen. Allereerst moeten alle back-ups worden getest, al dan niet versleuteld. Back-ups zijn mogelijk niet volledig, of hebben mogelijk een vorm van corruptie. U kunt er niet zeker van zijn dat uw back-up kan worden hersteld totdat u het herstel daadwerkelijk uitvoert. Daarom is regelmatige back-upverificatie een must. Versleuteling voegt meer complexiteit toe aan het back-upproces. Er kunnen opnieuw problemen optreden tijdens de versleuteling - bugs of glitches kunnen de versleutelde bestanden beschadigen. Eenmaal gecodeerd, is de vraag of het mogelijk is om het te decoderen en te herstellen?
U moet een hersteltestproces hebben. Idealiter zou de hersteltest na elke back-up worden uitgevoerd. Test uw back-ups minimaal een paar keer per jaar. U moet het beslist testen zodra er een wijziging in het back-upproces is doorgevoerd. Heb je compressie aan de back-up toegevoegd? Heb je de coderingsmethode gewijzigd? Heb je de coderingssleutel gedraaid? Al deze acties kunnen enige invloed hebben op uw vermogen om uw back-up daadwerkelijk te herstellen. Daarom moet u ervoor zorgen dat u het hele proces na elke wijziging test.
ClusterControl kan het verificatieproces automatiseren, zowel op aanvraag als gepland na elke back-up.
Om een bestaande back-up te verifiëren, hoeft u alleen maar degene uit de lijst te kiezen, op de optie "Herstellen" te klikken en vervolgens de herstelwizard te doorlopen. Eerst moet je verifiëren welke back-up je wilt herstellen.
Vervolgens moet u bij de volgende stap de optie herstellen en verifiëren kiezen.
U moet wat informatie doorgeven over de host waarop u het herstel wilt testen. Het moet toegankelijk zijn via SSH vanuit de ClusterControl-instantie. U kunt besluiten om de testserver voor terugzetten draaiende te houden (en er vervolgens een aantal gedeeltelijke gegevens van te dumpen als u voor een gedeeltelijk herstel wilt gaan) of deze af te sluiten.
Bij de laatste stap gaat het erom te verifiëren of je de juiste keuzes hebt gemaakt. Zo ja, dan kunt u de back-upverificatietaak starten.
Als de verificatie met succes is voltooid, ziet u dat de back-up is gemarkeerd als geverifieerd in de lijst met back-ups.
Wil je dit proces automatiseren, dan kan dat ook met ClusterControl. Bij het plannen van de back-up kunt u back-upverificatie inschakelen:
Dit voegt een nieuwe stap toe in de wizard voor het plannen van back-ups.
Hier moet je opnieuw de host definiëren die je wilt gebruiken voor back-uphersteltests, beslissen of je de software erop wilt installeren (of misschien al hebt gedaan), of je de herstelserver in de lucht wilt houden en of je wilt u de back-up direct testen nadat deze is voltooid of wilt u misschien even wachten.