Zarządzanie dostępem i bezpieczeństwo

Wyobraź sobie koszmar: jesteś adminem bazy danych, a ważna tabela z danymi klientów nagle... znika. Kto to zrobił? Dlaczego? Może to błąd niedoświadczonego stażysty, który przypadkiem napisał DROP TABLE. A może to był złośliwy użytkownik, który miał dostęp do bazy... Cokolwiek to było, na ratunek już za późno! Pozostaje tylko się obudzić, ogarnąć i zacząć ogarniać bezpieczeństwo baz danych. Bo baza bez zabezpieczeń to jak dom bez fundamentów.

Dla baz danych ochrona musi być na najwyższym poziomie, żeby zapobiec takim zagrożeniom jak:

• Nieautoryzowany dostęp: ktoś dostaje się do danych, do których nie powinien mieć dostępu.
• Wycieki danych: hasła, karty kredytowe albo poufne info trafiają w niepowołane ręce.
• SQL-injection: podstępna metoda, która pozwala atakującemu manipulować twoją bazą przez słabo zabezpieczone zapytania.
• Ludzkie błędy: przypadkowe usunięcie danych albo zmiana, której nie da się cofnąć.

W PostgreSQL bezpieczeństwo ogarnia się na kilku poziomach: od tworzenia ról i zarządzania uprawnieniami po ograniczenia dostępu sieciowego. Dzięki temu możesz elastycznie ustawić, kto i co może robić z twoimi danymi.

Główne poziomy bezpieczeństwa w PostgreSQL

W PostgreSQL masz trzy główne poziomy, na których możesz zarządzać dostępem:

1. Zarządzanie dostępem na poziomie bazy danych. Na tym poziomie decydujesz, kto może się łączyć z twoją bazą i co użytkownik może robić po połączeniu. Na przykład możesz niektórym całkiem zabronić wejścia do bazy. Innym — pozwolić tylko na odczyt danych. Kluczowe narzędzie do tego to role.

2. Kontrola dostępu na poziomie tabel, wierszy i kolumn.

W PostgreSQL dostęp do danych możesz ograniczać bardzo precyzyjnie. Możesz:

• Pozwolić użytkownikowi czytać tylko wybrane kolumny.
• Pozwolić czytać dane w tabeli tylko jeśli użytkownik jest właścicielem wiersza. To się nazywa ROW LEVEL SECURITY (RLS) i omówimy to szerzej na kolejnych wykładach.
• Ograniczyć dostęp tylko do wybranych części bazy (schematów), gdzie są ważne dane.

3. Konfiguracja dostępu sieciowego. Baza może być ustawiona tak, żeby przyjmować zapytania tylko od zaufanych klientów. To się ustawia w pliku konfiguracyjnym PostgreSQL o nazwie pg_hba.conf. Dzięki temu plikowi możesz np. pozwolić na połączenie tylko z lokalnej maszyny albo wybranych adresów IP.

Narzędzia bezpieczeństwa PostgreSQL

Sprawdźmy, jakie narzędzia bezpieczeństwa daje PostgreSQL i jak to działa w praktyce.

Zaczynamy od ról i uprawnień — to podstawa systemu zarządzania dostępem. W PostgreSQL rola to nie tylko użytkownik, ale coś bardziej elastycznego. Może reprezentować jedną osobę albo całą grupę. Na przykład możesz stworzyć rolę manager, która ma pełny dostęp do tabeli zamówień, a dla stażysty rolę intern, która ma tylko prawa do odczytu — żeby przypadkiem nic nie popsuł.

Same role możesz ustawiać bardzo elastycznie: komuś dać więcej praw, komuś mniej, a nawet pozwolić jednej roli dziedziczyć prawa innej. Przez role decydujesz, kto może się łączyć z bazą, jakie schematy i tabele są dostępne, a nawet które wiersze można zobaczyć lub zmienić.

Dalej są pliki konfiguracyjne. W PostgreSQL są dwa kluczowe pliki konfiguracyjne, które mają duże znaczenie dla bezpieczeństwa.

Pierwszy to pg_hba.conf. On odpowiada za dostęp sieciowy do bazy. Właśnie tutaj ustawiasz, kto w ogóle może się łączyć z serwerem, z jakiego IP i jak będzie wyglądać uwierzytelnianie. Jeśli chcesz ograniczyć dostęp tylko dla wybranych maszyn lub użytkowników — robisz to właśnie tutaj.

Drugi plik to postgresql.conf. On zarządza ogólnymi ustawieniami serwera, a między innymi ustawia parametry logowania i audytu. Dzięki temu możesz śledzić, kto co robi, szybko zauważyć podejrzaną aktywność i w razie czego przeanalizować szczegóły.

Na koniec logowanie i audyt. "Logi to twój najlepszy kumpel". Brzmi dziwnie, ale dla admina bazy to zasada numer jeden. W PostgreSQL możesz ustawić logowanie wszystkich zapytań i działań użytkowników. To pomoże ogarnąć, kto co zrobił z bazą, jeśli coś pójdzie nie tak.

Przykład: ochrona danych przed SQL-injection

SQL-injection to jeden z najpopularniejszych sposobów ataku na bazę. I naprawdę trzeba umieć się przed tym bronić. Wyobraź sobie, że masz apkę, gdzie użytkownik wpisuje ID swojego konta, żeby zobaczyć profil. I apka robi takie zapytanie:

SELECT * FROM users WHERE id = 123;

A co jeśli użytkownik wpisze 123 OR 1=1 zamiast liczby? Wtedy zapytanie zamieni się w coś takiego:

SELECT * FROM users WHERE id = 123 OR 1=1;

I zamiast jednego rekordu cała tabela users będzie dostępna.

Jak się bronić? PostgreSQL pozwala używać parametryzowanych zapytań albo przygotowanych komend (PREPARE i EXECUTE), żeby dane od użytkownika nigdy nie mieszały się z kodem SQL. Tak to wygląda:

PREPARE get_user_by_id (int) AS
SELECT * FROM users WHERE id = $1;

EXECUTE get_user_by_id(123);

Kolejne przykłady realnych zagrożeń

Żebyś dobrze zrozumiał, po co to wszystko, podam dwa realne scenariusze:

Przykład 1: "Pracownik usunął całą tabelę"

Kiedyś w jednej firmie (a tak naprawdę, to nie raz i nie w jednej...) stażysta przypadkiem wpisał w konsoli komendę:

DROP TABLE employees;

I 10 lat danych o pracownikach przepadło bezpowrotnie. Jak tego uniknąć?

• Zarządzaj uprawnieniami! Na przykład roli intern pozwól tylko na odczyt.
• Ustaw audyt! Logi pokażą, kto odpalił tę fatalną komendę.

Przykład 2: "Wycieki danych przez niezaszyfrowane połączenie"

Jeśli użytkownik łączy się z serwerem PostgreSQL bez szyfrowania, jego login i hasło mogą zostać przechwycone przez atakującego. Skonfiguruj SSL i upewnij się, że połączenia są zabezpieczone.

Kluczowe zadania dla administratorów

Na koniec tego wstępu wyróżnijmy trzy najważniejsze zadania każdego admina PostgreSQL:

• Rozdzielanie dostępu. Upewnij się, że tylko uprawnieni użytkownicy mogą wykonywać określone akcje.
• Szyfrowanie. Poufne dane zawsze powinny być przechowywane i przesyłane w formie zaszyfrowanej.
• Monitoring. Ustaw audyt i obserwuj podejrzaną aktywność w logach.

Na kolejnych wykładach dowiesz się, jak tworzyć role, zarządzać dostępem przez GRANT i REVOKE, wdrażać kontrolę dostępu na poziomie wierszy i używać szyfrowania do ochrony danych.