Partilhar via

Projetar montagens

  • Artigo

Aplica-se a:SQL Server

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

  • Conjuntos de embalagem
  • Gerenciando a segurança da montagem
  • Restrições às assembleias

Montagens de pacotes

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

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.

Permissão SAFE

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

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.

Os assemblies SAFE e EXTERNAL_ACCESS podem conter apenas código que seja comprovadamente 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.

Permissão INSEGURA

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

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

Conteúdo relacionado