Zugriffsverwaltung in Azure HorizonDB (Vorschau)

Die Verwaltung des Zugriffs auf Ihre Azure HorizonDB ist ein wichtiger Bestandteil der Aufrechterhaltung von Sicherheit und Compliance. In diesem Artikel wird erläutert, wie Sie PostgreSQL-Rollen und Azure-Features verwenden, um Berechtigungen zu steuern und bewährte Methoden für die Zugriffsverwaltung zu implementieren.

Rollenverwaltung

Die beste Möglichkeit, Azure HorizonDB-Datenbankzugriffsberechtigungen in großem Maßstab zu verwalten, ist die Verwendung des Konzepts 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. Sie können einer anderen Rolle die Mitgliedschaft in einer Rolle gewähren, wodurch die Mitgliedsrolle die einer anderen Rolle zugewiesenen Berechtigungen nutzen kann. Azure HorizonDB können Sie den Datenbankbenutzern Berechtigungen direkt erteilen. Erstellen Sie als bewährte Sicherheitspraxis Rollen mit bestimmten Berechtigungssätzen basierend auf minimalen Anwendungs- und Zugriffsanforderungen. Weisen Sie jedem Benutzer die entsprechenden Rollen zu. Verwenden Sie Rollen, um ein Least-Privilege-Modell für den Zugriff auf Datenbankobjekte zu erzwingen.

Zusätzlich zu den integrierten Rollen, die PostgreSQL erstellt, enthält der Azure HorizonDB-Cluster drei Standardrollen. Sie können diese Rollen anzeigen, indem Sie den folgenden Befehl ausführen:

SELECT rolname FROM pg_roles;

Die Rollen lauten:

  • azure_pg_admin
  • azuresu
  • administrator role

Wenn Sie den Azure HorizonDB-Cluster erstellen, geben Sie Anmeldeinformationen für einen administrator role an. Verwenden Sie diese administrator role Option, um weitere PostgreSQL-Rollen zu erstellen.

Sie können z. B. einen Benutzer oder eine Rolle mit dem Namen exampleusererstellen.

CREATE USER exampleuser PASSWORD password123;

Verwenden Sie die Administratorrolle nicht für die Anwendung.

In cloudbasierten PaaS-Umgebungen ist der Zugriff auf ein Azure HorizonDB-Superbenutzerkonto nur auf die Steuerung von Flugzeugvorgängen beschränkt. Die Rolle azuresu verfügt über Superuserberechtigungen, aber das Azure HorizonDB-Clusteradministratorkonto gehört nicht zur Rolle azuresu.

Die azure_pg_admin Rolle ist als Pseudo-Superbenutzerkonto vorhanden. Die Administratoranmeldung, die Sie beim Erstellen des Clusters konfiguriert haben, ist Mitglied der Rolle azure_pg_admin.

Sie können die Liste der Rollen in Ihrem Cluster regelmäßig überwachen.

Sie können beispielsweise mithilfe des psql Clients eine Verbindung herstellen und die pg_roles Tabelle abfragen, die alle Rollen zusammen mit Berechtigungen auflistet, z. B. andere Rollen erstellen, Datenbanken erstellen, Replikation usw. erstellen.

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

Important

mit Azure HorizonDB können Sie CAST-Befehle erstellen. Um die CREATE CAST Anweisung auszuführen, muss der Benutzer mitglied der azure_pg_admin Rolle sein. Derzeit können Sie ein CAST nicht löschen, nachdem Sie es erstellt haben.

Azure HorizonDB unterstützt nur CAST-Befehle, die die Optionen WITH FUNCTION und WITH INOUT verwenden. Die WITHOUT FUNCTION-Option wird nicht unterstützt.

Steuern des Schemazugriffs

Neu erstellte Datenbanken in Azure HorizonDB enthalten eine Standardgruppe von Berechtigungen im öffentlichen Schema der Datenbank, die allen Datenbankbenutzern und -rollen die Möglichkeit zum Erstellen von Objekten gewähren. Um den Anwendungsbenutzerzugriff auf die Datenbanken zu beschränken, die Sie in Ihrer Azure HorizonDB-Instanz erstellen, sollten Sie diese standardmäßigen öffentlichen Berechtigungen widerrufen. Nachdem Sie diese Berechtigungen widerrufen haben, gewähren Sie Datenbankbenutzern spezifische Berechtigungen auf genauerer Basis. Beispiel:

  • Widerrufen Sie das Erstellen von Berechtigungen für das public Schema aus der public Rolle, um zu verhindern, dass Anwendungsdatenbankbenutzer Objekte im öffentlichen Schema erstellen.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Erstellen Sie eine neue -Datenbank.

    CREATE DATABASE Test_db;

  • Alle Berechtigungen aus dem PUBLIC-Schema für diese neue Datenbank widerrufen.

    REVOKE ALL ON DATABASE Test_db FROM PUBLIC;

  • Erstellen Sie eine benutzerdefinierte Rolle für Anwendungsdatenbankbenutzer.

    CREATE ROLE Test_db_user;

  • Geben Sie Datenbankbenutzern mit dieser Rolle die Möglichkeit, eine Verbindung mit der Datenbank herzustellen.

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

  • Erstellen Sie einen Datenbankbenutzer.

    CREATE USER user1 PASSWORD 'Password_to_change'

  • Weisen Sie dem Benutzer die Rolle mit ihren Verbindungs- und Auswahlberechtigungen zu.

    GRANT Test_db_user TO user1;

In diesem Beispiel kann Benutzer benutzer1 eine Verbindung herstellen und verfügt über alle Berechtigungen in der Testdatenbank Test_db, jedoch keine andere Datenbank im Cluster. Anstatt diesem Benutzer oder dieser Rolle ALL PRIVILEGES für diese Datenbank und seine Objekte zuzuweisen, sollten Sie in Betracht ziehen, selektivere Berechtigungen wie SELECT, , INSERT, EXECUTEund andere bereitzustellen. Weitere Informationen zu Berechtigungen in PostgreSQL-Datenbanken finden Sie in den Grant - und REVOKE-Befehlen in den PostgreSQL-Dokumenten.

Änderungen des öffentlichen Schemabesitzes in Azure HorizonDB

In Azure HorizonDB ist das öffentliche Schema in allen unterstützten PostgreSQL-Versionen im Besitz der Rolle azure_pg_admin.

Verbesserte Steuerung für azure_pg_admin

In Azure HorizonDB ist die azure_pg_admin Rolle eine vom System verwaltete, eingeschränkte Rolle, die Sie nicht ändern können. Wenn Sie versuchen, sie zu ändern, z. B. indem Sie ihr eine andere Rolle zuweisen, erhalten Sie eine Fehlermeldung wie:

GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"

Diese Einschränkung ist ein integrierter Schutz, um Änderungen an kritischen Administrativen Rollen zu verhindern. Wenn Sie Berechtigungen oder Rollen zuweisen müssen, sollten Sie stattdessen eine benutzerdefinierte Rolle erstellen und dieser Rolle die erforderlichen Berechtigungen erteilen.

Azure HorizonDB verbessert die Funktionen der azure_pg_admin Rolle in allen PostgreSQL-Versionen. Mitglieder der azure_pg_admin Rolle können Rollen verwalten und auf Objekte zugreifen, die einer nicht eingeschränkten Rolle gehören, auch wenn diese Rollen auch Mitglieder von azure_pg_admin sind. Mit diesem Feature wird sichergestellt, dass Administrative Benutzer die einheitliche und umfassende Kontrolle über die Rollen- und Berechtigungsverwaltung beibehalten und eine nahtlose und zuverlässige Benutzererfahrung bieten, ohne dass ein Superuser-Zugriff erforderlich ist.

Important

Azure HorizonDB erlaubt nicht, Benutzern das Attribut pg_write_all_data zu gewähren, das es einem Benutzer ermöglicht, in alle Datenobjekte (Tabellen, Ansichten, Sequenzen) zu schreiben, als hätte er für diese Objekte die Rechte INSERT, UPDATE und DELETE sowie USAGE-Rechte für alle Schemas, auch wenn ihm dieses Attribut nicht explizit gewährt wurde. Als Problemumgehung wird empfohlen, ähnliche Berechtigungen auf einer granulareren Ebene pro Datenbank und Objekt zu gewähren.

Zeilenbasierte Sicherheit

Row-Level Security (RLS) ist ein Azure HorizonDB-Sicherheitsfeature, mit dem Datenbankadministratoren Richtlinien definieren können, die steuern, wie bestimmte Zeilen mit Daten für eine oder mehrere Rollen angezeigt und ausgeführt werden. Sicherheit auf Zeilenebene fügt einer Azure HorizonDB-Datenbanktabelle einen zusätzlichen Filter hinzu. Wenn ein Benutzer versucht, eine Aktion für eine Tabelle auszuführen, wird dieser Filter vor den Abfragekriterien oder anderen Filtern 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 oder sie für alle Befehle angeben. Anwendungsfälle für die Sicherheit auf Zeilenebene umfassen PCI-kompatible Implementierungen, klassifizierte Umgebungen und gemeinsam genutzte Hosting- oder Mehrinstanzenanwendungen.

Nur Benutzer mit SET ROW SECURITY Rechten können Zeilensicherheitsrechte auf eine Tabelle anwenden. Der Tabellenbesitzer kann die Zeilensicherheit für eine Tabelle festlegen. Wie OVERRIDE ROW SECURITY, ist dieses Recht derzeit ein implizites Recht. Die Sicherheit auf Zeilenebene setzt vorhandene GRANTBerechtigungen nicht außer Kraft. Dies fügt eine feiner abgestimmte Steuerungsebene hinzu. Beispielsweise gewährt die Einstellung ROW SECURITY FOR SELECT einem bestimmten Benutzer nur dann Zugriff auf Zeilen, wenn der Benutzer 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 Managerrolle nur auf die Zeilen für ein bestimmtes Konto zugreifen können. Der Code im folgenden Beispiel wird in der PostgreSQL-Dokumentation freigegeben.

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 und stellt so sicher, dass Mitglieder der Rolle „Manager“ keine SELECT-, DELETE- oder UPDATE-Vorgänge an Zeilen ausführen können, die anderen Managern gehören, und keine neuen Zeilen für einen anderen Manager INSERT können.

Sie können eine Zeilensicherheitsrichtlinie mit dem Befehl DROP POLICY löschen, wie im folgenden Beispiel gezeigt:

DROP POLICY account_managers ON accounts;

Obwohl Sie die Richtlinie möglicherweise entfernen, kann der Rollenmanager weiterhin keine Daten einsehen, die einem anderen Manager gehören. Diese Einschränkung besteht, da die Sicherheitsrichtlinie auf Zeilenebene weiterhin für die Tabelle „accounts“ aktiviert ist. Wenn die Sicherheit auf Zeilenebene standardmäßig aktiviert ist, verwendet PostgreSQL eine Standardverweigerungsrichtlinie.

Sie können die Sicherheit auf Zeilenebene deaktivieren, wie im folgenden Beispiel gezeigt:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Umgehen der Sicherheit auf Zeilenebene

PostgreSQL enthält BYPASSRLS und NOBYPASSRLS Berechtigungen, die Sie einer Rolle zuweisen können. Standardmäßig wird die NOBYPASSRLS Berechtigung zugewiesen. In Azure HorizonDB funktioniert das Umgehen von Sicherheitsberechtigungen auf Zeilenebene (BYPASSRLS) wie folgt:

  • Nichtadministrative Benutzer, die von der azure_pg_admin Administratorrolle erstellt wurden, können bei Bedarf Rollen mit dem Attribut oder den BYPASSRLS Berechtigungen erstellen.

  • Verwenden Sie den azure_pg_admin Benutzer, um administrative Aufgaben auszuführen, die die BYPASSRLS Berechtigung erfordern.

Verwandte Inhalte

  • Last updated on