Съхранението на резервни копия извън сайта трябва да бъде критична част от плана за възстановяване при бедствия на всяка организация. Възможността за съхраняване на данни на отделно физическо място, където те биха могли да оцелеят при катастрофално събитие, което унищожава всички данни във вашия основен център за данни, гарантира оцеляването на вашите данни и непрекъснатостта на вашата организация. Услугата за съхранение в облак е доста добър метод за съхраняване на резервни копия извън сайта. Без значение дали използвате облачен доставчик или ако просто копирате данни във външен център за данни, криптирането на архива е задължително в такива случаи. В един от предишните ни блогове обсъдихме няколко метода за криптиране на вашите резервни копия. Днес ще се съсредоточим върху някои най-добри практики за криптиране на архивиране.
Уверете се, че вашите тайни са в безопасност
За да криптирате и декриптирате вашите данни, трябва да използвате някаква парола или ключ. В зависимост от метода на криптиране (симетричен или асиметричен), той може да бъде една тайна както за криптиране, така и за декриптиране или може да бъде публичен ключ за криптиране и частен ключ за декриптиране. Важното е, че трябва да ги пазите. Ако случайно използвате асиметрично криптиране, трябва да се съсредоточите върху частния ключ, този, който ще използвате за декриптиране на резервни копия.
Можете да съхранявате ключове в система за управление на ключове или в трезор - на пазара има много опции, от които да избирате, като KMS на Amazon или Vault на Hashicorp. Дори и да решите да не използвате тези решения, все пак трябва да прилагате общи практики за сигурност, като да гарантирате, че само правилните потребители имат достъп до вашите ключове и пароли. Трябва също да помислите за подготовка на вашите скриптове за архивиране по начин, по който няма да излагате ключове или пароли в списъка с изпълнявани процеси. В идеалния случай ги поставете във файла, вместо да ги предавате като аргумент на някои команди.
Помислете за асиметрично криптиране
Основната разлика между симетричното и асиметричното криптиране е, че докато използвате симетрично криптиране както за криптиране, така и за декриптиране, използвате един ключ или парола. Това изисква по-високи стандарти за сигурност и в двата края на процеса. Трябва да се уверите, че хостът, на който криптирате данните, е много сигурен, тъй като изтичането на симетричния ключ за криптиране ще позволи достъп до всичките ви криптирани архиви.
От друга страна, ако използвате асиметрично криптиране, имате два ключа:публичен ключ за криптиране на данните и частен ключ за декриптиране. Това прави нещата много по-лесни - всъщност не е нужно да се интересувате от публичния ключ. Дори и да бъде компрометиран, той пак няма да позволи никакъв вид достъп до данните от архивни копия. Трябва да се съсредоточите само върху сигурността на частния ключ. По-лесно е - най-вероятно криптирате резервни копия на дневна база (ако не и по-често), докато възстановяването се случва от време на време, което прави възможно съхраняването на частния ключ на по-сигурно място (дори на специално физическо устройство). По-долу е даден много бърз пример за това как можете да използвате gpg, за да генерирате двойка ключове и да го използвате за криптиране на данни.
Първо, трябва да генерирате ключовете:
[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.Това създава както публични, така и частни ключове. След това искате да експортирате своя публичен ключ, който да използвате за криптиране на данните:
gpg --armor --export [email protected] > mybackupkey.ascСлед това можете да го използвате, за да шифровате резервното си копие.
[email protected]:~# xtrabackup --backup --stream=xbstream | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backupИ накрая, пример как можете да използвате своя първичен ключ (в този случай той се съхранява в локалния ключов пръстен), за да дешифрирате вашите резервни копия:
[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]>"Завъртете вашите ключове за криптиране
Без значение какъв вид криптиране сте приложили, симетрично или асиметрично, трябва да помислите за ротацията на ключовете. На първо място, много е важно да имате механизъм за завъртане на клавишите. Това може да е полезно в случай на пробив в сигурността и ще трябва бързо да смените ключовете, които използвате за криптиране и декриптиране на резервно копие. Разбира се, в случай на пробив в сигурността, трябва да помислите какво ще се случи със старите архиви, които са били криптирани с помощта на компрометирани ключове. Те са компрометирани, въпреки че все още могат да бъдат полезни и необходими според целта на точката на възстановяване. Има няколко опции, включително повторното им криптиране или преместването им в некомпрометирана локализация.
Ускорете процеса на криптиране, като го паралелизирате
Ако имате възможност да приложите паралелизиране на процеса на криптиране, помислете за това. Ефективността на криптирането зависи най-вече от мощността на процесора, като по този начин позволява на повече ядра на процесора да работят паралелно, за да криптират файла, би трябвало да доведе до много по-малко времена за криптиране. Някои от инструментите за криптиране дават такава опция. Един от тях е xtrabackup, който има опция за използване на вградено криптиране и паралелизиране на процеса.
Това, което търсите, са опции „--encrypt-key“ или „--encrypt-key-file“, които позволяват вградено криптиране. Докато правите това, можете също да дефинирате „--encrypt-threads“ и „--encrypt-chunk-size“. Второ увеличава работния буфер за криптиране, първо определя колко нишки трябва да се използват за криптиране.
Разбира се, това е само едно от решенията, които можете да приложите. Можете да постигнете това с помощта на инструменти за обвивка. Пример по-долу:
[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{}"'Това в никакъв случай не е идеално решение, тъй като трябва да знаете предварително колко голям, повече или по-малко ще бъде архивът, за да го разделите на предварително дефиниран брой файлове, съответстващи на нивото на паралелизиране, което искате да постигнете (ако искате да използвате 2 CPU ядра, трябва да имате два файла, ако искате да използвате 4 ядра, 4 файла и т.н.). Той също така изисква дисково пространство, което е два пъти по-голямо от размера на архива, тъй като първоначално генерира множество файлове чрез разделяне, а след това криптирането създава друг набор от криптирани файлове. От друга страна, ако размерът на вашия набор от данни е приемлив и искате да подобрите ефективността на криптирането, това е опция, която можете да обмислите. За да дешифрирате архива, ще трябва да дешифрирате всеки един от отделните файлове и след това да използвате „cat“, за да ги обедините заедно.
Тествайте вашите архивни копия
Без значение как ще приложите криптирането на резервно копие, трябва да го тествате. На първо място, всички архиви трябва да бъдат тествани, криптирани или не. Резервните копия може да не са пълни или да страдат от някакъв вид повреда. Не можете да сте сигурни, че архивът ви може да бъде възстановен, докато действително не извършите възстановяването. Ето защо редовната проверка на архива е задължителна. Шифроването добавя повече сложност към процеса на архивиране. Отново може да се появят проблеми по време на криптиране - грешки или проблеми могат да повредят криптираните файлове. Веднъж криптиран, въпросът е дали е възможно да се дешифрира и възстанови?
Трябва да имате тестов процес за възстановяване. В идеалния случай тестът за възстановяване ще се изпълнява след всяко архивиране. Като минимум трябва да тествате своите архиви няколко пъти годишно. Определено трябва да го тествате веднага след като бъде въведена промяна в процеса на архивиране. Добавихте ли компресия към архива? Променихте ли метода на криптиране? Завъртяхте ли ключа за криптиране? Всички тези действия може да окажат някакво влияние върху способността ви действително да възстановите архива си. Затова трябва да се уверите, че тествате целия процес след всяка промяна.
ClusterControl може да автоматизира процеса на проверка, както при поискване, така и по график след всяко архивиране.
За да потвърдите съществуващ архив, просто трябва да изберете този от списъка, да кликнете върху опцията „Възстановяване“ и след това да преминете през съветника за възстановяване. Първо, трябва да проверите кое резервно копие искате да възстановите.
След това на следващата стъпка трябва да изберете опцията за възстановяване и проверка.
Трябва да предадете информация за хоста, на който искате да тествате възстановяването. Той трябва да бъде достъпен чрез SSH от екземпляра на ClusterControl. Може да решите да поддържате тестовия сървър за възстановяване работещ (и след това да изхвърлите някои частични данни от него, ако искате да отидете за частично възстановяване) или да го изключите.
Последната стъпка е да проверите дали сте направили правилния избор. Ако отговорът е да, можете да стартирате заданието за проверка на архивиране.
Ако проверката завърши успешно, ще видите, че резервното копие е маркирано като проверено в списъка с резервните копия.
Ако искате да автоматизирате този процес, това е възможно и с ClusterControl. Когато планирате архивирането, можете да активирате проверка на архивиране:
Това добавя още една стъпка в съветника за планиране на архивиране.
Тук отново трябва да дефинирате хоста, който искате да използвате за тестове за възстановяване на резервно копие, да решите дали искате да инсталирате софтуера на него (или може би вече сте го направили), дали искате да поддържате сървъра за възстановяване и дали искате да тествате архивирането веднага след като приключи или може би искате да изчакате малко.
