Freigeben über

Sicherheit in Azure Database for PostgreSQL – Flexible Server

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexibler Server

Zum Schutz der Daten auf Ihrer Azure Database for PostgreSQL – Flexibler Server-Instanz gibt es mehrere Sicherheitsebenen. In diesem Artikel werden diese Sicherheitsoptionen beschrieben.

Da Organisationen zunehmend auf daten angewiesen sind, die in Datenbanken gespeichert sind, um wichtige Entscheidungsaktivitäten zu fördern, die den Wettbewerbsvorteil steigern, ist die Notwendigkeit solider Datenbanksicherheitsmaßnahmen nie wichtiger gewesen. Ein Sicherheitsausfall kann katastrophale Folgen auslösen, darunter das Offenlegen vertraulicher Daten, was zu Reputationsschäden bei der Organisation führt.

Informationsschutz und -verschlüsselung

Azure Database for PostgreSQL – Flexibler Server verschlüsselt Daten auf zwei Arten:

  • Daten während der Übertragung: Azure Database for PostgreSQL – Flexibler Server verschlüsselt Daten während der Übertragung mit Secure Sockets Layer und Transport Layer Security (SSL/TLS). Verschlüsselung wird standardmäßig erzwungen. Ausführlichere Informationen zur Verbindungssicherheit mit SSL\TLS finden Sie in dieser Dokumentation. Um eine bessere Sicherheit zu erzielen, können Sie SCRAM-Authentifizierung in Azure Database for PostgreSQL – Flexibler Server aktivieren.

    Obwohl sehr davon abgeraten wird, haben Sie bei Bedarf aufgrund der Inkompatibilität mit älteren Clients die Möglichkeit, TLS/SSL für Verbindungen mit Azure Database for PostgreSQL – Flexibler Server zu deaktivieren, indem Sie den Serverparameter require_secure_transport auf OFF festlegen. Sie können die TLS-Version auch über die ssl_max_protocol_version-Serverparameter festlegen.

  • Ruhende Daten: Für die Speicherverschlüsselung verwendet Azure Database for PostgreSQL – Flexibler Server das FIPS 140-2-zertifizierte Kryptografiemodul. Daten werden auf dem Datenträger verschlüsselt, einschließlich Sicherungen und der temporären Dateien, die während der Ausführung von Abfragen erstellt wurden.

    Der Dienst verwendet den Modus Galois/Counter Mode (GCM) mit dem in der Azure Storage-Verschlüsselung enthaltenen AES-256-Bit-Verschlüsselungsverfahren, und die Schlüssel werden vom System verwaltet. Dies ähnelt anderen Verschlüsselungstechnologien für ruhende Daten wie Transparent Data Encryption in SQL Server- oder Oracle-Datenbanken. Die Speicherverschlüsselung ist immer aktiviert und kann nicht deaktiviert werden.

Netzwerksicherheit

Wenn Sie Azure Database for PostgreSQL – Flexible Server ausführen, haben Sie zwei Hauptoptionen für das Netzwerk:

  • Privater Zugriff: Sie können Ihren Server in einem virtuellen Azure-Netzwerk bereitstellen. Virtuelle Azure-Netzwerke ermöglichen eine private und sichere Netzwerkkommunikation. Ressourcen in einem virtuellen Netzwerk können über private IP-Adressen kommunizieren. Weitere Informationen finden Sie unter Übersicht über den Netzwerkbetrieb bei Azure Database for PostgreSQL – Flexible Server.

    Mit Sicherheitsregeln in Netzwerksicherheitsgruppen können Sie den Typ des ein- und ausgehenden Netzwerkdatenverkehrs von Subnetzen virtueller Netzwerke und Netzwerkschnittstellen filtern. Weitere Informationen finden Sie in der Übersicht über Netzwerksicherheitsgruppen.

  • Öffentlicher Zugriff: Auf den Server kann über einen öffentlichen Endpunkt zugegriffen werden. Der öffentliche Endpunkt ist eine öffentlich auflösbare DNS-Adresse. Der Zugriff darauf wird durch eine Firewall geschützt, die alle Verbindungen standardmäßig blockiert.

    IP-Firewallregeln gewähren Serverzugriff auf der Grundlage der Ursprungs-IP-Adresse der jeweiligen Anforderung. Weitere Informationen finden Sie in der Übersicht über Firewallregeln.

Support bei Microsoft Defender für Cloud

Microsoft Defender für relationale Open-Source-Datenbanken erkennt anomale Aktivitäten, die auf ungewöhnliche und potenziell schädliche Zugriffsversuche auf Datenbanken oder Datenbankexploits hinweisen. Defender for Cloud bietet Sicherheitswarnungen zu anomalen Aktivitäten, damit Sie potenzielle Bedrohungen erkennen und darauf reagieren können, sobald sie auftreten. Wenn Sie diesen Plan aktivieren, gibt Defender for Cloud Warnungen aus, sobald ein anomaler Datenbankzugriff und anomale Abfragemuster sowie verdächtige Datenbankaktivitäten erkannt werden.

Diese Warnungen werden auf der Seite mit Sicherheitswarnungen von Defender für Cloud angezeigt und umfassen Folgendes:

  • Details zur verdächtigen Aktivität, die die Warnung ausgelöst hat
  • Die zugehörige MITRE ATT&CK-Taktik
  • Empfohlene Aktionen zur weiteren Untersuchung und Behandlung der Bedrohung
  • Optionen zum Fortsetzen Ihrer Untersuchungen mit Microsoft Sentinel

Microsoft Defender for Cloud und Brute-Force-Angriffe

Ein Brute-Force-Angriff gehört zu den häufigsten und ziemlich erfolgreichen Hacking-Methoden, obwohl es die am wenigsten raffinierte Hacking-Methoden ist. Die Theorie hinter einem solchen Angriff ist, dass Sie bei einer unendlichen Anzahl von Versuchen, ein Kennwort zu erraten, zwangsläufig irgendwann richtig liegen werden. Wenn Microsoft Defender for Cloud einen Brute-Force-Angriff erkennt, löst es eine Warnung aus, um Sie darauf aufmerksam zu machen, dass ein Brute-Force-Angriff stattgefunden hat. Es kann auch einfache Brute-Force-Angriffe von einem Brute-Force-Angriff auf einen gültigen Benutzer oder einem erfolgreichen Brute-Force-Angriff unterscheiden.

Um Warnungen vom Microsoft Defender-Plan zu erhalten, müssen Sie ihn zunächst wie im nächsten Bereich beschrieben aktivieren.

Aktivieren der erweiterten Sicherheit mit Microsoft Defender for Cloud

  1. Navigieren Sie im Azure-Portal zum Menü „Sicherheit“ im linken Bereich.
  2. Wählen Sie Microsoft Defender for Cloud aus.
  3. Wählen Sie im rechten Bereich Aktivieren aus.

Screenshot: Aktivieren von Cloud Defender im Azure-Portal.

Hinweis

Wenn das Feature für „relationale Open-Source-Datenbanken“ in Ihrem Microsoft Defender-Plan aktiviert ist, werden Sie feststellen, dass Microsoft Defender standardmäßig für Ihre Ressource für Azure Database for PostgreSQL – Flexibler Server aktiviert wird.

Zugriffsverwaltung

Die beste Methode, um Datenbankzugriffsberechtigungen für Azure Database for PostgreSQL – Flexibler Server im großen Stil zu verwalten, ist das Konzept der Rollen. Eine Rolle kann entweder ein Datenbankbenutzer oder eine Gruppe von Datenbankbenutzern sein. Rollen können die Datenbankobjekte besitzen und anderen Rollen Berechtigungen für diese Objekte zuweisen, um zu steuern, wer Zugriff auf welche Objekte hat. Auch ist es möglich, eine Rolle zum Mitglied einer anderen Rolle zu machen, sodass die Mitgliedsrolle Berechtigungen nutzen kann, die einer anderen Rolle zugewiesen sind. Mit Azure Database for PostgreSQL – Flexibler Server können Sie den Datenbankbenutzer*innen Berechtigungen direkt erteilen. Aus Sicherheitsgründen empfiehlt es sich, basierend auf den mindestens erforderlichen Anwendungs- und Zugriffsanforderungen Rollen mit spezifischen Berechtigungen zu erstellen. Anschließend können Sie den einzelnen Benutzern jeweils die entsprechenden Rollen zuweisen. Mithilfe von Rollen wird der Zugriff auf Datenbankobjekte mit einem Modell mit geringstmöglichen Berechtigungen erzwungen.

Die Instanz von Azure Database for PostgreSQL – Flexibler Server wird zusätzlich zu den integrierten Rollen, die von PostgreSQL erstellt werden, mit den drei definierten Standardrollen erstellt. Sie können diese Rollen durch Ausführung des folgenden Befehls anzeigen: .

SELECT rolname FROM pg_roles;

Die Rollen sind unten aufgeführt:

  • azure_pg_admin
  • azuresu
  • Administratorrolle

Während Sie die Azure Database for PostgreSQL –Flexibler Server-Instanz erstellen, geben Sie Anmeldeinformationen für eine Administratorrolle ein. Diese Administratorrolle kann zum Erstellen weiterer PostgreSQL-Rollen genutzt werden.

Im Folgenden können Sie beispielsweise eine*n Benutzer*in/Rolle mit dem Namen demouser erstellen,


 CREATE USER demouser PASSWORD password123;

Die Administratorrolle sollte niemals von der Anwendung verwendet werden.

In cloudbasierten PaaS-Umgebungen ist der Zugriff auf ein Azure Database for PostgreSQL – Flexibler Server Superuser-Konto nur auf Vorgänge auf der Steuerungsebene durch Cloudbetreiber beschränkt. Daher ist das Konto azure_pg_admin als Pseudo-Superuser-Konto vorhanden. Die Administratorrolle ist ein Mitglied der Rolle azure_pg_admin.
Das Serveradministratorkonto ist jedoch nicht Teil der Rolle azuresu, die über Superuser-Rechte verfügt und zum Ausführen von Steuerungsebenenvorgängen verwendet wird. Da dieser Dienst ein verwalteter PaaS-Dienst ist, ist nur Microsoft Mitglied der Superuser-Rolle.

Sie können die Liste mit den Rollen auf Ihrem Server in regelmäßigen Abständen überprüfen. Beispielsweise können Sie eine Verbindung herstellen, indem Sie den psql-Client verwenden, und die Tabelle pg_roles abfragen, in der alle Rollen und die zugehörigen Berechtigungen (z. B. andere Rollen erstellen, Datenbanken erstellen, Replikation usw.) aufgeführt sind.


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

Wichtig

Kürzlich wurde die Möglichkeit geschaffen, CAST-Befehle in Azure Database for PostgreSQL – Flexibler Server zu erstellen. Zur Ausführung der CREATE CAST-Anweisung muss der Benutzer Mitglied der Gruppe azure_pg_admin sein. Bitte beachten Sie, dass es derzeit nicht möglich ist, ein CAST nach dem Erstellen zu löschen.

Für Azure Database for PostgreSQL – Flexibler Server ist auch die Überwachungsprotokollierung in Azure Database for PostgreSQL – Flexibler Server verfügbar, um Aktivitäten in Ihren Datenbanken nachverfolgen zu können.

Steuern des Schemazugriffs

Neu erstellte Datenbanken in Azure Database for PostgreSQL – Flexibler Server verfügen über einen Standardsatz von Berechtigungen im öffentlichen Schema der Datenbank, der es allen Datenbankbenutzer*innen und -rollen ermöglicht, Objekte zu erstellen. Um den Zugriff von Anwendungsbenutzer*innen auf die Datenbanken, die Sie auf Ihrer Azure Database for PostgreSQL – Flexibler Server-Instanz erstellen, besser einzuschränken, empfehlen wir, dass Sie in Erwägung ziehen, diese öffentlichen Standardberechtigungen zu widerrufen. Danach können Sie den Datenbankbenutzer*innen auf einer differenzierteren Basis bestimmte Berechtigungen erteilen. Beispiel:

  • Um zu verhindern, dass Benutzer*innen der Anwendungsdatenbank Objekte im öffentlichen Schema erstellen, entziehen Sie für das Schema public der Rolle public die Berechtigung zum Erstellen.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Als Nächstes erstellen Sie eine neue Datenbank.

    CREATE DATABASE Test_db;

  • Widerrufen Sie alle Berechtigungen aus dem PUBLIC-Schema für diese neue Datenbank.

    REVOKE ALL ON DATABASE Test_db FROM PUBLIC;

  • Erstellen einer benutzerdefinierten Rolle für Anwendungsdatenbankbenutzer*innen

    CREATE ROLE Test_db_user;

  • Geben Sie Datenbankbenutzer*innen mit dieser Rolle die Möglichkeit, sich mit der Datenbank zu verbinden.

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

  • Erstellen von Datenbankbenutzer*innen

    CREATE USER user1 PASSWORD 'Password_to_change'

  • Weisen Sie den Benutzer*innen eine Rolle mit den entsprechenden Verbindungs- und Auswahlberechtigungen zu.

    GRANT Test_db_user TO user1;

In diesem Beispiel kann user1 eine Verbindung herstellen und verfügt in unserer Testdatenbank Test_db über alle Berechtigungen, aber in keiner anderen Datenbank auf dem Server. Es wäre ferner empfehlenswert, statt diesem Benutzer\dieser Rolle ALLE BERECHTIGUNGEN für diese Datenbank und ihre Objekte zu gewähren, selektivere Berechtigungen wie SELECT, INSERT, EXECUTE usw. zu erteilen. Weitere Informationen zu Berechtigungen in PostgreSQL-Datenbanken finden Sie in der PostgreSQL-Dokumentation zu den Befehlen GRANT und REVOKE.

Änderungen des öffentlichen Schemabesitzes in PostgreSQL 15

Ab Version 15 wurde der Besitz des öffentlichen Schemas in die neue pg_database_owner Rolle geändert. Es ermöglicht jedem Datenbankbesitzer, das öffentliche Schema der Datenbank zu besitzen.
Weitere Informationen finden Sie in den Versionshinweisen zu PostgreSQL.

PostgreSQL 16-Änderungen mit rollenbasierter Sicherheit

In der PostgreSQL-Datenbank kann eine Rolle viele Attribute haben, die ihre Privilegien definieren. Eines dieser Attribute ist das Attribut CREATEROLE, das für die Verwaltung von Benutzerkonten und Rollen in der PostgreSQL-Datenbank wichtig ist. In PostgreSQL 16 wurden erhebliche Änderungen an diesem Attribut eingeführt. In PostgreSQL 16 haben Benutzer*innen mit dem Attribut CREATEROLE nicht mehr die Möglichkeit, die Mitgliedschaft in einer beliebigen Rolle an irgendjemanden zu vergeben. Stattdessen können sie, wie andere Benutzer*innen ohne dieses Attribut, nur Mitgliedschaften in Rollen vergeben, für die sie die ADMIN-OPTION besitzen. Außerdem erlaubt das Attribut CREATEROLE in PostgreSQL 16 einem Nicht-Superuser immer noch, neue Benutzerkonten bereitzustellen, allerdings kann er bzw. sie nur Benutzerkonten löschen, die er bzw. sie selbst erstellt hat. Der Versuch, Benutzerkonten zu löschen, die nicht von einem Benutzer bzw. einer Benutzerin mit dem Attribut CREATEROLE erstellt wurden, führt zu einem Fehler.

In PostgreSQL 16 wurden auch neue und verbesserte integrierte Rollen eingeführt. Die neue Rolle pg_use_reserved_connections in PostgreSQL 16 ermöglicht die Verwendung von Verbindungsplätzen über „reserved_connections“. Die Rolle pg_create_subscription ermöglicht es Superuser*innen, Abonnements zu erstellen.

Wichtig

Azure Database for PostgreSQL - Flexible Server erlaubt es nicht, dass Benutzern das Attribut pg_write_all_data gewährt wird, das es ihnen erlaubt, alle Daten (Tabellen, Ansichten, Sequenzen) zu schreiben, als ob sie INSERT-, UPDATE- und DELETE-Rechte auf diese Objekte und USAGE-Rechte auf alle Schemas hätten, auch wenn dies nicht ausdrücklich gewährt wurde. Als Problemumgehung wird empfohlen, ähnliche Berechtigungen auf einer endlicheren Ebene pro Datenbank und Objekt zu erteilen.

Sicherheit auf Zeilenebene

Die Sicherheit auf Zeilenebene (Row Level Security, RLS) ist ein Sicherheitsfeature von Azure Database for PostgreSQL – Flexibler Server, mit dem Datenbankadministrator*innen Richtlinien definieren können, um zu steuern, wie bestimmte Datenzeilen für eine oder mehrere Rollen angezeigt und ausgeführt werden. Die Sicherheit auf Zeilenebene ist ein zusätzlicher Filter, den Sie auf eine Datenbanktabelle von Azure Database for PostgreSQL – Flexibler Server anwenden können. Wenn ein Benutzer versucht, eine Aktion für eine Tabelle auszuführen, wird dieser Filter vor den Abfragekriterien oder einer anderen Filterung angewendet, und die Daten werden gemäß Ihrer Sicherheitsrichtlinie eingeschränkt oder abgelehnt. Sie können Sicherheitsrichtlinien auf Zeilenebene für bestimmte Befehle wie SELECT, INSERT, UPDATE und DELETE erstellen und für ALLE Befehle angeben. Anwendungsfälle für die Sicherheit auf Zeilenebene umfassen PCI-konforme Implementierungen, klassifizierte Umgebungen sowie Anwendungen mit freigegebenem Hosting oder mehreren Instanzen.

Nur Benutzerinnen und Benutzer mit Rechten vom Typ SET ROW SECURITY können Zeilensicherheitsrechte auf eine Tabelle anwenden. Die Tabellenbesitzerin bzw. der Tabellenbesitzer könnte die Zeilensicherheit für eine Tabelle festlegen. Wie OVERRIDE ROW SECURITY ist dies derzeit ein implizites Recht. Die Sicherheit auf Zeilenebene überschreibt keine vorhandenen GRANT-Berechtigungen, sondern ermöglicht eine feiner abgestufte Steuerung. Wenn Sie beispielsweise ROW SECURITY FOR SELECT festlegen, um einem bestimmten Benutzer bzw. einer bestimmten Benutzerin das Angeben von Zeilen zu erlauben, erhält diese*r Benutzer*in nur Zugriff, wenn er bzw. sie auch über SELECT-Berechtigungen für die betreffende Spalte oder Tabelle verfügt.

Das folgende Beispiel zeigt, wie Sie eine Richtlinie erstellen, die sicherstellt, dass nur Mitglieder der benutzerdefinierten erstellten Rolle Manager ausschließlich auf die Zeilen für ein bestimmtes Konto zugreifen können. Der Code im folgenden Beispiel wurde in der PostgreSQL-Dokumentation veröffentlicht.

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

Die USING-Klausel fügt implizit eine WITH CHECK-Klausel hinzu. Dadurch wird sichergestellt, dass Mitglieder der Rolle „Manager“ keine SELECT-,DELETE- oder UPDATE-Vorgänge für Zeilen ausführen können, die zu anderen Managerinnen oder Managern gehören. Außerdem können Sie keine INSERT-Vorgänge für neue Zeilen ausführen, die einem anderen Manager bzw. einer anderen Managerin gehören. Sie können eine Zeilensicherheitsrichtlinie mithilfe des Befehls DROP POLICY löschen, wie in diesem Beispiel:



DROP POLICY account_managers ON accounts;

Auch wenn Sie die Richtlinie möglicherweise gelöscht haben, kann der Rollen-Manager weiterhin keine Daten anzeigen, die zu einem anderen Manager gehören. Dies liegt daran, dass die Sicherheitsrichtlinie auf Zeilenebene in der Kontentabelle weiterhin aktiviert ist. Wenn die Sicherheit auf Zeilenebene standardmäßig aktiviert ist, verwendet PostgreSQL eine Richtlinie der standardmäßigen Verweigerung. Sie können die Sicherheit auf Zeilenebene deaktivieren, wie im nachstehenden Beispiel gezeigt:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Umgehen der Sicherheit auf Zeilenebene

PostgreSQL verfügt über BYPASSRLS- und NOBYPASSRLS-Berechtigungen, die einer Rolle zugewiesen werden können. NOBYPASSRLS wird standardmäßig zugewiesen. Bei neu bereitgestellten Servern in Azure Database for PostgreSQL Flexible Server wird die Berechtigung zum Umgehen der Sicherheit auf Zeilenebene (BYPASSRLS) wie folgt implementiert:

  • Für Server mit Postgres 16 und höheren Versionen wird Standardverhalten von PostgreSQL 16 angewendet. Von der Administratorrolle azure_pg_admin erstellte Benutzer ohne Administratorberechtigung ermöglichen es Ihnen, bei Bedarf Rollen mit BYPASSRLS-Attribut\-Berechtigung zu erstellen.
  • Für Server mit Postgres 15 und niedrigeren Versionen können Sie das Benutzerkonto azure_pg_admin verwenden, um Verwaltungsaufgaben auszuführen, die BYPASSRLS-Berechtigungen erfordern. Es ist jedoch nicht möglich, Benutzerkonten ohne Administratorberechtigung mit der BypassRLS-Berechtigung zu erstellen, da die Administratorrolle wie bei cloudbasierten PaaS-PostgreSQL-Diensten üblicherweise nicht über Superuserberechtigungen verfügt.

Aktualisieren von Kennwörtern

Eine bewährte Methode zur Erhöhung der Sicherheit besteht darin, Ihr Administratorkennwort und die Kennwörter für Datenbankbenutzerkonten regelmäßig zu rotieren. Wir empfehlen Ihnen, sichere Kennwörter mit Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen zu verwenden.

Verwenden von SCRAM

Der Salted Challenge Response Authentication Mechanism (SCRAM) verbessert die Sicherheit der kennwortbasierten Benutzerauthentifizierung erheblich, indem er mehrere wichtige Sicherheitsfunktionen hinzufügt, die Rainbow-Table-Angriffe, Man-in-the-Middle-Angriffe und Angriffe mit gespeicherten Kennwörtern verhindern und gleichzeitig Unterstützung für mehrere Hashalgorithmen und Kennwörter bieten, die Nicht-ASCII-Zeichen enthalten.

Bei der SCRAM-Authentifizierung nimmt der Client an der Verschlüsselungsarbeit teil, um den Identitätsnachweis zu erzeugen. Die SCRAM-Authentifizierung lagert also einige der Berechnungskosten an die Clients aus, in den meisten Fällen Anwendungsserver. Die Übernahme von SCRAM bietet daher zusätzlich zu einem stärkeren Hashalgorithmus auch Schutz vor verteilten Denial-of-Service-Angriffen (DDoS) gegen PostgreSQL, indem eine CPU-Überladung des Servers zum Berechnen von Kennworthashes verhindert wird.

Wenn Ihr Clienttreiber SCRAM unterstützt, können Sie Zugriff auf Azure Database for PostgreSQL – Flexible Server mithilfe von SCRAM als scram-sha-256 im Vergleich zum Standard md5 einrichten.

Zurücksetzen des Administratorkennworts

Befolgen Sie die Anleitung zum Zurücksetzen des Administratorkennworts.

Aktualisieren eines Kennworts für Datenbankbenutzer

Sie können Clienttools verwenden, um die Kennwörter von Datenbankbenutzern zu aktualisieren.
Beispiel:

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Azure Policy-Unterstützung

Azure Policy unterstützt Sie bei der Durchsetzung von Organisationsstandards und der Bewertung der Compliance im großen Stil. Über sein Compliance-Dashboard bietet der Dienst eine aggregierte Ansicht zur Bewertung des Gesamtzustands der Umgebung mit der Möglichkeit, einen Drilldown zur Granularität pro Ressource und Richtlinie durchzuführen. Außerdem trägt er durch Massenwartung für vorhandene Ressourcen und automatische Wartung dazu bei, dass Ihre Ressourcen Compliance-Anforderungen erfüllen.

Integrierte Richtliniendefinitionen

Integrierte Richtlinien werden von Microsoft entwickelt und getestet, um sicherzustellen, dass sie gängige Standards und Best Practices erfüllen und schnell bereitgestellt werden, ohne dass zusätzliche Konfiguration erforderlich ist, wodurch sie ideal für Standardcomplianceanforderungen geeignet sind. Integrierte Richtlinien decken häufig allgemein anerkannte Standards und Complianceframeworks ab.

Der folgende Abschnitt enthält einen Index der integrierten Azure Policy-Richtliniendefinitionen für Azure Database for PostgreSQL – Flexible Server. Verwenden Sie den Link in der Spalte Quelle, um die Quelle im Azure Policy-GitHub-Repository anzuzeigen

Name (Azure-Portal) Beschreibung Auswirkungen Version (GitHub)
Ein Microsoft Entra-Administrator sollte für flexible PostgreSQL-Server bereitgestellt werden. Überprüfen Sie die Bereitstellung von Microsoft Entra-Administratoren für Ihren flexiblen PostgreSQL-Server, um die Microsoft Entra-Authentifizierung zu aktivieren. Die Microsoft Entra-Authentifizierung ermöglicht eine vereinfachte Berechtigungsverwaltung und eine zentralisierte Identitätsverwaltung von Datenbankbenutzer*innen und anderen Microsoft-Diensten. AuditIfNotExists, Disabled 1.0.0
Die Überwachung mit PgAudit sollte für flexible PostgreSQL-Server aktiviert sein. Mit dieser Richtlinie können flexible PostgreSQL-Server in Ihrer Umgebung überwacht werden, bei denen die Verwendung von pgaudit nicht möglich ist. AuditIfNotExists, Disabled 1.0.0
Die Verbindungsdrosselung muss für flexible PostgreSQL-Server aktiviert sein Mit dieser Richtlinie können Sie überwachen, ob für alle flexiblen PostgreSQL-Server in Ihrer Umgebung die Verbindungsdrosselung aktiviert ist. Diese Einstellung aktiviert die temporäre Verbindungsdrosselung pro IP-Adresse bei zu vielen Anmeldefehlern aufgrund ungültiger Kennwörter. AuditIfNotExists, Disabled 1.0.0
Diagnoseeinstellungen für flexible PostgreSQL-Server in Log Analytics-Arbeitsbereich bereitstellen Hiermit werden die Diagnoseeinstellungen für flexible PostgreSQL-Server zum Streamen in einen regionalen Log Analytics-Arbeitsbereich bereitgestellt, wenn flexible PostgreSQL-Server erstellt oder aktualisiert werden, auf denen diese Diagnoseeinstellungen fehlen. DeployIfNotExists, Disabled 1.0.0
Verbindungstrennungen sollten für flexible PostgreSQL-Server protokolliert werden Mit dieser Richtlinie können flexible PostgreSQL-Server in Ihrer Umgebung überwacht werden, ohne dass „log_disconnections“ aktiviert ist. AuditIfNotExists, Disabled 1.0.0
Erzwingen einer SSL-Verbindung sollte für flexible PostgreSQL-Server aktiviert sein Azure Database for PostgreSQL unterstützt das Herstellen einer Verbindung zwischen Ihrem Azure Database for PostgreSQL - flexibler Server und Clientanwendungen unter Verwendung von Secure Sockets Layer (SSL). Durch das Erzwingen von SSL-Verbindungen zwischen Ihrem flexiblen Datenbankserver und Ihren Clientanwendungen können Sie sich vor Man-in-the-Middle-Angriffen schützen, indem Sie den Datenstrom zwischen dem Server und Ihrer Anwendung verschlüsseln. Diese Konfiguration erzwingt, dass SSL für den Zugriff auf Ihren flexiblen PostgreSQL-Server immer aktiviert ist. AuditIfNotExists, Disabled 1.0.0
Georedundante Sicherung sollte für Azure Database for PostgreSQL - flexibler Server aktiviert sein Mit Azure Database for PostgreSQL - flexible Server können Sie die Redundanzoption für Ihren Datenbankserver auswählen. Sie kann auf einen georedundanten Sicherungsspeicher festgelegt werden, in dem die Daten nicht nur in der Region gespeichert werden, in der Ihr Server gehostet wird, sondern auch in eine gekoppelte Region repliziert werden, um die Wiederherstellungsoption bei einem Regionsausfall bereitzustellen. Das Konfigurieren von georedundantem Speicher für die Sicherung ist nur während der Erstellung des Servers zulässig. Audit, Disabled 1.0.0
Protokollprüfpunkte für flexible PostgreSQL-Datenbankserver müssen aktiviert sein Mit dieser Richtlinie können flexible PostgreSQL-Server in Ihrer Umgebung überwacht werden, ohne dass „log_checkpoints“ aktiviert ist. AuditIfNotExists, Disabled 1.0.0
Protokollverbindungen für flexible PostgreSQL-Server müssen aktiviert sein Mit dieser Richtlinie können flexible PostgreSQL-Server in Ihrer Umgebung überwacht werden, ohne dass „log_connections“ aktiviert ist. AuditIfNotExists, Disabled 1.0.0
Flexible PostgreSQL-Server sollten kundenseitig verwaltete Schlüssel zur Verschlüsselung ruhender Daten verwenden Verwenden Sie kundenseitig verwaltete Schlüssel, um die Verschlüsselung ruhender Daten Ihrer flexiblen PostgreSQL-Server zu verwalten. Standardmäßig werden die Daten im Ruhezustand mit dienstseitig verwalteten Schlüsseln verschlüsselt. Kundenseitig verwaltete Schlüssel sind jedoch häufig zur Einhaltung gesetzlicher Bestimmungen erforderlich. Mit kundenseitig verwalteten Schlüsseln können die Daten mit einem Azure Key Vault-Schlüssel verschlüsselt werden, der von Ihnen erstellt wird und sich in Ihrem Besitz befindet. Sie verfügen über die volle Kontrolle über und Verantwortung für den Schlüssellebenszyklus, einschließlich Rotation und Verwaltung. Audit, Deny, Disabled 1.0.0
Auf flexiblen PostgreSQL-Servern muss TLS-Version 1.2 oder höher ausgeführt werden. Mit dieser Richtlinie können flexible PostgreSQL-Server in Ihrer Umgebung überwacht werden, auf denen eine niedrigere Version als TLS 1.2 ausgeführt wird. AuditIfNotExists, Disabled 1.0.0
Privater Endpunkt sollte für flexible PostgreSQL-Server aktiviert sein Private Endpunktverbindungen erzwingen eine sichere Kommunikation durch das Aktivieren privater Konnektivität mit Azure Database for PostgreSQL. Konfigurieren Sie eine private Endpunktverbindung, um nur Zugriff auf Datenverkehr zu ermöglichen, der aus bekannten Netzwerken stammt, und Zugriff von allen anderen IP-Adressen, auch solchen in Azure, zu verhindern. AuditIfNotExists, Disabled 1.0.0

Benutzerdefinierte Richtliniendefinitionen

Benutzerdefinierte Richtlinien können exakt an die spezifischen Anforderungen Ihrer Organisation angepasst werden, einschließlich individueller Sicherheitsrichtlinien oder Compliancemandaten. Mit benutzerdefinierten Richtlinien haben Sie die vollständige Kontrolle über die Richtlinienlogik und -parameter, wodurch anspruchsvolle und differenzierte Richtliniendefinitionen möglich sind.

Zugehöriger Inhalt