Resumo das alterações na segurança de acesso de código
No .NET Framework versão 4, code access security (CAS) passou por alterações importantes, com o objetivo de simplificar o sistema de segurança. Em versões anteriores do.NET Framework, os direitos de um aplicativo gerenciado foram determinados pelas regras de diretiva de segurança que foram definidas todo o computador para estabelecer as configurações de tempo de execução. Começando com o .NET Framework 4:
Diretiva de segurança não está mais em vigor. As permissões são ainda em uso; o sistema de diretiva foi eliminado.
Direitos de acesso para os aplicativos são determinados por dois fatores: suas permissões (o conjunto de concessão estabelecido pelo domínio do aplicativo) e seus transparência. Todos os aplicativos de confiança são classificados como transparente. Não é necessário se preocupar com segurança aplicativos transparentes. Transparência foi usada primeiro para o Microsoft Silverlight e agora foi estendida para todos os ambientes hospedados.
Aplicativos de intranet local e da área de trabalho recebem confiança total.
.gif "Observação importante") Importante |
|---|
A principal alteração para o CAS é a eliminação da diretiva de segurança.Não foi eliminado CAS propriamente dito; somente o uso de política (e algumas solicitações de permissão) foi removidas. |
Este tópico fornece uma breve visão geral das alterações de CAS na .NET Framework 4. Para obter mais informações, consulte Alterações de segurança na.NET Framework 4.
Modo seguro e o modelo de permissão
A lista a seguir descreve o modelo de confiança para desktop e os aplicativos hospedados na .NET Framework 4. Para obter mais informações, consulte Alterações de segurança na.NET Framework 4.
Aplicativos de desktop. Como nas versões anteriores do.NET Framework, os aplicativos gerenciados que residem na área de trabalho (a menos que eles tenham sido baixados da Web) recebem confiança total. Aplicativos que residem em compartilhamentos da intranet local também recebem confiança total. Você não pode usar a diretiva para restringir permissões para um aplicativo baseado em sua pasta no disco rígido local.
Aplicativos hospedados. Os aplicativos executados em uma proteção (por exemplo, aplicativos baseados no Silverlight) são concedidos a um conjunto limitado de permissões que determinam quais recursos do computador poderão acessar (por exemplo, os arquivos que eles têm permissão para usar). Caixas de proteção fornecem a capacidade de identificar alguns assemblies dentro da caixa de proteção como sendo parcialmente confiável e alguns como sendo totalmente confiáveis. Os assemblies de confiança são concedidos a um conjunto específico de permissões, conforme determinado pelo domínio do aplicativo (System.AppDomain) que criou o seguro. Parte do código de confiança total nas bibliotecas de confiança total pode ser chamado pelo código parcialmente confiável. Que código confiável pode fazer chamadas a recursos protegidos no computador. No entanto, os membros que podem chamar recursos protegidos e acessíveis publicamente tipos de confiança total devem já passaram por uma auditoria de segurança. Esses membros são classificados como críticos em safe, conforme discutido na próxima seção. Eles podem ser chamados pelo código de confiança parcial (transparente) e, por sua vez, eles podem chamar código critical.
Transparência da segurança
Transparência da segurança separa o código sensível à segurança do código de segurança rígidas. Ele foi introduzido na .NET Framework versão 2.0 para facilitar as auditorias de segurança, anotando o código que tiveram de executar ações de sensíveis à segurança como crítica de segurança. Isso significava que qualquer código que não era crítico de segurança (ou seja, o código transparent) não exigem uma revisão cuidadosa. No entanto, nessas versões anteriores do.NET Framework, a transparência foi usado somente pelo código do Microsoft.
No .NET Framework 4, esse modelo foi estendido e as regras têm sido apertadas para ativar a transparência da segurança em um modelo de aplicação. Nesse modelo aprimorado, o código que é sensível à segurança e podem ser chamados por aplicativos de confiança parcial é mais facilmente identificável. Isso reduz ainda mais a área de superfície que tem a serem auditados.
A tabela a seguir mostra as categorias de transparência e os atributos associados para anotar o código.
Categoria de segurança |
Atributo |
Descrição |
|---|---|---|
Transparente |
Código que não faz nada inerentemente sensíveis à segurança. |
|
Crítica |
Código que pode fazer qualquer coisa, mas que não pode ser chamado a partir de aplicativos de confiança parcial. |
|
Safe crítica |
Código que pode fazer qualquer coisa e que podem ser chamados de aplicativos parcialmente confiáveis. Esta é a camada de corretagem de segura; seu objetivo é realizar verificações de segurança adequadas e a validação antes de chamar o código critical. |
Código Transparent não pode fazer o seguinte, independentemente das permissões concedidas a ele:
Conter código não verificado.
Execute Assert as operações.
Chame o código critical.
Derive o código critical.
Chamar o código é protegido por um LinkDemand (ou seja, código que é considerado crítico).
Se seu código tentar violar essas regras, as exceções são lançadas (mesmo se o seu código possui confiança total). Para obter mais informações, consulte Alterações de segurança na.NET Framework 4.
Observe que a sensibilidade de segurança é definida no common language runtime (CLR) como ações são proibidas para código transparent. O modelo transparência não protege contra violações de segurança específicos do cenário como armazenar senhas nos campos.
Como funciona o modelo de segurança
Cada AppDomain tem um conjunto de permissões associado, que é definido pelo host em um cenário hospedado. (O conjunto de permissões é confiança total para código não está hospedado).
Código parcialmente confiável é sempre transparente; Portanto, ele não poderá executar as ações proibidas para o código transparent (consulte transparência).
Por padrão, o código de confiança total é essencial, a menos que ele tenha sido marcado como sendo transparente. Se um aplicativo de desktop estiver marcado como transparente, ela não pode chamar o código critical, mesmo que ela tenha confiança total.
Bibliotecas podem ser expostas a confiança parcial código pelo host e pela.NET Framework. Essas bibliotecas contêm uma mistura de código seguro crítica, crítico e transparente.
O código seguro crítico deve exigem permissões apropriadas antes de usar a funcionalidade crítica. Por exemplo, o File.Open método demandas FileIOPermission antes de abrir um arquivo.
O código seguro crítico também deve executar outras verificações e validação antes e depois de chamadas para funcionalidade crítica. Por exemplo, mensagens e exceções talvez precise ser filtrados antes de ser passado para o código parcialmente confiável.
O código Critical deve declarar as permissões que ele precisa, quando ele é chamado pelo código parcialmente confiável, porque o código critical pode estar fazendo algo que o código de confiança parcial não é permitido fazer.