Správa přístupu na flexibilním serveru Azure Database for PostgreSQL

Správa přístupu k prostředkům flexibilního serveru Azure Database for PostgreSQL je důležitou součástí údržby zabezpečení a dodržování předpisů. Tento článek vysvětluje, jak používat role PostgreSQL a funkce Azure k řízení oprávnění a implementaci osvědčených postupů pro správu přístupu.

Správa rolí

Nejlepší způsob, jak spravovat Azure Database for PostgreSQL flexibilní přístupová oprávnění k serveru ve velkém měřítku, je použití konceptu rolí. Role může být uživatel databáze nebo skupina uživatelů databáze. Role mohou vlastnit databázové objekty a přiřazovat oprávnění k těmto objektům jiným rolím, aby bylo možné řídit, kdo má přístup ke kterým objektům. Jedné roli můžete udělit členství v jiné roli, čímž se členské roli umožní používat oprávnění přiřazená jiné roli. Azure Database for PostgreSQL flexibilní server umožňuje udělit oprávnění přímo uživatelům databáze. Dobrým postupem zabezpečení je vytvoření rolí s konkrétními sadami oprávnění na základě minimálních požadavků na aplikaci a přístup. Přiřaďte jednotlivým uživatelům příslušné role. Pomocí rolí vynucujte model s nejnižšími oprávněními pro přístup k databázovým objektům.

Kromě předdefinovaných rolí, které PostgreSQL vytváří, zahrnuje flexibilní server Azure Database for PostgreSQL tři výchozí role. Tyto role můžete zobrazit spuštěním následujícího příkazu:

SELECT rolname FROM pg_roles;

Jedná se o následující role:

  • azure_pg_admin
  • azuresu
  • role správce

Při vytváření Azure Database for PostgreSQL flexibilního serveru zadáte přihlašovací údaje pro roli správce. Pomocí této role správce můžete vytvořit další role PostgreSQL.

Můžete například vytvořit uživatele nebo roli s názvem demouser.

CREATE USER demouser PASSWORD password123;

Nepoužívejte pro aplikaci roli správce .

V cloudových prostředích PaaS je přístup k účtu superuživatele Azure Database for PostgreSQL omezen pouze na operace roviny řízení pouze cloudovými operátory. Proto účet azure_pg_admin existuje jako účet pseudo-superuživatele. Role správce je členem role azure_pg_admin. Účet správce serveru ale není součástí azuresu role, která má oprávnění superuživatele a používá se k provádění operací roviny řízení. Vzhledem k tomu, že tato služba je spravovaná služba PaaS, je součástí role superuživatele pouze Microsoft.

Seznam rolí na serveru můžete pravidelně auditovat.

Můžete se například připojit pomocí psql klienta a dotazovat se na pg_roles tabulku, která obsahuje seznam všech rolí spolu s oprávněními, jako jsou vytváření dalších rolí, vytváření databází, replikace a další.

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

Důležité

Azure Database for PostgreSQL nedávno povolil možnost vytvářet příkazy CAST. Aby bylo možné spustit CREATE příkaz CAST, musí být uživatel členem skupiny azure_pg_admin . V současné době po vytvoření přetypování CAST nemůžete odstranit.

Azure Database for PostgreSQL podporuje pouze příkazy CAST, které používají tyto WITH FUNCTION a WITH INOUT možnosti. Možnost WITHOUT FUNCTION není podporovaná.

Protokolování auditu ve službě Azure Database for PostgreSQL je k dispozici také ve službě Azure Database for PostgreSQL ke sledování aktivit ve vašich databázích.

Řízení přístupu ke schématu

Nově vytvořené databáze ve službě Azure Database for PostgreSQL zahrnují výchozí sadu oprávnění ve veřejném schématu databáze, která všem uživatelům a rolím databáze umožňuje vytvářet objekty. Pokud chcete lépe omezit přístup uživatelů aplikace k databázím, které vytvoříte na flexibilním serveru Azure Database for PostgreSQL, zvažte odvolání těchto výchozích veřejných oprávnění. Po odvolání těchto oprávnění udělte konkrétním uživatelům databáze podrobnější oprávnění. Například:

  • Odvolání oprávnění k vytvoření schématu publicpublic z role, aby uživatelé aplikační databáze nemohli vytvářet objekty ve veřejném schématu.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Vytvořte novou databázi.

    CREATE DATABASE Test_db;

  • Odvolat všechna oprávnění z veřejného schématu v této nové databázi.

    REVOKE ALL ON DATABASE Test_db FROM PUBLIC;

  • Vytvořte vlastní roli pro uživatele aplikační databáze.

    CREATE ROLE Test_db_user;

  • Udělte uživatelům databáze s touto rolí možnost připojit se k databázi.

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

  • Vytvořte uživatele databáze.

    CREATE USER user1 PASSWORD 'Password_to_change'

  • Přiřaďte uživateli roli s oprávněními pro připojení a výběr.

    GRANT Test_db_user TO user1;

V tomto příkladu se uživatel user1 může připojit a má všechna oprávnění v testovací databázi Test_db, ale ne žádnou jinou databázi na serveru. Místo udělení tomuto uživateli nebo roli VŠECHNA OPRÁVNĚNÍ k této databázi a jejím objektům zvažte udělení specifičtějších oprávnění, například SELECT, INSERT, EXECUTE a dalších. Další informace o oprávněních v databázích PostgreSQL najdete v příkazech GRANT a REVOKE v dokumentaci k PostgreSQL.

Změny vlastnictví veřejného schématu ve službě Azure Database for PostgreSQL

V PostgreSQL 15 a novějších se vlastnictví veřejného schématu změnilo na novou pg_database_owner roli, což vlastníkům databází umožňuje řídit ho. Další informace najdete v poznámkách k verzi PostgreSQL. V Azure Database for PostgreSQL ale tato změna neplatí. Veřejné schéma vlastní azure_pg_admin role ve všech podporovaných verzích PostgreSQL. Toto chování spravované služby poskytuje zabezpečení a konzistenci.

Změny v PostgreSQL 16 v zabezpečení založeném na rolích

V PostgreSQL může mít role databáze mnoho atributů, které definují jeho oprávnění. Jedním z těchto atributů je atribut CREATEROLE, který je důležitý pro správu databáze PostgreSQL uživatelů a rolí. V PostgreSQL 16 byly v tomto atributu zavedeny významné změny.

V PostgreSQL 16 už uživatelé s atributem CREATEROLE nemají možnost předat členství v jakékoli roli komukoli. Místo toho, stejně jako jiní uživatelé bez tohoto atributu, mohou předat pouze členství v rolích, pro které mají ADMIN OPTION. Atribut CREATEROLE v PostgreSQL 16 také stále umožňuje uživatelům bez oprávnění zřizovat nové uživatele. Můžou ale odstranit jenom uživatele, které sami vytvořili. Při pokusu o odstranění uživatelů dojde k chybě v případě, že uživatel nebyl vytvořen uživatelem s atributem CREATEROLE .

PostgreSQL 16 také zavádí novou a vylepšenou integrovanou roli. Role pg_create_subscription umožňuje superuživatelům vytvářet předplatná.

V Azure Database for PostgreSQL flexibilním serveru je role azure_pg_admin role spravovaná systémem, omezená a uživatelé ji nemůžou upravovat. Při pokusech o změnu, například udělení jiné role, dojde k chybě jako:


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

Tato chyba je integrovaná ochrana, která brání změnám důležitých rolí správy. Pokud potřebujete přiřadit oprávnění nebo role, zvažte místo toho vytvoření vlastní role a udělení potřebných oprávnění této roli.

Vylepšený ovládací prvek pro azure_pg_admin

V PostgreSQL 16 se pro uživatele s oprávněním CREATEROLE implementuje striktní struktura hierarchie rolí, konkrétně související s rolemi udělení. Azure Database for PostgreSQL vylepšuje možnosti azure_pg_admin role napříč všemi verzemi PostgreSQL, aby se zlepšila flexibilita správy a řešení omezení zavedených v PostgreSQL. S touto aktualizací můžou členové role azure_pg_admin spravovat role a přistupovat k objektům vlastněným jakoukoli neomezenou rolí, i v případě, že jsou tyto role také členy azure_pg_admin. Toto vylepšení zajišťuje, aby správci udržovali konzistentní a komplexní kontrolu nad správou rolí a oprávnění a poskytovali bezproblémové a spolehlivé prostředí bez nutnosti přístupu superuživatele.

Zabezpečení na úrovni řádků

Zabezpečení na úrovni řádků (RLS) je funkce zabezpečení Azure Database for PostgreSQL, která správcům databází umožňuje definovat zásady, které určují, jak konkrétní řádky dat zobrazují a fungují pro jednu nebo více rolí. Zabezpečení na úrovni řádků přidá do tabulky databáze Azure Database for PostgreSQL další filtr. Když se uživatel pokusí provést akci v tabulce, použije se tento filtr před kritérii dotazu nebo jiným filtrováním a data se zúží nebo odmítne podle zásad zabezpečení. Můžete vytvořit zásady zabezpečení na úrovni řádků pro konkrétní příkazy, jako je SELECT, INSERTUPDATEa DELETEnebo je zadat pro všechny příkazy. Případy použití zabezpečení na úrovni řádků zahrnují implementace kompatibilní s PCI, klasifikovaná prostředí a sdílené hostování nebo víceklientské aplikace.

U tabulky můžou používat práva zabezpečení řádků pouze uživatelé s SET ROW SECURITY právy. Vlastník tabulky může nastavit zabezpečení řádků v tabulce. Stejně jako OVERRIDE ROW SECURITY je i toto právo v současnosti implicitní. Zabezpečení na úrovni řádků nenahrazuje stávající oprávnění GRANT. Přidá jemně odstupňovanou úroveň řízení. Když ROW SECURITY FOR SELECT například nastavíte, aby daný uživatel mohl přistupovat k řádkům, udělí mu přístup pouze v případě, že uživatel má SELECT oprávnění k danému sloupci nebo tabulce.

Následující příklad ukazuje, jak vytvořit zásadu, která zajistí, že pouze členové uživatelsky vytvořené managerrole budou mít přístup pouze k řádkům pro konkrétní účet. Kód v následujícím příkladu se sdílí v dokumentaci k 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);

Klauzule USING implicitně přidává klauzuli WITH CHECK, a zajišťuje tak, že členové role manažera nemohou provádět operace SELECT, DELETE ani UPDATE na řádcích, které patří jiným manažerům, a nemohou INSERT nové řádky patřící jinému manažerovi.

Zásadu zabezpečení na úrovni řádků můžete odstranit pomocí příkazu DROP POLICY, jak ukazuje tento příklad:

DROP POLICY account_managers ON accounts;

I když byste mohli zásadu odstranit, správce rolí stále nemůže zobrazit žádná data, která patří jinému správci. Toto omezení existuje, protože v tabulce účtů jsou stále povolené zásady zabezpečení na úrovni řádků. Pokud je ve výchozím nastavení povolené zabezpečení na úrovni řádků, použije PostgreSQL zásadu výchozího zamítnutí.

Zabezpečení na úrovni řádků můžete zakázat, jak je znázorněno v následujícím příkladu:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Obejít zabezpečení na úrovni řádků

PostgreSQL má oprávnění BYPASSRLS a NOBYPASSRLS , která můžete přiřadit k roli. NOBYPASSRLS je ve výchozím nastavení přiřazena. S nově zřízenými servery ve službě Azure Database for PostgreSQL se vynechání oprávnění zabezpečení na úrovni řádků (BYPASSRLS) implementuje takto:

  • U serverů Postgres 16 a novějších verzí dodržujeme standardní chování PostgreSQL 16. Uživatelé, kteří nejsou správci a které vytvořila role správce azure_pg_admin, vám umožňují podle potřeby vytvářet role s atributem nebo oprávněním BYPASSRLS.

  • U serverů Postgres 15 a starších verzí můžete pomocí azure_pg_admin uživatele provádět úlohy správy, které vyžadují oprávnění BYPASSRLS. S oprávněním BypassRLS ale nemůžete vytvářet uživatele bez oprávnění správce, protože role správce nemá žádná oprávnění superuživatele, jak je běžné v cloudových službách PaaS PostgreSQL.

Související obsah

  • Last updated on