Design assemblies

Applies to:SQL Server

In diesem Artikel werden die folgenden Faktoren beschrieben, die Sie beim Entwerfen von Assemblys berücksichtigen sollten:

• Packaging assemblies
• Verwalten der Assemblysicherheit
• Einschränkungen für Assemblys

Package assemblies

Eine Assembly kann Funktionen für mehrere SQL Server-Routinen oder -Typen in den Klassen und Methoden enthalten. In den meisten Fällen ist es sinnvoll, die Funktionen von Routinen, die verwandte Funktionen ausführen, in der gleichen Assembly zu verpacken, insbesondere, wenn diese Routinen Klassen gemeinsam verwenden, deren Methoden sich gegenseitig aufrufen. Klassen, die Dateneingabe-Verwaltungstasks für CLR-Trigger (Common Language Runtime) und CLR-gespeicherte Prozeduren ausführen, können z. B. in der gleichen Assembly verpackt werden. Dies liegt daran, dass sich die Methoden für diese Klassen eher gegenseitig aufrufen als Methoden weniger verwandter Aufgaben.

Berücksichtigen Sie beim Packen von Code in der Assembly Folgendes:

• CLR-benutzerdefinierte Typen und Indizes, die von CLR-benutzerdefinierten Funktionen abhängen, können bewirken, dass sich persistente Daten in der Datenbank befinden, die von der Assembly abhängen. Das Ändern des Codes einer Assembly ist häufig komplexer, wenn gespeicherte Daten vorhanden sind, die von der Assembly in der Datenbank abhängen. Daher ist es besser, Code zu trennen, auf dem beibehaltene Datenabhängigkeiten (z. B. benutzerdefinierte Typen und Indizes mit benutzerdefinierten Funktionen) von Code getrennt werden, der nicht über diese dauerhaften Datenabhängigkeiten verfügt. For more information, see Implement assemblies and ALTER ASSEMBLY.

• Wenn ein Teil von verwaltetem Code eine höhere Berechtigung erfordert, ist es besser, diesen Code in eine separate Assembly vom Code zu trennen, der keine höhere Berechtigung erfordert.

Codezugriffssicherheit wird nicht mehr unterstützt

CLR verwendet die Codezugriffssicherheit (Code Access Security, CAS) im .NET Framework, die nicht länger als Sicherheitsbegrenzung unterstützt wird. Eine CLR-Assembly, die mit PERMISSION_SET = SAFE erstellt wurde, kann womöglich auf externe Systemressourcen zugreifen, nicht verwalteten Code aufrufen und sysadmin-Privilegien erwerben. In SQL Server 2017 (14.x) und höheren Versionen verbessert die sp_configure Option clr strict security die Sicherheit von CLR-Assemblys. clr strict security ist standardmäßig aktiviert und behandelt SAFE- und EXTERNAL_ACCESS-Assemblys so, als wären Sie als UNSAFE gekennzeichnet. Die Option clr strict security kann für die Abwärtskompatibilität deaktiviert werden, es wird jedoch nicht empfohlen.

Es wird empfohlen, dass Sie alle Assemblys durch ein Zertifikat oder einen asymmetrischen Schlüssel mit einem entsprechenden Anmeldenamen signieren, dem UNSAFE ASSEMBLY-Berechtigung für die master-Datenbank gewährt wurde. SQL Server-Administratoren können auch Assemblys einer Liste von Assemblys hinzufügen, der die Datenbank-Engine vertrauen sollte. For more information, see sys.sp_add_trusted_assembly.

Verwalten der Assemblysicherheit

Sie können steuern, im welchem Umfang eine Assembly auf Ressourcen zugreifen kann, die durch .NET Code Access Security geschützt ist, wenn diese verwalteten Code ausführt. Dazu geben Sie einen von drei Berechtigungssätzen an, wenn Sie eine Assembly erstellen oder ändern: SAFE, EXTERNAL_ACCESS, oder UNSAFE.

SAFE permission

SAFE ist der Standardberechtigungssatz und ist der restriktivste. Code, der von einer Assembly mit SAFE Berechtigungen ausgeführt wird, kann nicht auf externe Systemressourcen wie Dateien, Das Netzwerk, Umgebungsvariablen oder die Registrierung zugreifen. SAFE Code kann auf Daten aus den lokalen SQL Server-Datenbanken zugreifen oder Berechnungen und Geschäftslogik ausführen, die keinen Zugriff auf Ressourcen außerhalb der lokalen Datenbanken erfordern.

Die meisten Assemblys führen Berechnungs- und Datenverwaltungsaufgaben durch, ohne auf Ressourcen außerhalb von SQL Server zugreifen zu müssen. Daher wird SAFE empfohlen, als Assemblyberechtigungssatz festzulegen.

EXTERNAL_ACCESS permission

EXTERNAL_ACCESS ermöglicht Assemblys den Zugriff auf bestimmte externe Systemressourcen wie Dateien, Netzwerke, Webdienste, Umgebungsvariablen und die Registrierung. Nur SQL Server-Anmeldungen mit EXTERNAL ACCESS Berechtigungen können Assemblys erstellen EXTERNAL_ACCESS .

SAFE und EXTERNAL_ACCESS Assemblys können nur Code enthalten, der nachweislich typsicher ist. Dies bedeutet, dass diese Assemblys auf Klassen nur über definierte Einstiegspunkte zugreifen können, die für die Typdefinition gültig sind. Daher können sie nicht willkürlich auf Speicherpuffer zugreifen, die nicht im Besitz des Codes sind. Darüber hinaus können sie keine Vorgänge ausführen, die sich negativ auf die Stabilität des SQL Server-Prozesses auswirken können.

UNSAFE permission

UNSAFE bietet Assemblys uneingeschränkten Zugriff auf Ressourcen, sowohl innerhalb als auch außerhalb von SQL Server. Code, der in einer UNSAFE Assembly ausgeführt wird, kann nicht verwalteten Code aufrufen.

Außerdem ermöglicht die Angabe UNSAFE , dass der Code in der Assembly Vorgänge ausführt, die vom CLR-Prüfer als typunsicher eingestuft werden. Diese Vorgänge können potenziell auf Speicherpuffer im SQL Server-Prozessbereich auf unkontrollierte Weise zugreifen. UNSAFE Assemblys können das Sicherheitssystem entweder von SQL Server oder der Common Language Runtime möglicherweise subvertieren. UNSAFE Berechtigungen sollten nur von erfahrenen Entwicklern oder Administratoren streng vertrauenswürdigen Assemblys erteilt werden. Only members of the sysadmin fixed server role can create UNSAFE assemblies.

Einschränkungen für Assemblys

SQL Server legt bestimmte Einschränkungen für verwalteten Code in Assemblys fest, um sicherzustellen, dass sie zuverlässig und skalierbar ausgeführt werden können. Dies bedeutet, dass bestimmte Vorgänge, die die Stabilität des Servers gefährden können, in SAFE und EXTERNAL_ACCESS Assemblys nicht zulässig sind.

Nicht zulässige benutzerdefinierte Attribute

Assemblys können nicht mit den folgenden benutzerdefinierten Attributen kommentiert werden:

System.ContextStaticAttribute
System.MTAThreadAttribute
System.Runtime.CompilerServices.MethodImplAttribute
System.Runtime.CompilerServices.CompilationRelaxationsAttribute
System.Runtime.Remoting.Contexts.ContextAttribute
System.Runtime.Remoting.Contexts.SynchronizationAttribute
System.Runtime.InteropServices.DllImportAttribute
System.Security.Permissions.CodeAccessSecurityAttribute
System.STAThreadAttribute
System.ThreadStaticAttribute

SAFE EXTERNAL_ACCESS Darüber hinaus können Assemblys nicht mit den folgenden benutzerdefinierten Attributen kommentiert werden:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

Unzulässige .NET Framework-APIs

Jede .NET Framework-API, die mit einem der unzulässigen HostProtectionAttributes versehen ist, kann nicht aus SAFE- und EXTERNAL_ACCESS Assemblys aufgerufen werden.

HostProtectionAttribute.SelfAffectingProcessMgmt
HostProtectionAttribute.SelfAffectingThreading
HostProtectionAttribute.Synchronization
HostProtectionAttribute.SharedState
HostProtectionAttribute.ExternalProcessMgmt
HostProtectionAttribute.ExternalThreading
HostProtectionAttribute.SecurityInfrastructure
HostProtectionAttribute.MayLeakOnAbort
HostProtectionAttribute.UI

Unterstützte .NET Framework-Assemblys

Jede Assembly, auf die von der benutzerdefinierten Assembly verwiesen wird, muss mithilfe CREATE ASSEMBLYvon SQL Server in SQL Server geladen werden. Die folgenden .NET Framework-Assemblys werden bereits in SQL Server geladen und können daher von benutzerdefinierten Assemblys ohne Verwendung CREATE ASSEMBLYreferenziert werden.

• mscorlib.dll
• CustomMarshalers.dll
• Microsoft.VisualBasic.dll
• Microsoft.VisualC.dll
• System.Configuration.dll
• System.Core.dll
• System.Data.OracleClient.dll
• System.Data.SqlXml.dll
• System.Data.dll
• System.Deployment.dll
• System.Security.dll
• System.Transactions.dll
• System.Web.Services.dll
• System.Xml.Linq.dll
• system.Xml.dll
• System.dll

Related content

• Assemblys (Database Engine)
• CLR-Integrationssicherheit