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_transportserveru na VYPNUTO. Verzi protokolu TLS můžete nastavit také nastavenímssl_max_protocol_versionparametrů 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á režim Galois/Counter Mode (GCM) s 256bitovou šifrou 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
- Na webu Azure Portal přejděte do nabídky Zabezpečení v levém podokně.
- Výběr Microsoft Defenderu pro cloud
- 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é
V poslední době se na flexibilním serveru Azure Database for PostgreSQL povolila možnost vytvářet příkazy CAST. Pokud chcete spustit příkaz CREATE CAST, musí být uživatel členem skupiny azure_pg_admin . Mějte na paměti, že po vytvoření není možné přetypování vypustit.
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
publicvytvoření schématu zpublicrole.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 správce. 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
Podpora služby Azure Policy
Azure Policy pomáhá vynucovat standardy organizace a vyhodnotit dodržování předpisů ve velkém měřítku. Skrze řídicí panel dodržování předpisů nabízí agregované zobrazení sloužící k vyhodnocení celkového stavu prostředí s možností přejít k podrobnostem jednotlivých prostředků a podrobnostem zásad. Napomáhá tomu, aby prostředky dodržovaly předpisy, a sice prostřednictvím hromadné nápravy existujících prostředků a automatické nápravy nových prostředků.
Předdefinované definice zásad
Předdefinované zásady jsou vyvíjeny a testovány Microsoftem a zajišťují, aby splňovaly běžné standardy a osvědčené postupy, které se nasazují rychle bez nutnosti další konfigurace, což je ideální pro standardní požadavky na dodržování předpisů. Předdefinované zásady často pokrývají široce známé standardy a architektury dodržování předpisů.
Následující část obsahuje index předdefinovaných definic zásad služby Azure Policy pro flexibilní server Azure Database for PostgreSQL. Pomocí odkazu ve sloupci Zdroj zobrazte zdroj v úložišti Azure Policy na GitHubu.
| Název (Azure Portal) | Popis | Efekty | Version(GitHub) |
|---|---|---|---|
| Pro flexibilní servery PostgreSQL by měl být zřízen správce Microsoft Entra. | Audit zřizování správce Microsoft Entra pro flexibilní server PostgreSQL, aby bylo možné povolit ověřování Microsoft Entra. Ověřování Microsoft Entra umožňuje zjednodušenou správu oprávnění a centralizovanou správu identit uživatelů databáze a dalších služby Microsoft | AuditIfNotExists, zakázáno | 1.0.0 |
| Auditování s využitím PgAudit by mělo být povolené pro flexibilní servery PostgreSQL. | Tato zásada pomáhá auditovat všechny flexibilní servery PostgreSQL ve vašem prostředí, které není povolené používat pgaudit. | AuditIfNotExists, zakázáno | 1.0.0 |
| U flexibilních serverů PostgreSQL by se mělo povolit omezování připojení. | Tato zásada pomáhá auditovat všechny flexibilní servery PostgreSQL ve vašem prostředí bez povoleného omezování připojení. Toto nastavení umožňuje dočasné omezování připojení na IP adresu pro příliš mnoho chyb přihlášení neplatných hesel. | AuditIfNotExists, zakázáno | 1.0.0 |
| Nasazení nastavení diagnostiky pro flexibilní servery PostgreSQL do pracovního prostoru služby Log Analytics | Nasadí nastavení diagnostiky pro flexibilní servery PostgreSQL pro streamování do místního pracovního prostoru služby Log Analytics, když se vytvoří nebo aktualizuje jakékoli flexibilní servery PostgreSQL, u kterých chybí toto nastavení diagnostiky. | DeployIfNotExists, zakázáno | 1.0.0 |
| Pro flexibilní servery PostgreSQL by se měly protokolovat odpojení. | Tato zásada pomáhá auditovat všechny flexibilní servery PostgreSQL ve vašem prostředí bez povolení log_disconnections. | AuditIfNotExists, zakázáno | 1.0.0 |
| Vynucení připojení SSL by mělo být povolené pro flexibilní servery PostgreSQL | Azure Database for PostgreSQL podporuje připojení flexibilního serveru Azure Database for PostgreSQL k klientským aplikacím pomocí protokolu SSL (Secure Sockets Layer). Vynucení připojení SSL mezi flexibilním serverem vaší databáze a klientskými aplikacemi pomáhá chránit před útoky "man in the middle" šifrováním datového proudu mezi serverem a vaší aplikací. Tato konfigurace vynucuje, aby protokol SSL byl vždy povolený pro přístup k flexibilnímu serveru PostgreSQL. | AuditIfNotExists, zakázáno | 1.0.0 |
| U flexibilních serverů Azure Database for PostgreSQL by se mělo povolit geograficky redundantní zálohování. | Flexibilní servery Azure Database for PostgreSQL umožňují zvolit možnost redundance pro váš databázový server. Dá se nastavit na geograficky redundantní úložiště zálohování, ve kterém se data neukládají jenom v rámci oblasti, ve které je váš server hostovaný, ale replikuje se také do spárované oblasti a poskytuje možnost obnovení v případě selhání oblasti. Konfigurace geograficky redundantního úložiště pro zálohování je povolená pouze při vytváření serveru. | Audit, zakázáno | 1.0.0 |
| Pro flexibilní servery PostgreSQL by měly být povolené kontrolní body protokolů. | Tato zásada pomáhá auditovat všechny flexibilní servery PostgreSQL ve vašem prostředí bez povolení log_checkpoints nastavení. | AuditIfNotExists, zakázáno | 1.0.0 |
| U flexibilních serverů PostgreSQL by se měla povolit připojení protokolů. | Tato zásada pomáhá auditovat všechny flexibilní servery PostgreSQL ve vašem prostředí bez povolení log_connections nastavení. | AuditIfNotExists, zakázáno | 1.0.0 |
| Servery PostgreSQL FlexIble by měly k šifrování neaktivních uložených dat používat klíče spravované zákazníkem. | Používejte klíče spravované zákazníkem ke správě šifrování neaktivních uložených flexibilních serverů PostgreSQL. Ve výchozím nastavení se neaktivní uložená data šifrují pomocí klíčů spravovaných službou, ale klíče spravované zákazníkem se běžně vyžadují ke splnění standardů dodržování právních předpisů. Klíče spravované zákazníkem umožňují šifrování dat pomocí klíče služby Azure Key Vault vytvořeného a vlastněného vámi. Máte plnou kontrolu nad klíčovým životním cyklem, včetně obměně a správy. | Audit, Odepřít, Zakázáno | 1.0.0 |
| Flexibilní servery PostgreSQL by měly používat protokol TLS verze 1.2 nebo novější. | Tato zásada pomáhá auditovat všechny flexibilní servery PostgreSQL ve vašem prostředí, které běží s protokolem TLS verze menší než 1.2. | AuditIfNotExists, zakázáno | 1.0.0 |
| Pro flexibilní servery PostgreSQL by se měl povolit privátní koncový bod. | Připojení privátního koncového bodu vynucují zabezpečenou komunikaci povolením privátního připojení ke službě Azure Database for PostgreSQL. Konfigurace připojení privátního koncového bodu pro povolení přístupu k provozu přicházejícímu jenom ze známých sítí a zabránění přístupu ze všech ostatních IP adres, včetně v rámci Azure | AuditIfNotExists, zakázáno | 1.0.0 |
Vlastní definice zásad
Vlastní zásady se dají přesně přizpůsobit tak, aby odpovídaly konkrétním požadavkům vaší organizace, včetně jedinečných zásad zabezpečení nebo mandátů dodržování předpisů. Díky vlastním zásadám máte úplnou kontrolu nad logikou a parametry zásad, což umožňuje sofistikované a jemně odstupňované definice zásad.