Compartilhar via

Assemblies de design

  • Artigo

Aplica-se:SQL Server

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

  • Conjuntos de embalagem
  • Gerenciando a segurança do assembly
  • Restrições em assemblies

Conjuntos de pacotes

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. Para obter mais informações, consulte Implementar assemblies e 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.

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.

Permissão SAFE

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 permissão

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 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.

Permissão UNSAFE

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. Somente membros da função de servidor fixa sysadmin podem criar 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

Conteúdo relacionado