Bezpieczeństwo jest dziś najważniejsze w całym IT. Od czasu do czasu słyszymy o atakach ransomware lub wyciekach danych, które mają swoje źródło w niezabezpieczonych bazach danych lub infrastrukturze IT. Możesz się zastanawiać:jakie są najlepsze praktyki w projektowaniu środowiska MySQL, abyś mógł czuć się bezpiecznie ze swoimi danymi? Jeśli tak, ten blog jest dla Ciebie. Należy pamiętać, że nie omówimy tego tematu w pełni - pasowałoby to bardziej do białej księgi niż do bloga. Dołożymy wszelkich starań, aby wspomnieć o najważniejszych aspektach zabezpieczenia Twojej bazy danych MySQL. Ideą tego bloga jest to, aby czytelnik wiedział, czego nie wie i pomógł zidentyfikować tematy i słowa kluczowe do dalszych badań. Zilustrujemy to zrzutami ekranu z naszego produktu, ClusterControl, który zawiera szeroki zestaw funkcji, w tym niektóre dotyczące bezpieczeństwa bazy danych.
Sieć
Przede wszystkim musimy gdzieś wdrożyć MySQL. Niezależnie od tego, czy jest to samodzielna instancja, podstawowa - replika asynchroniczna replikacja, czy jedna z bardziej zaawansowanych topologii replikacji synchronicznej, takich jak Galera lub klaster InnoDB. Bez względu na to, co to jest, musi być chronione na poziomie sieci. Baza danych zawiera dane, które nierzadko są najcenniejszym zasobem całej organizacji.
Zabezpieczenie dostępu
Instancje bazy danych nigdy nie powinny znajdować się w sieci publicznej. Segmenty sieci, w których skonfigurowane są bazy danych, powinny być dostępne tylko z ograniczonej liczby innych sieci. Ogólna zasada brzmi – czy dany węzeł powinien mieć dostęp do sieci baz danych? Jeśli odpowiedź brzmi nie, sieci powinny być rozdzielone.
Oczywiście wszystko zależy od dokładnej konfiguracji, ale w najczęstszych przypadkach, gdy masz warstwy aplikacji, proxy, pamięci podręcznej i bazy danych, najbardziej typową konfiguracją jest to, że tylko proxy powinno być w stanie aby uzyskać dostęp do bazy danych. Wszystkie inne podmioty powinny być skonfigurowane w taki sposób, aby uzyskiwały dostęp do bazy danych tylko przez warstwę proxy. Ten projekt jest dobry pod wieloma względami. Oprócz zwiększonego bezpieczeństwa pomaga również ukryć przed aplikacją złożoność warstwy bazy danych.
Warstwa proxy powinna podążać za topologią bazy danych i powinna obsługiwać awarie węzłów bazy danych i zmiany topologii. Aplikacja łącząca się z warstwą proxy powinna zawsze mieć możliwość dotarcia do działającego węzła bazy danych odpowiedniego do typu żądania. To samo dotyczy warstwy pamięci podręcznej. Można go zaimplementować w warstwie proxy, niektóre serwery proxy, takie jak ProxySQL, zezwalają na żądania pamięci podręcznej w obrębie proxy, ale jeśli jest to osobna warstwa zbudowana wokół, na przykład memcache lub Redis, powinna zawsze sięgać do bazy danych przez warstwę proxy.
Kolejnym typem węzłów, który może wymagać bezpośredniego dostępu do warstwy bazy danych, są węzły zarządzania – te, które są wykorzystywane przez zespoły operacyjne do zarządzania bazami danych. Powód jest prosty:niektóre zadania konserwacyjne mogą wymagać bezpośredniego dostępu do baz danych. Mogą to być skrypty automatyzacji zadań, przewijanie podręczników Ansible w całej flocie baz danych lub inne zadania. W takim przypadku oczywiście powinny istnieć środki bezpieczeństwa, aby zapewnić, że tylko osoby, które mają dostęp, mogą zalogować się do takiego węzła zarządzania.
Innym możliwym typem węzłów (choć do tego można również wykorzystać węzły zarządzania), które mogą wymagać dostępu do bazy danych, są węzły zaangażowane w zbieranie metryk i prezentowanie ich użytkownikom - mówimy tu o monitorowaniu i działania alarmowe.
VPN
W przypadku każdego rodzaju warstwy bazy danych obejmującej wiele centrów danych należy rozważyć użycie VPN do ich połączenia. Otwarte, nieszyfrowane połączenia przez sieć WAN to coś, co nigdy nie powinno mieć miejsca. Nawet skonfigurowanie szyfrowania SSL nie jest najlepszą opcją, ponieważ wymagałoby to otwarcia dostępu między warstwą bazy danych a siecią WAN - połączenia SSL między węzłami bazy danych wymagają od nich możliwości bezpośredniego połączenia. VPN rozwiązuje ten problem, dodając pośrednika, który tworzy bezpieczny sposób łączenia segmentów sieci warstwy bazy danych.
VPN powinien być również obowiązkowy dla każdego rodzaju dostępu użytkownika do sieci organizacji, ponieważ wdraża bezpieczną łączność między stacją roboczą a siecią produkcyjną.
Zapora sieciowa
Oczywiście przy zabezpieczaniu sieci powinniśmy rozważyć użycie firewalla. Ogólnie rzecz biorąc, każdy węzeł bazy danych powinien odbierać połączenia tylko ze zdefiniowanego zestawu źródeł - nazw hostów i portów. Nawet „wymagane” segmenty sieci nie powinny mieć pełnego dostępu do sieci bazy danych, a jedynie do wymaganych portów. Jeśli serwer proxy musi połączyć się tylko z portem bazy danych, nie ma powodu, aby mógł uzyskać dostęp do dowolnego innego portu w węzłach bazy danych. Należy również pamiętać, że nie należy używać domyślnych portów. Jest to oczywiście zabezpieczenie przez ukrywanie - w końcu port jest gdzieś otwarty, ale pomaga radzić sobie przynajmniej z niektórymi włamaniami do bezpieczeństwa, które wykorzystują automatyczne skrypty. Nie przeszkodzi to komuś, kto jest zdeterminowany, aby uzyskać dostęp, ale może go spowolnić (w połączeniu z wykrywaniem skanowania portów i środkami zapobiegającymi skanowaniu), jednocześnie uniemożliwiając powodzenie automatycznych ataków.
Bezpieczeństwo bazy danych
Sieć to pierwsza linia obrony, istnieją inne środki bezpieczeństwa i dobre praktyki, których możesz użyć, aby jeszcze bardziej poprawić swoje bezpieczeństwo. Niektóre z nich można zaimplementować w samej bazie danych.
Użytkownicy i hosty
Samych baz danych można używać do implementacji kontroli dostępu i ograniczeń. Na początek można zaimplementować kontrolę dostępu opartą na hoście, uniemożliwiając hostom innym niż krótka lista węzłów logowanie się do bazy danych. Oczywiście, jeśli użyłeś firewalla do ograniczenia dostępu, może to brzmieć jak duplikat, ale nadal dobrym pomysłem jest ograniczenie dostępu do samej bazy danych - nigdy nie wiesz, kiedy przez przypadek firewall zostanie wyłączony. W takim przypadku nadal masz drugą warstwę ochrony.
To, co chcesz tutaj zaimplementować, to lista użytkowników bazy danych i hostów, którzy mają dostęp do bazy danych. Najprawdopodobniej powinieneś mieć dostęp do jednego lub więcej użytkowników z hostów znajdujących się w warstwie proxy. Stopień szczegółowości kontroli dostępu zależy od posiadanego systemu bazy danych. Na przykład MySQL nie pozwala na szczegółową kontrolę nad maskami sieci - po prostu używa /32, /24, /16 lub /8. Z drugiej strony w PostgreSQL możesz użyć dowolnego rodzaju maski sieciowej.
Dotacje
Jeżeli Twoja baza danych na to pozwala, każdy z użytkowników powinien mieć zdefiniowany zestaw grantów - zapewniając, że przypisane mu uprawnienia są minimum wymagane do wykonania przez użytkownika czynności, które musi wykonać . Systemy baz danych mogą mieć różne zestawy uprawnień i różne ich poziomy. Zazwyczaj mamy kilka poziomów uprawnień - globalne, mające wpływ na cały serwer bazy danych, poziom schematu - dany użytkownik może mieć różne uprawnienia przypisane do różnych schematów. Możesz mieć uprawnienia na poziomie tabeli lub nawet kolumny. Jak wspomnieliśmy wcześniej, celem jest stworzenie minimalnego zestawu uprawnień dla każdego użytkownika. Prawdopodobnie będziesz chciał mieć przynajmniej jednego użytkownika z wysokimi uprawnieniami - będzie on używany do zarządzania bazą danych. Taki użytkownik powinien być ściśle ograniczony, jeśli chodzi o łączność. Nie powinno (i w rzeczywistości żaden z użytkowników nie powinien) mieć możliwości łączenia się z dowolnej lokalizacji - powinien to być albo host lokalny, albo jakiś konkretny węzeł zarządzania, dedykowany do wykonywania operacji na bazie danych.
Zarządzanie hasłami
Każdy użytkownik w bazie danych powinien mieć zdefiniowane hasło. To jest oczywiste. Hasło powinno być przechowywane w postaci skrótu. Powinieneś upewnić się, że do przechowywania haseł używasz najbezpieczniejszego algorytmu skrótu, jaki ma do zaoferowania Twoja baza danych. Hasła nie powinny być łatwe do odgadnięcia ani nie powinny być podatne na atak słownikowy. Niektóre systemy bazodanowe, takie jak MySQL, pozwalają precyzyjnie określić wymagania, jakie muszą spełniać Twoje hasła, aby można było z nich korzystać. Małe i duże litery, cyfry, znaki specjalne, długość hasła - to wszystko jest ważne i jeśli możesz wymusić jakieś zasady dotyczące siły hasła, powinieneś to zrobić. Kolejnym ważnym elementem jest rotacja haseł. Hasła nie powinny być tworzone raz na zawsze przez cały okres istnienia bazy danych, powinieneś mieć politykę rotacji haseł. Ponownie, niektóre systemy baz danych mogą to za Ciebie wymusić. Użytkownik administracyjny może mieć możliwość tworzenia nowych kont użytkowników z wymuszoną rotacją haseł. Może również wymusić rotację haseł dla danego użytkownika.
Dzienniki audytu
Niektóre systemy bazodanowe oferują logi audytu - chodzi o to, aby zebrać jak najwięcej informacji o aktywności w bazie danych. Kto i kiedy co zrobił? Które zapytanie zostało wykonane, przez kogo? Kto próbował się zalogować, ale nie udało się? Z jakiego gospodarza? W idealnym przypadku dzienniki zawierające takie informacje byłyby przechowywane poza węzłami bazy danych. Możesz przesyłać je strumieniowo do centralnego serwera dziennika w celu przechowywania, dalszego przetwarzania i lepszych możliwości wyszukiwania.
Bezpieczeństwo SQL
Wspomnieliśmy o użytkownikach i hostach, ale atak może również nastąpić z innego źródła. Jeśli Twoja aplikacja nie jest odpowiednio zabezpieczona, a dane wejściowe nie są poprawnie zweryfikowane, możesz napotkać ataki pochodzące z Twojej witryny. Mówimy tutaj o wstrzykiwaniu SQL. W takim przypadku zapory nie są tak naprawdę przydatne, biorąc pod uwagę, że zapytanie pochodzi z prawidłowego źródła (serwera WWW, a następnie węzła proxy). Przyznawanie grantów może faktycznie pomóc w zapobieganiu niektórym tego rodzaju atakom, ale nie jest to idealne rozwiązanie - w końcu Twoja aplikacja w większości przypadków będzie potrzebowała użytkownika, który może usunąć lub zmodyfikować zawartość bazy danych. Taki użytkownik, gdy zostanie wykorzystany, może zostać wykorzystany do wyrządzenia szkody. Istnieje kilka sposobów przeciwdziałania smakołykom.
Zapora sieciowa SQL
Najprostszym sposobem na to jest zaimplementowanie zapory SQL. Można tego dokonać na różnych poziomach iw różnych miejscach. Jedną z opcji jest użycie do tego równoważenia obciążenia. Niektóre z nich mają tę funkcjonalność, co najmniej łatwo osiągalną, jeśli nie zostały jeszcze zaimplementowane. Ideą, która się za tym kryje, jest zbudowanie listy zapytań, które wykonuje aplikacja, a następnie skonfigurowanie serwera proxy tak, aby przepuszczał tylko ten rodzaj ruchu. Nie jest to idealne rozwiązanie, ponieważ będziesz musiał je utrzymywać w czasie, dodając nowe zapytania i usuwając stare, które nie są już używane. Z drugiej strony, taki zestaw reguł uniemożliwi dotarcie do bazy danych nieautoryzowanym zapytaniom.
Wykrywanie wstrzyknięć SQL
Inną możliwą opcją byłoby zaimplementowanie wykrywania wstrzyknięć SQL w warstwie proxy. Istnieje kilka rozwiązań, między innymi ProxySQL, które można skonfigurować tak, aby próbowały wykryć iniekcję SQL w ruchu, który przez nie przechodzi. Oczywiście wszystko to opiera się na heurystyce, więc może skutkować fałszywymi alarmami, ale może być dobrym dodatkiem do zapory SQL.
W przeszłości omawialiśmy, jak zaimplementować zaporę SQL i wykrywanie iniekcji SQL za pomocą ProxySQL, modułu równoważenia obciążenia, który można wdrożyć z ClusterControl:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-część druga
Bezpieczeństwo danych
Na koniec bezpieczeństwo danych. Do tej pory dyskutowaliśmy o tym, jak wzmocnić bazę danych, jak ograniczyć do niej dostęp oraz jak zapobiegać różnego rodzaju atakom pochodzącym z samej aplikacji. Nadal powinniśmy rozważyć ochronę samych danych. To może mieć kilka warstw. Bezpieczeństwo fizyczne — jeśli jesteś właścicielem centrum danych, upewnij się, że jest ono odpowiednio zablokowane. Jeśli korzystasz z zewnętrznych dostawców usług internetowych lub dostawców usług w chmurze, upewnij się, że mają odpowiednie protokoły bezpieczeństwa, jeśli chodzi o dostęp do sprzętu. Następnie mamy serwer, maszynę wirtualną lub inny sposób, z którego korzystasz. Dane znajdują się na dysku, przechowywane lokalnie na serwerze. Dane są przesyłane między aplikacją, serwerem proxy i bazą danych. Dane są przesyłane między węzłami bazy danych za pomocą replikacji. Dane są przechowywane poza siedzibą firmy jako kopie zapasowe. Te dane powinny być chronione.
Kopie zapasowe
Kopie zapasowe zawsze powinny być szyfrowane. Klucz szyfrowania powinien być starannie utrzymywany i regularnie zmieniany.
Dane w drodze
Przesyłane dane powinny być zaszyfrowane. Upewnij się, że Twoja aplikacja, warstwa proxy i baza danych zostały skonfigurowane do korzystania z protokołu SSL lub TSL. Każdy sposób przesyłania danych pomiędzy węzłami bazy danych powinien być również zabezpieczony i zaszyfrowany. Celem jest uczynienie wszelkiego rodzaju podsłuchiwania sieci bez sensu.
Dane w spoczynku
Na koniec same dane przechowywane w węźle bazy danych. Powinien być również zaszyfrowany. Istnieje kilka metod, których możesz użyć, podchodząc do tego tematu. Po pierwsze, szyfrowanie na poziomie hosta. Wolumin, na którym baza danych ma swój katalog danych, może zostać zaszyfrowany (i odszyfrowany podczas rozruchu). Bazy danych mają również tendencję do szyfrowania. To, co można zaszyfrować, zależy od konkretnego rozwiązania oraz typu i wersji bazy danych, ale w niektórych przypadkach opcje są dość rozbudowane. Szyfrowanie przestrzeni tabel, szyfrowanie logów, czasem nawet szyfrowanie struktur w pamięci. Jeśli zrobisz to poprawnie, dostęp do węzła bazy danych nie wystarczy, aby uzyskać dostęp do danych.
Wnioski
Jak wspomnieliśmy wcześniej, ten blog nie jest praktycznym przewodnikiem po bezpieczeństwie baz danych, ale poruszyliśmy większość aspektów, które należy wziąć pod uwagę przy projektowaniu środowiska bazy danych i mamy nadzieję ten przewodnik okaże się przydatny.
