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, nível 1

 

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.

Transparência ajuda os desenvolvedores a escrever mais seguras bibliotecas do .NET Framework que expõem a funcionalidade ao código parcialmente confiável. Transparência de nível 1 foi introduzida no .NET Framework versão 2.0 e foi usada principalmente apenas dentro da Microsoft. Começando com o .NET Framework 4, você pode usar transparência de nível 2. No entanto, transparência de nível 1 foi retida para que você possa identificar código herdado que deve ser executado com as regras de segurança anteriores.

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 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.

Este tópico contém as seguintes seções:

Quando você usa a transparência de nível 1, você estiver usando um modelo de segurança que separa o código em métodos crítico de segurança, segurança crítica segura e transparente de segurança.

Você pode marcar um assembly inteiro, algumas classes em um assembly ou alguns métodos em uma classe como transparente de segurança. Código transparente de segurança não pode elevar privilégios. Essa restrição tem três consequências:

  • Não é possível executar código transparente de segurança Assert ações.

  • Qualquer demanda de link que seria atendida pelo código transparente de segurança se torna uma demanda completa.

  • Código não seguro (não verificado) que deve ser executados no código transparente de segurança faz com que uma demanda completa para o UnmanagedCode permissão de segurança.

Essas regras são aplicadas durante a execução do common language runtime (CLR). Código transparente de segurança passa todos os requisitos de segurança do código chama de volta para os chamadores. As demandas que fluem através do código transparente de segurança não podem elevar privilégios. Se um aplicativo de baixa confiança chama código transparente de segurança e faz com que uma demanda de alto privilégio, a demanda de fluxo de volta para o código de baixa confiança e falhar. O código transparente de segurança não pode interromper a demanda porque não é possível executar ações de declaração. O mesmo código transparente de segurança chamado de resultados de código de confiança total em uma demanda com êxito.

Segurança crítica é o oposto de transparência de segurança. Código de segurança crítica é executado com confiança total e pode executar todas as operações privilegiadas. Código de segurança crítica segura é código privilegiado que passou por uma auditoria de segurança para confirmar que ele não permite chamadores parcialmente confiáveis usar os recursos que eles não têm permissão para acessar.

Você precisa aplicar transparência explicitamente. A maioria do código que manipula a lógica e manipulação de dados normalmente pode ser marcada como transparente de segurança, ao passo que a menor quantidade de código que executa as elevações de privilégios é marcada como crítico de segurança ou segurança crítica segura.

System_CAPS_importantImportante

Transparência de nível 1 é limitada ao escopo do assembly. não é imposto entre assemblies. Transparência de nível 1 foi usada principalmente dentro da Microsoft para fins de auditoria de segurança. Tipos de segurança crítica e membros dentro de um assembly de nível 1 podem ser acessados pelo código transparente de segurança em outros assemblies. É importante que você execute as demandas de link de confiança total em todos os seus membros e tipos de segurança crítica de nível 1. Membros e tipos de segurança crítica segura também devem confirmar que os chamadores têm permissões para recursos protegidos são acessados por tipo ou membro.

Para fins de compatibilidade com versões anteriores do .NET Framework, todos os membros que não são anotados com atributos de transparência são considerados seguros-crítico de segurança. Todos os tipos que são anotados não são considerados para ser transparente. Não há nenhuma regra de análise estática para validar a transparência. Portanto, talvez seja necessário depurar erros de transparência em tempo de execução.

A tabela a seguir descreve os três atributos que você usa para anotar o código de transparência.

Atributo

Descrição

SecurityTransparentAttribute

Permitido somente no nível do assembly. Identifica todos os tipos e membros no assembly como transparente de segurança. O assembly não pode conter qualquer código de segurança crítica.

SecurityCriticalAttribute

Quando usado no nível do assembly sem a Scope propriedade identifica todo o código no assembly como transparente de segurança por padrão, mas indica que o assembly pode conter código crítico de segurança.

Quando usado no nível de classe, identifica a classe ou método como crítico de segurança, mas não os membros da classe. Para fazer com que todos os membros crítico de segurança, defina o Scope propriedade Everything.

Quando usado no nível do membro, o atributo se aplica somente a esse membro.

A classe ou membro identificado como crítico de segurança pode executar as elevações de privilégio.

System_CAPS_importantImportante

Em transparência de nível 1, membros e tipos de segurança crítica são tratados como segurança-crítico de segurança quando eles são chamados de fora do assembly. Você deve proteger segurança crítica tipos e membros com uma demanda de link de confiança total para evitar não autorizada elevação de privilégio.

SecuritySafeCriticalAttribute

Identifica o código de segurança crítica que pode ser acessado pelo código transparente de segurança no assembly. Caso contrário, código transparente de segurança não pode acessar membros crítico de segurança internos ou privados no mesmo assembly. Isso seria influenciar o código de segurança crítica e possibilitam inesperadas elevações de privilégio. Código de segurança crítica segura deve passar por uma auditoria de segurança rigorosa.

System_CAPS_noteObservação

Membros e tipos de segurança crítica segura devem validar as permissões de chamadores para determinar se o chamador tem autoridade para acessar recursos protegidos.

O SecuritySafeCriticalAttribute atributo permite que o código transparente de segurança acessar membros crítico de segurança no mesmo assembly. Considere o código de segurança transparente e crítico de segurança em seu assembly como separadas em dois assemblies. O código transparente de segurança não poderá ver os membros particulares ou internos do código de segurança crítica. Além disso, o código crítico de segurança geralmente é auditado para acesso à sua interface pública. Você não esperava um estado particular ou interno para ser acessível de fora o assembly. Convém manter o estado isolado. O SecuritySafeCriticalAttribute atributo mantém o isolamento de estado entre o código de segurança transparente e crítico de segurança fornecendo a capacidade de substituir o isolamento quando for necessário. Código transparente de segurança não pode acessar o código crítico de segurança interno ou privado, a menos que esses membros foram marcados com SecuritySafeCriticalAttribute. Antes de aplicar o SecuritySafeCriticalAttribute, auditoria esse membro como se ele fosse exposto publicamente.

A tabela a seguir descreve os efeitos do uso de atributos de segurança no nível do assembly.

Atributo de assembly

Estado de assembly

Nenhum atributo em um assembly parcialmente confiável

Todos os tipos e membros são transparentes.

Nenhum atributo em um assembly totalmente confiável (no cache de assembly global ou identificado como confiança total no AppDomain)

Todos os tipos são transparentes e todos os membros são segurança crítica segura.

SecurityTransparent

Todos os tipos e membros são transparentes.

SecurityCritical(SecurityCriticalScope.Everything)

Todos os tipos e membros são críticas de segurança.

SecurityCritical

Todos os códigos padrão é transparente. No entanto, membros e tipos individuais podem ter outros atributos.

Para usar as regras de transparência do .NET Framework 2.0 (transparência de nível 1), use a anotação de assembly a seguir:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Se você quiser criar um assembly inteiro transparente para indicar que o assembly não contém qualquer código crítico e não elevar os privilégios de qualquer forma, você pode adicionar explicitamente transparência para o assembly com o seguinte atributo:

[assembly: SecurityTransparent]

Se você desejar misturar código transparente e crítico no mesmo assembly, inicie marcando o assembly com o SecurityCriticalAttribute atributo para indicar que o assembly pode conter código crítico, da seguinte maneira:

[assembly: SecurityCritical]

Se você quiser executar ações de segurança crítica, você deve marcar explicitamente o código que executará a ação crítica com outra SecurityCriticalAttribute atributo, conforme mostrado no exemplo de código a seguir:

[assembly: SecurityCritical]
Public class A
{
    [SecurityCritical]
    private void Critical()
    {
        // critical
    }

    public int SomeProperty
    {
        get {/* transparent */ }
        set {/* transparent */ }
    }
}
public class B
{    
    internal string SomeOtherProperty
    {
        get { /* transparent */ }
        set { /* transparent */ }
    }
}

O código anterior é transparente, exceto para o Critical método, que é explicitamente marcado como crítico de segurança. Transparência é a configuração padrão, mesmo com o nível de assembly SecurityCriticalAttribute atributo.

Mostrar: