Zarządzanie dostępem na serwerze elastycznym Azure Database for PostgreSQL

Zarządzanie dostępem do Azure Database for PostgreSQL elastycznych zasobów serwera jest ważną częścią utrzymania zabezpieczeń i zgodności. W tym artykule wyjaśniono, jak używać ról postgreSQL i funkcji platformy Azure do kontrolowania uprawnień i implementowania najlepszych rozwiązań dotyczących zarządzania dostępem.

Zarządzanie rolami

Najlepszym sposobem zarządzania Azure Database for PostgreSQL elastycznymi uprawnieniami dostępu do serwera na dużą skalę jest użycie koncepcji ról. Rola może być użytkownikiem bazy danych lub grupą użytkowników bazy danych. Role mogą być właścicielami obiektów bazy danych i przypisywać uprawnienia do tych obiektów do innych ról, aby kontrolować, kto ma dostęp do których obiektów. Możesz nadać członkostwo w roli innej roli, co pozwala roli członkowskiej korzystać z uprawnień przypisanych do innej roli. Azure Database for PostgreSQL serwer elastyczny umożliwia przyznawanie uprawnień bezpośrednio użytkownikom bazy danych. Dobrym rozwiązaniem w zakresie zabezpieczeń jest tworzenie ról z określonymi zestawami uprawnień na podstawie minimalnych wymagań aplikacji i dostępu. Przypisz odpowiednie role do każdego użytkownika. Użyj ról, aby wymusić model najniższych uprawnień na potrzeby uzyskiwania dostępu do obiektów bazy danych.

Oprócz wbudowanych ról tworzonych przez usługę PostgreSQL serwer elastyczny Azure Database for PostgreSQL zawiera trzy role domyślne. Te role można wyświetlić, uruchamiając następujące polecenie:

SELECT rolname FROM pg_roles;

Istnieją następujące role:

  • azure_pg_admin
  • azuresu
  • rola administratora

Podczas tworzenia serwera elastycznego Azure Database for PostgreSQL należy podać poświadczenia dla roli administratora. Użyj tej roli administratora, aby utworzyć więcej ról bazy danych PostgreSQL.

Możesz na przykład utworzyć użytkownika lub rolę o nazwie demouser.

CREATE USER demouser PASSWORD password123;

Nie używaj roli administratora dla aplikacji.

W środowiskach PaaS opartych na chmurze dostęp do konta superużytkownika usługi Azure Database for PostgreSQL jest ograniczony do sterowania operacjami płaszczyzny tylko przez operatory chmury. Dlatego konto azure_pg_admin istnieje jako konto pseudo-superużytkownika. Rola administratora należy do roli azure_pg_admin. Jednak konto administratora serwera nie należy do roli azuresu, która ma uprawnienia superużytkownika i służy do wykonywania operacji w płaszczyźnie sterowania. Ponieważ ta usługa jest zarządzaną usługą PaaS, tylko firma Microsoft jest częścią roli administratora.

Można okresowo przeprowadzać inspekcję listy ról na serwerze.

Możesz na przykład nawiązać połączenie przy użyciu psql klienta i wykonać zapytanie pg_roles względem tabeli, która zawiera listę wszystkich ról wraz z uprawnieniami, takimi jak tworzenie innych ról, tworzenie baz danych, replikacja i nie tylko.

select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname        | demouser
rolsuper       | f
rolinherit     | t
rolcreaterole  | f
rolcreatedb    | f
rolcanlogin    | f
rolreplication | f
rolconnlimit   | -1
rolpassword    | ********
rolvaliduntil  |
rolbypassrls   | f
rolconfig      |
oid            | 24827

Ważne

Ostatnio usługa Azure Database for PostgreSQL umożliwiała tworzenie poleceń CAST. Aby uruchomić instrukcję CREATE CAST, użytkownik musi być członkiem grupy azure_pg_admin . Obecnie nie można usunąć CAST po utworzeniu.

Usługa Azure Database for PostgreSQL obsługuje tylko polecenia CAST, które używają opcji WITH FUNCTION i WITH INOUT. Opcja WITHOUT FUNCTION nie jest obsługiwana.

Rejestrowanie inspekcji w usłudze Azure Database for PostgreSQL jest również dostępne w usłudze Azure Database for PostgreSQL w celu śledzenia aktywności w bazach danych.

Kontrola dostępu do schematu

Nowo utworzone bazy danych w usłudze Azure Database for PostgreSQL zawierają domyślny zestaw uprawnień w publicznym schemacie bazy danych, który przyznaje wszystkim użytkownikom bazy danych i rolam możliwość tworzenia obiektów. Aby lepiej ograniczyć dostęp użytkowników aplikacji do baz danych utworzonych na serwerze elastycznym Azure Database for PostgreSQL, rozważ odwołanie tych domyślnych uprawnień publicznych. Po odwołaniu tych uprawnień przyznaj określone uprawnienia użytkownikom bazy danych w bardziej szczegółowy sposób. Przykład:

  • Odbierz uprawnienia do tworzenia w schemacie public roli public, aby uniemożliwić użytkownikom bazy danych aplikacji tworzenie obiektów w schemacie public.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Utwórz nową bazę danych.

    CREATE DATABASE Test_db;

  • Odbierz wszystkie uprawnienia do schematu PUBLIC w tej nowej bazie danych.

    REVOKE ALL ON DATABASE Test_db FROM PUBLIC;

  • Utwórz rolę niestandardową dla użytkowników bazy danych aplikacji.

    CREATE ROLE Test_db_user;

  • Nadaj użytkownikom bazy danych z tą rolą możliwość łączenia się z bazą danych.

    GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;

  • Utwórz użytkownika bazy danych.

    CREATE USER user1 PASSWORD 'Password_to_change'

  • Przypisz użytkownikowi rolę wraz z uprawnieniami CONNECT i SELECT.

    GRANT Test_db_user TO user1;

W tym przykładzie użytkownik user1 może nawiązać połączenie i ma wszystkie uprawnienia w testowej bazie danych Test_db, ale nie żadnej innej bazy danych na serwerze. Zamiast udzielać temu użytkownikowi lub roli WSZYSTKIE UPRAWNIENIA w tej bazie danych i jego obiektach, rozważ udostępnienie bardziej selektywnych uprawnień, takich jak SELECT, INSERT, EXECUTEi innych. Aby uzyskać więcej informacji na temat uprawnień w bazach danych PostgreSQL, zobacz polecenia GRANT i REVOKE w dokumentacji bazy danych PostgreSQL.

Zmiany własności schematu publicznego w usłudze Azure Database for PostgreSQL

W programie PostgreSQL 15 lub nowszym własność schematu publicznego została zmieniona na nową pg_database_owner rolę, która umożliwia właścicielom bazy danych kontrolowanie tego schematu. Aby uzyskać więcej informacji, zobacz informacje o wersji bazy danych PostgreSQL. Jednak w usłudze Azure Database for PostgreSQL ta zmiana nie ma zastosowania. Schemat `public` należy do roli azure_pg_admin we wszystkich obsługiwanych wersjach PostgreSQL. To zachowanie usługi zarządzanej zapewnia bezpieczeństwo i spójność.

Zmiany bazy danych PostgreSQL 16 z zabezpieczeniami opartymi na rolach

W usłudze PostgreSQL rola bazy danych może mieć wiele atrybutów definiujących jej uprawnienia. Jednym z takich atrybutów jest atrybut CREATEROLE, który jest ważny dla zarządzania bazą danych PostgreSQL użytkowników i ról. W programie PostgreSQL 16 wprowadzono istotne zmiany w tym atrybucie.

W PostgreSQL 16 użytkownicy z atrybutem CREATEROLE nie mogą już przyznawać dowolnym użytkownikom członkostwa w dowolnej roli. Zamiast tego, podobnie jak inni użytkownicy bez tego atrybutu, mogą przydzielać członkostwo tylko w tych rolach, dla których posiadają ADMIN OPTION. Ponadto, w PostgreSQL 16 atrybut CREATEROLE nadal pozwala użytkownikowi niebędącemu superużytkownikiem tworzyć nowych użytkowników. Mogą jednak usuwać tylko utworzonych przez siebie użytkowników. Próby porzucania użytkowników powodują błąd, gdy użytkownik nie został utworzony przez użytkownika z atrybutem CREATEROLE .

Program PostgreSQL 16 wprowadza również nową i ulepszoną wbudowaną rolę. Rola pg_create_subscription umożliwia superużytkownikom tworzenie subskrypcji.

Na serwerze elastycznym Azure Database for PostgreSQL rola azure_pg_admin jest zarządzaną przez system rolą o ograniczonych uprawnieniach i nie może być modyfikowana przez użytkowników. Próby jego zmiany, takie jak przyznanie mu innej roli, powodują błąd, taki jak:


  GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"

Ten błąd jest wbudowanym zabezpieczeniem zapobiegającym zmianom krytycznych ról administracyjnych. Jeśli musisz przypisać uprawnienia lub role, rozważ utworzenie roli niestandardowej i przyznanie niezbędnych uprawnień do tej roli.

Większa kontrola nad azure_pg_admin

W programie PostgreSQL 16 zaimplementowano ścisłą strukturę hierarchii ról dla użytkowników z uprawnieniami CREATEROLE , w szczególności związanymi z udzielaniem ról. Aby zwiększyć elastyczność administracyjną i rozwiązać problem z ograniczeniami wprowadzonymi w usłudze PostgreSQL 16, usługa Azure Database for PostgreSQL zwiększa możliwości roli azure_pg_admin we wszystkich wersjach bazy danych PostgreSQL. Dzięki tej aktualizacji członkowie roli azure_pg_admin mogą zarządzać rolami i uzyskiwać dostęp do obiektów należących do dowolnej nieokreślonej roli, nawet jeśli te role są również członkami azure_pg_admin. To ulepszenie gwarantuje, że użytkownicy administracyjni zachowają spójną i kompleksową kontrolę nad zarządzaniem rolami i uprawnieniami, zapewniając bezproblemowe i niezawodne środowisko bez konieczności dostępu administratora.

Zabezpieczenia na poziomie wiersza

Zabezpieczenia na poziomie wiersza to funkcja zabezpieczeń usługi Azure Database for PostgreSQL, która umożliwia administratorom bazy danych definiowanie zasad kontrolujących sposób wyświetlania i działania określonych wierszy danych dla co najmniej jednej roli. Zabezpieczenia na poziomie wiersza dodają dodatkowy filtr do tabeli bazy danych usługi Azure Database for PostgreSQL. Gdy użytkownik próbuje wykonać akcję w tabeli, ten filtr jest stosowany przed kryteriami zapytania lub innymi filtrami, a dane zawężają lub odrzucają zgodnie z zasadami zabezpieczeń. Możesz utworzyć zasady zabezpieczeń na poziomie wiersza dla określonych poleceń, takich jak SELECT, INSERT, UPDATEi DELETE, lub określić je dla wszystkich poleceń. Przykłady zastosowań zabezpieczeń na poziomie wierszy to implementacje zgodne z PCI, środowiska niejawne oraz hosting współdzielony lub aplikacje wielodzierżawne.

Tylko użytkownicy z prawami SET ROW SECURITY mogą stosować prawa zabezpieczeń wierszy do tabeli. Właściciel tabeli może ustawić zabezpieczenia wierszy w tabeli. Podobnie jak OVERRIDE ROW SECURITY, to prawo jest obecnie prawem niejawnym. Zabezpieczenia na poziomie wiersza nie zastępują istniejących GRANT uprawnień. Dodaje bardziej precyzyjny poziom kontroli. Na przykład ustawienie ROW SECURITY FOR SELECT zezwalające użytkownikowi na dostęp do wierszy udziela dostępu tylko tym użytkownikom, jeśli użytkownik ma SELECT również uprawnienia do danej kolumny lub tabeli.

Poniższy przykład pokazuje, jak utworzyć zasadę, która zapewnia, że tylko członkowie niestandardowej rolimanager mają dostęp wyłącznie do wierszy dotyczących określonego konta. Kod w poniższym przykładzie jest udostępniany w dokumentacji bazy danych PostgreSQL.

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);

Klauzula USING niejawnie dodaje klauzulę WITH CHECK, zapewniając, że członkowie roli managera nie mogą wykonywać operacji SELECT, DELETE ani UPDATE na wierszach należących do innych managerów oraz nie mogą INSERT nowych wierszy należących do innego managera.

Zasady zabezpieczeń wiersza można usunąć przy użyciu DROP POLICY polecenia , jak pokazano w tym przykładzie:

DROP POLICY account_managers ON accounts;

Mimo że zasady mogą zostać porzucene, menedżer ról nadal nie może wyświetlać żadnych danych należących do innego menedżera. To ograniczenie wynika z tego, że zasada zabezpieczeń na poziomie wiersza jest nadal włączona w tabeli kont. Jeśli zabezpieczenia na poziomie wiersza są domyślnie włączone, usługa PostgreSQL używa zasad odmowy domyślnej.

Zabezpieczenia na poziomie wiersza można wyłączyć, jak pokazano w poniższym przykładzie:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Pomijanie zabezpieczeń na poziomie wiersza

Usługa PostgreSQL ma uprawnienia BYPASSRLS i NOBYPASSRLS , które można przypisać do roli. NOBYPASSRLS jest domyślnie przypisywany. W przypadku nowo aprowizowanych serwerów w usłudze Azure Database for PostgreSQL pomijanie zabezpieczeń na poziomie wiersza (BYPASSRLS) jest realizowane w następujący sposób:

  • W przypadku serwerów Postgres 16 lub nowszych używamy standardowego zachowania bazy danych PostgreSQL 16. Użytkownicy bez uprawnień administratora utworzeni przez rolę administratora azure_pg_admin umożliwiają tworzenie ról z atrybutem lub uprawnieniem BYPASSRLS, w zależności od potrzeb.

  • W przypadku serwerów Postgres 15 i starszych w wersji można użyć użytkownika azure_pg_admin do wykonywania zadań administracyjnych, które wymagają uprawnień BYPASSRLS. Nie można jednak tworzyć użytkowników niebędących administratorami z uprawnieniami BypassRLS, ponieważ rola administratora nie ma uprawnień administratora, co jest powszechne w usługach PaaS PostgreSQL opartych na chmurze.

Treści powiązane

  • Last updated on