Leçons tirées de la panne de certificat de Spotify

Spotify a été frappé hier par une panne à cause - vous l'avez deviné - d'un fichier expiré. SSL/TLS expiré. Il semble que chaque mois (et même chaque semaine), c'est l'éternel recommencement.

Les pannes causées par l'expiration SSL/TLS expirés se produisent bien plus souvent que ce que l'on peut lire dans les journaux, et elles peuvent se manifester de différentes manières. et elles peuvent se manifester de toutes sortes de façons.

Au début de l'année, Microsoft Teams de l'entreprisen'a pas de renouveler a certificat d'authentification clientlaissant millions d'utilisateurs bloqués alors qu'ils commençaient à travailler depuis leur domicile. La semaine dernière, en Californie, un certificat expiré a été à l'origine sous-déclaration des cas de COVID-19.

En l'occurrence, il s'agit des utilisateurs de Spotify, utilisateurs de Spotify n'ont pas pu d'accéder le populaire service de streaming musical, et des milliers d'entre eux (environ 4 000 conversations) se sont rendus sur Twitter en utilisant le hashtag #spotifydown - tout cela à cause d'un certificat expiré.

La plupart des organisations ont des dizaines, voire des centaines de milliers de ces SSL/TLS dans leur environnement. Suivre le rythme de l'émission et de la certificats et les renouvellements renouvellement des certificats à cette échelle est est loin d'être facilede sécurité utilisent encore des méthodes manuelles pour les suivre. méthodes manuelles pour les suivre.

Il suffit d'une expiration imprévue et vous vous retrouvez avec une panne coûteuse à nettoyer. Cependant, certains désordres sont plus difficiles plus difficiles à nettoyer que d'autres. Cela s'explique par le fait que les certificats ne doivent pas seulement être renouvelés. parce que les certificats n'ont pas seulement besoin d'être renouvelés. souvent souvent mis à jour sur plusieurs serveurs web, serveurs d'applications et autres emplacements de votre réseau qui en dépendent.

Si un certificat existe Si un certificat existe à plusieurs endroits, il peut être facile d'oublier où il doit être installé. être installé. Ceci est particulièrement problématique avec les certificats génériques.

SSL/TLS sont généralement utilisés pour vérifier la confiance entre les sites web publics et le navigateur web de votre appareil. et le navigateur web de votre appareil. En termes simples, si vous visitez un site web doté d'un certificat SSL/TLS , l'adresse commencera par "https://" et non par "https://"(le symbole s signifie "sécurisé"). Chacun de ces certificats a une date d'expiration, à partir de laquelle ils doivent être mis à jour et remplacés.

La plupart des entreprises n'ont pas n'ont pas qu'un seul site webCependant, elles disposent de plusieurs domaines et sous-domaines (par exemple, .com, info, elles ont plusieurs domaines et sous-domaines (par exemple keyfactor.com, info.keyfactor.com, blog.keyfactor.com, etc.) C'est pourquoi certaines organisations, ou certains groupes en leur sein, optent pour l'utilisation de certificats de type "wildcard".

Au lieu d'acheter plusieurs certificats SSL/TLS auprès d'une autorité de certification publique (CA) pour chaque sous-domaine, un seul certificat générique peut être utilisé pour sécuriser un site web et tous ses sous-domaines. Cela peut s'avérer pratique, dans la mesure où vous avez besoin de moins de certificats pour votre infrastructure.

Mais.., c'est une arme à double tranchant, car sans une bonne gestion du cycle de vie des certificatsil peut être difficile de savoir si vous avez remplacé le certificat dans tous les endroits où il doit être mis à jour, et ce en même temps. Cela pose également des problèmes de sécurité, car un seul certificat de type "wildcard" peut mettre en péril l'ensemble de votre infrastructure s'il est compromis.l'ensemble de votre infrastructure en cas de compromission.

Dans la plupart des cas, nous recommandons de ne pas utiliser de certificats Wildcard, simplement en raison du risque élevé de panne ou de violation qui pourrait en résulter.

Revenons à Spotify. Un coup d'œil rapide sur Google Certificate Transparency Logs (voir l'image ci-dessous) montre que le certificat certificat qui a causé cette était en fait un certificat de type "wildcard". Comment s'en rendre compte ? L'astérisque à côté du nom de domaine (CN=) est le signe révélateur.

Pour éviter cette situation, vous devez limiter l'utilisation des certificats de type "wildcard" par votre organisation. Cela dit, dans certaines situations, ils peuvent s'avérer utiles.dans certaines situations, ils peuvent être utiles. Dans tous les cas, vous devez devez vous assurer que vous avez une visibilité de chaque certificat dans votre organisation et mettre en place des processus pour les renouveler avant qu'ils n'expirent.

Voici quelques quelques éléments clés à retenir:

• Limiter l'utilisation de certificats de type "wildcard" dans votre organisation
• Tenir un inventaire précis et actualisé inventaire des certificatss dans votre environnement, y compris (au minimum) la longueur de la clé, l'algorithme de hachage, l'expiration, l'emplacement dess, et le propriétaire du certificat
• Veiller à ce que les clés privées soient stockées et protégées conformément aux meilleures pratiques
• Automatiser le renouvellement et l'approvisionnement des certificats afin d'éviter les expirations inattendues

Ce n'est Ce n'est un secret pour personne que les outils d'automatisation du cycle de vie des certificats tels que Keyfactor Command sont conçus pour répondre à ces besoins (et plus encore). La croissance rapide du nombre de clés et de certificats dans les organisations a rendu obsolètes les méthodes manuelles et artisanales. Cependant, avant d'envisager l'utilisation d'outils, il est important de définir vos besoins.

Si vous ne savez pas par où commencer, le fait de savoir où vous en êtes aujourd'hui est un bon début.

Télécharger le modèle de maturité de la gestion des certificats pour voir comment votre organisation se situe par rapport aux meilleures pratiques et obtenir recommandations pratiques pour améliorer vos processus.