TLS, dostęp sieciowy i uprawnienia SQL odpowiadają na różne pytania
Szyfrowanie połączenia, dopuszczenie źródła i nadanie tabeli to trzy decyzje. Przejdź je po kolei, zanim zapytasz, czy TLS może zastąpić VPN.
Ktoś proponuje dać klientowi login PostgreSQL, aby wniosek o zwrot kosztów podróżował zaszyfrowany od początku do końca. Administrator bazy danych potrzebuje prawdziwej sesji SQL, a ktoś inny proponuje zamiast tego formularz webowy. Oba pomysły rozwiązują niewłaściwy problem, bo żaden nie zaczął od operacji, którą klient faktycznie wykonuje. Przejdź trzy decyzje po kolei, a pytanie, czy TLS może zastąpić VPN, odpowie samo.
Zacznij od operacji, której potrzebuje klient
Zapisz, co klient ma osiągnąć. Złożenie wniosku, odczyt jednego wiersza raportu i uruchomienie doraźnego zapytania to trzy różne operacje o trzech różnych profilach ryzyka.
Następnie zapisz, kto składa żądanie. Klient, pracownik wsparcia i administrator nie są wymienni, nawet gdy dotykają tej samej tabeli. Różnica decyduje o tym, ile języka zapytań klient powinien kiedykolwiek zobaczyć.
Para odpowiedzi decyduje o interfejsie. Wszystko później to implementacja, a większość sporów o szyfrowanie to w rzeczywistości spory o to, który interfejs wybrano.
Trzy kontrole, trzy decyzje
Uwierzytelniony TLS chroni połączenie i decyduje, które tożsamości TLS są akceptowane. Dostęp sieciowy decyduje, które źródła mogą w ogóle dotrzeć do nasłuchującego procesu. Autoryzacja w bazie danych decyduje, których obiektów i akcji może używać rola.
Żadna z trzech nie zastępuje pozostałych, co tabela pokazuje wprost.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Przeczytaj wiersz, na którym polegasz, zanim usuniesz inny. Większość takich projektów zawodzi, bo kontrolę założono, zamiast ją skonfigurować.
Bezpośredni SQL zostawia politykę bazy danych odpowiedzialną
Przy zatwierdzonym połączeniu bezpośrednim zachowaj zarówno weryfikację tożsamości usługi, jak i zamierzoną politykę dostępu. Włączenie TLS udostępnia połączenia szyfrowane; nie odrzuca niezaszyfrowanych, chyba że konfiguracja dostępu wymaga tego przez wpisy hostssl.
Tę różnicę warto sprawdzić w działającej konfiguracji, a nie w szablonie. Serwer, który oferuje TLS i przyjmuje zwykły tekst, nie jest projektem, który większość uważa, że wdrożyła. Przeczytaj reguły dostępu i sprawdź, które wpisy rzeczywiście tego wymagają. To jedno sprawdzenie oddziela serwer zdolny do szyfrowania od serwera tylko szyfrowanego.
Używaj ról tylko z uprawnieniami, których wymaga praca, i przeglądaj własność, odziedziczone członkostwo i szeroko nadane uprawnienia. Model uprawnień PostgreSQL jest granicą władzy dla obiektów bazy danych.
VPN może ograniczyć, które urządzenia docierają do usługi przed uwierzytelnieniem w bazie danych, a brama dostępu może zrobić coś podobnego. Żadne z nich nie usuwa potrzeby utrzymywania wystawionego komponentu, zarządzania poświadczeniami i ograniczania zużycia zasobów.
Certyfikaty klienta to poświadczenie, nie ACL
Certyfikat klienta może dodać wymóg w chwili połączenia. Ustawienie clientcert może wymagać zaufanego certyfikatu, a w trybie bardziej rygorystycznym relacji między nazwą certyfikatu a użytkownikiem bazy danych.
To silniejsze poświadczenie. To nie jest lista autoryzacji i nie czyni serwera niewidocznym, bo komponent przyjmujący połączenie nadal przetwarza ruch sieciowy i uścisk dłoni. Traktowanie certyfikatu jako listy dostępu pozostawia rzeczywiste uprawnienia nietknięte. Ma też skłonność do poszerzania dystrybucji certyfikatów, co tworzy następny problem.
Silny certyfikat przypisany do roli z nadmiarem uprawnień daje dobrze uwierzytelnionego administratora. Sprawdź rolę, zanim zaczniesz świętować certyfikat.
Wybierz węższy interfejs, gdy pasuje
Dla wniosku o zwrot kosztów punkt końcowy aplikacji, który przyjmuje wniosek, egzekwuje reguły biznesowe i zwraca dozwolony wynik tego użytkownika, reprezentuje operację lepiej niż ogólne konto SQL.
Aplikacja używa potem własnej ograniczonej tożsamości w bazie danych, a klient nigdy nie otrzymuje języka zapytań jako funkcji. To mniejsza powierzchnia z mniejszą liczbą sposobów na błąd.
To wybór projektowy, a nie twierdzenie, że kod aplikacji jest automatycznie bezpieczniejszy. Ten kod musi uwierzytelniać swoich wywołujących, autoryzować każdą akcję i walidować dane wejściowe, a jego własne uprawnienia w bazie danych nadal mają znaczenie.
Bezpośredni SQL pozostaje właściwy dla osób i narzędzi, których zatwierdzona praca tego wymaga. Ogranicz ten projekt rolami, zasięgiem sieci i limitami operacyjnymi, a pozostałym klientom zostaw węższy interfejs. Mieszanie obu populacji w jednej roli to miejsce, w którym zaczynają się spory.