ASP NET - Security

Histórico

De longa data os servidores web sofrem ataques que visam degradar ou mesmo impedir seu funcionamento visando dificultar a vida das empresas e por décadas foram feitas correções para eliminar esses problemas.

Os exemplos aqui prestados são efeitos didáticos porque hoje a segurança é bem melhorada mas ainda encontramos algumas brechas de segurança em sites mal configurados.

Inicio

Inicialmente não havia problemas porque o cliente não enviava nada para o servidor exceto dados dentro de um form.

Nessa época o único ataque que até hoje é possível a toda aplicação é o sql injection que nada mais é inserir comandos sql junto com os dados digitados. Por exemplo, ao invés de digitar o nome o usuário 'digita jorge;drop table a*;joao' e se o programador não fizer uma proteção e concatenar o string para armazenar o nome no banco de dados vai ter surpresas desagradáveis.

File upload

A maioria das brechas de segurança vem em melhorias dos sistemas que são mal implementadas. As vunerabilidades só são descobertas depois que ocorrem.

Aí começou um inferno. Com o file upload o usuário podia enviar arquivos para o servidor web.

Um ataque pode ter diversas fases...a primeira de abrir uma brecha que permita, por exemplo, subir uma ameaça. Note que subir a ameaça não significa que ela esteja ativa ou atue em sua finalidade.
A segunda etapa é conseguir executar o código malicioso. Se você subiu o arquivo sabe onde está, nome do arquivo, pasta, etc...Os mecanismos de CGI normalmente estão habilitados (pelo menos nessa época) e ai ficava fácil para pedir ao mecanismo CGI executar o código e tornar a ameaça ativa.
Nota : sem o CGI um simples submit num form não funcionaria.

Inicialmente podiamos subir qualquer arquivo. Nesta época você subia um vírus (um arquivo .exe, dll, etc) e o executar ele era tarefa relativamente fácil, trabalhosa mas fácil. Lembre-se que o recurso de 'execute script' é um recurso fundamental em muitos serviços de servidores web.
Se o anti-vírus não segurasse teríamos um problema. E nessa época os anti-vírus eram uma porcaria e os 'hakers' muito criativos sempre inventando novas coisas para atrapalhar a vida dos outros.
Quantas vezes sabiamos que havia um vírus na máquina e a gente tinha que aguardar a próxima versão do anti-vírus para matar ele. O ruim é quando era necessário apagar o arquivo para eliminar o vírus ou mesmo ter que reformatar a máquina inteira por causa de um vírus que destruíu arquivos do sistema operacional.

Sendo assim fizeram regras que não podiam enviar arquivos .exe, dll ou com extensões tidas como perigosas mas não podiam inibir o serviço porque era particularmente importante para muitas empresas.
Ter a facilidade de enviar um arquivo pela Internet e não ter que levá-lo pessoalmente ao interessado é um recurso que poupa muito tempo e dinheiro.

Aí os hackers com ajuda da Microsoft bolaram um jeito de enviar um vírus dentro de um arquivo qualquer, mesmo texto, pdf. Bastava mudar a extensão do nome do arquivo de .exe para .txt que o sistema deixava subir o arquivo com vírus. Note que o programa consegue verificar a extensão do arquivo mas não o seu conteúdo.

Eu disse com ajuda da Microsoft e não foi à toa não, você não tinha como barrar a subida de um arquivo .txt mas na hora de abrir o arquivo o sistema operacional olhava dentro do arquivo e via que a estrutura do arquivo era um arquivo .exe e executava o vírus normalmente.

Felizmente hoje em dia temos bons anti-vírus e temos algumas funcionalidade que nos permite verificar a constituição do arquivo e, baseado no conteúdo e não na sua extensão, podemos barrar a subida do arquivo.

Novos ataques

Se não se podia enviar um vírus começaram a fazer aplicativos capazes de corromper o sistema. Novamente com ajuda da Microsoft. Foi a época dos 'vírus de Macros do Office' onde dentro do arquivo havia, por exemplo, uma macro maliciosa que era executada automaticamente quando o arquivo era aberto limpava seu hd ou coisa parecida ( veja a tabela de partição do seu disco ).

O problemas dos vírus de macros foram resolvidas pelos softwarea anti-virus e pela própria Microsoft dando extensões diferente para arquivos com e sem macros e os arquivos com macros quando abertos não executavam mais a macro automaticamente, informavam ao usuário que havia macros e se ele habilitar pessoalmente elas podem ser executadas. Essa mudança foi feita no próprio jeito que o office funcionava.

Ataques DDOS ou DOS (Denial Of Service)

Se não podiam enviar um vírus poderiam fazer o servidor ficar tão ocupado que não conseguisse atender aos seus clientes ?

A ideia base era descobrir um serviço qualquer prestado pelo servidor como uma página um pouco pesada ou que exigisse um pouco mais do servidor e fazer tantas solicitações a esta página que o servidor simplesmente negaria o serviço por estar ocupado demais.

Muitas empresas ficaram com servidores inativos por esse tipo de ataque e até hoje mecanismos atuam dinâmicamente para bloquear uma aplicação quando massivas solicitações são feitas pelo mesmo endereço ip. Hoje a coisa ficou mais complicado porque os hackers conseguiram colocar o ataque até em cameras de segurança e aí o ataque fica muito mais abrangente mas não chega a derrubar um servidor da empresa porque existe sempre uma restrição de banda, restrição de alocação dos recursos de uma app ou algo parecido que segura o ataque.

Sites Camaleão

São sites que se passam por sites verdadeiros copiando exatamente as páginas do site verdadeiro e fazendo com que os seus serviços se pareçam com os dos sites verdadeiros até atingirem seus objetivos como obter a conta bancária e a senha do usuário.

O ataque era feito com a cumplicidade de algum outro site. Por exemplo, os hackers fizeram tantas solicitações ao site camaleão deles que o Google hankeou o sites deles como o mais popular no seu sistema de busca e quando você entrava no Google procurando 'banco de brasil', por exemplo, era direcionado para o site dos camaleões que era igualzinho ao site do banco. Lembre-se que o Google hankeia os sites com critérios específicos e antigamente esse ataque acontecia.

Termos técnicos utilizados

Há muitos termos utilizados pela Microsoft especialmente em inglês que muitas vezes você fica semana para descobrir o que é. Vejamos alguns.

Profile : É o conjunto de informações sobre algum item do processo. O mais comum é o user profile aonde você armazena as informações do usuário como nome, email, perfil, etc. Este 'profile' pode ser armazenado na session do servidor ou mesmo em cookies. Podemos ainda definir quanto tempo a informação será útil, por exemplo, por 2 horas (120 minutos), 30 minutos, etc. Note que na autorização de acesso a página podemos utilizar os dados da profile para controlar o acesso ao recurso.

Impersonate : É quando um usuário 'roda' algo como se fosse outro usuário. Por exemplo, temos um usuário autenticado e queremos que ele atue como um usuário comum numa certa pasta do site. No profile (veja acima) podemos definir que o campo pode ser impersonate adicionando ao campo a cláusula allowAnonymous="true". Veja o documento clicando aqui.

Contudo podemos também que o usuário 'rode' a aplicação com credenciais que só a aplicação sabe para aumentar a segurança. Por exemplo, o usuário entra no site, usa o site e pode até usar o sql server sem problemas mas no site ele 'roda' a aplicação com credenciais especiais do site, nem ele mesmo sabe qual é. Isto não seria Impersonate mas sim um quesito lógico de segurança implementado na solução.
Note que o recurso 'impersonate' resolve o problema do usuário ser 'público' mas ter uma identificação de maneira que possamos identificar o usuario e saber quem fêz o que no site ou no banco de dados.

Conceitos Fundamentais

Autenticação é o processo de identificar os usuários.

Autorização é o processo de garantir o acesso dos usuários baseados na sua identidade.

No windows NT as definições de segurança são gravadas no arquivo, ou melhor dizendo, no próprio sistema de gerenciamento de arquivos, dentro e em cada arquivo, independentemente. Se você já alterou as permissões em uma pasta com muitos arquivos no windows NT viu que ao alterar a permissão o windows demorou muito porque teve que gravar a segurança em cada arquivo.

Usuários dentro do windows : Dentro do windows, bem como na web, temos 2 classes de 'usuários' : Os autenticados e os não autenticados.

No windows os usuários NÃO AUTENTICADOS rodam com as credenciais BUILTIN\Usuários e tem acesso muito restrito ao sistema operacional, só podem 'ReadAndExecute, Synchronize', ou seja, 'Ler e Executar', 'Listar Conteúdo da pasta' e 'Leitura' dos arquivos. Não tem permissão para criar novos arquivos muito menos alterar os arquivos já presentes na pasta. Nesta classe de usuários está o nosso IIS-IUSRS ( usuário default não autenticado para o Servidor web ).

Os usuários 'AUTENTICADOS' rodam com as credenciais 'AUTORIDADE NT\Usuários autenticados' e tem um acesso bem melhorado : 'Modify, Synchronize' mas não é o full. Em resumo suas permissões são as do usuário não autenticado mais alterar arquivos. Contudo eles NÃO PODEM criar arquivos nem extender suas permissões a outros arquivos e/ou usuários.

Além desses 2 usuários temos mais 2 usuários importantes mas não tem o nome 'usuário'. São eles o sistema operacional (AUTORIDADE NT\SISTEMA), os administradores do sistema operacional (BUILTIN\Administradores) que rodam com a permissão 'FullControl'. Sem essas credenciais você sequer conseguirá, por exemplo, atualizar o anti-virus da sua máquina pois ele poderá criar arquivos novos na atualização e isso não é permitido para os outros usuários. Eles podem fazer qualquer coisa até extender as suas permissões a outros usuários e, por esse motivo, a senha do admin de qualquer servidor deve ser segredo senão vira zona.

Note que existe uma falha absurda no windows : Sempre que o sistema vai atualizar algo importante ele pergunta ao usuário ( via UAC ) se deve ou não prosseguir como se o usuário entendesse ou sequer soubesse o que será feito pela alteração.

O windows, bem como qualquer outro sistema operacional, abstraí muita coisa simplificando a vida do usuário mas em ocasiões onde a coisa é severa e pode detonar a máquina ele pergunta ao usuário, um leigo, se deseja prosseguir ou não sem sequer mencionar o que será feito na alteração e isto é feito, com certeza, porque a Microsoft não deseja ser a 'única' culpada pelo dano causado ao equipamento e deseja ter você como cúmplice. É uma piada mas é o mundo real.

Para que segurança ?

A grande maioria dos sites são públicos e as informações estão lá para todos verem. É o caso do Google e mais de um milhão de sites, por exemplo.

Contudo muitos sites disponibilizam informações que são restritas a um usuário mas não são tão sigilosas. É o caso das redes sociais. Embora não sejam tão 'sigilosas' praticamente todas as redes sociais de hoje já utiliza criptografia de ponta-a-ponta para ninguém interceptar as mensagens trocadas. Contudo grandes sites como Facebook comercializam as informações e preferencias dos usuários.

Finalmente temos os sites cujas informações além de pessoais e restritas são sigilosas como é o caso do banco. Neste caso tudo que for possível para melhorar a segurança é utilizado. Por exemplo, a autenticação por dois fatores onde um site envia um código para o seu celular para que você confirme e o acesso ao site seja liberado.

Note que a autenticação é exigida sempre que tentamos acessar informações privadas do site. Pode ser algo pessoal ou destinado a um grupo como os administradores de um site.

Você também deve conhecer aquela autenticação que pede para você clicar em algo para evitar o acesso a robos no site. Aparece uma tela com imagens para você clicar nas figuras que tem carro...depois outra que tem faixas de pedestres...depois ainda que você clica fica aparecendo um 'aguardar' que demora para responder e autorizar.... Segurança muitas vezes gera um ódio terrível nos usuários mas não tem jeito, temos que nos sujeitar se quiser continuar.

Quem é ?

Se você está num site que exibe informações sem qualquer autenticação você está acessando o site com as credenciais de um usuário visitante ou não autenticado. Este usuário é criado por default dentro do windows com o nome IIS_IUSRS e dentro da pasta root do site este usuário tem a permissão de 'Ler e Executar', 'Listar Conteúdo da pasta' e 'Leitura'.

Dentro da aplicação asp net para que este usuário tenha acesso ao site devemos autorizar ele a acessar o site adicionando :
        <authorization>
            <allow users="*"/>
        </authorization>
dentro da chave <system.web>.

Veremos mais tarde que o asterisco(*) significa todos os usuários o verbo 'allow' permite o acesso.

Note que como a segurança é implementada em todos os pontos do sistema. Sendo assim o usuário IIS-IUSRS existe no NTFS mas tem que existir algo na aplicação permitindo seu acesso ou não. Digamos que são independentes mas para que algo funcione a segurança tem que ser definida em todos os níveis.

Formas de autenticação no ASP NET

A autenticação é necessária sempre que queremos acessar informações privadas ou restritas dentro do site. Podem ser direcionadas a um grupo de usuários ( role ou regra ) ou a um usuário específico.

None : Indica que não há nenhuma forma de autenticação do usuário, tudo no site é público que é o mesmo que dizer que não há informações privadas no site.

Windows: O ASP .NET usa o IIS (Internet Information Service) para autenticar os usuários e senhas. O IIS trabalha de três formas: Básico, Digest e Integrado com o Windows.
Note que ao escolher estas autenticações a opção de usuário anônimo poderá ser desabilitado ou não.

Se precisar de um exemplo dessa autenticação clique aqui

Passport : Este tipo de autenticação é realizada com as credenciais armazenadas nos servidores da Microsoft. A vantagem de usar este tipo de autenticação é que a Microsoft armazena usuários e senhas para você como quando você entra num site que exige autenticação e o windows abre um box perguntando se deseja salvar o usuário e senha desse site. A diferença é que no exemplo essas credenciais são salvas no seu micro mas no IIS utilizando as autenticação passport as credenciais serão armazenadas no servidor da Microsoft.

Nota : É necessário instalar o Passport.sdk no Visual studio para trabalhar com este tipo de autenticação.

Se precisar de um exemplo dessa autenticação clique aqui

Forms : Neste tipo de autenticação se o usuário ainda não for autenticado ele será direcionado à pagina de autenticação e, se a autenticação for aceita, a página solicitada será retornada ou uma página contendo a mensagem de erro informando que o usuário não passou no processo de autenticação.

Se precisar de um exemplo dessa autenticação clique aqui

Na autenticação tipo forms temos os seguintes parâmetros possíveis no web.config:

Nota : os termos que deram para ser traduzidos para português eu fiz mas alguns são parâmetros e devem permancer em inglês para funcionarem corretamente.

Elemento	Atributo	Descrição
<authentication>	mode	Deverá ter a palavra Forms para definir o tipo de autenticação
<forms>	name	Será o nome do cookie onde a credencial será armazenada. O default é .authaspx. Nota : se houver mais de uma aplicação rodando no servidor o nome do cookie deverá ser único, ou seja, cada aplicação deverá ter seu próprio nome de cookie exclusivamente.
<forms>	loginUrl	É a página de autenticação do usuário que será enviada a ele caso ainda não esteje autenticado. O default é 'Default.aspx'.
<forms>	protection	O default desse parâmetro é All que define que o cookie será protegido pela criptografia e a validação do usuário será exigida obrigatóriamente. Se o parâmetro for 'Encryption' o cookie será protegido pela criptografia mas a validação será facultativa. Se o parâmetro for 'Validation' o cookie será utilizado para validação mas a criptografia é facultativa. Se o parâmetro for 'None' tanto a criptografia do cookie bem como a obrigatoriedade do login via form serão facultativos.
<forms>	timeout	Define por quantos minutos os dados de autentição permanecerão válidos. Passados esses 'minutos' sem qualquer atividade do usuário no site a autenticação deixará de ser válida e ele será encaminhado novamente a página de login
<forms>	path	É a pasta onde o cookie será armazenado na máquina do usuário. O default é a pasta corrente, ou seja, '\' mas podemos escolher uma pasta para armazenar nossos cookies.
<credentials>	passwordFormat	Define a criptografia a ser empregada no cookie. O default é 'SHA1' mas podemos mudar para 'MD5' ou 'Clear' onde o cookie não será criptografado.
<users>	name	Define um nome de usuário que será aceito na autenticação forms.
<users>	password	Define a senha de usuário que será aceito na autenticação forms. Note que no web.config a senha é armazenada como texto sem criptografia mas no usuário, dentro do cookie esta deverá ser criptografada obrigatóriamente senão todos saberão como entrar no site como usuário autenticado.

Importante : Note bem que até este nível não temos regras de acesso aos componentes e serviços do IIS. Por exemplo, no servidor temos o serviço de envio de emails(SMTP) mas onde está definido que aplicação pode ou não acessar essa funcionalidade ? Só porque está no servidor não significa que todos podem ou devem acessar. Foi para isso que foi criada a namespace Security.

Fechando as portas - Security

Você deve se lembrar que no windows a coisa também era feia, muitos ataques danificaram o sistema operacional e deixaram as máquinas de usuários inoperantes.

Uma grande ideia da Microsoft foi o UAC ( User Account Control ) onde uma aplicação, por default, roda com baixos privilégios administrativos e se ela quiser alterar algo no sistema o sistema pergunta ao usuário que a app quer fazer a alteração e o usuário pode autorizar ou negar a permissão.

Por isso dizemos que no windows todo usuário com direitos administrativos deve ter uma boa senha porque impede esses ataques. Jamais deixe a senha do windows em branco.

Hoje em dia um site web tem condições de diferenciar o que é um recurso próprio do ASP NET e um recurso externo ao ASPNET como do sistema operacional, por exemplo, SMTP e um recurso de acesso a dados, como o Oledb. Note que para esses recursos fora do ASPNET funcionarem precisam de um código que é normalmente uma dll e o ASP NET chama o componente para extender suas funcionalidades.

E porque não aplicar a mesma regra do windows no site web...a app roda dentro de um ambiente compartimentalizado ( pool de aplicação ) e se quiser acessar algo que seja fora do serviço asp net vai ter que pedir permissão.

A ideia é a seguinte : No servidor eu tenho um serviço, por exemplo, SMTP que é feito pelo sistema operacional. Se sua aplicação quiser acessar esse 'componente externo' vai ter que declarar ele direitinho (versão, assinatura, etc) e pedir permissão para o sistema operacional para acessar o componente. O servidor web tem as politicas de acesso definidas e vai permitir ou negar o acesso conforme sua conveniência.

Só para dar uma ideia exibo abaixo como faço o registro um componente de acesso a dados (mysql) no web.config de minha aplicação:

  <system.data>
    <DbProviderFactories>
      <clear />
      <add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient"
           description=".Net Framework Data Provider for MySQL"
          type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.9.7.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
    </DbProviderFactories>
  </system.data>

Como o servidor web não tem um administrador 24 horas por dia para apertar o botão autorizando ou negando as autorizações resolveram criar um ambiente de segurança para a aplicação onde o usuário solicita a elevação da credencial e o servidor web, baseado em regras pré-estabelecidas, autoriza ou nega o acesso.

Citando um exemplo, tenho um site asp rodando perfeitamente todos os objetos do asp net numa boa.

Contudo numa parte da aplicação preciso chamar o serviço de SMTP para enviar um email (serviço feito pelo sistema operacional) ou um serviço como MySQL ( feito por uma DLL específica ) e aí terei que declarar os objetos que pretendo acessar no web.config e solicitar ao System.Security acesso a eles.

Como funciona

A segurança no servidor IIS é implementada diretamente pelos componentes que ela utiliza. Os componentes são :

1-NTFS : O administrador do servidor define quais são os objetos e a segurança deles para que o site funcione perfeitamente e atenda as necessidades dos usuários.

2 - ACL, Polices ou Regras(Roles) : A maioria dos servidores web estão implementados em servidores que possuem autenticação de usuário e regras de grupos e usuários. Este 'gerenciamento de usuários' é feito por ferramentas como o 'Active Directory' do Windows. Podemos criar usuários, grupos de usuários e definir o acesso deles aos componentes do sistema Windows ou Web.

Dentro do gerenciador do IIS podermos criar regras ( roles ) para controlar o acesso a pastas, páginas do site permitindo ou negando ou mesmo definindo que um usuário deve utilizar credenciais de outro usuário para ter acesso ao site.

3-Machine Config (arquivo web.config) : É o próprio Framework instalado no servidor IIS. Neste arquivo determinamos o modo de funcionamento de todas as aplicações na máquina. Por exemplo, em servidores web ligados na Internet é aqui que definimos o nível de confiança ( Trust Level ) 'Médio' inibindo seu 'override', ou seja, você na sua aplicação não poderá passar por cima dele.

Chamamos esta configuração da máquina ou machine.config porque ela afeta todas as aplicações .NET que rodam na máquina sejam elas aplicações de console (Console applications), Aplicações windows ( Windows Forms ), Biblioteca de classes (Class Libraries) e as aplicações web feitas com o .NET.

4-Machine Config (arquivo machine.config) : É o arquivo do próprio Framework que informa quais os recursos foram intalados no sistema e que conseguem interagir com o servidor IIS. Por exemplo, se você instalou um componente de conexão ADO para acessar o MySQL ele é automaticamente registrado aqui pelo sistema operacional no momento da instalação do componente.

5-IIS : Arquivo applicationHost.config.

Vimos que no framework temos 2 arquivos : o machine.config que informa quais os componentes foram instalados no servidor e o web.config que define a segurança para todos os aplicativos que usam o framework na máquina, seja ele uma aplicação de console ou outra coisa qualquer.

No applicationHost.config definimos onde e quais os componentes do sistema operacional poderão ser usados pelo IIS, ou seja, a definição de quando buscamos um serviço do IIS pelo seu nome qual a ddl que executa a tarefa. Por exemplo, que o nome 'HttpLoggingModule' está ligado a dll "%windir%\System32\inetsrv\loghttp.dll" ( veja globalModules ).

Este arquivo não define níveis de confiança mas sim dos componentes instalados na máquina quais o servidor web ASP NET utiliza, muitos deles copiados do web.config do framework para o web.config do IIS. Define quais componentes podem ser usados pelo servidor web. Note que esta configuração não são normalmente alterada pelo usuário mas sim pelos softwares de instalação do IIS e de seus componentes.

Define os componentes básicos do funcionamento do IIS como system.applicationHost, system.webServer, authorization, system.ftpServer, applicationPools, listenerAdapters:http, a pasta DefaultAppPool:physicalPath="%SystemDrive%\inetpub\wwwroot", a porta do serviço IIS : 80, a pasta do arquivo de logs (%SystemDrive%\inetpub\logs\LogFiles"), o nome dos arquivos default (defaultDocument), a associação entre os módulos do IIS e as dlls que executam a tarefa (Ex: ConfigurationValidationModule:%windir%\System32\inetsrv\validcfg.dll), páginas de erro personalizadas, os isapiFilters que são as dlls do ASP NET, define que o usuário não identificado tenha acesso ao servidor (<anonymousAuthentication enabled="true" userName="IUSR" />), as extensões de arquivos permitidas ou não no site, a segurança e relacionamento entre os objetos IIS e as respectivas dlls que as executam ( handlers accessPolicy="Read, Script" ), define quais os módulos estão acessíveis ou não as aplicações (modules).

É um componente chave do IIS com certeza na definição de seus componentes internos.

6-Do root do site IIS (arquivo web.config): define o que as aplicações do site pode ou não fazerem. Este é o primeiro nível de segurança definível pela aplicação mas todas as aplicações instaladas em sub-pastas estarão sujeitas as determinações do web.config da pasta root do site.

7-Da aplicação (arquivo web.config) : Cada aplicação tem o seu web.config que determina o que a app pode fazer. Este é o segundo nível de segurança definível pela aplicação, o primeiro é o do root do site.

Importante : As entidades possuem seguranças totalmente independentes entre sí. Se definimos a segurança, por exemplo, a nível da aplicação ao rodar a aplicação e esta solicitar um recurso do sistema operacional ( como um ADO ), neste caso, estará sujeita a segurança do nível que executa a tarefa, mais claramente, do Framework.

Fazendo uma analogia com a vida real digamos que eu tenho algumas regras para o que faço em minha casa. Elas valem para coisas que ocorrem na minha casa mas se eu for fazer algo na casa do meu cunhado ? As minhas regras deverão ser 'adaptadas' as regras da casa do meu cunhado porque na casa dele é ele quem manda, eu sou só um visitante. Portanto quando defino alguma regra ao nível da app e a app solicita um serviço do sistema operacional, as regras são outras e é ele quem manda. Estamos sujeitas a elas.

Como funciona - Detalhes

Quando estamos trabalhando com sites com certas restrições de segurança temos as seguintes opções :

•1 -'verificar a permissão' , ou seja, precisamos verificar se temos acesso ao recurso desejado antes de executar a tarefa. Se tivermos podemos executar o serviço senão não podemos executar a tarefa porque com certeza ocorrerá um erro de acesso ao componente.

•2 -Os componentes de segurança podem comunicar entre sí e pedir permissão de acesso ao recurso. Como no windows quando pede permissão para o administrador para realizar uma tarefa. Na aplicação ela 'pede' o acesso ( que não teria se não pedisse ) e o sistema pode dar esse acesso baseando nas regras configuradas na segurança.

Como numerado acima cada um dos itens define sua própria segurança. A partir do item 3 começam os configs e eles ao definirem novas regras podem permitir a sobrescrita ( override ) dos elementos inferiores ou não. Se houver o override na regra o item inferior poderá definir nova regra e a regra do nível superior será ignorada. Mas se o nível superior não definir a sobrescrita da regra e o componente inferior tentar redefinir essa mesma regra isso provocará um erro.

Fazendo um resumo : Se você tentar fazer o acesso diretamente ao componente poderá ser barrado e isto ocasionará um erro.
Portanto você precisa pedir o acesso ao componente através da comunicação da segurança dos componentes.
A app ASPNET solicita o acesso ao servidor web que por sua vez responderá se tem acesso ou não.

Detalhe importante

Outro conceito fundamental é que como a segurança é implementada em camadas a aplicação de um nível de confiança em um nível de segurança não é o mesmo que a aplicação desse mesmo nível de confiança em outro nível de segurança .

Por exemplo, para rodar a aplicação o web.config do root do site precisa ter o nível de confiança full senão irá ocorrer um erro se segurança porque a aplicação não terá acesso aos recursos do sistema para rodar 'web apps'.

Sendo assim se você definir qualquer nível de confiança diferente de full no web.config no root do site todas as aplicações irão parar de funcionar porque perdem o acesso aos componentes do sistema necessários para a execução do ASP NET.

Contudo se você definir o nível de confiança "Médio" no web.config do framework do servidor IIS ( machine.config ) apenas se a aplicação tentar acessar 'coisas importantes' do sistema ou de outros sites terá que perdir permissão ao sistema para prosseguir. Mas uma aplicação asp net simples rodaria sem problemas

System.Security

Esta é a ferramenta que permite as ferramentas de segurança comuniquem-se uma com as outras e obter as informações sobre segurança dos componentes do ASPNET. Este recurso permite obter do elemento 'pai' (que vai executar a tarefa) se a página filha (que solicita o serviço) tem acesso ou não ao recurso. A resposta pode ser autorizado ou negado. Note que a permissão é solicitada antes de sequer tentar acessar o objeto porque se tentar e não estiver autorizado é erro na certa.

Como System.Security Funciona ?

O acesso a esses componentes externos ao ASP.NET. é gerenciado pela segurança desses componentes externos. O System.Security pode perguntar se tem acesso ou não ao recurso.

Se você está lembrado quando o windows vai executar uma operação que pode potencialmente pode danificar ou alterar o sistema ( lógicamente essas alterações já são contidas pelas regras do próprio sistema operacional ) ele pede ao usuário que confirme a modificação que a atualização pretende fazer. O usuário autoriza ou não e é para isso precisa de 'credenciais' como a senha e/ou perfil de administrador do windows, para prosseguir.

Note que temos 2 elementos interagindo ai, a aplicação rodando com baixos privilégios e o famoso UAC (User Account Control) que define que privilégios o usuario possí e autoriza ou rejeita a tarefa em questão.

Seguindo a mesma linha de raciocínio no ASP.NET porque não rodar o aplicativo compartimentalizado, ou seja, o ASP.NET pode fazer o que quiser dentro do ASP.NET mas quando for utilizar recursos externos ao ASP.NET a segurança do componente externo determina se pode ou não executar a tarefa .

Essa 'restrição de acesso' foi implementada porque só porque existe um recurso não significa que todos podem utilizar. Por exemplo, temos no sistema operacional um recurso de envio de emails chamado SMTP. Só porque o sistema operacional tem o recurso significa que todas as apps podem utilizar ele sem restrições ? Não seria bom saber qual app acessa o recurso e qual não pode ou deveria acessar ? Por esse motivo inventaram o System.Security que pergunta ao sistema operacional (ou a segurança do elemento pai ) se tem autorização de acesso ao componente.

Caso tenha dúvida no que é barrado ou permitido de acordo com o nível de confiança do servidor IIS sugiro dar uma lida em neste item .

Implementação da Segurança

Todos que trabalham com infra sabem que o poder do usuário é a sua liberdade para fazer a tarefa desejada. Hoje em dia damos esse 'poder' ao usuário mas tentamos acercar suas atividades para que não sejam impactantes no caso de um erro grave.

A implementação da segurança é feita por cada item isoladamente e independentemente. É o 'mecanismo de segurança' que deve integrar a segurança desejada pela aplicação com a segurança desejada para manter o servidor e dessa maneira uma aplicação possa interagir com outra aplicação e saber o que pode e o que não pode fazer. Vejamos como é feita na realidade.

Tipo de Segurança	Security.Permissions ou utilitário	Finalidade
NTFS	Nenhuma.Nativa do Sistema operacional.	Gerencia os direitos de acesso, o acesso em sí(lock) ao arquivo ou pasta
ACLs, Policies, Regras(Roles)	Utilitários Caspol.exe, PermView.exe ou IIS Manager	Podem exibir ou mesmo definir a politica local de segurança para uma máquina, grupo ou usuário a nível do sistema operacional (Polices + NTFS)
Pelo Programa	Grupos de permissões	A segurança é definida em 'partes do código' que será chamado para extender a funcionalidade ASPNET. Proporciona um nível extra de segurança verificando se as medidas de segurança estabelecidas na máquina não estão sendo violadas (*1).
Criptografia(Cryptographic)	É uma 'Strong Name' de um utilitário/Assembly chamado SignCode.exe.	Permite a utilização da infraestrutura de chaves públicas e certificados

Strong Name : É um nome reconhecido pelo sistema (confiável por default).
*1 - Não quer dizer que só porque o sistema tem o recurso que todas as aplicações possam utilizar o recurso livremente

Note que por regra default o acesso direto a funcionalidade poderá ser negado. A aplicação deve 'verificar a permissão' através do sistema de segurança que informará se tem ou não acesso a funcionalidade e, a partir daí, podemos acessar a funcionalidade sem possibilidade de erro. A gente chama isso de 'aperto de mão' ou 'handshake' em inglês que nada mais é que pedir licença para fazer tal coisa.

Outro recurso do sistema de segurança é executar a aplicação web com baixos privilégios e, se a aplicação 'solicitar', elevar o privilégio da aplicação até o nível de segurança determinado pelo objeto pai. É como a elevação de credenciais do windows onde o windows pergunta ao usuário se realmente deseja fazer a alteração ( via UAC ).

Sendo assim se o programa acessar o recurso diretamente terá o acesso negado porque está rodando com baixas credenciais mas se pedir ao sistema a elevação de credenciais e ele responder que pode elevar, o acesso ao componente será permitido .

A solicitação de acesso é pedida confrontando credenciais, da seguinte maneira : A aplicação pede ao sistema de segurança o acesso de escrita em um arquivo. O sistema de segurança autoriza ou não. Se receber a autorização a aplicação poderá escrever no arquivo senão não poderá alterar o arquivo original.

Segurança Provida pelo NTFS

Este é o nível mais baixo e básico da segurança.

Se você conhece o windows conhece o NTFS de cor e salteado, sabe que podemos dar acesso e retirar o acesso a qualquer elemento dele, com excessão do sistema operacional claro.

Sempre que uma app roda no servidor ASPNET ela roda com as credenciais de um usuário do windows ou que o windows reconhece como um usuário. Por default é o IIS_IUSRS se for um usuário não autenticado mas pode ser outro usuário, com outros tipos de autenticação do windows (forms, passaporte, etc.)

Por exemplo, na pasta local do seu servidor IIS ( C:\Inetpub/wwwroot ) o usuário IIS_IUSRS só tem permissão para 'Ler e executar' e 'Leitura'. Até mesmo um 'Listar' arquivos está bloqueada. Com isto, por default, até mesmo um file upload seria barrado porque ele não tem a permissão de 'Gravar' e nem mesmo poderia alterar o conteúdo de um arquivo já existente porque não tem a permissão 'Alterar'.

Note que cabe ao administrador do windows realizar a tarefa de estabelecer a segurança nas pastas do servidor web. Se você é o administrador do seu servidor saiba que uma coisa é um servidor local e outro um servidor ligado na Internet. Com o poder do administrador vem grandes responsabilidades e no conjunto de responsabilidades vem as responsabilidades pelas consequencias de seus atos. Saiba o que está fazendo antes de fazer especialmente quando se trata de Internet.

Como este é o nível mais baixo de segurança recomendo não fazer alterações nele, o próprio instalador do IIS faz isso automaticamente deixando o site seguro para rodar na sua máquina.

Listas de Controle de Acesso(ACL) - Polices - Regras (Roles)

Quando atribuimos a 'permissão' a um grupo de usuários temos uma lista de usuários. Sendo assim as 'Listas de Controle de Acesso(ACL)' agrupam pastas, arquivos, usuários, ou seja, algum recurso do sistema a um ou um grupo de usuários definindo o que eles podem fazer ou não. Normalmente esse serviço é feito pelo gerenciador de usuários que é um componente chave do 'Active Directory'. Por regra o 'Active Directory' controla o acesso a todos os componentes do sistema.

Note que este recurso do usuário acessar uma pasta ou arquivo nativamente vem do UNIX através do comando CHMOD e foi copiado por todos sistemas operacionais de hoje.

Note que num windows básico até mesmo professsional as ACLs são implementadas dentro do próprio NTFS mas em servidores esse controle é muito melhor elaborado, temos o gerenciador de usuários com funcionalidades muito mais bem elaboradas. Através das ACLs ou Polices podemos definir se o usuário pode criar pastas ou criar um grupo com características administrativas próprias e sempre que um usuário precisar dessas 'características' para trabalhar a gente adiciona ele ao grupo.

Nota : Este recurso é bastante perigoso para usuários leigos. Eles podem retirar acesso deles mesmos a recursos e depois precisarão da ajuda do administrador do sistema para recuperar o acesso ao elemento.

Administrador da Máquina (machine administrator)

A 'administração da máquina' ou machine.config é totalmente isolada do sistema operacional (NTFS) ou das ACLs, Policies e Regras(Roles) do sistema NT de servidores windows. contudo não pode passar por cima delas NUNCA.

É chamada de Machine config porque afeta todos os tipos de aplicações .NET da máquina seja ela uma aplicação de console, Windows Forms, aplicações web, Biblioteca de classe.

Esta configuração está no próprio framework do servidor e é definida quando configuramos o serviço IIS no nosso servidor IIS.

Se você instalou o servidor IIS ele, por default, instalou uma conjunto de regras para seu 'funcionamento'. Este 'funcionamento' pode estar de acordo com o que você precisa mas normalmente precisará de alguns ajustes feito pelo 'Gerenciador do Serviços de Informações da Internet (IIS)'

Administrador do Framework (Framework web.config)

Esta configuração está no próprio framework no arquivo web.config.
Como diz a própria Microsoft no site No momento, não há snap-in do console de gerenciamento Microsoft (MMC) ou outra ferramenta de administração fornecida pela Microsoft que você pode usar para criar e modificar arquivos config, portanto se quiser alterar este arquivo terá que fazê-lo na mão o que não recomendo e normalmente não é necessário.

Se abrir o arquivo vai ver que o nível de confiança é full (<trust level="Full" originUrl="" />). Para aplicações na sua máquina local está muito bom porque você poderá fazer tudo mas em servidores esta configuração costuma ser 'Medium' o que nos obriga a trabalhar com o System.Security.

Administração do servidor IIS

Dentro do servidor IIS temos um arquivo chamado applicationHost.config que define as regras gerais como o servidor IIS deve operar. Essas regras são mais básicas e menos alteradas como, por exemplo, a pasta onde o site IIS está instalado ou a porta web que o servidor IIS responde.

Segurança pelo Código(Code Security)

Esta é a segurança que definimos nos web.configs tanto no root do site bem como nas aplicações dentro do root do site.

A 'segurança pelo código' é a segurança implementada pela nossa aplicação (web.config).
Está subordinada a 'administração da máquina' que por sua vez está subordinada as regras definidas pelo NTFS não podendo passar por cima delas NUNCA.

Segurança pela Criptografia(Cryptography)

Este é o nível mais elevado da segurança e está presente cada vez mais nas comunicações entre os dispositivos eletronicos.

Para dar uma ideia hoje podemos ter chips numa placa de circuito impresso ( incontávelmente mais simples que um computador ) falando um com outro usando protocolos de criptografia para melhorar a segurança na troca da informação.

A criptografia embaralha a comunicação entre dois elementos de maneira que somente eles conseguem entender a informação que está sendo trocada. É como um dialeto onde duas pessoas estão falando e quem entra no meio não entende nada.

Sem essa 'chave' os dados trocados não poderão ser descriptografados ou, por exemplo, com uma chave de criptografia de 256 bits o mais poderoso computador do mundo pode demorar semanas para decodificar um bloco de informações de 2KB isso se tiver uma ideia do resultado a ser encontrado. E já existe criptografia de 512 bits ou mais, por exemplo, uma imagem pode ser usada como chave de criptografia.

Para criptografia começar a funcionar requer que inicialmente de 'chaves' . Essas chaves definem como os códigos de criptografia ou descriptografia devem funcionar. Sem elas é impossível tanto codificar como decodificar as informações.

Chaves públicas ou privadas

Se um servidor vai 'falar' com outro e trocar informações não públicas ( sigilosas ) é bom estabelecer um certo sigilo nessa comunicação ou todas as informações que estão sendo trocadas podem ser 'capturadas' por sites inescrupulosos.
A melhor maneira de fazer isso é uma espécie de 'aperto de mão' (handshake) entre os servidores onde eles estabelecem uma 'linguagem' ou 'código' que só eles entendem e isso é feito com criptografia das informações cujo 'código chave para a criptografia' é feito por 'chaves de codificação'.

A chave privada fica dentro do servidor e jamais é enviada ou sai do servidor por nenhum motivo que seja. São criadas num servidor e compartilhadas entre as empresas por outros meios que não os públicos, como um email ou algo com excelente garantia de sigilo ( que deve usar criptografia para isso).

A chave pública é uma chave que o servidor de destino envia ao servidor de origem isto quando estabeleceu alguma regra de 'confiança' com ele. Note que se a chave for assimétrica a chave usada para criptografar a informação não pode ser usada para descriptografar a mesma informação.

Chaves Simétricas e Assimétricas

Uma chave é chamada de chave simétrica quando a mesma chave é utilizada para criptografar e descriptografar a mensagem. Sendo assim uma chave simétrica só poderia ser uma chave pública se o site destinatário estabeleceu uma relação de confiança com o site remetente. Isto é feito, por exemplo, no HTTPS.

As chaves são chamadas de chaves assimétricas quando uma chave é usada para criptografar e outra chave é utilizada para descriptografar.
O método comum é quando o destinatário envia uma chave ao remetente/codificador (chave pública - ver abaixo) que codifica a mensagem e a envia ao destinatário contudo somente o destinatário tem a chave para decodificar a informação (chave privada - ver abaixo ).
Note que se a mesma chave for usada para criptografar e descriptografar a informação este processo não obterá os dados originalmente criptografados.

Se você trabalha com SQL conhece o método de criptografia MD5 e sabe que o que ele codifica não pode ser decodificado. Por exemplo, salvamos a senha de um usuário num banco de dados utilizando o código MD5. Para uma aplicação verificar se o usuário digitou a senha correta ele simplesmente pega o dado digitado e converte utilizando o código MD5 e compara o MD5 do dado digitado com o MD5 da senha no banco de dados. Se forem iguais a senha está correta. Portanto alguns algorítimos de criptografia somente tem um sentido, só criptografam. São os mais seguros.

Certificado Digital

Os certificados digitais são pedra chave para a funcionalidade SSL da Internet.
A certificação é feita por um elemento externo e inviolável.

O primeiro tipo de certificado não é utilizado na Internet e são feitos por cartões inteligentes (smartcards) que normalmente é uma memória com os dados do cliente e um chip processador destinado a proteger o acesso a esses dados. O protocolo necessário para obter as informações do cartão é um conjunto de regras particulares que a agência certificadora definiu de maneira única e exclusiva. Até mesmo para ler o cartão normalmente é vendido com uma máquina leitora exclusiva da agencia certificadora.

A segurança neste tipo de cartão é tão rigida que o acesso incorreto e seguido por 3 vezes inutiliza em definitivo o cartão.

Este recurso é muito utilizado por advogados e contadores para endossar seus documentos. Se quiser mais detalhes sobre este tipo de certificado digital veja a CertSign ou Certificação Digital.

O segundo tipo é o certificado emitido por uma identidade idônea que endossa a autenticidade do remetente da informação. Neste caso a entidade 'endossante' é um site que usa todos os recursos de segurança conhecidos para não ser fraudada. Essa entidade 'endossante' verifica o ip/mac do remetente da informação e se este ip/mac estiver numa lista de entidades confiáveis ele emitirá o certificado.

No caso do certificado digital para sites (SSL) temos 2 tipos : O compartilhado e o não compartilhado. O compartilhado é quando na mesma máquina todos os sites utilizam o mesmo certificado. Sendo assim é impossível trocar informação sem saber a máquina que originou ela, contudo precisará ser feita uma investigação para ver qual site dentro da máquina servidora enviou a informação.
Quando o certificado não for compartilhado não tem como enviar uma informação de um site para outro através de qualquer segurança sem que seja identificado. Se você conhece bem, por exemplo, a emissão de uma nota fiscal sabe bem como esse processo funciona.

SSL - Secure Sockets Layer

O SSL atua a complementar o serviço de criptografia.
Com o SSL podemos identificar sem sombra de dúvida que quem está enviando a informação é realmente quem ele diz ser .

Quando o site remetente é identificado positivamente por um certificado SSL no navegador aparece um cadeado fechado informando que o site é seguro. Portanto sempre que acessar seu banco veja o cadeado... se ele não aparecer cuidado.

Como o SSL funciona:

Nível de Confiança (Trust Level) em sites web

Não confunda permissão com nível de confiança. Permissão a gente define quem e o que pode ser feito em cada objeto do sistema como no caso do NTFS. O nível de confiança está acima do nível de confiança e é independente e nada mais é que uma autorização que damos para que seja possível realizar uma tarefa e que resguarde nossos recursos de maneira a ficarem confiáveis por mais tempo possível. Contudo o nível de confiança sempre estará submisso ao nível de permissão definido para cada objeto.

Quando você executa um aplicativo ASPNET utiliza o framework e, com certeza, o framework tem configurações de segurança e confiança. Quando você instala o framework ele tem um nível de confiança, por default, Full. Mas isto é muito arriscado para um servidor web.

Note que para executar uma app ASPNET é utilizado um framework para compilar e executar a aplicação. Portanto existe um framework em sua máquina e um outro no servidor onde você publica o seu aplicativo. É obrigatório que ambos os frameworks sejam compatíveis mas podem ser executados com níveis de confiança diferentes, ou seja, o seu framework local deve estar rodando com o nível de confiança full mas no servidor dever ser o medium para baixo.

Segurança no Sistema Operacional - NTFS

Note que quando definimos algo no NTFS fazemos isso para todos os sites de nosso servidor IIS.
Contudo algumas aplicações precisam de permissões especiais para funcionarem e, quando abrimos a permissão no NTFS abrimos para todos os sites do servidor.

Por exemplo, para fazer um file upload numa aplicação precisamos dar a permissão de 'Escrita' na pasta para o usuário público do IIS ( IIS_IUSRS ) suba arquivos o que permitirá subir qualquer tipo de arquivo . Ao fazer isso abrimos a permissão de acesso não só para o site corente mas sim para todos os sites do servidor.

Segurança no Sistema Operacional - Listas de acesso (ACLs), Polices e Regras(Rules)

Para facilitar o gerenciamento e 'afinar' o controle de acesso dos usuários temos as listas de controle de acesso que define, por exemplo, um grupo de de usuários e que usuários pertencem a esse grupo. Por exemplo, quando no windows definimos que os administradores do windows tem acesso full aos recursos isso é armazenado numa lista, tanto o nome do grupo de usuários (administradores) como o nível de acesso(full) e quem pertence a essa lista ( os usuários que pertencem ao grupo 'administradores' e que, por causa disso, são administradores do sistema).

No IIS podemos criar regras (roles) de acesso aos recursos tanto do serviço IIS como dos sites dentro dele. Veja no Gerenciador do IIS o item 'Regras de Autorização', 'Adicionar Regra de Permissão.

Note bem que temos permissões ditadas em um nível hierárquico, de baixo para cima, pelo NTFS, pelo Policy, ACLs e Regras(Roles) e pela segurança da aplicação. Quando solicitamos o acesso a um recurso nossa aplicação vai através do security buscar essas credenciais no elemento mais superior, o policy. Se o policy não tiver a informação vai perguntar ao NTFS.

Outra coisa é que nossa app nunca vai ter permissão maior que a dada pelos seus elementos superiores. Sempre terá seu limite ditado pelo elemento superior.

Níveis de Confiança

Os níveis de confiança ajudam a melhorar a segurança no site.

Por default o nível de confiança é Full, ou seja, não há restrições.

Mas se a gente mudar o nível de confiança do IIS para 'Médio' (Medium) ao executar a aplicação ele irá 'rodar' com baixos privilégios e se quiser acessar algo tido como perigoso será barrado por default. Contudo, mesmo rodando com o nível de confiança 'Médio' podemos escalar a credencial até o que o nível superior de segurança ( através da Namespace System.Security) e aí poderemos, a partir desse recurso de segurança ter acesso ( ou não ) ao recurso do sistema desejado. Como no windows quando ele exige a permissão do usuário para fazer alguma tarefa tida como 'perigosa' ao sistema.

Abaixo temos uma tabela com os níveis de confiança do IIS e as restrições sofridas por cada tipo de 'nível de confiança'

Nível de Confiança	Descrição
Acesso pleno - FullTrust	Permite o acesso a todos os recursos. A própria Assembly do programa é inserida na lista de acesso pleno.
Tudo - Everything	Permite o acesso a todos os itens cobertos pelas permissões.
Nada - Nothing	Nega a permissão de acesso inclusive o privilégio de execução (Execution) dado na pasta pelo windows.
Execução - Execution	Permite o privilégio de execução de scripts na página.
Pular verificação - Skip Verifications	Habilita todos os objetos a pularem o processo de verificação de segurança
Internet	Define os direitos básicos necessários a aplicações da Internet
LocalInternet	Define direitos bem mais amplos que os da Internet mas não é FullTrust

Como na sua máquina só você ou o sistema operacional pode executar tarefas a coisa é segura mas na Internet a coisa é diferente, o nível máximo de segurança é Médium.

Machine.config

Se quiser visualizar a configuração do framework local do seu micro veja a pasta onde o framework seu foi instalado porque depende da versão. A pasta padrão é %SystemRoot%\Microsoft.NET\Framework%bits%\versão\Config e que no meu micro atualmente está em C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config.
Note que %bits% pode ser 32 ou 64 bits.

Chamamos a configuração do framework de machine.config porque afeta todas as aplicações na máquina sejam elas aplicações de console, windows forms, aplicações web, classes.
Essa configuração só é alterada pela instalação ou remoção de componentes pertinentes ao serviço web ou ao framework.

No framework temos 2 arquivos de configuração : machine.config e o web.config.

O arquivo machine.config não define segurança mas sim quais são as versões e quais são os elementos fundamentais para o framework funcionar como connectionStrings, mscorlib (core do framework), system.data, system.data.oledb, system.data.sqlclient, system.net, authenticationModules e até mesmo de módulos externos instalados no servidor como MySQLRoleProvider entre muitos outros.

Se quiser ver um modelo do arquivo machine.config Clique aqui

O arquivo web.config define o nível de confiança do Framework. Procure por trust level e vai ver que esta opção esta marcada como 'FULL' (<trust level="Full" originUrl="" />).

O arquivo Web.Config(do Framework) está na mesma pasta do machine.config e define os defaults e os recursos disponíveis a nível de servidor para as aplicações. A configuração armazenada nele é definida pela configuração que fazemos do IIS no 'Gerenciador de Informações da Internet (IIS)'. Caso deseje ver um modelo desse arquivo Clique aqui.

Aplication.config ou o config do IIS

O arquivo ApplicationHost.config do IIS fica na pasta onde o IIS foi instalado, ou seja, na pasta do windows, system32 e sub-pasta inetsrv ( C:\Windows\System32\inetsrv ).

O ApplicationHost.config (arquivo applicationHost.config) pode ser configurado via 'Gerenciador do Serviços de Informações da Internet (IIS)' clicando no elemento 'Pool de Aplicativos' e na janela central temos os pools de aplicativos. O que costumamos usar é o DefaultApp.pool e clicando no item com o botão direito do mouse temos acesso a 'configuração básica' e a 'configuração avançada do item'.

Caso queira visualizar em detalhes os parâmetros definidos neste arquivo de configuração Clique aqui

Segurança dentro da nossa aplicação

A segurança da aplicação está sujeita a segurança do servidor IIS que está sujeita a segurança do ACLs/Polices/Roles, NTFS. Cada um trabalha independentemente mas são integrados por componentes de segurança que permitem obter a segurança ou mesmo escalar o baixo privilégio que a aplicação está rodando no momento para uma mais alta, sem passar por cima dos outros.

A partir deste ponto temos os arquivos web.config que podemos configurar na noassa aplicação.
Se nossa app fica no root estaremos configurando o web.config do root do site mas podemos ter uma app instalada numa pasta dentro do root do site. A hierarquia de funcionamento dos web.cofigs é feita como ilustrado na figura a seguir.

Todos os arquivos de configuração da figura acima e abaixo mencionados ficam no servidor.

No web.config note que as definições do nível hierárquico superior podem ser 'mergeadas' ou somadas com a dos níveis inferiores ou sub-pastas se o parâmetro overrideModeDefault="Allow" ou "Deny" ou não . Podemos definir que um parâmetro definido num nível superior seja 'sobrescrito' por um nível inferior ou não.

O arquivo web.config no root do site ( não confunda com o superior (web.config root) que fica no framework do servidor ) define um um modelo para o pool da aplicação e é publicado quando você publica seu site no root do site. Este item personaliza os demais acima para todas as aplicações do pool e é definido e publicado pelo desenvolvedor em sí.

O web.config root do site fica na pasta default do IIS, ou seja, C:\inetpub\wwwroot.

O arquivo web.config abaixo do root do site são os web.configs das aplicação ou sub-pastas do servidor. São definidas e publicadas pelo desesenvolvedor e definem regras para uma aplicação em particular no servidor IIS.

O web.config da aplicação fica dentro da pasta root do site, na subpasta da aplicação, ou seja, dentro de uma sub-pasta de C:\inetpub\wwwroot.

Resumo 1 : Súmula dos elementos configuráveis no servidor IIS :
1-NTFS : Define a segurança básica dos elementos no servidor.
2-ACLs e Polices : Num servidor NT temos os serviços de gerenciamento de usuários que definem os recursos acessíveis ao usuário ( Normalmente o Active Directory)
3-O framework que roda a app dentro do servidor. Configurado pelo gerenciador do IIS
4-O Machine do IIS que gerencia os componentes instalados no servidor IIS.
5-Root do IIS : Define em linhas gerais o que as apps podem fazer.
6-Config do App : web.config de sua app que roda dentro de uma sub-pasta do root do site.

Resumo 2: A hierarquia dos configs temos :
1-NTFS e ACLs : Definidos pela segurança básica do servidor pelo administrador.
2-Machine.Config - Do próprio framework/IIS que roda no servidor
3-Web.Config.Root(Framework) - web.config do próprio framework que roda no servidor
4-Application.Config - É o web.config do servidor IIS.
5-Web.Config.Root(Site) - É o web.config do servidor IIS.
6-Web.Config.App - É o web.config da sua app que está dentro de uma sub-pasta do root do site do IIS.

Nota 1 : O item 1 tem prioridade sobre o item 2 e assim por diante. Portanto se o item 1 (pai) define uma proibição o item 2 não poderá passar por cima dela. Mas o contrário é possível, se o nível inferior define uma restrição e o nível superior não tem essa restrição a tarefa será executada sem problemas. Lembre-se que as seguranças são totalmente independentes e que a segurança é definida sobre itens que o elemento opera, portanto se o nosso elemento está chamando outro item 'externo' o item externo é o principal responsável pela segurança.

Nota 2: Um config pode definir o que lhe é pertinente mas pode se omitir o que não lhe é pertinente. Explicando melhor o Machine.config como config mais alto tem por obrigação definir o que é mais básico para o framework funcionar mas ele sequer sabe se o IIS está instalado ou não e por isso não define nada sobre o IIS. Citando exemplos, o 'web.config root(machine-IIS)' e o 'Application Config' não definem 'níveis de confiança(<trust level="Full" originUrl="" />)' porque não faz parte do escopo de configuração do elemento.

Se você conhece CSS sabe como essa hierarquia funciona...sempre a última definição é a que vale mas nos configs isso pode ser proibido se o parâmetro override estiver inibindo. se o elemento superior permitir

Configurando sua aplicação para rodar com o nível de confiança Full

Vá no arquivo web.config da sua app na sua máquina e adicione :
<trust level="Full" originUrl="" />

dentro de <system.web>

Quando esta definição não existe a aplicação roda com o nível de confiança default do IIS que é full por default. A aplicação deverá rodar normalmente sem problemas.

Configurando sua aplicação para rodar com o nível de confiança Alto(High)

Vá no arquivo web.config da sua app na sua máquina e adicione :
<trust level="High" originUrl="" />

dentro de <system.web>

A sua aplicação deverá dar erro de funcionamento porque ao fazer isso o IIS perde acesso ao ASP NET (framework) por motivos de segurança. Pode alterar para qualquer outro nível (Full|High|Medium|Low|Minimal) que você não terá acesso. Apenas com o nível de acesso Full irá funcionar.

Nota : Clique na imagem com o botão direito do mouse e selecione 'Abrir a imagem em outra guia'. Ela será exibida bem maior e com mais acuidade.

Por esse motivo definir o nível de confiança em sua aplicação local é besteira porque só funciona com FULL.

Contudo lá no seu servidor web o web.config do framework está configurado para o nível 'Médio'(Medium) e o 'override=false' o que significa que você na sua app não poderá mudar isso.
Aí sim você terá que fazer alguns 'preparativos' para acessar componentes da máquina ou externos tidos como 'perigosos ao ASP NET'.

Configurando o IIS para rodar as aplicações com nível de confiança Alto(High)

O IIS por default vem com o nível de confiança Full. Ao alterar o nível de confiança neste ponto (IIS) você estará mudando o nível de confiança no root do site web (C:\Inetpub\wwwroot\web.config). É o mesmo efeito que se você mudasse o nível de confiança do web.config na aplicação root do seu site. Ela simplesmente irá parar de funcionar.

Para alterar o nível de confiança que o IIS roda suas aplicações vá até o gerenciador de serviços do IIS, selecione 'Default web site', clique com o botão direito do mouse em 'Níveis de confiança' e selecione 'Abrir Recurso' e selecione o nível de confiança desejado e não se esqueça de clicar no botão 'Aplicar' no painel à direita da tela.
Depois no painel esquerdo clique no item superior (seu micro) e no painel a direita selecione 'Reinciar'.

Se você quiser ver onde esta alteração foi feita vá na pasta root do site ( normalmente C:\inetpub\wwwroot ), abra o web.config com o bloco de notas e procure por trust level=

Porque usar um nível de confiança diferente do Full

Sites feitos com tecnologias mais antigas são obrigados a rodar com nível de confiança full porque o mecanismo de segurança ainda não existia na época que as ferramentas de desenvolvimento foram criadas. Por esse motivo sites feitos com tecnologias mais antigas são muito mais vuneráveis que os modernos e só conseguem 'sobreviver' na Internet porque o leque de funcionalidades dessas antigas aplicações web é muito restrito.

O problema de rodar aplicações com nível de confiança full, por exemplo, é que você não restringe o uso dos seus recursos pelos demais sites do servidor ou de um servidor compartilhado. Por exemplo, se eu defini uma pasta para file upload todos os outros sites do servidor podem usar a pasta sem restrições fazendo, por exemplo, que minha cota de disco seja estourada por um monte de lixo.

Por exemplo, se estamos utilizando a tecnolgia ASP NET tudo o que for feito dentro dele utilizando apenas a tecnologia ASP NET dentro da aplicação local será aceito. Coisas simples como exibir o nome do servidor (Environment), acessar o ADO e alguns recursos do ASP NET ( que normamente não são usados ) poderão sofrer restrições devido a este nível de segurança.

Contudo os serviços ASP NET são complementados por inúmeras ferramentas expandem seu potencial. Uma delas, por exemplo é o ADO que permite o acesso a bancos de dados. Se você tentar acessar um banco de dados utilizando ADO num servidor IIS com nível de confiança médio será barrado da seguinte maneira :

Análise passo a passo

Primeiramente vamos partir de um ponto onde tudo funciona para ir fechando a segurança e vendo o que é preciso para que a app continue funcionando.

Importante : Quando alteramos parâmetros no 'Gerenciador de Serviços de Informação da Internet (IIS)' as modificações são feitas na pasta onde o framework foi instalado. Se quiser testar mude o trust level, salve e abra o arquivo web.config do framework. A alteração estará lá.

Com relação a configuração da minha máquina tenho o seguinte :

1-Na pasta framework (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config), que é configurado pelo gerenciados do IIS, tenho :
1.1-O machine.config não define nível de confiança (trust level).
1.2-O web.config do framework : Está com o nível FULL TRUST (<trust level="Full" originUrl="" />).
Note que é no framework que temos os configs para todos os níveis de confiança.

2-Na pasta o config do IIS temos o config da aplicação (applicationHost.config) que não define nível de confiança.

3-Na pasta root do site (C:\inetpub\wwwroot) tenho o web.config e nele temos a definição do nível de confiança full ( <trust level="Full" originUrl="" />).

4-Na pasta root do meu site o servidor IIS através da segurança do windows defini que o usuário IIS_IUSRS só tenha a permissão de 'Ler e executar', 'Listar conteúdo da pasta' (que não recomendo em servidore da Internet) e 'Leitura'. É o default de segurança quando a gente instala o IIS na máquina local.

5-No web.config da minha aplicação não defini nada de nível de segurança ainda. Portanto ela está rodando com o default do IIS que é a full. Contudo coloquei as seguintes definições dentro do web.config, dentro do <system.web> para :

5.1-<customErrors mode="Off" /> - Exibe os detalhes dos erros e não os erros amigáveis default da configuração do IIS.

5.2 -
        <authorization>
            <allow users="*"/>
        </authorization>

Para que qualquer usuário tenha acesso as páginas do site.

Outra configuração importante que é colocana no web.config quando criamos uma nova aplicação é a depuração de erros que deverá ser habilitada pelo seguinte comando:
<compilation debug="true" />.

Esta linha pode ser colocada depois do Authorization.

Resumindo:
1-No web.config do framework/IIS defini o nível de confiança Full.
2-No web.config do root do Site defini :
2.1-O nível de confiança Full.
2.2-Que todos tenham acesso ao site (autorização).
3-A autenticação é nativa do windows e está rodando com as credenciais do usuário default do IIS.

Resultado : a aplicação deverá rodar sem problemas. Se tiver o problema é na instalação do IIS.

Definindo o nível de confiança para full

Este é o default mas as vezes alteramos e dá erro e precisamos voltar.

Para definir o nível de confiança para full no web.config da minha aplicação acrescento a linha :
<trust level="Full" originUrl="" />
dentro da área configuration/system.web do web.config da aplicação.

Resultado : a aplicação deverá rodar sem problemas.

Definindo o nível de confiança para Médio a nível apenas da aplicação

condições do teste - As mesmas do teste anterior mas alterei web.config do root do Site onde defini o nível de confiança para Médio.
Mudei uma linha no web.config da aplicação: <trust level="Medium" originUrl="" />

Resultado : a aplicação deu erro de segurança.

Note que o erro ocorreu na carga do aplicativo e não na execução do mesmo. Isto se deve ao fato que um recurso que o ASP NET precisa para rodar, o framework, não teve permissão de acesso.

Esta configuração só é usada em sites com alta segurança e para isto trazemos o framework para dentro da nossa aplicação e aí os componentes do framework estarão acessíveis porque estão dentro de nossa aplicação. Mas sua implementação é relativamente complexa e foge aos objetivos deste documento.

Ajuda saber o que sua aplicação web precisa do .NET para funcionar ?

A resposta é não muito. Fica mais fácil saber o que está faltando se soubermos o que é necessário, ou seja, o que falta e provocou o erro é algo que esta sendo utilizado pela aplicação.

Criando um projeto web vazio no Visual Studio as seguintes referências as namespaces de suporte da aplicação são feitas :

System, SystemComponentModel.DataAnnotations, System.Configuration, System.Core, System.Data, System.Data.DataSetExtensions, System.Drawing, System.EnterpriseServices, System.Web, System.Web.ApplicationServices, System.Web.DinamicData, System.Web.Entity, System.Web.Extensions, System.Web.Services, System.XML, System.XML.Linq.

Se você for no gerenciador do iis e selecionar 'Default web sites' e selecionar o item 'Páginas e Controles' clicando com o botão direito do mouse, selecionar 'Abrir Recurso' e abrir a aba NameSpaces verá que as System,System.Collections, System.Collections.Generic, System.Collections.Specialized, System.ComponentModel.DataAnnotations, System.Configuration, System.Linq, System.Text, System.Text.RegularExpressions, System.Web, System.Web.Caching, System.Web.DynamicData, System.Web.SessionState, System.Web.Security, System.Web.Profile, System.Web.UI, System.Web.UI.WebControls, System.Web.UI.WebControls.WebParts, System.Web.UI.HtmlControls, System.Xml.Linq.

Batendo as NameSpaces declaradas na sua APP versus a do IIS notamos que falta :
01-SystemComponentModel.DataAnnotations.
02-System.Core.
03-System.Data e System.Data.DataSetExtensions.
04-System.Drawing.
05-System.EnterpriseServices.
06-System.Web.ApplicationServices.
07-System.Web.DinamicData.
08-System.Web.Entity.
09-System.Web.Extensions.
10-System.Web.Services.
11-System.XML

Como eu disse acima não ajuda muito porque alguns serviços são usados na app, mas não no servidor. E o inverso também é valido. Podemos notar que no servidor tem muito mais namespace definida que na app.

Análise do erro gerado

Contudo na mensagem de erro está exibindo uma mensagem do foco do erro :
1-Erro: Policy Exception: Não foi possível obter a permissão para execução.
2-Objeto : FileLoadException: Não foi possível carregar arquivo ou assembly 'Microsoft.WebTools.BrowserLink.Runtime

Portanto houve um erro causado pela segurança que impediu o acesso a um recurso nativo do framework utilizado pelo ASP NET.

Onde está o maldito CAS (Code Access Security) ?

No framework 2 foi implementado a segurança e por esse motivo, a tecnologia ainda não estava madura, os componentes ainda não estavam com suas funcionalidades bem estruturadas, e para auxiliar na bagunça havia uma ferramenta auxiliar de gerenciamento da configuração da segurança do IIS.
Era uma ferramenta prática, visual e muito útil no framework 2.
No framework 4 a segurança foi em muito melhorada e seus componentes agregaram novas funcionalidades fazendo com que esta ferramenta fosse retirada simplesmente porque não era mais prática.

Rodando nossa app em servidores com nível de segurança Médio

Como eu sugeri neste documento faça uma página ASP NET simples, faça um teste e, se funcionar, agrege um pouco mais da complexidade necessária na sua página e refaça o teste. Passo-a-passo até encontrar um problema.

Com a depuração ligaga (debug = true) você terá o recurso e a linha do programa que deu erro e isto é a melhor pista para sua solução que você irá encontrar.

De cara posso dizer a vocês que recursos como o Ambiente do Servidor (Environment), o ADO (trazendo o seu componente para dentro do bin da sua app) irá funcionar perfeitamente no nível médio de segurança.
Faça um teste e confirme. Pode ser que haja um erro de configuração do servidor e aí você vai ter que abrir um chamado no suporte do provedor do seu site para corrigir o problema.

Note que se a segurança foi fechada no servidor você poderá pedir permissão de acesso ao componente e será permitida ou não dependendo do que foi configurado no servidor.

Por exemplo, existe a namespace System.Security.Principal que permite você obter as credenciais do usuário logado. Se você está logado como usuário público do IIS ( IIS-IUSRS ) lógicamente você não será administrador da máquina, não estará logado e muito pouco irá acrescentar ao que você já sabe sobre esse usuário.
Contudo nesta NameSpace podemos ter o GUID do usuário e dos grupos a que ele pertence.
Sendo assim, por motivos de segurança, o correto é fechar o acesso a essa Namespace e com isso fechamos uma porta para os invasores e para os usuários. Digamos que as informações 'podem ser vistas' ou são irrelevantes ou são perigosas.

Súmula componentes afetados pela segurança

Num.	Componente	Utilização	Restrição
1	Ambiente(Environment)	System.Environment.Variavel. Veja aqui	High(N), Medium(N),Low(?),Minimal(?)
2	Arquivos	Segurança implementada pelo Windows NT	File-IO - High(N), Medium(S),Low(S),Minimal(S)
3	Fila de mensagens		Message Queue - High(N), Medium(S),Low(S),Minimal(S)
4	Reflection		Reflection - High(N), Medium(S),Low(S),Minimal(S)
5	Rede		Socket - High(N), Medium(S),Low(S),Minimal(S)
6	ACLs, Polices, Regras(Roles)		Directory Services - High(N), Medium(S),Low(S),Minimal(S)
7	Log de Eventos		Event Log - High(N), Medium(S),Low(S),Minimal(S)
8	Indicadores de Performances		Performance Counters - High(N), Medium(S),Low(S),Minimal(S)
9	Registro do Windows		Registry - High(N), Medium(S),Low(S),Minimal(S)
10	DNS		High(N), Medium(S),Low(S),Minimal(S)
11	Impressão		Printing - - High(N), Medium(S),Low(S),Minimal(S)
12	Sistema de Segurança		System Security- High(N), Medium(S),Low(S),Minimal(S)
13	Armazenamento Isolado		Isolated Storage - High(N), Medium(S),Low(S),Minimal(S)
14	Diálogo para abrir arquivo		File Dialog - High(N), Medium(S),Low(S),Minimal(S)

Por definição no nível de segurança full nenhum componente sofrerá qualquer restrição.

Os itens Web, UI são fundamentais para uma app web e por isso havendo restrição destes itens nada será exibido. Por padrão não devem ser restritos pela segurança.

Requisitando acesso

Você pode solicitar acesso a um recurso e o retorno será o máximo acesso permitido.
As solicitações abaixo estão em C# mas para vb basta mudar [ por < e ] por > .
Essas tags devem ser inseridas no Assembly do seu projeto e a referencia ao System.Security também.

A solicitação pode ter como parâmetro minimum, optional ou refused.

Solicitando permissão de acesso a File.IO :
[assembly:FileIOPermissionAttribute (SecurityAction.RequestOptional,All="C:\\")]

Solicitando permissão do windows :
[assembly:UIPermissionAttribute (SecurityAction.RequestMinimum, Window=UIPermissionWindow.SafeSubWindows)]

Fechando o acesso ao recurso:
[assembly:SecurityPermissionAttribute (SecurityAction.RequestRefused,UnmanagedCode=true)]

Súmula - Como trabalhar com servidores web com segurança Média

Quando o provedor configura a segurança média no servidor ele fecha as portas ao funcionamento de sites, como o asp clássico ou php porque tudo que o site precisa para funcionar tem que estar disponível na sua pasta local, jamais irá acessar pastas externas as designadas ao site.

Sendo assim, por exemplo, se o seu site vai usar o MySQL você vai ter que colocar a dll do MySQLData dentro da pasta bin do projeto porque é lá que vai estar seu código compilado ( VBNET ou C# ) e quando ele precisar acessar o componente do MySQLData vai encontrar na pasta local e irá funcionar normalmente.

Como você deve saber o código VBNET ou C# de todo o site é compilado é guardado numa única dll e colocado na pasta bin. Se seu código acessa componentes externos do COM (Component Object Model- Veja adicionar Referências no menu Projeto) ou mesmo se você foi no GIT e trouxe alguns componente, coloque eles na pasta bin e faça seu projeto referenciar ao componente local na pasta bin.

Dicas de funcionamento

Outra dica fundamental é que todo provedor tem uma página informando como deverá ser feita a conexão e como utilizar os componentes.

Por exemplo, sites da UOL exigem versões específicas de componentes ( como o MySQLData ) para funcionarem. Eles mencionam quais que funcionam e normalmente são surpreendentemente velhos.

Eu aconsellho a seguir a 'receita de bolo' do provedor e fazer exatamente como ele menciona. Passo a passo.

Eu já perdi dias tentando fazer uma coisa funcionar e em 2 horas mais consegui fazer funcionar com a dica do provedor.