Role grupowe - jak zarządzać uprawnieniami zbiorczo

PostgreSQL

Role grupowe - jak zarządzać uprawnieniami zbiorczo

W skrócie

Kiedy w bazie masz trzy konta, ręczne nadawanie uprawnień jeszcze uchodzi. Przy piętnastu robi się z tego koszmar: nowy analityk dołącza do zespołu, a Ty klikasz przez trzydzieści tabel, żeby nadać mu SELECT. Ktoś odchodzi i nie wiadomo, do czego naprawdę miał dostęp. Rozwiązaniem są role grupowe, które w PostgreSQL działają wyjątkowo elegancko, bo baza w ogóle nie oddziela pojęcia użytkownika od grupy.

Jak to wygląda w praktyce

Objaw jest zawsze podobny. Masz zespół, który powinien mieć te same uprawnienia - na przykład wszyscy analitycy czytają dane z kilkunastu tabel raportowych. Nadajesz je pierwszej osobie: GRANT SELECT ON tabela1 TO anna, potem to samo dla kolejnych tabel, potem to samo dla Bartka, Celiny i reszty. Dochodzi nowa tabela raportowa - trzeba obejść wszystkie konta z osobna. Ktoś zmienia dział - nie masz jak jednym ruchem odebrać mu całego pakietu dostępu, bo ten pakiet nigdzie nie istnieje jako całość, jest rozsypany po kontach. Efekt to rosnąca liczba GRANT-ów, których nikt już nie ogarnia, i realne ryzyko, że po odejściu pracownika zostawisz mu żywy dostęp do produkcji.

Dlaczego tak się dzieje

W PostgreSQL nie ma osobnego bytu "grupa". Od wersji 8.1 wszystko jest rolą. Rola, która ma atrybut LOGIN, zachowuje się jak zwykły użytkownik i może się połączyć z bazą. Rola bez LOGIN nie zaloguje się nigdzie, ale nadal może posiadać uprawnienia - i właśnie taką rolę traktujemy jako grupę. Kluczowa cecha jest taka, że role da się zagnieżdżać: jedna rola może być członkiem drugiej. Jeśli rola-użytkownik jest członkiem roli-grupy, to dziedziczy jej uprawnienia. Skoro więc nadawaliśmy uprawnienia bezpośrednio kontom ludzi, sami pozbawialiśmy się warstwy pośredniej, która trzyma wszystko w jednym miejscu. Uprawnienia powinny wisieć na grupie, a nie na konkretnej osobie.

Jak to rozwiązać krok po kroku

1. Utwórz rolę grupową, która nie loguje się do bazy: CREATE ROLE analitycy NOLOGIN;. To będzie nasz worek na uprawnienia.
2. Nadaj uprawnienia grupie, a nie ludziom. Dla całego schematu naraz: GRANT USAGE ON SCHEMA raporty TO analitycy; oraz GRANT SELECT ON ALL TABLES IN SCHEMA raporty TO analitycy;.
3. Dodaj konta ludzi jako członków grupy: GRANT analitycy TO anna; i tak samo dla pozostałych. Od tej chwili każdy członek widzi to, co widzi grupa.
4. Upewnij się, że dziedziczenie działa automatycznie. Konto założone jako CREATE ROLE anna LOGIN INHERIT; od razu korzysta z uprawnień grupy. Atrybut INHERIT jest domyślny, ale warto o nim wiedzieć - przy NOINHERIT trzeba by ręcznie robić SET ROLE.
5. Gdy dochodzi nowa tabela w schemacie, nadaj do niej dostęp raz - grupie: GRANT SELECT ON raporty.nowa_tabela TO analitycy;. Wszyscy członkowie dostają go natychmiast.
6. Gdy ktoś odchodzi z zespołu, odbierasz członkostwo jednym poleceniem: REVOKE analitycy FROM anna;. Cały pakiet dostępu znika z tego konta od razu.

Jak sprawdzić, że zadziałało

Najszybciej w psql poleceniem \du - w kolumnie "Member of" zobaczysz, do jakich grup należy każde konto. Pełną listę powiązań daje też zapytanie do widoku systemowego: sprawdź pg_roles i tabelę członkostw pg_auth_members. Aby zweryfikować realny efekt, zaloguj się jako testowe konto należące do grupy i wykonaj SELECT na tabeli, do której dostęp ma tylko grupa - jeśli zapytanie przechodzi, dziedziczenie działa. Po odebraniu członkostwa to samo zapytanie powinno zwrócić błąd o braku uprawnień.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5