Module 1 : Introduction

Sur cette page

Dans ce module
Objectifs
S'applique à
Environnement connecté
Principes fondamentaux
Association des technologies
Principes de conception
Résumé

Dans ce module

La création d'applications Web distribuées sécurisées est une opération complexe. Il faut notamment tenir compte des nombreux liens que comportent les applications distribuées, sachant que la sécurité générale d'une application dépend toujours de son lien le plus faible. Pour faire fonctionner ensemble les différents éléments d'une application distribuée, vous devez être familiarisé avec un large éventail de produits et de technologies.

Ce module décrit les concepts fondamentaux relatifs à la création d'applications Web distribuées sécurisées : l'authentification, l'autorisation et les communications sécurisées. Il présente également un ensemble de principes de sécurité clés que vous devez respecter lors de la génération de telles applications.

Haut de page

Objectifs

Ce module vous permet d'effectuer les opérations suivantes :

• comprendre ce que recouvrent les termes « authentification », « autorisation » et « communications sécurisées » dans le contexte de ce guide ;

• comprendre tous les aspects de l'architecture globale d'une application Web ASP.NET ; dans cette optique, vous devez vous familiariser avec les technologies qui constituent cette architecture et les options d'authentification, d'autorisation et de communication sécurisée fournies par chacune de ces technologies ;

• comprendre les principes de sécurité fondamentaux sur lesquels reposent les éléments évoqués dans ce guide.

Haut de page

S'applique à

Ce module s'applique aux produits et technologies suivants :

• Windows XP ou Windows 2000 Server et systèmes d'exploitation ultérieurs

• .NET Framework versions 1.0 et ultérieures

• ASP.NET 1.0

Haut de page

Environnement connecté

Vous savez peut-être déjà comment créer des applications sécurisées, mais savez-vous également exploiter vos connaissances lorsque vous développez des applications Web .NET ? Êtes-vous en mesure d'appliquer votre savoir-faire dans le contexte actuel des applications Web distribuées ? Aujourd'hui en effet, les applications Web connectent les sociétés entre elles ou à leurs clients et présentent divers degrés d'exposition (sur des réseaux intranet ou extranet ou encore sur Internet, par exemple).

Vous devez prendre en considération certaines caractéristiques fondamentales de cet environnement connecté :

• Les services Web utilisent des standards tels que SOAP, XML (Extensible Markup Language) et HTTP (Hypertext Transport Protocol), mais sont par essence amenés à transmettre des informations potentiellement sensibles en texte brut (non crypté).

• Les applications Internet entreprises-clients (B2C) transmettent des données sensibles sur le Web.

• Les applications extranet interentreprises (B2B) rendent parfois floues les limites de confiance et permettent à des applications d'être appelées par d'autres applications de sociétés partenaires.

• Quant aux applications intranet, elles ne sont pas sans risque, étant donné la nature sensible des applications de ressources humaines et de gestion des salaires. Ces applications sont particulièrement vulnérables et peuvent être la cible de salariés mécontents ou d'administrateurs malveillants.

Haut de page

Principes fondamentaux

Pour être efficace, la stratégie de sécurité des applications doit s'appuyer sur une méthode robuste d'authentification et d'autorisation assortie de communications sécurisées afin de protéger la confidentialité et l'intégrité des données sensibles. Avant de continuer, nous allons définir ces concepts fondamentaux. Dans le Module 3, « Authentification et autorisation », nous verrons comment les divers mécanismes d'authentification et d'autorisation peuvent être combinés pour offrir une sécurité solide.

Authentification

L'authentification consiste à identifier de manière positive les clients d'une application. Les clients peuvent être des utilisateurs finaux, des services, des processus ou des ordinateurs. Dans le jargon de la sécurité, les clients authentifiés sont appelés entités.

L'authentification intervient sur les différents niveaux d'une application Web distribuée. Les utilisateurs finaux peuvent être authentifiés par l'application Web, généralement à l'aide d'un nom d'utilisateur et d'un mot de passe. Ensuite, lorsque la demande de l'utilisateur final est traitée par les serveurs d'applications de niveau intermédiaire (si votre architecture comporte de tels serveurs) et par le serveur de base de données, une authentification est réalisée pour valider la demande et procéder à son traitement.

Dans de nombreuses applications, les serveurs et les composants en aval n'authentifient pas l'utilisateur final. Ils authentifient plutôt l'entité que représente l'application en amont, partant du principe que cette application a correctement authentifié et autorisé la demande avant de la transmettre.

Les nombreux mécanismes d'authentification qui s'appliquent au développement d'applications ASP.NET sont présentés dans le Module 2, « Modèle de sécurité pour les applications ASP.NET ».

Autorisation

Le processus d'autorisation détermine les ressources et les opérations auxquelles le client authentifié a accès. Les ressources comprennent les fichiers, les bases de données, les tables, les lignes, etc., ainsi que les ressources de niveau système, telles que les clés de Registre et les données de configuration.

De nombreuses applications Web autorisent l'accès à des opérations mises à la disposition des ressources sous-jacentes sous forme de méthodes (et non directement), principalement pour des raisons d'évolutivité et de facilité de gestion. Il reste cependant primordial de sécuriser les ressources de niveau système à l'aide de mécanismes de sécurité au niveau de la plate-forme, tels que les listes de contrôle d'accès (ACL) Windows. La plupart des modèles d'autorisation de niveau application les plus courants font appel aux rôles pour regrouper les utilisateurs possédant les mêmes privilèges au sein de l'application.

Les diverses options d'autorisation et les différents opérateurs de contrôle d'appels à la disposition des développeurs d'application ASP.NET sont présentés dans le Module 2, « Modèle de sécurité pour les applications ASP.NET ».

Communication sécurisée

Les données sensibles sont souvent transmises entre les différents niveaux d'application, du serveur de base de données au navigateur, et vice versa. Sont considérés comme données sensibles les coordonnées des comptes bancaires, les numéros de carte de crédit, les informations relatives aux salaires, etc. De plus, les applications doivent sécuriser les informations d'identification quand celles-ci sont transmises sur le réseau dans le cadre des ouvertures de session.

La communication sécurisée offre les deux fonctionnalités suivantes :

• Confidentialité. La confidentialité consiste à garantir le caractère privé et confidentiel des données et à empêcher leur visualisation par des personnes susceptibles d'être équipées de logiciels de surveillance du réseau. La confidentialité est généralement assurée au moyen du cryptage.

• Intégrité. Les canaux de communication sécurisés doivent également garantir que les données sont protégées contre toute modification accidentelle ou délibérée (malveillante) lors de leur transit. L'intégrité est généralement assurée à l'aide de codes d'authentification des messages (MAC, Message Authentication Code).

Il est important d'appliquer des techniques de communication sécurisée à l'intérieur et à l'extérieur du pare-feu, car de nombreuses violations de la sécurité et de la confidentialité des informations sont possibles en interne, au sein des réseaux d'entreprise.

Les communications sécurisées et les diverses méthodes disponibles sont présentées dans le Module 4, « Communication sécurisée ».

Haut de page

Association des technologies

Les applications Web ASP.NET sont développées à l'aide d'un large éventail de technologies et de produits. Il est nécessaire de faire appel à diverses méthodes d'authentification, d'autorisation et de communication sécurisée dans les différents niveaux de votre application afin de renforcer la stratégie de sécurité.

La figure 1 récapitule les différentes technologies ainsi que les principales options d'authentification et d'autorisation correspondantes.

Figure 1
Sécurité des applications Web .NET

Haut de page

Principes de conception

Les conseils fournis dans les modules suivants de ce guide reposent sur un certain nombre de principes. Nous vous conseillons d'assimiler ces principes et de les appliquer lors de la création de vos applications :

• Adoptez le principe du moindre privilège. Les processus qui font appel à des scripts ou à un code doivent s'exécuter à l'aide d'un compte doté de privilèges minimum afin de limiter les dommages potentiels qui risquent de survenir si l'intégrité du processus est compromise. Si un utilisateur malintentionné parvient à injecter un code dans un processus serveur, les privilèges accordés à ce processus déterminent dans une large mesure les types d'opérations que cet utilisateur peut effectuer. Le code nécessitant des approbations supplémentaires (et des privilèges plus élevés) doit être isolé au sein de processus séparés.
  L'équipe ASP.NET a décidé d'exécuter le compte ASP.NET avec des privilèges minimum (à l'aide du compte ASPNET). Cette modification a été implémentée dans la version initiale de .NET Framework. Dans les versions bêta, ASP.NET était exécuté en tant que SYSTÈME, paramètre moins sécurisé par nature.

• Renforcez votre protection. Placez des points de contrôle dans chacune des couches et des sous-systèmes de l'application. Les points de contrôle sont les opérateurs de contrôle d'appels qui garantissent que seuls les utilisateurs authentifiés et autorisés sont en mesure d'accéder à la couche en aval suivante.

• Ne faites pas confiance aux entrées des utilisateurs. Les applications doivent valider intégralement toutes les entrées des utilisateurs avant d'effectuer des opérations à l'aide de celles-ci. La validation peut consister, par exemple, à exclure certains caractères spéciaux. Cette mesure préventive protège l'application contre une mauvaise utilisation ou contre des attaques délibérées de la part de personnes qui tentent d'injecter des commandes malveillantes dans le système. Il peut s'agir notamment d'une injection de code SQL, d'une injection de scripts ou encore d'un dépassement de la capacité de la mémoire tampon.

• Utilisez des paramètres par défaut sécurisés. Les développeurs ont souvent tendance à utiliser des paramètres de sécurité limités dans le seul but de faire fonctionner l'application. Si votre application nécessite des fonctionnalités qui vous obligent à restreindre ou à modifier les paramètres de sécurité par défaut, testez l'incidence et mesurez les conséquences de ces modifications avant de les apporter.

• Ne partez pas du principe que les données cachées sont sécurisées. Le fait de cacher des données secrètes en utilisant des noms de variables trompeurs ou en les stockant à des emplacements de fichiers peu courants ne garantit par leur sécurité. Dans cette partie de cache-cache, il est préférable d'utiliser des fonctionnalités de plate-forme ou des techniques éprouvées pour protéger les données.

• Vérifiez les autorisations au niveau du portail. Vous n'avez pas nécessairement besoin de transmettre le contexte de sécurité des utilisateurs au serveur principal pour vérifier les autorisations. Dans un système distribué, ce n'est d'ailleurs souvent pas la meilleure solution. Les vérifications à effectuer au niveau du portail consistent à autoriser les utilisateurs au premier point d'authentification (par exemple, dans l'application Web sur le serveur Web) et à déterminer les ressources et les opérations (potentiellement fournies par les services en aval) auxquelles les utilisateurs doivent être autorisés à accéder.
  Si vous élaborez des stratégies d'authentification et d'autorisation solides au niveau du portail, il n'est pas nécessaire de déléguer le contexte de sécurité de l'appelant initial jusqu'au niveau des données des applications.

• Partez du principe que les systèmes externes ne sont pas sécurisés. Si vous ne gérez pas vous-même la sécurité, ne supposez pas que celle-ci est assurée pour vous.

• Diminuez la surface d'exposition. Évitez de dévoiler des informations si cela n'est pas nécessaire. Vous risquez en effet d'ouvrir des portes susceptibles de générer des failles supplémentaires. Par ailleurs, gérez les erreurs de manière appropriée : ne divulguez pas plus d'informations qu'il n'est nécessaire lorsque vous renvoyez un message d'erreur à l'utilisateur final.

• Échec de l'application et mode sécurisé. En cas d'échec de l'application, assurez-vous que les données sensibles sont toutes protégées. En outre, ne fournissez pas trop de détails dans les messages d'erreur. N'incluez pas d'informations susceptibles de permettre à un utilisateur malveillant d'exploiter une faille de votre application. Rédigez les informations d'erreur détaillées dans le journal d'événements Windows.

• Souvenez-vous que la sécurité générale d'une application dépend toujours de son lien le plus faible. La sécurité doit être prise en compte à tous les niveaux d'une application.

• Si vous n'utilisez pas un élément, désactivez-le. Vous pouvez supprimer des points d'attaque potentiels en désactivant les modules et les composants qui ne sont pas nécessaires à votre application. Si votre application n'utilise pas le cache de sortie, par exemple, désactivez le module de cache de sortie ASP.NET. Si une faille concernant la sécurité est détectée par la suite dans le module, votre application ne sera ainsi pas menacée.

Haut de page

Résumé

Ce module vous a proposé les informations fondamentales vous permettant de vous préparer pour les autres parties du présent guide. Assurez-vous de bien comprendre les concepts et les principes clés présentés dans ce module, car ils seront souvent utilisés et mentionnés dans les pages qui suivent.

Haut de page