SQL Server-Programmierung und Hostschutzattribute
Aktualisiert: November 2007
Da auf einem SQL Server-Host verwalteter Code geladen und ausgeführt werden kann, müssen die Anforderungen an die Codezugriffssicherheit und den Ressourcenschutz des Hosts erfüllt sein. Die Anforderungen an die Codezugriffssicherheit werden durch einen der drei SQL Server-Berechtigungssätze SAFE, EXTERNAL-ACCESS oder UNSAFE angegeben. Bei der Codeausführung innerhalb der Berechtigungssätze SAFE oder EXTERNAL-ACCESS müssen bestimmte Typen oder Member, auf die das HostProtectionAttribute-Attribut angewendet wurde, vermieden werden. Das HostProtectionAttribute ist keine Sicherheitsberechtigung, sondern eher eine Verlässlichkeitsgarantie, da es bestimmte Codekonstrukte (Typen oder Methoden) erkennt, die für den Host möglicherweise nicht zulässig sind. Die Verwendung des HostProtectionAttribute erzwingt ein Programmiermodell, mit dem die Stabilität des Hosts besser geschützt werden kann.
Hostschutzattribute
Hostschutzattribute geben die Typen oder Member an, die sich nicht für das Hostprogrammiermodell eignen und die folgenden Zuverlässigkeitsrisiken darstellen (ansteigende Gefährdung):
Sie sind andernfalls ohne Auswirkung.
Sie können zur Destabilisierung von serververwaltetem Benutzercode führen.
Sie können zur Destabilisierung des Serverprozesses führen.
SQL Server lässt keine Typen oder Member mit HostProtectionAttribute zu, das einen HostProtectionResource-Wert von SharedState, Synchronization, MayLeakOnAbort oder ExternalProcessMgmt angibt. Dies verhindert, dass Assemblys Member aufrufen, die die Freigabe des Zustands aktivieren, Synchronisierungen durchführen, einen Ressourcenverlust bei der Beendigung hervorrufen oder die Integrität des SQL Server-Prozesses beeinträchtigen.
Unzulässige Typen und Member
In der folgenden Tabelle sind Typen und Member aufgeführt, deren HostProtectionResource-Werte in SQL Server nicht zulässig sind.
SQL Server-Berechtigungssätze
Benutzer können in SQL Server die Zuverlässigkeitsanforderungen für Code angeben, der in einer Datenbank bereitgestellt wird. Beim Hochladen von Assemblys in die Datenbank kann der Verfasser der Assembly für diese einen von drei Berechtigungssätzen angeben: SAFE, EXTERNAL-ACCESS oder UNSAFE.
Berechtigungssatz |
SAFE |
EXTERNAL-ACCESS |
UNSAFE |
|---|---|---|---|
Codezugriffssicherheit |
Nur Ausführen |
Ausführen + Zugriff auf externe Ressourcen |
Uneingeschränkt |
Einschränkungen des Programmiermodells |
Ja |
Ja |
Keine Einschränkungen |
Überprüfbarkeit erforderlich |
Ja |
Ja |
Nein |
Aufrufbarkeit von systemeigenen Code |
Nein |
Nein |
Ja |
SAFE ist der zuverlässigste und sicherste Modus, der mit Einschränkungen hinsichtlich des zulässigen Programmiermodells einhergeht. Code der Stufe SAFE bietet Features für hohe Zuverlässigkeit und Sicherheit. Assemblys der Stufe SAFE verfügen über ausreichende Berechtigungen für die Ausführung, die Durchführung von Berechnungen und den Zugriff auf die lokale Datenbank. Assemblys der Stufe SAFE müssen nachweislich typsicher sein und dürfen keinen nicht verwalteten Code aufrufen.
EXTERNAL-ACCESS stellt eine mittlere Sicherheitsebene dar, bei der Code auf Ressourcen außerhalb der Datenbank zugreifen kann, die aber dennoch so zuverlässig und sicher wie SAFE ist.
UNSAFE ist für hoch vertrauenswürdigen Code vorgesehen, der nur von Datenbankadministratoren erstellt werden kann. Dieser vertrauenswürdige Code verfügt über keine Codezugriffsbeschränkungen und kann nicht verwalteten (systemeigenen) Code aufrufen.
In SQL Server wird mithilfe der auf Hostebene festgelegten Stufe der Codezugriffssicherheits-Richtlinie eine Hostrichtlinie eingerichtet, die anhand des in den SQL Server-Katalogen gespeicherten Berechtigungssets einen von drei Berechtigungssätzen gewährt. Verwaltetem Code, der in der Datenbank ausgeführt wird, wird immer einer dieser Codezugriffsberechtigungssätze abgerufen.
Einschränkungen des Programmiermodells
Im Programmiermodell für verwalteten Code in SQL Server werden Funktionen, Prozeduren und Typen benötigt, für die weder der über mehrere Aufrufe gespeicherte Zustand noch die Freigabe des Zustands über mehrere Benutzersitzungen erforderlich sind. Darüber hinaus kann ein gespeicherter Zustand, wie bereits erläutert, zu schwerwiegenden Ausnahmen führen, die die Skalierbarkeit und Zuverlässigkeit der Anwendung gefährden können.
Aus diesen Gründen lässt SQL Server keine Verwendung statischer Variablen und Datenmember zu. Bei Assemblys vom Typ SAFE und EXTERNAL-ACCESS untersucht SQL Server bei der Ausführung von CREATE ASSEMBLY die Metadaten der Assembly. Wenn die Verwendung statischer Datenmember oder Variablen ermittelt wird, wird die Assembly nicht erstellt.