Introdução

Este documento discute o tópico geral de isolamento de aplicativos, na medida em que isso está relacionado com aplicativos Web executados em servidores Windows Server 2003 nos quais o IIS 6.é executado no modo de isolamento do processo de trabalho. O isolamento tem a ver com o grau de separação entre dois aplicativos Web executados em um servidor. Neste documento, o significado do termo “aplicativo Web” é bastante amplo; ele abrange os processos, os arquivos, e mesmo os usuários, que usam o aplicativo. Os aplicativos são isolados entre si de forma que um determinado aplicativo seja impedido de acessar os recursos empregados por outro aplicativo.

Benefícios do isolamento

As empresas estão cada vez mais interessadas no isolamento por sua oportunidade de reduzir custos por meio da consolidação do servidor. Tendo em vista que as capacidades de hardware melhoram sensivelmente com o tempo, menos servidores são necessários para fornecer os mesmos aplicativos. Embora isso diminua os custos de implementação e manutenção, pode criar dificuldades logísticas quando existe um interesse especial em manter limites claros entre aplicativos que são executados permanentemente em um único servidor.

Em algumas situações, cada LOB (Line of Business, linha de negócios) de uma organização é, essencialmente, um cliente separado do grupo de TI responsável pela infra-estrutura do aplicativo. Por exemplo, uma organização adquirida provavelmente concorrerá com outras partes da organização adquirente. Conseqüentemente, a necessidade comercial de criar barreiras eficazes entre os aplicativos que atendem a cada LOB e de proteger dados confidenciais é real.

Outro exemplo em que existe uma nítida necessidade de alto isolamento é o de um ISP que hospeda sites para vários clientes. Um determinado cliente não deveria ser capaz de visualizar os arquivos ou bancos de dados que estão sendo usados por outros sites no servidor.

Em outros casos, uma empresa pode oferecer aplicativos Web e outros recursos técnicos a parceiros comerciais concorrentes entre si. Portanto, o nível de isolamento que as empresas precisam oferecer aos aplicativos empregados por clientes, parceiros ou unidades de negócios particulares que usam o mesmo servidor é alto. Por exemplo, é fundamental poder configurar o software de um parceiro que acessa um banco de dados de modo que esse aplicativo não possa acessar o banco de dados de outro parceiro.

Outro benefício do isolamento de aplicativos é a possibilidade de desenvolver a infra-estrutura dos aplicativos, do servidor e da rede para melhorar a capacidade de distribuição de conteúdos e aplicativos. Por exemplo, talvez você queira inserir um conteúdo em um armazenamento de arquivo remoto para que possa ser compartilhado por mais de um servidor. Alternativamente, talvez você queira hospedar diferentes conteúdos do aplicativo em diferentes servidores de arquivos, para isolar ainda mais cada aplicativo LOB, mas compartilhar o mesmo servidor Web como um front end.

As seções a seguir discutem várias abordagens para obtenção de um alto nível de isolamento.

Isolamento físico

É possível alcançar o nível mais alto de isolamento quando os aplicativos são hospedados em computadores completamente diferentes. Obviamente, esse recurso oferece o nível máximo de isolamento para os aplicativos, mas é também o mais caro, pois exige licenças adicionais de hardware e servidor para fornecer suporte a cada aplicativo. Contudo, em aplicativos LOB de missão crítica, em que as informações são valiosas, provavelmente essa é a melhor opção.

Isolamento virtual

Você pode também criar aplicativos isolados por meio de servidores virtuais. Usando softwares como o Connectix VPC ou VMware, que lhe permitem criar vários servidores virtuais que podem ser executados como tarefas em um único sistema operacional, você pode criar vários servidores particionados de maneira funcional. Portanto, os aplicativos podem ser isolados consideravelmente, além de poderem ser executados no mesmo hardware. Pelo fato de o desempenho dos sistemas virtuais não ser tão bom quanto o de computadores individuais, o isolamento virtual oferece um alto nível de isolamento, mas compromete o desempenho. Outro custo incremental é o de licença de software para os sistemas virtuais. Além das licenças de software necessárias para o servidor que hospeda os sistemas virtuais, você tem de adquirir também licenças de software distintas para o sistema operacional e os aplicativos em cada sistema virtual, como se cada sistema virtual fosse um sistema individual.

Isolamento configurado

Utilizar o isolamento configurado significa tirar vantagem de limites de isolamento naturais, como processos, identidades de segurança, listas de controle de acesso (ACLs) e espaços de nome que ocorrem pelo fato de os aplicativos serem executados em um servidor Web. O nível de isolamento alcançado por meio do isolamento configurado não é tão grande quanto o físico e virtual. Entretanto, na maioria das vezes o isolamento configurado é uma opção razoável para equilibrar o uso de recursos, facilitar administração e aproveitar ainda mais os investimentos em hardware, software e licenciamento. Mais do que nunca, os novos recursos do Windows Server 2003 e IIS 6.0 tornam essa opção uma solução mais confiável, segura e escalonável.

Isolamento por meio de recursos do sistema operacional

No Microsoft Windows Server 2003, há inúmeros recursos que permitem criar ambientes isolados para os aplicativos. A Delegação restrita e a Transição de protocolo permitem que você “transponha” um contexto de segurança do usuário para servidores de arquivos, independentemente do protocolo usado para autenticar o usuário no IIS. Entre as melhorias na qualidade de serviço (QoS) está um agendador de pacotes integrado com o IIS, que permite que um administrador limite a quantidade de largura de banda disponível para um aplicativo. O Windows System Resource Manager (WSRM) pode ser usado com o Windows Server 2003, Enterprise Edition e o Windows Server 2003, Datacenter Edition. Com o WSRM, o administrador pode controlar exatamente quanto um pool de aplicativos pode consumir da CPU quando a carga da CPU é insuficiente.

Isolamento por meio da configuração do IIS

No IIS 6.0, o isolamento de aplicativos foi desenvolvido como um componente primário da arquitetura. Todo site tem capacidade de hospedar um ou vários aplicativos, aos quais se pode atribuir a função de executar um pool de processos especificado, chamado pool de aplicativos. Um pool de aplicativos é servido por um ou mais processos de trabalho, pode ser configurado independentemente para configurações relacionadas com eficiência e pode ser configurado para executar no contexto de uma conta de usuário designado.

Há vários objetivos na configuração de isolamento de aplicativos:

• Confiabilidade.Se um aplicativo falhar, não deve afetar outros aplicativos. Além disso, deve ser possível especificar ações exclusivas de recuperação para diferentes aplicativos.
• Segurança.Se um aplicativo estiver executando um código mal-intencionado de um invasor (ou possivelmente do próprio autor do aplicativo), outros aplicativos são protegidos dos efeitos desse código mal-intencionado e barreiras eficazes são desenvolvidas para impedir que o invasor entre no “espaço” de outro aplicativo.
• Desempenho. Um aplicativo que utiliza exageradamente os recursos não deveria afetar a eficácia de outros aplicativos. Entretanto, os aplicativos que exigem recursos adicionais deveriam poder alocar esses recursos mediante solicitação.

Combinando as capacidades do IIS 6.0 com as do Windows Server 2003, você pode implementar eficazmente o isolamento e alcançar as metas que acabamos de especificar. Além disso, melhorias no FTP e nas Extensões de Servidor do Microsoft FrontPage® ajudam a aumentar o nível de isolamento e segurança desses aplicativos.

O restante deste documento abordará a capacidade do Microsoft Windows Server 2003 e do IIS 6.0 de criar aplicativos com um alto nível de isolamento executados em um único servidor. Não há nenhuma técnica ou tarefa administrativa exclusiva que alcance essa meta; porém, por meio de técnicas associadas, você pode implementar eficazmente o isolamento de aplicativos.

Usando o isolamento para melhorar a confiabilidade

Uma das principais metas no desenvolvimento da arquitetura do IIS 6.0 foi melhorar o isolamento entre aplicativos e minimizar as compensações de desempenho. Isso se tornou uma realidade ao remodelarmos a arquitetura do IIS de forma que seu desempenho, confiabilidade e segurança aumentassem. Os princípios básicos dessa nova arquitetura, no que diz respeito a essa maior confiabilidade, englobam os seguintes elementos:

• A criação de um manipulador de solicitações, o HTTP.sys, executado no núcleo do sistema operacional. A função do HTTP.sys é escutar solicitações HTTP e de enfileiramento a uma fila de solicitações para que o pool de aplicativos as recupere. O HTTP.sys não carrega nem executa nenhum código de aplicativo no modo de usuário (como as páginas ASP).
• A execução de aplicativos Web em processos configuráveis, variados e isolados, denominados processos de trabalho, que são executados com o nome de W3wp.exe. Isso é quase a mesma coisa que “alto” isolamento no IIS 5.0 ou execução “externa ao processo”, com a exceção de que o desempenho é bem melhor porque o processo troca dados diretamente com o HTTP.sys, em vez de empacotar dados usando o principal processo do servidor Web, o Inetinfo.exe, como intermediário.
• A inclusão de um novo processo administrativo, o componente Administração e Monitoração de Serviços WWW (WWW Service Administration and Monitoring), cuja função é dupla:
  • Criar o link entre o manipulador de solicitações HTTP e os aplicativos Web.
  • Monitorar e manter a eficiência dos processos de trabalho.

Melhor isolamento com pools de aplicativos

Tecnicamente, um pool de aplicativos é um objeto de configuração definido por um limite lógico de processo usado pelo mapeador de espaços de nome HTTP.sys para encaminhar solicitações ao processo de trabalho correto. Na prática, passa a ser a tarefa extremamente simples de usar o Gerenciador do IIS para criar um pool de aplicativos, como o “Projeto32-AltamenteRestrito”, e em seguida instruir os programas contidos em sites e diretórios a executar esse ou outros pools de aplicativos, de acordo com sua necessidade (veja a Figura 1).

Figura 1   Atribuindo programas a pools de aplicativos no IIS 6.0

Na verdade, os pools de aplicativos permitem que você agrupe ou isole aplicativos de acordo com suas necessidades técnicas, administrativas e comerciais.

Usando pools de aplicativos para isolar aplicativos de clientes ou unidades de negócios

Os pools de aplicativos criam limites de processo entre aplicativos de diferentes sites ou diretórios no IIS. Isso é ideal para provedores, em que os aplicativos do cliente precisam ser isolados dos outros, ou para a situação usada anteriormente, em que os aplicativos LOB precisam ser isolados entre si. Consulte a seção Segurança, neste documento, para obter detalhes sobre como usar ACLs para reforçar o isolamento de aplicativos em nível de arquivo.

Usando pools de aplicativos para isolar aplicativos não confiáveis

O componente Administração e Monitoração de Serviços do IIS conta com recursos de reciclagem e eficiência que podem reiniciar automaticamente um pool de aplicativos. Comprovadamente, esses recursos melhoram a confiabilidade de maneira significativa. Por exemplo, imagine um importante aplicativo que você não pode, em hipótese alguma, manter off-line, embora ocasionalmente ele pare de responder. Ao colocar esse aplicativo em seu pool de aplicativos particular, você isola esses efeitos sobre outros aplicativos. Isso aumenta a confiabilidade geral de outros aplicativos executados no servidor. Além disso, pelo fato de os pools de aplicativos serem monitorados individualmente e poderem ser configurados automaticamente para que reiniciem quando pararem de responder, a oferta de aplicativos não confiáveis é cada vez maior. Solucionar problemas em um aplicativo desse tipo é também mais fácil porque ele pode ser configurado para ser executado de acordo com seu próprio processo.

Reciclagem

Os critérios de reciclagem podem ser facilmente administrados por meio da caixa de diálogo Propriedades de DefaultAppPool, como mostrado na Figura 2 a seguir. A reciclagem pode ser acionada de acordo com vários parâmetros, como tempo de atividade do aplicativo e número de solicitações, em intervalos programados, com base no consumo de memória, ou de acordo com sua vontade.

Figura 2   Reciclando parâmetros que podem ser usados com o IIS 6.0

A reciclagem pode aumentar o isolamento e a confiabilidade do aplicativo da seguinte maneira:

• Atualizando aplicativos com problemas comprovados de degradação, antes de pararem de responder. Na maioria dos casos desse tipo, por sua experiência com o aplicativo, o administrador do IIS sabe que, antes de precisar ser reiniciado, normalmente o aplicativo executará durante algum tempo.
• Reciclando os aplicativos que provavelmente afetam o desempenho de outros aplicativos que estão sendo executados no servidor. Por exemplo, se houver vazamento e consumo exagerado de memória em um aplicativo, você pode definir um limite para o uso de memória que ativará um evento de reciclagem para o pool de aplicativos.

Impactos da reciclagem de aplicativos

Quando um aplicativo é reciclado, qualquer informação armazenada no processo de trabalho, como estado da sessão, é perdida. Para otimizar o desempenho e a confiabilidade de seus aplicativos com o IIS 6.0, provavelmente você desejará desenvolvê-los de forma que sejam reciclados sem perder dados sobre transações em andamento. Por exemplo, você pode preservar os detalhes do estado da sessão externamente ao processo usando o serviço ASPState no Microsoft ASP.NET ou armazenar os dados no Microsoft SQL Server™.

O tempo de reinicialização dos aplicativos desenvolvidos para reciclagem é otimizado para que seja o menor possível. Os aplicativos que exigem um longo procedimento de reinicialização não terão um bom desempenho se as reciclagens forem freqüentes. Você pode contornar esse problema programando o uso de reciclagem para curtos períodos.

Resumindo, é possível que seus aplicativos possam ser executados lado a lado com outras instâncias do mesmo aplicativo. Na configuração da reciclagem, você pode escolher entre a reciclagem de sobreposição e não-sobreposição. A reciclagem de sobreposição é a configuração padrão: o componente Administração e Monitoração de Serviços WWW cria um novo processo de trabalho para processar qualquer nova solicitação para o aplicativo antes que o processo de trabalho existente seja encerrado. O processo de trabalho anterior é mantido em atividade até que conclua o processamento das solicitações existentes ou até que ocorra um evento de encerramento por tempo-limite — o que ocorrer primeiro. Durante esse período, ambas as instâncias do aplicativo precisarão compartilhar recursos. Se a reciclagem configurada for a de não-sobreposição, o componente Administração e Monitoração de Serviços WWW encerrará o processo de trabalho antes de iniciar um novo. Para obter informações sobre com configurar a reciclagem de sobreposição e não-sobreposição, consulte DisallowOverlappingRotation na Ajuda do IIS 6.0 (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/
proddocs/standard/ref_mb_disallowoverlappingrotation.asp, site em inglês).

Integridade

O componente Administração e Monitoração de Serviços WWW também mantém a integridade dos aplicativos testando periodicamente a capacidade de resposta de um pool de aplicativos. Para não ser confundido com o comando ping de ICMP (Internet Control Message Protocol, protocolo de mensagem de controle da Internet), esse recurso consulta internamente o pool de aplicativos em um intervalo configurável (a cada 30 segundos, por padrão) e aguarda uma resposta.

Se não houver nenhuma resposta, o componente Administração e Monitoração de Serviços WWW encerra o processo de trabalho, registra um evento e inicia um novo processo de trabalho. O IIS pode ainda ser configurando para não destruir o processo de trabalho que falhou. Além de manter o processo de trabalho que falhou, você pode determinar que um programa inicie quando esse evento ocorrer para, desse modo, instanciar automaticamente a solução de problemas ou ferramentas de relatório.

Para obter mais informações sobre como isolar processos de trabalho prejudiciais, consulte
Application Pool Health (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/
proddocs/standard/ca_orphwrkrprocess.asp) e
OrphanWorkerProcess (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/
proddocs/standard/ref_mb_orphanworkerprocess.asp) na Ajuda do IIS 6.0 (sites em inglês).

Rápida proteção contra falhas

A rápida proteção contra falhas pode proteger o servidor contra uma série de falhas rápidas de processo de trabalho no mesmo pool de aplicativos desativando esse pool. Quando um pool de aplicativos é desativado, o IIS remove-o do serviço e coloca-o em um modo em que o driver de modo de núcleo (kernel) retorna imediatamente a mensagem de erro 503, de serviço indisponível, a qualquer solicitação para esse pool de aplicativos.

A quantidade de falhas e o intervalo no qual elas devem ocorrer são configuráveis por pool de aplicativos. Quando a proteção rápida contra falhas é ativada, as configurações de Limite do tempo de inicialização e do Limite do tempo de desligamento são usadas como medidas de integridade do pool de aplicativos (veja a Figura 3).

Figura 3   Opções de integridade oferecidas no IIS 6.0

Quando um processo de trabalho não inicia ou não encerra no prazo estipulado, isso é considerado uma falha, que é adicionada ao número de falhas exigido para colocar o pool de aplicativos off-line. Por padrão, a proteção rápida contra falhas está configurada para desativar um pool de aplicativos, se ocorrerem cinco falhas no aplicativo, no prazo de cinco minutos.

Uso funcional dos pools de aplicativos

Em alguns casos, é provável que você descubra a utilidade de usar um pool de aplicativos para separar aplicativos cujos requisitos técnicos são diferentes. Por exemplo, talvez você acabe descobrindo a utilidade de configurar todos os aplicativos que exigem um componente COM particular em um único pool de aplicativos, se for comprovado que o componente COM está com problemas. Além disso, à medida que seus aplicativos sofrerem atualizações e melhorias, é útil criar pools de aplicativos separados para as novas versões.

Domínios dos aplicativos .NET Framework

No Windows Server 2003, o ASP.NET usa o modelo de processamento de solicitações do aplicativo no isolamento de processos de trabalho e, além disso, mapeia um ou mais domínios dos aplicativos ASP.NET para cada processo de trabalho. Os domínios de aplicativo dentro de um único processo de trabalho podem ser reciclados independentemente e ter componentes, variáveis de sessão e outros recursos privados. Desse modo, é possível contar com um nível adicional e um melhor grau de isolamento.

.NET Framework e montagens lado a lado

Normalmente, quando um componente ou aplicativo é atualizado em um computador, a versão antiga é removida e substituída pela versão mais nova. Quando a nova versão não é compatível com a anterior, em geral outros aplicativos que usam esse componente ou aplicativo param de funcionar. Com o .NET Framework, é possível usar a execução lado a lado, que permite que várias versões de uma montagem ou de um aplicativo sejam instaladas ao mesmo tempo, no mesmo computador. Visto que várias versões podem ser instaladas simultaneamente, os aplicativos gerenciados podem selecionar a versão a ser usada, sem afetar outros aplicativos que usam uma versão diferente.

Por exemplo, os aplicativos podem se beneficiar das montagens lado a lado para que outros aplicativos sejam instalados no mesmo computador que exige diferentes versões de DLL, como MDAC, MFS, MSVCRT ou MSXML. Para obter mais informações sobre esse tópico, consulte o apêndice, no fim deste documento.

Usando o isolamento para proteger os aplicativos

Uma das principais ferramentas para configurar o isolamento é utilizar ACLs, autenticação e identidades de processo para criar limites de segurança eficazes entre os aplicativos. Embora o isolamento configurado não se equipare ao grau de isolamento proporcionado por servidores independentes, você pode usar ACLs com eficácia para impedir que um aplicativo acesse os arquivos de outro inadvertidamente ou propositadamente. Por exemplo, um administrador de site pode criar um script para navegar pelo diretório ou alterar arquivos de outro aplicativo usando o objeto do sistema de arquivos. O administrador poderia ainda desenvolver um aplicativo ASP que lê dados de arquivos de outro site, como um banco de dados de cliente. O uso adequado de ACLs e outros limites de autorização no Windows Server 2003 pode evitar essa situação.

Configurando a identidade do pool de aplicativos

Uma das regras mais importantes a ser lembrada ao proteger um servidor é que todos os processos devem ser executados como uma conta de usuário ou uma conta interna. Na maioria dos casos, esse requisito é óbvio, porque os recursos do sistema de arquivos exigidos ou solicitados por um aplicativo normalmente são abertos no contexto em que o usuário faz a solicitação. Contudo, um desenvolvedor de aplicativos pode optar por criar um aplicativo de tal forma que os recursos do sistema de arquivos sejam abertos no contexto da conta usada para abrir o processo pai que hospeda um aplicativo, em vez de o usuário.

Examinemos o que ocorre quando um usuário anônimo abre um aplicativo. O usuário faz uma solicitação ao aplicativo e é automaticamente atribuído à conta anônima (em geral, a conta IUSR_<Nome_do_computador>). O arquivo solicitado é aberto e executado com as credenciais do usuário anônimo, se as permissões apropriadas estiverem presentes no Gerenciador do IIS e nas ACLs, no arquivo solicitado. Entretanto, se em seguida o aplicativo chamar a função Win32API RevertToSelf, os acessos subseqüentes ao arquivo, feitos do aplicativo, ocorrerão como a conta de usuário Serviços de rede. A conta de usuário Serviços de rede é a conta interna atribuída como identidade dos pools de aplicativos.

Contas internas

Mesmo se a conta de usuário Serviço de rede tiver direitos restritos no servidor, os pools de aplicativos que compartilham essa identidade têm direitos recíprocos aos recursos um do outro quando as ACLs são configuradas para permitir acesso a essa conta interna. Você provavelmente desejará atribuir uma identidade particular a cada pool de aplicativos para isolar de forma eficaz os aplicativos, como mostrado na Figura 4.

Figura 4   A identidade padrão de um pool de aplicativos é a conta de usuário Serviços de rede

Pelo fato de um aplicativo poder ser executado como a identidade do pool de aplicativos, ao selecionar uma identidade de pool de aplicativos, você deve escolher uma que tenha a quantidade mínima de privilégios exigidos por seu aplicativo. No caso em que a identidade do processo de trabalho é configurada como uma conta com privilégios superiores, como Sistema Local, é provável que o aplicativo receba permissões além do escopo do usuário autenticado. Em vez disso, experimente configurar a identidade do processo de trabalho como uma conta com privilégios inferiores para impedir que um aplicativo eleve seus privilégios dessa maneira.

Atribuindo uma conta

Ao configurar uma conta de usuário individual como a identidade do pool de aplicativos, você deve tornar essa conta de usuário um membro do grupo local IIS_WPG. O grupo IIS_WPG é criado para simplificar o processo de configuração de autorizações e direitos necessários em todos os recursos de sistema que um processo de trabalho deve acessar para funcionar apropriadamente, até para abrir pools de aplicativos. Quando o IIS é instalado ou quando novos pools de aplicativos são criados, o grupo IIS_WPG é incluído em todas as ACLs de recursos que o pool de aplicativos deve acessar. Contudo, não é necessário adicionar o IIS_WPG em diretórios e arquivos de conteúdo de um site. Na verdade, se você necessitar de um alto nível de isolamento entre os usuários, mas configurar ACLs que concedam acesso ao IIS_WPG, poderá diminuir o grau de isolamento porque todos os aplicativos cujas contas de usuário são membros do grupo IIS_WPG provavelmente têm acesso ao conteúdo uma da outra. Conseqüentemente, você desejará adicionar ao grupo local IIS_WPG as contas que criou para cada identidade de pool de aplicativos, mas não deve usar o grupo IIS_WPG nas ACLs de arquivos e diretórios de conteúdo.

As contas usadas para a identidade de pool de aplicativos deveriam também ser diferenciadas das contas anônimas e individuais de autores e proprietários de site. As contas usadas para acesso anônimo ou para autores e proprietários de site não devem ser adicionadas ao grupo IIS_WPG porque, dessa forma, concederiam acesso a diretórios compartilhados entre pools de aplicativos, como o cache de compactação e o cache de modelo ASP.

Além disso, se você configurar pools de aplicativos com uma outra identidade que não seja a de Serviço_de_rede e seus aplicativos abrirem processos CGI, precisará atribuir os seguintes direitos de usuário a contas designadas como identidades de pool de aplicativos:

• Ajustar cotas de memória para um processo (SeIncreaseQuota).
• Substituir um processo em nível de token (SeAssignPrimaryToken).

Considerações sobre autenticação

A autenticação é o processo que comprova que você é um usuário válido de um aplicativo. Uma vez comprovado como válido, atribui-se uma identidade ao usuário, que é usada para restringir o acesso a recursos. Parte da criação de limites de segurança entre os aplicativos destina-se a assegurar que as identidades de seus aplicativos e usuários sejam organizadas de tal forma que você possa gerenciar eficazmente a autorização do aplicativo e o acesso do usuário aos recursos.

O IIS 6.0 aceita os seguintes tipos de autenticação: Anônima, Básica, Digest, Digest Avançada, Certificados de Cliente, Windows Integrada (NTLM e Kerberos) e Passport. Além disso, os aplicativos podem implementar métodos particulares de autenticação; por exemplo, autenticação baseada em formulários no ASP.NET. Lembre-se de que o método de autenticação que você usa pode afetar suas opções de implementação de segurança.

Para aplicativos altamente isolados, é melhor criar uma única conta de usuário, a ser usada para acesso anônimo ao aplicativo, e em seguida designar esse usuário como o usuário anônimo, na guia Segurança de diretório das propriedades do site (veja a Figura 5). Desse modo, você poderá configurar autorizações (consulte a seção Configurando autorizações) de modo que os aplicativos abertos pelo usuário anônimo estejam restritos a recursos apropriados. Uma identidade exclusiva de usuário anônimo, associada a uma conta designada à identidade de pool de aplicativos, oferece dois elementos essenciais para a criação de um limite de segurança eficaz para o aplicativo.

Para configurar uma conta exclusiva de usuário anônimo para um site

1. No Gerenciador do IIS, expanda o computador local, expanda a pasta Sites da Web, clique com o botão direito no site que deseja alterar e, em seguida, clique em Propriedades.
2. Na guia Segurança de diretório, em Autenticação e controle de acesso, clique no botão Editar, como mostrado na Figura 5.

   

   Figura 5   Guia Segurança de diretório de propriedades do site
    

3. Na caixa de diálogo Métodos de autenticação, digite o Nome de usuárioe Senha da conta para usar como acesso anônimo, como mostrado na Figura 6.

    

   Figura 6   Configurando uma conta exclusiva de usuário anônimo
    

4. Clique em OK.
5. Clique em OK.

Quando usar a autenticação Kerberos ou Básica, poderá usar a autenticação de passagem UNC para determinar as credenciais a serem usadas para ganhar acesso a um compartilhamento UNC, em um computador remoto. Os administradores podem configurar o IIS para usar um conjunto permanente de credenciais ou submeter as credenciais do usuário, conhecidas por autenticação de passagem (pass-trought), ao servidor de arquivos ou dispositivo NAS. Por padrão, o IIS está configurado para usar a autenticação de passagem, para a autenticação Básica e Kerberos, ao trabalhar em um ambiente Windows Server 2003 e executar pools de aplicativos com a identidade Serviços de rede. Você pode ainda configurar o Windows Server 2003 de modo que a autenticação de passagem seja possível a qualquer método de autenticação.

Observação Use uma conta de domínio ao atribuir uma identidade de pool de aplicativos, se pretende usar a autenticação de passagem com a Kerberos. Para obter mais informações, consulte o informe oficial Deploying and Configuring Internet Information Services
(IIS) 6.0 with Remotely Stored Content on UNC Servers and NAS Devices (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/deploy/
confeat/RemStorg.asp, site em inglês).

Os aplicativos ASP.NET que usam autenticação baseada em formulários dependem principalmente do uso de arquivos .config para controlar a autenticação. Os arquivos .config do aplicativo podem conter nomes de usuário e senhas exigidos para acessar os aplicativos ou podem consultar um banco de dados (exceto o SAM local ou o Microsoft Active Directory®) para validar usuários. Os aplicativos que usam a autenticação baseada em formulários aumentaram os limites dos aplicativos, visto que a autenticação de um usuário é válida somente no aplicativo autorizado.

Configurando autorizações

O princípio para reforçar eficazmente o isolamento de aplicativos depende do uso apropriado da autorização. A autorização usa a identidade autenticada do usuário, mesmo do usuário anônimo, para restringir o acesso aos recursos. Para os nossos objetivos, o conceito de “usuário” é também estendido para a identidade de pools de aplicativos, que estão autorizados a usar somente os recursos exigidos pelo aplicativo.

Os métodos para reforçar a autorização englobam a configuração de ACLs em conteúdos, permissões compartilhadas, a metabase e o Registro. Além disso, outras técnicas podem ser usadas, como a autorização de URL que usa o Gerenciador de autorizações de URL do Windows Server 2003 e a autorização nos aplicativos ASP.NET.

Configurando ACLs em conteúdos

A configuração de ACLs ficará mais fácil se você tiver em mente dois princípios:

• Atribuir usuários a grupos e, em seguida, atribuir permissões de ACL com base nesses grupos.
• Quando as permissões não são consentidas de modo explícito, o acesso é negado.

Ao implementar permissões, em geral os usuários exigem uma flexibilidade que não foi preconcebida quando os aplicativos foram configurados pela primeira vez. Para manter suas opções e facilitar a administração, experimente usar grupos para abrigar as identidades de pool de aplicativos e, em seguida, atribua ACLs a esses grupos. Por exemplo, ao configurar o isolamento de um “aplicativo X,” crie um grupo, como “Processos do aplicativo X” e, em seguida, atribua a identidade do pool de aplicativos do aplicativo X a esse grupo. Desse modo, você terá várias comodidades:

• Se alterar a identidade do pool de aplicativos no futuro, precisará apenas adicionar a nova identidade ao grupo Processos do Aplicativo X. Isso evita a tarefa cansativa, e provavelmente propensa a erros, de alterar ACLs em todos os recursos para o aplicativo.
• Você pode adicionar outros aplicativos no futuro (aplicativo Z) que necessitam de acesso aos recursos usados pelo aplicativo X e, ao mesmo tempo, impedir que o aplicativo X acesse recursos específicos usados pelo aplicativo Z. Em outras palavras, o grupo Processos do aplicativo X conteria as contas de usuário para as identidades do pool de aplicativos atribuídas tanto para o aplicativo X quanto para o aplicativo Z, mas o grupo Processos do aplicativo Z conteria apenas a identidade do pool de aplicativos do aplicativo Z.
• É provável que você precise permitir ou negar acesso a recursos para grupos de pools de aplicativos. Por exemplo, talvez você deseje criar uma identidade “Todos_os_aplicativosASP.NET” que tenha acesso a recursos específicos. Isso é mais fácil quando as identidades do pool de aplicativos são removidas de contas de usuário específicas.

Assim que você atribuir sua identidade de pool de aplicativos, precisará atribuir permissões NTFS a recursos de sistema para reconhecer permissões em uma variedade de locais, incluindo pastas usadas em bancos de dados, compilação ou armazenamento em cache de scripts, diretórios de conexão para conexão personalizada ou outros locais do sistema de arquivos que a identidade do pool de aplicativos precisa acessar. Tenha cuidado para não permitir involuntariamente que outra identidade de pool de aplicativos acesse os mesmos recursos. Por exemplo, você provavelmente não desejaria atribuir permissões aos Usuários ou ao grupo IIS_WPG. Lembre-se de que o acesso será negado, se não for consentido de modo específico.

Além de configurar ACLs para que a identidade de pool de aplicativos tenha um acesso apropriado, você precisa fornecer permissões aos usuários. Ao criar grupos que designam funções, como Autores do aplicativo X e Usuários anônimos do aplicativo X, e em seguida adicionar usuários a esses grupos e atribuir permissões aos grupos, isso se torna mais fácil. É útil ter um grupo para os usuários anônimos, se você desejar autenticar alguns usuários para conexão ou auditoria, mas ainda assim isso apenas lhes permite acesso aos recursos como usuários anônimos.

Configurando acesso a conteúdos UNC

Ao acessar conteúdos em outro servidor que usa caminhos UNC, você deve respeitar tanto as permissões Compartilhamento quanto as NTFS. Na maioria das vezes, as permissões Compartilhamento são bem flexíveis e as permissões NTFS são usadas para proteger o conteúdo. O nível de bloqueio de suas permissões Compartilhamento depende de suas necessidades específicas de segurança.

Na maioria dos aplicativos, as permissões de compartilhamento e NTFS em conteúdos remotos serão atribuídas ao usuário autenticado que está solicitando acesso. Se estiver usando a autenticação de passagem padrão, será o usuário individual, como autenticado pelo IIS. Se estiver especificando uma conta de usuário para acesso remoto, como exigido no IIS 4.0 e no IIS 5.0, o usuário especificado necessitará de direitos de acesso tanto para as permissões Compartilhamento quanto para as NTFS. Se o usuário especificado para acesso a conteúdos remotos não for uma conta de domínio, seria melhor se a conta fosse criada com o mesmo nome de usuário e senha no servidor IIS, bem como no servidor de arquivos remoto. Isso facilita o gerenciamento de conteúdos remotos no console do Gerenciador do IIS. Para obter mais informações sobre como configurar autenticações e autorizações para servidores UNC e dispositivos NAS, consulte o informe oficial Deploying and Configuring Internet Information
Services (IIS) 6.0 with Remotely Stored Content on UNC Servers and NAS Devices (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/
deploy/confeat/RemStorg.asp, site em inglês).

Configurando ACLs na metabase

Além de configurar ACLs nos recursos do sistema de arquivos, você pode configurar ACLs nas chaves da metabase. Use o Metabase Explorer 1.6 ou o MetaEdit 2.2 para visualizar e configurar ACLs nas chaves da metabase. O Metabase Explorer 1.6 pode ser descarregado do site
http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-
ade629c89499&DisplayLang=en(site em inglês). O MetaEdit 2.2 pode ser descarregado do site http://download.microsoft.com/download/iis50/Utility/5.0/NT45/EN-US/MtaEdt22.exe.

No caso de sites e respectivos conteúdos em que as chaves correspondem a propriedades existentes na metabase, o grupo IIS_WPG é configurado como Permitido para as permissões: Consultar, Consultar propriedade desprotegida e Enumerar Propriedade. As ACLs padrão nos pools de aplicativos permitem que as contas IIS_WPG, Serviços de rede e Sistema local consultem as propriedades da metabase para todos os pools de aplicativos.

Os aplicativos executados no contexto do pool de aplicativos não conseguem alterar a metabase, a menos que o aplicativo possa ser executado no contexto de segurança da identidade Administrador, que, por padrão, tem controle total sobre a metabase como um todo. Isso pode ocorrer, por exemplo, quando o administrador do sistema efetua logon ou autentica o aplicativo usando as credenciais de Administrador e o aplicativo aceita as credenciais via representação. Conseqüentemente, essas configurações não representam um sério risco de segurança. Contudo, é possível aumentar o isolamento de aplicativos fazendo os seguintes ajustes para isolar as configurações da metabase de um site:

• Remova entradas para o IIS_WPG.
• Atribua a identidade do processo de trabalho: Ler
• Designe todos os autores ou administradores de site: Ler
• Conceda ao grupo Administradores e a qualquer outro administrador de sistema: Controle Total

Configurando ACLs em chaves do Registro

Nos servidores protegidos, é recomendável que as permissões sejam reforçadas em determinadas chaves do Registro. Você pode obter um resultado melhor usando um modelo incluído no console Security and Analysis Configuration (http://www.microsoft.com/windows2000/techinfo/planning/security/secconfsteps.asp, site em inglês). A Microsoft fornece vários modelos para reforçar as permissões, incluindo aquelas fornecidas no Security Operations Guide (http://www.microsoft.com/technet/security/prodtech/win2000/secwin2k/default.asp, site em inglês). Aumentar a segurança em geral aumentará a eficácia do isolamento de aplicativos, mas é provável que você precise restringir especificamente o acesso a partes do Registro que contêm informações sobre objetos COM usados por seus aplicativos. Por exemplo, não deveria ser possível a um usuário determinar que objetos estão registrados no servidor e, em seguida, desenvolver um script para chamar esses objetos.

Isolamento COM+

As partições COM+ podem ser usadas para isolar aplicativos Web em suas partições COM+ particulares. Isso é útil para evitar que um aplicativo Web acesse os aplicativos COM+ privados, informações de configuração e dados de outro aplicativo Web. As partições COM+ podem manter diferentes versões de seus componentes COM personalizados. Por exemplo, se você hospedar sites para duas empresas concorrentes, em que ambas usem o COM+ em seus aplicativos Web, poderá usar partições COM+ para assegurar que um aplicativo Web de uma empresa não acesse os componentes COM+ nos aplicativos Web da outra empresa. Se uma dessas empresas solicitar que você altere determinados recursos em um aplicativo COM+ usados por ambas, você pode isolar a nova versão desse aplicativo COM+ na partição que está vinculada ao aplicativo Web de ambas.

Para ativar as partições COM+ no IIS, configure o sinalizador AspUsePartitionna propriedade da metabase AspAppServiceFlags, no aplicativo. A partição é identificada por um GUID (criado com o snap-in Gerenciador de serviços de componentes), que pode ser configurado na propriedade da metabase AspPartitionID (site em inglês). Se nenhuma partição for especificada, será usada a partição padrão do sistema. Para obter mais informações, consulte “Creating and Configuring COM+ Partitions”, no COM+ SDK (http://go.microsoft.com/fwlink/?LinkId=2823, site em inglês).

Importante  Apenas uma única versão de um componente COM+ pode ser usada em qualquer pool de aplicativos, mesmo se esse recurso for configurável no aplicativo. Por exemplo, se o aplicativo Ap1 usa a versão 1.0 de um aplicativo COM+ personalizado, chamado Shop.dll, e o aplicativo Ap2 usa a versão 2.0 do Shop.dll, o Ap1 e o Ap2 não devem estar no mesmo pool de aplicativos. Se estiverem, será carregada a versão Shop.dll do aplicativo que for carregado primeiro, e o outro aplicativo será forçado a usá-la até que os aplicativos sejam descarregados.