Segurança de acesso a código da integração CLR

  • Artigo

O CLR (common language runtime) dá suporte a um modelo de segurança denominado segurança de acesso para código gerenciado. Nesse modelo, são concedidas permissões a assemblies com base na identidade do código. Para obter mais informações, consulte a seção "Segurança de acesso do código" no Software Development Kit do .NET Framework.

A política de segurança que determina as permissões concedidas a assemblies é definida em três locais diferentes:

  • Política do computador: essa é a política em vigor para todo o código gerenciado em execução no computador no qual SQL Server está instalado.

  • Política de usuário: trata-se da política em vigor para o código gerenciado hospedado por um processo. Para SQL Server serviço está em execução.

  • Política de host: essa é a política configurada pelo host do CLR (nesse caso, SQL Server) que está em vigor para o código gerenciado em execução nesse host.

O mecanismo da segurança de acesso do código para o qual o CLR oferece suporte se baseia na pressuposição de que o runtime pode hospedar tanto o código totalmente confiável quanto o parcialmente confiável. Os recursos protegidos pela segurança de acesso ao código CLR normalmente são encapsulados por interfaces de programação de aplicativo gerenciado que exigem a permissão correspondente antes de permitir o acesso ao recurso. A demanda pela permissão será atendida somente se todos os chamadores (no nível do assembly) na pilha de chamadas tiverem a permissão de recurso correspondente.

O conjunto de permissões de segurança de acesso de código que são concedidas ao código gerenciado durante a execução dentro de SQL Server concede um conjunto de permissões a um assembly carregado em SQL Server, o conjunto eventual de permissões fornecidas ao código do usuário pode ser restringido ainda mais pelas políticas de nível de usuário e computador.

Conjuntos de permissões do nível de política do host do SQL Server

O conjunto de permissões de segurança de acesso de código concedidas a assemblies pelo SQL Server nível de política de host é determinado pelo conjunto de permissões especificado ao criar o assembly. Há três conjuntos de permissões: SAFEe EXTERNAL_ACCESSUNSAFE (especificados usando a opção PERMISSION_SET deCREATE ASSEMBLY (Transact-SQL)).

SQL Server. Essa política não se destina ao domínio de aplicativo padrão que estaria em vigor quando SQL Server cria uma instância do CLR.

O SQL Server fixedpolicy para assemblies do sistema e política especificada pelo usuário para assemblies de usuário.

A política fixa para assemblies CLR e assemblies do sistema SQL Server concede confiança total a eles.

A parte especificada pelo usuário da política de host SQL Server baseia-se no proprietário do assembly especificando um dos três buckets de permissão para cada assembly. Para obter mais informações sobre as permissões de segurança listadas abaixo, consulte o SDK do .NET Framework.

SAFE

Somente a computação interna e o acesso a dados local são permitidos. SAFE é o conjunto de permissões mais restritivo. O código executado por um assembly com as permissões SAFE não pode acessar recursos externos do sistema, como arquivos, rede, variáveis de ambiente ou Registro.

Os assemblies SAFE têm as seguintes permissões e valores:

Permissão Valor(es)/descrição
SecurityPermission Execution: permissão para executar código gerenciado.
SqlClientPermission Context connection = true, context connection = yes: apenas a conexão de contexto pode ser usada, e a cadeia de conexão só pode especificar um valor igual a "context connection=true" ou "context connection=yes".

AllowBlankPassword = false: Senhas em branco não são permitidas.

EXTERNAL_ACCESS

EXTERNAL_ACCESS assemblies têm as mesmas permissões SAFE que assemblies, com a capacidade adicional de acessar recursos externos do sistema, como arquivos, redes, variáveis ambientais e o registro.

Os assemblies EXTERNAL_ACCESS também têm as seguintes permissões e valores:

Permissão Valor(es)/descrição
DistributedTransactionPermission Unrestricted: Transações distribuídas são permitidas.
DNSPermission Unrestricted: Permissão para solicitar informações de Servidores de Nomes de Domínio.
EnvironmentPermission Unrestricted: é permitido o acesso completo ao sistema e às variáveis de ambiente do usuário.
EventLogPermission Administer: As seguintes ações são permitidas: criar uma origem do evento, ler logs existentes, excluir origens do evento ou logs, responder a consultas, limpar um log de eventos, escutar eventos e acessar uma coleção de todos os logs de eventos.
FileIOPermission Unrestricted: é permitido o acesso completo a arquivos e pastas.
KeyContainerPermission Unrestricted: é permitido o acesso completo a contêineres de chave.
NetworkInformationPermission Access: é permitida a execução de ping.
RegistryPermission Ela permite a leitura de direitos para HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIG e HKEY_USERS.
SecurityPermission Assertion: possibilidade de declarar que todos os chamadores do código tenham a permissão necessária à operação.

ControlPrincipal: possibilidade de manipular o objeto principal.

Execution: permissão para executar código gerenciado.

SerializationFormatter: possibilidade de fornecer serviços de serialização.
SmtpPermission Access: são permitidas conexões de saída com a porta de host SMTP 25.
SocketPermission Connect: são permitidas conexões de saída (todas as portas, todos os protocolos) em um endereço de transporte.
SqlClientPermission Unrestricted: é permitido o acesso completo à fonte de dados.
StorePermission Unrestricted: é permitido o acesso completo a repositórios de certificados X.509.
WebPermission Connect: são permitidas conexões de saída com recursos da Web.

UNSAFE

UNSAFE permite aos assemblies acesso irrestrito a recursos, dentro e fora SQL Server. O código em execução em um assembly UNSAFE também pode chamar código não gerenciado.

Os assemblies UNSAFE recebem FullTrust.

Importante

SAFEé a configuração de permissão recomendada para assemblies que executam tarefas de computação e gerenciamento de dados sem acessar recursos fora SQL Server. EXTERNAL_ACCESSassemblies, por padrão, são executados como a conta de serviço do SQL Server, a permissão para executar EXTERNAL_ACCESS só deve ser dada a logons confiáveis para serem executados como a conta de serviço. De uma perspectiva da segurança, os assemblies EXTERNAL_ACCESS e UNSAFE são idênticos. No entanto, os assemblies EXTERNAL_ACCESS fornecem várias proteções de confiabilidade e eficiência que não se encontram nos assemblies UNSAFE. Especificar UNSAFE permite que o código no assembly execute operações ilegais no SQL Server. Para obter mais informações sobre como criar assemblies CLR em SQL Server, consulte Gerenciando assemblies de integração CLR.

Acessando recursos externos

Caso uma UDT (tipo definido pelo usuário), um procedimento armazenado ou outro tipo de construção seja registrado com o conjunto de permissões SAFE, o código gerenciado em execução na construção não pode acessar recursos externos. No entanto, se os EXTERNAL_ACCESS conjuntos de permissões ou UNSAFE forem especificados e o código gerenciado tentar acessar recursos externos, SQL Server aplicará as seguintes regras:

If Então
O contexto de execução corresponde a um logon SQL Server. As tentativas de acessar recursos externos são negadas, e ocorre uma exceção de segurança.
O contexto de execução corresponda a um logon do Windows e seja o chamador original. O recurso externo é acessado no contexto de segurança da conta de serviço do SQL Server.
O chamador não for o chamador original. O acesso será negado, e ocorrerá uma exceção de segurança.
O contexto de execução corresponder a um logon do Windows e o contexto da execução for o chamador original, e o chamador tiver sido representado. O acesso usará o contexto de segurança do chamador, não a conta de serviço.

Resumo do conjunto de permissões

O gráfico a seguir resume as restrições e as permissões concedidas aos conjuntos de permissões SAFE, EXTERNAL_ACCESS e UNSAFE.
SAFE EXTERNAL_ACCESS UNSAFE
Code Access Security Permissions Somente execução Execução + acesso a recursos externos Irrestrito (inclusive P/Invoke)
Programming model restrictions Sim Sim Sem restrições
Verifiability requirement Sim Sim No
Local data access Sim Sim Sim
Ability to call native code No No Sim

Consulte Também

Segurança da integração CLR
Atributos de proteção de host e programação da Integração CLR
Restrições do modelo de programação da Integração CLR
Ambiente hospedado de CLR