Restrições do modelo de programação da Integração CLR

Artigo
05/07/2013

Durante a criação de um procedimento armazenado gerenciado ou de outro objeto de banco de dados gerenciado, há determinadas verificações de código realizadas pelo SQL Server que precisam ser consideradas. O SQL Server realiza verificações no assembly de código gerenciado quando este é registrado pela primeira vez no banco de dados usando a instrução CREATE ASSEMBLY, e também em tempo de execução. O código gerenciado também é verificado em tempo de execução porque, em um assembly, talvez haja caminhos de código que jamais possam ser alcançados em tempo de execução. Isso proporciona flexibilidade para registrar, especialmente, assemblies de terceiros, logo um assembly não seria bloqueado quando houvesse um código 'não seguro' projetado para execução em um ambiente do cliente, mas que jamais seria executado no CLR hospedado. Os requisitos que o código gerenciado devem atender dependem do registro do assembly como SAFE, EXTERNAL_ACCESS ou UNSAFE, SAFE sendo o mais rígido, listados abaixo.

Além das restrições colocadas nos assemblies de código gerenciado, também há permissões de segurança de código que são concedidas. O CLR (Common Language Runtime) oferece suporte a um modelo de segurança chamado segurança de acesso do código (CAS) destinado ao código gerenciado. Nesse modelo, são concedidas permissões a assemblies com base na identidade do código. Os assemblies SAFE, EXTERNAL_ACCESS e UNSAFE têm permissões CAS diferentes. Para obter mais informações, consulte Segurança de acesso a código da integração CLR.

Verificações de CREATE ASSEMBLY

Quando a instrução CREATE ASSEMBLY é executada, as seguintes verificações são executadas em cada nível de segurança. Se houver falha em alguma verificação, CREATE ASSEMBLY apresentará uma mensagem de erro.

Global (qualquer nível de segurança)

Todos os assemblies referenciados devem atender a um ou mais dos seguintes critérios:

O assembly já está registrado no banco de dados.
O assembly é um daqueles para os quais há suporte. Para obter mais informações, consulte Bibliotecas do .NET Framework compatíveis.
Você está usando CREATE ASSEMBLY FROM<location>, e todos os assemblies referenciados e as dependências estão disponíveis em <location>.
Você está usando CREATE ASSEMBLY FROM <bytes …>,, e todas as referências são especificadas por meio de bytes separados por espaço.

EXTERNAL_ACCESS

Todos os assemblies EXTERNAL_ACCESS devem atender aos seguintes critérios:

Não são usados campos estáticos para armazenar informações. São permitidos campos estáticos somente leitura.
O teste PEVerify passou. A ferramenta PEVerify (peverify.exe), que verifica se o código MSIL e os metadados associados atendem aos requisitos de segurança do tipo, é fornecida com o SDK do .NET Framework.
A sincronização, por exemplo com a classe SynchronizationAttribute, não é usada.
Não são usados métodos Finalizer.

Os seguintes atributos personalizados são desaprovados no assembly EXTERNAL_ACCESS:

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.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute
System.STAThreadAttribute
System.ThreadStaticAttribute

SAFE

Todas as condições do assembly EXTERNAL_ACCESS são verificadas.

Verificações de tempo de execução

Em tempo de execução, o assembly do código é verificado em relação às seguintes condições. Se alguma dessas condições for encontrada, o código gerenciado não terá permissão de execução, e uma exceção será lançada.

UNSAFE

Não é permitido carregar um assembly – explicitamente, chamando o método System.Reflection.Assembly.Load() em uma matriz de bytes, ou implicitamente usando o namespace Reflection.Emit.

EXTERNAL_ACCESS

Todas as condições UNSAFE são verificadas.

São desaprovados todos os tipos e métodos anotados com os seguintes valores HPA (atributo de proteção de host) na lista de assemblies para a qual há suporte.

SelfAffectingProcessMgmt
SelfAffectingThreading
Synchronization
SharedState
ExternalProcessMgmt
ExternalThreading
SecurityInfrastructure
MayLeakOnAbort
UI

Para obter mais informações sobre HPAs e uma lista dos tipos e membros desaprovados nos assemblies para os quais há suporte, consulte Atributos de proteção de host e programação da Integração CLR.