Bezpieczeństwo danych ma kluczowe znaczenie w czasach RODO, PCI DSS czy HIPPA. Aby zachować zgodność z przepisami, należy zachować szczególną ostrożność w zakresie przechowywania i ochrony danych. Dane zazwyczaj mogą być w spoczynku lub w trakcie przesyłania. Dane w drodze to dane przesyłane z lub do bazy danych. Wyniki zapytań wysyłane do klienta lub aplikacji lub replikowane dane między węzłami klastra to przykłady przypadków przesyłania danych. Mamy tendencję do zabezpieczania danych w tym stanie za pomocą SSL lub TLS - zaszyfrowanych połączeń między węzłami bazy danych lub bazą danych i klientem.
Po drugiej stronie spektrum mamy dane w spoczynku – powiedzielibyśmy, że większość danych jest w danym momencie w spoczynku. Mowa tu o danych przechowywanych na dysku w przestrzeniach tabel, różnych strukturach danych (bufor gcache, logi redo) i logach (logi binarne i relay). Przyjrzyjmy się rozważaniom na ten temat w MariaDB.
Co zaszyfrować w MariaDB?
Idealnie wszystko trzeba zaszyfrować. Bazy danych przechowują dane w różnych miejscach i na różne sposoby, jak wspomniano powyżej. Największy zestaw danych jest przechowywany w przestrzeniach tabel — jest to „końcowa” lokalizacja, w której przechowywane są dane. Oczywiście możliwe jest szyfrowanie przestrzeni tabel - w przeciwnym razie cała funkcja byłaby bezcelowa. MariaDB może przechowywać dane w jednym wspólnym obszarze tabel, kilku z nich lub każda tabela może być przechowywana w osobnym obszarze tabel - wszystkie te scenariusze są obsługiwane. Użytkownicy mają pewien poziom elastyczności przy wyborze elementów do zaszyfrowania. Możesz zaszyfrować wszystko, pojedyncze tabele lub wszystko oprócz niektórych pojedynczych tabel.
Dziennik przeróbek MariaDB InnoDB
Kolejną strukturą przechowującą dane jest log przeróbek InnoDB. InnoDB redo log to miejsce, w którym zapisywane są dane po aktualizacji danego wiersza. Dane z logu redo zostaną ostatecznie przeniesione do przestrzeni tabel, ale na razie log redo InnoDB zawiera wszystkie modyfikacje, które miały miejsce w ostatnim czasie. Jak możesz sobie wyobrazić, te dane są również krytyczne i powinny być chronione - MariaDB umożliwia szyfrowanie dziennika przeróbek InnoDB.
Dzienniki binarne MariaDB
Dzienniki binarne (jak również logi przekazywania) przechowują informacje o wykonanych zapytaniach, które modyfikują dane. Ponieważ zawarte informacje pozwalają nam odtworzyć aktualny stan wiersza, który został zmodyfikowany, jest to kolejna forma danych, które należy chronić i szyfrować. W MariaDB można szyfrować zarówno dzienniki binarne, jak i przekaźnikowe.
Pamięć podręczna Galery
Galera cache (gcache) to bufor na dysku w Galera Cluster, który przechowuje informacje o wykonanych modyfikacjach. Jest używany w przypadku awarii węzła lub tymczasowych problemów z siecią, aby umożliwić węzłom dołączającym do klastra nadrobienie zaległości przy użyciu tylko tych danych, których im brakuje, co pozwala uniknąć przesyłania całego zestawu danych. Podobnie jak logi binarne lub logi redo, gcache zawiera listę modyfikacji i jako taki może być używany do odzyskiwania i łączenia części danych. W społecznościowej wersji MariaDB Galera Cluster gcache nie może być zaszyfrowane. Taka opcja jest dostępna w Klastrze MariaDB Galera w wersji Enterprise.
Czego nie można zaszyfrować w MariaDB?
Nadal są miejsca, w których mogą pojawić się fragmenty danych, których nie można zaszyfrować, przynajmniej na razie, w MariaDB. Po pierwsze, dzienniki błędów mogą zawierać próbki zapytań, które potencjalnie mogą ujawnić niektóre dane. Nie można zaszyfrować dzienników błędów, ale możliwe jest przekierowanie dziennika błędów do dziennika systemowego i zaimplementowanie jakiegoś mechanizmu ochrony poza MariaDB.
Dzienniki z wtyczki audytu
Wtyczka audytu również generuje dziennik — ten dziennik może zawierać poufne informacje, w tym dokładne zapytania, które zostały wykonane w bazie danych. Nie można zaszyfrować tego dziennika, ale można go przekierować do dziennika systemowego i tam zaszyfrować.
Dzienniki zapytań
Dzienniki ogólnych i wolnych zapytań — te dzienniki będą zawierać zapytania (lub przynajmniej ich próbki), które zostały wykonane przez MariaDB. W tej chwili nie jest możliwe szyfrowanie tych dzienników.
Pula buforów InnoDB
Pamięć — MariaDB szyfruje tylko strony przechowywane na dysku. Wszystkie dane przechowywane w puli buforów InnoDB będą niezaszyfrowane. Pula buforów InnoDB jest przeznaczona do przechowywania wierszy ostatnio zmodyfikowanych lub udostępnionych przez zapytanie SELECT - te wiersze będą oczywiście zawierać próbki danych. Obecnie nie ma opcji szyfrowania puli buforów InnoDB w MariaDB. Należy pamiętać, że do odczytu pamięci na żywo wymagany jest dostęp do systemu. Nie jest to trywialne zadanie, nawet jeśli nie jest niemożliwe do wykonania.
Pamiętaj, że omówiliśmy opcje szyfrowania zawarte w MariaDB. Zawsze istnieje możliwość zastosowania innej warstwy szyfrowania. Na przykład zaszyfrowanie całej pamięci spowoduje, że logi nie będą czytelne dla nikogo, kto miałby fizyczny dostęp do dysku. Z drugiej strony nie ochroni danych przed kimś, kto jest w stanie zalogować się do systemu.
Kompatybilność z narzędziami zewnętrznymi
Kolejną rzeczą do rozważenia jest kompatybilność. Jeśli zdecydujesz się zaszyfrować swoją bazę danych MariaDB, musisz pamiętać, że może to wpłynąć na sposób, w jaki działasz. Nie można używać zewnętrznych narzędzi, takich jak XtraBackup lub mysqlbinlog, do przetwarzania danych i tworzenia kopii zapasowych lub do obsługi dzienników binarnych. Będziesz musiał trzymać się narzędzi stworzonych przez MariaDB (takich jak Mariabackup), które są napisane z myślą o mechanizmie szyfrowania. Mogą obsługiwać dane w spoczynku, szyfrowanie jest zaimplementowane w MariaDB.
Planowanie procesu szyfrowania
W tej sekcji nie omówimy szczegółowo procesu, ale omówiono, co należy wziąć pod uwagę podczas planowania szyfrowania, np. zasoby i czas. Wykorzystanie procesora wzrośnie, podobnie jak aktywność we/wy na czas trwania procesu. Z punktu widzenia użytkownika wszystko sprowadza się do ustawień konfiguracyjnych, a następnie wykonania poleceń ALTER w celu odbudowania i zaszyfrowania istniejących tabel. W przypadku dużych baz danych samo to może być poważnym wyzwaniem, które wymaga planowania. Zmiany schematu mogą być poważnym obciążeniem i zaleca się korzystanie z narzędzi takich jak pt-online-schema-change, aby zmniejszyć ich wpływ na systemy produkcyjne i uzyskać lepszą kontrolę nad procesem.
Ostateczne myśli
Jak wspomnieliśmy, dane mają kluczowe znaczenie dla wszystkich organizacji i zapewnienie ich bezpieczeństwa i ochrony ma kluczowe znaczenie. Szyfrowanie danych w spoczynku jest jednym z ważnych elementów całego obrazu. Chcielibyśmy usłyszeć od Ciebie o Twoich doświadczeniach z szyfrowaniem danych w spoczynku w MariaDB. Jeśli chcesz podzielić się swoimi przemyśleniami, możesz zostawić komentarz poniżej.
