CLR-Integration und Codezugriffssicherheit
Die Common Language Runtime (CLR) unterstützt ein Sicherheitsmodell namens Codezugriffssicherheit für verwalteten Code. 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: Dies ist die Richtlinie, die für den gesamten verwalteten Code gilt, der auf dem Computer ausgeführt wird, 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 Dienst ausgeführt wird.
Hostrichtlinie: Dies ist die Richtlinie, die vom Host der CLR (in diesem Fall SQL Server) eingerichtet wird, die für verwalteten Code gilt, 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 Ressourcen, die durch die CLR-Codezugriffssicherheit geschützt sind, werden in der Regel durch verwaltete Anwendungsprogrammierschnittstellen umschlossen, die die entsprechende Berechtigung erfordern, bevor sie den Zugriff auf die Ressource zulassen. Die Anforderung der Berechtigung wird nur erfüllt, wenn alle Aufrufer (auf Assemblyebene) im Aufrufstapel über die entsprechende Ressourcenberechtigung verfügen.
Der Satz von Codezugriffssicherheitsberechtigungen, die verwaltetem Code gewährt werden, wenn in SQL Server ausgeführt wird, gewährt eine Reihe von Berechtigungen für eine Assembly, die in SQL Server geladen wird. Der letztendliche Berechtigungssatz für Benutzercode kann durch die Richtlinien auf Benutzer- und Computerebene weiter eingeschränkt werden.
Berechtigungssätze auf SQL Server Host-Richtlinienebene
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: SAFEund UNSAFEEXTERNAL_ACCESS (wird mithilfe der PERMISSION_SET OptionCREATE ASSEMBLY (Transact-SQL) angegeben.
SQL Server. Diese Richtlinie ist nicht für die Standardanwendungsdomäne vorgesehen, die gültig ist, wenn SQL Server eine Instanz der CLR erstellt.
Die SQL Server fixedpolicy für Systemassemblys und benutzerseitig angegebene Richtlinie für Benutzerassemblys.
Durch die fixed-Richtlinie für CLR-Assemblys und SQL Server-Systemassemblys wird ihnen volle Vertrauenswürdigkeit gewährt.
Der vom Benutzer angegebene Teil der SQL Server Hostrichtlinie basiert darauf, dass der Assemblybesitzer einen von drei Berechtigungs-Buckets 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, 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 folgende Berechtigungen und Werte:
| Berechtigung | Wert(e)/Beschreibung |
|---|---|
DistributedTransactionPermission |
Unrestricted: Verteilte Transaktionen sind zulässig. |
DNSPermission |
Unrestricted: Berechtigung zum Anfordern von Informationen von Domänennamenservern. |
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 uneingeschränkten Zugriff auf Ressourcen innerhalb und außerhalb SQL Server. Code, der innerhalb einer UNSAFE-Assembly ausgeführt wird, kann außerdem nicht verwalteten Code aufrufen.
UNSAFE-Assemblys erhalten FullTrust.
Wichtig
SAFEist die empfohlene Berechtigungseinstellung für Assemblys, die Rechen- und Datenverwaltungsaufgaben ausführen, ohne auf Ressourcen außerhalb SQL Server zuzugreifen. EXTERNAL_ACCESSAssemblys werden standardmäßig als SQL Server Dienstkonto ausgeführt. Die Berechtigung zur Ausführung EXTERNAL_ACCESS sollte nur Anmeldenamen erteilt werden, die vertrauenswürdig sind, um als Dienstkonto ausgeführt zu 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. Die Angabe UNSAFE ermöglicht es dem Code in der Assembly, illegale Vorgänge für den SQL Server auszuführen. 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 die Berechtigungssätze EXTERNAL_ACCESS oder UNSAFE angegeben sind 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. | Der Zugriff auf die externe Ressource erfolgt unter dem 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 der Ausführungskontext ist der ursprüngliche Aufrufer, und der Aufrufer wurde identitätswechselt. | 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 | Yes | Keine Einschränkungen |
Verifiability requirement |
Ja | Ja | Nein |
Local data access |
Ja | Ja | Ja |
Ability to call native code |
Nein | Nein | Ja |
Weitere Informationen
Sicherheit der CLR-Integration
Hostschutzattribute und Programmierung der CLR-Integration
Beschränkungen des Programmiermodells für die CLR-Integration
Gehostete CLR-Umgebung