Cloudflare pour les entreprises : DNS, WAF, protection DDoS et réglages à ne pas manquer

La réponse courte : Cloudflare place son réseau entre les visiteurs et le site de l’entreprise. Il héberge la zone DNS, masque l’adresse réelle du serveur, absorbe les attaques DDoS et filtre le trafic par un WAF. Mais ces protections ne valent que si la configuration est juste : proxy activé sur les enregistrements web, mode SSL Full (strict), DNSSEC activé, et surtout serveur d’origine inaccessible en direct. Un site « sur Cloudflare » mais joignable par son adresse IP reste exposé.

Ce guide reprend ce que Cloudflare apporte à une entreprise, les réglages à vérifier et les erreurs que nous rencontrons le plus souvent. Il s’appuie sur la documentation officielle de Cloudflare. Notre propre site est d’ailleurs hébergé sur l’infrastructure Cloudflare.

Ce que Cloudflare apporte à une entreprise

Service	Ce qu’il fait	Disponible
DNS	Héberge la zone du nom de domaine, avec DNSSEC	Toutes les offres
Proxy	Répond avec les adresses de Cloudflare au lieu de celle du serveur	Toutes les offres
Protection DDoS	Détecte et atténue automatiquement les attaques, des couches 3 et 4 jusqu’à la couche 7	Toutes les offres, sans limite de volume
Certificats et HTTPS	Chiffre le trafic entre les visiteurs et Cloudflare, puis vers le serveur	Toutes les offres
WAF	Règles personnalisées, limitation de débit, règles gérées	Règles gérées complètes sur les offres payantes
Cache et performance	Met en cache les contenus statiques au plus près des visiteurs	Toutes les offres
Cloudflare One (zero trust)	Access, Gateway, Tunnel pour les accès des salariés	Offre distincte

La documentation de Cloudflare précise que la protection DDoS standard, des couches 3 à 7, est incluse et non plafonnée sur toutes les offres, gratuite comprise. Pour le WAF, l’offre gratuite inclut les règles personnalisées, une règle de limitation de débit et un jeu de règles gérées réduit ; les règles gérées complètes sont réservées aux offres Pro, Business et Enterprise. Nous détaillons le fonctionnement d’un pare-feu applicatif dans notre guide sur le WAF et le pare-feu applicatif web.

1. Le DNS : proxy ou DNS seul

Chaque enregistrement DNS d’une zone Cloudflare a deux états :

• Avec proxy (nuage orange) : Cloudflare répond avec ses propres adresses, le trafic web passe par son réseau, l’adresse du serveur est masquée, et le WAF, le cache et la protection DDoS s’appliquent.
• DNS seul (nuage gris) : la requête DNS renvoie la vraie adresse du serveur, et le trafic ne passe pas par Cloudflare.

Seuls les enregistrements A, AAAA et CNAME peuvent passer par le proxy. Les autres, comme MX ou TXT, restent toujours en DNS seul. Cloudflare recommande d’activer le proxy sur les enregistrements qui servent du trafic web, et de laisser en DNS seul ceux qui servent à la messagerie ou à la vérification d’un service tiers.

Enregistrement	Réglage conseillé
Site web (racine et www)	Proxy activé
Application web, extranet	Proxy activé, avec WAF et accès contrôlé
MX de la messagerie	DNS seul (imposé)
SPF, DKIM, DMARC, vérifications	DNS seul (imposé)
Autodiscover, accès VPN, téléphonie SIP	DNS seul, le proxy ne gère que le trafic web

Les enregistrements de messagerie méritent un soin particulier lors du transfert de la zone : un MX ou un enregistrement DKIM oublié et les courriels ne partent ou n’arrivent plus. Notre guide SPF, DKIM et DMARC et notre méthode de migration de messagerie vers Microsoft 365 détaillent ces enregistrements.

2. Le chiffrement : choisir Full (strict)

Cloudflare propose plusieurs modes de chiffrement entre ses serveurs et le serveur d’origine :

Mode	Visiteur vers Cloudflare	Cloudflare vers le serveur
Off	HTTP	HTTP
Flexible	HTTPS possible	HTTP, non chiffré
Full	HTTPS	HTTPS, sans vérifier le certificat du serveur
Full (strict)	HTTPS	HTTPS, avec vérification du certificat

Le mode Flexible donne l’illusion d’un site sécurisé : le cadenas s’affiche dans le navigateur, mais le trafic circule en clair entre Cloudflare et le serveur. Cloudflare recommande fortement Full ou Full (strict), le second ajoutant la vérification du certificat. Le certificat du serveur peut provenir d’une autorité publique ou de l’autorité d’origine de Cloudflare.

3. DNSSEC : signer la zone

DNSSEC ajoute une authentification aux réponses DNS, pour qu’un visiteur ne soit pas dirigé vers un domaine usurpé. Dans Cloudflare, l’activation se fait depuis les réglages DNS : Cloudflare signe la zone et fournit un enregistrement DS, qu’il faut ensuite ajouter chez le registrar du nom de domaine. Pour un domaine en .ma, cela se fait auprès du bureau d’enregistrement qui gère le domaine. Attention lors d’un transfert : Cloudflare demande de désactiver DNSSEC chez l’ancien fournisseur avant de déplacer la zone.

4. Protéger le serveur d’origine : le point le plus souvent oublié

Le proxy masque l’adresse du serveur, mais si cette adresse est connue (anciens enregistrements DNS, messagerie hébergée sur le même serveur, sous-domaine resté en DNS seul), un attaquant peut contourner Cloudflare et attaquer le serveur en direct. La documentation de Cloudflare recommande plusieurs mesures, de la plus simple à la plus robuste :

1. Vérifier les enregistrements en DNS seul (SPF, TXT, sous-domaines) pour qu’aucun ne révèle l’adresse du serveur.
2. Ne pas héberger la messagerie sur le serveur protégé : un courriel renvoyé peut révéler son adresse.
3. Changer l’adresse IP du serveur après la mise en place, car l’historique DNS peut conserver l’ancienne.
4. N’autoriser que les adresses de Cloudflare sur le pare-feu du serveur ou de l’hébergement.
5. Activer l’authentification des requêtes d’origine (Authenticated Origin Pulls), qui garantit que les requêtes viennent bien de Cloudflare ; elle exige le mode Full ou Full (strict).
6. Utiliser Cloudflare Tunnel : le serveur établit des connexions sortantes uniquement et n’a plus besoin d’adresse publique. C’est la méthode la plus propre pour une application hébergée dans les locaux.

5. Le WAF et la limitation de débit

Une fois le trafic sur Cloudflare, quelques règles simples apportent beaucoup :

• Protéger les pages d’administration (/wp-admin/, back-office, console) : accès limité à certaines adresses ou à un utilisateur authentifié.
• Limiter le débit sur la page de connexion et les formulaires, pour freiner les essais de mots de passe et le spam.
• Activer les règles gérées disponibles sur l’offre choisie, en commençant par observer les journaux avant de bloquer.
• Filtrer par pays seulement si l’activité le justifie : une entreprise marocaine qui travaille avec l’Europe et l’Afrique ne doit pas bloquer ses propres clients.

Consultez régulièrement les événements de sécurité : Cloudflare journalise quelle règle a été déclenchée par quelle requête, ce qui permet de repérer un faux positif qui bloque un client, ou un type d’attaque qui mérite une nouvelle règle. Sur l’offre gratuite, ces journaux sont échantillonnés ; pour une application importante, il vaut mieux les faire remonter dans la supervision de l’entreprise.

Ces règles complètent les mesures propres au site, que nous décrivons pour sécuriser un site WordPress d’entreprise.

6. Les accès des salariés : Cloudflare One

Au-delà du site public, la plateforme Cloudflare One applique une logique zero trust aux accès internes : Access authentifie l’utilisateur avant d’ouvrir une application, Gateway filtre le trafic DNS et web des postes, et Tunnel publie une application interne sans ouvrir de port sur le pare-feu. C’est une alternative au VPN d’entreprise pour certains usages, et une bonne façon de ne jamais exposer un bureau à distance sur Internet, comme nous le recommandons pour l’accès RDP. Access s’appuie sur l’annuaire existant, Microsoft Entra ID ou Google Workspace, avec la double authentification.

Mettre une zone sur Cloudflare sans coupure

1. Inventorier la zone actuelle : copie complète de tous les enregistrements, y compris messagerie, vérifications et sous-domaines oubliés.
2. Créer la zone dans Cloudflare et comparer ligne à ligne avec l’existant.
3. Désactiver DNSSEC chez l’ancien fournisseur si nécessaire.
4. Changer les serveurs de noms chez le registrar, puis vérifier le site, la messagerie et les services tiers.
5. Installer un certificat sur le serveur, passer en Full (strict).
6. Activer DNSSEC et ajouter l’enregistrement DS chez le registrar.
7. Verrouiller l’origine, puis activer les règles WAF en observation avant blocage.
8. Sécuriser le compte Cloudflare lui-même : double authentification, un compte par administrateur, pas d’identifiant partagé. Celui qui contrôle ce compte contrôle le site et la messagerie.

Les erreurs les plus fréquentes

• Laisser le mode SSL en Flexible.
• Oublier un enregistrement de messagerie lors du transfert de zone.
• Laisser le serveur d’origine joignable par son adresse IP.
• Garder un sous-domaine en DNS seul qui pointe vers le même serveur que le site.
• Bloquer des pays entiers sans vérifier d’où viennent les clients.
• Gérer le compte Cloudflare avec un seul identifiant partagé, sans double authentification.

Comment nous accompagnons les entreprises

Nous commençons par l’audit initial offert : zone DNS, enregistrements de messagerie, mode de chiffrement, exposition du serveur d’origine, règles en place et sécurité des comptes d’administration. Nous réalisons ensuite la mise en place ou la correction de la configuration, en lien avec le pare-feu de vos locaux et votre infrastructure réseau.

Dans le cadre de notre offre de cybersécurité des entreprises au Maroc, les sites et applications exposés sont suivis par la supervision 24/7, et un incident critique est pris en charge en moins de 15 minutes. Demandez votre audit initial offert : nous vous répondons sous 24 h ouvrées.