Die TRUSTWORTHY Eigenschaft einer Datenbank (wenn auf ON gesetzt ) deklariert SQL Server im Wesentlichen, dass Code, der in dieser Datenbank enthalten ist und in einem imitierten Kontext ausgeführt wird, außerhalb dieser Datenbank zugänglich sein sollte, während dieser imitierte Sicherheitskontext beibehalten wird. Es erlaubt auch alle SQLCLR-Assemblys in dieser Datenbank, die auf EXTERNAL_ACCESS festgelegt werden sollen und UNSAFE , unabhängig davon, ob dieser Code den Server verlässt oder nicht (externe Bedeutung:Netzwerkzugriff, Dateisystemzugriff, Registrierungszugriff, Umgebungszugriff usw.).
Es ist ein eher allgemeines Mittel, um dies zu ermöglichen, da es den gesamten Code innerhalb der Datenbank abdeckt. Die Verwendung von Zertifikaten und/oder asymmetrischen Schlüsseln zum Signieren von Modulen – Prozeduren und/oder Assemblys – ermöglicht eine genauere Kontrolle darüber, welcher Code welche Berechtigungen hat.
Setzen einer Datenbank auf TRUSTWORTHY ermöglicht auch, dass jeder Prozess, der in dieser Datenbank beginnt, bis zur Serverebene und/oder zu anderen Datenbanken reicht. Normalerweise wird ein Prozess auf die Datenbank beschränkt / unter Quarantäne gestellt, in der er gestartet wurde. Wenn die Datenbank dem "sa"-Login gehört, dann hat jeder Prozess, der in dieser Datenbank initiiert wurde und als "dbo" läuft, effektiv "sa"-Privilegien (yikes!).
Anstatt zu versuchen, hier in der Menge an Details zu beschreiben, die erforderlich sind, um die Besonderheiten des Identitätswechsels, der Erweiterung des Identitätswechsels, des Signierens von Modulen usw. vollständig zu kommunizieren, empfehle ich, die folgenden Ressourcen zu diesem Thema zu lesen:
- BITTE, bitte , hören Sie bitte auf, Identitätswechsel, TRUSTWORTHY und DB-übergreifende Eigentumsverkettung zu verwenden
- Richtlinien für die Verwendung der Datenbankeinstellung TRUSTWORTHY in SQL Server
- Datenbankidentitätswechsel durch Verwendung von EXECUTE AS erweitern
Dies ist ein sehr informatives Dokument, das die meisten Aspekte dieses Themas abdeckt und auf das auch auf der oben verlinkten Seite verwiesen wird. - Treppe zu SQLCLR Level 4:Sicherheit (EXTERNE und UNSAFE-Assemblies)
Dies ist ein Artikel, den ich als Teil einer Reihe über SQLCLR geschrieben habe, der Beispiele enthält, die die Unterschiede zwischen der TRUSTWORTHY-Methode und der Signed-Assembly-basierten Anmeldemethode veranschaulichen; Eine kostenlose Registrierung ist erforderlich.
Sie sollten Ihre Datenbank nicht auf TRUSTWORTHY setzen so viel wie möglich. Wenn Sie wirklich Multithreading-/Async-Aufrufe haben müssen UND wenn Sie den Quellcode haben und die Assembly kompilieren, dann kann ich mir keinen Grund vorstellen, den SET TRUSTWORTHY ON zu verwenden Möglichkeit. Stattdessen sollten Sie die Assembly mit einem Passwort signieren und verwenden Sie die folgenden Befehle, um die bevorzugte Methode zum Zulassen von EXTERNAL_ACCESS einzurichten und UNSAFE Baugruppen:
USE [master];
CREATE ASYMMETRIC KEY [ClrPermissionsKey]
AUTHORIZATION [dbo]
FROM EXECUTABLE FILE = 'C:\path\to\my\assembly.dll';
CREATE LOGIN [ClrPermissionsLogin]
FROM ASYMMETRIC KEY [ClrPermissionsKey];
GRANT UNSAFE ASSEMBLY TO [ClrPermissionsLogin];
Sobald dies eingerichtet ist, können Sie zu der Datenbank gehen, in die Ihre Assembly geladen und ausgeführt wurde:
ALTER ASSEMBLY [MyAssembly] WITH PERMISSION_SET = UNSAFE;
Oder Sie hätten WITH PERMISSION_SET = UNSAFE einfügen können am Ende von CREATE ASSEMBLY Befehl.
