MSDN auf dieser Artikel sagt:
CLR verwendet Code Access Security (CAS) im .NET Framework, das ist keine länger als Sicherheitsgrenze unterstützt. Eine CLR-Assembly, die mit erstellt wurde PERMISSION_SET = SAFE kann möglicherweise auf externe Systemressourcen zugreifen Rufen Sie nicht verwalteten Code auf und erwerben Sie Systemadministratorberechtigungen. Mit ... anfangen SQL Server 2017, eine sp_configure-Option namens clr strict security ist eingeführt, um die Sicherheit von CLR-Baugruppen zu verbessern. clr streng Die Sicherheit ist standardmäßig aktiviert und behandelt SAFE und EXTERNAL_ACCESS Versammlungen, als ob sie als UNSAFE markiert wären. Die clr strenge Sicherheit Option kann aus Gründen der Abwärtskompatibilität deaktiviert werden, dies ist jedoch nicht möglich empfohlen. Microsoft empfiehlt, dass alle Assemblys von einem signiert werden Zertifikat oder asymmetrischer Schlüssel mit einem entsprechenden Login in der master-Datenbank die Berechtigung UNSAFE ASSEMBLY erteilt.
Wie kann eine mit PERMISSION_SET = SAFE erstellte CLR-Assembly möglicherweise auf externe Systemressourcen zugreifen, nicht verwalteten Code aufrufen und Systemadministratorberechtigungen erwerben?
Warum wird CAS nicht mehr als Sicherheitsgrenze unterstützt?
Wie ich verstehe, können CLR-Baugruppen nicht mehr sicher sein, was sehr bedauerlich ist.
Wie kann eine CLR-Assembly, die mit PERMISSION_SET = SAFE erstellt wurde, möglicherweise auf externe Systemressourcen zugreifen, nicht verwalteten Code aufrufen und Systemadministratorberechtigungen erwerben?
Dies ist auf Sicherheitsänderungen in .NET Framework zurückzuführen, die in Version 4.5 (glaube ich) beginnen.
MSDN-Dokumentation für Grundlagen zu Codezugriffssicherheit :
Das .NET Framework bietet einen Mechanismus zum Erzwingen unterschiedlicher Vertrauensstufen bei unterschiedlichem Code, der in derselben Anwendung ausgeführt wird, der so genannten Code Access Security (CAS). Codezugriffssicherheit in .NET Framework sollte nicht als Mechanismus zum Erzwingen von Sicherheitsgrenzen auf der Grundlage von Code-Origination oder anderen Identitätsaspekten verwendet werden. Wir aktualisieren unsere Anleitung, um zu reflektieren, dass Code Access Security und Security-Transparent Code nicht als Sicherheitsgrenze mit teilweise vertrauenswürdigem Code, insbesondere Code unbekannter Herkunft, unterstützt wird. Wir raten davon ab, Code unbekannter Herkunft zu laden und auszuführen, ohne alternative Sicherheitsmaßnahmen zu treffen.
Und verweist dann auf die Seite für Sicherheitsänderungen im .NET Framework , die besagt:
Die wichtigste Sicherheitsänderung in .NET Framework 4.5 ist die starke Benennung.
Was dann auf die Dokumentation für Enhanced Strong Naming verweist welches besagt:
Starke Namensschlüssel bestehen aus einem Signaturschlüssel und einem Identitätsschlüssel. Die Assembly ist mit dem Signaturschlüssel signiert und wird durch den Identitätsschlüssel identifiziert. Vor .NET Framework 4.5 waren diese beiden Schlüssel identisch. Beginnend mit .NET Framework 4.5 bleibt der Identitätsschlüssel gleich wie in früheren Versionen von .NET Framework. Der Signaturschlüssel wurde jedoch durch einen stärkeren Hash-Algorithmus erweitert. Außerdem wird der Signaturschlüssel mit dem Identitätsschlüssel signiert, um eine Gegensignatur zu erstellen.
Auch in der Dokumentation zu Secure Coding Guidelines heißt es:
Code Access Security und Security - Transparenter Code wird nicht als Sicherheitsgrenze mit teilweise vertrauenswürdigem Code unterstützt. Wir raten davon ab, Code unbekannter Herkunft zu laden und auszuführen, ohne alternative Sicherheitsmaßnahmen zu treffen ...
Das Sicherheitsmodell für .NET hat sich also vor Jahren geändert, aber SQL Server (bis SQL Server 2017) darf weiterhin das alte Sicherheitsmodell verwenden. Es scheint, dass mit SQL Server 2017 entschieden wurde, das alte Sicherheitsmodell nicht mehr zu unterstützen.
Ich vermute, dass das Erlauben des alten Sicherheitsmodells war:
verhindert, dass SQL Server (zumindest die CLR-bezogenen Funktionen / Komponenten) auf den neueren Versionen von .NET Framework basiert und
verantwortlich für die abrupte Entfernung von SQLCLR als unterstütztes Feature aus der Azure SQL-Datenbank (die Unterstützung wurde Ende 2014 mit dem Start von v12 hinzugefügt, wurde aber am 15. April 2016 vollständig entfernt).
> Also, ja, das ist irgendwie scheiße. Was es bedeutet (zumindest im Moment) ist, dass man zuerst ein Zertifikat oder einen asymmetrischen Schlüssel (der zum Signieren von zu ladenden Assemblys verwendet wurde) in [master] erstellt, um dann ein Melden Sie sich an und erteilen Sie UNSAFE ASSEMBLY dem Login. Dies ist die gleiche Abfolge von Ereignissen, die man beim Laden von EXTERNAL_ACCESS und UNSAFE Assemblys durchführen muss, aber jetzt leider für die SAFE Assemblies.
Gegenwärtig gibt es keinen Mechanismus, der dies in einer vollständig tragbaren Weise handhabt (d. h. nicht auf externen Dateien beruht) und nicht von Visual Studio / SSDT ohne manuellen Eingriff gehandhabt werden kann. Das war irgendwie schon der Fall, aber zumindest war es möglich, ein Setup zu erstellen, das dies in einer vollständig portablen Art und Weise (dh vollständig innerhalb eines .sql-Skripts) bewältigt: siehe Stairway zu SQLCLR Level 7: Entwicklung und Sicherheit für Details (das ist ein Artikel, den ich geschrieben habe).
Es ist möglich, ein Zertifikat aus Hex-Bytes (dh FROM BINARY = 0x... ) zu erstellen, aber das funktioniert nicht mit Visual Studio (das auf MSBuild basiert) / SSDT, da die Verwendung von signtool und MSBuild sn benötigt .
Damit dies machbar gemacht wird, damit der Visual Studio / MSBuild / SSDT-Veröffentlichungsprozess funktioniert (was wiederum bedeuten würde, dass jeder in der Lage wäre, ein vollständig eigenständiges .sql-Skript zu erstellen, das den asymmetrischen Schlüssel erzeugen kann) ohne auf eine externe Datei angewiesen zu sein), muss der Befehl CREATE ASYMMETRIC KEY erweitert werden, damit er aus einer Binärzeichenfolge erstellt werden kann.Ich habe diesen Vorschlag für Microsoft Connect gemacht - Erlaube Asymmetrischen Schlüssel aus einer binären Hex-Byte-Zeichenfolge wie CREATE CERTIFICATE zu erstellen - also bitte unterstütze es: -).
Alternativ (im Moment, bis MS hoffentlich eine bessere Methode erstellt, wie zB meine Asymmetric Key-Vorschläge), können Sie eine der beiden Techniken ausprobieren, die ich in den folgenden Blogposts beschreibe (beide arbeiten vollständig mit SSDT):
Als letzter Ort können Sie den folgenden Ansatz in Betracht ziehen:
[master] -Datenbank auf TRUSTWORTHY ON
[master]
[master] -Datenbank auf TRUSTWORTHY OFF
UNSAFE ASSEMBLY an diesen Login Bitte beachten Sie, dass ich nicht die neue Funktion "Trusted Assembly" als Option hinzugefügt habe. Der Grund, warum es nicht erwähnt wurde, liegt darin, dass es viel mehr Mängel als Vorteile hat, ganz zu schweigen davon, dass es überhaupt nicht notwendig ist, da die bestehenden Funktionen bereits die Situation "Trusted Assemblies" behandelten. Ausführliche Informationen dazu und eine Demonstration der korrekten Handhabung von bestehenden, unsignierten Assemblies finden Sie unter: .
Ich bin neulich darauf gestoßen, und es scheint, dass es nicht so schlimm ist, wie es sich anhört (abgesehen davon, dass Sie nicht mehr einfach eine SAFE-Assembly erstellen können, sondern sie unterschreiben müssen, oder TRUSTWORTHY verwenden). .
In meinen Tests:
Das bedeutet für mich, dass es immer noch einige Kontrollen gibt, was ausgeführt wird. Ich folgte dem nach:
Ich bin mir also nicht so sicher, ob die Aussage in der Dokumentation von "clr strict security" zu 100% korrekt ist.
Ich habe einen Blogbeitrag über meine Erfahrungen geschrieben, und Sie können ihn hier finden, wenn Sie ihn selbst ausprobieren möchten: Ссылка
Niels
Tags und Links .net sql-server sqlclr cas sql-server-2017