Faltam 0 dias! Inscreva-se agora! O maior encontro de profissionais web da américa latina.

Vimos na matéria anterior o mecanismo de Security Policy. Também mostramos de maneira superficial um exemplo de configuração para acessar um Assembly pela rede. Nesta matéria vamos ver exemplos mais reais e que poderão fazer parte do seu cotidiano, além de algumas dicas de como distribuir as políticas de segurança pela sua rede, e por último vamos fazer uma introdução à criptografia.

Imaginemos as três situações abaixo:

01. Você fez um programa e deseja que o mesmo seja acessado pelas estações via rede, utilizando uma pasta compartilhada. (Não entraremos no mérito se essa é uma boa solução ou não);

02. Você desenvolveu um programa, e deseja que o mesmo seja acessado utilizando o browser, facilitando a distribuição e atualização. (Chamamos esse tipo de distribuição de Smart Clients);

03. Você deseja que apenas os programas desenvolvidos pela sua empresa ou por você mesmo, tenham permissão de rodar nas estações.

Bem, vamos agora mostrar passa a passo como implementar cada tipo de política de segurança para as situações acima. Começaremos com a primeira situação.

1.1. Desenvolva uma aplicação que faça acesso a arquivos ou ao registro do Windows, situações que já vimos, por padrão, não são permitidas serem executadas por assemblies carregados pela rede.

1.2. Crie uma pasta compartilhada e ponha o seu assembly, por enquanto dê permissão a todos. Veremos em matérias futuras, como configurar segurança baseada em Roles (Role-Based Security)

1.3. Agora abra a ferramenta de configuração mscorcfg.msc (Painel de controle -> Ferramentas Administrativas -> Microsoft .NET Framework 1.1 Configuration) e acesse o nível Enterprise.

1.4. Clique com o botão direito em All_Code, escolha a opção “Novo...”. Será aberta uma tela como a mostrada na imagem abaixo. Preencha o campo nome, com o nome de seu grupo de código e avance.

1.5. Nessa etapa (escolha do Membership Condition) devemos escolher que condição deverá ser cumprida pelo nosso assembly para que seja dada a permissão necessária para ele ser executado. No nosso caso, podemos escolher: Strong Name, Hash, Zona. Dentre essas, as melhores opções são Strong Name e Hash. Se o assemlby possuir um Strong Name, devemos usar essa opção, caso contrário usaremos Hash. Vamos escolher a opção Hash.

Escolha um dos tipos de algoritmos para o cálculo do valor Hash, e depois clique no botão Importar para localizar o assembly, após selecionar o mesmo clique em abrir. Feito isso o valor Hash para o Assembly será mostrado no campo Hash, como mostrado abaixo.

1.6. Após avançar, deveremos escolher que permissão dar ao Assembly. Nesse caso, poderemos dar permissão FullTrust, embora, você possa criar seu próprio conjunto de permissão. Avance e conclua a configuração.

Para a situação 2 (dois), basta repetirmos o item 1.5 e alterar o Membership Condition para Site ou URL e colocar o endereço em que o Assembly irá ser baixado ou o endereço do próprio Assembly.

Para a situação 3 (três), use a mesma tela do item 1.5 e escolha o Membership Condition Editor ou Publisher.

Importe o Assembly assinado digitalmente ou importe o arquivo de certificado. Nessa matéria, não falaremos sobre o procedimento de assinar digitalmente o arquivo. Veja mais detalhes nos links abaixo:

http://msdn....url=/workshop/security/authcode/intro_authenticode.asp

http://msdn...url=/library/en-us/cptools/html/cpgrfFileSigningToolSigncodeexe.asp

http://msdn....url=/library/en-us/secmod/html/secmod101.asp

http://msdn....url=/library/en-us/security/security/signedcode_sign.asp

Numa próxima oportunidade falarei sobre esse assunto.

Agora que terminamos de configurar a política de segurança do Assembly, seja qual situação tenhamos escolhido, podemos distribuir essa política pela rede usando um instalador Windows Installer.

Para criá-lo, clique com o botão direito em Diretiva de segurança do Common Language Runtime e escolha a opção: “Cria Pacote de Implantação...”. Agora escolha o nível da diretiva de segurança a ser implantado, nesse caso, mantenha o nível Empresa ou Enterprise.

Digite o path do arquivo de instalação, avance e conclua a criação do pacote de instalação. Feito isso, basta rodar esse instalador em todas as máquinas na sua rede, e as mesmas ficarão configuradas para rodar o seu assembly sem problemas. Existem outras formas de distribuição, como o SMS, mas não falaremos sobre esse assunto.

Mesmo que nosso assembly tenha permissões configuradas, podemos manipulá-la via código de forma a garantir ou negar permissão para determinados blocos de código. Fazemos isso para ajustar de forma mais precisa as permissões para o assembly. Vamos ver agora, alguns exemplos de como configurar segurança via código. Podemos definir as permissões para execução de um bloco de código de forma Declarativa ou Imperativa.

Forma Declarativa: Usamos atributos para inserir informações de segurança no Assembly, Classe ou Métodos. Esse atributos definem as permissões requisitadas (Demanded) e como elas irão interagir com o código.

O construtor de cada atributo aceita um dos nove membros da enumeração SecurityAction, que indicam qual permissão será usada. Por exemplo, a declaração abaixo usa o atributo PrintingPermission para assegurar que o método é executado somente se o assembly for capaz de imprimir.

<PrintingPermission(SecurityAction.Demand, level:=PrintingPermissionLevel.SafePrinting)> _
        Public Sub Imprimir()
                'Código para imprimir
        End Sub

No código acima, caso o assembly ou alguns de seus “Chamadores” de nível superior no Call Stack não tenham permissão para realizar impressão uma SecurityException será disparada.

Podemos também requisitar o mínimo de permissão ao invés de simplesmente negar, o que em alguns casos é a melhor opção. Veja:

<Assembly: FileIOPermissionAttribute(SecurityAction.RequestMinimum, Write:= "c: este.txt")>

Forma Imperativa: Utilizamos as classes derivadas de CodeAccessPermission para invocar em tempo de execução as verificações de segurança. Veja um exemplo:

Dim oIO As New FileIOPermission(FileIOPermissionAccess.Read, PathArquivo)

‘Para requisitar permissão, o método apropriado (Demand, Assert, DemandImmediate, RevertAsserty, Deny, etc..) precisa ser chamado.

Try
        oIO.Demand()
Catch e As SecurityException
        'Tratamento de erro
End Try

Vamos ver os itens da enumeração SecurityAction, que você pode usar para ajustar as suas permissões.

Assert: O código chamado pode acessar os recursos especificados pelo permission object, mesmo que os “chamadores” de nível superior no stack não tenham essas permissões;

'Permite asseso ao recusro
<Assembly: FileIOPermissionAttribute(SecurityAction.Assert, Write:= "c: este.txt")>

Demand: Todos os “chamadores” de nível superior no call stack são analisados e precisam ter permissão para acessar o recurso especificado pelo permission object atual;

'Verifica se todos os chamados no call stack tem permissão para escrever
'no arquivo, caso tenham, o código é executado, senão uma
'SecurityException será disparada.
<Assembly: FileIOPermissionAttribute(SecurityAction.Demand, Write:= "c: este.txt")>

Deny: Nega acesso ao recurso especificado no permission object atual, mesmo que exista permissão para acesso ao recurso.

'Nega acesso ao arquivo teste.txt, mesmo que o assembly tenha permissão
'para tal ação.
<Assembly: FileIOPermissionAttribute(SecurityAction.Demand, Write:= "c: este.txt")>

InheritanceDemand: Se aplicado no scopo da classe, indica que somente o código com uma específica permissão pode herdar essa classe. Já no scopo de método, o código tem que possuir uma específica permissão para sobrescrever o método.

LinkDemand: Apenas o “chamador” de nível imediatamente superior será verificado e precisa ter permissão para acessar o recurso especificado pelo permission object atual;

'Verifica se o “chamador” imediatamente superior no call stack tem acesso ao recurso. Caso contrário, será disparada uma SecurityException.
<Assembly: FileIOPermissionAttribute(SecurityAction.Demand, Write:= "c: este.txt")>

PermitOnly: Somente os recursos especificados pelo permission object atual podem ser acessados.

'O código só pode executar a ação de leitura no arquivo, caso o código 'queira escrever no arquivo, será gerada uma SecurityException.
<Assembly: FileIOPermissionAttribute(SecurityAction. PermitOnly, Read:= "c: este.txt")>

RequestMinimum: Requisita apenas as permissões mínimas necessárias para o código rodar. Só pode ser usado no escopo do assembly.

RequestOptional: Requisita permissões adicionais, aquelas que não são necessárias para o código rodar. Só pode ser usado no escopo do assembly.

RequestRefuse: Indica que as requisições que não serão usadas pelo código, não serão garantidas.

Agora vamos falar um pouco sobre Criptografia. O .NET Framework possui um conjunto de serviços de criptografia que estendem os serviços fornecidos pela API do Windows, como a Crypto API.

O Namespace que contém toda essa funcionalidade é o System.Security.Cryptography. Esse Namespace provém acesso a diversos serviços de criptografia que você pode incorporar na sua aplicação para criptografar, descriptografar, assegurar a integridade dos dados, manipular assinaturas digitais e certificados, etc.

Veremos na próxima matéria, mais detalhes sobre o Namespace System.Security.Cryptography.

Até a próxima.