Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Zarządzanie dostępem do zasobów usługi Azure Database for PostgreSQL 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 do bazy danych usługi Azure Database for PostgreSQL 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 przyznać członkostwu w roli innej roli, która umożliwia roli członka używanie uprawnień przypisanych do innej roli. Usługa Azure Database for PostgreSQL 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 wystąpienie usługi 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_adminazuresu- rola administratora
Podczas tworzenia wystąpienia usługi 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.
azure_pg_admin W związku z tym konto istnieje jako konto pseudoużytkownika. Rola administratora jest członkiem azure_pg_admin roli.
Jednak konto administratora serwera nie jest częścią azuresu roli, która ma uprawnienia administratora i służy do wykonywania operacji płaszczyzny 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ąć rzutowania po jego utworzeniu.
Usługa Azure Database for PostgreSQL obsługuje tylko polecenia CAST korzystające z WITH FUNCTION opcji 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 w wystąpieniu usługi 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:
Odwoływanie uprawnień tworzenia do schematu
publicpublicz roli, 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;Odwołaj wszystkie uprawnienia ze schematu PUBLICZNEGO 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 tę rolę możliwość nawiązywania połączenia 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 rolę z jej połączeniem i wybierz uprawnienia do użytkownika.
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 publiczny jest własnością azure_pg_admin roli we wszystkich obsługiwanych wersjach bazy danych 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 programie PostgreSQL 16 użytkownicy z atrybutem CREATEROLE nie mają już możliwości rozdania członkostwu w żadnej roli każdemu. Zamiast tego, podobnie jak inni użytkownicy bez tego atrybutu, mogą przekazać członkostwo tylko w rolach, dla których mają .ADMIN OPTION Ponadto w usłudze PostgreSQL 16 atrybut CREATEROLE nadal zezwala spoza użytkownika na aprowizację 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 usługi Azure Database for PostgreSQL rola azure_pg_admin jest rolą zarządzaną przez system, ograniczoną i nie może być modyfikowana przez użytkowników. Próby jego zmiany, takie jak przyznanie mu innej roli, spowoduje wystąpienie błędu, takiego jak:
GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"
Jest to wbudowane zabezpieczenie, które zapobiega zmianom w krytycznych rolach administracyjnych. Jeśli musisz przypisać uprawnienia lub role, rozważ utworzenie roli niestandardowej i przyznanie niezbędnych uprawnień do tej roli.
Ulepszona kontrola 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.
Ważne
Usługa Azure Database for PostgreSQL nie zezwala użytkownikom na przyznawanie pg_write_all_data atrybutu, który umożliwia użytkownikowi zapisywanie wszystkich danych (tabel, widoków, sekwencji), tak jak w przypadku INSERTposiadania praw , UPDATEi DELETE na tych obiektach oraz praw UŻYTKOWANIA we wszystkich schematach, nawet bez jawnego udzielenia. Jako obejście zalecane udzielanie podobnych uprawnień na bardziej skończonym poziomie dla bazy danych i obiektu.
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ń. Przypadki użycia zabezpieczeń na poziomie wiersza obejmują implementacje zgodne ze standardami PCI, środowiska sklasyfikowane oraz udostępnione aplikacje hostingowe lub wielodostępne.
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.
W poniższym przykładzie pokazano, jak utworzyć zasady, które zapewniają dostęp tylko do wierszy dla określonego konta tylko członków rolimenedżera utworzonego przez użytkownika niestandardowego. 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 menedżera nie mogą wykonywać SELECToperacji na DELETEUPDATE wierszach należących do innych menedżerów i nie INSERT mogą tworzyć nowych wierszy należących do innego menedżera.
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 istnieje, ponieważ zasady zabezpieczeń na poziomie wiersza są nadal włączone w tabeli accounts. 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 aprowizowania serwerów w usłudze Azure Database for PostgreSQL pomijanie uprawnień zabezpieczeń na poziomie wiersza (BYPASSRLS) jest implementowane w następujący sposób:
W przypadku serwerów Postgres 16 lub nowszych używamy standardowego zachowania bazy danych PostgreSQL 16. Użytkownicy niebędący administratorami utworzonymi przez rolę administratora azure_pg_admin umożliwiają tworzenie ról za pomocą atrybutu BYPASSRLS lub uprawnień w razie potrzeby.
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.