Sécurisation des rôles
Mise à jour : novembre 2007
La gestion des rôles vous permet de gérer l'autorisation pour votre application à l'aide de catégories créées qui portent le nom de « rôles ». En assignant des utilisateurs à des rôles, vous pouvez contrôler l'accès à différentes parties ou fonctionnalités de votre application Web en fonction d'un rôle au lieu d'un nom d'utilisateur ou en plus de celui-ci. Par exemple, l'application d'un employé peut répondre à des rôles tels que Gestionnaires, Employés, Directeurs, etc., différents privilèges étant spécifiés pour chaque rôle.
Les utilisateurs peuvent appartenir à plusieurs rôles. Par exemple, si votre site est un forum de discussion, certains utilisateurs peuvent appartenir aux rôles Membres et Modérateurs. Vous pouvez affecter des privilèges différents à chaque rôle du site, et un utilisateur qui appartient aux deux rôles dispose de deux ensembles de privilèges.
Bien que l'application des méthodes conseillées en matière de codage et de configuration puisse améliorer la sécurité de votre application, il est également important de mettre à jour en permanence votre serveur d'application à l'aide des derniers correctifs de sécurité pour Microsoft Windows et les services IIS (Internet Information Services), ainsi que tous les correctifs pour Microsoft SQL Server, Active Directory ou d'autres sources de données de rôle.
Pour plus d'informations sur les méthodes conseillées relatives à l'écriture d'un code sécurisé et la sécurisation des applications, consultez le manuel « Writing Secure Code » de Michael Howard et David LeBlanc et l'aide fournie par Microsoft Patterns and Practices (https://www.microsoft.com/resources/practices/default.mspx).
Configuration du gestionnaire de rôles sécurisé
La fonctionnalité de gestionnaire de rôles est désactivée par défaut pour les applications ASP.NET pour améliorer la sécurité des applications qui n'utilisent pas le gestionnaire de rôles. Lorsqu'elle est activée, les paramètres de configuration par défaut ont les valeurs les plus sécurisées. Pour plus d'informations sur les paramètres de configuration du gestionnaire de rôles et leurs valeurs par défaut, consultez roleManager, élément (Schéma des paramètres ASP.NET).
Sécurisation de valeurs de configuration
Lorsque vous stockez des informations sensibles dans un fichier de configuration pour une application, vous devez chiffrer les valeurs sensibles à l'aide de la configuration protégée. Les informations qui sont particulièrement sensibles incluent les clés de chiffrement stockées dans l'élément de configuration machineKey et les chaînes de connexion à une source de données stockées dans l'élément de configuration connectionStrings. Pour plus d'informations, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée.
Clés de chiffrement sécurisées et hachage
Il est vivement recommandé de protéger les noms de rôles mis en cache dans un cookie en affectant la valeur All à l'attribut cookieProtection de l'élément roleManager. Les valeurs de clés de chiffrement pour l'algorithme de chiffrement spécifié sont stockées dans l'élément de configuration machineKey. Pour renforcer le chiffrement, spécifiez une clé de chiffrement qui est une valeur générée aléatoirement de la longueur appropriée pour l'algorithme de chiffrement sélectionné.
Sur un serveur qui héberge plusieurs applications, vous devez définir des clés de chiffrement uniques pour chaque application. Une solution moins sécurisée consiste à définir une clé de chiffrement unique et à définir l'option IsolateApps à l'aide de la clé.
Les serveurs hôtes peuvent également empêcher que les paramètres de configuration soient remplacés dans la configuration de l'ordinateur en refusant des droits de substitution. Cela inclut le fait d'empêcher que les clés de chiffrement soient redéfinies dans le fichier Web.config d'une application.
Sécurisation des connexions à une source de données de rôle
Chaînes de connexion
Comme il a été mentionné précédemment, il est important de protéger la chaîne de connexion utilisée pour accéder à SQL Server, à Active Directory ou à une autre application de source de données. Pour sécuriser la connexion à votre serveur de base de données, vous devez chiffrer les informations de la chaîne de connexion dans la configuration à l'aide de la configuration protégée. Pour plus d'informations, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée.
Connexion à SQL Server à l'aide de la sécurité intégrée
Pour vous connecter aux ordinateurs qui exécutent SQL Server, vous devez utiliser la sécurité intégrée qui permet d'éviter que votre chaîne de connexion soit compromise et que votre ID d'utilisateur et votre mot de passe soient accessibles. Lorsque vous spécifiez une connexion qui utilise la sécurité intégrée pour vous connecter à un ordinateur qui exécute SQL Server, la fonctionnalité de gestionnaire de rôles rétablit l'identité du processus. Vous devez vérifier que l'identité du processus (par exemple, le pool d'applications) qui exécute ASP.NET correspond au compte de processus par défaut ou à un compte d'utilisateur restreint. Pour plus d'informations, consultez Emprunt d'identité ASP.NET.
Autorisations de la base de données SQL Server
La base de données SQL Server qui est utilisée pour stocker les informations de rôles des utilisateurs inclut des rôles et des vues de base de données qui vous permettent de limiter l'accès des utilisateurs à la visibilité et aux fonctions requises. Vous devez assigner des privilèges minimums à l'ID d'utilisateur utilisé pour se connecter à la base de données de rôle SQL Server. Pour plus d'informations, consultez Rôles et vues dans la base de données des services d'application pour SQL Server.
Identité du processus de traitement SQL Server Express
SQL Server Express 2005 inclut un nouveau mode de fonctionnement qui permet à SQL Server de démarrer un processus de traitement qui s'exécute en tant qu'identité de l'utilisateur qui se connecte. Cette fonction est appelée mode « passage comme utilisateur ». Bien que ce mode de fonctionnement convienne au développement bureautique lors de l'utilisation des services IIS, le démarrage de processus de traitement n'est pas adapté aux serveurs Web qui hébergent plusieurs bases de code de clients non fiables. Les serveurs d'hébergement partagés qui contiennent des applications qui ne se font pas mutuellement confiance doivent désactiver explicitement la fonction « passage comme utilisateur ». Cette fonctionnalité peut être désactivée en se connectant à l'instance SQL Express (par exemple, osql –E –S .\sqlexpress) et en soumettant la commande Transact-SQL suivante.
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Sécurisation du magasin d'autorisations
Pour améliorer la sécurité de votre source de données lorsque vous utilisez AuthorizationStoreRoleProvider, vous devez stocker vos informations de rôles dans un serveur Active Directory, par opposition à un magasin d'autorisations basé sur des fichiers. Cette procédure peut empêcher le fichier de magasin de stratégies d'être exposé si le serveur Web venait à être compromis.
La fonctionnalité de gestionnaire de rôles rétablit l'identité du processus lors de la connexion à un serveur Active Directory. Vous devez vérifier que l'identité du processus (par exemple, le pool d'applications) qui exécute ASP.NET correspond au compte de processus par défaut ou à un compte d'utilisateur restreint. Pour plus d'informations, consultez Emprunt d'identité ASP.NET. En outre, vous devez assigner des autorisations au compte dans le magasin d'autorisations Active Directory, qui autorisent uniquement l'accès à l'application Gestionnaire d'autorisations spécifique ou à la portée requise par votre application ASP.NET.
Vous devez utiliser un outil du chiffrement du réseau, par exemple la sécurité du protocole Internet (IPSec), pour protéger la connexion au serveur Active Directory.
Sécurisation du cookie de rôle
Pour améliorer les performances, vous pouvez spécifier la mise en cache des noms de rôles d'un utilisateur dans un cookie de session en affectant la valeur true à l'attribut cacheRolesInCookie de l'élément roleManager. Par défaut, les noms de rôles sont stockés dans un format chiffré, mais vous devez fournir une sécurité supplémentaire au cookie de rôles en affectant la valeur true à l'attribut cookieRequireSSL, et mettre en cache uniquement les rôles dans un cookie de session lorsque le protocole SSL est activé. Cette procédure empêche le cookie de rôle d'être exposé sur le réseau et d'être utilisé dans une agression par reconstitution contre votre application.
Protection des cookies contre le partage entre plusieurs applications
Si l'attribut cacheRolesInCookie de l'élément roleManager a la valeur true et si l'attribut cookiePath a pour valeur un chemin d'accès qui inclut plusieurs applications, le même cookie de rôle sera envoyé à plusieurs applications. Vous pouvez partager le cookie de rôle entre plusieurs applications en spécifiant les mêmes informations de chiffrement dans l'élément de configuration machineKey pour chaque application.
Pour éviter que le cookie de rôle soit partagé entre plusieurs applications, spécifiez des clés de chiffrement distinctes dans l'élément de configuration machineKey pour chaque application, définissez l'attribut cookiePath de chaque application sur le chemin d'accès d'application spécifique et affectez une valeur unique à la propriété ApplicationName pour chaque application.
Pages Web sécurisées qui utilisent des rôles
Les pages d'application qui utilisent des données sensibles, par exemple les pages d'ouverture de session, doivent être sécurisées à l'aide de mécanismes de sécurité Web standard. Ceux-ci incluent l'utilisation du protocole SSL (SSL, Secure Socket Layer) et la nécessité pour les utilisateurs d'ouvrir une session pour exécuter des opérations sensibles comme la mise à jour d'informations utilisateur ou la suppression d'utilisateurs.
En outre, les pages ne doivent pas exposer de données de fonctionnalité sensibles (telles que des mots de passe et, dans certains cas, des noms d'utilisateurs) en texte clair. Assurez-vous que les pages qui affichent de telles informations utilisent le protocole SSL et ne sont accessibles qu'aux utilisateurs authentifiés. De même, évitez de stocker des données de fonctionnalité sensibles dans les cookies ou de les envoyer via des connexions non fiables.
Sécurisation contre les attaques par déni de service
Les méthodes qui exécutent des mises à jour ou de grandes opérations de recherche peuvent réduire la réactivité de votre source de données de rôle si elle est appelée en même temps par plusieurs clients. Pour éviter d'être exposé à une attaque par déni de service, limitez l'accès aux pages ASP.NET qui utilisent des méthodes qui exécutent des recherches ou des mises à jour de base de données aux utilisateurs administratifs et exposez uniquement les pages ASP.NET qui fournissent la validation de l'appartenance de rôle pour une utilisation générale.
Messages d'erreur et événements
Exceptions
Pour empêcher que des informations sensibles ne soient exposées à des sources non autorisées, configurez votre application soit pour ne pas afficher de messages d'erreur détaillés, soit pour afficher des messages d'erreur détaillés uniquement lorsque le client est le serveur Web lui-même. Pour plus d'informations, consultez customErrors, élément (Schéma des paramètres ASP.NET).
Journal des événements
Si votre serveur exécute Windows Server 2003, vous pouvez améliorer la sécurité de votre application en sécurisant le journal des événements et en définissant des paramètres concernant sa taille, sa conservation, etc. pour éviter toute attaque par déni de service indirecte.
Informations de traçage
Votre serveur Web peut être configuré pour assurer le traçage lorsque certaines actions concernant la fonctionnalité de gestionnaire de rôle se produisent et pour stocker les informations de traçage dans un fichier journal. Étant donné que des informations sensibles telles que les noms d'utilisateurs et les noms de rôles peuvent être stockées dans le fichier journal des traces, vous devez limiter la possibilité d'activer le traçage aux administrateurs uniquement, ainsi que la possibilité de configurer l'emplacement du fichier journal des traces et d'accéder au fichier journal des traces.
Fournisseurs de rôle personnalisés
Lors de la création d'un fournisseur de rôle personnalisé, vérifiez que vous appliquez les méthodes conseillées en matière de sécurité pour éviter des attaques telles que des attaques d'injection SQL lors de l'utilisation d'une base de données. Lorsque vous utilisez un fournisseur de rôle personnalisé, assurez-vous que celui-ci applique les méthodes conseillées en termes de sécurité.
Utilisation de caractères dépendants de la culture
Lors de l'utilisation du fournisseur de rôles SQL Server ou d'un fournisseur de rôles personnalisé, votre source de données peut être configurée pour stocker des données de rôle sous un format dépendant de la culture. Toutefois, ASP.NET évalue toujours les noms de rôles spécifiés dans l'élément de configuration authorization et les noms de rôles dans la source de données comme indifférents de la culture. Par conséquent, des utilisateurs non autorisés peuvent recevoir des autorisations indésirables car, lorsque le nom de leur rôle non autorisé est traité comme indifférent de la culture, il s'agit du même nom que celui d'un rôle autorisé. Pour éviter d'accorder l'accès à des utilisateurs non autorisés, assurez-vous que les noms de rôles sont uniques lorsqu'ils sont évalués comme étant indifférents de la culture.