Konfigurowanie uprawnień za pomocą GRANT i REVOKE

Wyobraź sobie, że twoje dane to twierdza, a każdy mieszkaniec tej twierdzy ma swoje prawa: ktoś może tylko chodzić po dziedzińcu, ktoś trzyma klucze do skarbca, a ktoś siedzi w sali tronowej i wszystkim zarządza. W naszej bazie danych tę rolę pełnią polecenia GRANT i REVOKE. To właśnie one decydują, kto, gdzie i po co może wejść.

Polecenie GRANT, jak każdy normalny grant, pozwala przyznawać dostęp do zasobów (np. baz danych, tabel, schematów) określonym rolom. To trochę jak "zaproszenie na imprezę", gdzie decydujesz, kto może czytać, pisać albo rozwalać meble.

Polecenie REVOKE robi odwrotnie – odbiera wcześniej nadane prawa. To jak powiedzieć: "Hej, impreza dla ciebie się skończyła, zostaw klucze przy wyjściu".

Przyznawanie uprawnień za pomocą GRANT

Zacznijmy od najwyższego poziomu — bazy danych. Żeby użytkownik mógł się połączyć z bazą, trzeba mu przyznać prawo do połączenia. Do tego służy polecenie:

GRANT CONNECT ON DATABASE database_name TO role_name;

Na przykład, jeśli mamy bazę university i rolę student, możemy pozwolić studentom się łączyć za pomocą takiego zapytania:

GRANT CONNECT ON DATABASE university TO student;

Ale samo połączenie to jeszcze nie wszystko. Żeby użytkownik mógł tworzyć obiekty w bazie, potrzebuje jeszcze prawa do tworzenia:

GRANT CREATE ON DATABASE university TO student;

Uprawnienia do bazy można sprawdzić poleceniem:

\l+ university

Odbieranie uprawnień za pomocą REVOKE

Jeśli student zacznie się dziwnie zachowywać (np. próbuje tworzyć więcej tabel niż się spodziewaliśmy), możemy odebrać mu prawo do tworzenia poleceniem:

REVOKE CREATE ON DATABASE university FROM student;

Po tym student będzie mógł się tylko łączyć, ale już żadnych "twórczych szaleństw" nie zrobi.

Konfigurowanie uprawnień na poziomie schematów

Schemat to w zasadzie "pokój" w naszej bazie, gdzie trzymane są tabele, widoki i inne obiekty. Żeby użytkownik mógł pracować z obiektami w schemacie, można ustawić prawa do czytania, pisania albo tworzenia obiektów.

Przyznawanie uprawnień do schematu

Załóżmy, że mamy schemat public (tworzony domyślnie w każdej bazie). Możemy pozwolić użytkownikowi przeglądać zawartość schematu:

GRANT USAGE ON SCHEMA public TO student;

Ale samo USAGE nie wystarczy do pracy z tabelami. Żeby użytkownik mógł tworzyć nowe obiekty, dodajemy:

GRANT CREATE ON SCHEMA public TO student;

Dzięki temu student może nie tylko czytać, ale i tworzyć tabele w schemacie public.

Odbieranie uprawnień do schematu

Jeśli student zacznie zaśmiecać schemat dziwnymi tabelami o nazwach typu bad_idea_01, możemy ograniczyć mu prawa:

REVOKE CREATE ON SCHEMA public FROM student;

Teraz student nie doda już nowych tabel. Porządek przywrócony!

Konfigurowanie uprawnień na poziomie tabel

Tabela to chyba najpopularniejszy obiekt w bazie. Zobaczmy, jak ustawić dostęp konkretnie do tabel. Są tu trzy główne kategorie działań: czytanie, pisanie i modyfikacja.

Prawa do czytania

Żeby pozwolić użytkownikowi czytać zawartość tabeli, używamy polecenia:

GRANT SELECT ON TABLE table_name TO role_name;

Na przykład, żeby studenci mogli czytać rekordy z tabeli courses:

GRANT SELECT ON TABLE courses TO student;

Teraz użytkownik student może odpalać zapytania SELECT z tabeli courses.

Prawa do pisania

Jeśli chcesz, żeby użytkownik mógł dodawać nowe wiersze do tabeli, ustaw to tak:

GRANT INSERT ON TABLE table_name TO role_name;

Przykład:

GRANT INSERT ON TABLE courses TO student;

Teraz studenci mogą dodawać nowe kursy do tabeli. Ale chwila... Czy na pewno to dobry pomysł?

Prawa do modyfikacji i usuwania

Jeśli użytkownik ma mieć możliwość aktualizacji istniejących wierszy albo ich usuwania, trzeba przyznać prawa UPDATE i DELETE odpowiednio.

GRANT UPDATE ON TABLE courses TO student;
GRANT DELETE ON TABLE courses TO student;

Tip: nie przesadzaj z tymi prawami. Jeśli dasz studentom dostęp do usuwania danych, mogą przypadkiem (albo specjalnie) wszystko rozwalić.

Przykłady: tworzenie roli z ograniczonymi uprawnieniami

Wyobraź sobie, że tworzymy rolę dla nauczycieli, którzy mają mieć dostęp do czytania danych o studentach i kursach, ale nie mogą usuwać rekordów. Oto jak to zrobić:

1. Tworzymy rolę:

CREATE ROLE teacher;

2. Dajemy prawa do czytania tabel students i courses:

GRANT SELECT ON TABLE students, courses TO teacher;

3. Ograniczamy dostęp do usuwania:

REVOKE DELETE ON TABLE students, courses FROM teacher;

Teraz nasi nauczyciele mają tylko potrzebne prawa i nic więcej.

Jak łączyć GRANT i REVOKE dla elastycznej konfiguracji

Załóżmy, że mamy rolę intern, którą chcemy ograniczyć. Ma mieć dostęp tylko do danych o kursach, ale absolutnie nie do danych studentów. Tak to wygląda:

1. Pozwalamy na dostęp tylko do tabeli courses:

GRANT SELECT, INSERT ON TABLE courses TO intern;

2. Upewniamy się, że rola intern nie ma praw do tabeli students:

REVOKE ALL ON TABLE students FROM intern;

Ta kombinacja pozwala precyzyjnie ustawić dostęp.

Przykłady użycia w prawdziwych projektach

Ten mechanizm zarządzania dostępem jest często używany w realnych projektach. Na przykład:

1. W sklepach internetowych prawa do tabel użytkowników i zamówień są rozdzielone między role "administrator", "operator" i "gość".
2. W systemach uniwersyteckich administratorzy mogą dodawać i zmieniać kursy, a studenci — tylko je przeglądać.
3. W systemach bankowych dostęp do kont klientów jest rozdzielony między pracowników różnych działów.