Dernière mise à jour : 6 août 2026

Ce que le domaine d'une entreprise révèle – et ce qu'il ne révèle pas – sur sa surface d'attaque externe

L'essentiel en bref

• Un domaine d'entreprise constitue un point de départ approprié pour le recensement des infrastructures visibles du public, mais ne constitue pas un inventaire d'actifs achevé.
• Le DNS, les certificats et les services accessibles peuvent révéler des liens, des changements et des vulnérabilités techniques.
• Les indicateurs SPF, DKIM et DMARC reflètent les configurations de protection des e-mails publiées. Ils ne garantissent pas l'impossibilité de toute tentative de phishing ou d'utilisation frauduleuse d'un compte.
• Le fait d'identifier un type de technologie ne confirme pas nécessairement la version du produit, son propriétaire ou l'existence d'une vulnérabilité spécifique.
• Une évaluation solide associe les signaux « outside-in » au contexte interne des actifs, des processus et de l'activité.

Le nom de domaine est un point de départ, pas une carte de l'entreprise

Un domaine d'entreprise relie la marque, le site web, la messagerie électronique et les services techniques. C'est pourquoi il constitue un bon point de départ pour une analyse des surfaces d'attaque externes. Les relations observables de l'extérieur peuvent révéler l'existence d'autres hôtes, certificats, adresses IP et prestataires de services. Gestion de la surface d'attaque externe utilise ces points de départ pour détecter et identifier de manière récurrente les infrastructures exposées sur Internet.

Le nom de domaine ne reflète toutefois pas directement la structure juridique ni l'environnement informatique. Une organisation peut exploiter plusieurs marques et noms de domaine. Les filiales utilisent leurs propres espaces de noms. Les services cloud et SaaS apparaissent sous les noms de domaine d'autres fournisseurs. Les systèmes historiques peuvent encore être techniquement connectés, même s'ils ne font plus partie des activités en cours.

Le cas inverse pose également problème : une référence technique ne prouve pas la propriété. L'hébergement mutualisé, les réseaux de diffusion de contenu, les agences externes et les services de plateforme créent des liens entre plusieurs organisations. Une analyse doit donc faire la distinction entre l'inventaire confirmé, les candidats plausibles, les dépendances et les indices historiques.

Microsoft décrit ce principe pour Defender EASM : les ressources connues servent de points de départ pour la détection, les connexions surveillées mènent à d'autres candidats et la force de l'association influence leur statut. Concrètement, cela signifie qu'une personne ou une règle fiable doit vérifier la relation avant qu'un résultat ne soit attribué à une organisation.

Les DNS et les sous-domaines révèlent des liens techniques

Le système de noms de domaine (DNS) associe des noms à des ressources et services techniques. Les enregistrements accessibles au public peuvent renvoyer vers des destinations Web et de messagerie, des serveurs de noms faisant autorité et d'autres fonctions publiées. Les sous-domaines structurent souvent des offres, des régions, des applications ou des environnements techniques. Les modifications apportées à ces données peuvent indiquer que des services ont été mis en place, déplacés ou mis hors service.

Pour une analyse des risques, ce n'est pas le nombre de noms qui est déterminant. Ce qui importe, ce sont la fonction, l'accessibilité, le besoin de protection et le responsable. Un sous-domaine contenant un terme de test peut être opérationnel ; un hôte doté d'un nom professionnel peut ne contenir qu'une redirection. Les noms sont des indices, pas une classification fiable.

Les relations DNS permettent également de mettre en évidence les dépendances. Les serveurs de noms, les destinations de messagerie ou les relations d’alias peuvent renvoyer vers des plateformes externes. Cela aide à identifier les concentrations techniques et les relations avec les fournisseurs. Cela ne permet toutefois pas de déterminer automatiquement quel contrat est en vigueur, quelles données sont traitées ou quelles mesures de prévention des pannes ont été convenues.

Les informations historiques et mises en cache doivent être datées. Une ancienne entrée DNS peut s'avérer utile pour une analyse des causes, mais ne reflète pas nécessairement le fonctionnement actuel. Chaque évaluation doit indiquer le moment de l'observation, la source des données et l'état de la connexion. Les noms supprimés et les ressources cloud réutilisées nécessitent une attention particulière lors de leur attribution.

Les certificats complètent la vue d'ensemble des domaines

Les certificats TLS associent des clés publiques à des noms de domaine. La transparence des certificats (Certificate Transparency) met en œuvre des protocoles publiquement vérifiables et uniquement extensibles pour les certificats et les pré-certificats. La RFC 9162 décrit la CT comme un mécanisme permettant notamment de détecter les certificats TLS publics émis de manière erronée. Ces données peuvent indiquer l'existence de noms de domaine supplémentaires et des changements au fil du temps.

Une entrée CT ne constitue toutefois pas la preuve qu'un serveur est actuellement accessible. Les certificats préliminaires peuvent être enregistrés avant qu'un certificat définitif ne soit disponible ; les certificats peuvent être renouvelés, remplacés ou utilisés pour des systèmes qui ont été mis hors service par la suite. Les noms figurant dans un certificat peuvent refléter des désignations historiques ou internes à un projet. À l'inverse, toutes les infrastructures de certificats privées ne doivent pas nécessairement apparaître publiquement dans les mêmes protocoles.

Cette analyse permet de répondre à deux questions distinctes. Premièrement, elle peut compléter la phase de découverte : quels noms ont été observés en lien avec des certificats publics ou des pré-certificats ? Deuxièmement, elle peut mettre en évidence la nécessité d'un contrôle : un nom ou un émetteur inattendu est-il connu en interne ? Pour répondre à cette deuxième question, il faut disposer d’un inventaire à jour des certificats et d’un processus de validation bien défini.

Les caractéristiques des certificats ne permettent pas de se prononcer sur la sécurité globale du transport. Les versions de protocole, les algorithmes, la formation de chaînes, la configuration du serveur et le comportement du client influencent la connexion. Un audit externe peut évaluer les caractéristiques observables, mais doit limiter ses conclusions au point d'extrémité testé et au moment de l'audit.

Bien comprendre les services disponibles et les informations techniques

Un service accessible au public élargit la surface d'attaque externe. Ce n'est pas nécessairement un défaut. Les sites Web, les passerelles de messagerie, les portails clients et les interfaces de programmation doivent souvent être accessibles. La question de sécurité consiste à savoir si le service est nécessaire, à jour, protégé de manière adéquate et attribué à un responsable.

Les réponses visibles de l'extérieur peuvent contenir des indications sur des protocoles, des serveurs Web, des frameworks ou d'autres technologies. Une telle identification repose sur des caractéristiques qui peuvent se recouper, être modifiées ou dissimulées. Un nom de produit constitue donc une hypothèse dont le degré de certitude est déterminé. La version précise reste souvent indéterminée.

Cette limite est essentielle dans le cadre des notifications de vulnérabilités. Lorsqu’un produit est concerné par une nouvelle faille, une alerte technique appropriée peut déclencher une enquête rapide. Elle ne prouve pas que la version concernée soit active ni que la vulnérabilité soit exploitable. Les données internes relatives aux paquets et aux versions, les informations fournies par le fabricant, les analyses authentifiées ou les tests autorisés apportent la confirmation nécessaire.

Un Note de sécurité peut regrouper plusieurs caractéristiques observables en catégories ou en indicateurs. Cela facilite l'analyse des tendances et les comparaisons. L'observation individuelle, l'actualité des données et la logique d'évaluation doivent rester accessibles pour chaque mesure. Une bonne valeur ne préjuge en rien de l'efficacité de chaque contrôle interne.

Les indicateurs de sécurité des e-mails fournissent des lignes directrices, mais ne reflètent pas l'ensemble des risques liés aux e-mails

Les domaines publient des informations techniques destinées à l'authentification des e-mails. Le protocole SPF définit, pour un domaine « Mail-From » ou « HELO », quels sont les systèmes d'envoi autorisés. Le protocole DKIM permet d'apposer une signature cryptographique sur certains éléments du message. Le protocole DMARC relie les résultats obtenus au domaine d'expéditeur visible et à une politique publiée. La norme IETF actuelle pour DMARC est la RFC 9989 depuis mai 2026.

Il est possible de déterminer, de manière externe, si les entrées DNS correspondantes existent et peuvent être analysées d’un point de vue syntaxique. Le niveau des directives et les objectifs de rapport publiés peuvent également fournir des indications. La portée technique de ces informations reste toutefois limitée. L’existence d’une entrée ne prouve pas que chaque source d’envoi légitime soit correctement intégrée ni que les rapports soient analysés.

Les protocoles SPF, DKIM et DMARC traitent certaines formes d’authentification de l’expéditeur et d’alignement de domaine. Ils n’empêchent pas l’utilisation abusive d’un compte légitime piraté. Ils n’évaluent pas non plus le contenu d’un message et ne remplacent pas la formation, la sécurisation des identités ou la détection au sein du système de messagerie. Les domaines tiers d'apparence similaire constituent un autre problème.

Pour l'analyse externe des risques, les fonctionnalités de protection des e-mails constituent des indicateurs de configuration mesurables. Tout écart devrait donner lieu à un contrôle interne des sources d'envoi, de la politique en vigueur, de l'évaluation et des processus de modification. Affirmer de manière générale que le domaine est „ à l'abri du phishing “ ne serait pas techniquement valable.

Le classement, le contexte et les limites déterminent l'évaluation

L'analyse d'un domaine tire sa valeur du contexte. Associez les actifs observés à un service métier, à un propriétaire et à un besoin de protection. Faites la distinction entre les systèmes propres à l'entreprise, les services sous-traités, les dépendances techniques et les candidats non identifiés. Indiquez quelles relations ont été confirmées et lesquelles ont simplement été déduites à partir d'une caractéristique externe.

Une analyse externe ne permet pas de se prononcer de manière fiable sur la segmentation interne, les identités, les processus de sécurité, les sauvegardes de données ou les formations du personnel. Elle ne permet pas non plus de recenser tous les services cloud et toutes les applications privées. Une Analyse des risques informatiques devrait donc relier les signaux externes à l'inventaire interne, à l'architecture, aux flux de données et aux contrôles.

Les critères pris en compte pour la hiérarchisation sont l'accessibilité, les preuves techniques, l'importance stratégique pour l'entreprise, l'impact potentiel et la menace actuelle. Un hôte non identifié peut dans un premier temps nécessiter une vérification de la propriété. Un service critique confirmé présentant une configuration suspecte peut nécessiter un traitement plus rapide. Toute incertitude doit rester visible en tant qu'information distincte.

LocateRisk analyse les surfaces d'attaque accessibles au public sans installation d'agent et classe les observations externes en fonction d'indicateurs clés de performance (KPI). L'analyse met en évidence l'exposition et les caractéristiques logicielles utilisées, mais n'identifie pas nécessairement la version concrètement vulnérable. Pour obtenir une première évaluation de votre domaine d'entreprise, vous pouvez utiliser un évaluation gratuite les demander et vérifier les résultats en les replaçant dans votre contexte interne.

Avec LocateRisk, le périmètre s'étend automatiquement, à partir des domaines d'entreprise enregistrés et des références d'infrastructure connues, pour inclure les actifs et les candidats techniquement liés. Cette vue élargie peut ensuite être affinée de manière ciblée : les relations non pertinentes peuvent être supprimées du champ d’application considéré, les actifs confirmés peuvent être conservés de manière ciblée ou prédéfinis via une liste blanche. Des observations récurrentes indiquent si des actifs apparaissent, disparaissent ou modifient leurs caractéristiques. Les responsables examinent les écarts prioritaires et documentent les mesures prises. Ainsi, la découverte automatique reste exploitable sans pour autant considérer les relations techniques comme des indications fiables concernant la propriété ou les vulnérabilités.

Questions fréquentes

---

Quelles informations fournit un nom de domaine d'entreprise ?

Elle peut servir de point de départ pour les indicateurs de protection liés au DNS, aux sous-domaines, aux certificats, aux services et à la messagerie. Ces caractéristiques mettent en évidence des liens techniques et des expositions, mais nécessitent une vérification de la propriété, de l'actualité et du contexte commercial.

---

Le fait de trouver un sous-domaine prouve-t-il que celui-ci appartient à l'entreprise ?

Non. Les plateformes partagées, les prestataires de services, les relations historiques et les ressources réutilisées peuvent entraîner des attributions erronées. Un candidat doit être validé à l'aide d'un inventaire interne, d'un contrat ou par le responsable concerné.

---

Un certificat peut-il attester d'un service actif ?

Ce n'est pas tout. Les données relatives à la transparence des certificats montrent qu'un certificat ou un pré-certificat associé à un domaine a été enregistré publiquement. Il n'est pas nécessaire qu'un certificat définitif existe ; il se peut également qu'un service associé ait été désactivé. L'accessibilité et l'utilisation actuelle doivent être vérifiées séparément.

---

Que révèlent les protocoles SPF, DKIM et DMARC en matière de sécurité ?

Ils présentent des mécanismes publiés pour l'authentification des e-mails, la signature et l'alignement des domaines. Ils ne permettent pas de prévenir toutes les variantes d'hameçonnage, ni d'empêcher toute utilisation abusive de comptes légitimes, et ne remplacent pas les contrôles internes de sécurité des e-mails.

---

Une analyse externe permet-elle d'identifier la version exacte du logiciel ?

Ce n'est pas forcément le cas. Les réponses et les caractéristiques peuvent donner une indication sur la technologie utilisée, mais les versions restent souvent floues. Pour obtenir une confirmation fiable, il faut se référer aux données d'inventaire internes, aux informations fournies par le fabricant ou à des contrôles techniques agréés.

Vous souhaitez savoir quels systèmes accessibles au public peuvent être associés au domaine de votre entreprise ? Prenez rendez-vous avec LocateRisk pour une analyse externe des risques informatiques et validez les résultats avec vos responsables.