Nous avons construit de zéro l'infrastructure AWS d'une plateforme de santé (SaaS) aux États-Unis. L'application tourne sur Elastic Beanstalk avec Nginx. Elle est protégée par un filtre de trafic de 23 règles et par un script automatique qui bloque les scanners. Des requêtes prêtes à l'emploi sur les journaux montrent ce qui se passe.
Projet réel, sans nom
| Secteur | Santé et cliniques · SaaS et technologie |
|---|---|
| Défi | Confiance et crédibilité |
| Contexte de décision | Supervisé |
| Complexité | Élevée |
| Service | Mise en place cloud |
Quand une application gère des données sensibles, comme des données de santé, c'est l'infrastructure qui les protège chaque jour. Cette étude montre dans quel ordre cette protection a été mise en place, pourquoi chaque élément a été choisi, et comment même une personne qui n'est pas ingénieur peut lire ce qui se passe.
Une plateforme de santé proposée comme logiciel en ligne (SaaS) aux États-Unis avait besoin d'une infrastructure dans le cloud, bâtie de zéro. Il n'existait ni environnement, ni filtre, ni requête prête sur les journaux. Un produit de santé concerne des personnes et leur santé. L'infrastructure devait donc être juste dès le premier jour.
Nous avons pris en charge le côté cloud : monter l'environnement où l'application tourne, le protéger, et donner à l'équipe de la plateforme un moyen simple de le surveiller.
Partir de zéro a un avantage : rien d'ancien n'est à modifier. Cela demande pourtant de l'attention, car chaque choix est fait en conscience et consigné par écrit.
Toute application ouverte sur Internet reçoit des tests automatiques quelques heures après son lancement. Des programmes demandent des milliers d'adresses pour trouver un fichier de réglages oublié, un panneau d'administration ou un vieux script. L'OWASP décrit cet abus automatisé comme un bruit constant autour des applications web (voir les Sources).
Pour un produit de santé, chacun de ces tests pèse plus lourd que pour une simple page de présentation. L'infrastructure devait donc faire deux choses. D'abord, arrêter le trafic nuisible avant qu'il n'atteigne l'application. Ensuite, montrer clairement ce qui se passe, pour qu'une personne repère ce que les règles n'ont pas prévu.
Quatre contraintes ont guidé la plupart des choix. La solution devait tourner sur AWS. Elle devait être bâtie de zéro, d'une façon que comprenne facilement la personne qui la maintiendra plus tard. Le filtre devait laisser passer les vrais utilisateurs, même sur les points d'inscription complexes, où les requêtes ressemblent facilement à une attaque.
La quatrième contrainte concerne ce que nous publions. Cette page décrit uniquement ce qui a été mis en place, sans prétendre à des certifications et sans données du client.
Une telle mise en place fonctionne quand trois choses travaillent ensemble. Le filtre est réglé pour cette plateforme précise : les clients passent, les attaques s'arrêtent. Les journaux se lisent facilement pour l'équipe. La protection agit toute seule, sans attendre que quelqu'un pense à réagir.
Il aide aussi que chaque règle ait un but connu. Une longue liste copiée d'un modèle gêne l'équipe : quand un vrai utilisateur est bloqué, on ne voit pas quelle règle en est la cause. Avec des règles expliquées, la cause se trouve vite et le filtre reste actif.
Enfin, le blocage a une durée. Une adresse bloquée pour toujours peut appartenir plus tard à des utilisateurs innocents, car beaucoup d'adresses sont partagées ou réutilisées. Un blocage limité dans le temps protège la plateforme sans enfermer dehors de vraies personnes.
Nous avons travaillé par couches, de l'extérieur vers l'intérieur, pour que chaque couche attrape ce que la précédente laisse passer. D'abord l'hébergement de l'application, puis un filtre devant elle, puis un script automatique qui lit les journaux. Enfin, des requêtes prêtes pour la personne qui surveille la plateforme.
Hébergement de l'application sur AWS Elastic Beanstalk, avec Nginx devant le serveur de l'application.
Pare-feu pour applications web (AWS WAF), c'est-à-dire un filtre qui arrête le trafic nuisible, avec 23 règles.
Un petit script automatique (AWS Lambda en Python) qui lit les journaux toutes les 3 minutes, repère les scanners et les bloque.
Des requêtes prêtes dans Amazon CloudWatch Logs Insights, pour que l'équipe lise les journaux sans écrire les requêtes à chaque fois.
Les 23 règles couvrent une limite de requêtes par IP, une restriction géographique et des groupes de règles prêts, maintenus par AWS : menaces courantes, données malveillantes connues, réputation des IP d'Amazon, IP anonymes, WordPress, PHP. D'autres règles bloquent la recherche de fichiers comme .env, .git, node_modules ou phpMyAdmin. Elles bloquent aussi les fichiers ou paramètres PHP que la plateforme n'utilise pas, ainsi que les clients automatisés. Il existe encore des listes d'IP autorisées et bloquées, avec des exceptions pour les points d'inscription complexes.
Les décisions comptent plus que la liste des outils. Quatre se distinguent : des exceptions étroites pour l'inscription, des blocages qui s'allongent peu à peu, des règles au but clair, des requêtes prêtes sur les journaux avant d'en avoir besoin. Chacune rend la plateforme plus sûre, sans compliquer la vie des vrais utilisateurs.
Des exceptions pour l'inscription. Les points d'inscription complexes envoient des requêtes qu'un filtre strict juge suspectes. Nous avons exclu uniquement ces points de certaines règles précises. Toutes les autres règles sont restées actives sur l'ensemble de la plateforme.
Des blocages qui s'allongent peu à peu. La Lambda ne bloque pas une adresse pour toujours dès le premier signe. La durée du blocage augmente quand le comportement se répète : une erreur isolée expire vite, un scanner obstiné reste dehors plus longtemps.
Des règles au but clair. Chaque règle dit ce qu'elle arrête. Si un utilisateur est bloqué, la cause se trouve en quelques minutes.
Des requêtes prêtes à l'avance. Les requêtes dans Logs Insights couvrent les erreurs 4xx et 5xx, les redirections, les IP suspectes, les blocages. Lors d'un incident, les premières questions sont presque toujours les mêmes. Quand la réponse est prête, l'équipe gagne du temps au moment où cela compte.
Nous avons utilisé uniquement les services AWS dont la plateforme avait besoin, sans outils en plus. La technologie suit les besoins.
Le résultat est un ensemble de mécanismes qui travaillent ensemble. La plateforme tourne dans un environnement stable et défini. Le trafic nuisible rencontre un filtre avant d'atteindre l'application. Les scanners qui passent les premières règles sont repérés par le script en quelques minutes. L'équipe voit ce qui se passe grâce aux requêtes prêtes.
Nous ne publions pas de chiffres, comme le nombre d'attaques arrêtées ou les temps de réponse, car nous n'avons pas de données approuvées pour la publication. Une telle mise en place soutient la fiabilité de la plateforme pendant des années, parce qu'elle rend les problèmes visibles tôt. La sécurité est un travail continu : elle se maintient et s'améliore avec le temps.
Si vous préparez quelque chose de semblable, la page sur la mise en place AWS explique comment nous travaillons. L'article comment une application est protégée des scans automatisés explique l'idée en termes simples.
Quatre services ont été utilisés : AWS Elastic Beanstalk pour héberger l'application avec Nginx devant, AWS WAF pour le filtre de trafic, AWS Lambda en Python pour le blocage automatique, et Amazon CloudWatch Logs Insights pour lire les journaux. Seul ce dont la plateforme avait besoin a été ajouté.
C'est un projet réel. L'identité du client reste privée, tout comme ses données. Nous décrivons ici, en termes généraux, ce que nous avons mis en place, pour que vous puissiez juger l'approche.
Le filtre et le blocage automatique réduisent le bruit, arrêtent les attaques faciles et rendent visible ce qui reste. Aucune application n'est totalement invulnérable. C'est pourquoi les journaux avec leurs requêtes prêtes faisaient partie du travail dès le début.
Oui. La même méthode vaut pour toute plateforme web, dans tout secteur. Voyez comment nous travaillons sur la page plateformes SaaS et applications métier, ou démarrez un projet en décrivant vos besoins.
Les agents qualité et sécurité sont notre propre outil. Il contrôle chaque build sur un parcours fixe : QA, UX, sécurité, pentest, SEO/AEO, audit technique avec Lighthouse, revue de code.
Le site d'une plateforme SaaS rend le produit compréhensible quand le contenu est séparé par public et par niveau de détail, avec les cas d'usage avant la liste des fonctions.
Praion AI est notre propre plateforme SaaS, où chaque client a sa propre base de données. Trois applications (Lead Concentrator, Content Studio, Product Manager) partagent les comptes, les profils d'entreprise et un portefeuille de crédits IA.
Envoyez une demande de projet ou vérifiez gratuitement votre site actuel. Nous lisons chaque message nous-mêmes.