Este artigo foi traduzido por máquina. Para visualizar o arquivo em inglês, marque a caixa de seleção Inglês. Você também pode exibir o texto Em inglês em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.
Tradução
Inglês

Código transparente de segurança

.NET Framework (current version)
 

System_CAPS_cautionCuidado

Segurança de Acesso do Código e Código Parcialmente Confiável

O .NET Framework fornece um mecanismo para a imposição de níveis variáveis de confiança em códigos diferentes em execução no mesmo aplicativo chamado CAS (Segurança de Acesso do Código).  O CAS no .NET Framework não deve ser usado como um mecanismo de imposição de limites de segurança com base na origem do código ou em outros aspectos da identidade. Estamos atualizando nossas diretrizes para refletir que o CAS e o Código Transparente de Segurança não terão suporte como um limite de segurança com código parcialmente confiável, especialmente o código de origem desconhecida. Não aconselhamos carregar e executar códigos de origens desconhecidas sem a adoção de medidas de segurança alternativas no local.

Essa política é aplicável à todas as versões do .NET Framework, mas não é aplicável ao .NET Framework incluído no Silverlight.

A segurança envolve três partes interação: áreas de segurança, permissões e a imposição. Modo seguro 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 de concessão definido para a área restrita. O código do aplicativo que é executado dentro do conjunto de concessão de área restrita é considerado para ser transparente; ou seja, ele não pode executar todas as operações que podem afetar a segurança. A concessão definida para a área restrita é determinada pelo evidência (Evidence classe). Evidência identifica quais permissões específicas são necessárias por áreas de segurança e quais tipos de áreas de segurança podem ser criados. Imposição refere-se a permitir que o código transparente para executar somente dentro de seu conjunto de concessões.

System_CAPS_importantImportante

Política de segurança foi um elemento chave em versões anteriores do .NET Framework. Começando com o .NET Framework 4, política de segurança é obsoleta. A eliminação de política de segurança é separada da transparência da segurança. Para obter informações sobre os efeitos dessa 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 em mais detalhes. Ele contém as seguintes seções:

Transparência é um mecanismo de imposição que separa o código que é 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 o código que não é (código transparent). 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 conter código crítico.

O objetivo principal de imposição de transparência é fornecer um mecanismo simple e eficiente para isolar a 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 restritos,) ou parcialmente confiável (ou seja, restrita para o conjunto de permissões concedido ao modo seguro).

System_CAPS_importantImportante

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 no .NET Framework versão 2.0 para simplificar o modelo de segurança e tornar mais fácil gravar e implantar aplicativos e bibliotecas seguras. Código Transparent também é usado no Microsoft Silverlight, para simplificar o desenvolvimento de aplicativos parcialmente confiáveis.

System_CAPS_noteObservação

Ao desenvolver um aplicativo parcialmente confiável, você precisa estar ciente dos requisitos de permissão para os hosts de destino. Você pode desenvolver um aplicativo que usa recursos que não são permitidos por hosts. Este aplicativo será compilado sem erros, mas falhará quando ele é carregado no ambiente hospedado. Se você tiver 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 restritas. Para obter mais informações, consulte Como depurar um aplicativo 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.

Voltar ao início

Nível de assembly SecurityRulesAttribute atributo seleciona explicitamente o SecurityRuleSet regras que seguirão o assembly. As regras são organizadas em um sistema de nível numérico, em que níveis mais altos significam maior imposição de regras de segurança.

Os níveis são os seguintes:

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

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

A principal diferença entre os níveis de duas 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.

System_CAPS_importantImportante

Você deve especificar a transparência de nível 1 somente para compatibilidade; ou seja, especifique o nível 1 para o código que foi desenvolvido com o .NET Framework 3.5 ou anterior que usa o AllowPartiallyTrustedCallersAttribute atributo ou não usar o modelo de transparência. Por exemplo, use a transparência de nível 1 para 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.

Transparência de nível 2 foi introduzida no .NET Framework 4. Os três princípios desse modelo são código transparent, código de segurança crítica segura e código de segurança crítica.

  • Código Transparent, independentemente das permissões que é concedido (incluindo a confiança total), pode chamar apenas outro código transparent ou código de segurança crítica segura. Se o código parcialmente confiável, ele só pode executar ações que são permitidas pelo conjunto de permissões do domínio. O código Transparent não pode fazer o seguinte:

    • Executar um Assert operação ou elevação de privilégio.

    • Conter código não confiável ou.

    • Chame um código crítico diretamente.

    • Chamar código nativo ou código que tem o SuppressUnmanagedCodeSecurityAttribute atributo.

    • Chamar um membro que está protegido por um LinkDemand.

    • Herde de tipos critical.

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

  • Código de segurança crítica segura é totalmente confiável, mas pode 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 segurança e correção acontecem no código crítico de segurança.

  • Código de segurança crítica pode chamar qualquer código e é totalmente confiável, mas ele não pode ser chamado pelo código transparent.

O modelo de transparência de nível 1 foi introduzido no .NET Framework versão 2.0 para habilitar desenvolvedores a reduzir a quantidade de código que está sujeito a uma auditoria de segurança. Embora a transparência de nível 1 publicamente disponível na versão 2.0, ele foi principalmente usado apenas 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 executar outras ações confiáveis (crítico de segurança) e elevações 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 indica que a imposição de transparência é limitada para dentro do assembly. Em outras palavras, qualquer tipos públicos ou membros que são identificados como crítico de segurança são essenciais 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 demandas de link de confiança total. Se você não fizer isso, membros e tipos de segurança crítica publicamente visíveis são tratados como segurança-crítico de segurança 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:

  • Tipos de segurança crítica e membros públicos estão disponíveis no código transparente 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 demandas de link para impor a segurança para chamadas de fora do assembly.

  • Regras de herança não são impostas.

  • Existe o potencial para o código transparente executar ações prejudiciais quando executado em confiança total.

Voltar ao início

Regras de Transparency não são impostas até que a transparência é calculada. Nesse momento, um InvalidOperationException será lançada se uma regra de transparência é violada. O tempo de transparência é calculada depende de vários fatores e não pode ser previsto. Ele é calculado mais tarde. No .NET Framework 4, cálculo de transparência de nível de assembly ocorre com mais rapidez do que no .NET Framework 2.0. A única garantia é que o cálculo de transparência ocorrerá no momento em que for necessário. Isso é semelhante a como o compilador just-in-time (JIT) pode alterar o ponto quando um método é compilado e quaisquer erros no método são detectados. Cálculo de transparência é invisível se seu código não tem erros de transparência.

Mostrar: