sql >> Databáze >  >> RDS >> MariaDB

Šifrování zálohování databáze – doporučené postupy

Úložiště záloh mimo pracoviště by mělo být kritickou součástí plánu obnovy po havárii každé organizace. Schopnost ukládat data na samostatné fyzické místo, kde by mohla přežít katastrofickou událost, která zničí všechna data ve vašem primárním datovém centru, zajišťuje přežití vašich dat a kontinuitu vaší organizace. Služba cloudového úložiště je docela dobrá metoda pro ukládání záloh mimo pracoviště. Bez ohledu na to, zda používáte poskytovatele cloudu nebo pouze kopírujete data do externího datového centra, šifrování záloh je v takových případech nutností. V jednom z našich předchozích blogů jsme diskutovali o několika metodách šifrování vašich záloh. Dnes se zaměříme na některé osvědčené postupy týkající se šifrování záloh.

Ujistěte se, že jsou vaše tajemství v bezpečí

Chcete-li zašifrovat a dešifrovat svá data, musíte použít nějaké heslo nebo klíč. V závislosti na metodě šifrování (symetrické nebo asymetrické) to může být jeden tajný klíč pro šifrování i dešifrování nebo to může být veřejný klíč pro šifrování a soukromý klíč pro dešifrování. Co je důležité, měli byste je mít v bezpečí. Pokud náhodou používáte asymetrické šifrování, měli byste se zaměřit na soukromý klíč, ten, který budete používat k dešifrování záloh.

Klíče můžete ukládat do systému správy klíčů nebo do trezoru – na trhu je na výběr z mnoha možností, jako je Amazon's KMS nebo Hashicorp's Vault. I když se rozhodnete tato řešení nepoužívat, měli byste stále používat obecné bezpečnostní postupy, jako je zajistit, aby k vašim klíčům a heslům měli přístup pouze správní uživatelé. Měli byste také zvážit přípravu zálohovacích skriptů tak, abyste nezpřístupnili klíče nebo hesla v seznamu běžících procesů. V ideálním případě je vložte do souboru místo toho, abyste je předávali jako argument některým příkazům.

Zvažte asymetrické šifrování

Hlavní rozdíl mezi symetrickým a asymetrickým šifrováním spočívá v tom, že při použití symetrického šifrování pro šifrování i dešifrování používáte jeden klíč nebo heslo. To vyžaduje vyšší bezpečnostní standardy na obou koncích procesu. Musíte se ujistit, že hostitel, na kterém šifrujete data, je velmi bezpečný, protože únik symetrického šifrovacího klíče umožní přístup ke všem vašim šifrovaným zálohám.

Na druhou stranu, pokud používáte asymetrické šifrování, máte dva klíče:veřejný klíč pro šifrování dat a soukromý klíč pro dešifrování. Díky tomu jsou věci mnohem jednodušší – o veřejný klíč se ve skutečnosti nemusíte starat. I kdyby byl kompromitován, stále neumožní jakýkoli přístup k datům ze záloh. Musíte se zaměřit pouze na zabezpečení soukromého klíče. Je to jednodušší – s největší pravděpodobností šifrujete zálohy na denní bázi (ne-li častěji), zatímco k obnově dochází čas od času, takže je možné uložit soukromý klíč na bezpečnější místo (dokonce i na vyhrazeném fyzickém zařízení). Níže je velmi rychlý příklad toho, jak můžete pomocí gpg vygenerovat pár klíčů a použít jej k šifrování dat.

Nejprve musíte vygenerovat klíče:

[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.

Tím vznikl veřejný i soukromý klíč. Dále chcete exportovat svůj veřejný klíč, který chcete použít k šifrování dat:

gpg --armor --export [email protected] > mybackupkey.asc

Dále jej můžete použít k šifrování zálohy.

[email protected]:~# xtrabackup  --backup --stream=xbstream  | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backup

Nakonec příklad, jak můžete použít svůj primární klíč (v tomto případě je uložen v místním svazku klíčů) k dešifrování záloh:

[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]>"

Otočte své šifrovací klíče

Bez ohledu na to, jaký typ šifrování jste implementovali, symetrické nebo asymetrické, musíte myslet na rotaci klíčů. V první řadě je velmi důležité mít na místě mechanismus pro otáčení kláves. To může být užitečné v případě narušení zabezpečení a budete muset rychle změnit klíče, které používáte pro šifrování a dešifrování záloh. Samozřejmě v případě narušení bezpečnosti musíte zvážit, co se stane se starými zálohami, které byly zašifrovány pomocí kompromitovaných klíčů. Byly kompromitovány, i když stále mohou být užitečné a požadované podle cíle bodu obnovy. Existuje několik možností, včetně jejich opětovného zašifrování nebo přesunutí do nekompromitované lokalizace.

Urychlete proces šifrování jeho paralelizací

Pokud máte možnost implementovat paralelizaci procesu šifrování, zvažte to. Výkon šifrování většinou závisí na výkonu CPU, takže umožnění paralelní práce více jader CPU při šifrování souboru by mělo vést k mnohem kratším časům šifrování. Některé šifrovací nástroje takovou možnost poskytují. Jedním z nich je xtrabackup, který má možnost použít vestavěné šifrování a paralelizovat proces.

To, co hledáte, jsou možnosti „--encrypt-key“ nebo „--encrypt-key-file“, které umožňují vložené šifrování. Přitom můžete také definovat „--encrypt-threads“ a „--encrypt-chunk-size“. Druhá zvyšuje pracovní vyrovnávací paměť pro šifrování, první definuje, kolik vláken by se mělo použít pro šifrování.

Samozřejmě je to jen jedno z řešení, které můžete implementovat. Můžete toho dosáhnout pomocí nástrojů shellu. Příklad níže:

[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{}"'

Toto není v žádném případě dokonalé řešení, protože musíte předem vědět, jak velká, více či méně bude záloha, abyste ji rozdělili na předem definovaný počet souborů odpovídající úrovni paralelizace, které chcete dosáhnout (pokud chcete použít 2 CPU jádra, měli byste mít dva soubory, pokud chcete použít 4 jádra, 4 soubory atd.). Vyžaduje také místo na disku, které je dvakrát větší než záloha, protože nejprve generuje více souborů pomocí rozdělení a poté šifrování vytvoří další sadu šifrovaných souborů. Na druhou stranu, pokud je velikost vaší datové sady přijatelná a chtěli byste zlepšit výkon šifrování, je to možnost, kterou můžete zvážit. Chcete-li zálohu dešifrovat, budete muset dešifrovat každý z jednotlivých souborů a poté je spojit pomocí ‚cat‘.

Otestujte své zálohy

Bez ohledu na to, jak se chystáte implementovat šifrování záloh, musíte to otestovat. Za prvé, všechny zálohy musí být otestovány, ať už šifrované nebo ne. Zálohy nemusí být úplné nebo mohou trpět nějakým typem poškození. Nemůžete si být jisti, že zálohu lze obnovit, dokud obnovu skutečně neprovedete. Pravidelné ověřování záloh je proto nutností. Šifrování zvyšuje složitost procesu zálohování. Problémy se mohou znovu objevit v době šifrování - chyby nebo závady mohou poškodit šifrované soubory. Po zašifrování je otázkou, zda je možné jej dešifrovat a obnovit?

Měli byste mít zaveden testovací proces obnovy. V ideálním případě by se test obnovy prováděl po každé záloze. Minimálně byste měli své zálohy otestovat několikrát za rok. Rozhodně to musíte otestovat, jakmile byla zavedena změna v procesu zálohování. Přidali jste do zálohy kompresi? Změnili jste metodu šifrování? Otočili jste šifrovací klíč? Všechny tyto akce mohou mít určitý dopad na vaši schopnost skutečně obnovit zálohu. Proto byste se měli ujistit, že po každé změně otestujete celý proces.

ClusterControl může zautomatizovat proces ověřování, a to jak na vyžádání, tak naplánováno po každém zálohování.

Chcete-li ověřit existující zálohu, stačí vybrat zálohu ze seznamu, kliknout na možnost „Obnovit“ a poté projít průvodcem obnovení. Nejprve musíte ověřit, kterou zálohu chcete obnovit.

Poté byste v dalším kroku měli vybrat možnost obnovení a ověření.

Musíte předat nějaké informace o hostiteli, na kterém chcete testovat obnovu. Musí být přístupný přes SSH z instance ClusterControl. Můžete se rozhodnout ponechat testovací server obnovy v provozu (a poté z něj vypsat některá částečná data, pokud byste chtěli provést částečnou obnovu) nebo jej vypnout.

Posledním krokem je ověření, zda jste zvolili správně. Pokud ano, můžete spustit úlohu ověření zálohy.

Pokud ověření proběhlo úspěšně, uvidíte, že záloha je v seznamu záloh označena jako ověřená.

Chcete-li tento proces automatizovat, je to možné také pomocí ClusterControl. Při plánování zálohování můžete povolit ověření zálohy:

To přidává další krok v průvodci plánováním zálohování.

Zde musíte opět definovat hostitele, který chcete použít pro testy obnovy zálohy, rozhodnout se, zda na něj chcete nainstalovat software (nebo možná již máte hotovo), zda chcete zachovat server pro obnovení a zda chcete chcete otestovat zálohu ihned po jejím dokončení nebo možná budete chtít chvíli počkat.


  1. DateTime2 vs DateTime na SQL Server

  2. Zachování propagace vždy povolené v Oracle Streams

  3. Jak vypočítat klouzavý průměr v MySQL

  4. Režie sledování vytváření #temp tabulky