Wie signiere ich eine unsichere C# CLR und Assemblys, die ich benutze, anstatt die Datenbank vertrauenswürdig auf

Question

setzen Ich verwende .NET DirectoryServices und DirectoryServices.AccountManagement in meinem C# CLR-Code. Ich möchte in meiner SQL Server-Datenbank als eine unsichere CLR gespeicherte Prozedur veröffentlichen. In Visual Studio habe ich mein CLR-Projekt unterschrieben. Ich möchte vermeiden, dass Trustworthy aktiviert wird. Wie signiere ich die Baugruppen? Ich weiß, das klingt ziemlich einfach, aber ich habe 4 Stunden auf Google gesucht, ohne eine Antwort zu finden. Ich dachte, ich wäre ziemlich nah dran, als ich Stairway zu CLR heruntergeladen habe, aber ich konnte die Antwort dort nicht finden.

Answer 1

Zuerst: Vielen Dank, dass Sie nicht die einfache Route gehen und TRUSTWORTHY aktivieren. Ernst. Es ist nicht so viel Arbeit, dies richtig zu machen, also schätze ich (und dein Arbeitgeber) es, wenn du mehr Nachforschungen anstellst, und wenn du nicht weiter kamst, um Hilfe zu holen.

Wenn Sie auf die "Stairway to SQLCLR" -Serie auf SQL Server Central beziehen, bin ich der Autor dieser Artikel. Es tut mir leid, wenn die Informationen nicht leicht zu verstehen waren. Ich werde die Schritte hier skizzieren:

1. In Visual Studio, unterzeichnen Sie die Assembly mit einem starken Namen Key, und schützen sie mit einem Passwort (Sie haben dies bereits getan, nach der Frage)

2. Je nach was Sie tun, und die allgemeinen Anforderungen, haben Sie einige Möglichkeiten:

   1. Wenn Ihr Assembly Code verwendet wird, die Flagge auf der Überprüfungsschritt eine Verletzung tut, wenn sie über CREATE ASSEMBLY erstellt wird, dann Sie können technisch Last die Versammlung in [master], markiert als SAFE, um daraus den Asymmetrischen Schlüssel zu erstellen (Sie werden den Code hier nicht ausführen, so dass er hier nicht als UNSAFE markiert sein muss).
   2. Wenn Ihr Code die Verifizierung nicht besteht (dh er kann nur erstellt werden, wenn er als UNSAFE markiert ist), finde ich es am besten, eine separate, leere Assembly zu erstellen, die ebenfalls mit derselben Strong Name Key-Datei signiert ist (zB .pfx) Datei), die für die Hauptbaugruppe verwendet wird. Ich lade dann, leer, noch unterzeichnet, Versammlung in [master], markiert als SAFE
   3. Wenn Sie mit SQL Server 2017 umgehen müssen, dann erfordert das einen zusätzlichen Schritt, den ich gleich erwähnen werde.

3. Sobald Sie eine Assembly in [master] erstellt haben, die mit der gleichen .pfx Datei signiert wurden, der verwendet wurde Ihre Haupt, UNSAFE Versammlung zu unterzeichnen, dann können Sie einfach erstellen, in [master], einen asymmetrischen Schlüssel von dieser Versammlung.

4. erstellen Anmeldung von diesem asymmetrischen Schlüssel

5. Grants, dass Key-basierte Login der UNSAFE ASSEMBLY Erlaubnis

Diese Schritte für SQL Server arbeiten 2005-2016 und ich biete Anweisungen zum Automatisieren Sie dies (Option 2 oben - Verwenden einer separaten, leeren, signierten Assembly) in Visual Studio im Artikel Stairway to SQLCLR Level 7: Development and Security. (Übrigens, ich weiß, dass die in Level 7 beschriebenen Schritte zugegebenermaßen ein bisschen viel sind, aber sie bieten ein Mittel zur Automatisierung mit Visual Studio UND sie können durch die Verwendung von T4-Vorlagen vereinfacht werden - die mit VS geliefert wird - aber ich habe Es war noch Zeit, den vereinfachten Ansatz zu schreiben - hoffentlich bald.

Wenn Sie jedoch SQL Server 2017 (oder neuer, vermutlich) berücksichtigen müssen, funktionieren die obigen Schritte nicht, da nicht einmal SAFE Assemblys erstellt werden können, ohne signiert zu sein und den entsprechenden signaturbasierten Login zu haben das hat die UNSAFE ASSEMBLY Erlaubnis. Und leider erlaubt CREATE ASYMMETRIC KEY nicht für die Erstellung aus einem Hexadezimalbyte Zeichenfolge/VARBINARY Literal, so dass Sie ein Zertifikat verwenden müssen, die auf diese Weise erstellt werden können. In diese Richtung habe ich zwei Blog-Posts, das Detail, Schritt-für-Schritt, wie dies zu erreichen, vollständig über Visual Studio automatisierte (oder auch nicht mit Visual Studio):

• SQLCLR vs. SQL Server 2017, Part 2: “CLR strict security” – Solution 1 — diesen den Ansatz nutzt beschrieben in Stairway to SQLCLR Level 7: Entwicklung und Sicherheit als Grundlage, und aktualisiert es in der neuen Contraint arbeiten.
• SQLCLR vs. SQL Server 2017, Part 3: “CLR strict security” – Solution 2 — dies ist ein stark vereinfachte Ansatz, Zertifikate mit nur

Was immer Sie tun, tun nicht in getäuscht werden das neue „Trusted Assemblies“ Feature von SQL Server 2017 verwenden, da es zahlreiche Probleme damit, wie hier beschrieben: SQLCLR vs. SQL Server 2017, Part 4: “Trusted Assemblies” – The Disappointment und noch ein Beitrag, an dem ich gerade arbeite.

diesen unnötig schmerzhaften Prozess zu verbessern helfen, bitte meine Verbesserungsvorschläge unterstützen CREATE ASYMMETRIC KEY und SSDT zu verbessern:

• Allow Asymmetric Key to be created from binary hex bytes string just like CREATE CERTIFICATE (SQLCLR) — diese allein die Mehrheit der Schritte in jedem der Ansätze oben erwähnt, verringern würden und sogar die Notwendigkeit reduzieren die zertifikatsbasierte Optionen zu haben, da die asymmetrische Key-Option für alles funktionieren würde, auch innerhalb der neuen „clr strengen Sicherheits“ Einschränkung in SQL Server starten 2017.
• Add function to extract Asymmetric Key similar to CERTENCODED for Certificates (SQLCLR/SSDT)
• Add MSBuild predefined Targets for "BeforeSqlBuild" and "BeforePublish" to SSDT SQL Server Database Projects

Answer 2

Wir haben mehrere ältere Projekte, für die dies benötigt wird. Bis zu dieser Woche, als ich mir die Zeit nahm, das herauszufinden, hatten wir die gefürchtete Trustworthy-Flagge benutzt.

Nach ein paar Recherchen konnte ich dies ziemlich schmerzlos einrichten, indem ich ein Pre-Deployment-SQL-Skript in meinem Visual Studio-Projekt und einige einmalige Setups verwendete. This article hat mir am meisten geholfen.

Ich habe getestet und bestätigt dies funktioniert in:

• SQL Server 2008 R2
• SQL Server 2012
• SQL Server 2014
• SQL Server 2016

Schritte:

1. Erstellen Sie einen neuen starken Namensschlüssel Entwickler Eingabeaufforderung für Visual Studio und das Schreiben mit:

   sn -k ".\CLRKey.snk" 
   

2. In Ihren Visual Studio Projekteinstellungen, in dem SQLCLR Bereich, klicken Sie auf die Signing-Taste und wählen Sie Ihre Montag unterzeichnen Surfen auf die Schlüsseldatei, die Sie gerade erstellt haben:

3. Kopieren CLRKey.snk-C:\ jedes Ziel-SQL-Server oder einem anderen Pfad, der Server lesen kann.

4. Dieses Pre-Deployment Skript zu Ihrem Visual Studio-Projekt, den Schlüsselpfad und ein Passwort Anpassung Ihrer Umgebung zu passen:

   DECLARE @sp nvarchar(255) = '$(DatabaseName)..sp_executesql'; 
   DECLARE @create_user nvarchar(4000) = N'CREATE USER [CLRExtensionLogin] FOR LOGIN [CLRExtensionLogin]' 
   DECLARE @MSG varchar(8000) 
   
   use master; 
   BEGIN TRY 
   BEGIN TRAN 
   
       IF NOT EXISTS (select 1 from sys.asymmetric_keys where name=N'CLRExtensionKey') BEGIN 
        create asymmetric key CLRExtensionKey 
        from file = 'c:\CLRKey.snk' 
        encryption by password = '<invent a password>' 
        RAISERROR('Key created.', 0, 1) WITH NOWAIT 
       END ELSE BEGIN 
        RAISERROR('Key exists.', 0, 1) WITH NOWAIT 
       END 
   
       IF NOT EXISTS (SELECT * FROM sys.syslogins WHERE name=N'CLRExtensionLogin') BEGIN 
        CREATE LOGIN CLRExtensionLogin FROM ASYMMETRIC KEY CLRExtensionKey; 
        EXEC @sp @create_user 
        RAISERROR('User created.', 0, 1) WITH NOWAIT 
       END ELSE BEGIN 
        RAISERROR('User exists.', 0, 1) WITH NOWAIT 
       END 
   
       GRANT EXTERNAL ACCESS ASSEMBLY, UNSAFE ASSEMBLY TO [CLRExtensionLogin]; 
       COMMIT TRAN 
   
       SET @MSG = 'Assembly access granted.' + CHAR(10) + 'Done.' 
       RAISERROR(@MSG, 0, 1) WITH NOWAIT 
   END TRY 
   BEGIN CATCH 
       SET @MSG = ERROR_MESSAGE() + CHAR(10) + 'Aborted.' 
       RAISERROR(@MSG, 16, 1) 
       IF @@TRANCOUNT > 0 ROLLBACK 
   END CATCH 
   
   USE [$(DatabaseName)]; 
   

Solange SQL Server in diesem Schlüssel lesen kann Wenn das Skript zum ersten Mal ausgeführt wird, sollten Sie in der Lage sein, auf dem gleichen Server frei zu veröffentlichen, ohne sich um das Ganze kümmern zu müssen.

Wenn Sie andere Projekte haben, die auf demselben Server veröffentlichen, müssen Sie sie nur mit demselben Schlüssel wie in Schritt 2 signieren, aber es wäre eine bewährte Methode, eine Verbindung zu derselben Vorbereitungsgruppe herzustellen Skript in allen Ihren Projekten, falls Sie irgendwann einen auf einem anderen Server veröffentlichen möchten. Hoffe das hilft!