Exportar (0) Imprimir
Expandir Tudo
Este artigo foi traduzido por máquina. Coloque o ponteiro do mouse sobre as frases do artigo para ver o texto original. Mais informações.
Tradução
Original

Código transparente de segurança

A segurança envolve três partes interativas: área restrita, permissões e aplicação. Estar na área restrita 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 a área restrita. O código do aplicativo executado no conjunto de concessões da área restrita é considerado transparente, isto é, não pode executar nenhuma operação que possa afetar a segurança. O conjunto de concessões para a área restrita é determinado pela evidência (classe Evidence). A evidência identifica quais permissões específicas são necessárias para áreas restritas e que tipos de áreas restritas podem ser criados. A imposição se refere a permitir que código transparente seja executado somente em seu conjunto de concessão.

Observação importante Importante

A política de segurança era um elemento importante em versões anteriores do .NET Framework. A partir de .NET Framework 4, a política de segurança é obsoleta. A eliminação da política de segurança é separada da transparência de segurança. Para obter informações sobre os efeitos desta alteração, consulte Compatibilidade de políticas de segurança de acesso de código e migração.

Este tópico descreve o modelo de transparência com mais detalhes. Ele contém as seguintes seções:

A transparência é um mecanismo de reforço que separa o código que é executado como parte do aplicativo do código que é executado como parte da infraestrutura. Transparência desenha uma barreira entre o código que pode fazer coisas privilegiadas (código crítico), como chamar código nativo e o código que não pode (código transparente). O código transparente pode executar comandos dentro dos limites do conjunto de permissões que está funcionando em seguida, mas não pode executar, derivar de ou conter código crítico.

O objetivo fundamental da aplicação de transparência é fornecer um mecanismo simples e eficiente para isolar grupos diferentes de códigos com base no privilégio. Dentro do contexto do modelo da área restrita, esses grupos de privilégio são totalmente confiáveis (isto é, não restritos) ou parcialmente confiáveis (isto é, restritos ao conjunto de permissões concedido para a área restrita.)

Observação importante Importante

O modelo de transparência transcende a segurança de acesso a código. Transparência é imposta pelo compilador just-in-time e permanece em efeito independentemente do conjunto de concessões para um assembly, incluindo confiança total.

A transparência foi introduzida na versão 2.0 do .NET Framework para simplificar o modelo de segurança e para facilitar escrever e implantar bibliotecas seguras e aplicativos. O código transparente também é usado no Microsoft Silverlight para simplificar o desenvolvimento de aplicativos parcialmente confiáveis.

Observação Observação

Quando você desenvolve 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 os recursos que não são permitidos por alguns hosts. Este aplicativo compilará sem erro, mas falhará quando for carregado no ambiente hospedado. Se você desenvolveu seu aplicativo usando o Visual Studio, você poderá ativar a depuração em confiança parcial ou em um conjunto de permissões restrito a partir de ambiente de desenvolvimento. Para obter mais informações, consulte Como depurar um aplicativo ClickOnce com permissões restritas. O recurso de permissões de cálculo fornecido para aplicativos ClickOnce também está disponível para qualquer aplicativo parcialmente confiável.

De volta ao topo

O atributo SecurityRulesAttributeno nível do assembly seleciona explicitamente as regras SecurityRuleSet que o assembly seguirá. As regras são organizadas em um sistema de nível numérico, onde níveis superiores significam uma aplicação mais rigorosa de regras de segurança.

Os níveis são os seguintes:

  • Nível 2 (Level2) – regras de transparência do .NET Framework 4.

  • Nível 1 (Level1) – regras de transparência do.NET Framework 2.0.

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 do assembly e destina-se somente para compatibilidade.

Observação importante Importante

Você deve especificar a transparência de nível 1 para compatibilidade somente; isto é, especificar o nível 1 somente para o código que foi desenvolvido com o .NET Framework 3.5 ou anterior que usa o atributo de AllowPartiallyTrustedCallersAttribute ou não usa o modelo de transparência. Por exemplo, use a transparência de nível 1 para os assemblies do .NET Framework 2.0 que permitem chamadas de chamadores parcialmente confiáveis (APTCA). Para o código desenvolvido para o .NET Framework 4, sempre use a transparência de nível 2.

Ee191569.collapse_all(pt-br,VS.110).gifTransparência de Nível 2

A transparência de nível 2 foi introduzida no .NET Framework 4. Os três tenets desse modelo são código transparente, código segurança-seguro-crítica e código de segurança crítica.

  • O código transparente, independentemente das permissões que lhe foram concedidas (incluindo confiança total), pode chamar apenas outro código transparente ou código segurança-seguro-crítica. Se o código for parcialmente confiável, ele só poderá executar ações 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 uma elevação de privilégio.

    • Contém o código não seguro ou não verificável.

    • Chamar diretamente o código crítico.

    • Chamar código nativo ou código com o atributo SuppressUnmanagedCodeSecurityAttribute.

    • Chamar um membro que esteja protegido por um LinkDemand.

    • Herda de tipos críticos.

    Além disso, os métodos transparentes não podem substituir métodos virtuais críticos ou implementar métodos críticos da interface.

  • O código crítico para segurança e disponível no código transparente é totalmente confiável, mas pode ser chamado pelo código transparente. Expõe uma área da superfície limitada de código de confiança total. As verificações de exatidão e segurança ocorrem no código crítico para segurança.

  • O código crítico à segurança pode chamar qualquer código e é totalmente confiável, mas não pode ser chamado pelo código transparente.

Ee191569.collapse_all(pt-br,VS.110).gifTransparência de Nível 1

O modelo de transparência de nível 1 foi introduzido na versão 2.0 do .NET Framework para permitir que os desenvolvedores reduzam o valor do código que está sujeito a uma auditoria de segurança. Embora a transparência de nível 1 fosse publicamente disponível na versão 2.0, ela foi usada originalmente somente dentro da Microsoft para fins de auditoria de segurança. Através de anotações, os desenvolvedores podem declarar quais tipos e membros podem executar elevações de segurança e outras ações confiáveis (de segurança crítica) e quais não podem (segurança-transparente). O código que é identificado como transparente não exige um alto grau de auditoria de segurança. A transparência de nível 1 indica que a imposição de transparência está limitada ao assembly. Em outras palavras, qualquer tipo público ou membro identificado como crítico de segurança são somente críticos de segurança no assembly. Se desejar impor segurança a esses tipos e membros quando eles forem chamados de fora do assembly, use demandas de link para confiança total. Se você não fizer isso, tipos e membros críticos de segurança publicamente visíveis serão tratados como críticos e e seguros e serão chamados por código parcialmente confiável fora do assembly.

O modelo de transparência de nível 1 tem as seguintes limitações:

  • Os tipos e membros críticos à segurança que são públicos podem ser acessados pelo código transparente de segurança.

  • As anotações de transparência são aplicadas somente dentro de um assembly.

  • Os tipos e membros críticos à segurança devem usar demandas de link para aplicar a segurança em chamadas fora do assembly.

  • As regras de herança não são impostas.

  • O potencial existe para que o código transparente faça coisas prejudiciais quando executado em confiança total.

De volta ao topo

As regras de transparência não são aplicadas até que a transparência seja calculada. No momento, InvalidOperationException é lançada se uma regra de transparência é violada. A hora que a transparência é calculada depende de vários fatores e não podem ser esperados. É calculado o mais tarde possível. No .NET Framework 4, o cálculo de transparência no nível do assembly ocorre mais cedo do que no.NET Framework 2.0. A única garantia é que o cálculo de transparência ocorrerá quando for necessário. Isso é semelhante a como o compilador JIT (just-in-time) pode alterar o ponto quando um método é compilado e todo os erros nesse método são detectados. O cálculo de transparência é invisível se o código não tem nenhum erro de transparência.

De volta ao topo

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2015 Microsoft