Atributos de programação e proteção de host do SQL Server
A capacidade de carregar e executar código gerenciado em um host do SQL Server requer o atendimento aos requisitos do host para segurança de acesso ao código e proteção de recursos do host. Os requisitos de segurança de acesso ao código são especificados por um dos três conjuntos de permissões do SQL Server: SAFE, EXTERNAL-ACCESS ou UNSAFE. O código executado dentro dos conjuntos de permissões SAFE ou EXTERNAL-ACCESS deve evitar certos tipos ou membros que tenham o HostProtectionAttribute atributo aplicado. O HostProtectionAttribute não é uma permissão de segurança, mas uma garantia de confiabilidade na medida em que identifica construções de código específicas, tipos ou métodos, que o host pode não permitir. O uso do impõe um modelo de HostProtectionAttribute programação que ajuda a proteger a estabilidade do host.
Nota
O CAS (Code Access Security) foi preterido em todas as versões do .NET Framework e do .NET. As versões recentes do .NET não respeitam as anotações do CAS e produzem erros se as APIs relacionadas ao CAS forem usadas. Os desenvolvedores devem procurar meios alternativos de realizar tarefas de segurança.
Atributos de proteção do host
Os atributos de proteção do host identificam tipos ou membros que não se ajustam ao modelo de programação do host e representam os seguintes níveis crescentes de ameaça de confiabilidade:
São benignos.
Pode levar à desestabilização do código do usuário gerenciado pelo servidor.
Poderia levar à desestabilização do próprio processo do servidor.
O SQL Server não permite o uso de um tipo ou membro que tenha um HostProtectionAttribute que especifique um HostProtectionResource valor de SharedState, Synchronization, MayLeakOnAbortou ExternalProcessMgmt. Isso impede que os assemblies chamem membros que habilitam o estado de compartilhamento, executam sincronização, podem causar um vazamento de recursos no encerramento ou afetar a integridade do processo do SQL Server.
Tipos e membros não permitidos
A tabela a seguir identifica tipos e membros cujos HostProtectionResource valores não são permitidos pelo SQL Server.
Conjuntos de permissões do SQL Server
O SQL Server permite que os usuários especifiquem os requisitos de confiabilidade para o código implantado em um banco de dados. Quando assemblies são carregados no banco de dados, o autor do assembly pode especificar um dos três conjuntos de permissões para esse assembly: SAFE, EXTERNAL-ACCESS ou UNSAFE.
Conjunto de permissões | SEGURO | ACESSO EXTERNO | INSEGURO |
---|---|---|---|
Segurança de acesso ao código | Executar apenas | Executar + acesso a recursos externos | Sem restrição |
Restrições do modelo de programação | Sim | Sim | Sem restrições |
Requisito de verificabilidade | Sim | Sim | No |
Capacidade de chamar código nativo | No | No | Sim |
SAFE é o modo mais confiável e seguro com restrições associadas em termos do modelo de programação permitido. O código SAFE tem alta confiabilidade e recursos de segurança. Os assemblies SAFE recebem permissão suficiente para executar, executar cálculos e ter acesso ao banco de dados local. Os assemblies SAFE precisam ser verificáveis e não têm permissão para chamar código não gerenciado.
EXTERNAL-ACCESS fornece uma opção de segurança intermediária, permitindo que o código acesse recursos externos ao banco de dados, mas ainda tendo a confiabilidade e segurança do SAFE.
UNSAFE é para código altamente confiável que só pode ser criado por administradores de banco de dados. Esse código confiável não tem restrições de acesso ao código e pode chamar código não gerenciado (nativo).
O SQL Server usa a camada de política de segurança de acesso ao código no nível do host para configurar uma política de host que concede um dos três conjuntos de permissões com base no conjunto de permissões armazenado nos catálogos do SQL Server. O código gerenciado em execução dentro do banco de dados sempre obtém um desses conjuntos de permissões de acesso ao código.
Restrições do modelo de programação
O modelo de programação para código gerenciado no SQL Server requer funções, procedimentos e tipos que não exigem o uso de estado mantido em várias invocações ou o compartilhamento de estado em várias sessões de usuário. Além disso, conforme descrito anteriormente, a presença de estado compartilhado pode causar exceções críticas que afetam a escalabilidade e a confiabilidade do aplicativo.
Dadas essas considerações, o SQL Server não permite o uso de variáveis estáticas e membros de dados estáticos. Para assemblies SAFE e EXTERNAL-ACCESS, o SQL Server examina os metadados do assembly no momento CREATE ASSEMBLY e falha na criação desses assemblies se encontrar o uso de membros e variáveis de dados estáticos.