Comment gérer la sécurité de vos applications en mode Web ?

La plupart des applications informatiques sont désormais en mode 3-tiers. Quelles sont les problématiques de sécurité associées ? Comment les résoudre ? Nous débutons dans ce billet un dossier consacré à ce sujet.

Ce premier billet va développer les points suivants liés aux couches de sécurité :

1. La sécurité des communications
2. L'authentification
3. L'identification
4. Les contrôles d’accès
5. La signature unique – SSO

1. La sécurité des communications

L’utilisateur qui tente de se connecter doit échanger des données privées avec un serveur. Il est donc indispensable que pendant toute la phase d’authentification, les données ne soient pas échangées en clair, ce qui permettrait de les dupliquer à l’insu de l’utilisateur. Il faut également pouvoir s’assurer que le mécanisme d’authentification est bien « le vrai » et qu’il n’y a pas de passerelle permettant d’espionner l’opération (méthode dite « man in the middle »). Tout ceci suppose l’utilisation de mécanismes de chiffrement fiables (utilisation du protocole SSL, avec clés de chiffrement obtenues auprès de tiers de confiance). Par principe, les navigateurs Web peuvent interroger les services ayant fourni les clés SSL (Verisign, Thawte par exemple) et dans le cas de certificats d’origine douteuse demandent à l’utilisateur de poursuivre ou d’arrêter l’opération.

Source : Kryptotel

2. L'authentification

Il s’agit ici de permettre à un utilisateur de prouver sa bonne foi. Plusieurs méthodes existent :

La connaissance d’un mot de passe associé à son identifiant C’est une méthode simple, mais qui présente l’inconvénient d’être facilement recopiée, sans que le propriétaire légitime puisse s’en rendre compte. La parade consiste à forcer le changement régulier de ce dernier, de donner une durée de validité avant de devoir le ressaisir et à mettre en place des mécanismes permettant de compter le nombre de fois où ce dernier est en cours d’utilisation. Le mot de passe doit être suffisamment complexe (lié au nombre de caractères) pour résister à une attaque intelligente comme par exemple une attaque « force brute »  utilisant des dictionnaires, ou l’utilisation des informations connues de l’utilisateur (date de naissance, prénom des enfants, etc.). Il n’est pas nécessaire que ce soit une chaîne de caractères complexes, impossible à mémoriser, une phrase assez longue en français, avec chiffres et accents, peut suffire. Tout autre mécanisme plus complexe à dupliquer (token, clé RSA, carte à puce, détection biométrique) Pour utiliser le code d’accès, il faut physiquement utiliser  l’objet, et le propriétaire peut se rendre compte d’un vol Contrôle du contexte d’utilisation (un mot de passe où le jeton est spécifique de l’endroit où il est utilisé). On ne peut pas utiliser celui-ci hors d’une zone géographique ou sur n’importe quel ordinateur.

3. Identification

Il s’agit ici d’identifier de manière unique et fiable un utilisateur, quelle qu’ait été sa méthode d’authentification. Une fois l’utilisateur dûment authentifié, on peut lui donner un identifiant interne plus facile à gérer par la machine A cet identifiant sont ensuite attachés des attributs

• Ces attributs peuvent être attachés directement à l’identifiant
• Ces attributs peuvent aussi être associés à l’appartenance à des groupes. Les attributs sont définis au niveau du groupe, et le fait d’appartenir à celui-ci octroie automatiquement les attributs  aux membres

Généralement, la gestion des utilisateurs, de leurs identifiants et des groupes auxquels ils appartiennent, est déléguée à un annuaire LDAP, mais dans les cas simples, on peut trouver un fichier plat, une base de données relationnelle (par exemple la gestion des ressources humaines) ou un classeur excel.

4. Contrôle d’accès

Généralement, on tente de dissocier la partie « organisation des utilisateurs » de la partie « accès aux ressources d’une application :

• Plusieurs ressources peuvent utiliser les mêmes définitions des utilisateurs et l’appartenance à tel ou tel groupe
• On doit pouvoir changer (ajouter/supprimer) des groupes sans avoir à modifier l’annuaire de l’entreprise

Le contrôle d’accès utilise donc les informations des utilisateurs, mais doit les coupler avec sa connaissance des applications.

• On définit donc des règles donnant des droits d’accès à des ressources (consultation, création, suppression, administration) en partant des attributs des utilisateurs
• On a donc ici une « base de données » des droits d’accès ressource par ressource : ce sont les ACL (Acces Control List). Cette base de données pouvant prendre n’importe quelle forme (annuaire LDAP, fichier excel, base relationnelle, etc...). Pour chaque ressource, l’administrateur de celle-ci devra indiquer quels attributs de l’utilisateur sont pertinents pour limiter les accès
• Comme un utilisateur peut posséder de nombreux attributs, potentiellement contradictoires, un mécanisme d’arbitrage est généralement inclus dans le contrôle d’accès pour décider des droits in-fine, en se basant sur une logique combinatoire des divers attributs.

Exemple d'Access Control List

Le contrôle d’accès peut se baser sur plusieurs sources d’authentification et d’identification

• Généralement, il n’y a qu’un seul annuaire définissant les utilisateurs et les groupes
• L’utilisateur peut avoir plusieurs mécanismes pour s’authentifier (mot de passe ou token), voire authentification native sur Windows via un serveur Kerberos Domain Controller
• Mais l’utilisateur peut exister à plusieurs endroits avec des mots de passe différents (exister dans plusieurs annuaires à la fois)
• Il est alors nécessaire d’arbitrer entre ces différentes méthodes
  • Toutes doivent être valides pour que l’utilisateur soit accepté
  • Une méthode est « suffisante » et on s’arrête dès que la première a accepté
  • Une méthode est suffisante, mais on teste toutes les autres
  • En fonction des résultats, on peut se retrouver avec des attributs et des droits potentiellement contradictoires venant de chaque source ayant répondu favorablement, et de nouveau il faut une logique combinatoire pour déterminer les droits in-fine.

Pour éviter de demander à chaque fois à l’utilisateur de taper un mot de passe, le contrôle d’accès fabrique un jeton de session basé sur la date, l’identifiant de l’utilisateur et d’autres informations (adresse IP, informations du poste utilisateur, etc.)  et doté d’une durée de vie. Ce jeton est ensuite vérifié.

• Si le jeton n’existe pas, est invalide ou périmé, l’utilisateur est renvoyé vers le serveur d’authentification et un nouveau jeton est fabriqué
• Dans les applications Web, ce jeton est transmis à l’utilisateur qui le conserve dans la mémoire de son navigateur sous forme de « Cookie » que le serveur peut demander et/ou comme information dans les « HTTP_Headers » passés à chaque requête.

Le contrôle d’accès dispose de moyens pour invalider un jeton ou le supprimer

• Par la durée de vie
• Par un changement des caractéristiques ayant servi à fabriquer le jeton (répudiation)
• Par une demande explicite « log-off » de l’utilisateur.
• Généralement, l’utilisation de l’authentification Native Windows ne permet pas le log-off, le serveur Kerberos est considéré comme une ressource suffisante, et tant que l’utilisateur est connecté sur son poste, le jeton ne peut être invalidé.

5. Signature unique – SSO

Dans le cas général, chaque ressource gère ses méthodes d’accès (utilisateurs et droits) et s’enregistre donc auprès du contrôle d’accès. Il apparaît  intéressant de pouvoir mettre en commun la gestion des droits pour plusieurs ressources, on parle alors d’authentification unique. La première ressource qui est accédée, ne trouvant pas de jeton valide envoie l’utilisateur s’authentifier et se faire fabriquer un jeton. La même ressource, ou une autre ayant mis son contrôle en commun avec la première, constatant que le jeton est valide accepte l’utilisateur sans autre contrôle supplémentaire. Cette mise en commun suppose que toutes les ressources aient la même définition des utilisateurs et des droits associés. La mise en commun du mécanisme d’authentification, suppose également que l’invalidation du jeton est commune, quelle que soit la ressource qui demande le log-off, il est effectif pour toutes les autres.

Ce premier billet s'est concentré sur les aspects suivants de la sécurité :

1. La sécurité des communications
2. L'authentification
3. L'identification
4. Les contrôles d’accès
5. La signature unique – SSO

Dans un prochain billet, nous aborderons plusieurs produits Oracle et non-Oracle traitant certains des points abordés ici. ----------------------------------------------------------------------------------------------------------------------------------- Vous souhaitez en savoir plus sur l'amélioration de la sécurité sur vos environnements ? Contactez-nous ici pour de plus amples informations.