Le contrôle des sites complète la protection des identités

Le filtrage DNS et les contrôles de sites ajoutent des points de contrôle précoces dans le cloud

Le filtrage DNS et les contrôles de sites donnent aux équipes de sécurité davantage d’occasions d’arrêter les accès non sûrs dès 2026. Le filtrage du Domain Name System (DNS) vérifie les noms de domaine demandés par les appareils, tandis que les contrôles de sites régissent les destinations que les utilisateurs peuvent atteindre via des navigateurs ou des appareils gérés. Les deux ajoutent des points de contrôle à une architecture de sécurité en couches. Leur efficacité dépend d’une application cohérente sur tous les lieux de travail et d’une coordination avec la protection des comptes, les autorisations d’accès et les défenses contre les vulnérabilités logicielles.

Ces points de contrôle sont importants parce que les plateformes software-as-a-service (SaaS), les outils d’accès à distance et les services alimentés par l’IA relient les utilisateurs et les charges de travail dans des environnements distribués. Ces connexions élargissent ce que les organisations peuvent faire, mais elles offrent aussi davantage de moyens aux activités malveillantes d’atteindre les systèmes de l’entreprise. Les modèles de sécurité conçus pour des opérations sur site, cloisonnées, peinent à suivre le volume et la rapidité de ce trafic. À mesure que les services et les lieux de travail évoluent, une frontière fixe devient plus difficile à maintenir.

Les équipes distribuées et les organisations à distance ou hybrides rencontrent une autre difficulté lorsque leurs outils de sécurité fonctionnent séparément. Certaines ont ajouté le filtrage DNS et les contrôles de sites à leurs défenses existantes pour réduire l’exposition. Pour rendre ces ajouts utiles, les équipes doivent appliquer les règles de destination de manière cohérente à mesure que l’activité se déplace, tout en préservant les protections contre les autres voies d’accès initial.

Les voies d’entrée et les outils fragmentés exigent des réponses différentes

Pour positionner correctement les contrôles de destination, les équipes de sécurité doivent d’abord comprendre comment les attaquants pénètrent dans les environnements cloud. L’équipe Mandiant de Google Cloud attribue 83 % des entrées initiales dans les principaux environnements cloud et SaaS de ses données d’incident à des problèmes d’identité et d’accès. Google Cloud tire un bénéfice commercial de la demande en sécurité cloud, ce qui lui donne un intérêt dans la manière dont les organisations réagissent. Le constat de Mandiant place la protection des comptes et les autorisations d’accès au centre des décisions concernant ces incidents.

L’abus d’identifiants apparaît aussi dans l’analyse par Cloudflare de milliers de milliards de signaux réseau. Cloudflare, qui vend des services de sécurité et bénéficie des dépenses de protection, décrit des attaquants entrant via des identifiants compromis, parallèlement à un ciblage accru des environnements SaaS et des chaînes d’approvisionnement. Un compte valide peut permettre à un attaquant d’entrer sans franchir une frontière réseau conventionnelle. Les restrictions de destination peuvent interrompre une partie de l’activité associée, tandis que les contrôles d’identité déterminent si le compte lui-même doit être considéré comme fiable.

L’exploitation logicielle exige une réponse distincte. Verizon, qui a un intérêt commercial dans les services de sécurité, indique dans son dernier rapport sur les violations que l’exploitation des vulnérabilités logicielles a dépassé les identifiants volés comme principal point d’entrée « pour la première fois depuis près de vingt ans ». Le constat de Verizon et le pourcentage de Mandiant montrent la nécessité de traiter les deux voies d’entrée. La gestion des vulnérabilités traite les faiblesses logicielles exploitables, tandis que la gestion des identités et des accès régit l’usage des comptes et les autorisations.

La fenêtre de réponse aux faiblesses logicielles peut être courte, car une exploitation active peut suivre la divulgation en quelques jours. Les attaquants sondent en permanence les systèmes où la rapidité de livraison et la commodité ont pris le pas sur la sécurité. Des erreurs de configuration peuvent exposer des services, et des autorisations excessives peuvent donner à un compte accès à plus de ressources que son travail ne l’exige. Le shadow IT, c’est-à-dire les outils et services adoptés sans approbation de l’organisation, ajoute une activité que les équipes de sécurité peuvent avoir du mal à voir ou à gouverner.

Ces faiblesses peuvent aussi se croiser avec des choix de destination non sûrs. Une analyse intitulée « 10 real-life cloud security failures » regroupe la plupart de ses dix défaillances autour d’erreurs de configuration, d’accès trop larges ou d’utilisateurs atteignant des destinations non sûres. Chaque catégorie renvoie à une responsabilité opérationnelle différente : configurer les services, définir les autorisations ou contrôler l’accès aux destinations. Séparer les catégories aide les équipes à attribuer la bonne protection à chaque défaillance.

L’ampleur et le coût des incidents cloud font de ces responsabilités un enjeu métier. SentinelOne, un fournisseur de sécurité qui bénéficie de la demande en protection cloud, fait état d’une hausse de 21 % d’une année sur l’autre des attaques contre les infrastructures cloud et indique qu’environ 45 % des violations de données se produisent directement dans les environnements cloud. L’entreprise présente l’exposition au cloud comme un problème transversal à tous les secteurs et signale un coût moyen de 5,17 millions de dollars par incident. Pour les organisations qui dépendent de services accessibles à distance, les conséquences touchent les budgets technologiques et les opérations quotidiennes.

Réagir devient plus difficile lorsque les outils de protection fonctionnent de manière isolée. Le Fortinet 2026 Cloud Security Report décrit un « complexity gap », près de 69 % des organisations identifiant les outils déconnectés, les angles morts de visibilité et les contrôles incohérents comme leurs plus grandes difficultés. Fortinet vend des produits et services de sécurité, et bénéficie donc commercialement de la demande visant à résoudre ces problèmes. Les difficultés signalées expliquent comment des organisations peuvent posséder une technologie de sécurité importante tout en peinant à appliquer les politiques de manière fiable.

Une politique peut échouer lorsque des systèmes distincts l’interprètent ou l’appliquent différemment. Des vues incomplètes de l’activité compliquent aussi le suivi des changements concernant les services, les utilisateurs et les charges de travail. Le travail à distance et hybride ajoute de l’incohérence lorsqu’une règle dépend de l’endroit où quelqu’un se connecte. Les contrôles de destination ont donc besoin d’un objectif clair et d’un moyen fiable d’appliquer les décisions dans tous les environnements de travail.

Le filtrage DNS et les contrôles de sites interrompent l’accès à différentes étapes

Le premier point de contrôle est la résolution de domaine. Le DNS traduit un nom de domaine en informations d’adressage dont un appareil a besoin pour atteindre sa destination. Le filtrage DNS vérifie cette résolution et peut empêcher la résolution d’un domaine dangereux. Bloquer la résolution interrompt la requête avant qu’une connexion complète ne s’établisse.

Les contrôles de sites ajoutent une décision lorsqu’un utilisateur tente d’atteindre une destination via un navigateur ou un appareil géré. La politique de site de l’organisation détermine si l’utilisateur peut y accéder. Le filtrage DNS et les contrôles de sites interviennent donc à différentes étapes tout en soutenant une règle d’accès commune. Ensemble, ils peuvent réduire l’ensemble des destinations nuisibles que les utilisateurs peuvent atteindre.

Réduire cet ensemble peut empêcher les interactions avec des pages de phishing, des sites liés à des malwares et d’autres destinations non sûres. Cela réduit aussi la surface d’attaque : les systèmes, services et destinations par lesquels une activité malveillante pourrait se produire. Le blocage au niveau du domaine et du site peut interrompre certaines attaques liées aux identifiants en empêchant l’accès à une destination impliquée dans l’attaque. La protection des comptes et les contrôles d’autorisation continuent de régir la confiance accordée à l’identité et les ressources qu’elle peut utiliser.

Les équipes qui ont ajouté ces contrôles signalent une exposition plus faible au phishing et aux malwares, ainsi qu’une meilleure visibilité sur les outils non approuvés et la navigation à risque. Une meilleure visibilité aide les équipes de sécurité à repérer les écarts entre l’usage réel des services et l’usage approuvé. Les équipes peuvent examiner ces changements signalés dans leurs propres environnements. Le suivi de l’exposition et de la visibilité donne au déploiement un objectif pratique lié au fonctionnement des contrôles.

Le déploiement doit aussi préserver l’accès aux services dont les employés ont besoin. Les équipes indiquent qu’elles bloquent plus tôt les accès non sûrs tout en maintenant la rapidité de l’activité autorisée et en fonctionnant aux côtés des systèmes cloud-native existants. Atteindre cet équilibre dépend de politiques capables de distinguer les destinations risquées de celles qui sont nécessaires au travail légitime. Les responsables de l’ingénierie et de l’infrastructure doivent donc prendre en compte l’utilisabilité lorsqu’ils décident comment appliquer les restrictions de destination.

La threat intelligence, c’est-à-dire les informations utilisées pour identifier les activités malveillantes, aide à éclairer ces décisions à grande échelle. Cisco, qui vend Cisco Umbrella et bénéficie commercialement de la demande en sécurité DNS, indique que le service utilise une threat intelligence mondiale et bloque « des millions de domaines malveillants chaque jour » sur un volume important de requêtes DNS. Umbrella illustre la manière dont un blocage de domaines appuyé par l’intelligence peut fonctionner sur un trafic conséquent. Pour une équipe de déploiement, la question opérationnelle est de savoir comment cette intelligence éclaire les règles appliquées à ses propres utilisateurs et charges de travail.

L’intégration détermine si les contrôles ajoutés réduisent la fragmentation

L’application de ces règles crée une tension : les contrôles de destination ajoutent des points d’application, mais ils peuvent aussi ajouter des systèmes à gérer. Des produits de filtrage DNS et de contrôle de sites administrés séparément créent davantage d’endroits où maintenir les règles et inspecter l’activité. Leur valeur architecturale dépend donc de la manière dont leurs décisions se connectent à l’environnement de sécurité plus large. Des règles isolées et un traitement séparé peuvent accroître le travail de coordination auquel les équipes sont déjà confrontées.

Security Service Edge offre une façon d’organiser cette intégration en réunissant les services de sécurité pour l’accès aux ressources cloud et web dans une approche architecturale commune. Les décisions DNS et de site peuvent alors soutenir une politique d’accès plus large. Une architecture zero trust évalue les demandes d’accès sans supposer qu’un utilisateur ou un appareil est sûr en raison de son emplacement. Ces approches répondent à des préoccupations architecturales différentes, mais elles peuvent toutes deux soutenir des politiques qui restent applicables à mesure que les utilisateurs et les charges de travail se déplacent.

Pour les travailleurs à distance et hybrides, cette continuité signifie rester soumis aux règles de destination de l’organisation lorsque leur lieu de travail change. L’application doit suivre l’activité pour que la politique reste fiable. Exiger des utilisateurs qu’ils restent dans un seul lieu physique ou réseau préserverait le décalage entre le travail distribué et une protection dépendante de l’emplacement. L’intégration doit rendre la règle portable à travers les contextes d’accès utilisés par l’organisation.

Le zero trust établit aussi comment cette règle contribue à une décision d’accès plus large. Son principe d’évaluer « Every request » soumet chaque requête à la politique pertinente au lieu de prolonger une hypothèse de confiance. Les contrôles DNS et de sites apportent des décisions de destination, tandis que les systèmes d’identité évaluent le compte et que les contrôles d’autorisation déterminent ce qu’il peut faire. Les défenses contre les vulnérabilités conservent la responsabilité des faiblesses logicielles exploitables.

Le fait de garder ces responsabilités claires aide aussi les équipes à utiliser la threat intelligence de manière cohérente. Les informations sur les destinations malveillantes peuvent soutenir un blocage plus précoce pour les utilisateurs et les charges de travail lorsque les décisions qui en résultent s’intègrent dans la même approche opérationnelle. La protection des comptes, des autorisations appropriées et le traitement rapide des logiciels vulnérables restent nécessaires en parallèle de ce blocage. L’intégration doit préserver ces fonctions distinctes tout en facilitant l’application conjointe de leurs politiques.

Les équipes qui utilisent le filtrage DNS et les contrôles de sites signalent une application plus cohérente et une dépendance réduite à des solutions ponctuelles fragmentées. Le fait qu’un ajout produise ou non ces bénéfices dépend de la manière dont il modifie l’administration quotidienne des politiques. Les responsables de la sécurité peuvent évaluer ce changement en vérifiant si les règles s’appliquent dans l’ensemble de leur environnement ou si elles exigent une maintenance isolée et un traitement séparé. Un contrôle de destination fonctionnel peut malgré tout accroître la complexité opérationnelle si sa gestion reste déconnectée.

Les évaluations des principales plateformes zero trust décrivent de plus en plus le filtrage DNS comme une capacité de base. Son inclusion donne plus de poids à la manière dont il fonctionne dans le cadre d’une politique commune et aux côtés des autres protections de l’environnement. Pour une décision d’architecture, les administrateurs doivent examiner comment ils maintiendront les règles et les appliqueront dans les différents contextes d’accès. La présence d’une capacité et son intégration dans les opérations sont deux considérations distinctes.

Des attaques plus rapides renforcent l’importance d’une application en temps utile

Le tableau plus large de la sécurité en 2025 et 2026 accentue la pression pour accélérer ces opérations. Les attaquants comme les défenseurs étendent leur usage de l’IA, ce qui accélère l’activité sur toute la chaîne d’attaque. Combinée à une exploitation logicielle qui peut commencer peu après la divulgation, cette vitesse rend la période précédant une intervention efficace de plus en plus importante. Des défenses proactives et en couches visent à raccourcir cette période en plaçant les décisions là où elles peuvent interrompre une activité malveillante.

Le test opérationnel consiste à savoir si ces décisions prennent effet à temps et restent cohérentes à mesure que l’activité se déplace. Des tableaux de bord plus sophistiqués ont une valeur pratique limitée lorsque les systèmes d’application des règles appliquent les politiques de manière inégale. Les équipes sécurité et infrastructure doivent donc relier la visibilité au contrôle chargé d’agir en conséquence. Pour les menaces liées aux destinations, cela signifie transformer les informations sur les accès non sûrs en une décision DNS ou de site prise en temps utile, quel que soit l’endroit d’où provient la requête concernée.

Points clés

• Placer les contrôles en amont : le filtrage DNS peut bloquer les domaines dangereux avant qu’une connexion ne s’établisse, tandis que les contrôles de sites restreignent l’accès via les navigateurs et les appareils gérés. Les architectes sécurité peuvent utiliser les deux pour réduire l’exposition au phishing, aux malwares et aux destinations non sûres.
• Couvrir chaque voie d’entrée : l’abus d’identifiants, les autorisations excessives et les vulnérabilités logicielles exigent des protections distinctes. Les responsables sécurité doivent maintenir des contrôles d’identité, des revues d’autorisations et une gestion des vulnérabilités en parallèle des restrictions de destination.
• Préserver l’accès autorisé : les équipes infrastructure ont besoin de politiques de destination qui bloquent les services risqués tout en maintenant la disponibilité des outils métier essentiels. Évaluez les déploiements à l’aune de la réduction de l’exposition, de la visibilité sur les outils non approuvés et de la rapidité du travail légitime.
• Intégrer l’application des politiques : des contrôles gérés séparément peuvent accroître la complexité administrative. Les architectes sécurité qui évaluent le DNS et les contrôles de sites doivent vérifier si les règles restent cohérentes entre les services cloud, les travailleurs à distance et les systèmes d’accès existants.
• Relier l’intelligence à l’action : des attaques plus rapides renforcent l’importance d’une application en temps utile. Les équipes des opérations de sécurité doivent vérifier que les informations sur les destinations malveillantes produisent un blocage efficace partout où les requêtes concernées prennent naissance.