Comment signer un CLR C# et des assemblys que j'utilise au lieu de mettre la base de données de confiance sur

Question

J'utilise .NET DirectoryServices et DirectoryServices.AccountManagement dans mon code C# CLR. Je souhaite publier dans ma base de données SQL Server en tant que procédure stockée CLR non sécurisée. Dans Visual Studio, j'ai signé mon projet CLR. Je veux éviter d'activer Trustworthy. Comment puis-je également signer les assemblées? Je sais que cela semble assez simple, mais j'ai cherché 4 heures sur google sans trouver de réponse. Je pensais être assez proche quand j'ai téléchargé Stairway to CLR, mais je n'ai pas trouvé la réponse.

Answer 1

Premièrement: Merci de ne pas avoir choisi l'itinéraire facile et d'avoir activé TRUSTWORTHY. Sérieusement. Ce n'est pas beaucoup de travail pour le faire correctement, donc (et votre employeur) vous appréciez de faire plus de recherches, et quand vous ne pouviez pas aller plus loin, demander de l'aide.

Si vous faites référence à la série "Stairway to SQLCLR" sur SQL Server Central, je suis l'auteur de ces articles. Je suis désolé si l'information n'était pas facile à comprendre. Je vais décrire les étapes ici:

1. Dans Visual Studio, connectez-vous à l'Assemblée avec un nom fort clé, et le protéger avec un mot de passe (vous l'avez déjà fait, selon la question)

2. Selon ce que vous faites et les exigences générales, vous avez quelques options ici:

   1. Si votre Assemblée utilise le code qui fait signaler une violation à l'étape de vérification lors de sa création par CREATE ASSEMBLY, vous peut techniquement charge l'Assemblée en [master], marqué SAFE, pour créer la clé asymétrique à partir de celui-ci (vous n'exécuterez pas le code ici, donc il n'a pas besoin d'être marqué comme UNSAFE ici).
   2. Si votre code ne réussit pas la vérification (ce qui signifie qu'il ne peut être créé que lorsqu'il est marqué UNSAFE), alors je trouve préférable de créer un assemblage séparé et vide, également signé avec le même fichier clé Strong Name (.pfx fichier) utilisé pour l'Assemblée principale. Je charge ensuite, vide et pourtant signé, Assemblée dans [master], marqué comme SAFE
   3. Si vous avez besoin de traiter avec SQL Server 2017, alors cela nécessite une étape supplémentaire que je vais mentionner dans un instant.

3. Une fois que vous avez une Assemblée créée en [master] qui a été signé avec le même dossier .pfx qui a été utilisé pour signer votre principal, UNSAFE Assemblée, alors vous pouvez simplement créer, dans [master], une clé asymétrique de cette Assemblée.

4. Créer un identifiant de cette clé asymétrique

5. Accorde Key-base Connectez-vous la UNSAFE ASSEMBLY permission

Ces étapes fonctionnent pour SQL Server 2005-2016, et je donne des instructions sur la façon de automatisez ceci (Option 2 ci-dessus - en utilisant un assemblage distinct, vide et signé) dans Visual Studio dans l'article Stairway to SQLCLR Level 7: Development and Security. (btw, je me rends compte que les étapes décrites dans le niveau 7 sont certes un peu beaucoup, mais ils fournissent un moyen d'automatisation en utilisant Visual Studio ET ils peuvent être simplifiés en utilisant des modèles T4 - qui vient avec VS - mais je n'ai pas Nous n'avons pas encore eu le temps de rédiger l'approche simplifiée - espérons-le bientôt, cependant.Toutefois, si vous devez tenir compte de SQL Server 2017 (ou plus récent, probablement), alors les étapes ci-dessus ne fonctionneront pas car même pas SAFE Les assemblages peuvent être créés sans être signés et avoir la connexion basée sur la signature correspondante qui a l'autorisation UNSAFE ASSEMBLY. Et, malheureusement, CREATE ASYMMETRIC KEY ne permet pas de créer à partir d'une chaîne hexadécimale/VARBINARY littéral, vous devez donc utiliser un certificat qui permet d'être créé de cette façon. Le long de ces lignes, j'ai deux postes de blog qui décrivent en détail, étape par étape, comment effectuer cette opération, entièrement automatisée via Visual Studio (ou même pas en utilisant Visual Studio):

• SQLCLR vs. SQL Server 2017, Part 2: “CLR strict security” – Solution 1 — celui-ci utilise l'approche décrit dans Stairway to SQLCLR Level 7: développement et sécurité comme base, et le met à jour pour fonctionner dans le cadre de la nouvelle contrainte.
• SQLCLR vs. SQL Server 2017, Part 3: “CLR strict security” – Solution 2 — celui-ci est une approche très simplifiée, en utilisant des certificats ne

Quoi que vous fassiez, ne pas se laisser berner en utilisant la nouvelle fonctionnalité de SQL Server 2017 « Assemblées de confiance » comme il y a de nombreux problèmes avec elle, comme décrit ici: SQLCLR vs. SQL Server 2017, Part 4: “Trusted Assemblies” – The Disappointment et un autre post que je travaille maintenant.

Pour aider à améliorer ce processus inutilement douloureux, s'il vous plaît soutenir mes demandes d'amélioration pour améliorer CREATE ASYMMETRIC KEY et SSDT:

• Allow Asymmetric Key to be created from binary hex bytes string just like CREATE CERTIFICATE (SQLCLR) — celui-ci réduirait à elle seule la majorité des étapes dans chacune des approches indiquées ci-dessus, et que même réduire la nécessité d'avoir les options basées sur les certificats puisque l'option clé asymétrique fonctionnerait pour tout, même au sein de la nouvelle contrainte « clr stricte de sécurité » à partir de SQL Server 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

Nous avons plusieurs projets plus anciens pour lesquels cela est nécessaire. Jusqu'à cette semaine où j'ai pris le temps de comprendre cela, nous utilisions le redoutable drapeau digne de confiance.

Après un tas de recherches, j'ai été en mesure de mettre cela en place assez facilement en utilisant un script SQL pré-déploiement dans mon projet Visual Studio et une installation ponctuelle. This article m'a aidé le plus.

Je l'ai testé et confirmé cela fonctionne dans:

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

étapes:

1. Créer une nouvelle clé de nom fort en utilisant l'invite de commandes Developer pour Visual Studio et en tapant:

   sn -k ".\CLRKey.snk" 
   

2. Dans vos paramètres de projet Visual Studio, dans la zone SQLCLR, cliquez sur le bouton de signature et choisissez de signer votre assemblage par la navigation dans le fichier clé que vous venez de créer:

3. Copie CLRKey.snk-C:\ de chaque serveur cible SQL, ou un autre chemin qui peut lire le serveur.

4. Ajouter ce script pré-déploiement à votre projet Visual Studio, en ajustant le chemin de clé et mot de passe pour l'adapter à votre environnement:

   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)]; 
   

Tant que SQL Server peut lire dans cette clé Lorsque vous lancez le premier script, vous devriez pouvoir publier librement sur le même serveur sans avoir à vous soucier de tout cela.

Si vous avez d'autres projets qui publient sur le même serveur, tout ce que vous avez à faire est de les signer avec la même clé que vous avez fait à l'étape 2, mais cela peut être une bonne pratique. script dans tous vos projets au cas où vous souhaitez en publier un sur un serveur différent à un moment donné. J'espère que cela t'aides!