Le problème
Pourquoi fermer les ports ne suffit plus
L'approche classique du durcissement d'infrastructure consiste à scanner des plages d'adresses IP pour fermer les ports inutilisés. C'est une vision incomplète. Dans la majorité des parcs web et applicatifs, l'inventaire des actifs exposés est biaisé par des sous-domaines oubliés, des environnements de recette temporaires rendus accessibles par erreur et des règles de pare-feu obsolètes.
Les mesures publiées montrent les limites de cette approche.
- L'exploitation d'une vulnérabilité est devenue le premier vecteur d'accès initial aux compromissions : 31 %, contre 20 % l'année précédente, devant l'abus d'identifiants tombé à 13 % (Verizon, 2026 Data Breach Investigations Report, figure 10, n = 20 023).
- La correction ne suit pas : 26 % des vulnérabilités critiques du catalogue CISA ont été entièrement corrigées en 2025, contre 38 % un an plus tôt, avec un délai médian de 43 jours jusqu'à la résolution complète (même source).
- L'accès distant est devenu une marchandise : 44 % des types d'accès revendus par les courtiers d'accès initial (initial access brokers) sont des connexions VPN, suivies de près par les accès bureau à distance (même source, figure 49).
- L'exposition directe d'outils d'administration reste massive : 26 % des organisations laissent une base MySQL joignable depuis Internet, 16 % une base Postgres, 8 % une interface phpMyAdmin, et 60 % au moins une console d'administration web (Intruder, 2026 Attack Surface Management Index, 3 000 organisations sur douze mois).
Pour réduire la surface d'attaque de manière pérenne, il ne s'agit pas seulement d'empiler des règles de filtrage. Il faut supprimer la capacité même des attaquants à contacter directement le serveur d'origine. Dès lors qu'une adresse IP publique répond aux requêtes entrantes, l'infrastructure reste vulnérable au contournement des protections placées en bordure de réseau.
Le cadre de lecture
Le cadre d'exposition : l'origine, l'exposé et l'inventaire
La réduction de la surface d'attaque sur Cloudflare s'articule autour de trois éléments distincts.
01
L'infrastructure d'origine
Les serveurs physiques, instances cloud et conteneurs qui hébergent la logique applicative et les données.
02
Le périmètre volontairement exposé
Les points d'entrée publics (interfaces web, API) qui doivent rester accessibles aux clients et visiteurs légitimes.
03
La visibilité continue
La capacité à contrôler ce qui est réellement configuré et accessible depuis l'extérieur pour éliminer les erreurs d'exposition.
Verrouiller l'origine
Les trois niveaux de verrouillage de l'origine
Si un attaquant découvre l'adresse IP publique d'un serveur d'origine, il peut la frapper en direct. Les protections WAF, anti-DDoS et Bot Management placées sur Cloudflare sont alors totalement hors circuit. Trois niveaux de verrouillage permettent de supprimer ce risque.
Niveau 1 : restreindre les plages IP (ACL réseau)
Cette méthode consiste à n'autoriser que les blocs d'adresses IP de Cloudflare au pare-feu du serveur d'origine (via iptables, AWS Security Group ou Azure NSG) en automatisant la mise à jour depuis les listes officielles ips-v4 et ips-v6.
Limite : n'importe quel autre client Cloudflare peut encore atteindre votre adresse IP à travers le réseau Cloudflare. L'isolation n'est pas étanche entre comptes clients. Concrètement, un attaquant ouvre un compte, y déclare votre adresse IP comme origine de sa propre zone, et son trafic vous parvient depuis une plage que vous autorisez, sans passer par vos règles WAF puisque ce n'est pas votre zone qui les porte.
Niveau 2 : ACL réseau et Authenticated Origin Pulls (mTLS)
En complément de l'ACL réseau, l'option Authenticated Origin Pulls impose un certificat client mTLS propre à votre zone Cloudflare, vérifié par le serveur web d'origine (via ssl_client_certificate et ssl_verify_client on sous NGINX). Le mode de chiffrement doit être réglé sur Full (Strict) côté Cloudflare, sans quoi la chaîne n'est pas vérifiée de bout en bout.
Bénéfice : ce mécanisme de contrôle par certificat bloque l'abus inter-comptes. Seul le flux provenant de votre propre zone Cloudflare est accepté par l'origine.
Limite : l'origine conserve une adresse IP publique joignable sur le réseau, donc elle continue d'apparaître dans les résultats de scan.
Niveau 3 : Cloudflare Tunnel (zéro flux entrant)
Le démon cloudflared s'exécute directement sur le serveur d'origine et établit des connexions sortantes uniquement vers le réseau Cloudflare, en QUIC par défaut, avec repli en HTTP/2 et plusieurs connexions simultanées pour la disponibilité. Le serveur ne possède plus d'adresse IP publique et n'écoute sur aucun port. Le même tunnel peut publier des routes vers vos plages privées (RFC 1918), ce qui permet à Cloudflare Access et au Cloudflare One Client d'atteindre des ressources internes sans qu'aucune route existe côté Internet.
Bénéfice : le déploiement de Cloudflare Tunnel supprime intégralement la surface d'attaque réseau entrante. L'origine devient totalement invisible aux scans de ports sur Internet.
La matrice
Matrice de protection : ce qui reste exposé et les produits associés
Supprimer l'exposition réseau directe ne signifie pas que l'application est invulnérable. Le flux légitime continue d'emprunter le tunnel. WAAP filtre ce qui arrive, la réduction de surface fait qu'il n'y a rien où arriver.
Ce qui reste exposé, et ce qui reprend la main
Chaque produit reste à la fonction que sa documentation décrit. Aucune ligne extrapolée.
| Vecteur d'exposition | Fermé par Tunnel ? | Produit Cloudflare qui reprend la main |
|---|---|---|
| Scan de ports sur l'IP publique | Oui | Aucun besoin complémentaire |
| Frappe directe en contournement de la bordure | Oui | Authenticated Origin Pulls (si l'IP publique subsiste) |
| DDoS applicatif (HTTP/HTTPS) | Non | DDoS Protection, Smart Shield |
| DDoS volumétrique L3/L4 | Non | Magic Transit, avec Network Flow pour la détection |
| Exploitation de vulnérabilités web / OWASP | Non | WAF, règles managées et virtual patching |
| Attaques par force brute / moissonnage | Non | Rate Limiting |
| Bots automatisés et credential stuffing | Non | Bot Management, Turnstile |
| Abus d'API et failles de schéma | Non | API Shield |
| Scripts tiers malveillants chez le client | Non | Page Shield (exigences PCI DSS 6.4.3 / 11.6.1) |
| Protocoles non-HTTP (SSH, RDP, TCP) | Partiellement | Spectrum, Cloudflare Access |
| Fuite de données sensibles en sortie | Non | Data Loss Prevention (DLP) |
| Usurpation de domaine dans l'email | Non | DMARC Management |
Le détail de cette couche d'inspection est traité dans le cas d'usage WAAP managé. Rester en ligne sous attaque volumétrique fait l'objet du cas d'usage protection anti-DDoS.
Deux modes
Route publique et route privée : une architecture, deux comportements
Un connecteur cloudflared transporte les paquets : il n'inspecte pas le contenu. Un même serveur d'origine peut héberger deux routes distinctes via le même tunnel, avec des modèles de sécurité totalement différents.
| Critère | Route publique | Route privée (ZTNA / SASE) |
|---|---|---|
| Public ciblé | Tout internaute, clients et prospects | Collaborateurs et prestataires désignés |
| Authentification en bordure | Aucune (accès libre) | Obligatoire (fournisseur d'identité et posture) |
| Protocoles gérés | HTTP / HTTPS | HTTP, SSH, RDP, bases de données, TCP |
| Composant de sécurité | WAF, Bot Management, API Shield | Cloudflare Access et politiques Zero Trust |
| Visibilité sur Internet | Nom de domaine public fonctionnel | Écran d'authentification ou ressource masquée |
| Accès côté client | Navigateur web standard | Navigateur ou Cloudflare One Client |
| Périmètre du use case | Traité sur cette page | Traité sur le use case ZTNA |
Dans les deux modes, la surface entrante d'origine est fermée à l'identique. La différence réside dans ce qui garde la porte une fois le flux entré dans le tunnel : sur la route publique, l'inspection applicative fait tout le travail ; sur la route privée, l'identité est validée avant d'atteindre l'application.
Les routes privées relèvent de l'architecture d'ensemble, le SASE managé sur Cloudflare One.
L'inventaire
Audit de configuration avec Cloudflare Security Center
Réduire la surface d'attaque nécessite un suivi continu des configurations pour détecter les dérives d'exposition.
Cloudflare Security Center, via son module Security Insights, analyse l'ensemble des paramètres déclarés dans votre compte Cloudflare : enregistrements DNS, configurations SSL/TLS, règles WAF et politiques Cloudflare Access.
Security Center identifie et alerte spécifiquement sur plusieurs détections clés.
Dangling A / AAAA / CNAME Records
Enregistrements DNS pointant vers une ressource ou une adresse que vous ne contrôlez plus, ce qui expose le domaine à une prise de contrôle de sous-domaine (subdomain takeover).
Unproxied A / AAAA / CNAME Records
Enregistrements DNS pointant directement vers une IP d'origine sans passer par le proxy Cloudflare. La documentation le formule sans détour : Cloudflare ne peut pas protéger cette origine, puisqu'elle est exposée sur l'Internet public.
Unprotected Cloudflare Tunnels
Détection d'une application desservie par un tunnel Cloudflare mais ne disposant d'aucune politique Cloudflare Access associée. C'est précisément le risque d'une route privée publiée par erreur comme une route publique.
Security Insights n'est pas un scanner d'attaque externe couvrant l'ensemble d'Internet : il audite le périmètre déclaré dans votre compte pour garantir qu'aucun actif configuré ne reste vulnérable ou mal protégé. Un serveur monté sur un compte cloud inconnu de la DSI n'y apparaîtra pas.
La frontière
La frontière de la plateforme et le couplage avec le poste
Une posture de sécurité rigoureuse exige de préciser la frontière exacte de la plateforme. Cloudflare protège le transit et l'accès, mais ne remplace pas l'ingénierie système. La plateforme n'assure pas :
- l'application des correctifs de sécurité sur le système d'exploitation et les paquets applicatifs d'origine ;
- la gestion des privilèges des comptes locaux et des accès à privilèges (PAM) ;
- le durcissement des configurations du serveur d'origine (système et intergiciels) ;
- la détection de logiciels malveillants ou la réponse aux incidents directement sur l'hôte (EDR/XDR).
Le point de jonction entre Cloudflare et la sécurité du poste
Si Cloudflare ne remplace pas l'EDR ou le MDM, il s'y intègre directement. Via les contrôles de posture de Cloudflare One, les politiques Cloudflare Access interrogent les agents de sécurité présents sur les postes de travail. La documentation Cloudflare liste notamment CrowdStrike, SentinelOne, Microsoft Endpoint Manager, Tanium, Uptycs, Workspace ONE et Kolide, ainsi qu'un chemin d'intégration personnalisée.
Une règle d'accès peut ainsi refuser l'accès à une application interne si l'EDR du poste signale un niveau de risque élevé ou un agent désactivé. L'outil que Brixio n'exploite pas devient une condition de la règle que Brixio exploite. Dans le même esprit, vos journaux Cloudflare rejoignent votre SIEM par Logpush.
Ces éditeurs sont cités parce qu'ils figurent dans la documentation d'intégration de Cloudflare. Il ne s'agit pas d'une recommandation d'achat.
L'opérateur
L'accompagnement Brixio : audit et exploitation continue
Brixio intervient comme opérateur spécialisé Cloudflare pour concevoir, verrouiller et maintenir l'accès à vos serveurs d'origine.
Audit initial de la surface d'attaque
- Analyse non intrusive de l'exposition réelle de vos IP d'origine, examen des configurations DNS, des certificats et identification des contournements potentiels.
Migration vers une architecture zéro flux entrant
- Déploiement de Cloudflare Tunnel et configuration des certificats mTLS sans interruption de service pour vos utilisateurs.
Exploitation et maintien en condition de sécurité
- Ajustement continu des règles WAF, revue périodique des alertes Security Center et gestion du cycle de vie des accès.
Coordination à la frontière
- Conseil sur la catégorie à mobiliser, les critères de choix et l'articulation avec le plan Cloudflare, puis coordination avec l'équipe interne ou le prestataire qui l'exploite.
Ce que porte la posture permanente de Brixio
Cloudflare
Authorized Service Delivery Partner (ASDP)
Cloudflare seul
aucun autre éditeur en exploitation
ISO 27001:2022
certifié
4 implantations
Luxembourg · Paris · Dubaï · Singapour