Design assemblies

Applies to:SQL Server

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

• Packaging assemblies
• Gerenciando a segurança do assembly
• Restrições em assemblies

Package assemblies

Um assembly pode conter funcionalidade para mais de uma rotina ou tipo do SQL Server em suas classes e métodos. A maior parte do tempo, faz sentido empacotar a funcionalidade de rotinas que executam funções relacionadas dentro do mesmo assembly, especialmente se essas rotinas compartilharem classes cujos métodos chamam um ao outro. Por exemplo, classes que executam tarefas de gerenciamento de entrada de dados para gatilhos CLR (Common Language Runtime) e procedimentos armazenados CLR podem ser empacotados 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.

Ao empacotar o código no assembly, considere:

• Tipos de dados CLR definidos pelo usuário e índices que dependem de funções CLR definidas pelo usuário podem fazer com que dados persistentes fiquem no banco de dados que dependem 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 do qual dependem as dependências de dados persistentes (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 permissão mais alta, é melhor separar esse código em um assembly separado do código que não requer permissão mais alta.

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

O CLR usa o CAS (Segurança de Acesso do Código) no .NET Framework, para o qual não há mais suporte como um limite de segurança. Um assembly CLR criado com o PERMISSION_SET = SAFE pode conseguir acessar recursos externos do sistema, chamar um código não gerenciado e adquirir privilégios de administrador do sistema. No SQL Server 2017 (14.x) e versões posteriores, a opção sp_configureclr strict security aprimora a segurança dos assemblies CLR. A clr strict security está habilitada por padrão e trata assemblies SAFE e EXTERNAL_ACCESS como se eles fossem marcados como UNSAFE. A opção clr strict security pode ser desabilitada para compatibilidade com versões anteriores, mas não é recomendado.

Recomendamos que você assine todos os assemblies com uma chave de certificado ou chave assimétrica, com um logon correspondente que tenha recebido a permissão UNSAFE ASSEMBLY no banco de dados master. Os administradores do SQL Server também podem adicionar assemblies a uma lista de assemblies na qual o Mecanismo de Banco de Dados deve confiar. For more information, see sys.sp_add_trusted_assembly.

Gerenciar a segurança do assembly

Você pode controlar quanto um assembly pode acessar recursos protegidos por Código de .NET Access Security quando executar código gerenciado. Você faz isso especificando um dos três conjuntos de permissões ao criar ou modificar um assembly: SAFE, EXTERNAL_ACCESS, ou UNSAFE.

SAFE permission

SAFE é o conjunto de permissões padrão e é o mais restritivo. O código executado por um assembly com SAFE permissões não pode acessar recursos externos do sistema, como arquivos, rede, variáveis de ambiente ou registro. SAFE O 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 do assembly.

EXTERNAL_ACCESS permission

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

SAFE e EXTERNAL_ACCESS assemblies podem conter apenas o código que é verificável com segurança de tipo. Isso significa que esses assemblies só podem acessar classes por pontos bem definido de entrada que sejam 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 fornece aos assemblies acesso irrestrito aos recursos, dentro e fora do SQL Server. O código que está sendo executado de dentro de um UNSAFE assembly pode chamar código não gerenciado.

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

Restrições em assemblies

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

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, SAFEEXTERNAL_ACCESS os assemblies não podem ser anotados com os seguintes atributos personalizados:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

APIs não permitidas do .NET Framework

Qualquer API do .NET Framework anotada com uma das HostProtectionAttributes não permitidas não pode ser chamada 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 ASSEMBLYo . Os assemblies do .NET Framework a seguir já estão carregados no SQL Server e, portanto, podem ser referenciados por assemblies personalizados sem a necessidade de usar CREATE ASSEMBLYo .

• 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

• Assemblies (Mecanismo de Banco de Dados)
• de segurança de integração clr