Bezpieczeństwo bazy danych — szyfrowanie kopii zapasowych podczas transportu i w spoczynku

Zabezpieczenie Twoich danych to jedno z najważniejszych zadań, którym powinniśmy nadać priorytet. Pojawienie się przepisów wymagających zgodności z bezpieczeństwem, takich jak RODO, HIPAA, PCI DSS lub PHI, wymaga, aby Twoje dane były bezpiecznie przechowywane lub przesyłane przewodowo.

W ClusterControl doceniamy znaczenie bezpieczeństwa i oferujemy szereg funkcji zabezpieczających dostęp do bazy danych i przechowywanych danych. Jednym z nich jest zabezpieczenie kopii zapasowych bazy danych, zarówno w stanie spoczynku, jak i podczas przesyłania. W trakcie przesyłania kopia zapasowa jest przesyłana przez Internet lub sieć ze źródła do miejsca docelowego, podczas gdy w spoczynku dane są przechowywane w pamięci trwałej. W tym blogu pokażemy, jak używać ClusterControl do szyfrowania danych kopii zapasowej w stanie spoczynku i podczas przesyłania.

Szyfrowanie w drodze

Podczas zarządzania kopiami zapasowymi za pomocą ClusterControl, przy użyciu mysqldump lub Percona Xtrabackup/Mariabackup są domyślnie zarządzane bez szyfrowania, gdy są przesyłane przez sieć. Jednak używanie TLS/SSL do szyfrowania transmisji danych jest obsługiwane przez MySQL/MariaDB/Percona Server, podobnie jak Percona Xtrabackup, który oferuje opcje SSL podczas wywoływania polecenia.

ClusterControl domyślnie włącza SSL podczas wdrażania klastra, ale nie ma kontroli nad natychmiastowym przełączaniem i szyfrowaniem danych przez sieć podczas tworzenia kopii zapasowej. Możesz sprawdzić nasze poprzednie blogi dotyczące ręcznego podejścia przy użyciu ClusterControl podczas tworzenia klastra lub używania staromodnego sposobu ręcznej konfiguracji TLS/SSL w MySQL.

W ClusterControl, podczas wdrażania klastra, możesz sprawdzić zakładkę bezpieczeństwa lub tę ikonę .

Kliknięcie Przycisk umożliwi zastąpienie certyfikatu, który jest aktualnie używany lub wdrażany przez ClusterControl podczas wdrażania nowo udostępnionego grupa. Możesz sprawdzić ten blog "Updated:Become a ClusterControl DBA - SSL Key Management and Encryption of MySQL Data in Transit", dla którego pokazaliśmy, jak obsługujemy klucze. Zasadniczo możesz przejść przez nawigację po lewej stronie ClusterControl i kliknąć „Zarządzanie kluczami”.

Poniżej znajduje się przykład zarządzania kluczami, w którym możesz tworzyć i importować istniejące klucze.

Podczas tworzenia kopii zapasowej za pomocą mysqldump jako logicznej kopii zapasowej, aby zaszyfrować dane, upewnij się, że masz odpowiednio ustawione opcje SSL.

Co dalej?

Ponieważ mamy stworzone przez nas certyfikaty, musimy odpowiednio włączyć i skonfigurować SSL. Aby to zapewnić, możesz to sprawdzić za pomocą wiersza poleceń ClusterControl lub mysql. Zobacz zdjęcia poniżej:

lub możesz sprawdzić również w zakładce Wydajność i kliknąć Zmienne DB, jak pokazano poniżej:

Pamiętaj, że wypełnienie danych w sekcji Wydajność -> Zmienne DB może zająć trochę czasu. Więc jeśli chcesz sprawdzić ręcznie, możesz użyć wiersza poleceń mysql, tak jak poniżej:

Zdefiniowanie ssl_cipher może zwiększyć bezpieczeństwo. Istnieje lista zestawów szyfrów, jeśli uruchomisz SHOW GLOBAL STATUS LIKE „Ssl_cipher_list”\G lub sprawdź tutaj. Zestaw szyfrów to połączenie algorytmów uwierzytelniania, szyfrowania i kodu uwierzytelniania wiadomości (MAC). Są one używane podczas negocjowania ustawień bezpieczeństwa dla połączenia TLS/SSL, a także do bezpiecznego przesyłania danych.

Ponieważ ClusterControl uruchomi mysqldump lokalnie na tym hoście, dodając następujące parametry (patrz poniżej) w pliku konfiguracyjnym MySQL (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) zaszyfruje wszystkie akcje dla zrzutu SQL. Zobacz poniżej:

[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

Możesz spróbować monitorować za pomocą tcpdump i możesz zobaczyć poniżej w porównaniu do warstwy niezaszyfrowanej i zaszyfrowanej za pomocą TLS.

Z TLS/SSL:

Bez TLS/SSL:

W przypadku korzystania z Percona XtraBackup lub Mariabackup w ramach ClusterControl nie ma obecnie obsługi TLS/SSL, gdy kopia zapasowa jest przesyłana przez sieć. Używa socat, który po prostu otwiera port do innego węzła jako środek komunikacji.

np.

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

Jeśli potrzebujesz bezpiecznej warstwy podczas transportu, możesz to zrobić ręcznie, używając opcji --ssl* podczas wywoływania polecenia. Sprawdź tutaj instrukcję Percona XtraBackup, aby uzyskać więcej informacji. Nadal zalecamy uzyskanie certyfikatu/klucza z zarejestrowanego urzędu certyfikacji.

Alternatywnie, używając ClusterControl, możesz zaszyfrować swoje dane przed wysłaniem przez sieć, wysyłane pakiety nie są surowymi, ale zaszyfrowanymi danymi. Chociaż szyfrowanie opiera się na stanie spoczynku, omówimy to w następnej sekcji.

Szyfrowanie w spoczynku

W ClusterControl podczas tworzenia kopii zapasowej możesz zaszyfrować swoje dane. Zobacz poniżej:

Po zaszyfrowaniu ClusterControl użyje „Advance Encryption Standard” AES-256-CBC. Zobacz przykładowy dziennik poniżej:

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

Jeśli przechowujesz kopię zapasową w chmurze, na przykład za pomocą AWS S3, S3 oferuje trzy różne tryby szyfrowania po stronie serwera (SSE). Są to SSE-S3, SSE-C lub SSE-KMS. Amazon ma do zaoferowania świetne funkcje SSE, które obsługują szyfrowanie danych w spoczynku. Możesz zacząć tutaj, w którym omawia, w jaki sposób S3 korzysta z AWS KMS. Jeśli przenosisz kopię zapasową do pamięci masowej opartej na woluminach lub blokach, AWS obsługuje również szyfrowanie EBS przy użyciu AWS KMS. Możesz sprawdzić tutaj, aby uzyskać więcej informacji na ten temat.

Microsoft Azure ma również fajne funkcje podczas obsługi danych w spoczynku. Zapoznaj się ze stroną „Szyfrowanie usługi Azure Storage dla danych w spoczynku”. Platforma Azure obsługuje klucze w ich Azure Key Vault, tak samo jak AWS KMS. Szyfrowanie danych w spoczynku przez Google można sprawdzić tutaj.

Podczas przechowywania kopii zapasowych danych lokalnie możesz użyć LUKS (Linux Unified Key Setup) z kombinacją crypt lub dmcrypt. Nie będę o tym dyskutować na tym blogu, ale jest to dobre źródło do obejrzenia:Szyfrowanie MySQL w spoczynku – część 1 (LUKS). Aby uzyskać więcej informacji o szyfrowaniu dysku, ta strona ArchLinux „Szyfrowanie dysku” jest doskonałym źródłem na początek.

Co najważniejsze, chociaż Twoje dane zostały zaszyfrowane w spoczynku i podczas przesyłania, zawsze sprawdzaj, czy kopia zapasowa działa. Kopia zapasowa, która nie została przetestowana, nie jest kopią zapasową, jeśli nie działa, gdy potrzebne jest odzyskanie. Przechowywanie kopii zapasowej również w stanie zaszyfrowanym musi zostać odszyfrowane bez żadnych problemów, dlatego klucze muszą być przechowywane prywatnie i w jak najbardziej bezpieczny sposób. Ponadto dodanie szyfrowania do danych, takiego jak szyfrowanie InnoDB lub SST (dla Galera), zapewnia większe bezpieczeństwo, ale nie będziemy ich omawiać na tym blogu.

Wniosek

Szyfrowanie danych kopii zapasowej w stanie spoczynku i w trakcie przesyłania to kluczowe elementy zapewniające zgodność z PHI, HIPAA, PCI DSS lub RODO, aby zapewnić, że poufne dane przesyłane przez sieć lub zapisywane na dyskach nie są odczytywane przez żadnego użytkownika lub aplikację bez ważnego klucza. Niektóre przepisy dotyczące zgodności, takie jak PCI DSS i HIPAA, wymagają, aby dane w spoczynku były szyfrowane przez cały cykl życia danych.

Tutaj pokazujemy, w jaki sposób ClusterControl oferuje te opcje użytkownikowi końcowemu. Zgodność jest jednak ogromnym zadaniem, dotykającym wielu różnych obszarów. Regulacje są również często aktualizowane, a procesy/narzędzia również muszą być odpowiednio aktualizowane. Nieustannie ulepszamy różne obszary w ClusterControl, aby zapewnić zgodność. Chcielibyśmy poznać Twoje przemyślenia na ten temat i jak możemy to ulepszyć.