Alterações de segurança na.NET Framework 4

Tem havido duas principais alterações na segurança do .NET Framework versão 4. Diretiva de segurança de toda a máquina foi eliminada, embora o sistema de permissões permanece no lugar, e transparência da segurança tornou-se o mecanismo de imposição de padrão. (Para obter mais informações, consulte Código transparente para a segurança de nível 2.) Além disso, algumas operações de permissão apresentado o potencial de vulnerabilidades de segurança foram feitas obsoletas.

Importante
Code access security (CAS) não foi eliminado, a diretiva de segurança foi eliminada do CAS, mas evidências e permissões são ainda em vigor.Algumas permissões foram eliminadas e transparência simplificou a imposição de segurança.Para uma breve visão geral das alterações, consulte Resumo das alterações na segurança de acesso de código.

Você deve estar ciente dos seguintes pontos principais:

• Transparência separa o código é executado como parte do aplicativo de código que é executado como parte da infra-estrutura. Foi introduzido em .NET Framework versão 2.0e foi aprimorado para se tornar o código acesso segurança imposição mecanismo. Ao contrário da diretiva de segurança, a transparência de nível 2 as regras são impostas em tempo de execução, não no tempo de carregamento do assembly. Essas regras são sempre em vigor, mesmo para os assemblies que são executados como totalmente confiáveis por padrão. No entanto, a transparência de nível 2 não afeta o código totalmente confiável, não for anotado, como, por exemplo, aplicativos de desktop. Conjuntos de módulos (incluindo os assemblies de desktop) marcados com o SecurityTransparentAttribute e que chamar métodos marcados com o SecurityCriticalAttribute receber um MethodAccessException. Você pode alterar esse comportamento, aplicando a SecurityRulesAttribute e a configuração do SecurityRulesAttribute.RuleSet propriedade para Level1; No entanto, você deve fazer isso somente para versões anteriores compatibilidade. Você deve marcar explicitamente um aplicativo de desktop como transparente de segurança para aplicar restrições de transparência.

• Código que chama as APIs de diretiva de segurança recebe um NotSupportedException e avisos do compilador em tempo de execução. Diretiva pode ser reativada usando o <NetFx40_LegacySecurityPolicy> elemento de configuração. Quando a diretiva estiver ativada, a transparência de segurança ainda está em vigor. Diretiva de segurança é aplicada no tempo de carregamento do assembly e não tem efeito sobre transparência, que é imposta pelo tempo de execução.

• As permissões de solicitação obsoleto (RequestMinimum, RequestOptional, e RequestRefuse) receber avisos do compilador e não funcionam na .NET Framework 4, mas eles não causam uma exceção ser acionada. Denysolicitações causa uma NotSupportedException para ser lançada no tempo de execução.

• O LinkDemand a ação de segurança é não obsoleta, mas não deve ser usado para verificar permissões. Em vez disso, use o SecurityCriticalAttribute para tipos e métodos que exigem confiança total, ou usar o Demand método para tipos e métodos que exigem permissões individuais.

• Se seu aplicativo é construído com Visual Studio 2010, você pode executá-lo sem que essas alterações, especificando um destino.NET Framework versão mais antiga que a .NET Framework 4 em configurações de projeto de Visual Studio. No entanto, você não poderá usar os novos .NET Framework 4 tipos e membros. Você também pode especificar uma versão anterior do.NET Framework usando o <supportedRuntime> elemento no esquema de configurações de inicialização no seu arquivo de configuração do aplicativo.

As seções a seguir discutem essas e outras alterações na .NET Framework 4: 

• Simplificação da diretiva de segurança

• Nível de transparência de segurança 2

• Solicitações de permissão obsoleto

• APTCA condicional

• Objetos de evidência

• Coleções de evidência

Simplificação da diretiva de segurança

Começando com o .NET Framework 4, o common language runtime (CLR) está se afastando fornecendo a diretiva de segurança de computadores. Historicamente, o.NET Framework forneceu a diretiva de CAS (segurança) de acesso do código como um mecanismo totalmente controlar e configurar os recursos do código gerenciado. Embora a diretiva CAS é poderosa, pode ser complicado e restritivas. Além disso, a diretiva de CAS não se aplica para aplicativos nativos, para que sua segurança garante são limitada. Os administradores de sistema devem procurar soluções de nível de sistema operacional, como As diretivas de restrição de Software do Windows (SRP) ou AppLocker no Windows 7 e Windows Server 2008 R2 como um substituto para a diretiva de CAS. Diretivas SRP e AppLocker fornecem os mecanismos de confiança simples que se aplicam ao código gerenciado e nativo. Como uma solução de diretiva de segurança, SRP e o AppLocker são mais simples e fornecem a melhor segurança garante que as CAS.

No .NET Framework 4, a diretiva de segurança de toda a máquina está desativada por padrão. Aplicativos que não são hospedados (ou seja, aplicativos que são executados através do Windows Explorer ou de um comando prompt) agora é executado em confiança total. Isso inclui todos os aplicativos que residem em compartilhamentos da rede local. Aplicativos hospedados ou no modo seguro continuarem a execução com as diretivas de confiança são decidiu por seus hosts (por exemplo, ao Internet Explorer, ClickOnce ou ASP.NET). Aplicativos ou controles que são executados em caixas de proteção são considerados parcialmente confiáveis.

Para simplificar a diretiva de segurança, o modelo Transparência foi aplicado para o.NET Framework. Aplicativos e controles que são executados em um host ou o modo seguro com o conjunto de permissão limitada concedido pela área de segurança são considerados transparentes. Transparência significa que você não precisará se preocupar com a diretiva de CAS de verificação, quando você estiver executando aplicativos parcialmente confiáveis. Aplicativos transparentes apenas executado usando o seu conjunto de concessão. Como programador, sua única preocupação deve ser o que a concessão definido para o seu seguro de destino de seus aplicativos e que eles não chamam código que requer confiança total (código de segurança crítica).

Importante

Como resultado dessas alterações de diretiva de segurança, você poderá encontrar exceções em tempo de execução e avisos de compilação se você chamar os tipos de diretiva de CAS obsoletos e membros explícita ou implicitamente (por meio de outros tipos e membros).Para obter uma lista de tipos obsoletos e membros e suas substituições, consulte Compatibilidade de diretiva de segurança de acesso e a migração de código. Você pode evitar os avisos e erros usando o <NetFx40_LegacySecurityPolicy> elemento de configuração no esquema de configurações de tempo de execução para consentir o comportamento herdado de diretiva de CAS.No entanto, especificar o uso da diretiva de segurança herdados não inclui qualquer diretiva de CAS personalizada para essa versão, a menos que ele é migrado para .NET Framework 4. Você também pode ativar a diretiva de CAS de legado definindo o destino.NET Framework versão para o seu projeto de Visual Studio para uma versão anterior a .NET Framework 4. Isso permite que a diretiva de CAS herdada e inclui quaisquer políticas personalizadas de CAS especificadas para essa versão.No entanto, você não poderá usar os novos .NET Framework 4 tipos e membros.Você também pode especificar uma versão anterior do.NET Framework usando o <supportedRuntime> elemento no esquema de configurações de inicialização.

Voltar ao topo

Nível de transparência de segurança 2

Transparência da segurança foi introduzida na .NET Framework versão 2.0, mas era muito limitado e é usado principalmente para melhorar a eficiência de validação de código. No .NET Framework 4, 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 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, chamar, 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. No 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).

A execução de aplicativos de desktop como totalmente confiável; Portanto, não são afetados pelo modelo de transparência. Para obter mais informações sobre alterações de transparência da segurança, consulte Código transparente para a segurança de nível 2.

Voltar ao topo

Solicitações de permissão obsoleto

O suporte de tempo de execução foi removido para impor a Deny, RequestMinimum, RequestOptional, e RequestRefuse as solicitações de permissão. Em geral, essas solicitações não eram bem entendido e apresentado o potencial de vulnerabilidades de segurança quando não foram usados corretamente:

• A Deny ação poderia ser facilmente substituída por uma Assert ação. O código em um assembly foi capaz de executar um Assert a ação de permissão se a permissão foi na concessão de definir para o assembly. O Assert impedido a Deny sejam vistos na pilha, tornando ineficaz.

• RequestMinimumnão pôde ser usado efetivamente fora do escopo do aplicativo. Se RequestMinimum apareceu em um arquivo executável (. exe) e a concessão de conjunto não foi atendido, os usuários finais do arquivo recebido sem um tratamento FileLoadException exceção que não continha nenhuma informação sobre como corrigir o problema. Você não poderia usar uma única solicitação mínima definido para bibliotecas (arquivos. dll), porque os diferentes tipos e membros no assembly geralmente têm requisitos de permissão diferentes.

• RequestOptionalestava confuso e geralmente usados incorretamente com resultados inesperados. Os desenvolvedores facilmente poderiam omitir as permissões da lista sem perceber o que fazer então implicitamente recusada permissões omitidas.

• RequestRefusenão forneceu um modelo de privilégio mínimo eficaz, porque ele exigia a identificar explicitamente as permissões que você não quiser em vez de identificar as permissões que você precisava. Além disso, se as novas permissões se tornaram disponíveis, eles poderiam não ser incluídos na lista. Além disso, a recusa não fez sentido para todas as permissões. Por exemplo, você pode recusar um valor para o UserQuota propriedade de IsolatedStoragePermission.

  Finalmente, especificando somente as permissões você não quiser criado o potencial de vulnerabilidades de segurança se você não conseguiu identificar todas as permissões potencialmente prejudiciais.

• RequestOptionale RequestRefuse permitiram que os desenvolvedores quebrar domínios homogêneos, criando vários conjuntos de permissões no domínio.

O .NET Framework 4 Remove a imposição de tempo de execução dessas valores de enumeração. Assemblies contendo os atributos que usam esses SecurityAction valores continuará carregar; No entanto, o CLR não recusará carregar assemblies referenciados ou modificar o seu conjunto de concessão, com base em conjuntos de permissões.

Voltar ao topo

APTCA condicional

O uso condicional da AllowPartiallyTrustedCallersAttribute atributo (APTCA) permite que os hosts identificar quais assemblies que desejam expor aos chamadores parcialmente confiáveis, que são carregados no contexto de host. Os assemblies do candidato já devem ser criados para confiança parcial; ou seja, eles devem ser APTCA (segurança-safe-crítico no modelo Transparência) ou totalmente transparente. Um novo construtor para o AllowPartiallyTrustedCallersAttribute permite que o host especificar o nível de visibilidade de um conjunto APTCA, usando o PartialTrustVisibilityLevel enumeração na chamada do construtor.

Voltar ao topo

Objetos de evidência

Antes de .NET Framework 4, quase qualquer objeto pode ser usado como um objeto de evidência se quisesse que o código de hospedagem para aplicá-la como evidência. Por exemplo, alguns.Código do NET Framework reconhecido System.Uri objetos como evidência. O runtime considerados objetos de evidências como System.Object referências e não aplicou a qualquer tipo de segurança a eles.

Isso apresentado um problema porque o.NET Framework impostas restrições implícitas, no qual os tipos podem ser usados como objetos de evidências. Especificamente, qualquer objeto usado como evidência tinha de ser serializável e não pode ser nula. Se esses requisitos não foram atendidos, o CLR emitiu uma exceção sempre que foi executada uma operação que exigia essas suposições.

Para habilitar restrições nos tipos de objetos que podem ser usados como provas e fornecem a capacidade de adicionar novos recursos e requisitos para todos os objetos de evidência, a .NET Framework 4 apresenta uma nova classe de base, System.Security.Policy.EvidenceBase, que todos os objetos de evidência devem derivar de. O EvidenceBase classe garante, após a instanciação, que o objeto de prova é serializável. Além disso, os novos requisitos de evidências podem ser criados no futuro, adicionando novas implementações do padrão para a classe base.

Compatibilidade com Versões Anteriores

Todos os tipos usados pelo CLR, como objetos de evidências foram atualizados no .NET Framework 4 derivar de EvidenceBase. Entretanto, provas personalizadas, tipos usados pelos aplicativos de terceiros não são conhecidos e não pode ser atualizado. Portanto, esses tipos de evidência não podem ser usados com os novos membros que espera que a evidência derivada de EvidenceBase.

Voltar ao topo

Coleções de evidência

Antes de .NET Framework 4, o CLR gerou o conjunto completo de objetos de evidências aplicado a um assembly, quando o assembly foi carregado. Esses objetos eram armazenados em uma lista, os consumidores, em seguida, seriam iterar em busca de um objeto específico. Portanto, todas as evidências foi disponibilizada, independentemente de serem ou não foi usado. Para a maioria dos objetos de evidências, esse comportamento não era um problema; No entanto, evidências objetos, como System.Security.Policy.Publisher (que requer verificação Authenticode), esse comportamento foi ineficiente.

Para melhorar esse comportamento, a interação com a coleta de evidências foi reprojetada no .NET Framework 4. Uma coleta de evidências agora se comporta como um dicionário em vez de uma lista. Em vez de iterar sobre a coleta de evidências para ver se existe um objeto de evidências necessárias, os consumidores agora podem solicitar um tipo específico de evidências e a coleção retorna a evidência se ele for encontrado. Por exemplo, a chamada StrongName name = evidence.GetHostEvidence<StrongName>(); retorna um StrongName se o objeto existe; Caso contrário, retornará null.

Esse modelo de dicionário atrasa a geração de objetos de evidência até elas serem solicitadas. No Publisher exemplo de evidências, será atrasada a sobrecarga de desempenho de verificação da assinatura do Authenticode de um assembly até que a informação é necessária. No caso mais comum de aplicativos de confiança total onde Publisher não é necessária a evidência, o processo de verificação é totalmente evitados.

Voltar ao topo

Consulte também

Conceitos

Código Transparent de segurança

Código transparente para a segurança de nível 2

Compatibilidade de diretiva de segurança de acesso e a migração de código