Freigeben über

  • Artikel

Grundlegendes zum Ausführungskontext

Der Ausführungskontext wird durch den Benutzer oder den Benutzernamen bestimmt, der mit der Sitzung verbunden ist oder ein Modul ausführt (aufruft). Sie legt die Identität fest, für die überprüft wird, welche Berechtigungen zum Ausführen von Anweisungen oder Aktionen vorliegen. Der Ausführungskontext wird durch ein Paar Sicherheitstoken repräsentiert: ein Benutzernamentoken und ein Benutzertoken. Die Token identifizieren den Primär- und den Sekundärprinzipal, die zur Prüfung der Berechtigungen verwendet werden, sowie die Quelle, die zur Tokenauthentifizierung verwendet wird. Ein Benutzername, der eine Verbindung mit einer Instanz von SQL Server herstellt, verfügt über ein Benutzernamentoken und ein oder mehrere Benutzertoken (abhängig von der Anzahl der Datenbanken, auf die das Konto Zugriff hat).

Sicherheitstoken für Benutzer und Benutzernamen

Ein Sicherheitstoken für einen Benutzer oder Benutzernamen enthält folgende Elemente:

  • Ein Server- oder Datenbankprinzipal als Primäridentität

  • Ein oder mehrere Prinzipals als Sekundäridentitäten

  • Null oder mehr Authentifikatoren

  • Die Privilegien und Berechtigungen der Primär- und Sekundäridentitäten

Prinzipals sind die Personen, Gruppen und Prozesse, die SQL Server-Ressourcen anfordern können. Die Kategorisierung der Prinzipals erfolgt nach dem Umfang ihrer Einflussmöglichkeiten: Windows-Ebene, SQL Server-Ebene oder Datenbankebene. Weitere Informationen finden Sie unter Prinzipale (Datenbankmodul).

Authentifikatoren sind Prinzipals, Zertifikate oder asymmetrische Schlüssel, welche die Echtheit des Tokens garantieren. Häufig ist die Instanz von SQL Server der Authentifikator eines Tokens. Weitere Informationen zu Authentifikatoren finden Sie unter Erweitern des Identitätswechsels bei Datenbanken durch Verwenden von EXECUTE AS. Weitere Informationen zu Zertifikaten und asymmetrischen Schlüsseln finden Sie unter Verschlüsselungshierarchie.

Ein Benutzernamentoken ist für die gesamte Instanz von SQL Server gültig. Es enthält die Primär- und Sekundäridentitäten, für die die Prüfung der Berechtigungen auf der Serverebene sowie aller Berechtigungen auf der Datenbankebene, die diesen Identitäten zugeordnet sind, erfolgt. Die Primäridentität ist der Anmeldename selbst. Die Sekundäridentität enthält Berechtigungen, die von Rollen und Gruppen geerbt wurden.

Ein Benutzertoken ist nur für eine bestimmte Datenbank gültig. Es enthält die Primär- und Sekundäridentitäten, für die die Prüfung der Berechtigungen auf Datenbankebene erfolgt. Die Primäridentität ist der Datenbankbenutzer selbst. Die Sekundäridentität enthält Berechtigungen, die von Datenbankrollen geerbt wurden. Benutzertoken enthalten keine Server-Rollenmitgliedschaften und berücksichtigen auch nicht die Berechtigungen auf Serverebene, die den Identitäten im Token erteilt wurden, einschließlich der Berechtigungen, die der public-Rolle auf Serverebene erteilt wurden.

Wenn ein SQL Server-Benutzernamenkonto oder -Benutzerkonto explizit erstellt wird, wird die für dieses Konto erstellte Benutzernamen- oder Benutzer-ID als Primäridentität im Benutzernamen- oder Benutzertoken verwendet. Wenn ein Prinzipal impliziten Zugriff auf eine Instanz von SQL Server hat oder über CONTROL SERVER-Berechtigungen auf eine Datenbank zugreift, entspricht die Primäridentität im Anmeldetoken der Standardrolle public. Die Primäridentität im Benutzertoken ist public.

Wichtiger HinweisWichtig

Bei Mitgliedern der festen Serverrolle sysadmin ist die Primäridentität ihres Benutzertokens immer dbo.

Beispiel für Benutzernamentoken

Mary verfügt über einen SQL Server-Benutzernamen, der ihrem Windows-Konto MyDomain\Mary zugeordnet ist. Um Informationen zu dem für sie erstellte Anmeldetoken anzuzeigen, führt Mary die folgende Anweisung aus:

SELECT principal_id, sid, name, type, usage FROM sys.login_token;
GO

Das Resultset könnte ungefähr so aussehen:

principal_id sid name type usage

------------ ----------- ------------- -------------- -------------

261 0x583EA MyDomain\Mary WINDOWS LOGIN GRANT OR DENY

2 0x02 public SERVER ROLE GRANT OR DENY

(2 row(s) affected)

Das Resultset zeigt, dass das Windows-Konto für Mary die Primäridentität ihres Anmeldetokens ist. Die beim Erstellen ihres Benutzernamenkontos erstellte principal_id wird als primäre principal_id im Benutzernamentoken verwendet. Die public-Rolle wird als eine Sekundäridentität aufgeführt, weil Mary Mitglied dieser Standardrolle ist. Wäre Mary außerdem Mitglied anderer Rollen auf Serverebene, so würden diese Rollen als zusätzliche Sekundäridentitäten aufgeführt sein. Zum Zeitpunkt der Erstellung des Benutzernamens wurde ihr Windows-Konto durch die Instanz von SQL Server überprüft. Deshalb ist die Instanz von SQL Server der Authentifikator ihres Benutzernamentokens, wenn Mary sich an der Instanz anmeldet. Weil die Instanz von SQL Server der Authentifikator von Marys Benutzernamentoken ist, wird in der Abfrage kein Authentifikator wie z. B. ein Prinzipal, ein Zertifikat oder ein asymmetrischer Schlüssel zurückgegeben.

Beispiel für Benutzertoken

Mary hat ein Benutzertoken für jede Datenbank, auf die sie Zugriff hat. In diesem ersten Beispiel ist Mary mit der master-Datenbank verbunden. Zum Anzeigen von Informationen zum Benutzertoken, das für sie in der master-Datenbank erstellt wurde, führt Mary die folgende Anweisung aus:

SELECT principal_id, sid, name, type, usage FROM sys.user_token;
GO

Das Resultset könnte ungefähr so aussehen:

principal_id sid name type usage

------------ ----------- ------------- -------------- -------------

2 NULL guest SQL USER GRANT OR DENY

0 NULL public ROLE GRANT OR DENY

(2 row(s) affected)

Das Resultset zeigt, dass Mary kein expliziter Benutzer in der master-Datenbank ist, sondern stattdessen Zugriff über das guest-Konto hat. Die Primäridentität ihres Benutzertokens ist der guest-Benutzer. Die public-Rolle wird als eine Sekundäridentität aufgeführt, weil guest Mitglied dieser Standardrolle ist. Das Benutzertoken für Mary in der master-Datenbank enthält sämtliche Privilegien und Berechtigungen auf der Datenbankebene für den guest-Benutzer und die public-Rolle.

Im folgenden Beispiel wurde in der Sales-Datenbank ein explizites Benutzerkonto für Mary erstellt. Außerdem wurde sie der festen Datenbankrolle db_ddladmin für diese Datenbank hinzugefügt. Mit Sales als aktueller Datenbank führt Mary die Anweisung SELECT * FROM sys.user_token erneut aus.

Das Resultset könnte ungefähr so aussehen:

principal_id sid name type usage

------------ ----------- ------------- -------------- -------------

5 0x36CC4BBD1 Mary SQL USER GRANT OR DENY

0 NULL public ROLE GRANT OR DENY

16387 NULL db_ddladmin ROLE GRANT OR DENY

Dieses Resultset gibt das Benutzertoken an, das für Mary in der Sales-Datenbank erstellt wurde. Da Mary explizit als Benutzer zur Sales-Datenbank hinzugefügt wurde, wird sie als Primäridentität aufgeführt. Die beiden Rollen, in denen sie Mitglied ist, sind als Sekundäridentitäten aufgeführt. Der Authentifikator von Marys Benutzertoken ist die Instanz von SQL Server.

Wechseln des Ausführungskontexts

In SQL Server kann der Ausführungskontext einer Sitzung explizit geändert werden, indem in einer EXECUTE AS-Anweisung ein Benutzer oder Anmeldename angegeben wird. Der Ausführungskontext eines Moduls wie z. B. einer gespeicherten Prozedur, eines Triggers oder einer benutzerdefinierten Funktion kann implizit geändert werden, indem in einer EXECUTE AS-Klausel in der Moduldefinition ein Benutzer oder Benutzername angegeben wird. Wenn der Ausführungskontext zu einem anderen Benutzer oder Benutzernamen wechselt, überprüft SQL Server die Berechtigungen für die Benutzernamen- und Benutzertoken des entsprechenden Kontos. Das bedeutet im Wesentlichen, dass für die Dauer der Sitzung bzw. der Modulausführung die Identität dieses Kontos übernommen wird. Weitere Informationen finden Sie unter Grundlegendes zum Wechseln des Kontexts.