Programação em SQL Server e atributos de proteção de host
A capacidade de carregar e executar um código gerenciado em um host do SQL Server exige que os requisitos do host referentes à segurança de acesso do código e à proteção de recursos do host sejam atendidos. Os requisitos de segurança de acesso do 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 em execução nos conjuntos de permissões SAFE ou EXTERNAL-ACCESS devem evitar determinados tipos ou membros que têm o atributo HostProtectionAttribute aplicado. O HostProtectionAttribute não é uma permissão de segurança como uma garantia de confiabilidade, pois ele identifica constructos de código específicos, sejam tipos ou métodos, que o host pode não permitir. O uso do HostProtectionAttribute impõe um modelo de programação que ajuda a proteger a estabilidade do host.
Observação
O CAS (Segurança de Acesso do Código) foi preterido em todas as versões do .NET Framework e do .NET. As versões recentes do .NET não aceitam anotações de CAS e produzem erros caso as APIs relacionadas ao CAS sejam usadas. Os desenvolvedores devem buscar meios alternativos de realizar tarefas de segurança.
Atributos de proteção de 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 cada vez maiores de ameaça à confiabilidade:
Do contrário, benignos.
Poderia levar à desestabilização do código de usuário gerenciado por 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 tem um HostProtectionAttribute que especifica um valor HostProtectionResource igual a SharedState, Synchronization, MayLeakOnAbort ou ExternalProcessMgmt. Isso impede que os assemblies chamem membros que permitem o compartilhamento do estado, executam a sincronização, podem causar uma perda de recursos após o término ou afetam a integridade do processo do SQL Server.
Tipos e membros desaprovados
A tabela a seguir identifica os tipos e membros cujos valores HostProtectionResource não são permitidos pelo SQL Server.
Conjuntos de permissões do SQL Server
O SQL Server permite aos usuários especificar os requisitos de confiabilidade do código implantado em um banco de dados. Quando os assemblies são carregados no banco de dados, o autor do assembly pode especificar um dos três conjuntos de permissões para o assembly: SAFE, EXTERNAL-ACCESS ou UNSAFE.
| Conjunto de permissões | SAFE | EXTERNAL-ACCESS | UNSAFE |
|---|---|---|---|
| Segurança de acesso do código | Somente execução | Execução + acesso a recursos externos | Irrestrito |
| 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 ao modelo de programação permitido. O código SAFE tem recursos de alta confiabilidade e segurança. Assemblies SAFE recebem permissão suficiente para executar, realizar cálculos e ter acesso ao banco de dados local. Assemblies SAFE precisam ser seguros do tipo verificável 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 tenha a confiabilidade e a segurança de SAFE.
UNSAFE é para código altamente confiável que pode ser criado somente por administradores de bancos de dados. Esses códigos confiáveis não têm nenhuma restrição de acesso do código e podem chamar um código não gerenciado (nativo).
O SQL Server usa a camada da política de segurança de acesso do código em nível de 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. Código gerenciado em execução dentro do banco de dados sempre obtém um desses conjuntos de permissão de acesso de código.
Restrições do Modelo de Programação
O modelo de programação de código gerenciado no SQL Server exige funções, procedimentos e tipos que não exigem que o uso do estado seja mantido em várias invocações nem exigem o compartilhamento do estado entre várias sessões do usuário. Além disso, conforme descrito anteriormente, a presença do estado compartilhado pode causar exceções críticas que afetam a escalabilidade e a confiabilidade do aplicativo.
Com base nessas 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 em tempo CREATE ASSEMBLY e falha a criação desses assemblies se encontra o uso de variáveis e membros de dados estáticos.
