Identitätswechsel und Sicherheit der CLR-Integration
Wenn verwalteter Code auf externe Ressourcen zugreift, dann nimmt SQL Server nicht automatisch die Identität des aktuellen Ausführungskontexts an, in dem die Routine ausgeführt wird. Der in einer EXTERNAL_ACCESS-Assembly und einer UNSAFE-Assembly enthaltene Code kann explizit die Identität des aktuellen Ausführungskontexts annehmen.
.gif "Hinweis") Hinweis |
|---|
In SQL Server 2008 bestehen Verhaltensunterschiede beim Identitätswechsel. Weitere Informationen finden Sie unter Fehlerhafte Änderungen an Features des Datenbankmoduls in SQL Server 2008. |
Der prozessinterne Datenzugriffsanbieter stellt die Anwendungsprogrammierschnittstelle SqlContext.WindowsIdentity zur Verfügung, mit der das Token abgerufen werden kann, das dem aktuellen Sicherheitskontext zugeordnet ist. In EXTERNAL_ACCESS-Assemblys und UNSAFE-Assemblys enthaltener verwalteter Code kann mit dieser Methode den Kontext abrufen und die WindowsIdentity.Impersonate-Methode aus .NET Framework verwenden, um die Identität dieses Kontexts anzunehmen. Die folgenden Einschränkungen gelten, wenn Benutzercode explizit einen Identitätswechsel durchführt:
Der prozessinterne Datenzugriff ist nicht zulässig, wenn für verwalteten Code ein Identitätswechsel durchgeführt wurde. Code kann den Identitätswechsel rückgängig machen und dann den prozessinternen Datenzugriff aufrufen. Beachten Sie, dass hierzu der Rückgabewert (ein WindowsImpersonationContext-Objekt) der ursprünglichen Impersonate-Methode gespeichert und die Undo-Methode für dieses WindowsImpersonationContext-Objekt aufgerufen werden muss.
Diese Einschränkung bedeutet, dass ein prozessinterner Datenzugriff stets im Kontext des aktuellen Sicherheitskontexts erfolgt, der für die Sitzung gilt. Er kann nicht durch einen explizitem Identitätswechsel innerhalb des verwalteten Codes geändert werden.
Bei verwaltetem Code, der asynchron ausgeführt wird (beispielsweise durch UNSAFE-Assemblys, die Threads erzeugen und Code asynchron ausführen) werden keine prozessinterne Datenzugriffe zugelassen. Dies gilt unabhängig davon, ob ein Identitätswechsel vorgenommen wird.
Wenn Code in einem Kontext ausgeführt wird, dessen Identität angenommen wurde und der sich von SQL Server unterscheidet, dann kann er keine Aufrufe für prozessinterne Datenzugriffe ausführen. Bevor Aufrufe für prozessinterne Datenzugriffe ausgeführt werden, sollte der Identitätswechsel rückgängig gemacht werden. Wenn ein prozessinterner Datenzugriff aus verwaltetem Code erfolgt, dann wird immer der ursprüngliche Ausführungskontext des Transact-SQL-Einstiegspunkts in den verwalteten Code zur Autorisierung verwendet.
Sowohl EXTERNAL_ACCESS-Assemblys als auch UNSAFE-Assemblys greifen über das SQL Server-Dienstkonto auf Betriebssystemressourcen zu, sofern sie nicht freiwillig den aktuellen Sicherheitskontext wie oben beschrieben annehmen. Daher benötigen die Autoren von EXTERNAL_ACCESS-Assemblys eine höhere Vertrauensebene als die Autoren von SAFE-Assembly; die Vertrauensebene wird durch die EXTERNAL ACCESS-Berechtigung auf Anmeldungsebene festgelegt. Nur Anmeldekonten, die vertrauenswürdig sind und unter dem SQL Server-Dienstkonto Code ausführen dürfen, sollten die EXTERNAL ACCESS-Berechtigung erhalten.