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

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 ao Código" no kit de desenvolvimento de software 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 o SQL Server está instalado.

• Política de usuário: essa é a política em vigor para o código gerenciado hospedado por um processo. Para o serviço SQL Server 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 exigência da 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 ao executar dentro do SQL Server concede 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 pode ser restringido ainda mais 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: SAFEEXTERNAL_ACCESS e UNSAFE (especificado 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 o SQL Server cria uma instância do CLR.

A política fixa do SQL Server para assemblies do sistema e a 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.

SEGURO

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 SAFE permissões não pode acessar recursos externos do sistema, como arquivos, rede, variáveis de ambiente ou registro.

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

Permissão	Value(s)/Description
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	Value(s)/Description
DistributedTransactionPermission	Unrestricted: Transações distribuídas são permitidas.
DNSPermission	Unrestricted: Permissão para solicitar informações de servidores de nome 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.

INSEGURO

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.

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 do SQL Server. EXTERNAL_ACCESS assemblies, 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 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 os 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 SQL Server. Para obter mais informações sobre como criar assemblies CLR no SQL Server, consulte Gerenciando assemblies de integração clr.

Acessando 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:

Se	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 foi representado.	O Access usa 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_ACCESSe 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	Não
Local data access	Sim	Sim	Sim
Ability to call native code	Não	Não	Sim

Consulte Também

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