Partilhar via

Design assemblies

Applies to:SQL Server

Este artigo descreve os seguintes fatores que você deve considerar ao projetar montagens:

  • Packaging assemblies
  • Gerenciando a segurança da montagem
  • Restrições às assembleias

Package assemblies

Um assembly pode conter funcionalidade para mais de uma rotina do SQL Server ou digitar suas classes e métodos. Na maioria das vezes, faz sentido empacotar a funcionalidade de rotinas que executam funções relacionadas dentro do mesmo assembly, especialmente se essas rotinas compartilham classes cujos métodos chamam uns aos outros. Por exemplo, as classes que executam tarefas de gerenciamento de entrada de dados para gatilhos CLR (Common Language Runtime) e procedimentos armazenados CLR podem ser empacotadas no mesmo assembly. Isso ocorre porque os métodos para essas classes são mais propensos a chamar uns aos outros do que os métodos de tarefas menos relacionadas.

Quando você estiver empacotando o código em assembly, considere:

  • Os tipos e índices definidos pelo usuário do CLR que dependem de funções definidas pelo usuário do CLR podem fazer com que os dados persistentes estejam no banco de dados que depende do assembly. Modificar o código de um assembly é frequentemente mais complexo quando há dados persistentes que dependem do assembly no banco de dados. Portanto, é melhor separar o código no qual as dependências de dados persistentes dependem (como tipos e índices definidos pelo usuário usando funções definidas pelo usuário) do código que não tem essas dependências de dados persistentes. For more information, see Implement assemblies and ALTER ASSEMBLY.

  • Se uma parte do código gerenciado exigir uma permissão maior, é melhor separar esse código em um assembly separado do código que não requer permissão maior.

A segurança de acesso ao código não é mais suportada

O CLR usa o CAS (Code Access Security) no .NET Framework, que não é mais suportado como um limite de segurança. Um assembly CLR criado com PERMISSION_SET = SAFE pode aceder a recursos externos do sistema, chamar código não supervisionado e adquirir privilégios de administrador do sistema. No SQL Server 2017 (14.x) e versões posteriores, a opção sp_configure, segurança estrita do CLR, aumenta a segurança dos assemblies CLR. clr strict security está ativado por padrão e trata as assemblagens SAFE e EXTERNAL_ACCESS como se estivessem marcadas UNSAFE. A opção clr strict security pode ser desativada para compatibilidade com versões anteriores, mas não é recomendada.

Recomendamos que você assine todos os assemblies por um certificado ou chave assimétrica, com um logon correspondente que tenha recebido permissão UNSAFE ASSEMBLY no banco de dados master. Os administradores do SQL Server também podem adicionar assemblies à lista de assemblies, nos quais o motor de base de dados deve confiar. For more information, see sys.sp_add_trusted_assembly.

Gerencie a segurança da montagem

Você pode controlar o quanto um assembly pode acessar recursos protegidos pelo .NET Code Access Security quando executa código gerenciado. Para fazer isso, especifique um dos três conjuntos de permissões ao criar ou modificar um assembly: SAFE, EXTERNAL_ACCESSou UNSAFE.

SAFE permission

SAFE é o conjunto de permissões padrão e é o mais restritivo. O código executado por um assembly com permissões SAFE não pode acessar recursos externos do sistema, como arquivos, a rede, variáveis de ambiente ou o registro. SAFE código pode acessar dados dos bancos de dados locais do SQL Server ou executar cálculos e lógica de negócios que não envolvem o acesso a recursos fora dos bancos de dados locais.

A maioria dos assemblies executa tarefas de computação e gerenciamento de dados sem precisar acessar recursos fora do SQL Server. Portanto, recomendamos SAFE como o conjunto de permissões de assembly.

EXTERNAL_ACCESS permission

EXTERNAL_ACCESS permite que assemblies acessem determinados recursos externos do sistema, como arquivos, redes, serviços da Web, variáveis ambientais e o registro. Somente logons do SQL Server com permissões EXTERNAL ACCESS podem criar assemblies EXTERNAL_ACCESS.

SAFE e EXTERNAL_ACCESS os assemblies podem conter apenas código que seja verificável e seguro para digitação. Isso significa que esses assemblies só podem acessar classes por meio de pontos de entrada bem definidos que são válidos para a definição de tipo. Portanto, eles não podem acessar arbitrariamente buffers de memória que não pertencem ao código. Além disso, eles não podem executar operações que possam ter um efeito adverso na robustez do processo do SQL Server.

UNSAFE permission

UNSAFE dá aos assemblies acesso irrestrito aos recursos, dentro e fora do SQL Server. O código que está sendo executado de dentro de um assembly UNSAFE pode chamar código não gerenciado.

Além disso, especificar UNSAFE permite que o código no assembly execute operações que são consideradas inseguras pelo verificador CLR. Essas operações podem potencialmente acessar buffers de memória no espaço de processo do SQL Server de maneira não controlada. UNSAFE assemblies também podem potencialmente subverter o sistema de segurança do SQL Server ou do Common Language Runtime. UNSAFE permissões devem ser concedidas apenas a assemblies altamente confiáveis por desenvolvedores ou administradores experientes. Only members of the sysadmin fixed server role can create UNSAFE assemblies.

Restrições às assembleias

O SQL Server coloca certas restrições ao código gerenciado em assemblies para garantir que eles possam ser executados de maneira confiável e escalável. Isso significa que certas operações que podem comprometer a robustez do servidor não são permitidas em SAFE e EXTERNAL_ACCESS montagens.

Atributos personalizados não permitidos

Os assemblies não podem ser anotados com os seguintes atributos personalizados:

System.ContextStaticAttribute
System.MTAThreadAttribute
System.Runtime.CompilerServices.MethodImplAttribute
System.Runtime.CompilerServices.CompilationRelaxationsAttribute
System.Runtime.Remoting.Contexts.ContextAttribute
System.Runtime.Remoting.Contexts.SynchronizationAttribute
System.Runtime.InteropServices.DllImportAttribute
System.Security.Permissions.CodeAccessSecurityAttribute
System.STAThreadAttribute
System.ThreadStaticAttribute

Além disso, SAFE e EXTERNAL_ACCESS assemblies não podem ser anotados com os seguintes atributos personalizados:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

APIs do .NET Framework não permitidas

Qualquer API do .NET Framework anotada com um dos HostProtectionAttributes não permitidos não pode ser chamada a partir de assemblies SAFE e EXTERNAL_ACCESS.

HostProtectionAttribute.SelfAffectingProcessMgmt
HostProtectionAttribute.SelfAffectingThreading
HostProtectionAttribute.Synchronization
HostProtectionAttribute.SharedState
HostProtectionAttribute.ExternalProcessMgmt
HostProtectionAttribute.ExternalThreading
HostProtectionAttribute.SecurityInfrastructure
HostProtectionAttribute.MayLeakOnAbort
HostProtectionAttribute.UI

Assemblies do .NET Framework com suporte

Qualquer assembly referenciado pelo assembly personalizado deve ser carregado no SQL Server usando CREATE ASSEMBLY. Os seguintes assemblies do .NET Framework já estão carregados no SQL Server e, portanto, podem ser referenciados por assemblies personalizados sem precisar usar CREATE ASSEMBLY.

  • mscorlib.dll
  • CustomMarshalers.dll
  • Microsoft.VisualBasic.dll
  • Microsoft.VisualC.dll
  • System.Configuration.dll
  • System.Core.dll
  • System.Data.OracleClient.dll
  • System.Data.SqlXml.dll
  • System.Data.dll
  • System.Deployment.dll
  • System.Security.dll
  • System.Transactions.dll
  • System.Web.Services.dll
  • System.Xml.Linq.dll
  • system.Xml.dll
  • System.dll

Related content

  • Last updated on