Início / dba / Perguntas / 318280
Accepted
Muflix
Asked: 2022-10-17 08:31:23 +0800 CST

Como registrar o assembly CLR como confiável na implantação do SSDT

  • 772

Eu tenho o assembly CLR no SSDT e para implantar isso ele tem que ser confiável. Pelo que entendi, existem 4 opções de como fazer isso

Primeira opção, use TRUSTWORTHY

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;  
  
ALTER DATABASE SourceDatabase SET TRUSTWORTHY ON;

Segunda opção, desative a segurança estrita

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;  
  
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'clr strict security', 0;
RECONFIGURE;

Terceira opção, assine a montagem com chave ou certificado

Seems complicated and I was not able to manage that yet. I will appreciate the instructions, because the workflow is not clear here.

Quarta opção, usesp_add_trusted_assembly

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;

declare @assembly varbinary(max) = 0x4D5A90000300000004000000FFFF0000... -- I have to manually copy that from the failed SQL publish file.

declare @hash varbinary(64) = HASHBYTES('SHA2_512', @assembly);

EXEC sys.sp_add_trusted_assembly @hash, N'Foo Assembly';

Na 4ª opção tenho que cadastrar manualmente o assembly como confiável e só depois disso posso publicar o assembly. É possível automatizar de alguma forma esse processo?

Estou pensando em criar pre-deployment scriptque possa rodar o código da 4ª opção mas não sei como preencher a variável @assembly do arquivo do assembly .dll.

Como alternativa, se for possível implantar o assembly como não confiável, posso torná-lo confiável no servidor com o seguinte código ( post-deployment script)

-- Register all database assemblies as trusted
declare @name nvarchar(4000),
@content varbinary(max);

DECLARE appCursor CURSOR FAST_FORWARD FOR
    SELECT [name], content
    FROM   SourceDatabase.sys.assembly_files
 
OPEN appCursor
FETCH NEXT FROM appCursor INTO @name, @content
 
WHILE @@FETCH_STATUS = 0
BEGIN
   
   DECLARE @hash varbinary(64) = HASHBYTES('SHA2_512', @content);

    EXEC sys.sp_add_trusted_assembly @hash, @name;

   FETCH NEXT FROM appCursor INTO @name, @content
END
CLOSE appCursor
DEALLOCATE appCursor
GO

Alguma ideia ou qual é a sua abordagem?

sql-server-2017

1 respostas

  1. Best Answer

    Minha preferência é pela Opção 3: usando o mecanismo interno / "tradicional" de chave assimétrica (ou seja, nome forte) / certificado. Infelizmente, o SQL Server 2017 introduziu "segurança estrita de CLR" e sem meios internos de superar esse problema específico (de configurar a segurança com antecedência). Então, eu criei possíveis abordagens que tanto com Visual Studio / SSDT (ou sem), uma para chave assimétrica (já que é assim que o Visual Studio funciona por padrão, embora um pouco mais complicado do que a próxima opção) e outra para certificados ( requer um EXE extra para lidar com certificados, pois o Visual Studio / SSDT lida apenas com nomes fortes, mas um processo mais simples em geral):

    A idéia básica para a "Solução 1" (ou seja, usando uma chave assimétrica) é assinar um assembly vazio com o mesmo nome forte que é usado para a(s) DLL(s) que você está tentando instalar (e isso é apenas porque ainda não podemos crie uma chave assimétrica por hexbytes/ VARBINARYliteral!!!). Isso será carregado para masterque possamos configurar a segurança antes de carregar a montagem real em um ou mais bancos de dados de usuários. Isso por si só funcionou antes do SQL Server 2017 e da mal concebida "segurança estrita CLR". Com essa nova restrição de segurança, não podemos mais fazer upload de um documento não assinadoSAFEassembly (ou seja, o vazio assinado com a chave assimétrica), então agora precisamos também assinar o assembly vazio com um certificado (já que isso pode ser criado via hexbytes, antes de carregar um assembly). Isso permite carregar o assembly vazio para que possamos extrair a chave assimétrica. Convoluto sim, mas infelizmente é onde estamos até que as chaves assimétricas possam ser criadas a partir de hexbytes.

    A "Solução 2" ignora o assembly vazio e simplesmente assina o(s) assembly(s) personalizado(s) pretendido(s) com um certificado. Nesse caso, o certificado pode ser carregado diretamente [master]e os assemblies podem ser importados. No entanto, como o Visual Studio/SSDT não assina com certificados, você precisa atualizar manualmente o arquivo .sqlproj para injetar uma etapa para lidar com isso.

    • 5

relate perguntas