Partilhar via

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

Applies to:SQL ServerAzure SQL Managed Instance

Quando você cria um procedimento armazenado gerenciado ou outro objeto de banco de dados gerenciado, o SQL Server executa determinadas verificações de código que precisam ser consideradas. Essas verificações são realizadas no assembly de código gerenciado quando 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 pode haver caminhos de código que podem nunca ser realmente alcançados em tempo de execução.

These code checks provide flexibility for registering third-party assemblies especially, so that an assembly isn't blocked where there's unsafe code designed to run in a client environment, but would never be executed in the hosted common language runtime (CLR). Os requisitos que o código gerenciado deve atender dependem se o assembly está registrado como SAFE, EXTERNAL_ACCESSou UNSAFE. SAFE é o nível de segurança mais rigoroso.

Além das restrições serem colocadas nos assemblies de código gerenciado, também há permissões de segurança de código que são concedidas. O CLR suporta um modelo de segurança chamado CAS (segurança de acesso ao código) para código gerenciado. Neste modelo, as permissões são concedidas a assemblies com base na identidade do código. SAFE, EXTERNAL_ACCESSe UNSAFE assemblies têm permissões CAS diferentes. Para obter mais informações, consulte Segurança de acesso ao código de integração CLR.

If the publisher policy is set, CREATE ASSEMBLY fails.

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

O CLR usa o CAS (Code Access Security) no .NET Framework, que não é mais suportado como um limite de segurança. Um assembly CLR criado com PERMISSION_SET = SAFE pode aceder a recursos externos do sistema, chamar código não supervisionado e adquirir privilégios de administrador do sistema. No SQL Server 2017 (14.x) e versões posteriores, a opção sp_configure, segurança estrita do CLR, aumenta a segurança dos assemblies CLR. clr strict security está ativado por padrão e trata as assemblagens SAFE e EXTERNAL_ACCESS como se estivessem marcadas UNSAFE. A opção clr strict security pode ser desativada para compatibilidade com versões anteriores, mas não é recomendada.

Recomendamos que você assine todos os assemblies por um certificado ou chave assimétrica, com um logon correspondente que tenha recebido permissão UNSAFE ASSEMBLY no banco de dados master. Os administradores do SQL Server também podem adicionar assemblies à lista de assemblies, nos quais o motor de base de dados deve confiar. For more information, see sys.sp_add_trusted_assembly.

CRIAR VERIFICAÇÕES DE MONTAGEM

Quando a instrução CREATE ASSEMBLY é 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:

  • A montagem já está registada na base de dados.

  • O assembly é um dos assemblies suportados. Para obter mais informações, consulte bibliotecas suportadas do .NET Framework.

  • Você está usando CREATE ASSEMBLY FROM <location>e todos os assemblies referenciados e suas 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

Todas as EXTERNAL_ACCESS montagens devem atender aos seguintes critérios:

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

  • O teste PEVerify é aprovado. A ferramenta PEVerify (peverify.exe), que verifica se o código Common Intermediate Language (CIL) e os metadados associados atendem aos requisitos de segurança de tipo, é fornecida com o SDK do .NET Framework.

  • A sincronização, por exemplo, com a classe SynchronizationAttribute, não é usada.

  • Os métodos do finalizador não são usados.

Os seguintes atributos personalizados não são permitidos em assemblies 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 EXTERNAL_ACCESS condições de montagem são verificadas.

Runtime checks

No tempo de execução, o assembly de código é verificado para as 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á lançada.

UNSAFE

Você não pode carregar um assembly, seja explicitamente chamando o método System.Reflection.Assembly.Load() de uma matriz de bytes ou usando implicitamente Reflection.Emit namespace.

EXTERNAL_ACCESS

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

Todos os tipos e métodos anotados com os seguintes valores de atributo de proteção de host (HPA) na lista de assemblies suportados não são permitidos.

  • SelfAffectingProcessMgmt
  • SelfAffectingThreading
  • Synchronization
  • SharedState
  • ExternalProcessMgmt
  • ExternalThreading
  • SecurityInfrastructure
  • MayLeakOnAbort
  • UI

Para obter mais informações sobre HPAs e uma lista de tipos e membros não permitidos nos assemblies suportados, consulte Atributos de proteção de host e Programação de integração CLR.

SAFE

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

Related content

  • Last updated on