Share via

Beveiliging in Azure Database for PostgreSQL - Flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Er zijn meerdere beveiligingslagen beschikbaar om de gegevens op uw Azure Database for PostgreSQL - Flexible Server-exemplaar te beveiligen. In dit artikel worden deze beveiligingsopties beschreven.

Omdat organisaties steeds vaker vertrouwen op gegevens die zijn opgeslagen in databases om kritieke besluitvormingsactiviteiten te stimuleren die concurrentievoordeel opleveren, is de behoefte aan solide databasebeveiligingsmaatregelen nog nooit belangrijker geweest. Een beveiligingsverloop kan catastrofale gevolgen veroorzaken, waaronder het blootstellen van vertrouwelijke gegevens, waardoor reputatieschade aan de organisatie ontstaat.

Gegevensbeveiliging en -versleuteling

Azure Database for PostgreSQL - Flexible Server versleutelt gegevens op twee manieren:

  • Gegevens die onderweg zijn: Azure Database for PostgreSQL - Flexible Server versleutelt in-transitgegevens met Secure Sockets Layer en Transport Layer Security (SSL/TLS). Versleuteling wordt standaard afgedwongen. Raadpleeg deze documentatie voor meer gedetailleerde informatie over de beveiliging van verbindingen met SSL\TLS. Voor betere beveiliging kunt u ervoor kiezen om SCRAM-verificatie in te schakelen in Azure Database for PostgreSQL - Flexible Server.

    Hoewel het ten zeerste niet wordt aanbevolen, indien nodig, vanwege incompatibiliteit van verouderde clients, kunt u TLS\SSL uitschakelen voor verbindingen met Azure Database for PostgreSQL - Flexible Server door de require_secure_transport serverparameter bij te werken naar UIT. U kunt ook tls-versie instellen door serverparameters in te stellen ssl_max_protocol_version .

  • Data-at-rest: Voor opslagversleuteling maakt Azure Database for PostgreSQL - Flexible Server gebruik van de door FIPS 140-2 gevalideerde cryptografische module. Gegevens op de schijf worden versleuteld, inclusief back-ups en de tijdelijke bestanden die zijn gemaakt terwijl query's worden uitgevoerd.

    De service maakt gebruikt van AES 256-bits versleuteling die deel uitmaakt van Azure Storage-versleuteling. De sleutels worden door het systeem beheerd. Dit is vergelijkbaar met andere versleutelingsmethoden voor data-at-rest, zoals transparante gegevensversleuteling in SQL Server of Oracle-databases. Opslagversleuteling is altijd actief en kan niet worden uitgeschakeld.

Netwerkbeveiliging

Wanneer u Azure Database for PostgreSQL - flexibele server uitvoert, hebt u twee belangrijke netwerkopties:

  • Privétoegang: u kunt uw server implementeren in een virtueel Azure-netwerk. In virtuele Azure-netwerken kunt u gebruikmaken van privé- en beveiligde netwerkcommunicatie. Resources in een virtueel netwerk kunnen communiceren via privé-IP-adressen. Zie het netwerkoverzicht voor Azure Database for PostgreSQL - Flexible Server voor meer informatie.

    Met beveiligingsregels in netwerkbeveiligingsgroepen kunt u filteren op het type netwerkverkeer dat van en naar subnetten van virtuele netwerken en netwerkinterfaces kan stromen. Zie het overzicht van netwerkbeveiligingsgroepen voor meer informatie.

  • Openbare toegang: de server is toegankelijk via een openbaar eindpunt. Het openbare eindpunt is een openbaar omzetbaar DNS-adres. Toegang tot de app wordt beveiligd via een firewall die standaard alle verbindingen blokkeert.

    Met de IP-firewallregels wordt toegang verleend tot servers op basis van het IP-adres waar de aanvraag vandaan komt. Zie het overzicht van firewallregels voor meer informatie.

Microsoft Defender voor Cloud ondersteuning

Microsoft Defender voor opensource-relationele databases detecteert afwijkende activiteiten die duiden op ongebruikelijke en mogelijk schadelijke pogingen om toegang te krijgen tot of misbruik te maken van databases. Defender voor Cloud biedt beveiligingswaarschuwingen voor afwijkende activiteiten, zodat u potentiële bedreigingen kunt detecteren en erop kunt reageren wanneer ze optreden. Wanneer u dit plan inschakelt, geeft Defender voor Cloud waarschuwingen wanneer afwijkende databasetoegang en querypatronen en verdachte databaseactiviteiten worden gedetecteerd.

Deze waarschuwingen worden weergegeven op de pagina beveiligingswaarschuwingen van Defender voor Cloud en omvatten:

  • Details van de verdachte activiteit die hen heeft geactiveerd
  • De bijbehorende MITRE ATT&CK-tactiek
  • Aanbevolen acties voor het onderzoeken en beperken van de bedreiging
  • Opties voor het voortzetten van uw onderzoeken met Microsoft Sentinel

Microsoft Defender voor Cloud en beveiligingsaanvallen

Een beveiligingsaanval is een van de meest voorkomende en redelijk succesvolle hackmethoden, ondanks dat het minst geavanceerde hackmethoden zijn. De theorie achter een dergelijke aanval is dat als u een oneindig aantal pogingen neemt om een wachtwoord te raden, u uiteindelijk gelijk hebt. Wanneer Microsoft Defender voor Cloud een beveiligingsaanval detecteert, wordt er een waarschuwing geactiveerd om u bewust te maken van een beveiligingsaanval. Het kan ook een eenvoudige beveiligingsaanval scheiden van beveiligingsaanval op een geldige gebruiker of een geslaagde beveiligingsaanval.

Als u waarschuwingen wilt ontvangen van het Microsoft Defender-abonnement, moet u dit eerst inschakelen, zoals wordt weergegeven in de volgende sectie.

Verbeterde beveiliging inschakelen met Microsoft Defender voor Cloud

  1. Navigeer vanuit Azure Portal naar het menu Beveiliging in het linkerdeelvenster
  2. Kies Microsoft Defender voor Cloud
  3. Selecteer Inschakelen in het rechterdeelvenster.

Schermopname van Azure Portal waarin wordt getoond hoe u Cloud Defender inschakelt.

Notitie

Als u de functie 'opensource relationele databases' hebt ingeschakeld in uw Microsoft Defender-abonnement, ziet u dat Microsoft Defender automatisch is ingeschakeld voor uw flexibele Server-resource van Azure Database for PostgreSQL.

Toegangsbeheer

De beste manier om azure Database for PostgreSQL - Flexible Server-databasetoegangsmachtigingen op schaal te beheren, is het gebruik van het concept van rollen. Een rol kan een databasegebruiker of een groep databasegebruikers zijn. Rollen kunnen eigenaar zijn van de databaseobjecten en bevoegdheden voor deze objecten toewijzen aan andere rollen om te bepalen wie toegang heeft tot welke objecten. Het is ook mogelijk om lidmaatschap van een rol toe te kennen aan een andere rol, zodat de lidrol bevoegdheden kan gebruiken die aan een andere rol zijn toegewezen. Met Azure Database for PostgreSQL - Flexible Server kunt u rechtstreeks machtigingen verlenen aan de databasegebruikers. Als een goede beveiligingspraktijk kunt u het beste rollen maken met specifieke sets machtigingen op basis van minimale toepassings- en toegangsvereisten. Vervolgens kunt u de juiste rollen toewijzen aan elke gebruiker. Rollen worden gebruikt om een model met minimale bevoegdheden af te dwingen voor toegang tot databaseobjecten.

Het Azure Database for PostgreSQL - Flexible Server-exemplaar wordt gemaakt met de drie standaardrollen die zijn gedefinieerd. U kunt deze rollen zien door de opdracht uit te voeren:

SELECT rolname FROM pg_roles;

De rollen worden hieronder vermeld:

  • azure_pg_admin
  • azuresu
  • beheerdersrol

Terwijl u het exemplaar van Azure Database for PostgreSQL - Flexible Server maakt, geeft u referenties op voor een beheerdersrol. Deze beheerdersrol kan worden gebruikt om meer PostgreSQL-rollen te maken.

Hieronder kunnen we bijvoorbeeld een voorbeeld van een gebruiker/rol met de naam demouser maken


 CREATE USER demouser PASSWORD password123;

De beheerdersrol mag nooit door de toepassing worden gebruikt.

In paaS-omgevingen in de cloud is toegang tot een Superuser-account van Azure Database for PostgreSQL - Flexible Server beperkt tot besturingsvlakbewerkingen alleen door cloudoperators. Daarom bestaat het azure_pg_admin account als een pseudo-superuser-account. Uw beheerdersrol is lid van de azure_pg_admin rol.
Het beheerdersaccount van de server maakt echter geen deel uit van de azuresu rol, die supergebruikersbevoegdheden heeft en wordt gebruikt om besturingsvlakbewerkingen uit te voeren. Omdat deze service een beheerde PaaS-service is, maakt alleen Microsoft deel uit van de rol van supergebruiker.

U kunt regelmatig de lijst met functies op uw server controleren. U kunt bijvoorbeeld verbinding maken met behulp van psql de client en een query uitvoeren op de pg_roles tabel, waarin alle rollen samen met bevoegdheden worden vermeld, zoals het maken van extra rollen, het maken van databases, replicatie, enzovoort.


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

Belangrijk om te weten dat het aantal supergebruikersmachtigingen, zoals het maken van bepaalde impliciete casts, niet beschikbaar zijn voor Azure Database for PostgreSQL - Flexible Server, omdat azure_pg_admin de rol niet is afgestemd op machtigingen van de postgreSQL-superuserrol.

Auditlogboekregistratie in Azure Database for PostgreSQL - Flexible Server is ook beschikbaar met Azure Database for PostgreSQL - Flexible Server om activiteiten in uw databases bij te houden.

Schematoegang beheren

Nieuw gemaakte databases in Azure Database for PostgreSQL - Flexible Server hebben een standaardset bevoegdheden in het openbare schema van de database waarmee alle databasegebruikers en -rollen objecten kunnen maken. Als u de toegang van gebruikers van toepassingen wilt beperken tot de databases die u maakt op uw Exemplaar van Azure Database for PostgreSQL - Flexible Server, wordt u aangeraden deze standaard openbare bevoegdheden in te schakelen. Daarna kunt u specifieke bevoegdheden voor databasegebruikers op een gedetailleerdere basis verlenen. Voorbeeld:

  • Als u wilt voorkomen dat gebruikers van toepassingsdatabases objecten maken in het openbare schema, trekt u de bevoegdheden voor public het schema van public de rol in.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Maak vervolgens een nieuwe database.

    CREATE DATABASE Test_db;

  • Alle bevoegdheden van het OPENBARE schema voor deze nieuwe database intrekken.

    REVOKE ALL ON DATABASE Test_db FROM PUBLIC;

  • Aangepaste rol maken voor gebruikers van toepassingsdatabases

    CREATE ROLE Test_db_user;

  • Geef databasegebruikers met deze rol de mogelijkheid om verbinding te maken met de database.

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

  • Databasegebruiker maken

    CREATE USER user1 PASSWORD 'Password_to_change'

  • Rol toewijzen, met de bijbehorende verbinding en bevoegdheden selecteren voor de gebruiker

    GRANT Test_db_user TO user1;

In dit voorbeeld kan gebruiker gebruiker1 verbinding maken en heeft alle bevoegdheden in onze testdatabase Test_db, maar geen andere db op de server. Het wordt verder aanbevolen, in plaats van deze gebruiker\rol ALLE BEVOEGDHEDEN voor die database en de bijbehorende objecten te geven, om meer selectieve machtigingen te bieden, zoals SELECT, INSERT, EXECUTE, enzovoort. Zie de opdrachten GRANT en REVOKE in de PostgreSQL-documenten voor meer informatie over bevoegdheden in PostgreSQL-databases.

PostgreSQL 16-wijzigingen met beveiliging op basis van rollen

In postgreSQL-databaserol kunnen veel kenmerken hebben die de bevoegdheden definiëren. Een dergelijk kenmerk is het kenmerk CREATEROLE, wat belangrijk is voor het beheer van postgreSQL-databases van gebruikers en rollen. In PostgreSQL 16 zijn belangrijke wijzigingen geïntroduceerd in dit kenmerk. In PostgreSQL 16 kunnen gebruikers met het kenmerk CREATEROLE geen lidmaatschap meer uitdelen aan iedereen. In plaats daarvan kunnen gebruikers met het kenmerk CREATEROLE alleen lidmaatschappen uitdelen waarvoor ze beheerdersoptie hebben. In PostgreSQL 16 biedt het kenmerk CREATEROLE nog steeds de mogelijkheid om nieuwe gebruikers in te richten, maar ze kunnen alleen gebruikers verwijderen die ze zelf hebben gemaakt. Pogingen om gebruikers, die niet door de gebruiker met het kenmerk CREATEROLE worden gemaakt, te verwijderen, leiden tot een fout.

PostgreSQL 16 heeft ook nieuwe en verbeterde ingebouwde rollen geïntroduceerd. Nieuwe pg_use_reserved_connections rol in PostgreSQL 16 maakt het gebruik van verbindingssites mogelijk die zijn gereserveerd via reserved_connections. Met de rol pg_create_subscription kunnen supergebruikers abonnementen maken.

Beveiliging op rijniveau

Beveiliging op rijniveau (RLS) is een Azure Database for PostgreSQL - Flexible Server-beveiligingsfunctie waarmee databasebeheerders beleidsregels kunnen definiëren om te bepalen hoe specifieke rijen met gegevens worden weergegeven en worden gebruikt voor een of meer rollen. Beveiliging op rijniveau is een extra filter dat u kunt toepassen op een Database for PostgreSQL - Flexible Server-databasetabel. Wanneer een gebruiker een actie op een tabel probeert uit te voeren, wordt dit filter toegepast vóór de querycriteria of andere filters en worden de gegevens beperkt of geweigerd volgens uw beveiligingsbeleid. U kunt beveiligingsbeleid op rijniveau maken voor specifieke opdrachten, zoals SELECT, INSERT, UPDATE en DELETE, en deze opgeven voor ALLE opdrachten. Use cases for row level security include PCI compliant implementations, classified environments, and shared hosting /multitenant applications.

Alleen gebruikers met SET ROW SECURITY rechten kunnen rijbeveiligingsrechten toepassen op een tabel. De eigenaar van de tabel kan rijbeveiliging instellen voor een tabel. Dit OVERRIDE ROW SECURITY is momenteel een impliciet recht. Beveiliging op rijniveau overschrijft geen bestaande GRANT machtigingen, maar voegt een nauwkeuriger besturingselementniveau toe. Als u bijvoorbeeld wilt instellen ROW SECURITY FOR SELECT dat een bepaalde gebruiker rijen geeft, krijgt die gebruiker alleen toegang als de gebruiker ook bevoegdheden heeft SELECT voor de kolom of tabel in kwestie.

Hier volgt een voorbeeld van het maken van een beleid dat ervoor zorgt dat alleen leden van de aangepaste rol Manager toegang hebben tot de rijen voor een specifiek account. De code in het volgende voorbeeld is gedeeld in de PostgreSQL-documentatie.

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);

Met de USING-component wordt impliciet een WITH CHECK component toegevoegd, zodat leden van de managerrol geen bewerkingen kunnen uitvoeren op UPDATEDELETErijen die deel uitmaken van andere managers en geen INSERT nieuwe rijen kunnen toevoegen SELECTdie behoren tot een andere manager. U kunt een rijbeveiligingsbeleid verwijderen met behulp van de opdracht DROP POLICY, zoals in zijn voorbeeld:



DROP POLICY account_managers ON accounts;

Hoewel u het beleid mogelijk hebt verwijderd, kan rolbeheerder nog steeds geen gegevens bekijken die deel uitmaken van een andere manager. Dit komt doordat het beveiligingsbeleid op rijniveau nog steeds is ingeschakeld in de tabel Accounts. Als beveiliging op rijniveau standaard is ingeschakeld, gebruikt PostgreSQL een standaardbeleid voor weigeren. U kunt beveiliging op rijniveau uitschakelen, zoals in het onderstaande voorbeeld:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Beveiliging op rijniveau omzeilen

PostgreSQL heeft BYPASSRLS - en NOBYPASSRLS-machtigingen , die kunnen worden toegewezen aan een rol; NOBYPASSRLS is standaard toegewezen. Met nieuw ingerichte servers in Azure Database for PostgreSQL - Flexible Server die beveiligingsbevoegdheden op rijniveau (BYPASSRLS) overslaan, wordt als volgt geïmplementeerd:

  • Voor Postgres 16- en hoger versiebeheerservers volgen we het standaardgedrag van PostgreSQL 16. Niet-beheerdersrechten die door azure_pg_admin beheerdersrol zijn gemaakt, kunt u indien nodig rollen maken met bypassRLS-kenmerk\privilege.
  • Voor Postgres 15 en lager versiebeheerservers. , kunt u azure_pg_admin gebruiker gebruiken om beheertaken uit te voeren waarvoor BYPASSRLS-bevoegdheden zijn vereist, maar u kunt geen niet-beheerdersgebruikers maken met bypassRLS-bevoegdheden, omdat de beheerdersrol geen supergebruikersbevoegdheden heeft, zoals gebruikelijk in PaaS PostgreSQL-services in de cloud.

Wachtwoorden bijwerken

Voor een betere beveiliging is het een goed idee om uw beheerderswachtwoord en databasegebruikerswachtwoorden periodiek te roteren. Het is raadzaam sterke wachtwoorden te gebruiken met hoofdletters en kleine letters, cijfers en speciale tekens.

SCRAM gebruiken

Het Salted Challenge Response Authentication Mechanism (SCRAM) verbetert de beveiliging van gebruikersverificatie op basis van wachtwoorden aanzienlijk door verschillende belangrijke beveiligingsfuncties toe te voegen die regenboogtabelaanvallen, man-in-the-middle-aanvallen en opgeslagen wachtwoordaanvallen voorkomen, terwijl ook ondersteuning wordt toegevoegd voor meerdere hash-algoritmen en wachtwoorden die niet-ASCII-tekens bevatten.

Bij SCRAM-verificatie neemt de client deel aan het uitvoeren van het versleutelingswerk om het bewijs van identiteit te produceren. SCRAM-verificatie offload daarom een deel van de rekenkosten naar de clients, die in de meeste gevallen toepassingsservers zijn. Het aannemen van SCRAM, naast een sterker hash-algoritme, biedt daarom ook bescherming tegen DDoS-aanvallen (Distributed Denial of Service) tegen PostgreSQL, door een CPU-overbelasting van de server te voorkomen om wachtwoordhashes te berekenen.

Als uw clientstuurprogramma SCRAM ondersteunt, kunt u toegang tot Azure Database for PostgreSQL - Flexible Server instellen met behulp van SCRAM als scram-sha-256 standaard.md5

Beheerderswachtwoord opnieuw instellen

Volg de instructies voor het opnieuw instellen van het beheerderswachtwoord.

Wachtwoord van databasegebruiker bijwerken

U kunt clienthulpprogramma's gebruiken om wachtwoorden van databasegebruikers bij te werken.
Voorbeeld:

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Gerelateerde inhoud