Delen 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 gebruik van de GCM-modus (Galois/Counter Mode) met AES 256-bits codering die is opgenomen in Azure Storage-versleuteling en 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, naast ingebouwde rollen die PostgreSQL maakt. 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 andere 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

Belangrijk om te weten dat het aantal supergebruikersmachtigingen, zoals het maken van bepaalde impliciete casts met binaire coercible, niet beschikbaar zijn met Azure Database for PostgreSQL - Flexible Server, omdat azure_pg_admin de rol niet is afgestemd op machtigingen van postgreSQL-superuserrol. Een binaire coercible cast is een type cast waarvoor geen functie nodig is om de conversie uit te voeren, omdat de bron- en doeltypen dezelfde interne representatie Niet binaire coercible casts hebben, inclusief opties MET IN OUT en WITH FUNCTION worden ondersteund.

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.

Wijzigingen in het eigendom van openbare schema's in PostgreSQL 15

Vanaf Postgres versie 15 is het eigendom van het openbare schema gewijzigd in de nieuwe pg_database_owner-rol. Hiermee kan elke database-eigenaar eigenaar zijn van het openbare schema van de database.
Meer informatie vindt u in de releaseopmerkingen van PostgreSQL.

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.

Belangrijk

Met Azure Database for PostgreSQL - Flexible Server kunnen gebruikers geen pg_write_all_data kenmerk worden verleend, waardoor de gebruiker alle gegevens (tabellen, weergaven, reeksen) kan schrijven, alsof er rechten VOOR INSERT, UPDATE en DELETE zijn voor deze objecten, en gebruiksrechten voor alle schema's, zelfs zonder dat deze expliciet is verleend. Als tijdelijke oplossing wordt aanbevolen om vergelijkbare machtigingen toe te kennen op een meer eindig niveau per database en object.

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 waarin wordt getoond hoe u een beleid maakt 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 UPDATE DELETErijen 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 zijn gemaakt door azure_pg_admin beheerdersrol kunt u indien nodig rollen maken met bypassRLS-kenmerk\bevoegdheid.
  • 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

Ondersteuning voor Azure Policy

Azure Policy helpt bij het afdwingen van organisatiestandaarden en het beoordelen van naleving op schaal. Via het compliancedashboard biedt het een geaggregeerde weergave om de algehele status van de omgeving te evalueren, met de mogelijkheid om in te zoomen op de granulariteit per resource, per beleid. Hiermee kunt u ook zorgen voor compliance van uw resources via bulkherstel voor bestaande resources en automatisch herstel voor nieuwe resources.

Ingebouwde beleidsdefinities

Ingebouwde beleidsregels worden door Microsoft ontwikkeld en getest, zodat ze voldoen aan algemene standaarden en aanbevolen procedures, een snel worden geïmplementeerd zonder dat er extra configuratie nodig is, waardoor ze ideaal zijn voor standaardnalevingsvereisten. Ingebouwde beleidsregels hebben vaak betrekking op algemeen erkende standaarden en nalevingsframeworks.

De onderstaande sectie bevat een index van ingebouwde Azure Policy-beleidsdefinities voor Azure Database for PostgreSQL - Flexible Server. Gebruik de koppeling in de kolom Bron om de bron te bekijken in de Azure Policy GitHub-opslagplaats.

Naam (Azure Portal) Beschrijving Effect(en) Versie (GitHub)
Een Microsoft Entra-beheerder moet worden ingericht voor flexibele PostgreSQL-servers Controleer het inrichten van een Microsoft Entra-beheerder voor uw flexibele PostgreSQL-server om Microsoft Entra-verificatie in te schakelen. Microsoft Entra-verificatie maakt vereenvoudigd machtigingsbeheer en gecentraliseerd identiteitsbeheer van databasegebruikers en andere Microsoft-services AuditIfNotExists, uitgeschakeld 1.0.0
Controle met PgAudit moet zijn ingeschakeld voor Flexibele PostgreSQL-servers Dit beleid helpt bij het controleren van alle flexibele PostgreSQL-servers in uw omgeving, die niet is ingeschakeld voor het gebruik van pgaudit. AuditIfNotExists, uitgeschakeld 1.0.0
Verbindingsbeperking moet zijn ingeschakeld voor flexibele PostgreSQL-servers Dit beleid helpt bij het controleren van alle flexibele PostgreSQL-servers in uw omgeving zonder verbindingsbeperking ingeschakeld. Met deze instelling wordt tijdelijke verbindingsbeperking per IP ingeschakeld voor te veel ongeldige mislukte wachtwoordaanmelding AuditIfNotExists, uitgeschakeld 1.0.0
Diagnostische instellingen voor Flexibele PostgreSQL-servers implementeren in Log Analytics-werkruimte Hiermee worden de diagnostische instellingen voor flexibele PostgreSQL-servers geïmplementeerd om te streamen naar een regionale Log Analytics-werkruimte wanneer een PostgreSQL flexibele server, die deze diagnostische instelling ontbreekt, wordt gemaakt of bijgewerkt DeployIfNotExists, uitgeschakeld 1.0.0
Verbroken verbindingen moeten worden vastgelegd voor flexibele PostgreSQL-servers Dit beleid helpt bij het controleren van alle flexibele PostgreSQL-servers in uw omgeving zonder log_disconnections ingeschakeld AuditIfNotExists, uitgeschakeld 1.0.0
SSL-verbinding afdwingen moet zijn ingeschakeld voor flexibele PostgreSQL-servers Azure Database for PostgreSQL ondersteunt het verbinden van uw flexibele Azure Database for PostgreSQL-server met clienttoepassingen met ssl (Secure Sockets Layer). Het afdwingen van SSL-verbindingen tussen uw flexibele databaseserver en uw clienttoepassingen helpt bescherming te bieden tegen 'man in the middle'-aanvallen door de gegevensstroom tussen de server en uw toepassing te versleutelen. Deze configuratie dwingt af dat SSL altijd is ingeschakeld voor toegang tot uw flexibele PostgreSQL-server AuditIfNotExists, uitgeschakeld 1.0.0
Geografisch redundante back-up moet zijn ingeschakeld voor flexibele Azure Database for PostgreSQL-servers Met Flexibele Servers van Azure Database for PostgreSQL kunt u de redundantieoptie voor uw databaseserver kiezen. Deze kan worden ingesteld op een geografisch redundante back-upopslag waarin de gegevens niet alleen worden opgeslagen in de regio waar uw server wordt gehost, maar ook worden gerepliceerd naar een koppelde regio om een hersteloptie te bieden ingeval van storing in uw regio. Geografisch redundante opslag configureren voor back-up is alleen toegestaan tijdens het maken van de server Controle, uitgeschakeld 1.0.0
Logboekcontrolepunten moeten zijn ingeschakeld voor flexibele PostgreSQL-servers Dit beleid helpt bij het controleren van flexibele PostgreSQL-servers in uw omgeving zonder dat log_checkpoints instelling is ingeschakeld AuditIfNotExists, uitgeschakeld 1.0.0
Logboekverbindingen moeten zijn ingeschakeld voor flexibele PostgreSQL-servers Dit beleid helpt bij het controleren van flexibele PostgreSQL-servers in uw omgeving zonder dat log_connections instelling is ingeschakeld AuditIfNotExists, uitgeschakeld 1.0.0
PostgreSQL FlexIble-servers moeten door de klant beheerde sleutels gebruiken om data-at-rest te versleutelen Gebruik door de klant beheerde sleutels om de versleuteling at rest van uw flexibele PostgreSQL-servers te beheren. Standaard worden de gegevens in rust versleuteld met door de service beheerde sleutels, maar door de klant beheerde sleutels zijn doorgaans vereist om te voldoen aan nalevingsstandaarden voor regelgeving. Met door de klant beheerde sleutels kunnen de gegevens worden versleuteld met een Azure Key Vault-sleutel die door u is gemaakt en waarvan u eigenaar bent. U hebt volledige controle en verantwoordelijkheid voor de levenscyclus van de sleutel, inclusief rotatie en beheer Controleren, Weigeren, Uitgeschakeld 1.0.0
Flexibele PostgreSQL-servers moeten TLS-versie 1.2 of hoger uitvoeren Dit beleid helpt bij het controleren van alle flexibele PostgreSQL-servers in uw omgeving, die wordt uitgevoerd met TLS-versie kleiner dan 1.2 AuditIfNotExists, uitgeschakeld 1.0.0
Privé-eindpunt moet zijn ingeschakeld voor Flexibele PostgreSQL-servers Met privé-eindpuntverbindingen wordt beveiligde communicatie afgedwongen door middel van het inschakelen van privéconnectiviteit met Azure Database for PostgreSQL. Een privé-eindpuntverbinding configureren om toegang tot verkeer dat alleen afkomstig is van bekende netwerken in te schakelen en toegang vanaf alle andere IP-adressen, inclusief binnen Azure, te voorkomen AuditIfNotExists, uitgeschakeld 1.0.0

Aangepaste beleidsdefinities

Aangepaste beleidsregels kunnen nauwkeurig worden afgestemd op de specifieke vereisten van uw organisatie, inclusief uniek beveiligingsbeleid of nalevingsmandaten. Met aangepaste beleidsregels hebt u volledige controle over de beleidslogica en -parameters, waardoor geavanceerde en verfijnde beleidsdefinities mogelijk zijn.

Gerelateerde inhoud