Freigeben über

CLR-Integration Codezugriffssicherheit

  • Artikel

Gilt für: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:

  • Computerrichtlinie: Diese Richtlinie gilt für den gesamten verwalteten Code, der auf dem Computer ausgeführt wird, auf dem SQL Server installiert ist.

  • Benutzerrichtlinie: Diese Richtlinie gilt für verwalteten Code, der von einem Prozess gehostet wird. Für SQL Server ist die Benutzerrichtlinie spezifisch für das Windows-Konto, auf dem der SQL Server-Dienst ausgeführt wird.

  • Hostrichtlinie: Diese Richtlinie wird vom Host der CLR (in diesem Fall SQL Server) eingerichtet, der für verwalteten Code in diesem Host ausgeführt wird.

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.

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. Es gibt drei Berechtigungssätze: SAFE, EXTERNAL_ACCESSund UNSAFE (angegeben mithilfe der option PERMISSION_SETCREATE 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:

Berechtigung 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:

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

Wichtig

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:

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

Funktionalität SAFE EXTERNAL_ACCESS UNSAFE
Codezugriffssicherheitsberechtigungen Nur ausführen Ausführen + Zugriff auf externe Ressourcen Uneingeschränkt (einschließlich P/Invoke)
Beschränkungen des Programmiermodells Yes Yes Keine Einschränkungen
Überprüfbarkeit erforderlich Yes Yes No
Lokaler Datenzugriff Yes Yes Yes
Aufrufbarkeit von systemeigenem Code No No Yes

Verwandte Inhalte