A segurança baseada em evidência e a segurança de acesso do código fornecem mecanismos explícitos muito poderosos para implementar a segurança.
A maioria dos códigos de aplicativo podem simplesmente usar a infraestrutura implementada pelo .NET Framework. Em alguns casos, a segurança de aplicação específica adicional é necessária, compilada quer através da extensão do sistema de segurança ou usando novos métodos ad hoc.
Ao usar as permissões impostas do .NETFramework e de outras imposições em seu código, você deve colocar barreiras para impedir que o código mal-intencionado obtenha informações que você não deseja ou que execute outras ações indesejáveis.
Além disso, você deve golpear um equilíbrio entre a segurança e a usabilidade em todos os cenários esperados usando o código confiável.
Essa visão geral descreve as diferentes maneiras que o código pode ser criado para trabalhar com o sistema de segurança.
Observação
|
|
Em .NET Framework 4, houve mudanças importantes no modelo de segurança e terminologia do .NET Framework. Para obter mais informações sobre essas alterações, consulte Alterações na segurança do .NET Framework.
|
O código de segurança neutra não faz nada explícito com o sistema de segurança.
Ele executa com quaisquer permissões que recebe. Embora os aplicativos que falham ao obter as exceções de segurança associadas com as operações protegidas (como o uso de arquivos, rede e assim por diante) podem resultar em uma exceção não tratada, o código de segurança neutro ainda se beneficia de tecnologias de segurança do .NET Framework.
Uma biblioteca de segurança neutra tem as características especiais que você deve compreender.
Suponha que sua biblioteca fornece os elementos API quem usam arquivos ou código de chamada não gerenciada; se seu código não tem a permissão correspondente, não será executado conforme descrito. No entanto, mesmo que o código tenha a permissão, qualquer código do aplicativo que chama deve ter a mesma permissão para funcionar. Se o código de chamada não tem a permissão correta, SecurityException aparece como resultado do exame da pilha de segurança do acesso ao código.
Se seu código é parte de um aplicativo que não será chamado por outro código, a segurança é simples e a codificação especial pode não ser necessária.
No entanto, lembre-se que código mal-intencionado pode chamar seu código. Enquanto a segurança de acesso a código impede que o código mal-intencionado acesse os recursos, esse código ainda poderá ler os valores de seus campos ou propriedades que podem conter informações sigilosas.
Além disso, se seu código aceita a entrada do usuário da Internet ou outras fontes não confiáveis, você deve ter cuidado com as entradas maliciosas.
Normalmente nesse cenário, algumas funcionalidades úteis são implementadas em código nativo que você deseja tornar disponível para código gerenciado.
Os wrappers gerenciados são fáceis de escrever usando invocação de plataforma ou interoperabilidade COM. No entanto, se você fizer isso, os chamadores dos wrappers devem ter direitos de código não gerenciado para ter êxito. Na política padrão, isso significa que o código baixado de uma intranet ou da Internet não funcionará com os wrappers.
Em vez de fornecer todos os aplicativos que usam esses direitos de código não gerenciado de invólucros, é melhor fornecer esses direitos somente para o código do invólucro.
Se a funcionalidade subjacente não expõe quaisquer recursos e a implementação é igualmente segura, o invólucro só precisa declarar seus direitos, que permite que qualquer código chame por ele. Quando recursos estiverem envolvidos, a codificação de segurança deve ser a mesma dos exemplos de código de biblioteca descritos na próxima seção. Como o wrapper é potencialmente exposto aos chamadores para esses recursos, a verificação cuidadosa da segurança do código nativo é necessária e é responsabilidade do wrapper.
Essa é a abordagem mais poderosa, e portanto, a mais potencialmente perigosa (se realizada incorretamente), para a codificação de segurança: sua biblioteca serve como uma interface para outro código acessar determinados recursos que não estão disponíveis de outra forma, assim como as classes do .NET Framework impõe permissões para os recursos que usam.
Onde quer que você exponha um recurso, seu código deve primeiro exigir a permissão apropriada para o recurso (ou seja, deve executar uma verificação de segurança) e depois normalmente declarar os direitos para executar a operação atual.
