Zabezpečení databáze – šifrování záloh během přepravy a v klidu

Zabezpečení vašich dat je jedním z nejdůležitějších úkolů, kterému bychom měli dát přednost. Vznik předpisů, které vyžadují dodržování bezpečnosti, jako je GDPR, HIPAA, PCI DSS nebo PHI, vyžaduje, aby vaše data byla bezpečně uložena nebo přenášena po drátě.

V ClusterControl si vážíme důležitosti zabezpečení a nabízíme řadu funkcí pro zabezpečení přístupu k databázi a uložených dat. Jedním z nich je zabezpečení záloh databáze, a to jak v klidu, tak během přepravy. In-transit je, když je záloha přenášena přes internet nebo síť ze zdroje do cíle, zatímco v klidu je, když jsou data uložena na trvalém úložišti. V tomto blogu vám ukážeme, jak můžete použít ClusterControl k šifrování zálohovaných dat v klidu a při přenosu.

Šifrování během přepravy

Při správě záloh pomocí ClusterControl jsou pomocí mysqldump nebo Percona Xtrabackup/Mariabackup ve výchozím nastavení spravovány bez šifrování při přenosu po drátě. MySQL/MariaDB/Percona Server však podporuje použití TLS/SSL pro šifrování přenosu dat, stejně jako Percona Xtrabackup, který nabízí možnosti SSL při vyvolání příkazu.

ClusterControl ve výchozím nastavení povoluje SSL, když nasazujete cluster, ale nemá možnost okamžitě přepnout a zašifrovat vaše data po drátě během vytváření zálohy. Můžete se podívat na naše předchozí blogy o ručním přístupu pomocí ClusterControl při vytváření clusteru nebo pomocí staromódního způsobu ručního nastavení TLS/SSL v MySQL.

Když v ClusterControl nasadíte cluster, můžete zkontrolovat kartu zabezpečení nebo tuto ikonu .

Kliknutím na Tlačítko vám umožní nahradit certifikát, který právě používá nebo nasazuje ClusterControl během nasazení vašeho nově zřízeného shluk. Můžete se podívat na tento blog „Aktualizováno:Staňte se ClusterControl DBA – Správa klíčů SSL a šifrování dat MySQL při přenosu“, ve kterém jsme ukázali, jak s klíči zacházíme. V podstatě můžete projít levou navigací ClusterControl a kliknout na „Správa klíčů“.

Níže je uveden příklad správy klíčů, ve kterém můžete vytvářet a importovat své stávající klíče.

Při vytváření zálohy pomocí mysqldump jako logické zálohy se za účelem šifrování dat ujistěte, že máte odpovídajícím způsobem nastaveny možnosti SSL.

Co bude dál?

Protože máme vytvořené certifikáty, musíme odpovídajícím způsobem povolit a nastavit SSL. Chcete-li to zajistit, můžete to zkontrolovat pomocí příkazového řádku ClusterControl nebo mysql. Viz obrázky níže:

nebo můžete zkontrolovat také na kartě Výkon a kliknout na proměnné DB, jak je vidět níže:

Vezměte na vědomí, že může nějakou dobu trvat, než se naplní v části Výkon -> Proměnné DB. Takže pokud chcete zkontrolovat ručně, můžete použít příkazový řádek mysql stejně jako níže:

Definování ssl_cipher může přidat další posílení zabezpečení. Pokud spustíte ZOBRAZIT GLOBAL STATUS LIKE ‚Ssl_cipher_list‘\G, nebo se podíváte sem, existuje seznam šifrovací sady. Šifrovací sada je kombinací autentizace, šifrování a algoritmů pro ověřování zpráv (MAC). Používají se při vyjednávání nastavení zabezpečení pro připojení TLS/SSL a také pro bezpečný přenos dat.

Protože ClusterControl spustí mysqldump lokálně na tomto hostiteli, přidejte do konfiguračního souboru MySQL následující parametry (viz níže) (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) zašifruje všechny akce pro výpis SQL. Viz níže:

[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
host=127.0.0.1
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pem

Můžete zkusit monitorovat pomocí tcpdump a níže vidíte srovnání s nešifrovanou vs šifrovanou vrstvou pomocí TLS.

S TLS/SSL:

Bez TLS/SSL:

Při použití Percona XtraBackup nebo Mariabackup pod ClusterControl není v tuto chvíli žádná podpora TLS/SSL, když je záloha přenášena přes síť. Používá socat, který v podstatě jen otevírá port do jiného uzlu jako prostředek komunikace.

např.

[21:24:46]: 192.168.10.20: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | socat - TCP4:192.168.10.200:9999 ) 2>&1.
[21:24:46]: 192.168.10.20: The xtrabackup version is 2.4.12 / 2004012.
[21:24:46]: 192.168.10.20:3306: Checking xtrabackup version.
[21:24:46]: 192.168.10.20: Streaming backup to 192.168.10.200
[21:24:46]: 192.168.10.200: Netcat started, error log is in '192.168.10.200:/tmp/netcat.log'.
[21:24:43]: 192.168.10.200: Starting socat -u tcp-listen:9999,reuseaddr stdout > /home/vagrant/backups/BACKUP-71/backup-full-2018-11-12_132443.xbstream.gz 2>/tmp/netcat.log.

Pokud potřebujete zabezpečenou vrstvu během přenosu, můžete to udělat ručně pomocí voleb --ssl* během vyvolání příkazu. Více informací naleznete v příručce Percona XtraBackup zde. Stále doporučujeme získat certifikát/klíč od registrované certifikační autority.

Alternativně můžete pomocí ClusterControl svá data před odesláním přes síť zašifrovat, odesílané pakety nejsou nezpracovaná, ale zašifrovaná data. Ačkoli šifrování závisí na klidu, budeme o tom diskutovat v další části.

Šifrování v klidu

V ClusterControl máte při vytváření zálohy možnost nechat data zašifrovat. Viz níže:

Při zašifrování bude ClusterControl používat „Advance Encryption Standard“ AES-256-CBC. Viz ukázkový protokol níže:

[22:12:49]: 192.168.10.30: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-002471-32758-24c456ca6b087837.tmp | socat - TCP4:192.168.10.200:9999 ) 2>&1.

Pokud zálohu ukládáte do cloudu, například pomocí AWS S3, S3 nabízí tři různé režimy šifrování na straně serveru (SSE). Jedná se o SSE-S3, SSE-C nebo SSE-KMS. Amazon nabízí skvělé funkce SSE, které zvládnou šifrování dat v klidu. Můžete začít zde, která se zabývá tím, jak S3 používá AWS KMS. Pokud přesouváte zálohu do svazku nebo úložiště založeného na blocích, AWS má také šifrování EBS pomocí AWS KMS. Více informací o tomto najdete zde.

Microsoft Azure má skvělé funkce také při práci s daty v klidu. Podívejte se na stránku „Šifrování služby Azure Storage pro data v klidu“. Azure zpracovává klíče v jejich Azure Key Vault, stejně jako AWS KMS. Pokud jde o šifrování Google pro data v klidu, můžete zkontrolovat zde.

Při ukládání záloh dat on-prem můžete použít LUKS (Linux Unified Key Setup) s kombinací crypt nebo dmcrypt. Nebudu o tom diskutovat na tomto blogu, ale je to dobrý zdroj, na který se můžete podívat:MySQL Encryption at Rest – Part 1 (LUKS). Pro více informací o šifrování disku je tato stránka ArchLinuxu „Šifrování disku“ skvělým zdrojem pro začátek.

A co je nejdůležitější, i když byla vaše data v klidu a při přenosu zašifrována, vždy ověřte, zda záloha funguje. Záloha, která nebyla testována, není zálohou, pokud nefunguje, když je potřeba obnovení. Uložení zálohy i zašifrované musí být bez problémů dešifrováno, takže vaše klíče musí být uloženy v soukromí a co nejbezpečnějším způsobem. Navíc přidání šifrování k vašim datům, jako je šifrování InnoDB nebo SST (pro Galera), zvyšuje zabezpečení, ale těm se v tomto blogu nebudeme věnovat.

Závěr

Šifrování zálohovaných dat v klidu a při přenosu jsou životně důležité součásti pro soulad s PHI, HIPAA, PCI DSS nebo GDPR, aby bylo zajištěno, že citlivá data přenášená po drátě nebo uložená na discích nebudou čitelná žádným uživatelem ani aplikací bez platného klíče. Některá nařízení o shodě, jako je PCI DSS a HIPAA, vyžadují, aby data v klidu byla během životního cyklu dat šifrována.

Zde ukážeme, jak ClusterControl nabízí tyto možnosti koncovému uživateli. Dodržování předpisů je však obrovský úkol, který se týká mnoha různých oblastí. Předpisy jsou také často aktualizovány a procesy/nástroje je také třeba odpovídajícím způsobem aktualizovat. Neustále zlepšujeme různé oblasti v ClusterControl, abychom usnadnili dodržování předpisů. Rádi bychom slyšeli váš názor na toto a jak bychom se mohli zlepšit.