Hospedando Múltiplas Aplicações ASP.NET

Microsoft Corporation

Janeiro 2004

Neste Módulo

Os sistemas operacionais do Microsoft® Windows® Server 2000 e Windows Server™ 2003 fornecem ambientes de hospedagem amplamente escaláveis e robustos. Eles podem ser usados para hospedar, com segurança, centenas de sites da Web e aplicações do ASP.NET em um único servidor ou farm da Web.

No entanto, ao utilizar aplicações do ASP.NET em cenários compartilhados de hospedagem, você deve levar em conta como as aplicações estão isoladas uma da outra e de recursos compartilhados do sistema, incluindo o sistema de arquivo, o registro, e logs de evento. Sem o isolamento adequado, uma aplicação fajuta ou mal desenvolvida pode afetar, de maneira prejudicial, outras aplicações no servidor, ou então acessar recursos não-autorizados. Esse isolamento da aplicação e especialmente significativo para os Internet Service Providers (ISPs), que hospedam grande número de aplicações de diferentes empresas.

Este módulo explica as técnicas que você pode utilizar no Windows 2000 e 2003 para isolar as suas aplicações em ASP.NET a fim de assegurar a integridade, confidencialidade e autenticidade dos dados que estão no seu Web site.

Objectivos

Use este módulo para:

• Compreender a arquitetura e os principais componentes do ASP.NET no Windows 2000 e 2003.

• Isolar aplicações da Web usando múltiplas identidades, pools de aplicações e segurança de acesso ao código.

• Configurar personificação anônima de uma conta.

• Configurar personificação fixa de conta para acessar recursos locais ou remotos ao se autenticar usuários que utilizam autenticações ou certificados integrados do Windows.

• Aprimorar a segurança de autenticação dos formulários.

• Compreender como as credenciais são usadas ao se acessar dados armazenados em compartilhamentos UNC.

Aplica-se a:

Este módulo se aplica aos seguintes produtos e tecnologias:

• Microsoft Windows Server 2000 e 2003

• Microsoft .NET Framework 1.1 e ASP.NET 1.1

Como Utilizar Este Módulo

Este módulo está focado em como você é capaz de obter o isolamento da aplicação em ambientes de hospedagem compartilhados. Um dos principais elementos é a segurança de acesso ao código. Utilize este módulo juntamente como seguinte:

• Leia o Módulo 8, "Segurança de Acesso ao Código em Prática" (em inglês). Ele explica mais sobre como a segurança de acesso ao código atua e de que maneira ela pode ser usada para reprimir montagens individuais e, por exemplo, limitar sua habilidade de acessar o sistema de arquivo, o registro, a rede e outros recursos críticos.

• Leia o Módulo 9, "Usando a Segurança de Acesso ao Código com o ASP.NET" (em inglês). Ele explica como a diretiva de segurança de acesso ao código trabalha para as aplicações ASP.NET e aborda as considerações e implicações para a construção de aplicações parcialmente confiáveis.

• Leia o Módulo 16, "Protegendo o seu Servidor" (em inglês). Ele mostra a você como proteger o sistema operacional do Windows 2000 e Microsoft .NET Framework. Uma plataforma segura fundamental é um pré-requisito para proteger uma aplicação ASP.NET ou Web Service.

Nesta página

Introdução
Arquitetura do ASP.NET no Windows 2000
Arquitetura do ASP.NET no Windows Server 2003
Isolando Aplicações pela Identidade
Isolando Aplicações com Pools de Aplicação
Isolando Aplicações com a Segurança de Acesso ao Código
Questões sobre Autenticação de Formulários
Hospedagem de Compartilhamento do UNC
Sumário

Introdução

Em um ambiente de hospedagem compartilhado, é fundamental garantir que uma aplicação não cause um impacto desfavorável na operação e segurança de outras aplicações.

Há inúmeras maneiras de se obter o isolamento da aplicação. As opções disponíveis dependem da versão do .NET Framework e do sistema operacional que você executa no servidor.

• Se você está executando uma versão 1.1 do .NET Framework, pode usar o modelo de limitação do recurso, fornecido pela segurança de acesso ao código, a fim de possibilitar um nível de isolamento da aplicação. Esse isolamento é obtido, restringindo uma aplicação de acessar diferentes tipos de recursos, tais como arquivos de sistema, registro, log de evento, Active Directory, bancos de dados, recursos da rede e outros.

• O Windows Server 2003 fornece isolamento do processo através dos pools de aplicação do Internet Information Services 6.0 (IIS 6), que permite que múltiplas aplicações sejam executadas em instâncias separadas do processo do IIS. O isolamento do processo não é possível no Windows 2000, pois todas as aplicações são executadas em uma única instância do processo de trabalho do ASP.NET, com os domínios de aplicação fornecendo o isolamento.

A Tabela 1 sintetiza as diversas opções para o isolamento da aplicação, que estão disponíveis no Windows 2000 e Windows Server 2003.

Tabela 1 Recursos de Isolamento da Aplicação para o Windows 2000 e Windows Server 2003

O Windows Server 2003 que executa a versão 1.1 do .NET Framework é a plataforma recomendada para hospedar múltiplas aplicações do ASP.NET por suportar o isolamento do processo e fornecer a mais ampla variedade de opções para o isolamento.

Arquitetura do ASP.NET no Windows 2000

No Windows 2000, diversas aplicações da Web são executadas em uma única instância do processo de trabalho do ASP.NET (Aspnet_wp.exe). Cada aplicação reside em seu próprio domínio, que fornece um grau de isolamento para o código gerenciado. A arquitetura do Windows 2000/IIS5 é apresentada na Figura 1.

Figura 1. Arquitetura do ASP.NET no Windows 2000 com o IIS 5

Os componentes da arquitetura representada pela Figura 1 estão resumidos na Tabela 2.

Tabela 2 Componentes da arquitetura do Windows 2000 ASP.NET

Arquitetura do ASP.NET no Windows Server 2003

No Windows Server 2003, a arquitetura muda, pois o IIS 6 permite que múltiplos processos sejam usados para hospedar aplicações separadas. Isso é apresentado na Figura 2.

Nota O IIS 6 suporta um modo de compatibilidade inversa que, por sua vez, suporta o modelo do processo de trabalho do ASP.NET do IIS 5.0.

Figura 2. Arquitetura do ASP.NET no Windows Server 2003 com IIS 6

Comparado à arquitetura do ASP.NET no Windows 2000, a principal diferença no Windows Server 2003 é que instâncias separadas do processo do IIS (W3wp.exe) podem ser usadas para hospedar aplicações da Web. Por padrão, elas são executadas usando a conta NT Authority\NetworkService, que é uma conta de local menos privilegiado que atua como uma conta de computador sobre a rede. Uma aplicação executada no contexto da conta do Network Service apresenta as credenciais do computador para os servidores remotos autenticarem.

Configurando ACLs para o Network Service

Configurar uma ACL (access control list, lista de controle de acesso) para a conta do Network Service varia para as máquinas locais e remotas. Se você quer garantir acesso à conta do Network Service na máquina local, adicione a conta do Network Service em uma ACL. Se você quer garantir acesso à conta do Network Service em uma máquina remota, adicione a conta Nome_Domínio\Nome_Máquina$ em uma ACL.

Nota Não confunda a conta do Network Service com o grupo integrado da Rede, que inclui os usuários que foram autenticados através da rede.

Os principais componentes da arquitetura representada pela Figura 2 estão resumidos na Tabela 3.

Tabela 3 Componentes da Arquitetura do Windows Server 2003 ASP.NET

Isolando Aplicações pela Identidade

Você pode isolar as aplicações do ASP.NET a partir de um ponto de identidade do sistema, controlando a identidade da conta usada para executar cada aplicação. Se cada aplicação utiliza uma identidade separada de conta fixa, você pode autorizar e fazer a auditoria de cada aplicação separadamente.

Nota Se você hospeda uma aplicação em ASP.NET projetada usando o .NET Framework versão 1.0, a conta do processo precisa de permissões apropriadas para a raiz do drive atual do sistema de arquivo. Para mais informações, consulte o artigo 317955 da Microsoft Knowledge Base, "FIX: Mensagem de Erro Quando você Navega por uma Página do ASP.NET" (em inglês).

Há duas maneiras de se utilizar identidades fixas separadas para cada aplicação em um servidor compartilhado:

• Personificação anônima da conta

• Personificação fixa de identidade

Personificação anônima da conta

Com a personificação anônima da conta, a sua aplicação personifica a conta anônima especificada pelo IIS e configurada para o seu diretório virtual de aplicação. Você pode utilizar essa abordagem caso a sua aplicação autentique os usuários, independentemente do IIS, por exemplo, usando Formulários ou uma autenticação do Microsoft Passport. Nesses cenários, você pode isolar a aplicação usando uma conta fixa anônima. Uma vez que o visitante foi autenticado e os papéis foram verificados, o modelo confiável do servidor pode ser usado para baixar o acesso aos recursos, no qual a conta anônima configurada fornece a identidade confiável.

Para suportar esse argumento, os diretórios virtuais da aplicação no IIS devem suportar o acesso anônimo e uma conta anônima separada deve ser configurada para cada aplicação. A aplicação deve então ser configurada para personificação. Essa abordagem é mostrada na Figura 3. O acesso a recursos locais e remotos garante o contexto de segurança da conta anônima personificada.

Figura 3. Múltiplas contas anônimas usadas para cada aplicação

Para usar múltiplas contas anônimas para o acesso aos recursos

Este procedimento descreve como utilizar múltiplas contas anônimas, uma por aplicação da Web, para acesso de recursos a fim de suportar tanto a autorização quanto a auditoria individual da aplicação.

1. Crie novas contas anônimas de usuários, uma por aplicação.

   Para mais informações sobre a criação de uma conta anônima de usuário, consulte a seção "Contas", no módulo "Protegendo o Seu Servidor" (em inglês).

   Caso você necessite acessar recursos remotos usando a conta anônima, utilize ao menos uma conta de domínio privilegiada ou então uma conta local, e crie uma conta local duplicada no servidor remoto com um nome de usuário associado e uma senha.

2. Utilize as tags <location> em Machine.config para configurar cada aplicação para personificação.

3.	<location path="Web Site Name/VDirName" allowOverride="false" >
4.	  <system.web>
5.	    <identity impersonate="true" />
6.	  <system.web>
7.	<location>

A configuração allowOverride="false" previne que uma aplicação individual anule essa configuração em um arquivo Web.config. Para mais informações sobre o elemento <location>, consulte a seção "Explicação sobre Machine.config e Web.config" no módulo, "Protegendo a sua Aplicação ASP.NET" (em inglês).

1. Utilize o Gerenciador de Serviços da Internet para configurar cada diretório virtual da aplicação a fim de usar uma conta de usuário separada.

   a. Inicie o Internet Services Manager a partir do grupo de Ferramentas Administrativas.

   b. Selecione o diretório da aplicação, clique com o botão direito e depois clique em Propriedades.

   c. Clique na guia Segurança e depois no botão Editar.

   d. Certifique-se de que Acesso anônimo está selecionado e então clique em Editar.

   e. Digite o nome de usuário para a conta anônima que você criou, ou clique em Procurar para selecionar o nome de usuário de uma das listas.

   f. Caso você queira usar a conta para acessar um recurso remoto, desmarque a seleção de Permitir que o IIS Controle a Senha para a conta anônima.

   Se você selecionou a opção Permitir que o IIS Controle a Senha, a sessão de logon criada usando-se a conta anônima especificada possui credenciais de rede NULL e não pode ser usada para acessar recursos em que a autenticação seja exigida. Se você desmarcou essa caixa, a sessão de logon é uma sessão interativa com credenciais da rede. No entanto, se a conta local é para a máquina, nenhuma outra máquina na rede pode autenticar esta conta. Neste cenário, crie uma conta duplicada no servidor remoto de destino.

   Nota O tipo de sessão de logon criada é controlado pela configuração LogonMethod no Metabase do IIS. O padrão é uma sessão de logon interativa, que requer que a conta possua privilégio de usuário "Allow Log on Locally".

   A opção Allow IIS to Control Password não está disponível no IIS 6. O IIS 6 define o padrão LogonMethod como Network Cleartext, o que requer que a conta tenha um privilégio de usuário "Access this computer from the network". Isso permite que a conta seja autenticada por um servidor de rede.

2. Configure as permissões NTFS para cada conta a fim de garantir que cada conta tem acesso somente às pastas e arquivos apropriados do sistema, não podendo acessar recursos importantes como as ferramentas do sistema operacional.

   Para mais informações, veja o módulo "Protegendo o seu Servidor" (em inglês).

   Nota Se você executar o assistente do IISLockdown, ele criará um grupo Web Anonymous Users. Os membros deste grupo têm acesso negado aos diretórios e ferramentas do sistema.

Personificação Fixa de Identidade

Quando você precisa que o IIS autentique usuários para a sua aplicação (por exemplo, usando a autenticação Integrated Windows ou autenticação de certificado), você pode usar uma identidade fixa de personificação para executar a sua aplicação ASP.NET. Este cenário é apresentado na Figura 4.

Figura 4. As aplicações personificam uma conta fixa e a utilizam para acessar os recursos

Você pode configurar aplicações individuais em ASP.NET para personificar uma conta fixa. A vantagem desta configuração é que ela pode ser usada com qualquer método de autenticação do IIS e não requer autenticação anônima do IIS.

Para usar múltiplas contas fixas de personificação para o acesso aos recursos

Este procedimento descreve como utilizar múltiplas contas fixas de personificação, uma por aplicação, para que o acesso aos recursos suporte tanto a autorização quanto a auditoria individual da aplicação.

1. Crie novas contas anônimas de usuários, uma por aplicação.

   Para mais informações sobre a criação de conta anônima de usuário, consulte a seção "Contas" no módulo "Protegendo o Seu Servidor" (em inglês).

   Caso você necessite acessar recursos remotos usando a conta anônima, utilize ao menos uma conta de domínio privilegiada ou então uma conta local, e crie uma conta local duplicada no servidor remoto com um nome de usuário associado e uma senha.

2. Armazene as credenciais criptografadas da conta no registro.

   Execute o Aspnet_setreg.exe para armazenar as novas credenciais criptografadas da conta no registro. Para mais informações, consulte o artigo 329290 do Microsoft Knowledge Base, "Como Fazer: Utilize o Utilitário do ASP.NET para Criptografar Credenciais e Strings de Conexão do Estado de Sessão" (em inglês).

3. Configure as aplicações para personificação.

   Você pode fazer isso no Machine.config or Web.config. Para configurar múltiplas aplicações com diferentes identidades, utilize as tags <location> no Machine.config. A saída Aspnet_setreg.exe, executado no passo anterior, mostra você o formato exigido dos valores de atributos do userName e password para o elemento <identity>. Alguns exemplos são mostrados abaixo.

   <location path="Web Site Name/appvDir1" allowOverride="false" >
     <system.web>
        <identity impersonate="true"
                  userName=
             "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,userName"
                  password=
             "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,password"/>
     </system.web>
   </location>
   
   <location path="Web Site Name/appvDir2" allowOverride="false" >
     <system.web>
         <identity impersonate="true"
                   userName=
           "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,userName"
                   password=
           "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,password"/>
     </system.web>
   </location>
   

   Para configurar uma personificação no nível de aplicação, utilize o elemento <identity> no arquivo da aplicação Web.config, conforme mostrado abaixo.

   <identity impersonate="true"
      userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
      password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>
   

4. Configure as permissões NTFS para cada conta, a fim de assegurar que cada conta tenha acesso somente às pastas e arquivos apropriados do sistema, e nenhum acesso aos recursos mais importantes como as ferramentas do sistema operacional.

   Para mais informações sobre configuração das permissões NTFS para a conta anônima, consulte o módulo "Protegendo o seu Servidor" (em inglês).

Nota No Windows 2000 e no .NET Framework versão 1.0, se você personificar uma identidade fixa usando a configuração acima, você deve garantir o privilégio "Atuar como parte do sistema operacional" à conta do processo do ASP.NET para executar suas aplicações da Web. Isso é inverso ao princípio do menor privilégio. Recomenda-se que você se atualize para o .NET Framework versão 1.1, em que isso não é mais um requisito.

Isolando Aplicações com Pools de Aplicação

Se suas aplicações são executadas no Windows Server 2003, você pode usar os pools de aplicação e configurar cada uma delas para que rode em seu próprio processo, que fornece um isolamento de nível de processo. Por padrão, todas as aplicações são executadas em um pool de aplicação padrão. Com os pools, você é capaz de configurar cada processo para que seja executado usando uma identidade separada e, como resultado, você não precisa usar a personificação.

Para fornecer isolamento de nível de processo

1. Crie uma definição de novas contas do Windows, uma por aplicação, para rodar cada instância do processo.

2. Configure as permissões NTFS para cada conta, a fim de assegurar que cada conta tenha acesso somente às pastas e arquivos apropriados do sistema, e nenhum acesso aos recursos mais importantes como as ferramentas do sistema operacional.

   Para mais informações sobre configuração das permissões NTFS para a conta anônima, consulte o módulo "Protegendo o seu Servidor" (em inglês)

3. Desabilite a personificação da aplicação.

   Você pode fazer isso em Machine.config ou Web.config. Para desabilitar a personificação para múltiplas aplicações em Machine.config, coloque os elementos <identity> dentro dos elementos <location>, conforme mostrado abaixo.

   Utilize a seguinte configuração. Essa configuração não usa personificação.

   <location path="Web Site Name/appvDir1" allowOverride="false" >
     <system.web>
        <identity impersonate="false"
     </system.web>
   </location>
   

   Nota As aplicações ASP.NET não se personificam por padrão.

4. Crie novos pools de aplicação e configure-os para rodar sob as novas contas.

   Use o IIS 6 para criar novos pools de aplicação com as definições padrões, e utilize as contas criadas no passo 1 para configurar a identidade de cada pool, para que eles sejam executados usando uma identidade separada.

5. Configure cada aplicação para ser executada em seu próprio pool de aplicação.

   Na guia Diretório de cada aplicação do IIS, escolha o pool para que a aplicação seja executada nele.

Isolando Aplicações com a Segurança de Acesso ao Código

Com a versão 1.1 do .NET Framework, você pode configurar aplicações que sejam executadas em níveis parciais de confiança, usando o elemento <trust>. A seguinte configuração mostra como configurar um nível confiável da aplicação a partir do Machine.config. Neste exemplo, o nível Médio de confiança é utilizado.

<location path="Web Site Name/appvDir1" allowOverride="false">
  <system.web>
    <trust level="Medium" originUrl="" />
  </system.web>
</location>

Se você configurar uma aplicação que rode com um nível de confiança que não seja "Full," a aplicação terá permissões restritas de segurança de acesso ao código para acessar certos tipos de recursos. Desta maneira, você pode restringir as aplicações a fim de preveni-las de interagir com alguma outra e de obter acesso a recursos do sistema, tais como áreas restritas do sistema de arquivo, o registro, o log de evento e outras.

Para mais informações sobre os níveis de confiança do ASP.NET, sobre como eles podem ser usados para fornecer o isolamento da aplicação e sobre o design específico e considerações de desenvolvimento, consulte o módulo "Usando a Segurança de Acesso ao Código com o ASP.NET" (em inglês).

Nota Se você utiliza a segurança de acesso ao código para fornecer o isolamento da aplicação, deve ainda levar em conta a identidade do sistema operacional da aplicação. O modelo de isolamento recomendado é usar a segurança juntamente com o isolamento do processo no Windows Server 2003.

Questões sobre Autenticação de Formulários

Se você utiliza a autenticação de Formulários com a versão 1.0 do .NET Framework, deve usar caminhos e nomes separados de cookies. Caso você não use, é possível que um usuário autenticado faça uma solicitação a outro, sem ser redirecionado à página de logon da aplicação. As regras de autorização da URL dentro da Segunda aplicação podem negar acesso ao usuário, sem dar a ele a chance de fornecer credenciais de logon usando um formulário de logon.

Para evitar esse problema, utilize os atributos exclusivos de nome e caminho da cookie no elemento <forms> para cada aplicação, e use também chaves separadas de máquinas para cada aplicação.

A versão 1.1 do .NET Framework suporta a definição IsolateApps mostrada abaixo.

<machineKey validationKey="AutoGenerate,IsolateApps"
            decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

Isso garante que cada aplicação na máquina utilize uma chave separada para criptografia e validação de cookies de autenticação do Formulário e estado de visualização.

Com a versão 1.0 do .NET Framework, você não pode usar o IsolateApps e deve então gerar, manualmente, os elementos <machineKey>. Para mais informações sobre este assunto, consulte os seguintes artigos do Microsoft Knowledge Base.

• 313116, "PRB: Requisições para Autenticação de Formulários não são Direcionadas para a Página loginUrl" (em inglês).

• 312906, "Como Fazer: Crie Chaves Usando o Visual C# .NET para a Autenticação de Formulários" (em inglês).

Hospedagem de Compartilhamento do UNC

Se você executa uma aplicação com seu conteúdo em um compartilhamento Universal Naming Convention (UNC), as credenciais usadas para acessá-lo são tanto as da aplicação ou as do cliente autenticado. Isso é configurado no IIS por um administrador.

Quando uma aplicação é configurada desta maneira, o ASP.NET personifica o contexto de segurança do token que recebe do IIS. Isso não é configurável com a tag <identity> a menos que sejam fornecidas credenciais explícitas.

Com a versão 1.0 do .NET Framework, use o Mscorcfg.msc para criar um grupo de código baseado na URL e para garantir sua confiança completa.

Quando você utiliza um diretório virtual que aponte para um compartilhamento remoto a fim de hospedar uma aplicação do ASP.NET, você pode receber uma exceção de segurança. Para mais informações, consulte o artigo 320268 do Microsoft Knowledge Base, "PRB: "System.Security.SecurityException: Security error" Mensagem de Erro quando o Diretório Virtual Indica um Compartilhamento Remoto no ASP.NET." (em inglês).

Sumário

Se você hospeda múltiplas aplicações do ASP.NET em um único servidor da Web, precisa então levar em conta a forma como as aplicações são isoladas umas das outras e dos recursos compartilhados do sistema, tais como o sistema de arquivo, o registro e os logs de evento. Sem o isolamento adequado, uma aplicação fajuta ou mal desenvolvida pode afetar, de maneira prejudicial, outras aplicações no servidor.

No Windows Server 2003, utilize múltiplos modelos de processos suportados pelo IIS 6 a fim de fornecer isolamento do sistema operacional para as aplicações. No Windows 2000, o isolamento do processo não é possível, embora muitas aplicações possam ser configuradas para usar contas anônimas separadas de usuários. Isso fornece auditoria separada da aplicação e suporta autorização independente.

Em ambas as plataformas você pode utilizar o modelo de restrição fornecido pela segurança de acesso ao código como um controle adicional para restringir quais aplicações possuem acesso a certos tipos de recursos. O uso da segurança de acesso ao código com aplicações ASP.NET requer a versão 1.1 do .NET Framework.

Para mais informações sobre a proteção das aplicações do ASP.NET, consulte o módulo "Protegendo as Suas Aplicações do ASP.NET" (em inglês).