Découvrez le témoignage de Virginie Collineau, RSSI de Nameshield Group certifié ISO 27001 depuis 2017, lors du webinaire organisé par Lloyd’s Register, le 8 décembre 2020.
La sécurité de vos informations et de vos données est désormais essentielle.
Des risques technologiques aux risques humains, il est devenu incontournable de protéger vos systèmes d’information via des processus fiables et conformes en engageant les équipes.
Sur cet évènement Live, nos experts partageront leurs expériences via les regards croisés auditeur- audité, la vision et l’intérêt d’une approche SMSI avec ses bénéfices et les processus inhérents. Venez poser vos questions en matière de cybersécurité, cyberattaques, cybermenaces.
Webinaire Live
Date & Horaire : 8 décembre 2020 | 10:00 Inscription : Gratuite Durée : 30 min – Regards croisés // 20 min – Questions/Réponses
Au sommaire :
Tour d’horizon des solutions en matière de protection des systèmes d’information
Exemples et cas pratiques clients
L’approche et les services LR & Nameshield
Questions Réponses avec nos experts techniques
Intervenants :
Philippe Roudier, Responsable Technique et Accréditation – Lloyd’s Register France
Les certificats TLS/SSL sont utilisés pour authentifier les serveurs (Web le plus souvent) et chiffrer le trafic entre les sites Web et les utilisateurs. Ils garantissent ainsi l’intégrité des données échangées et empêchent l’espionnage de celles-ci. La digitalisation de l’entreprise et du monde en général, ainsi que la volonté des navigateurs d’imposer le HTTPS:// par défaut, ont multiplié de manière exponentielle les besoins en matière de certificats.
Pour répondre à ces besoins croissants, le certificat wildcard (*.nomdedomaine.com) est de plus en plus envisagé par les entreprises. S’il présente certains avantages, notamment en matière de réduction des coûts et de flexibilité, il convient d’en connaître les inconvénients pour choisir le bon certificat en toute connaissance de cause. Petit tour d’horizon du certificat wildcard.
Qu’est-ce qu’un certificat wildcard ?
Un certificat TLS standard permet de sécuriser un nom d’hôte (CN pour Common Name ou FQDN pour Fully Qualified Domain Name) explicite, défini dans ses métadonnées. Exemple, Google détient un certificat pour mail.google.com.
Ce certificat est valide uniquement pour : https://mail.google.com/
Il ne peut être utilisé pour : https://google.com/ – https://images.google.com/ – https://my.mail.google.com/
En d’autres termes, le nom d’hôte doit être une correspondance exacte. Si vous essayez d’utiliser ce certificat sur https://my.mail.google.com/ vous obtenez une erreur de certificat de votre navigateur.
Un certificat TLS wildcard est différent. Comme son nom l’indique, il utilise une correspondance générique plutôt qu’une correspondance exacte. Cette correspondance générique est matérialisée par « * » dans le CN et couvre tous les sous-domaines d’un même niveau. Exemple avec le certificat *.google.com.
Ce certificat est valide pour : https://mail.google.com/ ET https://images.google.com/ ainsi que tous les sous-domaines possibles de google.com.
Il ne peut être utilisé pour : https://google.com/ (sans sous-domaine) ou https://my.mail.google.com/ (le niveau de sous-domaine n’est pas le même).
Le côté pratique du certificat wildcard ?
Dans certaines situations, le certificat wildcard est très utile. Un hébergeur qui propose des sites web pour différents clients, hébergés sur un serveur mutualisé, et accessibles via des sous-domaines différents… client1.monsite.com, client2.monsite.com, client3… Il est peu pratique, techniquement plus compliqué et de facto plus cher de demander un nouveau certificat pour chaque client qui s’inscrit ; l’option la plus simple est un certificat wildcard pour *.monsite.com, certificat unique qui couvrira tous les clients. Le cas est identique pour une entreprise qui souhaite accéder à ses sites web via des FQDN dérivés d’un même domaine et hébergés sur un même serveur web, *.monentreprise.com. Jusque-là tout va bien.
Mais alors, quel est le risque ?
Dans les cas ci-dessus, tous les sites sont hébergés sur un seul serveur. Dans les grandes entreprises, ou pour les sites web importants, les hébergements sont souvent plus complexes et sur des serveurs différents. Reprenons notre exemple de Google avec images.google.com et mail.google.com, ces deux applications sont liées à des services différents de l’entreprise, hébergées sur des serveurs différents et gérées par des équipes techniques différentes. Ce genre d’organisation est extrêmement fréquent dans l’entreprise. Et c’est là que la sécurité des certificats wildcard s’arrête.
Le problème du certificat wildcard, et dans une moindre mesure des certificats contenant des entrées multiples (les fameux SAN, Subject Alternative Names), vient du fait de les déployer sur plusieurs serveurs. En effet, pour assurer la sécurité d’un certificat TLS/SSL, il faut absolument protéger la clé privée associée au certificat. Idéalement la mettre au coffre ou dans un HSM. Lorsqu’on installe un certificat sur plusieurs serveurs, les clés privées associées circulent, augmentant l’exposition au risque de compromission.
Cas de la compromission d’un certificat
En cas de compromission d’un certificat, ou d’erreur sur le certificat (problème de renouvellement), il convient d’intervenir rapidement pour limiter les dommages causés. Demande d’un nouveau certificat (ou renouvellement), installation du nouveau certificat et, le cas échéant, révocation du certificat compromis.
Dans notre exemple de création de sites Web sur serveur unique, ce n’est pas un problème. Nous avons un seul serveur, il a été compromis, le certificat volé/expiré/compromis ne fonctionne que pour ce seul serveur ; nous avons limité les dégâts autant que possible.
Dans un scénario à « plusieurs serveurs », si le certificat d’un seul des serveurs est affecté, il devient compromis sur l’ensemble des serveurs, ce qui va entraîner des conséquences sur l’ensemble de ceux-ci et demander une intervention bien plus large, le plus souvent en urgence, pour réparer les dégâts, et en supposant que l’ensemble des serveurs affectés soit identifié. En effet il n’est pas rare que le certificat circule au sein de plusieurs équipes et installé sans être répertorié sur nombre de serveurs. L’impact peut être considérable.
En reprenant notre exemple de Google. Imaginons que seul le serveur images.google.com ait été piraté et que mail.google.com n’ait pas été affecté. Le certificat pour images.google.com étant un certificat wildcard pour *.google.com commun à mail.google.com, le cyber-attaquant ayant compromis le service d’images a par ricochet usurpé l’identité du serveur mail.google.com et peut intercepter le trafic du service de messagerie alors que ce serveur n’a jamais été piraté !
Bonne pratique à respecter : un certificat TLS/SSL par serveur…
Dans notre dernier exemple, si nous avions eu deux certificats et non un seul, chacun des serveurs n’ayant accès qu’à son propre certificat, nous aurions limité le risque. Dans un monde idéal, chaque certificat ne doit être utilisé que pour un serveur (ou un cluster homogène de serveurs). Différents services sur différents serveurs doivent avoir leurs propres certificats, généralement non wildcard.
Un wildcard peut être utilisé si vous avez beaucoup de noms d’hôte, de type sous-domaine, pointant vers le même service sur le même serveur. Attention cependant que ce certificat générique ne couvre pas également des noms d’hôte pointant vers d’autres serveurs ; auquel cas chaque service devrait avoir ses propres certificats.
Enfin si vous avez quelques noms d’hôte pointant vers des serveurs uniques et tout le reste sur un seul service, alors il est préférable de dissocier les noms d’hôte. Par exemple, vous pouvez avoir un certificat pour login.monsite.com et un certificat (wildcard) pour *.clients.monsite.com. Sur ce dernier exemple, si le nombre de clients est fixe ou clairement défini, il vaut mieux s’orienter vers un certificat avec une liste de SAN précise, pour mieux maîtriser les noms d’hôte sécurisés et ne pas permettre le httpS:// sur des noms d’hôte non maîtrisés.
Conclusion
L’option du certificat wildcard existe et c’est une bonne chose pour certains besoins très spécifiques. Dans les faits, on ne devrait jamais avoir besoin de mettre en place un certificat wildcard, pas plus qu’on ne devrait installer un même certificat sur différents serveurs non bâtis en cluster.
Rendez-vous le 24 novembre prochain à 10h pour assister à notre webinar intitulé : Nom de domaine : les clés d’une stratégie de surveillance et de protection (cybercriminalité, cybermenaces, …).
Lors de ce webinar, découvrez en quoi le nom de domaine est un actif clé pour votre société, comprenez quelle est sa valeur, quelles sont les formes de cyber-risques qui pèsent sur cet actif et comment mettre en place une stratégie de surveillance et de protection.
De la valorisation financière, aux recommandations techniques (DNS / HTTPS / SSO etc.), en passant par le monitoring, nos experts vous présenteront un panorama complet des bonnes pratiques à mettre en place pour défendre efficacement votre territoire numérique.
Pour y assister, il faudra au préalable vous inscrire sur la plateformeWebikeo(inscription gratuite) puis réserver votre place pour ce webinar. Vous pourrez ainsi participer en live à cette web-conférence et poser vos questions en direct.
Vous ne serez pas disponible ? Pas d’inquiétude, ce webinar sera également disponible en replay.
Dans l’article publié le 13 octobre dernier, vous avez pu découvrir les différentes phases de vie d’un nom de domaine grâce à la fiche « 5 minutes pour comprendre – La durée de vie d’un nom de domaine ».
Retrouvez ces différentes phases dans l’infographie ci-dessous :
Cette infographie est disponible en téléchargement, en haute définition, sur le site de Nameshield.
Lancée par le registre Donuts, cette extension .CONTACT est intéressante, notamment pour les pages de contact de vos sites web.
Cette extension fait également partie du programme TrueName créé par le registre Donuts : lors de l’enregistrement d’un nom en .CONTACT, Donuts protègera aussi les alternatives typographiques de votre marque en les bloquant, empêchant ainsi certaines tentatives de phishing via l’enregistrement par un tiers d’un nom typographiquement similaire (ex. : loulou.contact vs l0ulou.contact).
Rappel du calendrier :
Sunrise [période réservée aux titulaires de marques] : 29 septembre 2020 – 28 novembre 2020
Early access phase [ouverte à tous, les prix sont décroissants jour après jour] :
– Early Access Phase (EAP) jour 1 : 2/3 décembre
– Early Access Phase (EAP) jour 2 : 3/4 décembre
– Early Access Phase (EAP) jour 3 : 4/5 décembre
– Early Access Phase (EAP) jour 4 : 5/6 décembre
– Early Access Phase (EAP) jour 5-7 : 6/9 décembre
L’optimisation pour les moteurs de recherche (SEO) regroupe un ensemble de techniques visant à favoriser la visibilité d’une page web dans les résultats de recherche. Le choix du nom de domaine y participe.
Découvrez dans cette infographie, quelques bonnes pratiques pour optimiser le SEO des noms de domaine.
Le mois d’octobre est en Europe celui qui met à l’honneur la cybersécurité. L’objectif de cette opération est chaque année de sensibiliser les utilisateurs aux enjeux de sécurité numérique, tant à un niveau personnel que professionnel.
De nombreux acteurs se mobilisent à cette occasion pour alerter sur les risques cyber et informer sur les mesures de protection existantes.
C’est dans ce contexte qu’a été mis en ligne le site cybervictime.net!
Ce site est un manuel numérique de solutions faciles à mettre en place pour protéger son informatique et sa vie numérique.
Vous y trouverez des tutos intéressants traitant de la sécurité de :
votre ordinateur ;
votre téléphone portable ;
votre vie numérique et la protection de vos données personnelles ;
Vous n’êtes pas à proprement parler propriétaire d’un nom de domaine, vous avez simplement un droit d’usage qui se traduit par une redevance annuelle qui peut être renouvelée à l’infini ou rompue en cas d’infraction. Dès lors que vous ne payez plus la redevance annuelle nécessaire à son maintien, et donc son renouvellement, le nom de domaine expirera et retombera dans le domaine public.
Cette suppression n’est cependant pas automatique, car au lendemain de sa période d’expiration, le nom de domaine va traverser 3 phases successives avant de retomber dans le domaine public.
Retrouvez dans cette fiche « 5 minutes pour comprendre », disponible en téléchargement sur le site de Nameshield, les différentes phases de vie d’un nom de domaine.
Nous vous indiquions en janvier dernier vous garder informés des mises à jour attendues de l’Eurid quant aux conditions d’enregistrement du .EU pour les ressortissants anglais à la suite du Brexit.
L’Eurid a en effet annoncé qu’à partir du 1er janvier 2021, il n’autorisera PLUS l’enregistrement de tout nouveau nom de domaine par des titulaires britanniques.
Le registre refusera également la mise à jour d’un nom de domaine vers un titulaire britannique.
Les titulaires n’étant pas conformes à ces règles seront prévenus dès le 21/12/2020.
Les nouvelles conditions d’éligibilité d’un .EU seront donc les suivantes :
ÊTRE :
un citoyen de l’Union, indépendant de son lieu de résidence ; ou
une personne physique qui n’est pas un citoyen de l’Union et qui est résident d’un État membre ; ou
une entreprise établie dans l’Union ; ou
une organisation établie dans l’Union, sans préjudice de l’application du droit national.
Soyez donc vigilants à vos .EU actuellement enregistrés afin d’être en conformité avec ces nouvelles règles qui entreront, pour rappel, en vigueur dès janvier 2021.
A NOTER
Les citoyens de l’Union qui résident au Royaume-Uni resteront éligibles pour détenir un nom de domaine en .EU après la fin de la période de transition. Ils devront mettre à jour leurs données d’enregistrement et prouver leur citoyenneté dans l’Union.
Les citoyens du Royaume-Uni résidant dans un État membre de l’Union resteront éligibles pour détenir un nom de domaine en .EU après la fin de la période de transition. En revanche, les citoyens du Royaume-Uni résidant en dehors des États membres de l’Union ne pourront plus détenir un nom de domaine en .EU après la fin de la période de transition.
Nameshield utilise des cookies
Nameshield souhaite utiliser des cookies permettant d’assurer le bon fonctionnement du site et, avec nos partenaires, d’en mesurer son audience🍪.
Nameshield souhaite utiliser des cookies permettant d’assurer le bon fonctionnement du site et, avec nos partenaires, d’en mesurer son audience. Plus d'informations dans notre politique de cookies 🍪.
Ces cookies sont essentiels au bon fonctionnement du site web. Ils assurent les fonctionnalités de base et les fonctions de sécurité du site web, de manière anonyme.
Cookie
Durée
Description
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Analytics" category .
cookielawinfo-checkbox-functional
1 year
The cookie is set by the GDPR Cookie Consent plugin to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Necessary" category .
cookielawinfo-checkbox-others
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Others".
cookielawinfo-checkbox-performance
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Performance".
CookieLawInfoConsent
1 year
Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
Ces cookies aident à réaliser certaines fonctionnalités comme le partage du contenu du site web sur les plateformes de médias sociaux, la collecte de commentaires et d’autres fonctionnalités de tiers.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Ces cookies sont utilisés pour comprendre comment vous arrivez sur notre Site et pour mesurer le nombre de visiteurs.
Cookie
Durée
Description
_ga
2 years
The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gat_gtag_UA_25904574_14
1 minute
Set by Google to distinguish users.
_gid
1 day
Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
Ces cookies sont utilisés pour vous proposer des offres et services personnalisés, plus adaptés à vos centres d’intérêts.
Cookie
Durée
Description
NID
6 months
NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.