Contact

← Retour aux cas d'usage

Cas d'usage #04

Cybersécurité et RGPD : protéger sans casser le référencement

Une attaque de plus de 2 milliards de requêtes bloquée, une surface d'attaque réduite, des traceurs qui attendent le consentement, et des robots légitimes qui passent.

Contexte

Grand groupe international B2B, soumis au RGPD et à NIS2. Écosystème classique : CDN et WAAP devant les sites publics, fédération d'identité avec authentification forte, plateforme de gestion du consentement, équipe sécurité dédiée. Les sites publics doivent rester rapides, indexables et conformes.

Schéma : CMS d'édition interne, génération statique, stockage d'origine, WAAP et CDN, visiteurs

Ce que j'ai fait, étape par étape

1. Bloquer l'attaque

Une attaque par déni de service de plus de 2 milliards de requêtes a été bloquée par le WAAP, sans interruption visible pour les visiteurs. La protection volumétrique se prépare avant l'attaque, pas pendant.

2. Démêler sécurité et performance

Un réglage WAF/CDN provoquait des boucles d'authentification et empêchait la mise en cache. Correction des règles de cache et de session avec l'équipe sécurité, sans affaiblir la protection applicative.

3. Réduire ce qui est exposé

Architecture cible : back-office d'édition non accessible depuis Internet, site public statique derrière répartiteur de charge, WAAP et CDN, accès administrateur par authentification forte plutôt que par filtrage d'adresses IP.

4. Rendre le consentement réel

Vérification qu'aucun traceur analytique ou tag tiers ne se déclenche avant accord explicite, via la plateforme de consentement et le mode de consentement avancé.

5. Laisser passer les robots légitimes

Les règles anti-bots bloquaient aussi les moteurs de recherche. Coordination entre sécurité, agence et marketing pour les autoriser sans ouvrir la porte au reste.

6. Appliquer un référentiel

Authentification forte et SSO obligatoires, durcissement du CMS, gestion centralisée des secrets, en-têtes de sécurité HTTP, protections contre les injections et le XSS, tests réguliers.

Pièges et décisions

  • Le filtrage par adresse IP ne remplace pas un contrôle d'accès : il cède dès qu'une personne se connecte depuis un autre lieu ou un autre réseau.
  • Une règle WAF ajoutée en urgence en production, sans test préalable, provoque l'incident suivant.
  • Un bandeau de consentement mal branché laisse partir des données avant l'accord du visiteur. Le défaut ne se voit qu'en inspectant les requêtes réseau.

Résultat

Surface d'attaque réduite, cache rétabli, consentement vérifiable, indexation débloquée. Protection et référencement cessent de s'opposer. Vous souhaitez en savoir plus ? Contactez-moi.

Stack et méthodes

Akamai (CDN/WAAP)
Google Cloud Armor
SSO / MFA
CMP
Consent Mode v2
RGPD
NIS2
← Cas précédent : Refonte de CMS : du CMS optimisé au site statique → Cas suivant : MarTech et data : mesurer juste, dans les règles

Un sujet proche du vôtre ?

Me contacter