Teilen über


CLR-Integrationscodezugriffssicherheit

Applies to:SQL Server

Die Common Language Runtime (CLR) unterstützt ein Sicherheitsmodell, das als Codezugriffssicherheit für verwalteten Code bezeichnet wird. In diesem Modell werden Assemblys Berechtigungen auf Grundlage der Identität des Codes gewährt. Weitere Informationen finden Sie unter Code Access Security.

Die Sicherheitsrichtlinie, die die Berechtigungen für Assemblys bestimmt, wird an drei verschiedenen Stellen definiert:

  • Machine policy: This policy is in effect for all managed code running in the machine on which SQL Server is installed.

  • User policy: This policy is in effect for managed code hosted by a process. Für SQL Server ist die Benutzerrichtlinie spezifisch für das Windows-Konto, auf dem der SQL Server-Dienst ausgeführt wird.

  • Host policy: This policy is set up by the host of the CLR (in this case, SQL Server) that is in effect for managed code running in that host.

Der von der CLR unterstützte Codezugriffs-Sicherheitsmechanismus basiert auf der Annahme, dass die Laufzeit sowohl vollständig vertrauenswürdigen als auch teilweise vertrauenswürdigen Code hosten kann. Die ressourcen, die durch CLR-Codezugriffssicherheit geschützt sind, werden in der Regel von verwalteten Anwendungsprogrammierschnittstellen umschlossen, die die entsprechende Berechtigung erfordern, bevor der Zugriff auf die Ressource zugelassen wird. Die Anforderung der Berechtigung ist nur dann erfüllt, wenn alle aufrufenden Prozesse (auf Assemblyebene) in der Aufrufliste über die entsprechende Ressourcenberechtigung verfügen.

Der Satz von Codezugriffssicherheitsberechtigungen, die verwaltetem Code beim Ausführen in SQL Server gewährt werden, ist die Schnittmenge der Berechtigungen, die von den vorherigen drei Richtlinienebenen gewährt werden. Selbst wenn SQL Server eine Reihe von Berechtigungen für eine assembly gewährt, die in SQL Server geladen wurde, kann der letztendliche Satz von Berechtigungen, die dem Benutzercode zugewiesen werden, möglicherweise durch die Richtlinien auf Benutzer- und Computerebene weiter eingeschränkt werden.

Codezugriffssicherheit wird nicht mehr unterstützt

CLR verwendet die Codezugriffssicherheit (Code Access Security, CAS) im .NET Framework, die nicht länger als Sicherheitsbegrenzung unterstützt wird. Eine CLR-Assembly, die mit PERMISSION_SET = SAFE erstellt wurde, kann womöglich auf externe Systemressourcen zugreifen, nicht verwalteten Code aufrufen und sysadmin-Privilegien erwerben. In SQL Server 2017 (14.x) und höheren Versionen verbessert die sp_configure Option clr strict security die Sicherheit von CLR-Assemblys. clr strict security ist standardmäßig aktiviert und behandelt SAFE- und EXTERNAL_ACCESS-Assemblys so, als wären Sie als UNSAFE gekennzeichnet. Die Option clr strict security kann für die Abwärtskompatibilität deaktiviert werden, es wird jedoch nicht empfohlen.

Es wird empfohlen, dass Sie alle Assemblys durch ein Zertifikat oder einen asymmetrischen Schlüssel mit einem entsprechenden Anmeldenamen signieren, dem UNSAFE ASSEMBLY-Berechtigung für die master-Datenbank gewährt wurde. SQL Server-Administratoren können auch Assemblys einer Liste von Assemblys hinzufügen, der die Datenbank-Engine vertrauen sollte. For more information, see sys.sp_add_trusted_assembly.

Berechtigungssätze auf SQL Server-Hostrichtlinienebene

Der Satz von Codezugriffssicherheitsberechtigungen, die Assemblys von der SQL Server-Hostrichtlinienebene gewährt werden, wird durch den Berechtigungssatz bestimmt, der beim Erstellen der Assembly angegeben wurde. There are three permission sets: SAFE, EXTERNAL_ACCESS, and UNSAFE (specified using the PERMISSION_SET option of CREATE ASSEMBLY).

SQL Server stellt beim Hosten eine Sicherheitsrichtlinienebene auf Hostebene für die CLR bereit. Diese Richtlinie ist eine zusätzliche Richtlinienebene unter den beiden Richtlinienebenen, die immer wirksam sind. Diese Richtlinie wird für jede Anwendungsdomäne festgelegt, die von SQL Server erstellt wird. Diese Richtlinie ist nicht für die Standardanwendungsdomäne gedacht, die wirksam wäre, wenn SQL Server eine Instanz der CLR erstellt.

Die SQL Server-Richtlinie auf Hostebene ist eine Kombination aus einer festen SQL Server-Richtlinie für Systemassemblys und eine vom Benutzer angegebene Richtlinie für Benutzerassemblys.

Die feste Richtlinie für CLR-Assemblys und SQL Server-Systemassemblys gewährt ihnen voll vertrauenswürdig.

Der vom Benutzer angegebene Teil der SQL Server-Hostrichtlinie basiert auf dem Assemblybesitzer, der einen von drei Berechtigungs-Buckets für jede Assembly angibt. Weitere Informationen zu den folgenden Sicherheitsberechtigungen finden Sie im .NET Framework SDK.

SAFE

Nur interne Berechnungen und lokaler Datenzugriff sind zulässig. SAFE ist der restriktivste Berechtigungssatz. Code, der von einer Assembly mit SAFE Berechtigungen ausgeführt wird, kann nicht auf externe Systemressourcen wie Dateien, Das Netzwerk, Umgebungsvariablen oder die Registrierung zugreifen.

SAFE Assemblys verfügen über die folgenden Berechtigungen und Werte:

Permission Werte /Beschreibung
SecurityPermission Execution: Berechtigung zum Ausführen von verwaltetem Code.
SqlClientPermission Context connection = true, context connection = yes: Nur die Kontextverbindung kann verwendet werden, und die Verbindungszeichenfolge kann nur einen Wert von context connection=true oder context connection=yesangeben.

AllowBlankPassword = false: Leere Kennwörter sind nicht zulässig.

EXTERNAL_ACCESS

EXTERNAL_ACCESS Assemblys verfügen über die gleichen Berechtigungen wie SAFE Assemblys, mit der zusätzlichen Möglichkeit, auf externe Systemressourcen wie Dateien, Netzwerke, Umgebungsvariablen und die Registrierung zuzugreifen.

EXTERNAL_ACCESS Assemblys verfügen außerdem über die folgenden Berechtigungen und Werte:

Permission Werte /Beschreibung
DistributedTransactionPermission Unrestricted: Verteilte Transaktionen sind zulässig.
DNSPermission Unrestricted: Berechtigung zum Anfordern von Informationen von Domänennamenservern.
EnvironmentPermission Unrestricted: Vollzugriff auf System- und Benutzerumgebungsvariablen ist zulässig.
EventLogPermission Administer: Die folgenden Aktionen sind zulässig: Erstellen einer Ereignisquelle, Lesen vorhandener Protokolle, Löschen von Ereignisquellen oder Protokollen, Antworten auf Einträge, Löschen eines Ereignisprotokolls, Überwachen von Ereignissen und Zugreifen auf eine Sammlung aller Ereignisprotokolle.
FileIOPermission Unrestricted: Vollzugriff auf Dateien und Ordner ist zulässig.
KeyContainerPermission Unrestricted: Vollzugriff auf Schlüsselcontainer ist zulässig.
NetworkInformationPermission Access: Pinging ist zulässig.
RegistryPermission Ermöglicht Leserechten HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIGund HKEY_USERS.
SecurityPermission Assertion: Fähigkeit, zu bestätigen, dass alle Aufrufer dieses Codes über die erforderliche Berechtigung für den Vorgang verfügen.

ControlPrincipal: Möglichkeit, das Prinzipalobjekt zu bearbeiten.

Execution: Berechtigung zum Ausführen von verwaltetem Code.

SerializationFormatter: Möglichkeit zum Bereitstellen von Serialisierungsdiensten.
SmtpPermission Access: Ausgehende Verbindungen mit SMTP-Hostport 25 sind zulässig.
SocketPermission Connect: Ausgehende Verbindungen (alle Ports, alle Protokolle) für eine Transportadresse sind zulässig.
SqlClientPermission Unrestricted: Vollzugriff auf die Datenquelle ist zulässig.
StorePermission Unrestricted: Vollzugriff auf X.509-Zertifikatspeicher ist zulässig.
WebPermission Connect: Ausgehende Verbindungen mit Webressourcen sind zulässig.

UNSAFE

UNSAFE ermöglicht assemblys uneingeschränkten Zugriff auf Ressourcen sowohl innerhalb als auch außerhalb von SQL Server. Code, der in einer UNSAFE Assembly ausgeführt wird, kann auch nicht verwalteten Code aufrufen.

UNSAFE Assemblys werden FullTrustangegeben.

SAFE ist die empfohlene Berechtigungseinstellung für Assemblys, die Berechnungs- und Datenverwaltungsaufgaben ausführen, ohne auf Ressourcen außerhalb von SQL Server zuzugreifen.

EXTERNAL_ACCESS wird für Assemblys empfohlen, die auf Ressourcen außerhalb von SQL Server zugreifen. EXTERNAL_ACCESS Assemblys werden standardmäßig als SQL Server-Dienstkonto ausgeführt. Es ist möglich, dass EXTERNAL_ACCESS Code die Identität des Sicherheitskontexts des Aufrufers für die Windows-Authentifizierung explizit imitiert. Da der Standardwert als SQL Server-Dienstkonto ausgeführt werden soll, sollte die Berechtigung zum Ausführen von EXTERNAL_ACCESS nur an Anmeldeinformationen übergeben werden, die als Dienstkonto ausgeführt werden.

Aus Sicherheitsgründen sind EXTERNAL_ACCESS und UNSAFE Assemblys identisch. EXTERNAL_ACCESS Assemblys bieten jedoch verschiedene Zuverlässigkeits- und Robustitätsschutzfunktionen, die sich nicht in UNSAFE Assemblys befinden.

Wenn Sie UNSAFE angeben, kann der Code in der Assembly unzulässige Vorgänge für den SQL Server-Prozessbereich ausführen und somit die Stabilität und Skalierbarkeit von SQL Server beeinträchtigen. Weitere Informationen zum Erstellen von CLR-Assemblys in SQL Server finden Sie unter Verwalten von CLR-Integrationsassemblys.

Important

SQL Server enthält CLR-Assemblys, die vom Datenbankmodul verwendet werden, um bestimmte Funktionen bereitzustellen. Die Microsoft.SQLServer.Types Assembly, die in der SQL Server-Installation enthalten ist, wird in den Metadaten als UNSAFE Assembly angezeigt. Es handelt sich hierbei um ein beabsichtigtes Verhalten. Diese Assemblys gelten standardmäßig als vertrauenswürdig und sicher.

Zugreifen auf externe Ressourcen

Wenn ein benutzerdefinierter Typ (USER-Defined Type, UDT), eine gespeicherte Prozedur oder ein anderer Konstruktassembly mit dem SAFE Berechtigungssatz registriert ist, kann verwalteter Code, der im Konstrukt ausgeführt wird, nicht auf externe Ressourcen zugreifen. Wenn jedoch entweder die EXTERNAL_ACCESS oder UNSAFE Berechtigungssätze angegeben werden, und verwalteter Code versucht, auf externe Ressourcen zuzugreifen, wendet SQL Server die folgenden Regeln an:

If Then
Der Ausführungskontext entspricht einer SQL Server-Anmeldung. Versuche, auf externe Ressourcen zuzugreifen, werden verweigert, und eine Sicherheitsausnahme wird ausgelöst.
Der Ausführungskontext entspricht einer Windows-Anmeldung, und der Ausführungskontext ist der ursprüngliche Aufrufer. Auf die externe Ressource wird unter dem Sicherheitskontext des SQL Server-Dienstkontos zugegriffen.
Der Anrufer ist nicht der ursprüngliche Anrufer. Der Zugriff wird verweigert, und eine Sicherheitsausnahme wird ausgelöst.
Der Ausführungskontext entspricht einer Windows-Anmeldung, und der Ausführungskontext ist der ursprüngliche Aufrufer und der Aufrufer wird als Identitätswechsel bezeichnet. Access verwendet den Sicherheitskontext des Aufrufers und nicht das Dienstkonto.

Zusammenfassung des Berechtigungssatzes

Das folgende Diagramm fasst die Einschränkungen und Berechtigungen zusammen, die den SAFE, EXTERNAL_ACCESSund UNSAFE Berechtigungssätzen erteilt wurden.

Functionality SAFE EXTERNAL_ACCESS UNSAFE
Codezugriffssicherheitsberechtigungen Execute only Ausführen + Zugriff auf externe Ressourcen Uneingeschränkt (einschließlich P/Invoke)
Beschränkungen des Programmiermodells Yes Yes No restrictions
Verifiability requirement Yes Yes No
Lokaler Datenzugriff Yes Yes Yes
Aufrufbarkeit von systemeigenem Code No No Yes