Christophe GUYARD
Désormais, la disponibilité du service repose directement sur la disponibilité des applications. Garantir la disponibilité des applications fait donc aujourd'hui partie des priorités nouvelles et fortes des entreprises. Afin d'assurer cette disponibilité, les responsables informatiques déploient différents types de solutions : Haute Disponibilité, Gestion des Risques ou encore des dispositifs de reprise après sinistre. Quoi qu'il puisse arriver, les applications doivent rester accessibles et opérationnelles afin d'assurer l'activité de l'entreprise. Il est de la responsabilité d'une organisation de prendre toutes les mesures et de souscrire à toutes les mesures lui permettant de garantir cette disponibilité. De même, toute faille pouvant mettre en défaut l'utilisation quotidienne des applications doit être anticipée. Ces précautions peuvent apparaître comme de nouvelles contraintes mais heureusement leur bénéfice va bien au-delà d'une simple assurance. Bénéficier d'une architecture de déploiement applicatif sécurisé s'avère de fait être un avantage stratégique pour l'entreprise, qui capitalise ainsi sur la satisfaction des utilisateurs, qu'ils soient employés, partenaires ou clients.
Performance, disponibilité et sécurité
• Performance
Garantir les performances dépend pour une large mesure de l'existence d'une infrastructure supportant les hauts débits. Cependant, surdimensionner l'architecture s'avère une piste facile mais coûteuse. Une approche plus rationnelle doit s'appuyer sur une optimisation répartie à plusieurs niveaux. D'une manière générale, la suppression ou délocalisation des tâches effectuées par le serveur applicatif et qui ne relèvent pas de sa vocation première (off-loading), constitue un principe de base à la fois pour la performance et pour l'extensibilité.
• Disponibilité
Une fois le niveau de performance requis atteint, celui-ci doit être protégé contre différents problèmes potentiels : panne matérielle, surcharge de trafic... Une gamme de solutions adresse de façon graduée ce besoin de disponibilité : Pass Through, Redundancy, Fail-over, Load Balancing, High Availability... En dernière extrémité, les solutions de Back Up et de Disaster Recovery viennent compléter ces dispositifs.
La Haute Disponibilité est une problématique connue, transposée au niveau de la couche 7 elle demande à ce que certaines particularités soient prises en compte. Par exemple, le suivi des sessions ou encore le besoin de transparence de bout en bout sont des caractéristiques qui doivent conditionner des mécanismes tel que l'équilibrage de charge entre serveurs d'applications.
• Sécurité
Les objectifs de performance et de disponibilité sont relativement faciles à comprendre et donc rarement sources de confusion. Par contre, la diversité de la couche applicative complexifie sa sécurité et en multiplie les implications. Une première et fondamentale question est de se demander quel est l'objectif premier d'une sécurité applicative? Est-ce uniquement le blocage des attaques ? Une telle approche resteraît simpliste au regard de la complexité du problème. Tout d'abord les attaques ne sont pas le seul danger auquel il faut faire face. Les robots, scanners et aspirateurs de site, tout comme les utilisateurs malicieux ou la navigation en dehors des liens, sont autant de mécanismes ou de comportements qui peuvent s'avérer très dangereux pour le processus applicatif.
Par ailleurs, la très grande majorité des applications n'est pas exempte de vulnérabilité, d'absence
de contrôle ou de carence de conformité avec une réglementation. La sécurisation d'un processus de mise à disposition d'une application, quelle que soit celle-ci, est une tâche qui comprend beaucoup plus que la prévention des attaques et qui impacte de nombreux domaines.
Une Politique de Sécurité Applicative
Vue sous l'angle produit, la mise en œuvre d'une politique de sécurité est le rôle d'un dispositif de type pare-feu (Firewall). Créés avec l'apparition de la sécurité réseau, les Firewalls appliquent une politique de sécurité sur les flux entrants et sortants. En d'autres termes on peut représenter une politique de sécurité réseau comme une matrice de flux. En revanche, définir une politique de sécurité au niveau applicatif apparaît comme beaucoup plus difficile. La politique doit-elle inclure tout ce qui est susceptible d'être autorisé ? Cette approche, dite positive, s'avère vite longue, complexe techniquement, et très consommatrice de ressources humaines. La politique doit-elle alors être basée sur tout ce qui est interdit? Cette deuxième méthode, dite négative, pose aussi de nombreux problèmes puisque les attaques applicatives, et encore plus les comportements anormaux, ne peuvent être connus à l'avance, et encore moins référencés.
-Voici un exemple typique de sécurité en environnement applicatif : certaines requêtes, bien que légitimes parce que mises en œuvre par l'application, peuvent malgré tout comporter un risque parce que basées sur une programmation faible. On ne peut cependant les interdire sans que ce soit toute l'application elle-même qui soit bloquée. Que doit alors faire l'administrateur sécurité confronté à de telles requêtes ? Le problème, on le voit, n'est pas simple et réclame donc des réponses innovantes.
Comprendre l'application, son processus métier, identifier ses ressources les plus sensibles et localiser les vulnérabilités potentielles ? Quels sont les types de flux de données? Comment l'authentification est-elle réalisée? Voici les questions-clés que doivent se poser les administrateurs de sécurité applicative. D'une part elles dépassent la simple défense contre les attaques et d'autre part elles démontrent que la protection d'un Firewall classique reste sans effet quand on parle de transactions.
Une politique de sécurité applicative repose sur la détection de toute utilisation anormale de l'application qui pourrait induire des résultats non anticipés par le programmeur. Cette politique consiste à définir un profil d'utilisation licite de l'application tout en mettant en évidence ses parties les plus sensibles ou vulnérables. Différents mécanismes de détection, complétés par un ensemble varié de modes de réponse, pourront alors bloquer, contrôler ou signaler toute utilisation anormale de l'application et tout événement potentiellement dangereux. Des mécanismes de détection proactifs doivent la prémunir contre les fuites d'information, la corruption des données ou les indisponibilités applicatives. Ce profil de l'application et de son utilisation doit également être complété par un ensemble de directives représentant les obligations (administratives, légales...) auxquelles doit répondre l'Entreprise. En effet, quelle que soit la nature de l'obligation réglementaire - interne à l'organisation, relative au secteur d'activité ou légale - seule une stricte garantie de conformité va octroyer à l'application le niveau de confiance nécessaire pour en faire un outil opérationnel fiable et utilisé.
Ainsi, au niveau applicatif, la sécurité doit adresser l'application, son utilisation et sa mise à disposition. En d'autres termes elle doit apporter la confiance nécessaire pour que les applications remplissent le rôle stratégique que les managers en attendent.
