Compartilhar via

Proteger conteúdo no IIS por meio de ACLs do sistema de arquivos

por Nazim Lala

Introdução

A ACL (lista de controle de acesso) é uma lista de permissões associadas a um objeto. Cada uma dessas entradas de permissão é chamada de ACE (entrada de controle de acesso). Um ACE contém permissões associadas a um objeto específico para uma identidade específica. Por exemplo, para objetos do sistema de arquivos, é possível definir ACLs em arquivos/diretórios em um sistema de arquivos NTFS.

Use as ferramentas de GUI (interface gráfica do usuário) (como Meu Computador ou Windows® Explorer) para definir ou editar as ACLs. Basta clicar com o botão direito do mouse em qualquer recurso de arquivo ou pasta de uma dessas ferramentas, selecionar Propriedades e selecionar guia Segurança, para visualizar uma representação gráfica da ACL no recurso escolhido. Nessa caixa de diálogo, é possível aplicar ou remover permissões de grupo ou usuário a recursos do sistema, como arquivos e pastas. Também é possível usar um utilitário de linha de comando Cacl.exe para exibir ou modificar ACLs de arquivo.

Noções básicas de ACL

É útil começar com algumas noções básicas de ACL.

Permissões comuns do IIS

As permissões mais comuns de interesse no ACE são o conteúdo de leitura, gravação, execução e lista de pastas.

  • Permissões de leitura/gravação. As permissões de leitura e gravação dão acesso de leitura e gravação ao objeto do sistema de arquivos, respectivamente.
  • Permissão listar conteúdo da pasta. A permissão de conteúdo da pasta da lista é usada para exibir o conteúdo de uma pasta e é necessária para registrar notificações de alteração de arquivo em um diretório.
  • Permissão de execução. A permissão de execução é usada para especificar se o sistema operacional deve executar um aplicativo específico como o usuário especificado. Isso não abrange cenários de aplicativos dinâmicos, como PHP (ou Microsoft® ASP.NET). Você está executando código quando invoca um arquivo .php ou .aspx, mas não da perspectiva do sistema operacional. Em vez de definir a permissão de execução, analise o uso das permissões de script/execução.
  • Controle total. A permissão de controle total fornece todo o acesso ao objeto do sistema de arquivos. Evite o controle total e use permissões de leitura/gravação mais granulares.
  • Script do IIS/Permissões de execução. Arquivos com conteúdo dinâmico, como arquivos .php (ou .aspx), precisam de permissão de script para funcionar. Mas note que, embora as ACLs do sistema de arquivos tenham um sinalizador de execução, elas não têm nada para o script. Isso ocorre porque os Serviços de Informações da Internet 7 e superiores (IIS 7 e superior) têm uma configuração especial para indicar se um arquivo específico tem conteúdo dinâmico. Essa configuração é armazenada na configuração do IIS, fora das ACLs do sistema de arquivos. Quando as permissões de script ou execução são discutidas, na verdade, é a configuração do IIS que não é a permissão de execução do sistema de arquivos.
  • Herança de objetos. As ACLs do sistema de arquivos geralmente são herdadas. Em alguns casos, o diretório pai pode ter ACLs muito soltas que precisam ser substituídas no nível filho para bloquear adequadamente o conteúdo. É improvável que isso seja um problema em um cenário hospedado, pois há poucas permissões na raiz.

Identidades comuns do IIS

É possível permitir ou negar permissões a identidades específicas por meio de ACLs para proteger seu conteúdo. Há dois tipos de identidades: identidades de processo (aquelas com as quais o processo de trabalho do IIS é iniciado) e as identidades do manipulador de solicitações (aquelas da autenticação da solicitação).

  • WPI (identidade do processo de trabalho). O processo de trabalho do IIS é executado como a WPI, que é configurável por meio das configurações do Pool de Aplicativos no IIS. O IIS 6.0 no Windows Server® 2003 e no IIS 7 e posterior no Windows Server® 2008, tem a identidade de “Serviço de Rede” como a WPI padrão. No entanto, o Windows Server® 2008 R2 usa a identidade do pool de aplicativos como a WPI padrão. Se o aplicativo se autenticar e representar, sua identidade do solicitante será a identidade do usuário autenticada.
    Se o Php.ini tiver fcgi.impersonate definido como “verdadeiro” (recomendado para O IIS), os processos do PHP serão executados como o usuário autenticado. É importante notar que, no caso de autenticação anônima, o usuário autenticado seria o usuário anônimo configurado.
  • IIS_IUSRS. Este é um grupo de identidades interno que é um contêiner de todas as WPIs (identidades de processo de trabalho) no servidor. O IIS inclui automaticamente todos os WPIs nesse grupo (não é necessário adicioná-los manualmente).
    No IIS 6.0 no Windows Server 2003, esse grupo é chamado de IIS_WPG. Esse é um grupo abrangente que contém todos as WPIs e, portanto, não é um bom candidato para isolar o conteúdo. Qualquer aplicativo em execução em qualquer pool de aplicativos estaria em execução como uma identidade que se enquadra nesse grupo, portanto, dar a esse grupo acesso de leitura significa que todos os aplicativos podem fazer a leitura do conteúdo.
  • IUSR/Identidade de usuário anônima. A conta IUSR interna é o padrão usado para indicar a identidade do usuário de qualquer pessoa que esteja usando a autenticação anônima. A identidade do usuário anônimo é configurável e pode ser definida como uma identidade além desse padrão interno.
    Na prática, você deverá configurar uma conta personalizada para a conta de usuário anônima e nunca usar a conta interna. É importante entender que, no IIS, o usuário anônimo não é a falta de um usuário autenticado. Em vez disso, as solicitações anônimas devem ser consideradas como solicitações em que o usuário autenticado é a identidade do usuário anônimo.
  • Identidade do pool de aplicativos. Essa é uma identidade virtual associada a um pool de aplicativos específico. Sempre que um usuário cria um pool de aplicativos, uma identidade virtual (identificador de segurança ou SID) é criada com ele, essa identidade é injetada no processo de trabalho do IIS, para que o processo de trabalho em execução nesse pool de aplicativos tenha acesso ao conteúdo com permissões bloqueadas para essa identidade virtual. No Service Pack 2 (SP2) do Windows Server 2008, o administrador pode criar seus processos de trabalho com essa identidade virtual. Isso é configurável nas configurações do pool de aplicativos do IIS como o tipo de “Identidade do Pool de Aplicativos” e é o tipo de identidade do WPI padrão para o Windows Server 2008 R2. (A identidade é exclusiva do pool de aplicativos que o criou e, portanto, pode ser usada para isolar o conteúdo no servidor para pools de aplicativos com mais eficiência.)
  • Identidade de usuário autenticada. Se o aplicativo usar qualquer forma de autenticação (inclusive autenticação anônima), essa será a identidade do usuário autenticado. No caso de autenticação anônima, essa identidade seria sua identidade de usuário anônima configurada.

Pipeline de execução do IIS

Para entender quais identidades são aplicáveis em quais estágios, é útil entender os conceitos básicos do pipeline de execução do IIS. As duas partes do pipeline que são mais aplicáveis são autenticação e mapeamento de manipulador.

  • Autenticação. Antes da autenticação, o contexto do usuário autenticado é desconhecido e todos os processos de trabalho do IIS são executados como o WPI. Caso tenha uma solicitação de PHP que esteja tentando acessar o conteúdo antes que a solicitação seja autenticada, o WPI precisará de acesso ao conteúdo. Este cenário entra em jogo ao usar as regras globais do Regravador de URL, que são executadas na fase de solicitação de pré-início global do pipeline do IIS, que ocorre antes da autenticação. O Regravador de URL tem a capacidade de processar regras de forma diferente com base em se o recurso que está sendo acessado é um arquivo ou um diretório. Para que isso seja avaliado, um acesso ao sistema de arquivos precisa ocorrer e, devido à sua posição no pipeline de execução, essa solicitação de acesso ocorre como o WPI.

    Após a autenticação, o contexto do usuário autenticado está definido, mas você não necessariamente representará até que sua solicitação seja mapeada para um manipulador. Para fases entre autenticação e mapeamento de manipulador, é mais provável que você esteja em execução como WPI.

  • Mapeamento de manipulador. Nesta fase do pipeline de execução, sua solicitação é mapeada para um manipulador; por exemplo, solicitações para *.php ser mapeadas para o manipulador do FastCGI. Após ocorrer esse mapeamento e você ter a representação habilitada, a identidade do manipulador é o Usuário Autenticado e todo o acesso a recursos nessa fase ocorre usando a identidade do usuário autenticado.

Selecionar uma identidade

Descobrir as contas certas para conceder permissões depende do perfil e dos recursos críticos do aplicativo. As principais considerações são quais permissões conceder e se você está ou não autenticado.

  • Conceder as permissões apropriadas. Conteúdo dinâmico como este em aplicativos do PHP e ASP.NET, precisa de permissão de script do IIS e acesso de leitura. Caso precise executar os arquivos executáveis, eles precisarão ter a permissão de execução do IIS e eles precisarão ser configurados corretamente na Lista de Restrições de CGI. Qualquer coisa que não seja carregada pelo usuário só precisa de acesso de leitura no sistema de arquivos.
    O conteúdo que será carregado por um usuário deve residir em uma pasta separada à qual você atribui acesso de gravação. É importante não conceder a esta pasta permissões de execução ou script do IIS, para que os usuários não possam carregar e executar código mal-intencionado.
    Em geral, a WPI deve ter acesso de leitura a todo o conteúdo para que o aplicativo funcione corretamente.
  • Aplicativos que exigem autenticação. Para aplicativos que exigem autenticação, bloqueie todos os recursos para um grupo que contém todos os usuários autenticados. Caso tenha diferentes categorias de usuários (administrador e não administrador), crie grupos separados e dê acesso adequadamente. Por exemplo, caso o aplicativo tenha um diretório de administração que contenha scripts de administração, conceda permissões para fazer a leitura desse diretório apenas para o grupo de administradores. Caso o aplicativo esteja representando, a identidade do manipulador será o usuário autenticado, caso contrário, é o WPI. Caso definiu fcgi.impersonate como “verdadeiro” no arquivo Php.ini, sua identidade de processos fcgi será a identidade do usuário autenticada, caso contrário, é o WPI. Com essas informações, um administrador pode determinar o conjunto certo de ACLs a serem colocadas no conteúdo.
  • Aplicativos que são executados anonimamente. É importante notar que a execução anônima no IIS significa que você está autenticado como a identidade do usuário anônimo. Nesse caso, bloqueie os recursos para a identidade do pool de aplicativos ou sua identidade anônima configurada personalizada e dê acesso à identidade do pool de aplicativos pela identidade anônima. Caso forneça acesso ao grupo IIS_IUSRS para o conteúdo, os aplicativos em execução em qualquer pool de aplicativos terão acesso ao conteúdo. Caso permita que usuários anônimos carreguem arquivos, o aplicativo deverá garantir verificações adicionais sobre os tipos de conteúdo que esses usuários podem carregar para manter o servidor seguro.

Como definir as ACLs

Há várias maneiras de definir as ACLs por meio do shell, incluindo ferramentas de linha de comando, como Icacls.exe. Este artigo se concentra no mecanismo de manifesto da XML (Ferramenta de Implantação da Web) que pode ser usado para definir as ACLs. Isso é usado ao instalar um aplicativo por meio da Ferramenta de Implantação da Web.

Para conceder permissões de leitura, execução e gravação ao diretório do sistema de arquivos MyApp para o usuário Foo, adicione a seguinte linha ao arquivo Manifest.xml:

<setAcl path="MyApp" setAclAccess="ReadAndExecute, Write" setAclUser="Foo" />

Para definir a ACL no caminho MyApp/Upload para permitir que usuários anônimos carreguem conteúdo, adicione a seguinte linha ao arquivo Manifest.xml:

<setAcl path="MyApp/Upload" setAclAccess="Write" setAclUser="anonymousAuthenticationUser" />

Note que o anonymousAuthenticationUser é um token especial que será resolvido para sua identidade de autenticação anônima configurada.

Para conceder acesso de leitura à pasta MyApp\Data para a identidade do pool de aplicativos, adicione a seguinte linha ao arquivo Manifest.xml:

<setAcl path="MyApp/Data" setAclAccess="Read" />

Observe que o setAclUse r não é usado aqui (o valor padrão para isso é a Identidade do Pool de Aplicativos).