CLR-Integration und Codezugriffssicherheit
Die CLR (Common Language Runtime) 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 im Abschnitt "Codezugriffsicherheit" im .NET Framework Software Development Kit.
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 auf dem Computer, auf dem SQL Server installiert ist.
Benutzerrichtlinie: Diese Richtlinie ist für verwalteten Code gültig, der von einem Prozess gehostet wird. Für SQL Server gilt die Benutzerrichtlinie für das Windows-Konto, unter dem der SQL Server-Dienst ausgeführt wird.
Hostrichtlinie: Diese Richtlinie wird vom Host der CLR (in diesem Fall SQL Server) eingerichtet, die für den verwalteten Code gültig ist, der auf 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 durch die CLR-Codezugriffssicherheit geschützten Ressourcen sind üblicherweise von verwalteten Schnittstellen für die Anwendungsprogrammierung (Application Programming Interfaces oder API) umgeben, für die die entsprechenden Berechtigungen erforderlichsind, bevor der Zugriff auf die Ressource zugelassen wird. Die Anforderungder Berechtigung ist nur dann erfüllt, wenn alle aufrufenden Prozesse (auf Assemblyebene) in der Aufrufliste über die entsprechende Ressourcenberechtigung verfügen.
Die Menge der Codezugriffsberechtigungen, die verwaltetem Code gewährt werden, wenn dieser innerhalb von SQL Server ausgeführt wird, ist die Schnittmenge der Berechtigungen, die auf den drei oben genannten Richtlinienebenen erteilt werden. Auch wenn SQL Server einer in SQL Server geladenen Assembly einen Berechtigungssatz gewährt, kann der schließlich für Benutzercode gewährte Berechtigungssatz durch die Richtlinien auf Computer- und Benutzerebenen weiter eingeschränkt sein.
Berechtigungssätze auf SQL Server Host-Richtlinienebene
Die Menge der Codezugriffsberechtigungen, die Assemblys von der SQL Server-Hostrichtlinienebene gewährt wird, wird von dem Berechtigungssatz bestimmt, der beim Erstellen der Assembly angegeben wurde. Es existieren drei Berechtigungssätze: SAFE, EXTERNAL_ACCESS und UNSAFE (wird mithilfe der PERMISSION_SET-Option von CREATE ASSEMBLY (Transact-SQL) angegeben).
SQL Server stellt für die gehostete CLR eine Sicherheitsrichtlinie auf Hostebene bereit; diese Richtlinie stellt eine zusätzliche Richtlinienebene unterhalb der zwei Richtlinienebenen dar, die immer gültig sind. Die Richtlinie wird für jede Anwendungsdomäne festgelegt, die von SQL Server erstellt wird. Sie ist nicht für die Standardanwendungsdomäne bestimmt, die gültig ist, wenn SQL Server eine Instanz der CLR erstellt.
Die SQL Server-Richtlinie auf Hostebene ist eine Kombination der festen Richtlinie von SQL Server für Systemassemblys und der benutzerdefinierten Richtlinie für Benutzerassemblys.
Die feste Richtlinie für CLR-Assemblys und SQL Server-Systemassemblys verleiht ihnen volle Vertrauenswürdigkeit.
Der benutzerdefinierte Teil der Hostrichtlinie von SQL Server basiert darauf, dass der Assemblybesitzer einen von drei Berechtigungsbuckets für jede Assembly angibt. Weitere Informationen über die unten aufgeführten Sicherheitsberechtigungen finden Sie unter .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, hat keinen Zugriff auf externe Systemressourcen wie Dateien, das Netzwerk, Umgebungsvariablen oder die Registrierung.
SAFE-Assemblys verfügen über folgende Berechtigungen und Werte:
Berechtigung |
Wert(e)/Beschreibung |
|---|---|
SecurityPermission |
Execution: Berechtigung zur Ausführung von verwaltetem Code. |
SqlClientPermission |
Context connection = true, context connection = yes: Es kann nur die Kontextverbindung verwendet werden, und die Verbindungszeichenfolge kann nur den Wert "context connection=true" oder "context connection=yes" angeben. AllowBlankPassword = false: Leere Kennwörter sind nicht zulässig. |
EXTERNAL_ACCESS
EXTERNAL_ACCESS-Assemblys verfügen über die gleichen Berechtigungen wie SAFE -Assemblys und können zusätzlich auf externe Systemressourcen zugreifen, z. B. Dateien, Netzwerke, Umgebungsvariablen oder die Registrierung.
EXTERNAL_ACCESS-Assemblys verfügen außerdem über folgende Berechtigungen und Werte:
Berechtigung |
Wert(e)/Beschreibung |
|---|---|
DistributedTransactionPermission |
Unrestricted: Verteilte Transaktionen sind zulässig. |
DNSPermission |
Unrestricted: Berechtigung zum Anfordern von Informationen von DNS-Servern. |
EnvironmentPermission |
Unrestricted: Der vollständige Zugriff auf System- und Benutzerumgebungsvariablen ist zulässig. |
EventLogPermission |
Administer: Folgende Aktionen sind zulässig: Erstellen einer Ereignisquelle, Lesen vorhandener Protokolle, Löschen von Ereignisquellen oder -protokollen, Reagieren auf Einträge, Löschen eines Ereignisprotokolls, Überwachen von Ereignissen und Zugreifen auf eine Auflistung sämtlicher Ereignisprotokolle. |
FileIOPermission |
Unrestricted: Der vollständige Zugriff auf Dateien und Ordner ist zulässig. |
KeyContainerPermission |
Unrestricted: Der vollständige Zugriff auf Schlüsselcontainer ist zulässig. |
NetworkInformationPermission |
Access: Die Pingausführung ist zulässig. |
RegistryPermission |
Lässt Leseberechtigungen für HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIG und HKEY_USERS. zu. |
SecurityPermission |
Assertion: Die Fähigkeit zu bestätigen, dass alle Aufrufer dieses Codes über die erforderliche Berechtigung für den Vorgang verfügen. ControlPrincipal: Die Fähigkeit zum Verändern des Hauptobjekts. Execution: Berechtigung zur Ausführung von verwaltetem Code. SerializationFormatter: Die Fähigkeit zum Bereitstellen von Serialisierungsdiensten. |
SmtpPermission |
Access: Ausgehende Verbindungen an den Anschluss 25 des SMTP-Hosts werden zugelassen. |
SocketPermission |
Connect: Ausgehende Verbindungen (alle Ports, alle Protokolle) auf einer Transportadresse werden zugelassen. |
SqlClientPermission |
Unrestricted:Der vollständige Zugriff auf die Datenquelle ist zulässig. |
StorePermission |
Unrestricted: Der vollständige Zugriff auf X.509-Zertifikatspeicher ist zulässig. |
WebPermission |
Connect: Ausgehende Verbindungen an Webressourcen werden zugelassen. |
UNSAFE
UNSAFE ermöglicht Assemblys den uneingeschränkten Zugriff auf Ressourcen innerhalb und außerhalb von SQL Server. Code, der innerhalb einer UNSAFE-Assembly ausgeführt wird, kann außerdem nicht verwalteten Code aufrufen.
UNSAFE-Assemblys erhalten FullTrust.
.gif "Sicherheitshinweis") Sicherheitshinweis |
|---|
SAFE ist die empfohlene Berechtigungseinstellung für Assemblys, die Berechnungs- und Datenverwaltungstasks 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. EXTERNAL_ACCESS-Code kann explizit die Identität des Aufrufers in Bezug auf den Sicherheitskontext der Windows-Authentifizierung annehmen. Aufgrund der standardmäßigen Ausführung als SQL Server-Dienstkonto sollte die Berechtigung zur Ausführung von EXTERNAL_ACCESS nur vertrauenswürdigen Logins, die als Dienstkonto ausgeführt werden, erteilt werden. Aus Sicht der Sicherheit sind die EXTERNAL_ACCESS-Assembly und die UNSAFE-Assembly identisch. EXTERNAL_ACCESS-Assemblys bieten gegenüber UNSAFE-Assemblys jedoch ein Mehr an Zuverlässigkeit und Stabilität. Das Festlegen von UNSAFE ermöglicht es Code in der Assembly, nicht zulässige Vorgänge im Prozessbereich von SQL Server auszuführen. Dies hat eine potenzielle Gefährdung der Stabilität und Skalierbarkeit von SQL Server zur Folge. Weitere Informationen zum Erstellen von CLR-Assemblys in SQL Server finden Sie unter Verwalten von CLR-Integrationsassemblys. |
Zugreifen auf externe Ressourcen
Wenn ein benutzerdefinierter Typ (UDT), eine gespeicherte Prozedur oder eine andere Konstruktassembly mit dem SAFE-Berechtigungssatz registriert wird, kann der verwaltete Code, der in dem Konstrukt ausgeführt wird, nicht auf externe Ressourcen zugreifen. Wenn jedoch entweder der EXTERNAL_ACCESS-Berechtigungssatz oder der UNSAFE-Berechtigungssatz angegeben wird und der verwaltete Code versucht, auf externe Ressourcen zuzugreifen, wendet SQL Server folgende 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. |
Der Zugriff auf die externe Ressource erfolgt im Sicherheitskontext des SQL Server-Dienstkontos. |
Bei dem Aufrufer handelt es sich nicht um den ursprünglichen Aufrufer. |
Der Zugriff wird verweigert, und eine Sicherheitsausnahme wird ausgelöst. |
Der Ausführungskontext entspricht einer Windows-Anmeldung und stimmt mit dem ursprünglichen Aufrufer überein. Die Identität des Aufrufers wurde angenommen. |
Für den Zugriff wird anstelle des Dienstkontos der Sicherheitskontext des Aufrufers verwendet. |
Zusammenfassung des Berechtigungssatzes
Das folgende Diagramm fasst die Einschränkungen und Berechtigungen zusammen, die den Berechtigungssätzen SAFE, EXTERNAL_ACCESS und UNSAFE erteilt werden.
SAFE |
EXTERNAL_ACCESS |
UNSAFE |
|
Code Access Security Permissions |
Nur ausführen |
Ausführen + Zugriff auf externe Ressourcen |
Uneingeschränkt (einschließlich P/Invoke) |
Programming model restrictions |
Ja |
Ja |
Keine Einschränkungen |
Verifiability requirement |
Ja |
Ja |
Nein |
Local data access |
Ja |
Ja |
Ja |
Ability to call native code |
Nein |
Nein |
Ja |
Siehe auch
Konzepte
Sicherheit der CLR-Integration
Hostschutzattribute und Programmierung der CLR-Integration
Beschränkungen des Programmiermodells für die CLR-Integration