Zabezpečení na flexibilním serveru Azure Database for PostgreSQL

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

K dispozici je několik vrstev zabezpečení, které pomáhají chránit data v instanci flexibilního serveru Azure Database for PostgreSQL. Tento článek popisuje tyto možnosti zabezpečení.

Vzhledem k tomu, že organizace stále více spoléhají na data uložená v databázích k řízení důležitých rozhodovacích aktivit, které řídí konkurenční výhodu, není potřeba pevného zabezpečení databází nikdy důležitější. Selhání zabezpečení může vyvolat katastrofické důsledky, včetně zveřejnění důvěrných dat, což způsobí poškození pověsti organizace.

Ochrana a šifrování informací

Flexibilní server Azure Database for PostgreSQL šifruje data dvěma způsoby:

• Přenášená data: Flexibilní server Azure Database for PostgreSQL šifruje přenášená data pomocí protokolu SSL/TLS (Secure Sockets Layer a Transport Layer Security). Šifrování se vynucuje ve výchozím nastavení. Podrobnější informace o zabezpečení připojení pomocí protokolu SSL\TLS najdete v této dokumentaci. Pro lepší zabezpečení se můžete rozhodnout povolit ověřování SCRAM na flexibilním serveru Azure Database for PostgreSQL.

  I když se v případě potřeby důrazně nedoporučuje, protože starší verze klienta není nekompatibility, máte možnost zakázat TLS\SSL pro připojení k flexibilnímu serveru Azure Database for PostgreSQL aktualizací parametru require_secure_transport serveru na VYPNUTO. Verzi protokolu TLS můžete nastavit také nastavením ssl_max_protocol_version parametrů serveru.

• Neaktivní uložená data: Pro šifrování úložiště používá flexibilní server Azure Database for PostgreSQL ověřený kryptografický modul FIPS 140-2. Data se šifrují na disku, a to včetně záloh a dočasných souborů vytvořených za běhu dotazů.

  Služba používá 256bitové šifrování AES, které je součástí šifrování úložiště Azure, a klíče jsou spravované systémem. Podobá se to dalším technologiím šifrování neaktivních uložených dat, jako je transparentní šifrování dat na SQL Serveru nebo v databázích Oracle. Šifrování úložiště je vždycky aktivní a není možné ho zakázat.

Zabezpečení sítě

Pokud používáte flexibilní server Azure Database for PostgreSQL, máte dvě hlavní možnosti sítí:

• Privátní přístup: Svůj server můžete nasadit do virtuální sítě Azure. Virtuální sítě Azure pomáhají zajistit privátní a zabezpečenou síťovou komunikaci. Prostředky ve virtuální síti můžou komunikovat prostřednictvím privátních IP adres. Další informace najdete v přehledu sítí pro flexibilní server Azure Database for PostgreSQL.

  Pravidla zabezpečení ve skupinách zabezpečení sítě umožňují filtrovat typ síťového provozu, který může přicházet do podsítí virtuálních sítí a síťových rozhraní a odcházet z nich. Další informace najdete v přehledu skupin zabezpečení sítě.

• Veřejný přístup: K serveru je možné přistupovat přes veřejný koncový bod. Veřejný koncový bod je veřejně přeložitelná adresa DNS. Přístup k této bráně je zabezpečený přes bránu firewall, která ve výchozím nastavení blokuje všechna připojení.

  Pravidla firewallu protokolu IP udělují přístup k serverům na základě zdrojové IP adresy každého požadavku. Další informace najdete v přehledu pravidel brány firewall.

Podpora Microsoft Defenderu pro cloud

Microsoft Defender pro opensourcové relační databáze detekuje neobvyklé aktivity označující neobvyklé a potenciálně škodlivé pokusy o přístup k databázím nebo jejich zneužití. Defender for Cloud poskytuje výstrahy zabezpečení na neobvyklé aktivity, abyste mohli detekovat potenciální hrozby a reagovat na ně, když k nim dojde. Když tento plán povolíte, Defender for Cloud poskytuje výstrahy, když detekuje neobvyklý přístup k databázi a vzory dotazů a podezřelé databázové aktivity.

Tyto výstrahy se zobrazí na stránce výstrah zabezpečení v programu Defender for Cloud a zahrnují tyto položky:

• Podrobnosti o podezřelé aktivitě, která je aktivovala
• Přidružená taktika MITRE ATT&CK
• Doporučené akce pro prozkoumání a zmírnění hrozby
• Možnosti pro pokračování vyšetřování v Microsoft Sentinelu

Microsoft Defender for Cloud a útoky hrubou silou

Útok hrubou silou patří mezi nejběžnější a poměrně úspěšné metody hackování, i když nejméně sofistikované. Teorie takového útoku spočívá v tom, že pokud vezmete nekonečný počet pokusů o uhodnutí hesla, budete mít pravdu nakonec. Když Microsoft Defender for Cloud zjistí útok hrubou silou, aktivuje výstrahu, která vás upozorní, že došlo k útoku hrubou silou. Může také oddělit jednoduchý útok hrubou silou od útoku hrubou silou na platného uživatele nebo úspěšného útoku hrubou silou.

Pokud chcete dostávat upozornění z plánu Microsoft Defenderu, musíte ho nejdřív povolit, jak je znázorněno v další části.

Povolení rozšířeného zabezpečení pomocí Microsoft Defenderu pro cloud

1. Na webu Azure Portal přejděte do nabídky Zabezpečení v levém podokně.
2. Výběr Microsoft Defenderu pro cloud
3. V pravém podokně vyberte Povolit.

Poznámka:

Pokud máte v plánu Microsoft Defender povolenou funkci open source relačních databází, zjistíte, že pro prostředek flexibilního serveru Azure Database for PostgreSQL je ve výchozím nastavení automaticky povolený Microsoft Defender.

Správa přístupu

Nejlepším způsobem, jak spravovat přístupová oprávnění k databázi flexibilního serveru Azure Database for PostgreSQL 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. Členství v roli je také možné udělit jiné roli, takže členská role může používat oprávnění přiřazená jiné roli. Flexibilní server Azure Database for PostgreSQL umožňuje udělit oprávnění přímo uživatelům databáze. Dobrým postupem zabezpečení je vhodné vytvořit role s konkrétními sadami oprávnění na základě minimálních požadavků na aplikaci a přístup. Potom můžete každému uživateli přiřadit příslušné role. Role se používají k vynucení modelu s nejnižšími oprávněními pro přístup k databázovým objektům.

Kromě předdefinovaných rolí PostgreSQL se vytvoří instance flexibilního serveru Azure Database for PostgreSQL se třemi výchozími rolemi. Tyto role můžete zobrazit spuštěním příkazu:

SELECT rolname FROM pg_roles;

Role jsou uvedené níže:

• azure_pg_admin
• azuresu
• role správce

Při vytváření instance flexibilního serveru Azure Database for PostgreSQL zadáte přihlašovací údaje pro roli správce. S využitím role správce je možné vytvářet další role PostgreSQL.

Níže můžeme například vytvořit příklad uživatele nebo role s názvem demouser.

 CREATE USER demouser PASSWORD password123;

Role správce by nikdy neměla být aplikací používána.

V cloudových prostředích PaaS je přístup k účtu superuživatele flexibilního serveru Azure Database for PostgreSQL omezen pouze na operace řídicí roviny pouze operátory cloudu. azure_pg_admin Účet proto existuje jako pseudo-superuživatel. Role správce je členem azure_pg_admin této role.
Úč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 všechny role spolu s oprávněními, jako jsou vytváření dalších rolí, vytváření databází, replikace atd.

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é

Důležité je poznamenat, že u flexibilního serveru Azure Database for PostgreSQL není k dispozici počet oprávnění, jako je například vytvoření určitých implicitních implicitních přetypování binárních souborů, protože azure_pg_admin role neodpovídá oprávněním role superuživatele PostgreSQL. Binární převodové přetypování je typ přetypování, který nevyžaduje žádnou funkci k provedení převodu, protože zdrojové a cílové typy mají stejné interní reprezentaci Ne binární převody, včetně obsahujících možnosti WITH IN OUT a WITH FUNCTION jsou podporovány.

Protokolování auditu na flexibilním serveru Azure Database for PostgreSQL je k dispozici také u flexibilního serveru 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 na flexibilním serveru Azure Database for PostgreSQL mají výchozí sadu oprávnění ve veřejném schématu databáze, která umožňuje všem uživatelům a rolím databáze vytvářet objekty. Pokud chcete lépe omezit přístup uživatelů aplikace k databázím, které vytvoříte v instanci flexibilního serveru Azure Database for PostgreSQL, doporučujeme zvážit odvolání těchto výchozích veřejných oprávnění. Potom můžete uživatelům databáze udělit specifická oprávnění podrobněji. Příklad:

• Pokud chcete uživatelům aplikační databáze zabránit ve vytváření objektů ve veřejném schématu, odvoláte oprávnění k public vytvoření schématu z public role.

  REVOKE CREATE ON SCHEMA public FROM PUBLIC;
  

• Dále 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ření vlastní role pro uživatele databáze aplikací

  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ření uživatele databáze

  CREATE USER user1 PASSWORD 'Password_to_change'
  

• Přiřazení role s oprávněními pro připojení a výběr uživateli

  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 naší testovací databázi Test_db, ale ne žádnou jinou databázi na serveru. Místo toho, aby tento uživatel\role VŠECHNA OPRÁVNĚNÍ pro danou databázi a jeho objekty poskytoval více selektivních oprávnění, jako je SELECT, INSERT, EXECUTE atd. 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 v PostgreSQL 15

Z Postgres verze 15 se vlastnictví veřejného schématu změnilo na novou roli pg_database_owner. Umožňuje každému vlastníkovi databáze vlastnit veřejné schéma databáze.
Další informace najdete v poznámkách k verzi PostgreSQL.

Změny PostgreSQL 16 se zabezpečením na základě rolí

V databázové roli PostgreSQL může mít 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 do tohoto atributu zavedeny významné změny. V PostgreSQL 16 už uživatelé s atributem CREATEROLE nemají možnost předávat členství v žádné roli komukoli. Místo toho, stejně jako jiní uživatelé bez tohoto atributu, můžou členství v rolích, pro které mají možnost SPRÁVCE. V PostgreSQL 16 také atribut CREATEROLE stále umožňuje uživatelům, kteří nejsou uživateli, aby zřídili nové uživatele, ale můžou odstranit pouze uživatele, které sami vytvořili. Pokusy o odstranění uživatelů, které uživatel s atributem CREATEROLE nevytvoří, způsobí chybu.

PostgreSQL 16 také zavedl nové a vylepšené předdefinované role. Nová role pg_use_reserved_connections v PostgreSQL 16 umožňuje použití slotů připojení rezervovaných prostřednictvím reserved_connections. Role pg_create_subscription umožňuje superuživatelům vytvářet předplatná.

Důležité

Flexibilní server Azure Database for PostgreSQL neumožňuje uživatelům udělit atribut pg_write_all_data , který uživateli umožňuje zapisovat všechna data (tabulky, zobrazení, sekvence), jako by k těmto objektům měly práva INSERT, UPDATE a DELETE a práva k používání pro všechna schémata, a to i bez explicitního udělení. Jako alternativní řešení se doporučuje udělit podobná oprávnění na více konečných úrovních pro databázi a objekt.

Zabezpečení na úrovni řádků

Zabezpečení na úrovni řádků (RLS) je funkce zabezpečení flexibilního serveru Azure Database for PostgreSQL, která správcům databází umožňuje definovat zásady pro řízení toho, jak konkrétní řádky dat zobrazují a fungují pro jednu nebo více rolí. Zabezpečení na úrovni řádků je další filtr, který můžete použít pro tabulku databáze flexibilního serveru Azure Database for PostgreSQL. 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 zamítnou podle zásad zabezpečení. Můžete vytvořit zásady zabezpečení na úrovni řádků pro konkrétní příkazy, jako je SELECT, INSERT, UPDATE a DELETE, a zadat je 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í / víceklientské aplikace.

U tabulky můžou používat práva zabezpečení řádků jenom uživatelé s SET ROW SECURITY právy. Vlastník tabulky může nastavit zabezpečení řádků v tabulce. Stejně jako OVERRIDE ROW SECURITY v současné době je to implicitní právo. Zabezpečení na úrovni řádků nepřepíše stávající GRANT oprávnění, přidává jemně odstupňovanou úroveň řízení. Pokud má uživatel například ROW SECURITY FOR SELECT oprávnění k danému sloupci nebo tabulce, může dát danému uživateli přístup pouze v případě, že má SELECT oprávnění k danému sloupci nebo tabulce.

Tady je příklad, který ukazuje, jak vytvořit zásadu, která zajišťuje, že k řádkům pro konkrétní účet mají přístup jenom členové vlastní vytvořené role manažera. Kód v následujícím příkladu se sdílel 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á WITH CHECK klauzuli, která zajišťuje, že členové role správce nemohou provádět SELECT, DELETEani UPDATE operace s řádky, které patří jiným manažerům, a nemohou INSERT nové řádky patřící jinému manažerovi. Zásady zabezpečení řádků můžete vyřadit pomocí příkazu DROP POLICY, jako v příkladu:

DROP POLICY account_managers ON accounts;

I když jste mohli zásadu vynechat, správce rolí stále nemůže zobrazit žádná data, která patří jinému správci. Důvodem je to, že v tabulce účtů je stále povolená zásada 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;

Obcházení zabezpečení na úrovni řádků

PostgreSQL má oprávnění BYPASSRLS a NOBYPASSRLS , která je možné přiřadit k roli; FUNKCE NOBYPASSRLS je ve výchozím nastavení přiřazena. U nově zřízených serverů ve službě Azure Database for PostgreSQL – Flexibilní server obejití oprávnění zabezpečení na úrovni řádků (BYPASSRLS) se implementuje takto:

• U serverů Postgres 16 a vyšších verzí se řídíme standardním chováním PostgreSQL 16. Nesprávní uživatelé vytvořená rolí správce azure_pg_admin umožňují vytvářet role s atributem BYPASSRLS a oprávněním podle potřeby.
• Pro servery Postgres 15 a nižší verze. Můžete použít azure_pg_admin uživatele k úlohám správy, které vyžadují oprávnění BYPASSRLS, ale nemůžete vytvářet uživatele bez oprávnění správce s oprávněním BypassRLS, protože role správce nemá žádná oprávnění superuživatele, jak je běžné v cloudových službách PaaS PostgreSQL.

Aktualizace hesel

Pro lepší zabezpečení je vhodné pravidelně obměňovat hesla správce a hesla uživatelů databáze. Doporučujeme používat silná hesla s velkými a dolními písmeny, čísly a speciálními znaky.

Použití SCRAM

Mechanismus ověřování SCRAM (Salted Challenge Response Authentication Mechanism) výrazně zlepšuje zabezpečení ověřování uživatelů založených na heslech přidáním několika klíčových funkcí zabezpečení, které brání útokům duhové tabulky, útokům man-in-the-middle a uloženým útokům hesel a zároveň přidává podporu více algoritmů hash a hesel, které obsahují znaky jiné než ASCII.

Při ověřování SCRAM se klient podílí na práci s šifrováním, aby vytvořil doklad o identitě. Ověřování SCRAM proto přesměruje některé výpočetní náklady na své klienty, což jsou ve většině případů aplikační servery. Přechod na SCRAM kromě silnějšího hashovacího algoritmu nabízí také ochranu před distribuovanými útoky DDoS (Denial-of-Service) proti PostgreSQL tím, že brání přetížení procesoru serveru pro výpočet hodnot hash hesel.

Pokud váš klientský ovladač podporuje SCRAM, můžete nastavit přístup k flexibilnímu serveru Azure Database for PostgreSQL pomocí SCRAM jako scram-sha-256 výchozího md5.

Resetování hesla správce

Postupujte podle pokynů k resetování hesla správce.

Aktualizace hesla uživatele databáze

Pomocí klientských nástrojů můžete aktualizovat hesla uživatelů databáze.
Příklad:

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Související obsah

• Pravidla brány firewall pro IP adresy
• Sítě privátního přístupu s flexibilním serverem Azure Database for PostgreSQL
• Ověřování Microsoft Entra