Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 executadas no assembly de código gerenciado quando registrado pela primeira vez no banco de dados, usando a CREATE ASSEMBLY instrução 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 colocadas nos assemblies de código gerenciado, também há permissões de segurança de código que são concedidas. O CLR dá suporte a um modelo de segurança chamado CAS (segurança de acesso ao 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 a 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 (Segurança de Acesso do Código) no .NET Framework, para o qual não há mais suporte como um limite de segurança. Um assembly CLR criado com o PERMISSION_SET = SAFE pode conseguir acessar recursos externos do sistema, chamar um código não gerenciado e adquirir privilégios de administrador do sistema. No SQL Server 2017 (14.x) e versões posteriores, a opção sp_configureclr strict security aprimora a segurança dos assemblies CLR. A clr strict security está habilitada por padrão e trata assemblies SAFE e EXTERNAL_ACCESS como se eles fossem marcados como UNSAFE. A opção clr strict security pode ser desabilitada para compatibilidade com versões anteriores, mas não é recomendado.
Recomendamos que você assine todos os assemblies com uma chave de certificado ou chave assimétrica, com um logon correspondente que tenha recebido a permissão UNSAFE ASSEMBLY no banco de dados master. Os administradores do SQL Server também podem adicionar assemblies a uma lista de assemblies na qual o Mecanismo de Banco de Dados deve confiar. For more information, see sys.sp_add_trusted_assembly.
Verificações CREATE ASSEMBLY
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 <location>o , e todos os assemblies referenciados e suas dependências estão disponíveis no<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:
Os campos estáticos não são usados para armazenar informações. São permitidos campos estáticos somente leitura.
O teste PEVerify é aprovado. A ferramenta PEVerify (
peverify.exe), que verifica se o código CIL (Common Intermediate Language) 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
SynchronizationAttributeclasse, não é usada.Os métodos finalizadores não são usados.
Os seguintes atributos personalizados são desaprovados no assembly EXTERNAL_ACCESS:
System.ContextStaticAttributeSystem.MTAThreadAttributeSystem.Runtime.CompilerServices.MethodImplAttributeSystem.Runtime.CompilerServices.CompilationRelaxationsAttributeSystem.Runtime.Remoting.Contexts.ContextAttributeSystem.Runtime.Remoting.Contexts.SynchronizationAttributeSystem.Runtime.InteropServices.DllImportAttributeSystem.Security.Permissions.CodeAccessSecurityAttributeSystem.Security.SuppressUnmanagedCodeSecurityAttributeSystem.Security.UnverifiableCodeAttributeSystem.STAThreadAttributeSystem.ThreadStaticAttribute
SAFE
- Todas as condições do assembly
EXTERNAL_ACCESSsão verificadas.
Runtime checks
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 terá permissão para ser executado e uma exceção será lançada.
UNSAFE
Você não pode carregar um assembly, seja explicitamente chamando o System.Reflection.Assembly.Load() método de uma matriz de bytes ou usando implicitamente o Reflection.Emit namespace.
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.
SelfAffectingProcessMgmtSelfAffectingThreadingSynchronizationSharedStateExternalProcessMgmtExternalThreadingSecurityInfrastructureMayLeakOnAbortUI
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.
SAFE
Todas as condições EXTERNAL_ACCESS são verificadas.