Backuplagring utanför platsen bör vara en kritisk del av alla organisationers katastrofåterställningsplan. Möjligheten att lagra data på en separat fysisk plats, där den skulle kunna överleva en katastrofal händelse som förstör all data i ditt primära datacenter, säkerställer din dataöverlevnad och kontinuitet i din organisation. En molnlagringstjänst är en ganska bra metod för att lagra säkerhetskopior utanför platsen. Oavsett om du använder en molnleverantör eller om du bara kopierar data till ett externt datacenter, är säkerhetskopieringskrypteringen ett måste i sådana fall. I en av våra tidigare bloggar diskuterade vi flera metoder för att kryptera dina säkerhetskopior. Idag kommer vi att fokusera på några bästa metoder kring kryptering av säkerhetskopiering.
Se till att dina hemligheter är säkra
För att kryptera och dekryptera dina data måste du använda något slags lösenord eller nyckel. Beroende på krypteringsmetoden (symmetrisk eller asymmetrisk) kan det vara en hemlighet för både kryptering och dekryptering eller så kan det vara en offentlig nyckel för kryptering och en privat nyckel för dekryptering. Vad som är viktigt, du bör hålla dem säkra. Om du råkar använda asymmetrisk kryptering bör du fokusera på den privata nyckeln, den du kommer att använda för att dekryptera säkerhetskopior.
Du kan lagra nycklar i ett nyckelhanteringssystem eller ett valv - det finns många alternativ på marknaden att välja mellan som Amazons KMS eller Hashicorps valv. Även om du bestämmer dig för att inte använda dessa lösningar, bör du fortfarande tillämpa allmänna säkerhetsrutiner som att säkerställa att endast rätt användare kan komma åt dina nycklar och lösenord. Du bör också överväga att förbereda dina säkerhetskopieringsskript på ett sätt så att du inte exponerar nycklar eller lösenord i listan över pågående processer. Lägg dem helst i filen istället för att skicka dem som ett argument till vissa kommandon.
Överväg asymmetrisk kryptering
Den största skillnaden mellan symmetrisk och asymmetrisk kryptering är att medan du använder symmetrisk kryptering för både kryptering och dekryptering, använder du en enda nyckel eller lösenord. Detta kräver högre säkerhetsstandarder i båda ändarna av processen. Du måste se till att värden som du krypterar data på är mycket säker eftersom en läcka av den symmetriska krypteringsnyckeln ger tillgång till alla dina krypterade säkerhetskopior.
Å andra sidan, om du använder asymmetrisk kryptering har du två nycklar:den offentliga nyckeln för att kryptera data och den privata nyckeln för dekryptering. Detta gör saker så mycket enklare - du behöver egentligen inte bry dig om den offentliga nyckeln. Även om det skulle äventyras, kommer det fortfarande inte att tillåta någon form av åtkomst till data från säkerhetskopior. Du måste bara fokusera på säkerheten för den privata nyckeln. Det är enklare – du krypterar med största sannolikhet säkerhetskopior dagligen (om inte oftare) medan återställning sker då och då, vilket gör det möjligt att lagra den privata nyckeln på en säkrare plats (även på en dedikerad fysisk enhet). Nedan är ett mycket snabbt exempel på hur du kan använda gpg för att generera ett nyckelpar och använda det för att kryptera data.
Först måste du skapa nycklarna:
[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.Detta skapade både offentliga och privata nycklar. Därefter vill du exportera din publika nyckel för att använda för att kryptera data:
gpg --armor --export [email protected] > mybackupkey.ascDärefter kan du använda den för att kryptera din säkerhetskopia.
[email protected]:~# xtrabackup --backup --stream=xbstream | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backupSlutligen, ett exempel på hur du kan använda din primära nyckel (i det här fallet är den lagrad i den lokala nyckelringen) för att dekryptera dina säkerhetskopior:
[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]>"Rotera dina krypteringsnycklar
Oavsett vilken typ av kryptering du implementerat, symmetrisk eller asymmetrisk, måste du tänka på nyckelrotationen. Först och främst är det mycket viktigt att ha en mekanism på plats för att rotera nycklarna. Detta kan vara användbart i händelse av ett säkerhetsintrång, och du måste snabbt ändra nycklar som du använder för säkerhetskopiering och dekryptering. Naturligtvis, i händelse av ett säkerhetsintrång måste du överväga vad som kommer att hända med de gamla säkerhetskopiorna som krypterades med komprometterade nycklar. De har äventyrats även om de fortfarande kan vara användbara och krävs enligt återställningspunktsmålet. Det finns ett par alternativ, inklusive att kryptera om dem eller flytta dem till en lokalisering som inte är komprometterad.
Öppna krypteringsprocessen genom att parallellisera den
Om du har ett alternativ att implementera parallellisering av krypteringsprocessen, överväg det. Krypteringsprestanda beror mestadels på CPU-kraften, vilket gör att fler CPU-kärnor kan arbeta parallellt för att kryptera filen bör resultera i mycket kortare krypteringstider. Vissa av krypteringsverktygen ger ett sådant alternativ. En av dem är xtrabackup som har en möjlighet att använda inbäddad kryptering och parallellisera processen.
Det du letar efter är antingen "--encrypt-key" eller "--encrypt-key-file" alternativ som möjliggör inbäddad kryptering. Medan du gör det kan du också definiera "--encrypt-threads" och "--encrypt-chunk-size". För det andra ökar en arbetsbuffert för kryptering, först definierar hur många trådar som ska användas för kryptering.
Naturligtvis är detta bara en av lösningarna du kan implementera. Du kan uppnå detta med hjälp av skalverktyg. Ett exempel nedan:
[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{}"'Detta är inte på något sätt en perfekt lösning eftersom du måste veta i förväg hur stor, mer eller mindre, backupen kommer att vara för att dela upp den till fördefinierat antal filer som matchar den parallelliseringsnivå du vill uppnå (om du vill använda 2 CPU kärnor, bör du ha två filer, om du vill använda 4 kärnor, 4 filer etc). Det kräver också diskutrymme som är dubbelt så stort som säkerhetskopian, eftersom det först genererar flera filer med split och sedan kryptering skapar ytterligare en uppsättning krypterade filer. Å andra sidan, om din datamängdsstorlek är acceptabel och du vill förbättra krypteringsprestandan, är det ett alternativ du kan överväga. För att dekryptera säkerhetskopian måste du dekryptera var och en av de enskilda filerna och sedan använda "cat" för att sammanfoga dem.
Testa dina säkerhetskopior
Oavsett hur du ska implementera säkerhetskopieringskrypteringen måste du testa den. Först och främst måste alla säkerhetskopior testas, krypterade eller inte. Säkerhetskopieringar kanske inte är kompletta eller kan lida av någon typ av korruption. Du kan inte vara säker på att din säkerhetskopia kan återställas förrän du faktiskt utför återställningen. Det är därför regelbunden säkerhetskopiering är ett måste. Kryptering gör säkerhetskopieringsprocessen mer komplex. Problem kan dyka upp vid krypteringstillfället, igen - buggar eller fel kan förstöra de krypterade filerna. När den väl är krypterad är frågan om det är möjligt att dekryptera och återställa det?
Du bör ha en återställningstestprocess på plats. Helst skulle återställningstestet utföras efter varje säkerhetskopiering. Som ett minimum bör du testa dina säkerhetskopior ett par gånger per år. Definitivt måste du testa det så snart en förändring i säkerhetskopieringsprocessen hade införts. Har du lagt till komprimering till säkerhetskopian? Har du ändrat krypteringsmetoden? Roterade du krypteringsnyckeln? Alla dessa åtgärder kan ha viss inverkan på din förmåga att faktiskt återställa din säkerhetskopia. Därför bör du se till att du testar hela processen efter varje förändring.
ClusterControl kan automatisera verifieringsprocessen, både på begäran eller schemalagd efter varje säkerhetskopiering.
För att verifiera en befintlig säkerhetskopia behöver du bara välja den från listan, klicka på alternativet "Återställ" och sedan gå igenom återställningsguiden. Först måste du verifiera vilken säkerhetskopia du vill återställa.
Sedan, i nästa steg, bör du välja alternativet för återställning och verifiering.
Du måste skicka lite information om värden som du vill testa återställningen på. Den måste vara tillgänglig via SSH från ClusterControl-instansen. Du kan bestämma dig för att hålla återställningstestservern igång (och sedan dumpa delar av data från den om du vill göra en partiell återställning) eller stänga av den.
Det sista steget handlar om att verifiera om du gjort rätt val. Om ja, kan du starta säkerhetskopieringsverifieringsjobbet.
Om verifieringen slutfördes kommer du att se att säkerhetskopian är markerad som verifierad på listan över säkerhetskopior.
Om du vill automatisera denna process är det också möjligt med ClusterControl. När du schemalägger säkerhetskopieringen kan du aktivera säkerhetskopieringsverifiering:
Detta lägger till ytterligare ett steg i schemaläggningsguiden för säkerhetskopiering.
Här måste du återigen definiera värddatorn som du vill använda för backup-återställningstester, bestämma om du vill installera programvaran på den (eller kanske du redan har det gjort), om du vill hålla återställningsservern uppe och om du vill testa säkerhetskopian direkt efter att den är klar eller kanske du vill vänta lite.