Säkerhet i Azure Database for PostgreSQL – flexibel server

Artikel
04/25/2024

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.

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_transport serverparametern till OFF. Du kan också ange TLS-version genom att ange ssl_max_protocol_version serverparametrar.
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 det chiffer med AES 256 bitar som ingår i Azures lagringskryptering, 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.

stöd 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 för molnet tillhandahåller säkerhetsaviseringar för 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 standardrollerna definierade. Du kan se dessa roller genom att köra kommandot:

SELECT rolname FROM pg_roles;

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,

postgres=> 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.

Kommentar

Antalet behörigheter som endast används för superanvändare, till exempel skapande av vissa implicita casts, är inte tillgängliga med Azure Database for PostgreSQL – flexibel server, eftersom azure_pg_admin rollen inte överensstämmer med behörigheter för PostgreSQL-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 ytterligare roller, skapa databaser, replikering osv.

postgres=> \x
Expanded display is on.
postgres=> 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

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 public från public roll.
```
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.

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.

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 endast ser till att medlemmar i den anpassade rollen "manager" bara 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. Med icke-administrativa användare som skapats av azure_pg_admin administratörsroll kan du 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 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.

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:

postgres=> ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE