Zarządzanie dostępem w usłudze Azure HorizonDB (wersja zapoznawcza)

Zarządzanie dostępem do Azure HorizonDB 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 uprawnieniami dostępu Azure bazy danych HorizonDB na dużą skalę jest użycie koncepcji role. 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 HorizonDB 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 klaster Azure HorizonDB 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
• administrator role

Podczas tworzenia klastra Azure HorizonDB należy określić poświadczenia dla elementu administrator role. Użyj tej administrator role funkcji, aby utworzyć więcej ról bazy danych PostgreSQL.

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

CREATE USER exampleuser PASSWORD password123;

Nie używaj roli administratora dla aplikacji.

W środowiskach PaaS opartych na chmurze dostęp do konta superużytkownika Azure HorizonDB jest ograniczony wyłącznie do operacji płaszczyzny sterowania. Rola azuresu ma uprawnienia administratora, ale konto administratora klastra Azure HorizonDB nie jest częścią roli azuresu.

Rola azure_pg_admin istnieje jako konto pseudo-superużytkownika. Identyfikator logowania administratora skonfigurowany podczas tworzenia klastra jest członkiem azure_pg_admin roli.

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

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

Important

Azure HorizonDB umożliwia tworzenie poleceń CAST. Aby uruchomić instrukcję CREATE CAST , użytkownik musi być członkiem azure_pg_admin roli. Obecnie nie można usunąć CAST po utworzeniu.

Azure HorizonDB obsługuje tylko polecenia CAST używające opcji WITH FUNCTION i WITH INOUT. Opcja WITHOUT FUNCTION nie jest obsługiwana.

Kontrola dostępu do schematu

Nowo utworzone bazy danych w usłudze Azure HorizonDB 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 w wystąpieniu usługi Azure HorizonDB, 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 roli public uprawnienie CREATE do schematu public, aby uniemożliwić użytkownikom bazy danych aplikacji tworzenie obiektów w schemacie publicznym.

  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 innej bazy danych w klastrze. 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 HorizonDB

W usłudze Azure HorizonDB schemat publiczny jest własnością roli azure_pg_admin we wszystkich obsługiwanych wersjach bazy danych PostgreSQL.

Ulepszone sterowanie dla azure_pg_admin

W Azure HorizonDB azure_pg_admin rola jest rolą zarządzaną przez system, której nie można modyfikować. Jeśli spróbujesz go zmienić, na przykład udzielając mu innej roli, zostanie wyświetlony błąd podobny do następującego:

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

To ograniczenie jest wbudowanym zabezpieczeniem, które zapobiega zmianom krytycznych ról administracyjnych. Jeśli musisz przypisać uprawnienia lub role, rozważ utworzenie roli niestandardowej i przyznanie niezbędnych uprawnień do tej roli.

Azure HorizonDB zwiększa możliwości roli azure_pg_admin we wszystkich wersjach PostgreSQL. azure_pg_admin Członkowie roli 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. Dzięki tej funkcji 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.

Important

W Azure HorizonDB użytkownikom nie można nadać atrybutu pg_write_all_data, który pozwala użytkownikowi zapisywać dane we wszystkich tabelach, widokach i sekwencjach, tak jakby miał prawa INSERT, UPDATE i DELETE do tych obiektów oraz uprawnienia USAGE do wszystkich schematów, nawet jeśli nie zostały mu one jawnie nadane. Jako obejście zalecane udzielanie podobnych uprawnień na bardziej szczegółowym poziomie dla bazy danych i obiektu.

Zabezpieczenia na poziomie wiersza

Zabezpieczeń na poziomie wiersza (RLS) to funkcja zabezpieczeń Azure HorizonDB, 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 Azure HorizonDB. 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

PostgreSQL obejmuje uprawnienia BYPASSRLS i NOBYPASSRLS, które można przypisać do roli. Domyślnie jest przypisane uprawnienie NOBYPASSRLS. W usłudze Azure HorizonDB uprawnienie do pomijania zabezpieczeń na poziomie wiersza (BYPASSRLS) działa w następujący sposób:

• Użytkownicy niebędący administratorami utworzonymi przez azure_pg_admin rolę administratora mogą w razie potrzeby tworzyć role z atrybutem BYPASSRLS lub uprawnieniami.

• Użyj użytkownika azure_pg_admin do wykonywania zadań administracyjnych wymagających uprawnienia BYPASSRLS.

Treści powiązane

• Secure your Azure HorizonDB (preview)