Compartilhar via

Restrições do modelo de programação de integração clr

Quando você está criando um procedimento armazenado gerenciado ou outro objeto de banco de dados gerenciado, há determinadas verificações de código executadas pelo SQL Server executa verificações no assembly de código gerenciado quando ele é registrado pela primeira vez no banco de dados, usando a CREATE ASSEMBLY instrução e também em runtime. O código gerenciado também é verificado em runtime porque, em um assembly, pode haver caminhos de código que podem nunca ser alcançados no runtime. Isso fornece flexibilidade para registrar assemblies de terceiros, especialmente, para que um assembly não seja bloqueado quando houver um código "não seguro" projetado para ser executado em um ambiente de cliente, mas nunca seria executado no CLR hospedado. Os requisitos que o código gerenciado deve atender dependem se o assembly está registrado como SAFE, EXTERNAL_ACCESSou UNSAFE, SAFE sendo o mais estrito e estão 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) dá suporte a um modelo de segurança chamado CAS (segurança de acesso de código) para 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 ao código de integração CLR.

CREATE ASSEMBLY Checks

Quando a CREATE ASSEMBLY instrução é executada, as verificações a seguir são executadas para cada nível de segurança. Se alguma verificação falhar, CREATE ASSEMBLY falhará com 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 com suporte.

  • Você está usando CREATE ASSEMBLY FROM<a localização> e todos os assemblies referenciados e suas dependências estão disponíveis no <local>.

  • 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:

  • Campos estáticos não são usados para armazenar informações. São permitidos campos estáticos somente leitura.

  • O teste PEVerify foi aprovado. 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 SynchronizationAttribute classe, não é usada.

  • Métodos de finalizador não são usados.

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

SEGURO

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

Verificações de runtime

Em runtime, o assembly do código é verificado em relação às seguintes condições. Se qualquer uma dessas condições for encontrada, o código gerenciado não poderá ser executado e uma exceção será gerada.

INSEGURO

Carregar um assembly explicitamente chamando o System.Reflection.Assembly.Load() método de uma matriz de bytes ou implicitamente por meio do uso do Reflection.Emit namespace não é permitido.

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

  • Sincronização

  • SharedState

  • ExternalProcessMgmt

  • ExternalThreading

  • SecurityInfrastructure

  • MayLeakOnAbort

  • Interface do usuário

Para obter mais informações sobre HPAs e uma lista de tipos e membros não permitidos nos assemblies com suporte, consulte Atributos de Proteção de Host e Programação de Integração clr.

SEGURO

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

Consulte Também

Bibliotecas do .NET Framework com suporte
Segurança de acesso ao código de integração clr
Atributos de proteção de host e programação de integração clr
Criando um assembly

  • Last updated on