Quand une agence web devient mature, elle améliore et met en place tout plein de process, dont l’un consiste à monter ce que l’on appelle dans le jargon un serveur de préprod, ou un staging comme moi j’aime à le dire. Ce serveur sert à tester une mise à jour qu’on a l’intention de déployer, ou encore l’ajout d’une nouvelle fonctionnalité, pour ne citer que ces deux éléments.

Et ça va peut-être te paraître paradoxal, mais malgré le fait que ce soit un environnement qui n’a pas vocation à être public, il y a moins de sécurité. Il n’y a clairement pas les restrictions d’une production. Dans certains cas, on est amené à éditer le code en direct sur cet environnement et à afficher des données de debug, comme tout bon développeur d’agence de com. qui se respecte (ne nous jugez pas) ! Mais dans la plupart des cas, ces environnements sont propres et contiennent la dernière version du code source que l’on souhaite déployer, donc a priori cela ne pose pas de réel problème. Enfin ça, c’est ce qu’on pourrait croire.

La mise en place de ces environnements de test a entraîné quelques petits soucis assez gênants.

Le premier problème, c’est que nos stagings se faisaient indexer par Google. Cela affichait clairement les URLs de staging, et nos environnements de développement devenaient en quelque sorte des surfaces d’attaque.

Si le duplicate content aurait pu être notre seul souci, le pire a été que, pour certains sites, le staging se faisait parfaitement indexer tandis que le site de production disparaissait des moteurs de recherche. En effet, lorsqu’on clonait des bases de données de production en staging, on cochait bien la case « Demander aux moteurs de recherche de ne pas indexer ce site » (propre aux installations WordPress), mais dans certaines situations, on était amené à renvoyer la DB de staging en production (avec la mauvaise option). C’est typiquement le genre de situation qui se produisait quand il n’y avait pas de modification en production et que tout le travail de mise à jour se faisait en staging, contenu y compris.

Lorsque je suis devenu Lead Dev, j’ai été en quelque sorte chargé du contrôle qualité et du bon fonctionnement du pôle dev et des projets web, donc cela faisait pleinement partie de mes prérogatives ! J’ai mis en place certaines procédures pour contrôler, d’une part, que les stagings ne se faisaient pas indexer et, d’autre part, que les sites en production étaient bien indexables. Malgré cela, il y avait toujours un site ou l’autre qui passait à travers les mailles du filet, et je ne pouvais pas avoir un œil partout, ce qui m’empêchait de garantir la résolution de ce problème.

Quelques choses ne marchaient pas, et je devais trouver une solution ! J’ai donc décidé de prendre ce problème à bras le corps.

L’idée que j’avais, c’était de faire passer tout le trafic à travers un serveur de relais qui, en fonction de l’URL ou du chemin d’URL, était capable de bloquer ou d’autoriser l’accès. De cette façon, peu importe l’option d’indexation configurée dans la base de données, c’est l’origine de la connexion internet qui décide si l’accès au site est autorisé ou non. Cela résolvait tous les problèmes et il n’y avait plus besoin de contrôle humain. Sur le papier, c’était parfait.

Je devais donc installer un logiciel capable de faire l’intermédiaire, c’est-à-dire d’intercepter la requête, de demander la page web au vrai serveur, et ensuite de retourner la réponse au client. Et bien évidemment, un programme où je peux configurer des règles de restriction afin de bloquer l’accès à nos stagings.

Comme tu t’en doutes, ce système existe belle et bien. Il porte le nom de reverse proxy et il en existe beaucoup. Les plus connus sont sans doute HAProxy ou Nginx, même si maintenant ça tend à se diversifier. Et c’est bien évidemment ce que j’ai décidé de mettre en place.

Il y a quelques années, j’avais participé à une conférence Docker dans laquelle était présenté Træfik, un reverse proxy moderne, et je m’étais dit que c’était une belle opportunité pour me former sur la technologie et, par la même occasion, résoudre une problématique de l’agence.

Mais était-ce que Træfik était en mesure de solutionner notre problème ? C’était un peu ce qui allait définir si je montais sur cette techno ou si j’en choisissais une autre. Et effectivement, d’après les recherches que j’avais menées, nous pourrions restreindre l’accès à notre serveur en fonction du chemin d’URL ou de l’adresse IP. Cela semblait assez flexible, je pourrais détecter les URL qui commençaient par « stg » ou « dev », définir que si l’IP n’était pas la mienne, alors renvoyer dans un mur (un service qui répondait 403 par exemple), et c’était exactement ce que je voulais faire !

Bon, je ne te cache pas qu’au début cela m’a paru imbitable ! D’ailleurs, encore aujourd’hui, je trouve la documentation très mal faite. Par exemple, que ce soit dans l’overview ou l’installation, les prérequis seraient d’avoir un environnement Kubernetes ou Docker alors que ce n’est pas du tout obligatoire. Dans mon cas, je voulais être au plus proche de mon infrastructure, c’est-à-dire faire en sorte que ça marche sur un Linux avec le moins de surcouches nécessaires, je voulais pouvoir maîtriser et comprendre 100 % de la chaîne.

Et je dois rendre à Xavki ce qui appartient à Xavki ! C’est un formateur sur Youtube qui a fait une formation sur Træfik et qui explique justement comment faire l’installation en mode binaire, donc sans le prérequis Kube/Docker. Pour moi, ça a été le point de départ de ma formation et la personne qui a su me démystifier Træfik dans les premiers instants. J’aimerais le remercier au travers de cet article !

Avant de pouvoir présenter l’idée de la solution à binsfeld, je voulais être sûr de moi, obtenir un niveau de connaissance suffisamment élevé et pouvoir maîtriser la mise en place de A à Z, en tout cas pour nos premiers besoins, et ne pas imposer à l’équipe plus de contraintes que nous n’en avions déjà !

Depuis près d’un an maintenant, j’étudie Træfik et l’expérimente de manière plus ou moins intensive. Il y a quelques mois, j’ai même eu l’opportunité de convier l’ensemble de l’équipe et de faire ma première présentation/formation sur le thème de la « cybersécurité via reverse proxy », qui, je le pense, aura été le tremplin pour son adoption au sein des équipes. Je dois avouer que je suis plutôt fier de cela !

La mise en place s’est faite en deux temps.

Dans un premier temps, j’avais proposé d’installer un reverse proxy de test pour y faire passer le trafic de quelques sites web et apprendre sur le tas. Mettre les mains dans le cambouis reste, selon moi, le meilleur moyen d’apprendre.

Honnêtement, les développeurs s’en sont très bien sortis. Ils ont mis en place différentes configurations de routage alors que l’outil nécessitait une base théorique et une certaine rigueur dans la syntaxe.

La seconde phase a consisté à déployer le premier dispositif complet de reverse proxy pour résoudre notre problème initial, et avec le recul, je dois dire que cela a totalement résolu notre problématique.

Bon, et où est-ce que tout cela m’amène ? Dans la même lignée de tout ce que j’entreprends, j’ai décidé de partager ma vision des choses dans le domaine du reverse proxy, et particulièrement sur Træfik, car je trouve que c’est un outil formidable qui offre beaucoup de possibilités.

Je vais donc ouvrir une nouvelle section sur mon blog, entièrement dédiée à Træfik, où je vais reposer les bases, expliquer à quoi sert un reverse proxy et donner des exemples concrets. J’écrirai une série d’articles techniques sur comment l’installer et l’utiliser, en gardant toujours ma vision de faire les choses simple. Bien évidemment, je partagerai aussi mes petits trucs et astuces, car croyez-moi, je n’arrête pas de retourner l’outil dans tous les sens et il y a énormément de possibilités !

J’espère donc vous avoir accroché sur le sujet et je vous donne rendez-vous dans un de mes futurs articles, qui parlera de reverse proxy et sans doute de Træfik !