Öffentliche Rolle in SQL Server

Datenbankrollen sind ähnlich wie Windows-Gruppen — anstatt jedem Benutzer einzeln den Zugriff zu entziehen oder zu gewähren, verwalten Administratoren den Zugang, indem sie Berechtigungen von Rollen erteilen oder entziehen und die Mitgliedschaft in Rollen ändern. Die Verwendung von Rollen erleichtert es, Berechtigungen für Datenbankbenutzer genau zu erteilen und zu entziehen. Und da mehrere Benutzer Mitglieder einer SQL-Datenbankrolle sein können, können Sie die Rechte für eine ganze Gruppe von Benutzern auf einmal einfach verwalten.

In this post, we explain the public role in Microsoft SQL Server and some of the best practices related to it. (We are deliberately using lowercase letters here, since that is how the public role is spelled in the SQL Server world, unlike in the Oracle world.)

Rollenarten in SQL Server

Microsoft SQL Server bietet verschiedene Arten von vordefinierten Rollen:

• Fixed server roles — They are called “fixed” server roles because, except for the public role, they cannot be modified or drop
• Feste Datenbankrollen
• Anwendung Rolle – Ein Datenbankprinzipal, der von einer Anwendung verwendet werden kann, um mit einem eigenen Berechtigungssatz zu laufen (standardmäßig deaktiviert)
• Benutzerdefinierte Rollen (ab SQL Server 2012) — Nur Serverebenenberechtigungen können zu benutzerdefinierten

Wo die öffentliche Rolle ihren Platz hat

Alle Datenbankplattformen verfügen über eine vordefinierte Rolle namens public, aber die Implementierung dieser Rolle variiert je nach Plattform. In SQL Server ist die Rolle public Teil der festen Serverrolle, und Berechtigungen können der SQL Server public Rolle erteilt, verweigert oder entzogen werden.

Wenn ein SQL Server-Login erstellt wird, wird diesem die Rolle 'public' zugewiesen, und diese kann nicht entzogen werden. Wenn dem Serverprinzipal keine spezifischen Berechtigungen für ein sicherbares Objekt erteilt oder verweigert werden, erbt der Login automatisch die Berechtigungen für dieses Objekt, die der Rolle 'public' gewährt werden.

Berechtigungen, die der öffentlichen Rolle zugewiesen sind

Um die Sicherheit des SQL Server zu gewährleisten und die Einhaltung zahlreicher Vorschriften, einschließlich PCI DSS und HIPAA, sicherzustellen, müssen Sie alle Server- und Datenbankebenen-Rollen kennen, die jedem Benutzer zugewiesen sind. Lassen Sie uns die dem öffentlichen Rolle zugewiesenen Serverebenen-Berechtigungen mit einer Management Studio Transact-SQL-Abfrage überprüfen:

      SELECT sp.state_desc as "Permission State", sp.permission_name as "Permission",
sl.name "Principal Name",sp.class_desc AS "Object Class", ep.name "End Point"
FROM sys.server_permissions AS sp
  JOIN sys.server_principals AS sl
    ON sp.grantee_principal_id = sl.principal_id
  LEFT JOIN sys.endpoints AS ep
    ON sp.major_id = ep.endpoint_id
WHERE sl.name = 'public';
      

Wie die obige Tabelle zeigt, werden nur fünf Server-Ebene-Berechtigungen der öffentlichen Rolle zugewiesen. Beachten Sie, dass die Berechtigung VIEW ANY DATABASE den Benutzern keinen Zugriff auf Datenbankobjekte gewährt; sie erlaubt ihnen lediglich, alle Datenbanken in einer SQL Server-Instanz aufzulisten. Daher kann ein Benutzer, wenn Sie ein neues Login erstellen und keine weiteren Rollen oder Berechtigungen zuweisen, sich nur bei der Instanz anmelden und ist nicht in der Lage, etwas anderes zu tun.

Berechtigungen, wenn einem SQL Server-Login eine Standarddatenbank zugewiesen wird

Jetzt erstellen wir eine SQL Server-Anmeldung, die SQL-Authentifizierung verwendet, indem wir diesem Benutzer eine Standarddatenbank zuweisen.

      USE [master]
GO
CREATE LOGIN [SQTest] WITH PASSWORD=N'nhggLboBn6SHolSWfipjzO/7GYw8M2RMbCt1LsCTK5M=', DEFAULT_DATABASE=[SBITS], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
      

Wenn wir uns als dieser Benutzer anmelden und alle Datenbankebene-Berechtigungen für die Standarddatenbank SBITS des Benutzers auflisten, können wir sehen, welche Berechtigungen sie haben. Wie unten gezeigt, hat der Benutzer Stealth keine Berechtigungen für die SBITS-Datenbank, obwohl dies die Standarddatenbank des Benutzers ist. Mit anderen Worten, nur weil einem Benutzer-Login eine Standarddatenbank zugewiesen ist, bedeutet das nicht, dass der Benutzer in der Lage sein wird, die Datenbankobjekte oder Daten zu sehen.

Um dies zu überprüfen, können wir das folgende Skript verwenden:

      EXECUTE AS LOGIN= 'SQTest';
GO
USE SBITS
GO
SELECT dp.state_desc AS "Class Description", dp.permission_name AS "Permission Name",
SCHEMA_NAME(ao.schema_id) AS "Schema Name", ao.name AS "Object Name"
FROM sys.database_permissions dp
 LEFT JOIN sys.all_objects ao
  ON dp.major_id = ao.object_id
 JOIN sys.database_principals du
  ON dp.grantee_principal_id = du.principal_id
WHERE du.name = 'TestLoginPerms'
 AND ao.name IS NOT NULL
ORDER BY ao.name;
REVERT
      

Berechtigungen, die von der öffentlichen Rolle in der Master-Datenbank geerbt werden

Da das Benutzer-Login Stealth standardmäßig Teil der Rolle public ist, betrachten wir die Berechtigungen, die von der Rolle public auf der Datenbank master geerbt wurden.

      USE master;
GO
 SELECT sp.state_desc AS "Permission State", sp.permission_name AS "Permission",
 SCHEMA_NAME(ao.schema_id) AS 'Schema', ao.name AS "Object Name"
 FROM sys.database_permissions sp
  LEFT JOIN sys.all_objects ao
     ON sp.major_id = ao.object_id
   JOIN sys.database_principals dp
     ON sp.grantee_principal_id = dp.principal_id
 WHERE dp.name = 'public'
 AND ao.name IS NOT NULL
 ORDER BY ao.name
      

In SQL Server 2016, there are 2,089 permissions stored in the master database granted to the public role. While it might seem daunting, they are all SELECT permissions and do not allow the user Stealth to make any changes in the master database. However, it is good practice to revoke some of the permissions based on the security policies in your organization. However, exercise caution while revoking them because some are required by users for normal operations in certain circumstances.

Vereinfachung der Rollenüberprüfung und -verwaltung

Anstatt komplexe benutzerdefinierte Skripte zu verwenden, um die Probleme im Zusammenhang mit der öffentlichen Rolle in einer Instanz nach der anderen zu ermitteln, sollten Sie Netwrix Access Analyzer in Betracht ziehen. Diese Plattform für die Governance des Datenzugriffs kann alle SQL Server-Rollen und -Privilegien auflisten, einschließlich der SQL Server öffentlichen Rollen und SQL Server öffentlichen Datenbankrollen, und liefert sofort detaillierte Berechtigungsberichte. Sie bietet eine einheitliche Ansicht der öffentlichen Rolle über alle SQL Server in Ihrem Unternehmen und hilft Ihnen, Probleme mit einem Klick zu beheben.

Best Practices für die Public-Rolle in SQL Server

Wir empfehlen die folgenden Best Practices, wenn es um die öffentliche Rolle im SQL Server geht:

• Gewähren Sie der öffentlichen Rolle unter keinen Umständen zusätzliche Privilegien außerhalb der Standardprivilegien. Falls notwendig, nutzen Sie eine benutzerdefinierte Rolle.
• Ändern Sie nicht die Server-Ebene-Berechtigungen für die öffentliche Rolle, da dies dazu führen kann, dass Benutzer keine Verbindung zur Datenbank herstellen können.
• Überprüfen Sie die öffentlichen Berechtigungen jedes Mal, wenn Sie Ihren SQL Server aktualisieren, da Microsoft oft Änderungen an der öffentlichen Rolle vornimmt.

FAQ

Was ist eine öffentliche Datenbankrolle?

Berechtigungen, die der öffentlichen Datenbankrolle erteilt werden, werden von jedem Datenbankbenutzer geerbt.

Welche Berechtigungen hat die öffentliche Rolle im SQL Server?

Jeder SQL Server-Login gehört zur Rolle des öffentlichen Servers. Wenn einem Serverprinzipal keine spezifischen Berechtigungen für ein sicherbares Objekt erteilt oder verweigert wurden, erbt der Benutzer die Berechtigungen, die für dieses Objekt der öffentlichen Rolle gewährt wurden.