MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

Szyfrowanie kopii zapasowej bazy danych — najlepsze praktyki

Przechowywanie kopii zapasowych poza siedzibą firmy powinno stanowić kluczową część planu odzyskiwania po awarii w każdej organizacji. Możliwość przechowywania danych w oddzielnej fizycznej lokalizacji, w której mogłyby przetrwać katastrofalne zdarzenie, które zniszczy wszystkie dane w głównym centrum danych, zapewnia przetrwanie danych i ciągłość działania Twojej organizacji. Usługa przechowywania w chmurze to całkiem dobra metoda przechowywania kopii zapasowych poza siedzibą firmy. Bez względu na to, czy korzystasz z dostawcy chmury, czy po prostu kopiujesz dane do zewnętrznego centrum danych, szyfrowanie kopii zapasowej jest w takich przypadkach koniecznością. W jednym z naszych poprzednich blogów omówiliśmy kilka metod szyfrowania kopii zapasowych. Dzisiaj skupimy się na kilku najlepszych praktykach dotyczących szyfrowania kopii zapasowych.

Upewnij się, że Twoje sekrety są bezpieczne

Aby zaszyfrować i odszyfrować swoje dane, musisz użyć jakiegoś hasła lub klucza. W zależności od metody szyfrowania (symetryczne lub asymetryczne) może to być jeden sekret do szyfrowania i odszyfrowywania lub może to być klucz publiczny do szyfrowania i klucz prywatny do odszyfrowania. Co ważne, powinieneś zadbać o to, aby były bezpieczne. Jeśli zdarzy ci się używać szyfrowania asymetrycznego, powinieneś skupić się na kluczu prywatnym, tym, którego będziesz używać do odszyfrowywania kopii zapasowych.

Możesz przechowywać klucze w systemie zarządzania kluczami lub w skarbcu – na rynku dostępnych jest wiele opcji, takich jak KMS firmy Amazon lub Skarbiec Hashicorp. Nawet jeśli zdecydujesz się nie korzystać z tych rozwiązań, nadal powinieneś stosować ogólne praktyki bezpieczeństwa, takie jak zapewnienie, że tylko właściwi użytkownicy mogą uzyskać dostęp do twoich kluczy i haseł. Należy również rozważyć przygotowanie skryptów kopii zapasowych w taki sposób, aby nie ujawniać kluczy ani haseł na liście uruchomionych procesów. Najlepiej umieścić je w pliku zamiast przekazywać je jako argument do niektórych poleceń.

Rozważ szyfrowanie asymetryczne

Główna różnica między szyfrowaniem symetrycznym a asymetrycznym polega na tym, że podczas używania szyfrowania symetrycznego zarówno do szyfrowania, jak i odszyfrowywania, używasz jednego klucza lub hasła. Wymaga to wyższych standardów bezpieczeństwa po obu stronach procesu. Musisz upewnić się, że host, na którym szyfrujesz dane, jest bardzo bezpieczny, ponieważ wyciek symetrycznego klucza szyfrowania umożliwi dostęp do wszystkich zaszyfrowanych kopii zapasowych.

Z drugiej strony, jeśli używasz szyfrowania asymetrycznego, masz dwa klucze:klucz publiczny do szyfrowania danych i klucz prywatny do odszyfrowania. To znacznie ułatwia sprawę - tak naprawdę nie musisz przejmować się kluczem publicznym. Nawet gdyby został naruszony, nadal nie pozwoli na jakikolwiek dostęp do danych z kopii zapasowych. Musisz skupić się tylko na bezpieczeństwie klucza prywatnego. Jest to prostsze — najprawdopodobniej kopie zapasowe są szyfrowane codziennie (jeśli nie częściej), podczas gdy przywracanie odbywa się od czasu do czasu, dzięki czemu możliwe jest przechowywanie klucza prywatnego w bezpieczniejszym miejscu (nawet na dedykowanym urządzeniu fizycznym). Poniżej znajduje się bardzo szybki przykład wykorzystania gpg do wygenerowania pary kluczy i użycia jej do szyfrowania danych.

Najpierw musisz wygenerować klucze:

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

To stworzyło zarówno klucze publiczne, jak i prywatne. Następnie chcesz wyeksportować swój klucz publiczny, który będzie używany do szyfrowania danych:

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

Następnie możesz go użyć do zaszyfrowania kopii zapasowej.

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

Na koniec przykład, w jaki sposób możesz użyć klucza podstawowego (w tym przypadku jest on przechowywany w lokalnym pęku kluczy) do odszyfrowania kopii zapasowych:

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

Obróć klucze szyfrowania

Bez względu na to, jaki rodzaj szyfrowania wdrożyłeś, symetryczne czy asymetryczne, musisz pomyśleć o rotacji kluczy. Przede wszystkim bardzo ważne jest posiadanie mechanizmu do obracania kluczy. Może to być przydatne w przypadku naruszenia bezpieczeństwa i trzeba by szybko zmienić klucze używane do szyfrowania i odszyfrowywania kopii zapasowych. Oczywiście w przypadku naruszenia bezpieczeństwa należy zastanowić się, co się stanie ze starymi kopiami zapasowymi, które zostały zaszyfrowane przy użyciu zhakowanych kluczy. Zostały naruszone, chociaż nadal mogą być przydatne i wymagane zgodnie z celem punktu odzyskiwania. Istnieje kilka opcji, w tym ponowne ich zaszyfrowanie lub przeniesienie do niezagrożonej lokalizacji.

Przyspiesz proces szyfrowania poprzez jego zrównoleglenie

Jeśli masz możliwość zaimplementowania zrównoleglania procesu szyfrowania, rozważ to. Wydajność szyfrowania zależy głównie od mocy procesora, dlatego umożliwienie równoległej pracy większej liczby rdzeni procesora w celu zaszyfrowania pliku powinno skutkować znacznie krótszymi czasami szyfrowania. Niektóre narzędzia szyfrujące dają taką możliwość. Jednym z nich jest xtrabackup, który ma opcję użycia wbudowanego szyfrowania i zrównoleglenia procesu.

To, czego szukasz, to opcje „--encrypt-key” lub „--encrypt-key-file”, które umożliwiają wbudowane szyfrowanie. Robiąc to, możesz również zdefiniować „--szyfrowanie-wątków” i „--szyfrowanie-rozmiar-chunków”. Po drugie zwiększa bufor roboczy do szyfrowania, po pierwsze określa, ile wątków należy użyć do szyfrowania.

Oczywiście to tylko jedno z rozwiązań, które możesz wdrożyć. Możesz to osiągnąć za pomocą narzędzi powłoki. Przykład poniżej:

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

W żadnym wypadku nie jest to idealne rozwiązanie, ponieważ musisz z góry wiedzieć, jak duża, mniej więcej, będzie kopia zapasowa, aby podzielić ją na określoną liczbę plików odpowiadających poziomowi zrównoleglania, który chcesz osiągnąć (jeśli chcesz użyć 2 procesorów rdzeni, powinieneś mieć dwa pliki, jeśli chcesz użyć 4 rdzeni, 4 plików itp.). Wymaga również miejsca na dysku, które jest dwa razy większe niż kopia zapasowa, ponieważ najpierw generuje wiele plików za pomocą podziału, a następnie szyfrowanie tworzy kolejny zestaw zaszyfrowanych plików. Z drugiej strony, jeśli rozmiar zestawu danych jest akceptowalny i chcesz poprawić wydajność szyfrowania, jest to opcja, którą możesz rozważyć. Aby odszyfrować kopię zapasową, musisz odszyfrować każdy z pojedynczych plików, a następnie użyć „cat”, aby połączyć je ze sobą.

Przetestuj swoje kopie zapasowe

Bez względu na to, jak zamierzasz wdrożyć szyfrowanie kopii zapasowych, musisz to przetestować. Przede wszystkim wszystkie kopie zapasowe muszą być przetestowane, zaszyfrowane lub nie. Kopie zapasowe mogą być niekompletne lub mogą być uszkodzone. Nie możesz mieć pewności, że kopię zapasową można przywrócić, dopóki nie wykonasz przywracania. Dlatego regularna weryfikacja kopii zapasowej jest koniecznością. Szyfrowanie zwiększa złożoność procesu tworzenia kopii zapasowej. Problemy mogą pojawić się w czasie szyfrowania, ponownie - błędy lub usterki mogą uszkodzić zaszyfrowane pliki. Po zaszyfrowaniu pojawia się pytanie, czy można je odszyfrować i przywrócić?

Powinieneś mieć wdrożony proces przywracania. W idealnym przypadku test przywracania byłby wykonywany po każdej kopii zapasowej. Kopie zapasowe należy testować przynajmniej kilka razy w roku. Zdecydowanie trzeba to przetestować, gdy tylko zostanie wprowadzona zmiana w procesie tworzenia kopii zapasowej. Czy dodałeś kompresję do kopii zapasowej? Czy zmieniłeś metodę szyfrowania? Czy zmieniłeś klucz szyfrowania? Wszystkie te działania mogą mieć pewien wpływ na możliwość rzeczywistego przywrócenia kopii zapasowej. Dlatego po każdej zmianie upewnij się, że testujesz cały proces.

ClusterControl może zautomatyzować proces weryfikacji, zarówno na żądanie, jak i zaplanowany po każdej kopii zapasowej.

Aby zweryfikować istniejącą kopię zapasową, wystarczy wybrać tę z listy, kliknąć opcję „Przywróć”, a następnie przejść przez kreator przywracania. Najpierw musisz zweryfikować, którą kopię zapasową chcesz przywrócić.

Następnie w następnym kroku wybierz opcję przywracania i weryfikacji.

Musisz przekazać pewne informacje o hoście, na którym chcesz przetestować przywracanie. Musi być dostępny przez SSH z instancji ClusterControl. Możesz zdecydować się na pozostawienie testowego serwera przywracania w stanie włączonym (a następnie zrzucenie z niego części danych, jeśli chcesz przeprowadzić częściowe przywracanie) lub zamknięcie go.

Ostatnim krokiem jest sprawdzenie, czy dokonałeś właściwych wyborów. Jeśli tak, możesz rozpocząć zadanie weryfikacji kopii zapasowej.

Jeśli weryfikacja zakończy się pomyślnie, zobaczysz, że kopia zapasowa jest oznaczona jako zweryfikowana na liście kopii zapasowych.

Jeśli chcesz zautomatyzować ten proces, jest to również możliwe dzięki ClusterControl. Podczas planowania kopii zapasowej możesz włączyć weryfikację kopii zapasowej:

To dodaje kolejny krok w kreatorze planowania kopii zapasowych.

Tutaj ponownie musisz zdefiniować hosta, którego chcesz używać do testów przywracania kopii zapasowych, zdecydować, czy chcesz na nim zainstalować oprogramowanie (a może już to zrobiłeś), czy chcesz utrzymać serwer przywracania włączony i czy chcesz chcesz przetestować kopię zapasową natychmiast po jej zakończeniu, a może chcesz trochę poczekać.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Porównanie serwera MariaDB z klastrem MariaDB

  2. 2 sposoby na usunięcie zduplikowanych wierszy w MariaDB (ignoruje klucz podstawowy)

  3. 4 funkcje zwracające rok z daty w MariaDB

  4. Jak REPEAT() działa w MariaDB

  5. Ustaw zestaw znaków i sortowanie tabeli w MariaDB