Cassandra przez VPN: osobny dostęp dla klientów i węzłów

Jeden klaster Cassandra skrywa trzy grupy odbiorców. Oddzielnie zdecyduj, jak docierają do niego klienci, węzły partnerskie i operatorzy, i trzymaj tożsamość wewnątrz ścieżki VPN.

Wdrożenie Cassandra nie ma jednej uniwersalnej sieci bazy danych. Aplikacje rozmawiają z usługą kliencką, członkowie klastra rozmawiają ze sobą, a operatorzy korzystają z interfejsów administracyjnych, i te trzy grupy odbiorców nie powinny dziedziczyć swojej osiągalności nawzajem. Prywatna ścieżka, taka jak VPN, jest dobrym punktem wyjścia, ale nie jest tożsamością użytkownika bazy danych ani jej polityką szyfrowania. Decyzję o łączności i decyzję o autoryzacji traktuj jako dwa osobne przeglądy.

Każda z trzech grup odbiorców otrzymuje własną odpowiedź, a poniższe sekcje omawiają je w kolejności według ekspozycji.

Trzy grupy odbiorców, trzy decyzje

Zidentyfikuj, czego naprawdę potrzebuje każda grupa, zanim ruszysz jakąkolwiek regułę. Klienci potrzebują nasłuchu klienckiego i wystarczającej informacji, aby dotrzeć do każdego węzła, który może im zostać przydzielony, węzły partnerskie potrzebują siebie nawzajem na porcie internode, a operatorzy potrzebują interfejsu zarządzania do tego, czego faktycznie wymaga runbook. Trzy listy, trzy grupy, trzy poziomy zaufania.

Częstym błędem jest zbudowanie jednego płaskiego segmentu prywatnego i założenie, że granica VPN załatwi resztę. Wewnątrz niego aplikacja, która dociera do portu klienckiego, zwykle dociera też do portu internode, a narzędzia administracyjne operatora często siedzą na tym samym hoście przesiadkowym co aplikacja. Spłaszczenie tego oznacza, że przejęta tożsamość aplikacji ma już większy zasięg niż własne zapytania. Narysuj trzy grupy odbiorców jako trzy wiersze w dokumencie projektowym, każdy z regułą, która go dopuszcza, a luki staną się widoczne, zanim ktokolwiek je zbuduje.

Czego potrzebują klienci, i nic więcej

Zezwalaj zamierzonym źródłom aplikacji na punkty końcowe klienta dla wdrożonej wersji i trzymaj niepowiązane usługi klastra i zarządzania poza tym zasięgiem. Następnie sprawdź, jak sterownik odnajduje węzły. Osiągalny początkowy punkt kontaktu nie dowodzi, że każdy adres węzła wybierany później przez sterownik jest osiągalny z tego kontekstu klienta, ponieważ sterownik pyta klaster o partnerów, a potem łączy się z adresami, które klaster rozgłasza.

Dlatego jedna niezgodność adresów prywatnych daje znany wzorzec: udane pierwsze połączenie, a potem przekroczenia czasu. Konfiguruj rozgłaszane adresy i trasowanie klienta świadomie; publikowanie całego klastra w internecie, aby naprawić jedną niezgodność, zamienia błąd trasowania na ekspozycję, której nie da się cofnąć.

Utrzymuj też uwierzytelnianie bazy danych i uprawnienia ról aplikacji. Wspólny przetłumaczony adres VPN może reprezentować wielu użytkowników lub usługi, więc nigdy nie zastępuje odrębnych tożsamości bazy danych.

Szyfruj osobno połączenia klient-węzeł i internode

Dokumentacja bezpieczeństwa Apache traktuje szyfrowanie klient-węzeł i internode jako osobne konfiguracje, a włączenie jednego nie włącza drugiego. To rozróżnienie nadal obowiązuje wewnątrz VPN, ponieważ tunel chroni własny segment i nie rozciąga się automatycznie z procesu aplikacji do procesu bazy danych ani między każdą parą członków klastra.

Konfiguracja, która włącza oba jawnie, zamiast dziedziczyć domyślne ustawienie szablonu, wygląda mniej więcej tak:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

W konfiguracjach serwera, które dopuszczają opcjonalne szyfrowanie klienta, akceptowanie TLS może współistnieć z akceptowaniem połączeń nieszyfrowanych, więc czytaj obowiązującą politykę, a nie intencję. Zaplanuj nazwy certyfikatów, dystrybucję zaufania i odnowienia dla punktów końcowych, z którymi każdy klient faktycznie się kontaktuje; zastąpienie nazwy hosta adresem IP zmienia sprawdzanie tożsamości klienta, nie tylko jego trasę.

Trzymaj administrację na własnej ścieżce

Ruch internode potrzebuje dozwolonego zbioru partnerów i własnej polityki ochrony. Dostęp administracyjny, w tym JMX tam, gdzie jest używany, potrzebuje odrębnej grupy odbiorców i własnego uwierzytelniania. Aplikacja dopuszczona do zwykłych zapytań nie potrzebuje przez to każdej możliwości zarządzania, a odwrotność jest gorsza: ścieżka administracyjna wystawiona na segment aplikacji to najkrótsza droga od błędu do przebudowy. Zapisz te dwie grupy osobno i wskaż ich właścicieli, bo to zwykle różne zespoły, których reguły połączono przez pomyłkę.

Utrzymuj spójność obowiązujących reguł chmurowych, reguł hosta i konfiguracji nasłuchu. Prywatny nasłuch nadal może zostać wystawiony przez niezamierzone tłumaczenie lub proxy, a szeroka reguła publiczna może spokojnie leżeć obok wąskiej reguły VPN, dopóki ktoś nie przeaudytuje obu naraz.

Tam, gdzie operatorzy naprawdę potrzebują ścieżki zarządzania, daj jej nazwanego właściciela i krótszy czas życia poświadczeń niż aplikacja. Dzięki temu delegacja pozostaje widoczna, gdy kolejna osoba przejmie klaster.

Co obiecuje projekt

Zweryfikuj wszystkie trzy obietnice realnymi rolami, a nie samymi testami łączności. Zatwierdzona aplikacja powinna wykonać dozwoloną pracę i nic więcej, wykluczone źródło powinno zawieść na wejściu klienckim, a tożsamość aplikacji powinna zostać odrzucona na zarezerwowanych ścieżkach administracyjnych. Dodaj ponowne łączenie klienta i wybór węzła do tego samego testu wdrożenia, bo tam wychodzą błędy odnajdywania.

Zakończ trzema zdaniami w dokumencie projektowym: którzy klienci mogą wysyłać zapytania, które węzły mogą się komunikować i którzy operatorzy mogą administrować. Bycie za VPN to przydatna informacja o topologii, ale nie jest odpowiedzią na żadne z tych trzech pytań.

Powiązane artykuły