Les analyses récentes de sécurité des boutiques incitent à examiner les accès autour du site, y compris sa préproduction. Cloudflare Access peut ajouter un contrôle d'identité devant cet environnement ; sa validation doit inclure un visiteur refusé.
1. Délimiter l'environnement
Choisissez un nom dédié, par exemple preview.example.com, dans une zone Cloudflare active. Faites l'inventaire des personnes qui doivent l'ouvrir : équipe interne, agence et éventuellement un client chargé de la recette.
Préparez un compte autorisé et un compte témoin qui ne doit pas entrer. Le second est indispensable : réussir à vous connecter ne démontre pas que les autres visiteurs sont bloqués.
Recensez aussi les accès automatisés. Un contrôle destiné aux navigateurs peut interrompre une supervision ou une intégration. Ne résolvez pas ce problème en ouvrant l'environnement à tout le monde ; faites prévoir une politique adaptée aux machines.
Utilisez uniquement des données de test dans la préproduction. Le contrôle d'accès n'est pas une raison d'y copier des informations clients inutiles.
2. Configurer l'application avant son exposition
Dans Zero Trust, ouvrez Access controls puis Applications. Créez une application avec l'option Self-hosted and private, puis ajoutez le nom public retenu.
Associez une politique Allow limitée aux identités attendues et choisissez le fournisseur d'identité utilisé par l'équipe. Vérifiez la durée de session et les options d'authentification proposées avant de créer l'application. Les applications Access refusent par défaut les utilisateurs qui ne correspondent pas à une politique Allow.
Cloudflare recommande de créer l'application Access avant de publier la route d'un Tunnel. Si votre serveur est déjà accessible publiquement, traitez également son accès direct : protéger le nom public ne ferme pas automatiquement l'adresse d'origine.
La documentation demande de valider le jeton d'application Access pour sécuriser l'origine. Faites configurer cette validation selon votre mode de connexion avant de considérer le dispositif terminé.
3. Tester les deux côtés de la règle
Ouvrez une nouvelle session de navigateur et vérifiez qu'une identification est demandée avant l'affichage de la préproduction. Connectez-vous avec le compte autorisé, puis contrôlez une page profonde et un fichier que l'équipe utilise réellement.
Refaites l'essai avec le compte témoin. Il doit être refusé, même s'il parvient à s'authentifier chez le fournisseur d'identité.
Demandez enfin au responsable du serveur de tester, depuis un accès autorisé au diagnostic, qu'une requête directe sans jeton valide n'obtient pas le contenu protégé. Si ce contrôle échoue, la mise en place reste incomplète.
Consignez ces trois résultats et programmez la révision de la liste des personnes après la fin du projet.
Sources : Cloudflare Blog, documentation Cloudflare.