Freigeben über

Zugriffsverwaltung für Azure-Datenbank für PostgreSQL

Die Verwaltung des Zugriffs auf Ihre Azure-Datenbank für PostgreSQL-Ressourcen 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 zum Verwalten von Azure Database for PostgreSQL-Datenbankzugriffsberechtigungen im großen Maßstab ist die Verwendung des Rollenkonzepts. 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 Mitgliedschaft in einer Rolle gewähren, wodurch die Mitgliedsrolle Berechtigungen verwenden kann, die einer anderen Rolle zugewiesen sind. Mit Azure Database for PostgreSQL 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 Am wenigsten rechtes Modell für den Zugriff auf Datenbankobjekte zu erzwingen.

Zusätzlich zu den integrierten Rollen, die PostgreSQL erstellt, enthält die Azure-Datenbank für PostgreSQL-Instanz 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
  • Administratorrolle

Wenn Sie die Azure-Datenbank für Die PostgreSQL-Instanz erstellen, geben Sie Anmeldeinformationen für eine Administratorrolle an. Verwenden Sie diese Administratorrolle, um weitere PostgreSQL-Rollen zu erstellen.

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

CREATE USER demouser PASSWORD password123;

Verwenden Sie die Administratorrolle nicht für die Anwendung.

In cloudbasierten PaaS-Umgebungen ist der Zugriff auf ein Azure-Datenbank für PostgreSQL-Superbenutzerkonto auf die Steuerung von Flugzeugvorgängen nur durch Cloudoperatoren beschränkt. Daher ist das azure_pg_admin Konto als Pseudo-Superuser-Konto vorhanden. Ihre Administratorrolle ist Ein Mitglied der azure_pg_admin Rolle. Das Serveradministratorkonto ist jedoch nicht Teil der azuresu Rolle, die über Superbenutzerberechtigungen verfügt und zum Ausführen von Steuerungsebenenvorgängen verwendet wird. Da dieser Dienst ein verwalteter PaaS-Dienst ist, ist nur Microsoft Teil der Superuser-Rolle.

Sie können die Liste der Rollen auf Ihrem Server 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

Von Bedeutung

In letzter Zeit ermöglichte Azure Database for PostgreSQL das Erstellen von CAST-Befehlen. Um die CREATE CAST-Anweisung auszuführen, muss der Benutzer Mitglied der gruppe azure_pg_admin sein. Derzeit können Sie nach dem Erstellen kein CAST ablegen.

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

Die Überwachungsprotokollierung in Der Azure-Datenbank für PostgreSQL ist auch mit Azure Database for PostgreSQL verfügbar, um Aktivitäten in Ihren Datenbanken nachzuverfolgen.

Steuern des Schemazugriffs

Neu erstellte Datenbanken in Azure Database for PostgreSQL enthalten einen Standardsatz 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-Datenbank für PostgreSQL-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 auf dem Server. 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 der Azure-Datenbank für PostgreSQL

In PostgreSQL 15 und höher wurde der Besitz des öffentlichen Schemas in die neue pg_database_owner Rolle geändert, wodurch Datenbankbesitzer sie kontrollieren können. Weitere Informationen finden Sie in den Versionshinweisen zu PostgreSQL. In der Azure-Datenbank für PostgreSQL gilt diese Änderung jedoch nicht. Das öffentliche Schema gehört der azure_pg_admin Rolle in allen unterstützten PostgreSQL-Versionen. Dieses verhalten des verwalteten Diensts bietet Sicherheit und Konsistenz.

PostgreSQL 16-Änderungen mit rollenbasierter Sicherheit

In PostgreSQL kann die Datenbankrolle viele Attribute aufweisen, die ihre Berechtigungen definieren. Ein solches Attribut ist das CREATEROLE-Attribut, das für die Datenbankverwaltung von Benutzern und Rollen von PostgreSQL wichtig ist. In PostgreSQL 16 wurden erhebliche Änderungen an diesem Attribut eingeführt.

In PostgreSQL 16 haben Benutzer mit dem CREATEROLE-Attribut nicht mehr die Möglichkeit, eine Mitgliedschaft in jeder Rolle an jeden zu verteilen. Stattdessen können sie wie andere Benutzer ohne dieses Attribut nur Mitgliedschaften in Rollen aushändigen, für die sie verfügen ADMIN OPTION. Außerdem ermöglicht das CREATEROLE-Attribut in PostgreSQL 16 immer noch einem Nichtsuperbenutzer die Möglichkeit, neue Benutzer bereitzustellen. Sie können jedoch nur Benutzer ablegen, die sie selbst erstellt haben. Versuche, Benutzer abzulegen, führen zu einem Fehler, wenn der Benutzer nicht von einem Benutzer mit dem CREATEROLE-Attribut erstellt wurde.

PostgreSQL 16 führt auch neue und verbesserte integrierte Rolle ein. Mit der rolle pg_create_subscription können Superuser Abonnements erstellen.

In Azure Database for PostgreSQL Flexible Server ist die azure_pg_admin Rolle eine vom System verwaltete, eingeschränkte Rolle und kann von Benutzern nicht geändert werden. Versuche, sie zu ändern, z. B. das Gewähren einer anderen Rolle, führt zu einem Fehler wie:


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

Dies 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.

Verbesserte Steuerung für azure_pg_admin

In PostgreSQL 16 wird eine strenge Rollenhierarchiestruktur für Benutzer mit den CREATEROLE-Berechtigungen implementiert, insbesondere im Zusammenhang mit der Erteilung von Rollen. Um die administrative Flexibilität zu verbessern und eine Einschränkung zu beheben, die in PostgreSQL 16 eingeführt wurde, verbessert Azure Database for PostgreSQL die Funktionen der azure_pg_admin Rolle in allen PostgreSQL-Versionen. Mit diesem Update können Mitglieder der rolle azure_pg_admin Rollen verwalten und auf Objekte zugreifen, die sich im Besitz einer nicht eingeschränkten Rolle befinden, auch wenn diese Rollen auch Mitglieder von azure_pg_admin sind. Durch diese Erweiterung wird sichergestellt, dass Administrative Benutzer konsistente und umfassende Kontrolle über die Rollen- und Berechtigungsverwaltung behalten, was eine nahtlose und zuverlässige Benutzererfahrung bietet, ohne dass ein Superuser-Zugriff erforderlich ist.

Von Bedeutung

Die Azure-Datenbank für PostgreSQL lässt es Benutzern nicht zu, pg_write_all_data Attribut zu erteilen, wodurch Benutzer alle Daten (Tabellen, Ansichten, Sequenzen) schreiben können, als ob INSERTsie über diese UPDATEObjekte verfügen, und DELETE NUTZUNGsrechte für alle Schemas, auch ohne explizit erteilt zu haben. Als Problemumgehung wird empfohlen, ähnliche Berechtigungen auf einer endlicheren Ebene pro Datenbank und Objekt zu gewähren.

Zeilenbasierte Sicherheit

Die Sicherheit auf Zeilenebene (Row-Level Security, RLS) ist ein Azure-Datenbank für PostgreSQL-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. Die Sicherheit auf Zeilenebene fügt einer Azure-Datenbanktabelle für PostgreSQL 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, , , INSERTund , und UPDATE, oder sie für DELETEalle 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 überschreibt keine vorhandenen GRANT Berechtigungen. Es fügt eine feiner abgestimmte Steuerungsebene hinzu. Beispielsweise gewährt die Einstellung ROW SECURITY FOR SELECT , dass ein bestimmter Benutzer auf Zeilen zugreifen kann, nur diesen Benutzerzugriff, wenn der Benutzer auch über Berechtigungen für die betreffende Spalte oder Tabelle verfügt SELECT .

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, um sicherzustellen, dass Mitglieder der Managerrolle keine SELECTDELETEZeilen ausführen können, die zu anderen Managern gehören, oder UPDATE Vorgänge, die zu anderen Managern gehören, und keine INSERT neuen Zeilen, die zu einem anderen Manager gehören.

Sie können eine Zeilensicherheitsrichtlinie mithilfe des DROP POLICY Befehls ablegen, wie in diesem Beispiel gezeigt:

DROP POLICY account_managers ON accounts;

Obwohl Sie die Richtlinie möglicherweise ablegen, kann der Rollen-Manager dennoch keine Daten anzeigen, die zu einem anderen Vorgesetzten gehören. Diese Einschränkung ist vorhanden, da die Sicherheitsrichtlinie auf Zeilenebene weiterhin in der Kontentabelle 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 verfügt über BYPASSRLS - und NOBYPASSRLS-Berechtigungen , die Sie einer Rolle zuweisen können. NOBYPASSRLS ist standardmäßig zugewiesen. Bei neu bereitgestellten Servern in Azure Database for PostgreSQL wird das Umgehen von Sicherheitsberechtigungen auf Zeilenebene (BYPASSRLS) wie folgt implementiert:

  • Für Postgres 16 und höher versionierte Server folgen wir dem Standardverhalten von PostgreSQL 16. Nichtadministrative Benutzer, die von der azure_pg_admin Administratorrolle erstellt wurden, ermöglichen es Ihnen, bei Bedarf Rollen mit dem BYPASSRLS-Attribut oder -Berechtigungen zu erstellen.

  • Für Postgres 15- und frühere Versionsserver können Sie den azure_pg_admin Benutzer verwenden, um administrative Aufgaben auszuführen, die die BYPASSRLS-Berechtigung erfordern. Sie können jedoch keine Nichtadminbenutzer mit den BypassRLS-Berechtigungen erstellen, da die Administratorrolle keine Superuserberechtigungen aufweist, wie in cloudbasierten PaaS PostgreSQL-Diensten üblich.

Verwandte Inhalte

  • Last updated on