Nous sommes une petite startup. L'un de nos produits est un service Web B2B, accessible via son https://service.example.com
URL canonique.
À des fins de test, ce service s'exécute également sur différents environnements de test/de transfert/d'intégration, tels que https://test.service.example.com
, https://integration.service.example.com
, etc.
Nous avons également des outils collaboratifs tels qu'un traqueur de bogues ou un wiki. Ils fonctionnent également sur des machines fournies par notre hébergeur. Leurs URL sont par exemple https://wiki.example.com
, https://bugs.example.com
.
Pour simplifier les choses, nous utilisons un seul certificat (pour example.com
) et ont ajouté toutes les URL ci-dessus en tant que noms alternatifs de sujet à ce même certificat. Tous nos serveurs utilisent donc le même certificat.
Y a-t-il un problème de sécurité à ce sujet dont nous devrions être conscients? Si oui, quelle aurait été la "bonne" façon de faire les choses?
L'utilisation du même certificat n'affecte en rien la sécurité fondamentale de la connexion établie à l'aide de celui-ci.
La seule "faiblesse" possible introduite en utilisant le même certificat est que si ce certificat expire ou est divulgué, tous vos sites seront affectés. Étant donné que ce certificat se trouve sur plusieurs serveurs et que certains d'entre eux peuvent être des serveurs de test avec moins de sécurité, il est possible que la clé privée de ce certificat soit divulguée ou exposée par inadvertance à partir de l'un de ces serveurs non contrôlés. Ce n'est certainement pas un échec de la sécurité fournie par le certificat, mais plutôt un échec à garder secrète la clé privée du certificat.
L'alternative serait d'utiliser des certificats séparés pour tous vos sites, ce qui signifierait que vous auriez la charge administrative d'avoir à renouveler, protéger et surveiller plusieurs certificats.
Si vous protégez correctement les détails privés de ce certificat, il n'y a aucune raison pour que son utilisation soulève des problèmes de sécurité supplémentaires.
Ce modèle présente deux faiblesses.
1) Fuite d'informations. L'inclusion des URL dev/qa/etc dans le certificat permet de trouver plus facilement ces environnements. Souvent, ils sont moins sécurisés que l'environnement de production réel car ils sont utilisés pour tester le code. Si vous avez d'autres contrôles en place pour limiter l'accès, tels que les listes de contrôle d'accès du routeur/pare-feu (ou autre chose), ce n'est pas aussi important.
2) Confinement compromis. Je recommande fortement de dédier un certificat uniquement pour la production. Si, pour une raison quelconque, votre environnement dev/qa/etc est compromis et que l'accès à la clé privée a été obtenu, alors il faut se demander si le trafic de production a été compromis (c'est-à-dire MITM). Les certificats SSL sont très abordables de nos jours et je suggère à nouveau de dédier un certificat uniquement pour la production.
Comme l'a dit @anon, le principal problème est la fuite d'informations. Quiconque accède à l'un de vos sites peut voir le nom de tous les autres répertoriés dans le certificat (sauf si vous choisissez d'obtenir un certificat générique; cependant, un certificat générique ne vous permettra pas d'ajouter le niveau supplémentaire test.service...
, car le caractère générique ne peut pas contenir de points). Si vous ne vous souciez pas que les visiteurs de service
puissent voir que wiki
, bugs
, etc. existent, alors ce n'est pas un problème.
En général, je préfère utiliser des certificats auto-signés pour tester les sites. Cela donne juste une indication supplémentaire que le site n'est pas en production. J'ai commencé à le faire après avoir reçu un certain nombre de commandes sur le site de test d'une boutique en ligne. (Le fait qu'il soit indiqué en gros caractères gras en haut de chaque page de ne pas utiliser le site ne semble pas avoir d'importance. Il s'est également avéré que la plupart étaient des ordonnances de fraude, mais ce n'est pas le but.) ce site n'est pas digne de confiance ", un avertissement s'affiche pour empêcher les utilisateurs d'essayer d'acheter sur ce site.