PostgreSQL to jedna z najbezpieczniejszych baz danych na świecie. Bezpieczeństwo bazy danych odgrywa kluczową rolę w rzeczywistych środowiskach o znaczeniu krytycznym. Ważne jest, aby bazy danych i dane były zawsze zabezpieczone i nie podlegały nieautoryzowanemu dostępowi, co zagrażałoby bezpieczeństwu danych. Chociaż PostgreSQL zapewnia użytkownikom różne mechanizmy i metody bezpiecznego dostępu do bazy danych, można go również zintegrować z różnymi zewnętrznymi systemami uwierzytelniania, aby zapewnić spełnienie standardowych wymagań bezpieczeństwa bazy danych w przedsiębiorstwie.
Oprócz zapewniania bezpiecznych mechanizmów uwierzytelniania przez SSL, MD5, pgpass i pg_ident itp., PostgreSQL może być zintegrowany z różnymi innymi popularnymi zewnętrznymi systemami uwierzytelniania klasy korporacyjnej. W tym blogu skupię się na LDAP, Kerberos i RADIUS z SSL i pg_ident.
LDAP
LDAP odnosi się do Lightweight Directory Access Protocol, który jest powszechnie używanym scentralizowanym systemem uwierzytelniania. Jest to magazyn danych, który przechowuje poświadczenia użytkownika i różne inne szczegóły związane z użytkownikiem, takie jak nazwy, domeny, jednostki biznesowe itp. W formie hierarchii w formacie tabeli. Użytkownicy końcowi łączący się z systemami docelowymi (np. bazą danych) muszą najpierw połączyć się z serwerem LDAP, aby przejść pomyślnie uwierzytelnianie. LDAP to jeden z popularnych systemów uwierzytelniania używanych obecnie w organizacjach wymagających wysokich standardów bezpieczeństwa.
LDAP + PostgreSQL
PostgreSQL można zintegrować z LDAP. W moim doświadczeniu w konsultingu z klientami jest to uważane za jedną z kluczowych możliwości PostgreSQL. Ponieważ uwierzytelnianie nazwy użytkownika i hasła odbywa się na serwerze LDAP, aby zapewnić użytkownikom możliwość łączenia się z bazą danych przez LDAP, konto użytkownika musi istnieć w bazie danych. Innymi słowy, oznacza to, że użytkownicy próbujący połączyć się z PostgreSQL są najpierw kierowani do serwera LDAP, a następnie do bazy danych Postgres po pomyślnym uwierzytelnieniu. Konfigurację można przeprowadzić w pliku pg_hba.conf, aby upewnić się, że połączenia są kierowane do serwera LDAP. Poniżej znajduje się przykładowy wpis pg_hba.conf -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"Poniżej znajduje się przykład wpisu LDAP w pg_hba.conf:
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", ou=finance, dc=example, dc=com"W przypadku korzystania z innego niż domyślny portu ldap i TLS:
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"Zrozumienie powyższego wpisu LDAP
- LDAP używa różnych atrybutów i terminologii do przechowywania / wyszukiwania wpisu użytkownika w swoim magazynie danych. Ponadto, jak wspomniano powyżej, wpisy użytkowników są przechowywane w hierarchii.
- Powyższe wpisy ldap pg_hba.conf składają się z atrybutów zwanych CN (nazwa wspólna), OU (jednostka organizacyjna) i DC (składnik domeny), które są określane jako względne nazwy wyróżniające (RDN), te sekwencje RDN razem stają się czymś o nazwie DN (Nazwa Wyróżniająca). DN to obiekt LDAP, na podstawie którego wyszukiwanie jest przeprowadzane w magazynie danych LDAP.
- Wartości atrybutów LDAP, takie jak CN, DC, OU itp., są zdefiniowane w klasach obiektów LDAP, które mogą być dostarczone przez ekspertów systemowych, którzy zbudowali środowisko LDAP.
Czy to wystarczająco zabezpieczy LDAP?
Może nie. Hasła przesyłane przez sieć w środowisku LDAP nie są szyfrowane, co może stanowić zagrożenie bezpieczeństwa, ponieważ zaszyfrowane hasła mogą zostać złamane. Istnieją opcje, dzięki którym komunikacja danych uwierzytelniających jest bezpieczniejsza.
- Rozważ konfigurację LDAP w TLS (Transport Layer Security)
- LDAP można skonfigurować z SSL, co jest kolejną opcją
Wskazówki dotyczące integracji LDAP z PostgreSQL
(dla systemów opartych na Linuksie)
- Zainstaluj odpowiednie moduły openLDAP w oparciu o wersję systemu operacyjnego
- Upewnij się, że oprogramowanie PostgreSQL jest zainstalowane z bibliotekami LDAP
- Upewnij się, że LDAP jest dobrze zintegrowane z Active Directory
- Zapoznaj się z istniejącymi błędami w używanych modułach openLDAP. Może to być katastrofalne i może naruszyć standardy bezpieczeństwa.
- Windows Active Directory może być również zintegrowany z LDAP
- Rozważ skonfigurowanie protokołu LDAP z SSL, który jest bezpieczniejszy. Zainstaluj odpowiednie moduły openSSL i bądź świadomy błędów, takich jak bleed serca, które mogą ujawnić dane uwierzytelniające przesyłane przez sieć.
Kerber
Kerberos to scentralizowany system uwierzytelniania zgodny ze standardami branżowymi, powszechnie używany w organizacjach i zapewniający mechanizm uwierzytelniania oparty na szyfrowaniu. Hasła są uwierzytelniane przez serwer uwierzytelniania innej firmy o nazwie KDC (Centrum dystrybucji kluczy). Hasła mogą być szyfrowane na podstawie różnych algorytmów i mogą być odszyfrowane tylko za pomocą współdzielonych kluczy prywatnych. Oznacza to również, że hasła przesyłane przez sieć są szyfrowane.
PostgreSQL + Kerberos
PostgreSQL obsługuje uwierzytelnianie oparte na GSSAPI z Kerberos. Użytkownicy próbujący połączyć się z bazą danych Postgres zostaną skierowani do serwera KDC w celu uwierzytelnienia. To uwierzytelnianie między klientami a bazą danych KDC odbywa się na podstawie współdzielonych kluczy prywatnych, a po pomyślnym uwierzytelnieniu klienci będą teraz posiadać poświadczenia oparte na protokole Kerberos. Te same poświadczenia podlegają walidacji między serwerem Postgres a KDC, która zostanie wykonana na podstawie pliku tablicy kluczy wygenerowanego przez Kerberos. Ten plik tablicy kluczy musi istnieć na serwerze bazy danych z odpowiednimi uprawnieniami użytkownika będącego właścicielem procesu Postgres.
Proces konfiguracji i połączenia Kerberos -
-
Konta użytkowników oparte na protokole Kerberos muszą generować bilet (żądanie połączenia) za pomocą polecenia „kinit”.
-
Plik tabeli kluczy musi zostać wygenerowany za pomocą polecenia „kadmin” dla w pełni kwalifikowanego konta użytkownika opartego na protokole Kerberos (głównego), a następnie Postgres użyje tego samego pliku tabeli kluczy do zweryfikowania poświadczeń. Główne można zaszyfrować i dodać do istniejącego pliku tablicy kluczy za pomocą polecenia „ktadd”. Szyfrowanie Kerberos obsługuje różne branżowe algorytmy szyfrowania.
Wygenerowany plik tablicy kluczy musi zostać skopiowany na serwer Postgres, musi być możliwy do odczytania przez proces Postgres. Należy skonfigurować poniższy parametr postgresql.conf:
krb_server_keyfile = '/database/postgres/keytab.example.com'Jeśli zależy Ci na rozróżnianiu wielkości liter, użyj poniższego parametru
krb_caseins_users which is by default “off” (case sensitive) -
Należy wprowadzić wpis w pliku pg_hba.conf, aby upewnić się, że połączenia są kierowane do serwera KDC
Przykładowy wpis pg_hba.conf
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COMPrzykładowy wpis pg_hba.conf z wpisem mapy
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM map=krb -
Konto użytkownika, które próbuje się połączyć, musi zostać dodane do bazy danych KDC, która jest określana jako główny, a to samo konto użytkownika lub konto użytkownika mapującego musi również istnieć w bazie danych
Poniżej znajduje się przykład podmiotu Kerberos
przykł[email protected]
pguser to nazwa użytkownika, a „example.com” to nazwa obszaru skonfigurowana w konfiguracji Kerberos (/etc/krb5.conf) na serwerze KDC.
W świecie Kerberos zleceniodawcy są w formacie e-mail ([email protected]), a użytkownicy bazy danych nie mogą być utworzeni w tym samym formacie. To sprawia, że administratorzy baz danych myślą o tworzeniu mapowania nazw użytkowników bazy danych i upewniają się, że zleceniodawcy łączą się z mapowanymi nazwami za pomocą pg_ident.conf.
Poniżej znajduje się przykład wpisu nazwy mapy w pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
Czy to zapewni wystarczające zabezpieczenie Kerberos?
Może nie. Dane uwierzytelniające użytkownika przekazywane przez sieć mogą zostać ujawnione, zhakowane. Chociaż Kerberos szyfruje dane główne, można je ukraść lub zhakować. Powoduje to potrzebę wdrożenia zabezpieczeń warstwy sieciowej. Tak, SSL lub TLS to droga. System uwierzytelniania Kerberos można zintegrować z SSL lub TLS. TLS jest następcą SSL. Zaleca się skonfigurowanie protokołu Kerberos z SSL lub TLS, aby komunikacja w sieci była zabezpieczona.
WSKAZÓWKI
- Upewnij się, że biblioteki krb* są zainstalowane
- Biblioteki OpenSSL muszą być zainstalowane, aby skonfigurować SSL
- Upewnij się, że Postgres jest zainstalowany z następującymi opcjami
./configure --with-gssapi --with-krb-srvnam --with-openssl
PROMIEŃ
RADIUS to protokół sieciowy usługi zdalnego uwierzytelniania, który zapewnia scentralizowany
Uwierzytelnianie, autoryzacja i księgowość (AAA). Pary nazwa użytkownika/hasło są uwierzytelniane na serwerze RADIUS. Ten sposób scentralizowanego uwierzytelniania jest o wiele bardziej prosty i prostszy w porównaniu z innymi systemami uwierzytelniania, takimi jak LDAP i Kerberos, który wymaga pewnej złożoności.
RADIUS + PostgreSQL
PostgreSQL można zintegrować z mechanizmem uwierzytelniania RADIUS. Księgowość nie jest jeszcze obsługiwana w Postgresie. Wymaga to istnienia kont użytkowników bazy danych w bazie danych. Połączenia z bazą danych są autoryzowane na podstawie wspólnego hasła określanego jako „radiussecret”.
Wpis w konfiguracji pg_hba.conf jest niezbędny do trasowania połączeń do serwera promienia w celu uwierzytelnienia.
Przykładowy wpis pg_hba.conf
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128Aby zrozumieć powyższy wpis -
„radiusserver” to adres IP hosta serwera RADIUS, do którego użytkownicy są kierowani w celu uwierzytelnienia. Ten parametr jest konfigurowany w /etc/radiusd.conf na serwerze RADIUS.
Wartość „radiussecret” jest pobierana z pliku customers.conf. To jest tajny kod, który jednoznacznie identyfikuje połączenie klienta Radia.
„radiusport” można znaleźć w pliku /etc/radiusd.conf. To jest port, na którym będą nasłuchiwać połączenia promieniowe.
Znaczenie SSL
SSL (Secure Socket Layer) odgrywa nadrzędną rolę w przypadku zewnętrznych systemów uwierzytelniania. Zdecydowanie zaleca się skonfigurowanie SSL z zewnętrznym systemem uwierzytelniania, ponieważ nastąpi komunikacja poufnych informacji między klientami a serwerami przez sieć, a SSL może jeszcze bardziej zwiększyć bezpieczeństwo.
Wpływ na wydajność korzystania z zewnętrznych systemów uwierzytelniania
Skuteczny i wydajny system bezpieczeństwa odbywa się kosztem wydajności. Ponieważ klienci/użytkownicy próbujący połączyć się z bazą danych są kierowani do systemów uwierzytelniania w celu nawiązania połączenia, może wystąpić pogorszenie wydajności. Istnieją sposoby na pokonanie przeszkód w wydajności.
- Po uruchomieniu zewnętrznego mechanizmu uwierzytelniania może wystąpić opóźnienie podczas nawiązywania połączenia z bazą danych. Może to stanowić prawdziwy problem, gdy z bazą danych nawiązywana jest ogromna liczba połączeń.
- Deweloperzy muszą upewnić się, że niepotrzebnie duża liczba połączeń nie jest nawiązywana z bazą danych. Wiele żądań aplikacji obsługiwanych przez jedno połączenie byłoby korzystne.
- Ponadto ważną rolę odgrywa to, jak długo trwa każde żądanie na końcu bazy danych. Jeśli żądanie trwa dłużej, kolejne żądania będą ustawiane w kolejce. Dostrajanie wydajności procesów i skrupulatne zaprojektowanie infrastruktury będzie kluczowe!
- Baza danych i infrastruktura muszą być wydajnie zaprojektowane i odpowiednio wyposażone, aby zapewnić dobrą wydajność.
- Podczas przeprowadzania testów wydajności upewnij się, że protokół SSL jest włączony, a następnie należy ocenić średni czas nawiązania połączenia.
Integracja zewnętrznych systemów uwierzytelniania z ClusterControl — PostgreSQL
Instancje PostgreSQL mogą być budowane i konfigurowane automatycznie za pomocą GUI ClusterControl. Integracja zewnętrznych systemów uwierzytelniania z instancjami PostgreSQL wdrożonymi za pośrednictwem ClusterControl jest bardzo podobna w porównaniu z integracją z tradycyjnymi instancjami PostgreSQL i w rzeczywistości jest nieco prostsza. Poniżej znajduje się przegląd tego samego -
- ClusterControl instaluje biblioteki PostgreSQL z obsługą LDAP, KRB, GSSAPI i OpenSSL
- Integracja z zewnętrznymi systemami uwierzytelniania wymaga różnych zmian konfiguracji parametrów na serwerze bazy danych postgresql, co można wykonać za pomocą GUI ClusterControl.
