Po zakończeniu procesu instalacji serwera bazy danych PostgreSQL konieczne jest zabezpieczenie go przed przejściem do produkcji. W tym poście pokażemy, jak wzmocnić zabezpieczenia Twojej bazy danych, aby Twoje dane były bezpieczne.
1. Kontrola uwierzytelniania klienta
Podczas instalacji PostgreSQL w katalogu danych klastra bazy danych tworzony jest plik o nazwie pg_hba.conf. Ten plik kontroluje uwierzytelnianie klienta.
Z oficjalnej dokumentacji postgresql możemy zdefiniować plik pg_hba.conf jako zestaw rekordów, po jednym w wierszu, gdzie każdy rekord określa typ połączenia, zakres adresów IP klienta (jeśli dotyczy typu połączenia), nazwę bazy danych, nazwę użytkownika i metodę uwierzytelniania, która ma być używana do połączeń zgodnych z tymi parametrami.Pierwszy rekord z pasującym typem połączenia, adresem klienta, żądaną bazą danych i nazwą użytkownika jest używany do uwierzytelniania.
Więc ogólny format będzie wyglądał mniej więcej tak:
# TYPE DATABASE USER ADDRESS METHODPrzykładowa konfiguracja może wyglądać następująco:
# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.93.0/24 ident
# Reject any user from any host with IP address 192.168.94.x to connect
# to database "postgres
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.94.0/24 rejectIstnieje wiele kombinacji, które możesz wprowadzić, aby udoskonalić zasady (oficjalna dokumentacja szczegółowo opisuje każdą opcję i zawiera świetne przykłady), ale pamiętaj, aby unikać zasad, które są zbyt liberalne, takich jak zezwalanie na dostęp dla linii za pomocą BAZY DANYCH wszystko lub ADRESU 0.0.0.0/0.
Aby zapewnić bezpieczeństwo, nawet jeśli zapomnisz dodać regułę, możesz dodać następujący wiersz na dole:
# TYPE DATABASE USER ADDRESS METHOD
host all all 0.0.0.0/0 rejectPonieważ plik jest odczytywany od góry do dołu, aby znaleźć pasujące reguły, w ten sposób upewnisz się, że aby zezwolić na pozwolenie, będziesz musiał wyraźnie dodać pasującą regułę powyżej.
2. Konfiguracja serwera
W pliku postgresql.conf znajduje się kilka parametrów, które możemy zmodyfikować w celu zwiększenia bezpieczeństwa.
Możesz użyć parametru listen_address do kontrolowania, które adresy IP będą mogły łączyć się z serwerem. Oto dobra praktyka zezwalania na połączenia tylko ze znanych adresów IP lub Twojej sieci i unikania ogólnych wartości, takich jak „*”, „0.0.0.0:0” lub „::”, które powiedzą PostgreSQL, aby akceptował połączenie z dowolnego adresu IP.
Zmiana portu, na którym postgresql będzie nasłuchiwał (domyślnie 5432), jest również opcją. Możesz to zrobić, modyfikując wartość parametru portu.
Należy pamiętać o parametrach takich jak work_mem, maintenance_work_mem, temp_buffer , max_prepared_transactions, temp_file_limit w przypadku ataku typu „odmowa usługi”. Są to parametry instrukcji/sesji, które można ustawić na różnych poziomach (db, użytkownik, sesja), więc mądre zarządzanie nimi może pomóc nam zminimalizować wpływ ataku.
3. Zarządzanie użytkownikami i rolami
Złotą zasadą bezpieczeństwa dotyczącą zarządzania użytkownikami jest przyznanie użytkownikom minimalnej ilości dostępu, jakiej potrzebują.
Zarządzanie tym nie zawsze jest łatwe i może stać się naprawdę bałaganiarskie, jeśli nie zostanie wykonane dobrze od samego początku.
Dobrym sposobem na kontrolowanie uprawnień jest użycie roli, grupy, strategii użytkownika.
W postgresql wszystko jest traktowane jako rola, ale zamierzamy wprowadzić w tym pewne zmiany.
W tej strategii utworzysz trzy różne typy lub role:
- rola (identyfikowana przez prefiks r_)
- rola w grupie (oznaczona prefiksem g_)
- rola użytkownika (zazwyczaj nazwy osobiste lub nazwy aplikacji)
Role (r_ roles) będą tymi, które mają uprawnienia do obiektów. Rolom grupowym ( g_ roles ) zostaną nadane r_ role , więc będą one zbiorem r_ roles. I na koniec, role użytkowników otrzymają jedną lub więcej ról grupowych i będą tymi z uprawnieniami logowania.
Pokażmy tego przykład. Stworzymy grupę tylko do odczytu dla przykładu schematu, a następnie przydzielimy ją użytkownikowi:
Tworzymy rolę tylko do odczytu i przyznajemy jej uprawnienia do obiektu
CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT USAGE ON SCHEMA example to r_example_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;Tworzymy grupę tylko do odczytu i przydzielamy rolę tej grupie
CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';
GRANT r_example_ro to g_example_ro;Tworzymy rolę app_user i „dołączamy” do grupy tylko do odczytu
CREATE ROLE app_user WITH LOGIN ;
ALTER ROLE app_user WITH PASSWORD 'somePassword' ;
ALTER ROLE app_user VALID UNTIL 'infinity' ;
GRANT g_example_ro TO app_user;Korzystając z tej metody możesz zarządzać szczegółowością uprawnień oraz łatwo przyznawać i odbierać grupy dostępu użytkownikom. Pamiętaj, aby nadawać uprawnienia do obiektów tylko do ról, zamiast robić to bezpośrednio dla użytkowników i przyznawać uprawnienia do logowania tylko użytkownikom.
Dobrą praktyką jest jawne odbieranie publicznych uprawnień do obiektów, na przykład odbieranie publicznego dostępu do określonej bazy danych i przyznawanie go tylko poprzez rolę.
REVOKE CONNECT ON my_database FROM PUBLIC;
GRANT CONNECT ON my_database TO r_example_ro;Ogranicz dostęp SUPERUSER, zezwalaj na połączenia superuser tylko z domeny localhost/unix.
Używaj określonych użytkowników do różnych celów, na przykład określonych użytkowników aplikacji lub użytkowników kopii zapasowych, i ogranicz połączenia dla tego użytkownika tylko z wymaganych adresów IP.
4. Zarządzanie superużytkownikami
Utrzymanie silnej polityki haseł jest koniecznością, aby zapewnić bezpieczeństwo baz danych i uniknąć włamań do haseł. Aby zapewnić silną politykę, używaj preferencyjnie znaków specjalnych, cyfr, wielkich i małych liter i zawieraj co najmniej 10 znaków.
Istnieją również zewnętrzne narzędzia uwierzytelniające, takie jak LDAP lub PAM, które mogą pomóc w zapewnieniu zasad wygasania i ponownego użycia haseł, a także w obsłudze blokowania konta w przypadku błędów uwierzytelniania.
5. Szyfrowanie danych (przy połączeniu SSL)
PostgreSQL ma natywną obsługę połączeń SSL do szyfrowania komunikacji klient/serwer w celu zwiększenia bezpieczeństwa. SSL (Secure Sockets Layer) to standardowa technologia bezpieczeństwa służąca do ustanawiania zaszyfrowanego łącza między serwerem internetowym a przeglądarką. Ten link zapewnia, że wszystkie dane przekazywane między serwerem internetowym a przeglądarkami pozostaną prywatne i integralne.
Ponieważ klienci postgresql wysyłają zapytania w postaci zwykłego tekstu, a dane są również wysyłane w postaci niezaszyfrowanej, są one podatne na fałszowanie sieci.
Możesz włączyć SSL, ustawiając parametr ssl na on w postgresql.conf.
Serwer będzie nasłuchiwał połączeń normalnych i SSL na tym samym porcie TCP i będzie negocjował z każdym łączącym się klientem, czy używać SSL. Domyślnie jest to opcja klienta, ale możesz skonfigurować serwer tak, aby wymagał użycia SSL dla niektórych lub wszystkich połączeń za pomocą opisanego powyżej pliku konfiguracyjnego pg_hba.
6. Szyfrowanie danych w spoczynku (pg_crypto)
Istnieją dwa podstawowe rodzaje szyfrowania, jednokierunkowe i dwukierunkowe. W pewnym sensie nigdy nie zależy Ci na odszyfrowaniu danych do postaci czytelnej, ale po prostu chcesz sprawdzić, czy użytkownik wie, jaki jest ukryty tajny tekst. Jest to zwykle używane w przypadku haseł. W szyfrowaniu dwukierunkowym chcesz mieć możliwość szyfrowania danych, a także umożliwić autoryzowanym użytkownikom odszyfrowanie ich do znaczącej formy. Do tej kategorii należą dane takie jak karty kredytowe i numery SSN.
W przypadku szyfrowania jednokierunkowego funkcja crypt zawarta w pgcrypto zapewnia dodatkowy poziom bezpieczeństwa ponad sposób md5. Powodem jest to, że z md5 możesz stwierdzić, kto ma to samo hasło, ponieważ nie ma soli (w kryptografii sól to losowe dane, które są używane jako dodatkowe dane wejściowe do funkcji jednokierunkowej, która „haszuje” dane, hasło lub hasło), więc wszystkie osoby z tym samym hasłem będą miały ten sam zakodowany ciąg md5. Z kryptą będą się różnić.
W przypadku danych, które chcesz pobrać, nie chcesz wiedzieć, czy te dwie informacje są takie same, ale nie znasz tych informacji i chcesz, aby mogli je pobierać tylko autoryzowani użytkownicy. Pgcrypto zapewnia kilka sposobów na osiągnięcie tego, więc aby dowiedzieć się więcej o tym, jak z niego korzystać, możesz sprawdzić oficjalną dokumentację postgresql na https://www.postgresql.org/docs/current/static/pgcrypto.html.
7. Logowanie
Postgresql zapewnia szeroką gamę parametrów konfiguracyjnych do kontrolowania tego, co, kiedy i gdzie należy logować.
Możesz włączyć połączenia/rozłączenia sesji, długotrwałe zapytania, rozmiary plików tymczasowych i tak dalej. Może to pomóc w lepszym poznaniu obciążenia pracą w celu zidentyfikowania dziwnych zachowań. Możesz uzyskać wszystkie opcje logowania pod następującym linkiem https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html
Aby uzyskać bardziej szczegółowe informacje na temat obciążenia, możesz włączyć moduł pg_stat_statements, który umożliwia śledzenie statystyk wykonania wszystkich instrukcji SQL wykonywanych przez serwer. Istnieje kilka narzędzi bezpieczeństwa, które mogą pozyskiwać dane z tej tabeli i wygenerują białą listę sql, aby pomóc Ci zidentyfikować zapytania niezgodne z oczekiwanymi wzorcami.
Aby uzyskać więcej informacji https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.
Pobierz oficjalny dokument już dziś Zarządzanie i automatyzacja PostgreSQL za pomocą ClusterControlDowiedz się, co musisz wiedzieć, aby wdrażać, monitorować, zarządzać i skalować PostgreSQLPobierz oficjalny dokument8. Audyt
Rozszerzenie audytu PostgreSQL (pgAudit) zapewnia szczegółowe rejestrowanie audytu sesji i/lub obiektów za pośrednictwem standardowej funkcji rejestrowania PostgreSQL.
Podstawowe rejestrowanie instrukcji może być zapewnione przez standardowe narzędzie rejestrowania z log_statement =all. Jest to dopuszczalne w przypadku monitorowania i innych zastosowań, ale nie zapewnia poziomu szczegółowości zwykle wymaganego w przypadku audytu. Nie wystarczy mieć listę wszystkich operacji wykonywanych na bazie danych. Musi być również możliwe odnalezienie konkretnych stwierdzeń, które zainteresują biegłego rewidenta. Standardowa funkcja rejestrowania pokazuje, czego zażądał użytkownik, podczas gdy pgAudit skupia się na szczegółach tego, co się stało, gdy baza danych spełniała żądanie.
9. Łatanie
Regularnie i często sprawdzaj stronę z informacjami o zabezpieczeniach PostgreSQL, aby znaleźć krytyczne aktualizacje i poprawki zabezpieczeń.
Pamiętaj, że błędy bezpieczeństwa systemu operacyjnego lub bibliotek mogą również prowadzić do wycieku bazy danych, więc upewnij się, że aktualizujesz je.
ClusterControl dostarcza raport operacyjny, który zawiera te informacje i wykona dla Ciebie poprawki i aktualizacje.
10. Bezpieczeństwo na poziomie rzędu
Oprócz standardowego systemu uprawnień SQL dostępnego w ramach programu GRANT, tabele mogą mieć zasady bezpieczeństwa wierszy, które ograniczają dla każdego użytkownika, które wiersze mogą być zwracane przez zwykłe zapytania lub wstawiane, aktualizowane lub usuwane przez polecenia modyfikacji danych. Ta funkcja jest również znana jako zabezpieczenia na poziomie wiersza.
Gdy zabezpieczenia wierszy są włączone w tabeli, cały normalny dostęp do tabeli w celu wybierania wierszy lub modyfikowania wierszy musi być dozwolony przez zasady zabezpieczeń wierszy.
Oto prosty przykład, jak utworzyć zasady dotyczące relacji konta, aby umożliwić dostęp do wierszy tylko członkom roli menedżera i tylko wierszom ich kont:
CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);Więcej informacji na temat tej funkcji można znaleźć w oficjalnej dokumentacji postgresql https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html
Jeśli chcesz dowiedzieć się więcej, oto kilka zasobów, które mogą pomóc w lepszym wzmocnieniu bezpieczeństwa bazy danych…
- https://www.postgresql.org/docs/9.6/static/auth-pg-hba-conf.html
- https://www.postgresql.org/docs/9.6/static/ssl-tcp.html
- https://www.postgresql.org/docs/current/static/pgcrypto.html
- http://www.postgresonline.com/journal/archives/165-Encrypting-data-with-pgcrypto.html
- https://github.com/pgaudit/pgaudit
- https://www.postgresql.org/docs/9.6/static/pgstatstatements.html
Wniosek
Jeśli zastosujesz się do powyższych wskazówek, Twój serwer będzie bezpieczniejszy, ale nie oznacza to, że będzie niezniszczalny.
Dla własnego bezpieczeństwa zalecamy użycie narzędzia do testowania bezpieczeństwa, takiego jak Nessus, aby dowiedzieć się, jakie są Twoje główne luki w zabezpieczeniach i spróbować je rozwiązać.
Możesz również monitorować swoją bazę danych za pomocą ClusterControl. Dzięki temu możesz zobaczyć w czasie rzeczywistym, co dzieje się w Twojej bazie danych i je przeanalizować.
