Hospedando Vários Aplicativos da Web

Atualizado em: 21 de Maio de 2004

Nesta página

	Neste módulo
	Objetivos
	Aplica–se a
	Como usar este módulo
	Introdução
	Arquitetura ASP.NET no Windows 2000
	Arquitetura ASP.NET no Windows Server 2003
	Isolando aplicativos por identidade
	Isolando aplicativos com pools de aplicativos
	Isolando aplicativos com segurança de acesso a código
	Questões de autenticação Forms
	Hospedagem de compartilhamento UNC
	Resumo

Neste módulo

Os sistemas operacionais Windows Server 2000 e 2003 fornecem ambientes de hospedagem muito robustos e escaláveis. Esses ambientes podem ser usados para hospedar de forma segura centenas de sites e aplicativos ASP.NET em um único servidor Web ou Web farm.

No entanto, ao usar aplicativos ASP.NET em cenários de hospedagem compartilhada, você deve considerar como os aplicativos são isolados uns dos outros e de recursos compartilhados do sistema, inclusive o sistema de arquivos, o Registro e os logs de eventos. Sem isolamento adequado, um aplicativo malicioso ou mal–intencionado pode prejudicar outros aplicativos do servidor ou acessar recursos não autorizados. O isolamento do aplicativo é particularmente significativo para ISPs (Provedores de Internet) que hospedam um grande número de aplicativos de diferentes empresas.

Este módulo explica que técnicas você pode usar nos Windows 2000 e 2003 para isolar os aplicativos ASP.NET a fim de garantir a integridade, a confidencialidade e a autenticidade dos dados hospedados nos sites.

Início da página

Objetivos

Use este módulo para:

•	Compreender a arquitetura e os principais componentes do ASP.NET nos Windows 2000 e 2003.
•	Isolar aplicativos da Web usando várias identidades, pools de aplicativos e segurança de acesso a código.
•	Configurar representação de conta anônima.
•	Configurar representação de conta fixa para acessar recursos locais ou remotos ao autenticar usuários utilizando autenticação ou certificados integrados do Windows.
•	Melhorar a segurança de autenticação Forms.
•	Compreender como as credenciais são usadas quando dados armazenados em compartilhamentos UNC são acessados.

Início da página

Aplica–se a

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

•	Microsoft Windows Server 2000 e 2003
•	Microsoft .NET Framework 1.1 e ASP.NET 1.1

Início da página

Como usar este módulo

Este módulo mostra como você pode obter isolamento de aplicativos em ambientes de hospedagem compartilhados. Um dos elementos principais é a segurança de acesso a código. Além deste módulo, use o seguinte:

•	"Segurança do Acesso ao Código na Prática". Esse módulo fornece mais explicações sobre como a segurança de acesso a código funciona e como pode ser usada para restringir conjuntos individuais e, por exemplo, limitar sua capacidade de acessar o sistema de arquivos, o Registro, a rede e outros recursos críticos.
•	"Usando a Segurança do Acesso ao Código com o ASP.NET". Esse módulo explica como a diretiva de segurança de acesso a código funciona para aplicativos ASP.NET e discute as considerações e as implicações da criação de aplicativos com confiança parcial.
•	"Protegendo seu Servidor Web". Esse módulo mostra como proteger o sistema operacional Windows 2000 e o Microsoft .NET Framework. Uma plataforma subjacente segura é um dos pré–requisitos para a proteção de um aplicativo da Web ASP.NET ou de um Web Service.

Início da página

Introdução

Em um cenário de hospedagem compartilhada, é essencial garantir que um aplicativo não prejudique o funcionamento e a segurança de outros aplicativos.

Você pode obter o isolamento de aplicativos de várias maneiras. As opções disponíveis variam de acordo com a versão do .NET Framework e do sistema operacional executado no servidor Web.

•

Se estiver executando a versão 1.1 do .NET Framework, você poderá usar o modelo de restrição de recursos oferecido pela segurança de acesso a código para fornecer um nível de isolamento de aplicativos. Para obter esse isolamento de aplicativos, restrinja o acesso de um aplicativo a diferentes tipos de recursos, como o sistema de arquivos, o Registro, o log de eventos, o Active Directory, os bancos de dados, os recursos de rede etc.

•

O Windows Server 2003 fornece isolamento do processo por meio de pools de aplicativos do IIS 6 (Internet Information Services 6.0) que permitem que vários aplicativos sejam executados em instâncias separadas do processo de trabalho do IIS. O isolamento do processo não é possível no Windows 2000, pois todos os aplicativos da Web são executados em uma única instância do processo de trabalho do ASP.NET, com domínios do aplicativo fornecendo isolamento.

A tabela 20.1 resume as diversas opções de isolamento de aplicativos disponíveis no Windows 2000 e no Windows Server 2003.

Tabela 20.1 Recursos de isolamento de aplicativos para Windows 2000 e Windows Server 2003

Recurso de isolamento	Windows 2000	Windows Server 2003
Isolamento do processo	Não	Sim (Pools de aplic. IIS 6)
Isolamento de domínio do aplicativo	Sim	Sim
Identidades de vários segmentos	Sim	Sim
Restrição de recursos de segurança de acesso a código	Sim (.NET Framework versão 1.1)	Sim (.NET Framework versão 1.1)

Windows Server 2003 executando a versão 1.1 do .NET Framework é a plataforma recomendada para hospedar vários aplicativos ASP.NET, pois oferece suporte ao isolamento do processo e fornece a maior gama de opções para o isolamento de aplicativos.

Início da página

Arquitetura ASP.NET no Windows 2000

No Windows 2000, vários aplicativos da Web são executados em uma única instância do processo de trabalho do ASP.NET (Aspnet_wp.exe). Cada aplicativo reside em seu próprio domínio, que fornece um grau de isolamento para código gerenciado. A arquitetura do Windows 2000/IIS 5 é mostrada na figura 20.1.

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

Os componentes da arquitetura descritos na figura 20.1 são resumidos na tabela 20.2.

Tabela 20.2 Componentes da arquitetura ASP.NET do Windows 2000

Componente	Descrição
Inetinfo.exe	Principal processo do IIS. Um serviço do Windows executado na conta SYSTEM local.
Aspnet_isapi.dll	Os mapeamentos de script do IIS associam tipos de arquivo do ASP.NET a essa extensão ISAPI do ASP.NET executada dentro do Inetinfo.exe. A extensão é responsável pelo encaminhamento de solicitações ao processo de trabalho do ASP.NET por meio de um pipe nomeado assíncrono. Ela também inicia o processo de trabalho e executa monitoramentos de estado. A extensão ISAPI não contém códigos gerenciados e não executa processamentos de solicitações sozinha.
Aspnet_filter.dll	Filtro ISAPI leve usado apenas para oferecer suporte ao estado de sessão sem cookies de aplicativos ASP.NET. É executado em Inetinfo.exe.
Aspnet_wp.exe	Processo de trabalho do ASP.NET. Hospeda vários aplicativos da Web em domínios separados, usados para fornecer isolamento. Geralmente, uma instância por servidor; no entanto, em servidores com vários processadores, um modo de ambiente Web oferece suporte a vários processos idênticos com afinidade por um determinado processador. Não é possível separar aplicativos da Web específicos em processos diferentes. Isso requer o IIS 6 e o Windows Server 2003. O Aspnet_wp.exe é executado na conta ASPNET local, embora uma conta personalizada possa ser usada.
Aspnet_state.exe	Serviço opcional do Windows usado para armazenar estados de sessão de aplicativos ASP.NET. Pode ser executado no servidor Web ou em um computador remoto (necessário para cenários Web farm). É executado na conta ASPNET local, embora uma conta personalizada possa ser usada, configurada por meio do snap–in de serviços.

Início da página

Arquitetura ASP.NET no Windows Server 2003

No Windows Server 2003, a arquitetura muda, pois o IIS 6 permite que vários processos sejam usados para hospedar aplicativos da Web separados. Isso é mostrado na figura 20.2.

Observação: o IIS 6 oferece suporte a um modo de compatibilidade com versões anteriores que, por sua vez, oferece suporte ao modelo de processo de trabalho do ASP.NET IIS 5.

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

Comparada à arquitetura ASP.NET do Windows 2000, a principal diferença da arquitetura do Windows Server 2003 é que instâncias separadas de processo de trabalho do IIS (W3wp.exe) podem ser usadas para hospedar aplicativos da Web. Por padrão, essas instâncias são executadas com a conta NT Authority\NetworkService, que é uma conta local com menos privilégios que atua como a conta de computador na rede. Um aplicativo da Web executado no contexto da conta do Serviço de Rede apresenta as credenciais do computador a servidores remotos para autenticação.

Configurando ACLs para serviço de rede

A configuração de uma ACL (Lista de Controle de Acesso) para a conta do Serviço de Rede varia para computadores locais e remotos. Se desejar conceder acesso à conta do Serviço de Rede no computador local, adicione a conta do Serviço de Rede a uma ACL. Se desejar conceder acesso à conta do Serviço de Rede em um computador remoto, adicione a conta NomeDoDomínio\NomeDoComputador$ a uma ACL.

Observação:Não confunda a conta do Serviço de Rede com o grupo interno Rede, que inclui usuários autenticados na rede.

Os principais componentes da arquitetura descritos na figura 20.2 são resumidos na tabela 20.3.

Tabela 20.3 Componentes da arquitetura ASP.NET do Windows Server 2003

Componente	Descrição
Aspnet_isapi.dll	Coloca em fila solicitações de processamento feitas pelo mecanismo ASP.NET do código gerenciado e executa monitoramentos de estado.
Aspnet_filter.dll	Filtro ISAPI leve usado apenas para oferecer suporte ao estado de sessão sem cookies de aplicativos ASP.NET. Executado no W3wp.exe.
W3wp.exe	Processo de trabalho do IIS que contém o mecanismo de processamento do ASP.NET do código gerenciado. É possível dividir arbitrariamente o espaço URL entre diferentes instâncias do W3wp.exe usando os pools de aplicativos do IIS 6. Também há suporte para um modo de ambiente Web. As solicitações são roteadas para a instância de processo do W3wp.exe diretamente do Http.sys que é executado no modo kernel. Por padrão, o processo é executado na conta Serviço de Rede, mas pode ser configurado.
Aspnet_state.exe	Serviço opcional do Windows usado para armazenar estados de sessão de aplicativos ASP.NET. Pode ser executado no servidor Web ou em um computador remoto (necessário para cenários Web farm). É executado na conta Serviço de Rede, mas pode ser configurado com o snap–in de serviços.

Início da página

Isolando aplicativos por identidade

Você pode isolar aplicativos da Web ASP.NET da identidade do sistema operacional controlando a identidade de conta usada para executar cada aplicativo. Se cada aplicativo usar uma identidade de conta fixa separada, você poderá autorizar e auditar isoladamente cada aplicativo.

Observação: Se você hospedar um aplicativo da Web ASP.NET criado com o .NET Framework versão 1.0, a conta do processo precisará de permissões apropriadas na raiz da unidade de sistema de arquivos atual. Para obter mais informações, consulte o artigo 317955 do Microsoft Knowledge Base, "FIX: 'Failed to Start Monitoring Directory Changes' Error Message When You Browse to an ASP.NET Page".(em inglês)

Há duas maneiras de usar identidades fixas separadas para cada aplicativo em um servidor Web compartilhado:

•	Representação de conta anônima
•	Representação de identidade fixa

Representação de conta anônima

Com a representação de conta anônima, o aplicativo representa a conta anônima especificada pelo IIS e configurada para o diretório virtual do aplicativo. Você poderá usar essa abordagem se o aplicativo autenticar usuários independentemente do IIS; por exemplo, usando a autenticação Forms ou Microsoft Passport. Nesses cenários, você poderá isolar o aplicativo usando uma conta anônima fixa. Depois que o chamador for autenticado e que as funções forem verificadas, o modelo de servidor confiável poderá ser usado para acesso a recursos downstream, onde a conta anônima configurada fornecerá a identidade confiável.

Para oferecer suporte a essa abordagem, os diretórios virtuais do aplicativo no IIS devem oferecer suporte a acesso anônimo e uma conta anônima separada deve ser configurada para cada aplicativo. Em seguida, o aplicativo deve ser configurado para representação. Essa abordagem é mostrada na figura 20.3. O acesso a recursos locais e remotos considera o contexto de segurança da conta anônima representada.

Figura 20.3
Várias contas anônimas usadas para cada aplicativo

•

Para usar várias contas anônimas para acessar recursos

Este procedimento descreve como usar várias contas anônimas, uma por aplicativo da Web, para que o acesso a recursos ofereça suporte à auditoria e à autorização de aplicativos individuais.

Crie novas contas de usuário anônimas, uma por aplicativo.
Para obter mais informações sobre como criar uma conta de usuário anônima, consulte a seção "Contas" no módulo 16, "Protegendo seu Servidor Web".

Se precisar acessar recursos remotos usando a conta anônima, use uma conta de domínio com menos privilégios, ou use uma conta local e crie uma conta local duplicada no servidor remoto com a mesma senha e o mesmo nome de usuário.

Use marcas <location> em Machine.config para configurar cada aplicativo da Web para representação.

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

A configuração allowOverride="false" impede que um aplicativo individual substitua essa configuração em um arquivo Web.config. Para obter mais informações sobre o elemento <location>, consulte "Machine.config and Web.config Explained" "Protegendo seus Aplicativos ASP.NET e Web Services".

Use o Gerenciador de Serviços de Internet para configurar o diretório virtual de cada aplicativo para usar uma conta de usuário anônima separada.

1.	Inicie o Gerenciador de Serviços de Internet a partir do grupo de programas Ferramentas Administrativas.
2.	Selecione o diretório do aplicativo, clique com o botão direito do mouse e, em seguida, clique em Propriedades.
3.	Clique na guia Segurança e no botão Editar.
4.	Verifique se a opção Acesso anônimo está selecionada e clique em Editar.
5.	Insira o nome de usuário da conta anônima criada ou clique em Procurar para selecionar o nome de usuário em uma lista.
6.	Se desejar usar a conta para acessar um recurso remoto, desmarque a caixa de seleção Permitir que o IIS Controle a Senha da conta anônima. Se você selecionar Permitir que o IIS Controle a Senha, a sessão de logon criada com a conta anônima especificada terá credenciais de rede nulas e não poderá ser usada para acessar recursos de rede em que a autenticação seja necessária. Se você desmarcar essa caixa de seleção, a sessão de logon será interativa e terá credenciais de rede. No entanto, se a conta for local no computador, nenhum outro computador da rede poderá autenticá–la. Nesse cenário, crie uma conta duplicada no servidor remoto de destino. Observação: O tipo de sessão de logon criado é controlado pela configuração Metabase do IIS LogonMethod. O padrão é uma sessão de logon interativa, que requer que a conta tenha o privilégio de usuário "Permitir Logon Local". A opção Permitir que o IIS Controle a Senha não está disponível no IIS 6. O IIS 6 define o padrão LogonMethod como Network Cleartext, que requer que a conta tenha o privilégio de usuário "Acesso a este computador pela rede". Isso permite que a conta seja autenticada por um servidor de rede.

Configure permissões NTFS para cada conta para garantir que cada uma delas tenha acesso apenas às pastas e aos arquivos apropriados do sistema de arquivos, e não possa acessar recursos críticos, como ferramentas do sistema operacional.
Para obter mais informações sobre como configurar permissões NTFS para a conta anônima, consulte, "Protegendo seu Servidor Web".

Observação: Se você executar o assistente do IISLockdown, ele criará um grupo Web Anonymous Users. Os membros desse grupo não têm permissão para acessar ferramentas e diretórios do sistema.

Representação de identidade fixa

Quando precisar que o IIS autentique usuários no aplicativo, utilizando, por exemplo, a Autenticação integrada do Windows ou a autenticação de certificação, você poderá usar uma identidade de representação fixa para executar o aplicativo ASP.NET. Esse cenário é mostrado na figura 20.4.

Figura 20.4
Aplicativos representam uma conta fixa e usam essa conta para acessar recursos

Você pode configurar aplicativos ASP.NET individuais para representar uma conta fixa. A vantagem dessa 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 várias contas de representação fixas para acessar recursos

Este procedimento descreve como usar várias contas de representação fixas, uma por aplicativo da Web, para que o acesso a recursos ofereça suporte à auditoria e à autorização de aplicativos individuais.

1.	Crie novas contas de usuário anônimas, uma por aplicativo. Para obter mais informações sobre como criar uma conta de usuário anônima, consulte a seção "Contas" no módulo 16, "Protegendo seu Servidor Web". Se precisar acessar recursos remotos usando a conta anônima, use uma conta de domínio com menos privilégios, ou use uma conta local e crie uma conta local duplicada no servidor remoto com a mesma senha e o mesmo nome de usuário.
2.	Armazene as credenciais criptografadas da conta no Registro. Execute Aspnet_setreg.exe para armazenar as credenciais criptografadas da nova conta no Registro. Para obter mais informações, consulte o artigo 329290 do Microsoft Knowledge Base, "How To: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings".(em inglês)
3.	Configure aplicativos da Web para representação .Faça isso em Machine.config ou em Web.config. Para configurar vários aplicativos com identidades diferentes, use marcas <location> em Machine.config. O resultado de Aspnet_setreg.exe executado na etapa anterior mostra o formato necessário dos valores de atributo userName e password para o elemento<identity>. Alguns exemplos são mostrados a seguir. <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 representações no nível do aplicativo, use um elemento <identity> no arquivo Web.config do aplicativo, como mostrado a seguir. <identity impersonate="true" userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>
4.	Configure permissões NTFS para cada conta para garantir que cada uma delas tenha acesso apenas às pastas e aos arquivos apropriados do sistema de arquivos, e não possa acessar recursos críticos, como ferramentas do sistema operacional. Para obter mais informações sobre como configurar permissões NTFS para a conta anônima, consulte o módulo 16, "Protegendo seu Servidor Web".

Observação: no Windows 2000 e no .NET Framework versão 1.0, se representar uma identidade fixa usando a configuração acima, você precisará conceder o privilégio "Atuar como parte do sistema operacional" à conta do processo ASP.NET usada para executar os aplicativos da Web. Isso é contrário ao princípio de menos privilégios. É recomendável fazer uma atualização para o .NET Framework versão 1.1. Nessa versão, isso não é mais um requisito.

Início da página

Isolando aplicativos com pools de aplicativos

Se os aplicativos forem executados no Windows Server 2003, você poderá usar pools de aplicativos e configurar cada aplicativo para ser executado em seu próprio processo de trabalho que fornece isolamento no nível do processo. Por padrão, todos os aplicativos são executados em um pool de aplicativos. Com pools de aplicativos, você pode configurar cada processo a ser executado usando uma identidade separada e, como resultado, você não precisará usar representação.

•

Para fornecer isolamento no nível do processo

1.	Crie um conjunto de novas contas do Windows, uma por aplicativo, para executar cada instância do processo de trabalho.
2.	Configure permissões NTFS para cada conta a fim de garantir que cada conta só tenha acesso às pastas e aos arquivos do sistema de arquivos apropriado, e não possa acessar recursos críticos, como ferramentas do sistema operacional. Para obter mais informações sobre como configurar permissões NTFS para a conta anônima, consulte, "Protegendo seu Servidor Web".
3.	Desative a representação do aplicativo da Web. Você pode fazer isso em Machine.config ou Web.config. Para desativar a representação de vários aplicativos no Machine.config, coloque elementos <identity> dentro de elementos <location>, como mostrado a seguir. Use a configuração a seguir. Esta configuração não usa representação. <location path="Web Site Name/appvDir1" allowOverride="false" > <system.web> <identity impersonate="false" </system.web> </location> Observação: por padrão, aplicativos ASP.NET não usam representação.
4.	Crie novos pools de aplicativos e configure–os para serem executados nas novas contas. Use o IIS 6 para criar novos pools de aplicativos com configurações padrão e use as contas criadas na etapa 1 para configurar a identidade de cada pool, para que cada um deles seja executado com uma identidade separada.
5.	Configure cada aplicativo para ser executado em seu próprio pool. Na guia Diretório de cada aplicativo do IIS, escolha o pool no qual o aplicativo será executado.

Início da página

Isolando aplicativos com segurança de acesso a código

Com a versão 1.1 do .NET Framework, você pode configurar aplicativos para serem executados em níveis de confiança parcial, usando o elemento <trust>. A configuração a seguir mostra como configurar o nível de confiança de um aplicativo no Machine.config. Neste exemplo, é usado o nível de confiança médio.

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

Se você configurar um aplicativo para ser executado com um nível de confiança que não seja total, o aplicativo terá permissões de segurança de acesso a código restritas para acessar tipos específicos de recursos. Dessa forma, você pode restringir aplicativos para impedir que eles interajam uns com os outros e que obtenham acesso a recursos no nível do sistema, como áreas restritas do sistema de arquivos, o Registro, o log de eventos etc.

Para obter mais informações sobre os níveis de confiança do ASP.NET e como eles podem ser usados para fornecer isolamento de aplicativos, bem como sobre considerações específicas relacionadas a design e desenvolvimento do aplicativo, consulte o módulo 9, "Usando a Segurança do Acesso ao Código com o ASP.NET".

Observação: mesmo se usar segurança de acesso a código para fornecer isolamento de aplicativos, você deverá considerar a identidade do sistema operacional do aplicativo. O modelo de isolamento recomendado é usar a segurança de acesso a código juntamente com o isolamento no nível do processo no Windows Server 2003.

Início da página

Questões de autenticação Forms

Se usar autenticação Forms com a versão 1.0 do .NET Framework, você deverá usar nomes e caminhos de cookie separados. Se você não fizer isso, um usuário autenticado em um aplicativo poderá fazer uma solicitação para outro aplicativo sem ser redirecionado para a página de logon desse aplicativo. As regras de autorização de URL do segundo aplicativo poderão negar o acesso do usuário, sem permitir o fornecimento de credenciais de logon pelo formulário de logon.

Para evitar essa questão, use atributos exclusivos de caminho e nome de cookie no elemento <forms> de cada aplicativo. Além disso, use chaves de computadores separados separadas para cada aplicativo.

A versão 1.1 do .NET Framework oferece suporte à configuração IsolateApps mostrada a seguir.

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

Isso garante que cada aplicativo do computador use uma chave separada para criptografia e validação de cookies de autenticação Forms e View State.

Com a versão 1.0 do .NET Framework, você não poderá usar IsolateApps e deverá gerar manualmente elementos <machineKey>. Para obter mais informações sobre essa questão, consulte os seguintes artigos do Microsoft Knowledge Base.

•	313116, "PRB: Forms Authentication Requests Are Not Directed to loginUrl Page"(em inglês)
•	312906, "How To: Create Keys by Using Visual C# .NET for Use in Forms Authentication"(em inglês)

Início da página

Hospedagem de compartilhamento UNC

Se você executar um aplicativo com conteúdo em um compartilhamento UNC (Convenção Universal de Nomenclatura), as credenciais usadas para acessar o compartilhamento serão as credenciais do aplicativo ou do cliente autenticado. Isso é configurado no IIS por um administrador.

Quando um aplicativo é configurado dessa maneira, o ASP.NET representa o contexto de segurança do símbolo que ele recebe do IIS. Isso só poderá ser configurado com a marca <identity> se credenciais explícitas forem fornecidas.

Com a versão 1.0 do .NET Framework, use o Mscorcfg.msc para criar um grupo de códigos com base no URL e para conceder confiança total a esse grupo.

Ao usar um diretório virtual que aponte para um compartilhamento remoto para hospedar um aplicativo ASP.NET, você poderá receber uma exceção de segurança. Para obter mais informações, consulte o artigo 320268 do Microsoft Knowledge Base, "PRB: "System.Security.SecurityException: Security error" Error Message when the Virtual Directory Points to a Remote Share in ASP.NET".(em inglês)

Início da página

Resumo

Se hospedar vários aplicativos ASP.NET em um único servidor Web, você precisará considerar o modo como os aplicativos são isolados uns dos outros e de recursos compartilhados do sistema, como o sistema de arquivos, o Registro e os logs de evento. Sem isolamento adequado, um aplicativo malicioso ou mal–intencionado pode prejudicar outros aplicativos do servidor.

No Windows Server 2003, use o modelo de processo de trabalho múltiplo para o qual o IIS 6 oferece suporte a fim de fornecer isolamento do processo do sistema operacional para aplicativos. No Windows 2000, não é possível realizar o isolamento do processo, embora vários aplicativos possam ser configurados para usar contas de usuário anônimas separadas. Isso fornece auditoria separada de aplicativos e oferece suporte à autorização independente de aplicativos.

Em ambas as plataformas você pode usar o modelo de restrição de recursos fornecido pela segurança de acesso a código como controle adicional para determinar quais aplicativos têm acesso a quais tipos de recurso. O uso da segurança de acesso a código com aplicativos ASP.NET requer a versão 1.1 do .NET Framework.

Para obter mais informações sobre como proteger aplicativos ASP.NET, consulte, "Protegendo seus Aplicativos ASP.NET e Web Services".

Início da página