Par Philippe Léothaud, CTO de Bee Ware
Cette évolution qui peut sembler paradoxale s’explique en fait par la nécessité ressentie par les entreprises à implémenter les fonctionnalités nécessaires à la prise en compte d’un certain nombre de besoins fondamentaux. Premier besoin et non des moindres, mettre à disposition de leurs clients et partenaires -populations externes non maîtrisées- certains services fournis par leurs systèmes d’information. Mais aussi, rationaliser, intégrer et standardiser leurs applicatifs.
L’ensemble HTTP, Applications Web, Navigateurs Web et Web Services porte la promesse d’une solution à ces problématiques, à la condition que l’on puisse pallier à un certain nombre de déficiences du protocole HTTP inhérentes aux spécifications de ce dernier. Citons entre autres le fait que HTTP ne sait pas gérer de réelles sessions, qu’il est peu voire pas sécurisé et que ce n’est pas un protocole fiable.
Si quelques éléments de réponse ont été apportés au cours du temps, ils ne se sont pas révélés entièrement satisfaisants : SSL par exemple, souvent présenté comme le moyen de sécurisation ultime n’est qu’une solution partielle, en cela qu’il ne permet que l’encapsulation des trames HTTP dans une surcouche et ne résout donc qu’une partie du problème, la sécurisation n’étant opérée qu’au niveau de la couche transport et pas au niveau applicatif, sans même mentionner que les données utiles ne sont évidemment pas sécurisées avant et après leur transport…
La solution à laquelle la communauté IT a abouti ne consiste donc logiquement pas à empiler des couches apportant chacune tout ou partie des fonctionnalités manquantes, non plus qu’à changer le protocole ou à en créer un nouveau (voir le fiasco de HTTP/R), mais à trouver des méthodes pour mettre en place ces fonctionnalités à l’intérieur même des messages HTTP.
Cette nécessaire évolution des modes d’utilisation de HTTP a donc déclenché le transfert d’un certain nombre de fonctionnalités bas niveau vers la couche applicative, notamment le filtrage sécuritaire, le contrôle d’accès, la qualité/garantie de service, le routage et la journalisation.
Nouveaux métiers, nouveaux rôles…
Cela n’est pas sans incidence sur l’organisation au sein des entreprises.
Tout récemment encore, ces problématiques, aujourd’hui donc déportées au niveau applicatif, étaient prises en charge par les personnels système et réseau, or ceux-ci ne connaissent que peu ou pas la couche application, sans même parler du code des applications et de la sémantique des artefacts qu’elles mettent en œuvre. Cette organisation classique, reposant notamment sur le cloisonnement de la Production et des Études, est mise à mal par cette évolution récente, ce déport ajoutant nécessairement de l’adhérence entre le code qui est exécuté et l’environnement dans lequel il s’exécute, ce qui revient à dire que pour décrire (et donc comprendre et faire fonctionner au mieux) ces systèmes il faut prendre en compte de l’information située exactement entre les zones de responsabilité des équipes de Production et de Développement.
Cet impact sur l’organisation des Systèmes d’Information est parfaitement illustré par le besoin ressenti par leurs auteurs de définir de nouveaux rôles lors de la rédaction des spécifications JEE.
Si parmi ces rôles on retrouve des profils classiquement présents dans les SI, comme le Product Provider, l’Application Component Provider, l’Application Assembler, on découvre le Application Deployer dont l’importance se quantifie par le luxe de détails avec lequel ce rôle est défini : pas moins de 10 lignes pour en faire le tour, à comparer aux deux lignes spécifiant par exemple les responsabilités du System Administrator. De même le Tool Provider fait son apparition, tout comme le System Component Provider.
…Nouveaux outils
Si l’évolution des modes d’utilisation du protocole HTTP implique de nouveaux rôles dans l’organisation le besoin se fait également sentir de nouveaux outils qui permettent de mettre en place ces fonctionnalités autrefois gérées aux niveaux 3 et 4 et aujourd’hui déportées vers ce protocole.
Le Reverse Proxy, qui remplit cette fonction en «jouant» le rôle du serveur pour les clients, est un tel point d’extraction, de transformation, d’enrichissement et d’injection d’information dans les messages à destination et/ou en provenance du serveur, à la manière des containers proposés par les serveurs d’application, et permet notamment de filtrer les flux applicatifs.
Il permet également de décharger les serveurs backend (par exemple dans le cas où de la cryptographie entre en jeu), et rend accessible une implémentation graphique et centralisée de l’ensemble de ces fonctionnalités. Il met en outre à disposition des équipes des outils d’assessment qui fournissent de l’information pertinente sur les applications exécutées, évitant ainsi aux administrateurs de devoir descendre au niveau du code source des applications pour mettre en œuvre ces fonctionnalités.
Audits, pen-tests et WAF : la complémentarité
En termes de sécurité par exemple, le Reverse Proxy permet de récolter tous les fruits d’un audit de code et/ou d’un test de pénétration. Ceux-ci sont bien entendu incontournables. Mais que fait-on exactement de leurs résultats ? Et surtout, est-il raisonnablement envisageable de faire ces tests à chaque modification de chaque application ?
Il est courant qu’à la lecture des résultats d’audits et de tests, la consigne soit donnée aux développeurs d’améliorer la qualité du code. C’est encore une fois une démarche incontournable. Mais notoirement insuffisante.
Se reposer uniquement sur les développeurs pour la sécurité applicative est une hérésie. Le turn-over des équipes, le fait que les applications sont parfois développées par des sociétés tierces, souvent dans l’urgence, incite à une prudence raisonnée. A titre d’exemple, Microsoft a une politique de développement sécurisé parmi les plus évoluées. Pourtant…
La partie WAF des Reverse Proxies offre aux personnels responsables de la sécurité un outil leur permettant de définir et d’appliquer des politiques de sécurité correspondant à leurs applicatifs. Bien entendu, les règles de filtrage par défaut des WAF ne sont pas parfaites, même si leur mise en œuvre apporte un niveau de sécurité permettant d’éviter les attaques les plus courantes. En utilisant un WAF avec son paramétrage initial, on est très loin des capacités optimales de ce genre d’outils.
Le résultat des audits de code et des tests de pénétration sont justement un moyen efficace et complémentaire pour créer des règles de sécurité personnalisées permettant d’atteindre un niveau de sécurité optimal avec les WAF.
