Compartilhar via

Segurança de acesso ao código de integração clr

  • Artigo

Aplica-se:SQL Server

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 de Segurança de Acesso ao Código.

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

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

  • política de usuário: essa política está em vigor para o código gerenciado hospedado por um processo. Para o SQL Server, a política de usuário é específica para a conta do Windows na qual o serviço do SQL Server está sendo executado.

  • política de host: essa política é configurada pelo host do CLR (neste 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 aplicativos gerenciados que exigem a permissão correspondente antes de permitir o acesso ao recurso. A demanda para a permissão é satisfatória apenas quando todos os chamadores (no nível de assembly) na pilha de chamadas tiverem a permissão do recurso correspondente.

O conjunto de permissões de segurança de acesso de código que são concedidas ao código gerenciado ao executar dentro do SQL Server é a interseção do conjunto de permissões concedidas pelos três níveis de política anteriores. Mesmo que o SQL Server conceda um conjunto de permissões a um assembly carregado no SQL Server, o conjunto eventual de permissões fornecidas ao código do usuário poderá ser ainda mais restrito pelas políticas de nível de usuário e de computador.

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

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

O SQL Server fornece um nível de política de segurança no nível do host para o CLR durante a hospedagem. Essa política é um nível de política extra abaixo dos dois níveis de política que estão sempre em vigor. Essa política é definida para cada domínio de aplicativo criado pelo SQL Server. Essa política não se destina ao domínio de aplicativo padrão que estaria em vigor quando o SQL Server cria uma instância do CLR.

A política de nível de host do SQL Server é uma combinação da política fixa do SQL Server para assemblies do sistema e da 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 a eles confiança total.

A parte especificada pelo usuário da política de host do SQL Server é baseada no proprietário do assembly que especifica um dos três buckets de permissão para cada assembly. Para obter mais informações sobre as permissões de segurança a seguir, 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 permissões de SAFE não pode acessar recursos externos do sistema, como arquivos, rede, variáveis de ambiente ou o registro.

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

Permissão Valores/Descrição
SecurityPermission Execution: permissão para executar código gerenciado.
SqlClientPermission Context connection = true, context connection = yes: somente a conexão de contexto pode ser usada e a cadeia de conexão só pode especificar um valor de 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 que SAFE assemblies, com a capacidade adicional de acessar recursos externos do sistema, como arquivos, redes, variáveis ambientais e o registro.

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

Permissão Valores/Descrição
DistributedTransactionPermission Unrestricted: transações distribuídas são permitidas.
DNSPermission Unrestricted: permissão para solicitar informações dos Servidores de Nomes de Domínio.
EnvironmentPermission Unrestricted: o acesso total às variáveis de ambiente do sistema e do usuário é permitido.
EventLogPermission Administer: as seguintes ações são permitidas: criar uma fonte de evento, ler logs existentes, excluir fontes de eventos ou logs, responder a entradas, limpar um log de eventos, ouvir eventos e acessar uma coleção de todos os logs de eventos.
FileIOPermission Unrestricted: o acesso total a arquivos e pastas é permitido.
KeyContainerPermission Unrestricted: o acesso total a contêineres de chave é permitido.
NetworkInformationPermission Access: o ping é permitido.
RegistryPermission Permite que os direitos de leitura HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIGe HKEY_USERS.
SecurityPermission Assertion: capacidade de afirmar que todos os chamadores desse código têm a permissão necessária para a operação.

ControlPrincipal: capacidade de manipular o objeto principal.

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

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

UNSAFE

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

UNSAFE assemblies recebem FullTrust.

SAFE é a configuração de permissão recomendada para assemblies que executam tarefas de computação e gerenciamento de dados sem acessar recursos fora do SQL Server.

EXTERNAL_ACCESS é recomendado para assemblies que acessam recursos fora do SQL Server. EXTERNAL_ACCESS assemblies por padrão são executados como a conta de serviço do SQL Server. É possível que EXTERNAL_ACCESS código represente explicitamente o contexto de segurança da Autenticação do Windows do chamador. Como o padrão é executar como a conta de serviço do SQL Server, a permissão para executar EXTERNAL_ACCESS só deve ser dada aos logons confiáveis para serem executados como a conta de serviço.

Do ponto de vista de segurança, os assemblies EXTERNAL_ACCESS e UNSAFE são idênticos. No entanto, EXTERNAL_ACCESS assemblies fornecem várias proteções de confiabilidade e robustez que não estão em UNSAFE assemblies.

Especificar UNSAFE permite que o código no assembly execute operações ilegais no espaço de processo do SQL Server e, portanto, pode comprometer a robustez e a escalabilidade do SQL Server. Para obter mais informações sobre como criar assemblies CLR no SQL Server, consulte Gerenciar assemblies de integração CLR.

Importante

O SQL Server contém assemblies CLR que o Mecanismo de Banco de Dados usa para fornecer determinadas funcionalidades. O assembly Microsoft.SQLServer.Types incluído na instalação do SQL Server aparece nos metadados como um assembly UNSAFE. Isso ocorre por design. Esses assemblies são considerados confiáveis e seguros por padrão.

Acessar recursos externos

Se um UDT (tipo definido pelo usuário), um procedimento armazenado ou outro tipo de assembly de construção for registrado com o conjunto de permissões SAFE, o código gerenciado executado no constructo não poderá acessar recursos externos. No entanto, se os conjuntos de permissões EXTERNAL_ACCESS ou UNSAFE forem especificados e o código gerenciado tentar acessar recursos externos, o SQL Server aplicará as seguintes regras:

If Então
O contexto de execução corresponde a um logon do 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 é o chamador original. O acesso será negado, e ocorrerá uma exceção de segurança.
O contexto de execução corresponde a um logon do Windows e o contexto de execução é o chamador original e o chamador é representado. O Access usa o contexto de segurança do chamador e não a conta de serviço.

Resumo do conjunto de permissões

O gráfico a seguir resume as restrições e permissões concedidas aos conjuntos de permissões SAFE, EXTERNAL_ACCESSe UNSAFE.

Funcionalidade SAFE EXTERNAL_ACCESS UNSAFE
Permissões de Segurança de Acesso ao Código Somente execução Execução + acesso a recursos externos Irrestrito (inclusive P/Invoke)
Restrições do modelo de programação Sim Sim Sem restrições
Requisito de verificabilidade Sim Sim No
Acesso a dados locais Sim Sim Sim
Capacidade de chamar código nativo No No Sim

Conteúdo relacionado