Sécuriser le contenu dans IIS via des listes de contrôle d’accès au système de fichiers

  • Article

par Nazim Lala

Introduction

La liste de contrôle d’accès (ACL) est une liste d’autorisations associées à un objet. Chacune de ces entrées d’autorisation est appelée entrée de contrôle d’accès (ACE) ; un ACE contient des autorisations associées à un objet particulier, pour une identité particulière. Par exemple, pour les objets de système de fichiers, vous pouvez définir des listes de contrôle d’accès sur des fichiers/répertoires sur un système de fichiers NTFS.

Vous pouvez utiliser des outils d’interface utilisateur graphique (GUI) (par exemple, Mon ordinateur ou Explorateur Windows®) pour définir ou modifier des listes de contrôle d’accès. Cliquez simplement avec le bouton droit sur une ressource de fichier ou de dossier à partir de l’un de ces outils, sélectionnez Propriétés, puis cliquez sur l’onglet Sécurité pour afficher une représentation graphique de la liste de contrôle d’accès sur la ressource que vous avez choisie. Dans cette boîte de dialogue, vous pouvez appliquer ou supprimer des autorisations de groupe ou d’utilisateur sur des ressources système telles que des fichiers et des dossiers. Vous pouvez également utiliser un utilitaire de ligne de commande Cacl.exe pour afficher ou modifier des listes de contrôle d’accès de fichier.

Notions de base ACL

Il est utile de commencer par quelques notions de base de la liste de contrôle d’accès.

Autorisations IIS courantes

Les autorisations les plus courantes dans ACE sont le contenu des dossiers de lecture, d’écriture, d’exécution et de liste.

  • Activer les autorisations de lecture/écriture Les autorisations de lecture et d’écriture donnent respectivement un accès en lecture et écriture à l’objet système de fichiers.
  • Répertorier l’autorisation de contenu du dossier. L’autorisation de contenu du dossier de liste est utilisée pour afficher le contenu d’un dossier et doit inscrire des notifications de modification de fichier sur un répertoire.
  • Exécuter l’autorisation. Exécuter l’autorisation est utilisée pour spécifier si le système d’exploitation doit exécuter une application particulière en tant qu’utilisateur spécifié. Cela ne couvre pas les scénarios d’application dynamique tels que PHP (ou Microsoft® ASP.NET). Vous exécutez du code lorsque vous appelez un fichier .php ou .aspx, mais pas du point de vue du système d’exploitation. Au lieu de définir l’autorisation d’exécution, vous devez examiner l’utilisation des autorisations de script/d’exécution.
  • Contrôle total. L’autorisation de contrôle total donne tout accès à l’objet de système de fichiers. Évitez le contrôle total et utilisez des autorisations de lecture/écriture plus granulaires.
  • Script IIS / Autorisations d’exécution. Les fichiers avec du contenu dynamique, tels que des fichiers .php (ou .aspx), ont besoin d’une autorisation de script pour fonctionner. Notez toutefois que si les listes de contrôle d’accès du système de fichiers ont un indicateur d’exécution, elles n’ont rien pour le script. Cela est dû au fait qu’Internet Information Services 7 et aux versions ultérieures (IIS 7 et versions ultérieures) ont une configuration spéciale pour indiquer si un fichier particulier a du contenu dynamique ; cette configuration est stockée dans la configuration IIS, en dehors des listes de contrôle d’accès du système de fichiers. Lorsque des autorisations de script ou d’exécution sont abordées, il s’agit en fait de la configuration IIS qui n’est pas l’autorisation d’exécution du système de fichiers.
  • Héritage d’objet. Les listes de contrôle d’accès du système de fichiers sont généralement héritées. Dans certains cas, le répertoire parent peut avoir des listes de contrôle d’accès très lâches qui doivent être remplacées au niveau enfant pour verrouiller correctement le contenu. Il est peu probable qu’il s’agit d’un problème dans un scénario hébergé, car il existe peu d’autorisations à la racine.

Identités IIS courantes

Vous pouvez autoriser ou refuser des autorisations à des identités particulières via des listes de contrôle d’accès pour sécuriser votre contenu. Il existe deux types d’identités : les identités de processus (celles avec laquelle le processus de travail IIS est lancé) et les identités du gestionnaire de demandes (celles de l’authentification de la demande).

  • Identité de processus de travail (WPI). Le processus de travail IIS s’exécute en tant que WPI, qui est configurable via les paramètres de configuration du pool d’applications dans IIS. IIS 6.0 sur Windows Server® 2003 et IIS 7 et versions ultérieures sur Windows Server® 2008 ont l’identité « Service réseau » comme WPI par défaut. Windows Server® 2008 R2 utilise toutefois l’identité du pool d’applications comme WPI par défaut. Si votre application s’authentifie et emprunte l’identité, votre identité de hander de demande est l’identité de l’utilisateur authentifiée.
    Si votre Php.ini a fcgi.impersonate défini sur « true » (recommandé pour IIS), vos processus PHP s’exécutent en tant qu’utilisateur authentifié. Il est important de noter que dans le cas de l’authentification anonyme, l’utilisateur authentifié serait l’utilisateur anonyme configuré.
  • IIS_IUSRS. Il s’agit d’un groupe d’identités intégré qui est un conteneur de toutes les identités de processus de travail (WPIs) sur le serveur. IIS inclut automatiquement toutes les WPIs de ce groupe (il n’est pas nécessaire de les ajouter manuellement).
    Sur IIS 6.0 sur Windows Server 2003, ce groupe est appelé IIS_WPG. Il s’agit d’un groupe global qui contient toutes les WPIs et qui n’est donc pas un bon candidat pour isoler le contenu. Toute application s’exécutant dans un pool d’applications s’exécute en tant qu’identité qui tombe dans ce groupe. Par conséquent, l’accès en lecture à ce groupe signifie que toutes les applications sont en mesure de lire votre contenu.
  • IUSR / Identité d’utilisateur anonyme. Le compte IUSR intégré est la valeur par défaut utilisée pour désigner l’identité de l’utilisateur de toute personne utilisant l’authentification anonyme. L’identité de l’utilisateur anonyme est configurable et peut être définie sur une identité en plus de cette valeur par défaut intégrée.
    Dans la pratique, vous devez configurer un compte personnalisé pour le compte d’utilisateur anonyme et n’utiliser jamais le compte intégré. Il est important de comprendre que dans IIS, l’utilisateur anonyme n’est pas l’absence d’un utilisateur authentifié. Au lieu de cela, les demandes anonymes doivent être considérées comme des demandes où l’utilisateur authentifié est l’identité de l’utilisateur anonyme.
  • Identité du pool d’applications Il s’agit d’une identité virtuelle associée à un pool d’applications particulier. Chaque fois qu’un utilisateur crée un pool d’applications, une identité virtuelle (identificateur de sécurité ou SID) est créée avec elle ; cette identité est injectée dans le processus de travail IIS afin que le processus de travail exécuté sous ce pool d’applications ait accès au contenu avec des autorisations verrouillées sur cette identité virtuelle. Dans Windows Server 2008 Service Pack 2 (SP2), l’administrateur peut créer ses processus de travail avec cette identité virtuelle. Cela est configurable dans les paramètres de configuration du pool d’applications IIS comme type « Identité du pool d’applications » et est le type d’identité WPI par défaut pour Windows Server 2008 R2. (L’identité est unique au pool d’applications qui l’a créé et peut donc être utilisée pour isoler le contenu sur le serveur et les pools d’applications plus efficacement.)
  • Identité de l’utilisateur authentifiée. Si votre application utilise une forme d’authentification (y compris l’authentification anonyme), il s’agit de l’identité de l’utilisateur authentifié. Dans le cas d’authentification anonyme, cette identité serait votre identité d’utilisateur anonyme configurée.

Pipeline d’exécution IIS

Pour comprendre les identités applicables à quelles étapes, il est utile de comprendre les principes de base du pipeline d’exécution IIS. Les deux parties du pipeline qui sont les plus applicables sont l’authentification et le mappage de gestionnaire.

  • Authentification. Avant l’authentification, le contexte utilisateur authentifié est inconnu et tous les processus de travail IIS s’exécutent en tant que WPI. Si vous avez une demande PHP qui tente d’accéder au contenu avant l’authentification de la demande, le WPI doit accéder au contenu. Ce scénario entre en jeu lors de l’utilisation des règles globales pour la réécriture d’URL qui s’exécutent dans la phase de demande de prédéfini globale du pipeline IIS, qui se produit avant l’authentification. La réécriture d’URL a la possibilité de traiter les règles différemment en fonction de l’accès à la ressource est un fichier ou un répertoire. Pour qu’il soit évalué, un accès au système de fichiers doit se produire et, en raison de sa position dans le pipeline d’exécution, cette demande d’accès se produit en tant que WPI.

    Après l’authentification, le contexte utilisateur authentifié est défini, mais vous n’êtes pas nécessairement emprunt d’identité tant que votre demande n’est pas mappée à un gestionnaire. Pour les phases entre l’authentification et le mappage de gestionnaire, vous êtes probablement en cours d’exécution en tant que WPI.

  • Mappage de gestionnaires. Dans cette phase du pipeline d’exécution, votre requête est mappée à un gestionnaire ; par exemple, les demandes adressées à *.php sont mappées au gestionnaire FastCGI. Une fois que ce mappage se produit et que vous avez activé l’emprunt d’identité, l’identité du gestionnaire est l’utilisateur authentifié et l’accès à toutes les ressources de cette phase se produit à l’aide de l’identité de l’utilisateur authentifié.

Sélectionner une identité

La détermination des comptes appropriés pour accorder des autorisations dépend du profil et des ressources critiques de votre application. Les principales considérations sont les autorisations à accorder et si vous êtes authentifié ou non.

  • Octroi des autorisations appropriées. Le contenu dynamique tel que celui-ci dans PHP et les applications ASP.NET a besoin d’une autorisation de script IIS et d’un accès en lecture. Si vous avez besoin d’exécuter des exécutables, ils doivent disposer de l’autorisation d’exécution IIS et ils doivent être correctement configurés dans la liste de restrictions CGI. Tout ce qui n’est pas chargé par l’utilisateur n’a besoin que d’un accès en lecture sur le système de fichiers.
    Le contenu qui sera chargé par un utilisateur doit résider dans un dossier distinct auquel vous attribuez un accès en écriture. Il est important de ne pas accorder à ce dossier des autorisations d’exécution ou de script IIS afin que les utilisateurs ne puissent pas charger et exécuter du code malveillant.
    En général, le WPI doit disposer d’un accès en lecture à tout le contenu de votre application pour fonctionner correctement.
  • Applications qui nécessitent l’authentification. Pour les applications qui nécessitent l’authentification, verrouillez toutes les ressources sur un groupe contenant tous les utilisateurs authentifiés. Si vous avez différentes catégories d’utilisateurs (administrateur et non-administrateur), créez des groupes distincts et donnez accès en conséquence. Par exemple, si votre application a un répertoire d’administration qui contient des scripts d’administration, accordez des autorisations pour lire ce répertoire uniquement au groupe d’administration. Si votre application emprunte l’identité, l’identité du gestionnaire est l’utilisateur authentifié ; sinon, il s’agit de votre WPI. Si vous avez défini fcgi.impersonate sur « true » dans votre fichier Php.ini, votre identité fcgi traite l’identité de l’utilisateur authentifiée ; sinon, il s’agit du WPI. Avec ces informations, un administrateur peut déterminer l’ensemble approprié de listes de contrôle d’accès à placer sur le contenu.
  • Applications qui s’exécutent anonymement. Il est important de noter que l’exécution anonyme sur IIS signifie que vous êtes authentifié en tant qu’identité d’utilisateur anonyme. Dans ce cas, verrouillez les ressources vers l’identité du pool d’applications ou votre identité anonyme configurée personnalisée et donnez accès à l’identité du pool d’applications via l’identité anonyme. Si vous donnez IIS_IUSRS accès au groupe à votre contenu, les applications s’exécutant dans n’importe quel pool d’applications ont accès à votre contenu. Si vous autorisez les utilisateurs anonymes à charger des fichiers, votre application doit s’assurer que d’autres case activée sur les types de contenu que ces utilisateurs peuvent charger afin de sécuriser le serveur.

Guide pratique pour définir des listes de contrôle d’accès

Il existe plusieurs façons de définir vos listes de contrôle d’accès via l’interpréteur de commandes, notamment les outils en ligne de commande tels que Icacls.exe. Cet article se concentre sur le mécanisme XML (Web Deployment Tool) qui peut être utilisé pour définir des listes de contrôle d’accès. Cela est utilisé lors de l’installation d’une application via l’outil de déploiement web.

Pour accorder des autorisations lecture, exécution et écriture au répertoire du système de fichiers MyApp pour l’utilisateur Foo, ajoutez la ligne suivante au fichier Manifest.xml :

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

Pour définir la liste de contrôle d’accès sur le chemin MyApp/Upload pour permettre aux utilisateurs anonymes de charger du contenu, ajoutez la ligne suivante à votre fichier Manifest.xml :

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

Notez que anonymousAuthenticationUser est un jeton spécial qui sera résolu en votre identité d’authentification anonyme configurée.

Pour accorder l’accès en lecture au dossier MyApp\Data pour l’identité du pool d’applications, ajoutez la ligne suivante au fichier Manifest.xml :

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

Notez que setAclUse r n’est pas utilisé ici (la valeur par défaut est l’identité du pool d’applications).