Segurança de acesso a código da integração CLR
Aplica-se a: 
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