Hybrydowa chmura może być świetnym sposobem na zwiększenie elastyczności istniejących wdrożeń lokalnych. Jak pisaliśmy na kilku blogach, chmura publiczna może być świetnym dodatkiem do własnego centrum danych, zapewniając możliwość łatwego skalowania w celu obsługi obciążenia, zmniejszenia nakładów inwestycyjnych i wdrożenia procedur odzyskiwania po awarii. Bezpieczeństwo to kolejny aspekt, który musisz przemyśleć, kiedy planujesz budować takie systemy. W tym poście na blogu omówimy niektóre kwestie związane z bezpieczeństwem wdrożeń MariaDB w chmurze hybrydowej.
Łączność
VPN
Główną częścią każdej infrastruktury hybrydowej jest sieć. W końcu mówimy o dwóch środowiskach, lokalnym, on-premise i chmurze publicznej, które muszą być połączone i tworzyć jedną całość. Połączenie musi być szyfrowane. Jak do tego podejść, można to zrobić na wiele sposobów.
Jednym z nich byłoby skorzystanie z rozwiązania udostępnionego przez dostawcę chmury – większość z nich ma jakąś opcję łączności. Może to być AWS Direct Connect, jeśli integrujesz się z Amazon Web Services. Jeśli planujesz korzystać z Google Cloud, rozwiązania są omówione na następującej stronie internetowej:https://cloud.google.com/hybrid-connectivity. Krótko mówiąc, istnieje wiele różnych opcji, które różnią się od sprzętowej integracji VPN do konfiguracji komunikacji równorzędnej BGP.
Po drugiej stronie spektrum mamy programowe rozwiązania VPN. OpenVPN lub podobny rodzaj oprogramowania może być użyty do ustanowienia bezpiecznego, szyfrowanego połączenia sieciowego między własnym centrum danych a chmurą publiczną. W takim przypadku potrzebujesz osobnej instancji działającej w chmurze publicznej, która będzie używana przez serwer VPN. Korzystanie z oprogramowania VPN pozwala wybrać rozwiązanie, które najlepiej odpowiada Twoim wymaganiom i najlepiej pasuje do Twojego środowiska.
Zapora sieciowa
Bazy danych nigdy nie powinny być dostępne z sieci zewnętrznych. Najważniejsze jest zbudowanie środowiska w taki sposób, aby warstwa bazy danych była dostępna tylko z ograniczonego zestawu hostów. Dokładnie to, co jest wymagane i jak to zrobić, zależy od Ciebie. Typowa konfiguracja składa się z zabezpieczonej warstwy bazy danych, do której można uzyskać dostęp tylko z warstwy proxy, a w razie potrzeby należy zaimplementować jakiś host przeskoku, jeśli jest to wymagane do zadań automatyzacji i administracyjnych.
Serwery aplikacji nie powinny mieć bezpośredniego dostępu do bazy danych - nie muszą. Wszystko, co aplikacja powinna zrobić, to połączyć się z systemem równoważenia obciążenia. Systemy równoważenia obciążenia powinny mieć możliwość łączenia się z bazą danych. System równoważenia obciążenia, taki jak ProxySQL, doskonale radzi sobie z podziałem odczytu/zapisu oraz wysyłaniem odczytów i zapisów do właściwych węzłów bazy danych. Aplikacja powinna być w stanie połączyć się z ProxySQL, a reszta będzie obsługiwana przez proxy - uwierzytelnianie bazy danych, kształtowanie ruchu, dystrybucja ruchu na wiele replik, które możesz mieć. Wszelki niepotrzebny dostęp powinien być ograniczony. Grupy bezpieczeństwa, zapory — to narzędzia, których chcesz użyć do zabezpieczenia swojego środowiska.
W skrócie, dostęp do hostów bazy danych powinien być dozwolony tylko na wymaganych portach. W przypadku MariaDB będzie to oczywiście port używany do obsługi bazy danych, ale w razie potrzeby także inne porty - możesz mieć zainstalowane jakieś eksportery lub agenty. W przypadku Galery konieczne byłoby otwarcie portów do komunikacji wewnątrz klastra. Możesz również chcieć mieć otwarty port dla połączeń SSH. Najlepiej ograniczyć dostęp na podstawie hosta; tylko ograniczony zestaw hostów może uzyskać dostęp do danego portu. Na przykład port bazy danych może być dostępny z innych węzłów bazy danych, lokalnego hosta i warstwy proxy. Nie ma potrzeby otwierania go dla innych węzłów. Twoje węzły bazy danych mogą nawet znajdować się w oddzielnej podsieci, co zapewnia jeszcze większe bezpieczeństwo.
Jeśli chodzi o porty, najlepszą praktyką jest zmiana ich ustawień domyślnych na inne. Najlepiej coś losowego. Zmiana portu SSH z 22 na 2222 lub portu MariaDB z 3306 na 33306 może pomóc w uniknięciu niektórych zautomatyzowanych ataków, ale nadal można stwierdzić, czy ktoś aktywnie szuka dostępu do Twojej sieci. Jeśli chcesz większego bezpieczeństwa, możesz po prostu użyć kilku losowych wartości. Ustaw SSH na 5762, a MariaDB na 24359. Jest całkiem prawdopodobne, że nikt nie będzie w stanie ich odgadnąć. Ustaw limity czasu TCP tak, aby skanowanie portów było bardzo długie i kosztowne, a to z pewnością zwiększy Twoje szanse.
SSL
Oprócz VPN i zapory sieciowej należy upewnić się, że ruch bazy danych jest szyfrowany przy użyciu protokołu SSL.
W idealnym przypadku będziesz chronić zarówno połączenia frontendowe (przed load balancerami), jak i komunikacja między węzłami Twojej bazy danych (czy to replikacja, czy transfer wewnątrz klastra w klastrach Galera). ClusterControl może pomóc Ci włączyć te opcje za pomocą zaledwie kilku kliknięć.
Wszystko, co musisz zrobić, to pozwolić ClusterControl tworzyć nowe certyfikaty lub używać jednego z istniejących — jeśli chcesz, możesz zaimportować własny certyfikat. Włączenie SSL zapewnia, że ruch bazy danych nie będzie czytelny nawet przez osobę, która uzyskała dostęp do Twojej sieci.
Bezpieczeństwo bazy danych
Oczywiście sieć nie jest jedynym ważnym aspektem bezpieczeństwa. Tak, jest to krytyczne, szczególnie w środowisku chmury hybrydowej, ale są też inne bardzo ważne aspekty. Jednym z nich jest kontrola dostępu wbudowana w MariaDB.
Kontrola dostępu oparta na rolach dla MariaDB
MariaDB zawiera zestaw instrumentów zapewniających, że dostęp do bazy danych jest odpowiednio zarządzany i ograniczany wszędzie tam, gdzie jest to wymagane. Pierwsza linia uwierzytelniania to użytkownicy. Każdy i wszystko, co ma dostęp do MariaDB, powinno używać przypisanego użytkownika do łączenia się z bazą danych. Tacy użytkownicy będą mieli prawidłowe hasło — możesz włączyć sprawdzanie poprawności hasła w MariaDB, aby upewnić się, że hasła są wystarczająco silne. W idealnym przypadku ograniczyłbyś host dostępu użytkownika tylko do nazw hostów lub adresów IP systemów równoważenia obciążenia — w ten sposób użytkownicy zawsze łączą się z bazą danych. W przypadku niektórych użytkowników administracyjnych możesz chcieć zachować dostęp do hosta lokalnego, jeśli jest to wymagane. Oprócz wymuszania odpowiedniej siły hasła możesz skonfigurować hasło tak, aby wygasało po pewnym czasie lub wymusić rotację haseł na użytkownikach. Jak możesz sobie wyobrazić, właściwa polityka rotacji haseł to coś, co chcesz wdrożyć.
Każdy użytkownik w MariaDB może mieć przypisanych wiele uprawnień. Uprawnienia można nadawać na kilku poziomach - globalnym, bazodanowym, tabelowym, a nawet kolumnowym. Najlepszą praktyką jest nadanie użytkownikom ograniczonego zestawu uprawnień. Jeśli użytkownik potrzebuje dostępu tylko do określonej tabeli, po prostu mu to przyznaj. Nie ma potrzeby, aby ten użytkownik miał dostęp do innych tabel, nie wspominając o innych schematach. Możesz zdefiniować dość szczegółowe prawa dostępu, korzystając z dużego zestawu uprawnień, które możesz nadawać użytkownikom. Obejmuje ona prawa do odczytu, aktualizacji lub usuwania danych poprzez uprawnienia do zarządzania bazą danych, aż po uprawnienia „super”, które umożliwiają użytkownikowi wykonywanie działań, takich jak zarządzanie wątkami replikacji i pomijanie ustawienia tylko do odczytu.
Ponadto MariaDB zawiera role — aby ułatwić zarządzanie użytkownikami, można zdefiniować role z danym zestawem przyznanych uprawnień, a następnie przypisać te role użytkownikom. Tacy użytkownicy będą dziedziczyć granty związane z rolą, do której zostali przypisani, co ułatwi zarządzanie grantami na dużą skalę:zamiast zmieniać granty dla wielu użytkowników, możesz przypisać im jedną konkretną rolę, a następnie zarządzać wszystkimi ich uprawnieniami poprzez zmiana uprawnień przyznanych roli, do której zostały przypisane.
Powinieneś również upewnić się, że nie masz żadnych istniejących użytkowników bez przypisanego hasła lub ze zbyt dużym zestawem uprawnień. Taki audyt bezpieczeństwa powinien być przeprowadzany od czasu do czasu, upewniając się, że jesteś świadomy potencjalnych zagrożeń bezpieczeństwa i możesz zaplanować działania w ich przypadku.
Dziennik audytu
Jeśli Twoja baza danych zawiera dziennik kontroli, tak jak MariaDB, powinieneś rozważyć użycie go do śledzenia działań, które mają miejsce w bazie danych. Dziennik audytu pomoże Ci to osiągnąć. Po włączeniu będziesz mógł śledzić nawet szczegóły, takie jak użytkownik, który wykonał dane zapytanie. Jeśli używasz ClusterControl, możesz włączyć dziennik audytu za pomocą kilku kliknięć:
Podsumowując ten blog, należy wziąć pod uwagę kilka rzeczy, projektując wdrożenie MariaDB w środowisku chmury hybrydowej. Niektóre z nich są ściśle związane ze sposobem zaprojektowania środowiska, inne są w dużej mierze związane z typem bazy danych, z której korzystasz, a fakt, że korzystasz z chmury hybrydowej, tak naprawdę nie zmienia. Naprawdę ważne jest upewnienie się, że Twoja baza danych jest odpowiednio chroniona - to ostateczny cel, bez względu na środowisko.
