Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Christophe Guyard, Bee-Ware : sécuriser le déploiement des applications

septembre 2008 par Christophe Guyard, CEO de Bee-Ware

Avec le temps les applications Web pénètrent de plus en plus profondément l’activité de l’entreprise. Elles prennent un rôle stratégique et deviennent
un élément critique et vital dans le fonctionnement quotidien de toute
organisation moderne. 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 ouvre 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 ouvre 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.


Voir les articles précédents

    

Voir les articles suivants