.NET

1 out, 2012

Melhorando desempenho de aplicativos .NET – Parte 16

Publicidade

No nosso último artigo falamos sobre reflexão e otimização de ligação tardia. Hoje vamos discutir segurança de código de acesso.

O framework .NET oferece a segurança de código de acesso para controlar a habilidade do código para acessar vários recursos e operações protegidos. Um administrador pode controlar que qualquer permissão a um determinado assembly seja concedida por meio de política de configuração. Durante o tempo de execução, o acesso a tipos de recursos e operações específicas desencadeia uma demanda de permissão que verifica se cada visitante na stack de chamadas possui a permissão adequada para acessar o recurso ou para executar a operação restrita. Se o código de chamada não tiver a permissão relevante, uma exceção de segurança é acionada.

Se a segurança for um requisito, normalmente você não pode trocar a segurança pelo desempenho. E também não se pode trocar o desempenho por segurança. Se o seu planejamento indicar que você não possui os recursos necessários para oferecer uma função que seja segura e tenha o desempenho necessário, pode ser que seja a hora de começar a simplificar. Entregar um recurso seguro, mas que não é útil pelo fato do seu desempenho ser ruim, seria o mesmo que não entregar nada de fato. E isso é muito mais dispendioso. Dito isto, há geralmente uma abundância de outras áreas no seu aplicativo onde você pode investigar e ajustar primeiro. Certifique-se de usar a segurança sabiamente e uma conta para as despesas gerais.

Esta seção resume as diretrizes a se considerar – somente após uma cuidadosa revisão de segurança do seu aplicativo:

Considere SuppressUnmanagedCodeSecurity para o desempenho crítico de cenários confiáveis

Quando você usar P / Invoke ou COM interop, o código de interop estará sujeito a demandas de permissão que o guiam à uma stack de chamadas para assegurar que o código de chamada esteja autorizado a chamar o código não gerenciado.

Você pode usar o atributo SuppressUnmanagedCodeSecurity para melhorar o desempenho, eliminando a necessidade de permissão para a stack walk e substituindo-a por uma demanda de link que verifica apenas o ponto de chamada imediato.

Antes de fazer isso, você deve realizar uma revisão de código completo e ter certeza de que ele não é suscetível a um luring attack.

public NativeMethods

{

// The use of SuppressUnmanagedCodeSecurity here applies only to FormatMessage

[DllImport("kernel32.dll"), SuppressUnmanagedCodeSecurity]

private unsafe static extern int FormatMessage(

int dwFlags,

ref IntPtr lpSource,

int dwMessageId,

int dwLanguageId,

ref String lpBuffer, int nSize,

IntPtr *Arguments);

}

O exemplo a seguir mostra como usar o SuppressUnmanagedCodeSecurity com COM interop, onde este atributo deve ser utilizado a nível de interface.

[SuppressUnmanagedCodeSecurity]
public interface IComInterface

{

}

Prefira Declarative Demand à Imperative Demands

É bom usar Declarative Demands sempre que for possível. A segurança declarativa possui uma sintaxe rica e usar as exigências declarativas fornece o framework .NET com a capacidade máxima de otimizar o código, pois você está especificando a sua intenção de uma maneira simples e direta.

Considere o uso de Link Demand em vez de Full Demand para cenários confiáveis de desempenho crítico

Quando o código acessa um recurso protegido ou executa uma operação privilegiada, as exigências de segurança de código de acesso são usadas para garantir que o código tenha as permissões necessárias. As Full Demands exigem o tempo de execução para executar uma stack walk a fim de garantir que o código de chamada tenha as permissões necessárias.

A stack walk completa pode ser evitada usando uma Link Demand ao invés de uma Full Demand. Embora o desempenho seja aprimorado, porque a Link Demand verifica somente o ponto de chamada imediato durante a compilação JIT, você precisa atingir um equilíbrio entre este ganho de desempenho e os requisitos de segurança. A Link Demand aumenta significativamente as chances do seu código, que está sendo submetido a um luring attack, onde o código malicioso chama o seu código para acessar um recurso protegido ou executar uma operação privilegiada.

Você deve considerar o uso de Link Demand apenas em cenários de confiança, onde o desempenho for crítico. E você deve usá-lo somente apósfaizer a avaliação completa das implicações de segurança.

***

Artigo original está disponível em: http://blog.monitis.com/index.php/2012/05/29/improving-net-application-performance-part-16-code-access-security/