Sicherheit in Azure Database for PostgreSQL – Flexible Server

Artikel
04/22/2024

GILT FÜR: Azure Database for PostgreSQL – Flexible 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.

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 das in der Azure Storage-Verschlüsselung enthaltene 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

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

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 Azure Database for PostgreSQL – Flexibler Server-Instanz wird erstellt und verfügt über die drei definierten Standardrollen. Sie können diese Rollen durch Ausführung des folgenden Befehls anzeigen: .

SELECT rolname FROM pg_roles;

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,

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

Hinweis

Eine Reihe von Superuser-Berechtigungen, wie z.B. die Erstellung bestimmter impliziter Rollen, sind mit Azure Database for PostgreSQL – Flexibler Server nicht verfügbar, da die Rolle azure_pg_admin nicht mit den Berechtigungen der PostgreSQL-Superuser-Rolle übereinstimmt.

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. zusätzliche Rollen erstellen, Datenbanken erstellen, Replikation usw., aufgeführt sind.

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

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.

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.

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 den Benutzer azure_pg_admin verwenden, um Verwaltungsaufgaben auszuführen, die BYPASSRLS-Berechtigungen erfordern. Es ist jedoch nicht möglich, Benutzer ohne Administratorberechtigung mit der BypassRLS-Berechtigung zu erstellen, da die Administratorrolle wie bei cloudbasierten PaaS-PostgreSQL-Diensten üblich 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.

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:

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