Wprowadzenie
PostgreSQL wykorzystuje różne mechanizmy do implementacji uwierzytelniania, autoryzacji i własności obiektów w klastrach baz danych. Kluczem do nich jest koncepcja ról.
Role PostgreSQL to połączenie pomysłów użytkowników i grup w jedną, elastyczną całość. Są to persony, które użytkownik przyjmuje w systemie bazy danych, są podmiotami, przez które system uwierzytelniania akceptuje lub odmawia połączeń oraz przedmiotem zasad zarządzania uprawnieniami we wszystkich zakresach.
W tym przewodniku dowiesz się, jakie są role i jak nimi zarządzać w klastrze baz danych PostgreSQL. Dokładniej, ten przewodnik omówi zarządzanie rolami w odniesieniu do atrybutów ról. Aby uzyskać szerszy przegląd tego, jak role pasują do szerszego obrazu, zapoznaj się ze wstępem do przewodnika po uwierzytelnianiu i autoryzacji. Aby dowiedzieć się, jak zmienić uprawnienia ról w określonych obiektach bazy danych, zapoznaj się z naszym przewodnikiem na temat przyznawania ról.
Co to są role?
W PostgreSQL rola to grupowanie określonego zestawu możliwości, uprawnień i "posiadanych" encji. Zamiast mieć odrębne koncepcje „użytkowników” i „grup”, PostgreSQL używa ról do reprezentowania obu tych idei. Rola może odpowiadać pojedynczej osobie w świecie rzeczywistym lub może działać jako grupa z pewnym dostępem, którego inne role mogą stać się członkami.
Role są punktem zakotwiczenia w PostgreSQL, który określa, do kogo mają zastosowanie zasady uwierzytelniania i autoryzacji. Każda polityka, która nie ma uniwersalnego zastosowania, wymaga pojęcia tożsamości, aby określić, kogo ograniczać, a komu zezwolić. W PostgreSQL ta tożsamość jest reprezentowana przez role.
System uwierzytelniania PostgreSQL składa się z wielu różnych komponentów, z których każdy jest powiązany z rolami. Aby mogły zostać użyte do początkowego połączenia z klastrem bazy danych, role muszą najpierw mieć LOGIN zestaw atrybutów. Same reguły uwierzytelniania są zdefiniowane w pliku konfiguracyjnym hosta o nazwie pg_hba.conf . Każda reguła definiuje metody uwierzytelniania, które mogą być przypisane do indywidualnej roli. W przypadku ról skonfigurowanych do uwierzytelniania hasłem musi mieć ustawiony atrybut hasła, aby system mógł zweryfikować podane hasło użytkownika.
W zakresie autoryzacji role definiowane są na poziomie klastra bazy danych, co w PostgreSQL oznacza, że są one współdzielone pomiędzy bazami danych. Ponieważ role obejmują bazy danych, system uprawnień kontroluje poziom dostępu każdej roli do każdej jednostki bazy danych. Ponieważ role mogą reprezentować grupy ludzi, istnieje duża elastyczność w konfigurowaniu dostępu.
Role są również istotne dla koncepcji własności obiektów w PostgreSQL. Na przykład każda baza danych i tabela ma dokładnie jedną rolę skonfigurowaną jako właściciel. Inne niż superusers , rola właściciela jest jedyną rolą, która może modyfikować lub usuwać rzeczywisty obiekt.
Podsumowując, role są podstawą większości praktycznych operacji na bazach danych. Ich elastyczność pozwala im działać zarówno jako identyfikatory użytkowników, jak i klasy użytkowników. Każde działanie w klastrze bazy danych jest sprawdzane pod kątem uprawnień roli, a powodzenie każdego połączenia z klastrem bazy danych jest określane na podstawie roli, w której dokonuje się uwierzytelnienia. Ważne jest, aby dobrze opanować zarządzanie rolami ze względu na jego znaczenie w tak wielu podstawowych operacjach.
Atrybuty ról
Atrybuty ról to flagi samej roli, które określają niektóre z podstawowych uprawnień, jakie ma ona na poziomie klastra bazy danych. Można je ustawić podczas początkowego tworzenia roli lub zmienić w dowolnym momencie przez dowolną rolę z odpowiednimi atrybutami (SUPERUSER lub CREATEROLE w tym przypadku).
Atrybuty, które można zastosować do roli, obejmują:
LOGIN:umożliwia użytkownikom wstępne łączenie się z klastrem bazy danych przy użyciu tej roli.CREATE USERpolecenie automatycznie dodaje ten atrybut, podczas gdyCREATE ROLEpolecenie nie.SUPERUSER:Pozwala roli na pominięcie wszystkich kontroli uprawnień z wyjątkiem prawa do logowania. Tylko inneSUPERUSERrole mogą tworzyć role z tym atrybutem.CREATEDB:Pozwala roli na tworzenie nowych baz danych.CREATEROLE:Umożliwia roli tworzenie, zmienianie i usuwanie innych ról. Ten atrybut umożliwia również roli przypisanie lub zmianę członkostwa w roli. Wyjątkiem jest rola zCREATEROLEatrybut nie może zmienićSUPERUSERrole bez posiadaniaSUPERUSERatrybut.REPLICATION:Umożliwia roli inicjowanie replikacji strumieniowej. Role z tym atrybutem muszą mieć równieżLOGINatrybut.PASSWORD:Przypisuje hasło do roli, które będzie używane zpasswordlubmd5mechanizmy uwierzytelniania. Ten atrybut przyjmuje hasło w cudzysłowie jako argument bezpośrednio po słowie kluczowym atrybutu.INHERIT:Określa, czy rola dziedziczy uprawnienia ról, których jest członkiem. BezINHERIT, członkowie muszą używaćSET ROLEzmienić się w inną rolę, aby uzyskać dostęp do tych wyłącznych przywilejów. Ten atrybut jest domyślnie ustawiony dla nowych ról.
Możesz dowiedzieć się więcej o atrybutach ról, sprawdzając dokumentację PostgreSQL na temat atrybutów ról i CREATE ROLE polecenie.
Co to jest superuser rola?
Jak wspomniano pokrótce powyżej, specjalny przywilej o nazwie superuser umożliwia nieograniczony dostęp administracyjny do klastra bazy danych. Jest to podobne do root konto w systemach operacyjnych Linux i uniksopodobnych, ale na poziomie bazy danych.
Zawsze musi istnieć co najmniej jedna rola z superuser uprawnienia w każdym klastrze bazy danych. Początkowy superuser konto jest tworzone podczas procesu instalacji. Nazwa początkowego superuser konto może się różnić w zależności od procesu instalacji, ale najczęściej to konto nazywa się postgres .
Nie zaleca się wykonywania codziennej pracy przy użyciu konta z superuser przywilejów, zarówno ze względu na jego potencjał do działań destrukcyjnych, jak i zminimalizowanie szansy na skompromitowanie konta o szerokim dostępie. Zamiast tego, przez większość czasu użytkownicy powinni używać kont dedykowanych konkretnym funkcjom lub obiektom danych, z którymi pracują, używając tylko superuser konta, gdy wymagany jest bardziej zaawansowany dostęp.
Sprawdzanie istniejących atrybutów ról
Teraz, gdy masz już ogólne pojęcie o tym, czym są atrybuty ról i jakie typy uprawnień umożliwiają, powinieneś dowiedzieć się, jak znaleźć atrybuty zastosowane do ról w PostgreSQL. Ta sekcja pokaże Ci kilka poleceń, które pomogą Ci znaleźć atrybuty ustawione w rolach ogólnie, a konkretnie w Twojej aktualnej roli.
Lista wszystkich ról bazy danych i ich atrybutów
Istnieje kilka różnych sposobów sprawdzania atrybutów zastosowanych do ról w całym systemie.
Jeśli używasz psql klienta wiersza poleceń, możesz skorzystać z kilku pomocnych metapoleceń, które pozwalają uzyskać informacje o atrybutach roli bez zapytania.
\du meta-polecenie pokazuje wszystkie role i ich atrybuty:
\du
List of roles Role name | Attributes | Member of-----------+------------------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
W tym przypadku postgres role jest domyślną rolą z superuser uprawnienia skonfigurowane dla tego klastra bazy danych.
Równoważny kod SQL do listy ról (możliwy do wykrycia przez przekazanie -E lub --echo-hidden flaga podczas uruchamiania psql ) to:
SELECT r.rolname, r.rolsuper, r.rolinherit, r.rolcreaterole, r.rolcreatedb, r.rolcanlogin, r.rolconnlimit, r.rolvaliduntil, ARRAY(SELECT b.rolname FROM pg_catalog.pg_auth_members m JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid) WHERE m.member = r.oid) as memberof, r.rolreplication, r.rolbypassrlsFROM pg_catalog.pg_roles rWHERE r.rolname !~ '^pg_'ORDER BY 1;
Podobne zapytanie, które dostarcza informacje o atrybutach roli (bez komponentu przynależności do roli) znajduje się poniżej. Używamy psql meta-polecenie \x on aby wyświetlić wyniki w pionie dla lepszej czytelności tutaj:
-- turn on vertical display\x onSELECT * FROM pg_roles WHERE rolname !~ '^pg_';-- turn off vertical display\x off
-[ RECORD 1 ]--+---------rolname | postgresrolsuper | trolinherit | trolcreaterole | trolcreatedb | trolcanlogin | trolreplication | trolconnlimit | -1rolpassword | ********rolvaliduntil | rolbypassrls | trolconfig | oid | 10
Jeśli interesuje Cię tylko sprawdzenie, które role mają superuser atrybut, możesz wyraźnie poprosić o listę:
SELECT rolname FROM pg_roles WHERE rolsuper;
rolname---------- postgres(1 row)
Alternatywnie możesz wyświetlić listę wszystkich użytkowników i ich superuser status, aby uzyskać pełniejszy obraz:
SELECT usename,usesuper FROM pg_user;
usename | usesuper----------+---------- postgres | t user1 | f(2 rows)
Te same informacje można uzyskać za pomocą paradygmatu „role” PostgreSQL zamiast jego (czasem niejednoznacznej) nakładki „użytkownik” za pomocą tego nieco dłuższego zapytania:
SELECT rolname,rolsuper FROM pg_roles WHERE rolname !~ '^pg_';
rolname | rolsuper----------+---------- postgres | t user1 | f(2 rows)
Lista własnych atrybutów
Jeśli chcesz znaleźć atrybuty roli, której aktualnie używasz, możesz łatwo przefiltrować dane wyjściowe.
Podczas korzystania z psql meta-polecenia, możesz użyć USER zmienna, która zostanie zastąpiona aktualną powiązaną rolą. psql używa dwukropka (: ) do interpolacji zmiennych:
\du :USER
List of roles Role name | Attributes | Member of-----------+------------------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
Aby uzyskać listę pokazującą wartości wszystkich możliwych atrybutów ról, możesz użyć zapytania porównującego nazwę roli z wartością zwracaną przez CURRENT_ROLE Funkcja PostgreSQL. Ponownie używamy danych wyjściowych w pionie, aby zapewnić czytelność:
-- First, turn on vertical output\x onSELECT * FROM pg_roles WHERE rolename = CURRENT_ROLE;-- Change back to normal output\x off
-[ RECORD 1 ]--+---------rolname | postgresrolsuper | trolinherit | trolcreaterole | trolcreatedb | trolcanlogin | trolreplication | trolconnlimit | -1rolpassword | ********rolvaliduntil |rolbypassrls | trolconfig |oid | 10
Aby po prostu sprawdzić, czy Twoja obecna rola ma superuser uprawnienia, możesz wpisać:
SHOW is_superuser;
is_superuser-------------- on(1 row)
Sprawdź, czy masz uprawnienia do zarządzania rolami
Aby tworzyć, zmieniać lub usuwać role, musisz mieć superuser lub CREATEROLE przywileje.
Aby sprawdzić, które role w systemie mają uprawnienia do zarządzania rolami, wpisz:
SELECT rolname as "Users who can manage roles" FROM pg_roles WHERE rolsuper OR rolcreaterole;
Users who can manage roles---------------------------- postgres(1 rows)
Jeśli chcesz tylko wiedzieć, czy Twoja obecna rola ma uprawnienia do zarządzania rolami, możesz zamiast tego użyć:
SELECT 'Yes' AS "Can I manage roles?" FROM pg_roles WHERE rolname = :'USER' AND (rolsuper OR rolcreaterole);
Can I manage roles?--------------------- Yes(1 row)
Tworzenie ról
Po sprawdzeniu, czy masz uprawnienia do zarządzania rolami, możesz zacząć tworzyć, modyfikować lub usuwać role w PostgreSQL.
Jedną z opcji ustawienia atrybutów ról jest zadeklarowanie ich w momencie tworzenia roli. Pozwala to ustawić początkowe warunki dla roli, ale nadal możesz je później modyfikować, jeśli chcesz zmienić poziom dostępu roli. Możesz znaleźć więcej informacji na temat CREATE ROLE polecenie, którego użyjemy, aby zapoznać się z podstawową składnią.
Jednym ze sposobów tworzenia roli jest korzystanie z wiersza poleceń. PostgreSQL zawiera createuser polecenie, które utworzy rolę w klastrze bazy danych z LOGIN przywileje.
Ogólna składnia to:
createuser <options> <rolename>
Na przykład, aby utworzyć rolę o nazwie admin z superuser uprawnienia podczas pytania o hasło, możesz wpisać:
createuser --superuser admin
Będziesz wtedy mógł zalogować się za pomocą admin konto zgodnie z metodami uwierzytelniania opisanymi w pg_hba.conf plik.
Tworzenie ról przy użyciu SQL , ogólna składnia wygląda tak:
CREATE ROLE <role>;
Atrybuty można zdefiniować, określając je po nazwie roli za pomocą WITH :
CREATE ROLE <role> WITH <options>;
Na przykład, aby utworzyć rolę o nazwie user1 które mogą logować się za pomocą hasła secretpassword , możesz wpisać:
CREATE ROLE "user1" WITH LOGIN PASSWORD 'secretpassword';
Aby zamiast tego utworzyć rolę z superuser uprawnienia (musisz być także superuser aby pomyślnie wykonać to polecenie), czego nie można zaloguj się (użytkownik musi użyć SET ROLE aby zmienić tę rolę), możesz wpisać:
CREATE ROLE "user2" WITH SUPERUSER;
Zmiana istniejących ról
Aby zmodyfikować atrybuty istniejących ról, możesz użyć ALTER ROLE zamiast tego polecenie. Podobnie jak w przypadku tworzenia ról, twoja aktualna rola również musi mieć superuser lub CREATEROLE przywileje. Użytkownicy, którzy nie mają tych uprawnień, mogą używać tylko ALTER ROLE polecenie, aby zmienić własne hasło.
Zmiana ról umożliwia zmianę atrybutów przypisanych do roli po utworzeniu. Te same atrybuty wymienione w sekcji tworzenia ról mogą być używane z ALTER ROLE składnia. Jedna różnica polega na tym, że każdy typ atrybutu można zanegować, dodając NO prefiks. Na przykład, aby zezwolić roli na logowanie do klastra bazy danych, możesz nadać jej LOGIN atrybut. Aby usunąć tę zdolność, zmień rolę, określając NOLOGIN .
ALTER ROLE tylko polecenie zmienia atrybuty, które są wyraźnie wymienione. Innymi słowy, ALTER ROLE polecenie określa zmiany do atrybutów, a nie pełnego zestawu nowych atrybutów.
Aby zezwolić user2 rola logowania do klastra bazy danych, możesz wpisać:
ALTER ROLE "user2" WITH LOGIN;
Należy pamiętać, że chociaż umożliwia to zalogowanie się, dozwolone metody uwierzytelniania są nadal kontrolowane przez pg_hba.conf plik.
Jeśli chcesz user2 aby móc się logować, tworzyć role i zamiast tego tworzyć bazy danych, możesz określić te trzy atrybuty, oddzielone spacjami:
ALTER ROLE "user2" WITH LOGIN CREATEROLE CREATEDB;
Aby odwołać superuser status z roli (możesz wykonać to polecenie tylko przy użyciu innego superuser rola), wpisz:
ALTER ROLE "user2" WITH NOSUPERUSER;
Aby zmienić hasło do roli, możesz wpisać następujące polecenie (wszystkie role powinny być w stanie wykonać to polecenie we własnej roli, niezależnie od CREATEROLE lub superuser przywileje):
ALTER ROLE <role> WITH PASSWORD '<password>';
Chociaż powyższe polecenie działa, jeśli to możliwe, lepszym pomysłem jest użycie psql meta-polecenie do zmiany haseł. psql polecenie automatycznie pyta o hasło i szyfruje je przed wysłaniem na serwer. Pomaga to uniknąć wycieku poufnych danych w logach.
Możesz zmienić hasło roli za pomocą psql wpisując następujące
-- To change your own password\password-- To change the password for another role\password <role>
Możesz także użyć ALTER ROLE polecenie do zmiany nazwy roli:
ALTER ROLE <role> RENAME TO <newrole>
Pamiętaj, że nie możesz zmienić nazwy swojej obecnej roli w sesji.
Usuwanie ról
Usuwanie istniejącej roli przebiega według podobnego wzorca, jak w przypadku poprzednich poleceń. Ponownie, musisz mieć CREATEROLE lub superuser uprawnienia do wykonywania tych poleceń.
Jednym z czynników komplikujących jest to, że role nie mogą zostać usunięte, jeśli nadal odwołują się do nich obiekty w bazie danych. Oznacza to, że musisz usunąć lub przenieść własność wszystkich obiektów należących do roli. Następnie musisz także cofnąć wszelkie dodatkowe uprawnienia, jakie rola ma do obiektów bazy danych.
Szczegółowe wyjaśnienie, w jaki sposób odpowiednio ponownie przypisać i usunąć uprawnienia, jest dostarczane przez Erwina Brandstettera na stronie Database Administrators Stack Exchange. Ten sam proces jest używany poniżej.
Po pierwsze, możesz ponownie przypisać wszystkie obiekty należące do roli za pomocą REASSIGNED OWNED Komenda. Na przykład, jeśli przygotowujesz się do usunięcia user2 rolę, możesz przypisać jej obiekty do postgres rola wpisując:
REASSIGN OWNED BY "user2" TO "postgres";
Teraz obiekty są własnością postgres , możemy użyć DROP OWNED polecenie, aby odebrać wszystkie inne uprawnienia, które zostały nam nadane do obiektów. To polecenie usuwa również wszystkie obiekty, które posiadamy, ale ponieważ właśnie przenieśliśmy je do postgres rola, user2 rola nie ma już żadnych posiadanych obiektów. Z tego powodu polecenie odbierze tylko dodatkowe uprawnienia roli:
DROP OWNED BY "user2";
Bez DROP OWNED skrót powyżej, musisz wykonać REVOKE ALL PRIVILEGES na każdym pojedynczym obiekcie lub typie obiektu, do którego rola ma uprawnienia.
Po cofnięciu wszystkich powiązanych uprawnień możesz usunąć rolę, wpisując:
DROP ROLE "user2";
Logowanie za pomocą psql
Po skonfigurowaniu nowej roli i skonfigurowaniu szczegółów uwierzytelniania za pomocą pg_hba.conf pliku, możesz zalogować się do klastra bazy danych przy użyciu nowej roli. psql Klient wiersza poleceń zapewnia łatwy sposób na zrobienie tego.
Domyślnie psql zakłada, że chcesz połączyć się przy użyciu roli, która odpowiada nazwie użytkownika systemu operacyjnego. Więc jeśli jesteś zalogowany na swoim komputerze jako john , psql przyjmie, że chcesz spróbować połączyć się z bazą danych przy użyciu roli, która nazywa się również john .
Aby zmienić to zachowanie, możesz przekazać -U lub --username= opcja. Na przykład, jeśli chcesz zalogować się do roli o nazwie kerry , możesz wpisać:
psql -U kerry
Sukces psql polecenie będzie zależeć od istnienia kerry rolę, dostępność serwera, z którym próbujesz się połączyć, oraz reguły uwierzytelniania zdefiniowane na serwerze.
Zmiana na inną rolę podczas sesji
Czasami możesz chcieć tymczasowo przyjąć uprawnienia i tożsamość innej roli, do której masz dostęp. Na przykład jest to konieczne, jeśli chcesz uzyskać uprawnienia roli, której jesteś członkiem, jeśli twoja bieżąca rola nie ma INHERIT atrybut.
Aby zrozumieć, jak to działa, musisz znać terminologię używaną przez PostgreSQL do kategoryzowania aktywnych ról:
- Rola sesji :Rola sesji to rola, w której zalogowałeś się podczas początkowego połączenia z klastrem bazy danych PostgreSQL. Ustawia twoje początkowe uprawnienia i określa twój dostęp do systemu. Ta rola musi mieć
LOGINatrybut. - Obecna rola :Dla kontrastu, obecna rola to rola, w której aktualnie się pełnisz. Uprawnienia związane z bieżącą rolą, niezależnie od tego, czy są ustawione bezpośrednio, czy odziedziczone z innych ról, określają akcje, które możesz wykonywać, oraz obiekty, do których masz dostęp.
Możesz wyświetlić swoją sesję i aktualne wartości ról, wpisując:
SELECT SESSION_USER, CURRENT_USER;
current_user | session_user--------------+-------------- postgres | postgres(1 row)
Chociaż jedynym sposobem na zmianę roli sesji jest uruchomienie nowego połączenia przy użyciu innej roli, możesz zmienić swoją obecną rolę za pomocą SET ROLE Komenda. SET ROLE Polecenie służy do tymczasowego pełnienia innej roli. Polecenie opcjonalnie przyjmuje również następujące modyfikatory:
SESSION:Ustawienie domyślne. Powoduje to, żeSET ROLEpolecenie, aby wpłynąć na całą sesję bazy danych.LOCAL:Ten modyfikator sprawi, że polecenie zmieni rolę tylko dla bieżącej transakcji.
Aby zmienić bieżącą rolę na user2 rola (do końca sesji), wpisz:
SET ROLE "user2";
Jeśli sprawdzisz swoją sesję i aktualne wartości ról, zobaczysz, że aktualna wartość roli uległa zmianie:
SELECT SESSION_USER, CURRENT_USER;
current_user | session_user--------------+-------------- user2 | postgres(1 row)
Wszystkie Twoje działania będą teraz używać user2 rolę jako kontekst.
Aby przywrócić poprzednio używaną rolę sesji, możesz wpisać:
SET ROLE NONE;
Alternatywą, która pozwala osiągnąć ten sam wynik, jest:
RESET ROLE;
Wniosek
System ról, atrybutów ról, uprawnień i uwierzytelniania PostgreSQL tworzy elastyczny system, który pozwala administratorom efektywnie zarządzać uprawnieniami i dostępem do bazy danych. W tym przewodniku opisano, czym dokładnie są role i jak obejmują szeroki zakres przypadków użycia. Omówiono również sposób tworzenia, modyfikowania i usuwania ról oraz zarządzania atrybutami ról, które określają ich globalne możliwości. Zrozumienie, jak zarządzać tymi tożsamościami, jest konieczne, aby zabezpieczyć bazy danych i zapewnić użyteczny dostęp uprawnionym użytkownikom.
