Offsite backup-lagring bør være en kritisk del af enhver organisations katastrofegenopretningsplan. Muligheden for at gemme data på et separat fysisk sted, hvor det kunne overleve en katastrofal hændelse, som ødelægger alle data i dit primære datacenter, sikrer din dataoverlevelse og kontinuitet i din organisation. En cloud-lagringstjeneste er en ganske god metode til at gemme sikkerhedskopier uden for webstedet. Lige meget om du bruger en cloud-udbyder, eller om du blot kopierer data til et eksternt datacenter, er backup-krypteringen et must i sådanne tilfælde. I en af vores tidligere blogs diskuterede vi flere metoder til at kryptere dine sikkerhedskopier. I dag vil vi fokusere på nogle bedste fremgangsmåder omkring backup-kryptering.
Sørg for, at dine hemmeligheder er sikre
For at kryptere og dekryptere dine data skal du bruge en form for adgangskode eller en nøgle. Afhængigt af krypteringsmetoden (symmetrisk eller asymmetrisk), kan det være én hemmelighed til både kryptering og dekryptering, eller det kan være en offentlig nøgle til kryptering og en privat nøgle til dekryptering. Hvad der er vigtigt, bør du opbevare dem sikkert. Hvis du tilfældigvis bruger asymmetrisk kryptering, bør du fokusere på den private nøgle, den du vil bruge til at dekryptere sikkerhedskopier.
Du kan gemme nøgler i et nøglestyringssystem eller en boks - der er adskillige muligheder på markedet at vælge imellem som Amazons KMS eller Hashicorp's Vault. Selvom du beslutter dig for ikke at bruge disse løsninger, bør du stadig anvende generisk sikkerhedspraksis som for at sikre, at kun de korrekte brugere kan få adgang til dine nøgler og adgangskoder. Du bør også overveje at forberede dine backup-scripts på en måde, så du ikke vil afsløre nøgler eller adgangskoder på listen over kørende processer. Ideelt set skal du placere dem i filen i stedet for at sende dem som et argument til nogle kommandoer.
Overvej asymmetrisk kryptering
Den største forskel mellem symmetrisk og asymmetrisk kryptering er, at mens du bruger symmetrisk kryptering til både kryptering og dekryptering, bruger du en enkelt nøgle eller adgangskode. Dette kræver højere sikkerhedsstandarder i begge ender af processen. Du skal sørge for, at værten, som du krypterer dataene på, er meget sikker, da et læk af den symmetriske krypteringsnøgle vil give adgang til alle dine krypterede sikkerhedskopier.
På den anden side, hvis du bruger asymmetrisk kryptering, har du to nøgler:den offentlige nøgle til kryptering af data og den private nøgle til dekryptering. Dette gør tingene så meget nemmere - du behøver ikke rigtig at bekymre dig om den offentlige nøgle. Selvom det ville blive kompromitteret, vil det stadig ikke tillade nogen form for adgang til dataene fra sikkerhedskopier. Du skal kun fokusere på sikkerheden af den private nøgle. Det er nemmere - du krypterer højst sandsynligt sikkerhedskopier på daglig basis (hvis ikke hyppigere), mens gendannelse sker fra tid til anden, hvilket gør det muligt at gemme den private nøgle på et mere sikkert sted (selv på en dedikeret fysisk enhed). Nedenfor er et meget hurtigt eksempel på, hvordan du kan bruge gpg til at generere et nøglepar og bruge det til at kryptere data.
Først skal du generere nøglerne:
[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.Dette skabte både offentlige og private nøgler. Dernæst vil du eksportere din offentlige nøgle til at bruge til at kryptere dataene:
gpg --armor --export [email protected] > mybackupkey.ascDernæst kan du bruge den til at kryptere din sikkerhedskopi.
[email protected]:~# xtrabackup --backup --stream=xbstream | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backupTil sidst et eksempel på, hvordan du kan bruge din primære nøgle (i dette tilfælde er den gemt i den lokale nøglering) til at dekryptere dine sikkerhedskopier:
[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]>"Rotér dine krypteringsnøgler
Uanset hvilken slags kryptering du implementerede, symmetrisk eller asymmetrisk, skal du tænke på nøglerotationen. Først og fremmest er det meget vigtigt at have en mekanisme på plads til at dreje tasterne. Dette kan være nyttigt i tilfælde af et sikkerhedsbrud, og du skal hurtigt ændre nøgler, som du bruger til backup-kryptering og dekryptering. I tilfælde af et sikkerhedsbrud skal du selvfølgelig overveje, hvad der skal ske med de gamle sikkerhedskopier, som blev krypteret med kompromitterede nøgler. De er blevet kompromitteret, selvom de stadig kan være nyttige og krævede i henhold til Recovery Point-målsætningen. Der er et par muligheder, herunder genkryptering af dem eller flytning af dem til en ikke-kompromitteret lokalisering.
Fremskynd krypteringsprocessen ved at parallelisere den
Hvis du har mulighed for at implementere parallelisering af krypteringsprocessen, så overvej det. Krypteringsydeevnen afhænger for det meste af CPU-kraften, således at tillade flere CPU-kerner at arbejde parallelt for at kryptere filen burde resultere i meget kortere krypteringstider. Nogle af krypteringsværktøjerne giver en sådan mulighed. En af dem er xtrabackup, som har mulighed for at bruge indlejret kryptering og parallelisere processen.
Det, du leder efter, er enten "--encrypt-key" eller "--encrypt-key-file", som aktiverer indlejret kryptering. Mens du gør det, kan du også definere "--encrypt-threads" og "--encrypt-chunk-size". For det andet øger en arbejdsbuffer til kryptering, definerer først hvor mange tråde der skal bruges til kryptering.
Dette er selvfølgelig kun en af de løsninger, du kan implementere. Du kan opnå dette ved hjælp af skalværktøjer. Et eksempel nedenfor:
[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{}"'Dette er på ingen måde en perfekt løsning, da du på forhånd skal vide, hvor stor, mere eller mindre, backup'en vil være for at opdele den til et foruddefineret antal filer, der matcher det paralleliseringsniveau, du ønsker at opnå (hvis du vil bruge 2 CPU'er kerner, skal du have to filer, hvis du vil bruge 4 kerner, 4 filer osv.). Den kræver også diskplads, der er dobbelt så stor som sikkerhedskopien, da den først genererer flere filer ved hjælp af split og derefter kryptering skaber endnu et sæt krypterede filer. På den anden side, hvis din datasætstørrelse er acceptabel, og du gerne vil forbedre krypteringsydelsen, er det en mulighed, du kan overveje. For at dekryptere sikkerhedskopien bliver du nødt til at dekryptere hver af de individuelle filer og derefter bruge 'cat' til at forbinde dem.
Test dine sikkerhedskopier
Uanset hvordan du skal implementere backupkrypteringen, skal du teste den. Først og fremmest skal alle sikkerhedskopier testes, krypteret eller ej. Sikkerhedskopier er muligvis ikke fuldstændige, eller de kan lide af en eller anden form for korruption. Du kan ikke være sikker på, at din sikkerhedskopi kan gendannes, før du rent faktisk udfører gendannelsen. Derfor er regelmæssig backupverifikation et must. Kryptering tilføjer mere kompleksitet til backup-processen. Problemer kan dukke op på krypteringstidspunktet igen - fejl eller fejl kan ødelægge de krypterede filer. Når den er krypteret, er spørgsmålet så, om det er muligt at dekryptere det og gendanne det?
Du bør have en gendannelsestestproces på plads. Ideelt set ville gendannelsestesten blive udført efter hver sikkerhedskopiering. Som minimum bør du teste dine sikkerhedskopier et par gange om året. Du skal helt sikkert teste det, så snart en ændring i backup-processen var blevet introduceret. Har du tilføjet komprimering til sikkerhedskopien? Ændrede du krypteringsmetoden? Roterede du krypteringsnøglen? Alle disse handlinger kan have en vis indflydelse på din evne til faktisk at gendanne din sikkerhedskopi. Derfor bør du sørge for at teste hele processen efter hver ændring.
ClusterControl kan automatisere verifikationsprocessen, både efter behov eller planlagt efter hver sikkerhedskopiering.
For at bekræfte en eksisterende sikkerhedskopi skal du blot vælge den fra listen, klikke på "Gendan" og derefter gå gennem gendannelsesguiden. Først skal du bekræfte, hvilken sikkerhedskopi du vil gendanne.
Derefter skal du på næste trin vælge gendannelses- og bekræftelsesmuligheden.
Du skal videregive nogle oplysninger om værten, som du vil teste gendannelsen på. Det skal være tilgængeligt via SSH fra ClusterControl-instansen. Du kan beslutte at holde gendannelsestestserveren oppe og køre (og derefter dumpe nogle delvise data fra den, hvis du ønsker at gå til en delvis gendannelse) eller lukke den ned.
Det sidste trin handler om at verificere, om du har truffet de rigtige valg. Hvis ja, kan du starte sikkerhedskopieringsbekræftelsen.
Hvis bekræftelsen er gennemført, vil du se, at sikkerhedskopien er markeret som bekræftet på listen over sikkerhedskopier.
Ønsker du at automatisere denne proces, er det også muligt med ClusterControl. Når du planlægger sikkerhedskopieringen, kan du aktivere sikkerhedskopieringsbekræftelse:
Dette tilføjer endnu et trin i backup-planlægningsguiden.
Her skal du igen definere den vært, som du vil bruge til backup-gendannelsestest, beslutte om du vil installere softwaren på den (eller måske allerede har det gjort), om du vil holde gendannelsesserveren oppe og om du ønsker at teste sikkerhedskopien umiddelbart efter den er færdig eller måske vil du vente lidt.