Säkerhet i Azure Database for PostgreSQL – flexibel server
GÄLLER FÖR: 
Azure Database for PostgreSQL – flexibel server
Det finns flera säkerhetslager för att skydda data i din Azure Database for PostgreSQL – flexibel serverinstans. Den här artikeln beskriver de här säkerhetsalternativen.
Eftersom organisationer i allt högre grad förlitar sig på data som lagras i databaser för att driva viktiga beslutsaktiviteter som skapar konkurrensfördelar har behovet av solida databassäkerhetsåtgärder aldrig varit viktigare. Ett säkerhetsfel kan utlösa katastrofala konsekvenser, inklusive att exponera konfidentiella data, orsaka ryktesskador för organisationen.
Informationsskydd och kryptering
Azure Database for PostgreSQL – Flexibel server krypterar data på två sätt:
Data under överföring: Azure Database for PostgreSQL – Flexibel server krypterar data under överföring med Secure Sockets Layer och Transport Layer Security (SSL/TLS). Krypteringen är aktiverad som standard. Mer detaljerad information om anslutningssäkerhet med SSL\TLS finns i den här dokumentationen. För bättre säkerhet kan du välja att aktivera SCRAM-autentisering i Azure Database for PostgreSQL – flexibel server.
Även om det inte rekommenderas, om det behövs, på grund av inkompatibilitet för äldre klienter, kan du inaktivera TLS\SSL för anslutningar till Azure Database for PostgreSQL – flexibel server genom att uppdatera
require_secure_transportserverparametern till OFF. Du kan också ange TLS-version genom att angessl_max_protocol_versionserverparametrar.Vilande data: För lagringskryptering använder Azure Database for PostgreSQL – Flexibel server FIPS 140-2-verifierad kryptografimodul. Data krypteras på disken, inklusive säkerhetskopior och de temporära filer som skapas när du kör frågor.
Tjänsten använder GCM-läge (Galois/Counter Mode) med AES 256-bitars chiffer som ingår i Azure Storage-kryptering, och nycklarna hanteras av systemet. Det här liknar andra krypteringstekniker för vilande data, till exempel transparent datakryptering i SQL Server- eller Oracle-databaser. Lagringskrypteringen är alltid igång och kan inte inaktiveras.
Nätverkssäkerhet
När du kör Azure Database for PostgreSQL – flexibel server har du två huvudsakliga nätverksalternativ:
Privat åtkomst: Du kan distribuera servern i ett virtuellt Azure-nätverk. Virtuella Azure-nätverk ger dig en privat och säker nätverkskommunikation. Resurserna i ett virtuellt nätverk kan kommunicera via privata IP-adresser. Mer information finns i nätverksöversikten för Azure Database for PostgreSQL – flexibel server.
Med säkerhetsregler i nätverkssäkerhetsgrupper kan du filtrera vilken typ av nätverkstrafik som kan flöda in i och ut ur virtuella nätverk, undernät och nätverksgränssnitt. Mer information finns i översikten över nätverkssäkerhetsgrupper.
Offentlig åtkomst: Servern kan nås via en offentlig slutpunkt. Den offentliga slutpunkten är en DNS-adress som kan matchas offentligt. Åtkomst till den skyddas via en brandvägg som blockerar alla anslutningar som standard.
Du kan ge åtkomst till servrarna med IP-brandväggsregler som baseras på den IP-adress som varje förfrågan kommer från. Mer information finns i översikten över brandväggsregler.
Support för Microsoft Defender för molnet
Microsoft Defender för relationsdatabaser med öppen källkod identifierar avvikande aktiviteter som indikerar ovanliga och potentiellt skadliga försök att komma åt eller utnyttja databaser. Defender for Cloud tillhandahåller säkerhetsaviseringar om avvikande aktiviteter så att du kan identifiera potentiella hot och svara på dem när de inträffar. När du aktiverar den här planen tillhandahåller Defender för molnet aviseringar när den identifierar avvikande databasåtkomst och frågemönster och misstänkta databasaktiviteter.
De här aviseringarna visas på sidan Säkerhetsaviseringar i Defender för molnet och omfattar:
- Information om den misstänkta aktivitet som utlöste dem
- Den associerade MITRE ATT&CK-taktiken
- Rekommenderade åtgärder för att undersöka och minimera hotet
- Alternativ för att fortsätta dina undersökningar med Microsoft Sentinel
Microsoft Defender för molnet och råstyrkeattacker
En råstyrkeattack är bland de vanligaste och ganska framgångsrika hackningsmetoderna, trots att det är den minst sofistikerade hackningsmetoden. Teorin bakom en sådan attack är att om du tar ett oändligt antal försök att gissa ett lösenord, kommer du att ha rätt så småningom. När Microsoft Defender för molnet upptäcker en råstyrkeattack utlöser den en avisering för att göra dig medveten om att en råstyrkeattack har ägt rum. Den kan också separera en enkel råstyrkeattack från en råstyrkeattack på en giltig användare eller en lyckad råstyrkeattack.
Om du vill få aviseringar från Microsoft Defender-planen måste du först aktivera den som du ser i nästa avsnitt.
Aktivera förbättrad säkerhet med Microsoft Defender för molnet
- Från Azure-portalen går du till menyn Säkerhet i den vänstra rutan
- Välj Microsoft Defender för molnet
- Välj Aktivera i höger fönster.
Kommentar
Om du har funktionen "relationsdatabaser med öppen källkod" aktiverad i din Microsoft Defender-plan ser du att Microsoft Defender aktiveras automatiskt som standard för din flexibla serverresurs i Azure Database for PostgreSQL.
Åtkomsthantering
Det bästa sättet att hantera Åtkomstbehörigheter för Azure Database for PostgreSQL – flexibel serverdatabas i stor skala är att använda begreppet roller. En roll kan vara antingen en databasanvändare eller en grupp databasanvändare. Roller kan äga databasobjekten och tilldela behörigheter för dessa objekt till andra roller för att styra vem som har åtkomst till vilka objekt. Det är också möjligt att bevilja medlemskap i en roll till en annan roll, vilket gör att medlemsrollen kan använda privilegier som tilldelats till en annan roll. Med Azure Database for PostgreSQL – Flexibel server kan du bevilja behörigheter direkt till databasanvändare. Som en bra säkerhetspraxis kan du rekommendera att du skapar roller med specifika behörighetsuppsättningar baserat på minimikraven för program och åtkomst. Du kan sedan tilldela lämpliga roller till varje användare. Roller används för att framtvinga en modell med minst behörighet för åtkomst till databasobjekt.
Instansen Azure Database for PostgreSQL – flexibel server skapas med de tre definierade standardrollerna, förutom de inbyggda rollerna som PostgreSQL skapar. Du kan se dessa roller genom att köra kommandot:
SELECT rolname FROM pg_roles;
Rollerna visas nedan:
- azure_pg_admin
- azuresu
- administratörsroll
När du skapar Instansen Azure Database for PostgreSQL – flexibel server anger du autentiseringsuppgifter för en administratörsroll. Den här administratörsrollen kan användas till att skapa fler PostgreSQL-roller.
Nedan kan vi till exempel skapa en exempelanvändare/roll med namnet "demouser"
CREATE USER demouser PASSWORD password123;
Administratörsrollen bör aldrig användas av programmet.
I molnbaserade PaaS-miljöer begränsas åtkomsten till ett Azure Database for PostgreSQL – superanvändarkonto för flexibel server till att endast styra planåtgärder av molnoperatörer. Därför azure_pg_admin finns kontot som ett pseudo-superuser-konto. Din administratörsroll är medlem i azure_pg_admin rollen.
Serveradministratörskontot är dock inte en del av azuresu rollen, som har superanvändarbehörighet och används för att utföra kontrollplansåtgärder. Eftersom den här tjänsten är en hanterad PaaS-tjänst är endast Microsoft en del av superanvändarrollen.
Du kan regelbundet granska listan över roller på servern. Du kan till exempel ansluta med hjälp av psql klienten och köra frågor mot pg_roles tabellen, som visar alla roller tillsammans med behörigheter som att skapa andra roller, skapa databaser, replikering osv.
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
Viktigt!
Nyligen har vi aktiverat möjligheten att skapa CAST-kommandon i Azure Database for PostgreSQL – flexibel server. Tänk på att funktionen för närvarande fungerar som förväntat med undantag för DROP-instruktionen. Med andra ord är det för närvarande inte möjligt att släppa en CAST när den har skapats. Vi arbetar aktivt med att lägga till den här funktionen och förutser dess tillgänglighet inom en snar framtid.
Granskningsloggning i Azure Database for PostgreSQL – Flexibel server är också tillgänglig med Azure Database for PostgreSQL – flexibel server för att spåra aktivitet i dina databaser.
Kontrollera schemaåtkomst
Nyligen skapade databaser i Azure Database for PostgreSQL – Flexibel server har en standarduppsättning behörigheter i databasens offentliga schema som gör att alla databasanvändare och roller kan skapa objekt. För att bättre begränsa programanvändaråtkomsten till de databaser som du skapar i din Azure Database for PostgreSQL – flexibel serverinstans rekommenderar vi att du återkallar dessa offentliga standardprivilegier. När du har gjort det kan du sedan bevilja specifika behörigheter för databasanvändare på ett mer detaljerat sätt. Till exempel:
Om du vill förhindra att programdatabasanvändare skapar objekt i det offentliga schemat återkallar du skapa behörigheter för schema
publicfrånpublicroll.REVOKE CREATE ON SCHEMA public FROM PUBLIC;Skapa sedan en ny databas.
CREATE DATABASE Test_db;Återkalla alla behörigheter från PUBLIC-schemat för den nya databasen.
REVOKE ALL ON DATABASE Test_db FROM PUBLIC;Skapa en anpassad roll för programdatabasanvändare
CREATE ROLE Test_db_user;Ge databasanvändare med den här rollen möjlighet att ansluta till databasen.
GRANT CONNECT ON DATABASE Test_db TO Test_db_user; GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;Skapa databasanvändare
CREATE USER user1 PASSWORD 'Password_to_change'Tilldela roll, med dess anslutning och välj behörigheter till användaren
GRANT Test_db_user TO user1;
I det här exemplet kan användare user1 ansluta och har alla behörigheter i vår testdatabas Test_db, men inte någon annan databas på servern. Vi rekommenderar vidare, i stället för att ge den här användaren\rollen ALLA PRIVILEGIER för databasen och dess objekt, för att ge mer selektiva behörigheter, till exempel SELECT, INSERT, EXECUTE osv. Mer information om behörigheter i PostgreSQL-databaser finns i kommandona GRANT och REVOKE i PostgreSQL-dokumenten.
Ägarskapsändringar för offentligt schema i PostgreSQL 15
Från Postgres version 15 har ägarskapet för det offentliga schemat ändrats till den nya pg_database_owner rollen. Det gör att varje databasägare kan äga databasens offentliga schema.
Mer information finns i Viktig information om PostgreSQL.
PostgreSQL 16-ändringar med rollbaserad säkerhet
I PostgreSQL-databasrollen kan ha många attribut som definierar dess behörigheter. Ett sådant attribut är attributet CREATEROLE, vilket är viktigt för PostgreSQL-databashantering av användare och roller. I PostgreSQL introducerades 16 betydande ändringar i det här attributet. I PostgreSQL 16 har användare med CREATEROLE-attribut inte längre möjlighet att dela ut medlemskap i någon roll till vem som helst. I stället kan de, precis som andra användare, utan det här attributet bara dela ut medlemskap i roller som de har ADMINISTRATÖRSALTERNATIV för. I PostgreSQL 16 ger attributet CREATEROLE fortfarande en nonsuperuser möjlighet att etablera nya användare, men de kan bara släppa användare som de själva har skapat. Försök att släppa användare, som inte skapas av användare med CREATEROLE-attribut , resulterar i ett fel.
PostgreSQL 16 introducerade också nya och förbättrade inbyggda roller. Ny pg_use_reserved_connections roll i PostgreSQL 16 tillåter användning av anslutningsfack som reserverats via reserved_connections. Med pg_create_subscription roll kan superanvändare skapa prenumerationer.
Viktigt!
Azure Database for PostgreSQL – Flexibel server tillåter inte att användare beviljas pg_write_all_data attribut, vilket gör att användaren kan skriva alla data (tabeller, vyer, sekvenser), som om de har behörigheten INSERT, UPDATE och DELETE för dessa objekt och ANVÄNDNINGsrättigheter för alla scheman, även utan att uttryckligen beviljas. Som en lösning rekommenderas att bevilja liknande behörigheter på en mer begränsad nivå per databas och objekt.
Säkerhet på radnivå
Säkerhet på radnivå (RLS) är en säkerhetsfunktion för Azure Database for PostgreSQL – flexibel server som gör att databasadministratörer kan definiera principer för att styra hur specifika rader med data visas och fungerar för en eller flera roller. Säkerhet på radnivå är ytterligare ett filter som du kan använda för en Databastabell för Azure Database for PostgreSQL – flexibel server. När en användare försöker utföra en åtgärd i en tabell tillämpas det här filtret före frågevillkoren eller annan filtrering, och data begränsas eller avvisas enligt din säkerhetsprincip. Du kan skapa säkerhetsprinciper på radnivå för specifika kommandon som SELECT, INSERT, UPDATE och DELETE och ange dem för ALLA kommandon. Användningsfall för säkerhet på radnivå omfattar PCI-kompatibla implementeringar, klassificerade miljöer och delade värdprogram/program med flera klienter.
Endast användare med SET ROW SECURITY rättigheter kan använda radsäkerhetsrättigheter i en tabell. Tabellägaren kan ange radsäkerhet i en tabell. Detta OVERRIDE ROW SECURITY är för närvarande en implicit rättighet. Säkerhet på radnivå åsidosätter inte befintliga GRANT behörigheter. Den lägger till en finare kontrollnivå. Om du ROW SECURITY FOR SELECT till exempel anger att en viss användare ska kunna ge rader ger det bara användaren åtkomst om användaren också har SELECT behörighet för kolumnen eller tabellen i fråga.
Här är ett exempel som visar hur du skapar en princip som ser till att endast medlemmar i den anpassade rollen "manager" kan komma åt raderna för ett visst konto. Koden i följande exempel delades i PostgreSQL-dokumentationen.
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);
USING-satsen lägger implicit till en WITH CHECK -sats som säkerställer att medlemmar i chefsrollen inte kan utföra SELECT, DELETEeller UPDATE åtgärder på rader som tillhör andra chefer och inte INSERT kan nya rader som tillhör en annan chef.
Du kan släppa en radsäkerhetsprincip med hjälp av kommandot DROP POLICY, som i hans exempel:
DROP POLICY account_managers ON accounts;
Även om du kanske har tagit bort principen kan rollhanteraren fortfarande inte visa några data som tillhör någon annan chef. Det beror på att säkerhetsprincipen på radnivå fortfarande är aktiverad i kontotabellen. Om säkerhet på radnivå är aktiverat som standard använder PostgreSQL en standardprincip för nekande. Du kan inaktivera säkerhet på radnivå, som i exemplet nedan:
ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;
Kringgå säkerhet på radnivå
PostgreSQL har behörigheterna BYPASSRLS och NOBYPASSRLS , som kan tilldelas till en roll. NOBYPASSRLS tilldelas som standard. Med nyligen etablerade servrar i Azure Database for PostgreSQL – Flexibel server som kringgår säkerhetsprivilegier på radnivå (BYPASSRLS) implementeras på följande sätt:
- För Postgres 16 och senare versionerade servrar följer vi standardbeteendet PostgreSQL 16. Icke-administrativa användare som skapats av azure_pg_admin administratörsrollen gör att du kan skapa roller med BYPASSRLS-attribut\privilege efter behov.
- För Postgres 15- och underversionsservrar. kan du använda azure_pg_admin användare för att utföra administrativa uppgifter som kräver BYPASSRLS-behörighet, men som inte kan skapa icke-administratörsanvändare med BypassRLS-behörighet, eftersom administratörsrollen inte har några superanvändarbehörigheter, vilket är vanligt i molnbaserade PaaS PostgreSQL-tjänster.
Uppdatera lösenord
För bättre säkerhet är det en bra idé att regelbundet rotera administratörslösenord och lösenord för databasanvändare. Vi rekommenderar att du använder starka lösenord med hjälp av versaler och gemener, siffror och specialtecken.
Använda SCRAM
Scram (Salted Challenge Response Authentication Mechanism) förbättrar säkerheten för lösenordsbaserad användarautentisering avsevärt genom att lägga till flera viktiga säkerhetsfunktioner som förhindrar regnbågstabellattacker, man-in-the-middle-attacker och lagrade lösenordsattacker, samtidigt som stöd läggs till för flera hashalgoritmer och lösenord som innehåller icke-ASCII-tecken.
I SCRAM-autentisering deltar klienten i krypteringsarbetet för att skapa identitetsbeviset. SCRAM-autentisering avlastar därför en del av beräkningskostnaden till sina klienter, som i de flesta fall är programservrar. Genom att använda SCRAM, utöver en starkare hashalgoritm, erbjuds därför även skydd mot DDoS-attacker (Distributed Denial-of-Service) mot PostgreSQL genom att förhindra en CPU-överlagring av servern för att beräkna lösenordshashvärden.
Om klientdrivrutinen stöder SCRAM kan du konfigurera åtkomst till Azure Database for PostgreSQL – flexibel server med SCRAM som scram-sha-256 standard md5.
Återställa administratörslösenord
Följ guiden för att återställa administratörslösenordet.
Uppdatera databasanvändarlösenord
Du kan använda klientverktyg för att uppdatera databasanvändarlösenord.
Exempel:
ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE
Azure Policy-stöd
Azure Policy hjälper till att framtvinga organisationsstandarder och utvärdera efterlevnad i stor skala. Via dess instrumentpanel för efterlevnad finns en sammanställd vy för att utvärdera miljöns övergripande tillstånd, och du kan öka detaljnivån till per resurs och per princip. Du får också hjälp att säkerställa att resurserna efterlever kraven via massåtgärder för befintliga resurser och automatisk reparation för nya resurser.
Inbyggda principdefinitioner
Inbyggda principer utvecklas och testas av Microsoft, vilket säkerställer att de uppfyller vanliga standarder och bästa praxis, och distribueras snabbt utan att behöva ytterligare konfiguration, vilket gör dem idealiska för standardefterlevnadskrav. Inbyggda principer omfattar ofta allmänt erkända standarder och efterlevnadsramverk.
Avsnittet nedan innehåller ett index över inbyggda principdefinitioner i Azure Policy för Azure Database for PostgreSQL – flexibel server. Använd länken i kolumnen Källa för att visa källan på Azure Policy GitHub-lagringsplatsen.
| Namn (Azure Portal) | Beskrivning | Effekt(er) | Version(GitHub) |
|---|---|---|---|
| En Microsoft Entra-administratör bör etableras för flexibla PostgreSQL-servrar | Granska etableringen av en Microsoft Entra-administratör för din flexibla PostgreSQL-server för att aktivera Microsoft Entra-autentisering. Microsoft Entra-autentisering möjliggör förenklad behörighetshantering och centraliserad identitetshantering för databasanvändare och andra Microsoft usluge | AuditIfNotExists, inaktiverad | 1.0.0 |
| Granskning med PgAudit ska vara aktiverat för flexibla PostgreSQL-servrar | Den här principen hjälper dig att granska alla flexibla PostgreSQL-servrar i din miljö, som inte har aktiverats för att använda pgaudit. | AuditIfNotExists, inaktiverad | 1.0.0 |
| Anslutningsbegränsning ska vara aktiverat för flexibla PostgreSQL-servrar | Den här principen hjälper dig att granska alla flexibla PostgreSQL-servrar i din miljö utan att anslutningsbegränsning har aktiverats. Den här inställningen möjliggör tillfällig anslutningsbegränsning per IP-adress för för många ogiltiga lösenordsinloggningsfel | AuditIfNotExists, inaktiverad | 1.0.0 |
| Distribuera diagnostikinställningar för flexibla PostgreSQL-servrar till Log Analytics-arbetsytan | Distribuerar diagnostikinställningarna för flexibla PostgreSQL-servrar för att strömma till en regional Log Analytics-arbetsyta när några flexibla PostgreSQL-servrar, som saknar den här diagnostikinställningen, skapas eller uppdateras | DeployIfNotExists, inaktiverad | 1.0.0 |
| Frånkopplingar ska loggas för flexibla PostgreSQL-servrar | Den här principen hjälper dig att granska alla flexibla PostgreSQL-servrar i din miljö utan log_disconnections aktiverat | AuditIfNotExists, inaktiverad | 1.0.0 |
| Framtvinga SSL-anslutning ska vara aktiverat för flexibla PostgreSQL-servrar | Azure Database for PostgreSQL stöder anslutning av din flexibla Azure Database for PostgreSQL-server till klientprogram med hjälp av Secure Sockets Layer (SSL). Genom att framtvinga SSL-anslutningar mellan databasens flexibla server och klientprogrammen kan du skydda mot "man i mitten"-attacker genom att kryptera dataströmmen mellan servern och ditt program. Den här konfigurationen framtvingar att SSL alltid är aktiverat för åtkomst till din flexibla PostgreSQL-server | AuditIfNotExists, inaktiverad | 1.0.0 |
| Geo-redundant säkerhetskopiering bör aktiveras för flexibla Azure Database for PostgreSQL-servrar | Med Azure Database for PostgreSQL –flexibla servrar kan du välja redundansalternativet för databasservern. Den kan ställas in på en geo-redundant lagring där data inte bara lagras i den region där servern finns, utan också replikeras till en länkad region för att tillhandahålla återställningsalternativ vid ett regionfel. Konfiguration av geo-redundant lagring för säkerhetskopiering tillåts endast under serverskapande | Granskning, inaktiverad | 1.0.0 |
| Loggkontrollpunkter ska vara aktiverade för flexibla PostgreSQL-servrar | Den här principen hjälper dig att granska alla flexibla PostgreSQL-servrar i din miljö utan att log_checkpoints inställningen är aktiverad | AuditIfNotExists, inaktiverad | 1.0.0 |
| Logganslutningar ska vara aktiverade för flexibla PostgreSQL-servrar | Den här principen hjälper dig att granska alla flexibla PostgreSQL-servrar i din miljö utan att log_connections inställningen är aktiverad | AuditIfNotExists, inaktiverad | 1.0.0 |
| PostgreSQL FlexIble-servrar bör använda kundhanterade nycklar för att kryptera vilande data | Använd kundhanterade nycklar för att hantera krypteringen på resten av dina flexibla PostgreSQL-servrar. Som standard krypteras data i vila med tjänsthanterade nycklar, men kundhanterade nycklar krävs ofta för att uppfylla regelefterlevnadsstandarder. Med kundhanterade nycklar kan data krypteras med en Azure Key Vault-nyckel som skapas och ägs av dig. Du har fullständig kontroll och ansvar för nyckellivscykeln, inklusive rotation och hantering | Granska, neka, inaktiverad | 1.0.0 |
| Flexibla PostgreSQL-servrar ska köra TLS version 1.2 eller senare | Den här principen hjälper dig att granska alla flexibla PostgreSQL-servrar i din miljö, som körs med TLS-version mindre än 1.2 | AuditIfNotExists, inaktiverad | 1.0.0 |
| Privat slutpunkt ska vara aktiverad för flexibla PostgreSQL-servrar | Privata slutpunktsanslutningar framtvingar säker kommunikation genom att aktivera privat anslutning till Azure Database for PostgreSQL. Konfigurera en privat slutpunktsanslutning för att aktivera åtkomst till trafik som endast kommer från kända nätverk och förhindra åtkomst från alla andra IP-adresser, inklusive i Azure | AuditIfNotExists, inaktiverad | 1.0.0 |
Anpassade principdefinitioner
Anpassade principer kan skräddarsys exakt för att matcha organisationens specifika krav, inklusive unika säkerhetsprinciper eller efterlevnadsmandat. Med anpassade principer har du fullständig kontroll över principlogik och parametrar, vilket möjliggör avancerade och detaljerade principdefinitioner.