Código Transparent de segurança
A segurança envolve três partes de interação: modo seguro, permissões e imposição. Modo seguro se refere à prática de criação de domínios isolados, onde alguns códigos é tratado como código totalmente confiável e outro é restrito para as permissões de concessão definido para o modo seguro. O código do aplicativo é executado dentro do conjunto de concessão do modo seguro é considerado para ser transparente; ou seja, ele não pode executar qualquer operação que pode afetar a segurança. A concessão definido para o modo seguro é determinada pela evidência. Evidência identifica quais permissões específicas são exigidos por caixas de proteção e quais tipos de caixas de proteção podem ser criados. Imposição refere-se permitir que o código transparent executar somente dentro de seu conjunto de concessão.
.gif "Observação importante") Importante |
|---|
A diretiva de segurança foi um elemento-chave nas versões anteriores do.NET Framework.Começando com o .NET Framework versão 4, a diretiva de segurança é obsoleta.A eliminação da diretiva de segurança é separada da transparência da segurança.Para obter informações sobre os efeitos esse aviso de alteração e a atenuação, consulte Compatibilidade de diretiva de segurança de acesso e a migração de código. |
Este tópico descreve o modelo de transparência em mais detalhes. Ele contém as seguintes seções:
Finalidade do modelo de transparência
Especificando o nível de transparência
Aplicação de transparência
Finalidade do modelo de transparência
Transparência é um mecanismo de imposição que separa o código é executado como parte do aplicativo de código que é executado como parte da infra-estrutura. Transparência desenha uma barreira entre o código que pode fazer coisas privilegiadas (código crítico), como chamar código nativo e código que não é possível (código transparente). Código Transparent pode executar comandos dentro dos limites do conjunto de permissões que ele está funcionando, mas não pode executar, derivam ou contêm o código critical.
O principal objetivo da aplicação de transparência é fornecer um mecanismo simple e eficiente para isolar os diferentes grupos de código com base em privilégio. Dentro do contexto do modelo de modo seguro, esses grupos de privilégio são totalmente confiáveis (ou seja, não restrita) ou parcialmente confiável (ou seja, restrita para o conjunto de permissões concedido ao modo seguro).
| Importante |
|---|
O modelo Transparência transcende a segurança de acesso ao código.Transparência é imposta pelo compilador just-in-time e permanece em vigor, independentemente da concessão definido para um assembly, incluindo a confiança total. |
Transparência foi introduzida na.NET Framework versão 2.0 para simplificar o modelo de segurança e para facilitar a gravação e implantar aplicativos e bibliotecas de seguras. Código Transparent também é usado no Microsoft Silverlight, para simplificar o desenvolvimento de aplicativos parcialmente confiáveis.
Observação
Ao desenvolver um aplicativo parcialmente confiável, você precisa estar ciente dos requisitos de permissão para seus hosts de destino.Você pode desenvolver um aplicativo que usa recursos que não são permitidos por alguns hosts.Este aplicativo será compilado sem erros, mas falhará quando ele é carregado em ambientes hospedados.Caso você tenha desenvolvido seu aplicativo usando o Visual Studio, você pode habilitar a depuração em confiança parcial, ou em um conjunto do ambiente de desenvolvimento de permissões restrito.Para obter mais informações, consulte Como: Depurar um aplicativo ClickOnce com permissões restritas.O recurso de permissões de calcular fornecido para aplicativos de ClickOnce também está disponível para qualquer aplicativo parcialmente confiável.
Voltar ao topo
Especificando o nível de transparência
O nível de conjunto SecurityRulesAttribute explicitamente o atributo seleciona o SecurityRuleSet as regras que o assembly será a seguir. As regras são organizadas em um sistema numérico de nível, onde os níveis mais altos significam maior imposição de regras de segurança.
Os níveis são como segue:
Nível 2 (Level2) – o .NET Framework 4 as regras de transparência.
Nível 1 (Level1) – o.NET Framework 2.0 transparência regras.
A principal diferença entre os níveis de dois transparência é que o nível 1 não impõe regras de transparência para chamadas de fora do assembly e é destinada apenas para compatibilidade.
| Importante |
|---|
Você deve especificar a transparência de nível 1 somente para compatibilidade; Isto é, especifique o nível 1 para o código que foi desenvolvido com o.NET Framework 3.5 ou anterior que usa o AllowPartiallyTrustedCallersAttribute de atributo ou não usar o modelo de transparência.Por exemplo, use a transparência de nível 1 para.NET Framework 2.0 assemblies que permitem que chamadas de chamadores parcialmente confiáveis (APTCA).Para o código que é desenvolvido para o .NET Framework 4, use sempre transparência de nível 2. |
Transparência de nível 2
Transparência de nível 2 foi introduzida na .NET Framework versão 4. Os três princípios deste modelo são o código transparent, o código critical seguro para segurança e código de segurança crítico.
Código Transparent, independentemente das permissões que é concedida a ela (incluindo a confiança total), pode chamar apenas outro código transparent ou código critical seguro para segurança. Se o código é parcialmente confiável, ele só pode realizar ações que são permitidas pelo conjunto de permissões do domínio. Código Transparent não pode fazer o seguinte:
Realizar uma Assert operação ou a elevação de privilégio.
Conter código não seguro ou não verificado.
Chame diretamente o código critical.
Chamar código nativo ou o código que tenha a SuppressUnmanagedCodeSecurityAttribute atributo.
Chamar um membro que é protegido por um LinkDemand.
Herde de tipos critical.
Além disso, métodos transparentes não substituem os métodos virtuais críticos ou implementar métodos de interface crítica.
O código critical segura para segurança é totalmente confiável mas podem ser chamado pelo código transparent. Ele expõe uma área de superfície limitada do código de confiança total. Verificações de correção e segurança acontecem no código seguro-crítico.
Código de segurança crítica pode chamar qualquer código e é totalmente confiável, mas não pode ser chamado pelo código transparent.
Transparência de nível 1
O modelo de transparência de nível 1 foi introduzido na.NET Framework versão 2.0 para capacitar os desenvolvedores reduzir a quantidade de código que está sujeito a uma auditoria de segurança. Embora a transparência de nível 1 estava disponível publicamente na versão 2.0, ele foi principalmente usado somente dentro da Microsoft para fins de auditoria de segurança. Por meio de anotações, os desenvolvedores são capazes de declarar os tipos e membros podem realizar as elevações de segurança e outras ações confiáveis (críticas de segurança) e que não é possível (transparente de segurança). Código que é identificado como transparente não exige um alto grau de auditoria de segurança. Transparência de nível 1 informa que a aplicação de transparência é limitada a dentro do assembly. Em outras palavras, qualquer tipos públicos ou membros que são identificados como críticos de segurança são fundamentais de segurança somente dentro do assembly. Se você deseja aplicar a segurança para esses tipos e membros quando eles são chamados de fora do assembly, você deve usar as demandas de link de confiança total. Se você não fizer isso, membros e tipos de segurança críticos publicamente visíveis são tratados como segurança safe-críticos e podem ser chamados pelo código parcialmente confiável fora do assembly.
O modelo de transparência de nível 1 tem as seguintes limitações:
Membros que são públicos e tipos de segurança crítica são acessíveis no código transparent de segurança.
As anotações de transparência são aplicadas apenas dentro de um assembly.
Membros e tipos de segurança crítica devem usar as demandas de link para reforçar a segurança para chamadas de fora do assembly.
Regras de herança não são impostas.
Não existe o potencial para o código transparent fazer coisas perigosas quando executado em confiança total.
Voltar ao topo
Aplicação de transparência
Regras de transparência não são aplicadas até que a transparência é calculada. Nesse momento, um InvalidOperationException é lançada se uma regra de transparência é violada. A hora em que a transparência é calculada depende de vários fatores e não pode ser prevista. Ela é calculada mais tarde. No .NET Framework 4, o cálculo do nível de conjunto transparência ocorre mais cedo do que na.NET Framework 2.0. A única garantia é que o cálculo de transparência ocorrerá no momento em que ela é necessária. Isso é semelhante 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 de transparência é invisível se seu código não tem quaisquer erros de transparência.
Voltar ao topo