- 03/30/2017
- 6 minutos para ler
-
-
g -
D -
m -
Y -
s -
+8
-
-
Nível 2 (Nível2) – as regras de transparência .NET Framework 4.
-
Nível 1 (Nível1) – as regras de transparência .NET Framework 2.0.
-
Código transparente, independentemente das permissões que lhe forem concedidas (incluindo confiança total), pode chamar apenas outro código transparente ou código crítico de segurança. Se o código for parcialmente confiável, ele só pode executar ações que são permitidas pelo conjunto de permissões do domínio. O código transparente não pode fazer o seguinte:
-
Executar uma operação de Assert ou elevação de privilégio.
-
Conter código não seguro ou não verificável.
-
Chamar diretamente código crítico.
-
Chamar código nativo ou código que tenha o atributo SuppressUnmanagedCodeSecurityAttribute.
-
Chamar um membro que seja protegido por um LinkDemand.
-
Inherit de tipos críticos.
Além disso, métodos transparentes não podem sobrepor métodos virtuais críticos ou implementar métodos de interface críticos.
-
-
Código crítico de segurança é totalmente confiável, mas pode ser chamado por código transparente. Ele expõe uma área limitada de superfície de código de confiança total. As verificações de correção e segurança acontecem em código crítico de segurança.
-
Código crítico de segurança pode chamar qualquer código e é totalmente confiável, mas não pode ser chamado por código transparente.
-
Os tipos e membros críticos de segurança que são públicos são acessíveis por código transparente de segurança.
-
As anotações de transparência são aplicadas somente dentro de uma assembléia.
-
Os tipos e membros críticos de segurança devem usar as exigências de link para reforçar a segurança para chamadas de fora da assembléia.
-
As regras de heranças não são aplicadas.
-
Existe o potencial de código transparente para fazer coisas prejudiciais quando executado em plena confiança.
- Security-Transparent Code, Level 1
- Security-Transparent Code, Level 2
Cautela
Segurança de Acesso ao Código (CAS) e Código Parcialmente Confiável
O .NET Framework fornece um mecanismo para a aplicação de diferentes níveis de confiança em diferentes códigos executados na mesma aplicação chamada Code Access Security (CAS).
CAS não é suportado nas versões .NET Core, .NET 5, ou versões posteriores. CAS não é suportado por versões de C# posteriores a 7.0.
CAS em .NET Framework não deve ser usado como um mecanismo para reforçar os limites de segurança com base na originação do código ou outros aspectos de identidade. CAS e Código Transparente de Segurança não são suportados como um limite de segurança com código parcialmente confiável, especialmente código de origem desconhecida. Aconselhamos contra o carregamento e execução de códigos de origem desconhecida sem a implementação de medidas de segurança alternativas. O .NET Framework não irá emitir patches de segurança para quaisquer explorações de elevação de privilégios que possam ser descobertos contra o sandbox CAS.
Esta política aplica-se a todas as versões do .NET Framework, mas não se aplica ao .NET Framework incluído no Silverlight.
Segurança envolve três peças interativas: sandboxing, permissões e execução. Sandboxing refere-se à prática de criar domínios isolados onde algum código é tratado como totalmente confiável e outro código é restrito às permissões no conjunto de concessões para o sandbox. O código da aplicação que corre dentro do conjunto de concessões do sandbox é considerado transparente, ou seja, não pode realizar quaisquer operações que possam afectar a segurança. O conjunto de permissões para o sandbox é determinado pela evidência (classe de evidência). A evidência identifica quais permissões específicas são requeridas pelos sandboxes, e que tipos de sandboxes podem ser criadas. Aplicação refere-se a permitir que código transparente seja executado apenas dentro de seu grant set.
Importante
Política de segurança era um elemento chave nas versões anteriores do .NET Framework. Começando com o .NET Framework 4, a política de segurança é obsoleta. A eliminação da política de segurança é separada da transparência da segurança. Para informações sobre os efeitos desta mudança, veja Compatibilidade e Migração da Política de Segurança de Acesso ao Código.
Propósito do Modelo de Transparência
Transparência é um mecanismo de execução que separa o código que roda como parte da aplicação do código que roda como parte da infra-estrutura. A transparência desenha uma barreira entre código que pode fazer coisas privilegiadas (código crítico), como chamar código nativo, e código que não pode (código transparente). Código transparente pode executar comandos dentro dos limites do conjunto de permissões em que está operando, mas não pode executar, derivar ou conter código crítico.
O objetivo principal da aplicação de transparência é fornecer um mecanismo simples e eficaz para isolar diferentes grupos de código baseado em privilégios. Dentro do contexto do modelo sandboxing, esses grupos de privilégios são totalmente confiáveis (ou seja, não restritos) ou parcialmente confiáveis (ou seja, restritos ao conjunto de permissões concedidas ao sandbox).
Importante
O modelo de transparência transcende a segurança de acesso ao código. A transparência é aplicada pelo compilador just-in-time e permanece em vigor independentemente do conjunto de permissões concedidas para uma montagem, incluindo confiança total.
Transparência foi introduzida no .NET Framework versão 2.0 para simplificar o modelo de segurança, e para facilitar a escrita e implementação de bibliotecas e aplicações seguras. Código transparente também é usado no Microsoft Silverlight, para simplificar o desenvolvimento de aplicações parcialmente confiáveis.
Nota
Quando você desenvolve uma aplicação parcialmente confiável, você tem que estar ciente dos requisitos de permissão para seus hosts alvo. Você pode desenvolver uma aplicação que utiliza recursos que não são permitidos por alguns hosts. Esta aplicação irá compilar sem erros, mas irá falhar quando for carregada no ambiente hospedado. Se você desenvolveu sua aplicação usando Visual Studio, você pode habilitar a depuração em confiança parcial ou em um conjunto restrito de permissões do ambiente de desenvolvimento. Para mais informações, veja Como fazer: Depurar uma aplicação ClickOnce com permissões restritas. O recurso Calcular permissões fornecido para aplicativos ClickOnce também está disponível para qualquer aplicativo parcialmente confiável.
Especificar o nível de transparência
O atributo assembly-level SecurityRulesAttribute seleciona explicitamente as regras SecurityRulesSet que o assembly irá seguir. As regras são organizadas sob um sistema de nível numérico, onde níveis mais altos significam uma aplicação mais rigorosa das regras de segurança.
Os níveis são os seguintes:
A principal diferença entre os dois níveis de transparência é que o nível 1 não impõe regras de transparência para chamadas de fora da montagem e destina-se apenas à compatibilidade.
Importante
Você deve especificar o nível 1 de transparência somente para compatibilidade; ou seja, especifique o nível 1 somente para código que foi desenvolvido com o .NET Framework 3.5 ou anterior que usa o atributo AllowPartiallyTrustedCallersAttribute ou não usa o modelo de transparência. Por exemplo, use transparência de nível 1 para assembléias .NET Framework 2.0 que permitem chamadas de chamadores parcialmente confiáveis (APTCA). Para código que é desenvolvido para o .NET Framework 4, use sempre transparência nível 2.
Transparência nível 2
Transparência nível 2 foi introduzida no .NET Framework 4. Os três princípios deste modelo são código transparente, código crítico de segurança e código crítico de segurança.
Transparência nível 1
O modelo de transparência nível 1 foi introduzido no .NET Framework versão 2.0 para permitir que os desenvolvedores reduzam a quantidade de código que está sujeito a uma auditoria de segurança. Embora a transparência de nível 1 estivesse disponível publicamente na versão 2.0, ela foi usada principalmente dentro da Microsoft para fins de auditoria de segurança. Através de anotações, os desenvolvedores são capazes de declarar quais tipos e membros podem realizar elevações de segurança e outras ações confiáveis (críticas de segurança) e quais não podem (transparentes de segurança). O código que é identificado como transparente não requer um alto grau de auditoria de segurança. O nível 1 de transparência estabelece que a aplicação da transparência se limita ao âmbito da assembleia. Em outras palavras, quaisquer tipos públicos ou membros que são identificados como críticos de segurança são críticos de segurança apenas dentro da assembléia. Se você quiser reforçar a segurança para esses tipos e membros quando eles são chamados de fora da assembléia, você deve usar demandas de link para confiança total. Se você não o fizer, os tipos e membros críticos de segurança visíveis publicamente são tratados como críticos de segurança e podem ser chamados por código parcialmente confiável fora da assembléia.
O modelo de transparência nível 1 tem as seguintes limitações:
Transparência de Execução
As regras de transparência não são aplicadas até que a transparência seja calculada. Naquele momento, uma InvalidOperationException é lançada se uma regra de transparência for violada. O tempo em que a transparência é calculada depende de múltiplos fatores e não pode ser prevista. Ela é calculada o mais tarde possível. No .NET Framework 4, o cálculo da transparência em nível de montagem ocorre mais cedo do que no .NET Framework 2.0. A única garantia é que o cálculo da transparência ocorrerá no momento em que ela for necessária. Isto é similar a como o compilador just-in-time (JIT) pode alterar o ponto quando um método é compilado e quaisquer erros nesse método são detectados. O cálculo da transparência é invisível se o seu código não tiver nenhum erro de transparência.