Início / dba / Perguntas / 186957
Accepted
Solomon Rutzky
Asked: 2017-09-27 10:08:26 +0800 CST

Mensagem de erro 10314, nível 16, estado 11 com assembly SAFE após a atualização para o SQL Server 2017

  • 772

Tenho um banco de dados pré-SQL Server 2017 que restaurei/atualizei para o SQL Server 2017. Neste banco de dados tenho um Assembly SQLCLR. O Assembly está marcado como SAFE, pois não faz nada que exija um nível mais alto de permissões e o banco de dados TRUSTWORTHYdesabilitou / OFF. As funções SQLCLR e os procedimentos armazenados funcionaram conforme o esperado antes de migrar para o SQL Server 2017, mas agora quando tento executar qualquer um deles recebo o seguinte erro:

Msg 10314, Level 16, State 11, Server XXXXXXXXXXX, Line YYYYYY
      Ocorreu um erro no Microsoft .NET Framework ao tentar carregar o ID do assembly ZZZZZ. O servidor pode estar ficando sem recursos ou o assembly pode não ser confiável. Execute a consulta novamente ou verifique a documentação para ver como resolver os problemas de confiança do assembly. Para obter mais informações sobre este erro:
      System.IO.FileLoadException: não foi possível carregar o arquivo ou assembly '{assembly_name}, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' ou uma de suas dependências. Ocorreu um erro relacionado à segurança. (Exceção de HRESULT: 0x8013150A)

Confirmei que a integração CLR/SQLCLR foi habilitada no servidor/instância.

sql-server errors

1 respostas

  1. Best Answer

    O erro é resultado da nova clr strict securityopção de configuração no nível do servidor no SQL Server 2017. Essa nova configuração de segurança impede que qualquer Assembly, mesmo aqueles marcados como SAFE, seja criado ou carregado na memória para execução, a menos que:

    • a propriedade do banco de dados TRUSTWORTHYé ON(não faça isso, pois é um risco de segurança desnecessário) e o login que é o proprietário do banco de dados (ou seja, o mesmo SID usado pelo [dbo]usuário) precisa ter a UNSAFE ASSEMBLYpermissão (que já pode ter se o proprietário é sa ou um membro da sysadminfunção de servidor fixa ou talvez tenha a CONTROL SERVERpermissão).
    • a opção de configuração no nível do servidor clr strict securityestá desabilitada / 0(não faça isso, pois é um risco de segurança desnecessário)
    • a Assembléia está assinada e você tem um Login baseado em assinatura correspondente que recebeu a UNSAFE ASSEMBLYpermissão ( por favor, faça isso)
    • o hash SHA-512 do Assembly é registrado como um "Trusted Assembly" (absolutamente nunca faça isso, pois há vários problemas com ele, sem mencionar que nunca foi necessário em primeiro lugar)

    Tudo o que você precisa fazer para corrigir essa situação são as seguintes etapas (que não são difíceis e fornecem o mais alto nível de segurança):

    1. Criar um certificado no banco de dados onde reside o assembly
    2. Faça backup do certificado (chaves públicas e privadas) em arquivos (opcional)
    3. Assine a Montagem (ou Montagens) com o Certificado
    4. Remova a chave privada (pode ser restaurada posteriormente a partir do arquivo de backup) (opcional)
    5. Para cada banco de dados adicional que não assinou, SAFEassemblies:
      1. Pule esta subetapa (ou seja, pule para a Etapa 6), conclua as etapas e repita todo o processo (isso resultará em um Certificado por cada Banco de Dados que precisar de um), OU
      2. Faça o seguinte (isso resultará em um total de Certificados, que será usado para todos os Bancos de Dados):
        1. Crie o mesmo certificado dos arquivos de backup (incluindo a chave privada!)
        2. Assine a Montagem (ou Montagens) com o Certificado
        3. Remova a chave privada (pode ser restaurada posteriormente a partir do arquivo de backup)
    6. Copiar certificado para [master](somente chave pública!)
    7. Criar login do certificado
    8. Conceda a UNSAFE ASSEMBLYpermissão ao Login baseado em certificado

    Um exemplo simples disso (menos o backup opcional e a remoção da chave privada) seria:

    USE [{database_containing_unsigned_safe_assembly}];

CREATE CERTIFICATE [{certificate_name}]
  ENCRYPTION BY PASSWORD = '{some password}'
  WITH SUBJECT = '{simple description}',
  EXPIRY_DATE = '2099-12-31';

ADD SIGNATURE
  TO Assembly::[{assembly_name}]
  BY CERTIFICATE [{certificate_name}]
  WITH PASSWORD = '{some password}';

DECLARE @PublicKey VARBINARY(MAX),
        @SQL NVARCHAR(MAX);

SET @PublicKey = CERTENCODED(CERT_ID(N'{certificate_name}'));

SET @SQL = N'
CREATE CERTIFICATE [{certificate_name}]
  FROM BINARY = ' + CONVERT(NVARCHAR(MAX), @PublicKey, 1) + N';';
PRINT @SQL; -- DEBUG

EXEC [master].[sys].[sp_executesql] @SQL;

EXEC [master].[sys].[sp_executesql] N'
CREATE LOGIN [{login_name}]
  FROM CERTIFICATE [{certificate_name}];

GRANT UNSAFE ASSEMBLY TO [{login_name}]; -- REQUIRED!!!!
';

    Um exemplo totalmente funcional disso (menos o backup e a remoção da chave privada) pode ser encontrado no PasteBin:
    Evitando "Assemblies confiáveis" - Demo

    Uma explicação detalhada de por que você deve usar Certificados e por que você não deve usar "Trusted Assemblies" para corrigir esse problema é fornecida em minha postagem no blog:
    SQLCLR vs. SQL Server 2017, Parte 4: “Trusted Assemblies” – The Disappointment

    Além disso, considere apoiar minha solicitação para que a Microsoft remova o novo recurso "Trusted Assemblies" devido aos vários problemas que o cercam (incluindo preocupações de segurança) e a falta geral de benefícios para tê-lo:

    Os assemblies confiáveis ​​são mais problemáticos, mas menos funcionais do que os certificados - remova

    • 6

relate perguntas