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

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 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 de computador: essa é a política 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: trata-se da política 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 é 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 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 ao código que são concedidas ao código gerenciado ao ser executado dentro do SQL Server é a interseção do conjunto de permissões concedidas pelos três níveis de política acima. Mesmo que o SQL Server conceda um conjunto de permissões a um assembly carregado no SQL Server, o eventual conjunto de permissões concedido ao código do usuário pode ser restrito ainda mais pelas políticas de nível de usuário e de 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 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_ACCESS e UNSAFE (especificados usando a opção PERMISSION_SET de CREATE ASSEMBLY (Transact-SQL)).

O SQL Server fornece um nível de política de segurança no nível do host para o CLR ao hospedá-lo; Essa política é um nível de política adicional 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 criasse 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 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 permissões SAFE não pode acessar recursos externos do sistema, como arquivos, rede, variáveis de ambiente ou o registro.

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

Permissão	Valor(es)/descrição
SecurityPermission	Execução: permissão para executar código gerenciado.
SqlClientPermission	Conexão de contexto = true, conexão de contexto = yes: somente a conexão de contexto pode ser usada e a cadeia de conexão só pode especificar um valor de "conexão de contexto=true" ou "conexão de contexto=sim". AllowBlankPassword = false: senhas em branco não são permitidas.

EXTERNAL_ACCESS

EXTERNAL_ACCESS assemblies têm as mesmas permissões que os assemblies SAFE , 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	Valor(es)/descrição
DistributedTransactionPermission	Irrestrito: transações distribuídas são permitidas.
DNSPermission	Irrestrito: Permissão para solicitar informações de Servidores de Nomes de Domínio.
EnvironmentPermission	Irrestrito: O acesso total às variáveis de ambiente do sistema e do usuário é permitido.
EventLogPermission	Administrar: as seguintes ações são permitidas: criar uma fonte de eventos, ler logs existentes, excluir fontes ou logs de eventos, responder a entradas, limpar um log de eventos, ouvir eventos e acessar uma coleção de todos os logs de eventos.
FileIOPermission	Irrestrito: o acesso total a arquivos e pastas é permitido.
KeyContainerPermission	Irrestrito: o acesso total aos contêineres de chaves é permitido.
NetworkInformationPermission	Acesso: O ping é permitido.
Permissão de registro	Permite direitos de leitura para HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIG e HKEY_USERS.
SecurityPermission	Asserção: 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. Execução: permissão para executar código gerenciado. SerializationFormatter: capacidade de fornecer serviços de serialização.
SmtpPermission	Acesso: Conexões de saída para a porta 25 do host SMTP são permitidas.
SocketPermission	Conectar: conexões de saída (todas as portas, todos os protocolos) em um endereço de transporte são permitidas.
SqlClientPermission	Irrestrito: o acesso total à fonte de dados é permitido.
StorePermission	Irrestrito: o acesso total aos repositórios de certificados X.509 é permitido.
WebPermission	Conectar: conexões de saída com recursos da Web são permitidas.

UNSAFE

O UNSAFE permite que assemblies tenham acesso irrestrito a recursos, dentro e fora do SQL Server. O código executado de dentro de um assembly UNSAFE também pode chamar código não gerenciado.

Os assemblies UNSAFE recebem FullTrust.

Configurações de permissão recomendadas

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 concedida a logons confiáveis para serem executados como a conta de serviço.

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

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 Gerenciando assemblies de integração CLR.

Importante

O SQL Server contém assemblies CLR que o mecanismo do mecanismo de banco de dados usa para fornecer determinadas funcionalidades. O Microsoft.SQLServer.Types assembly 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.

Acessando recursos externos

Se um UDT (tipo definido pelo usuário), procedimento armazenado ou outro tipo de assembly de construção estiver registrado com o conjunto de permissões SAFE , o código gerenciado em execução na construção 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 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 permissões concedidas aos conjuntos de permissões SAFE, EXTERNAL_ACCESS e UNSAFE.

Funcionalidade	SEGURO	EXTERNAL_ACCESS	INSEGURO
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

Confira 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