Problèmes de sécurité concernant la délivrance de certificats génériques à des employés individuels
Nous avons récemment configuré une autorité de certification interne à deux niveaux. Nous diffusons également les autorités de certification racine via Active Directory afin que les certificats de notre autorité de certification interne soient automatiquement approuvés par tous les systèmes (Windows) de notre réseau.
Nos développeurs ont besoin de certificats SSL pour leurs postes de travail locaux. Une option serait de leur générer un certificat générique comme *.foo.bar.com.
Les avantages sont la facilité de mise en œuvre et la sécurité future (si nous créons de nouveaux sous-domaines à l'avenir, cela les couvrira automatiquement).
Cependant, le revers de la médaille est que si nous émettions un certificat générique, comment pouvez-vous être certain qu'un employé malveillant n'en abusera pas?
Imaginez une situation où un développeur malveillant configure un site Web sur son poste de travail local (mail.foo.bar.com) et peut en quelque sorte empoisonner le DNS ou modifier le fichier Host local d'un utilisateur. Ce certificat générique donne de la crédibilité à leur site Web malveillant, ce qui le rend plus authentique.
Suis-je trop paranoïaque? Devrions-nous émettre des caractères génériques et faciliter la maintenance des certificats ou devrions-nous générer des certificats uniques pour chaque nom DNS afin de limiter la portée de l'utilisation?
Quelqu'un a des pensées? Expériences?
ÉDITER
Il me semble qu'il y a deux très bonnes solutions affichées ici:
Séparez le développement/test et la production en autorités de certification indépendantes comme recommandé par @Kotzu. Pour nous personnellement, je ne peux pas justifier la création d'une deuxième autorité de certification uniquement à cette fin. C'est trop d'efforts pour le nombre de certificats que nous avons (40 au total dont 10-20 sont dev). Cela dit, je pense totalement que c'est la meilleure réponse.
Modifiez la structure de nommage DNS comme recommandé par @immbis afin que la partie "dev" du nom soit le sous-domaine et non le sous-sous-domaine. Ainsi, le caractère générique est plus évidemment un domaine de développement. Cela atténuerait dans une large mesure mes inquiétudes concernant la délivrance de certificats génériques. L'emprunt d'identité ne peut alors se produire que pour
*.dev.ourdomain.com- avec qui je suis d'accord. Cela dit, nous avons simplement trop de codes codés en dur pour que cela soit pratique.
Je pense que nous finirons par continuer à émettre des certificats SSL pleinement qualifiés pour chaque développeur. Cela semble plus sûr car cela laisse beaucoup moins de marge de manœuvre à une personne malveillante pour abuser/usurper l'identité d'une ressource légitime. Cette situation est un peu un cas de toute façon. J'espère que nos développeurs n'agissent généralement pas de manière malveillante et n'essaient pas de créer de faux sites. Je ne veux tout simplement pas distribuer des certificats génériques fiables comme des bonbons gratuits uniquement pour les utiliser plus tard de manière inattendue.
Si nous avons besoin de plus en plus de certificats et que l'émission de certificats individuels devient impossible à gérer, nous envisagerons de configurer une deuxième autorité de certification qui n'est approuvée que par les postes de travail de développement (et non par l'ensemble de l'entreprise) et d'émettre de nouveaux certificats génériques.
Je pense que vous devez séparer votre environnement. Seuls les certificats de production doivent être approuvés sur tout votre réseau. Les certificats de développement et de test ne doivent être approuvés que sur les ordinateurs sur lesquels travaillent les développeurs. Dans un environnement plus sécurisé, vous n'utiliseriez même pas la même autorité de certification racine pour les environnements de production et de développement.
Je vais supposer que vos développeurs ont besoin de certificats SSL de confiance localement. Comme indiqué précédemment, il pourrait être utile de se demander s'ils en ont vraiment besoin en premier lieu.
Un certificat générique fait référence à un certificat avec un CN ou SAN sur le formulaire *.something.example.com.
Le * s'étend à une seule étiquette; il ne s'étend pas à plusieurs étiquettes. Donc, ce qui précède correspondrait à foo.something.example.com (* extension à une seule étiquette) mais pas foo.bar.something.example.com (deux étiquettes) et encore moins foo.example.com (étiquette manquante).
Gardez également à l'esprit que si je me souviens bien, plusieurs * les étiquettes sont spécifiquement interdites dans les champs certificat SAN et CN. Vous ne pouvez donc pas créer de certificat valide pour, par exemple, *.*.something.example.com; qui serait rejeté car il a plusieurs * en un seul nom. (Je pense que c'était l'un des problèmes rencontrés par Stack Exchange lors de la configuration de HTTPS à l'échelle du réseau.)
Vraisemblablement, chaque poste de travail de développeur est nommé différemment. Vous pourriez donc avoir des postes de travail de développeur comme dev033.internal.example.com, dev7g-vm2.example.com, ou qu'avez-vous.
Donnez donc à chaque développeur un seul certificat pour un seul caractère générique SAN sous le nom complet de leur propre hôte plus le nom complet de leur propre hôte. Configurez-le pour qu'il ne soit pas autorisé à utiliser pour signer d'autres certificats (certificat feuille).
Par exemple, donnez au développeur qui utilise dev033.internal.example.com un certificat valable pour uniquement dev033.internal.example.com et *.dev033.internal.example.com.
De cette façon, le développeur est libre de configurer des alias sur son propre hôte (par exemple, api.dev033.internal.example.com et web.dev033.internal.example.com fonctionnerait tous les deux avec un tel certificat) mais ne peut pas configurer de SSL pour tout ce qui n'est pas sous le nom d'hôte de leur propre poste de travail. En supposant que vous n'exposez pas internal.example.com à tout hôte externe, en dehors de votre réseau, le développeur ne peut pas non plus vraiment faire avec le certificat ce qu'il ne pourrait pas faire avec un certificat auto-signé.
Pour les points bonus, mais pas vraiment requis: signez-les avec une autorité de certification interne qui n'est utilisée que pour ces certificats de développement (ou de test, ou autre).
Compte tenu de vos contraintes, je dirais que vous devriez mettre en place un script qui utilise Let's Encrypt (ou votre propre générateur de certificats, quel que soit le fonctionnement) pour générer automatiquement les certificats de sous-domaine demandés pour tout développeur de votre réseau, avec la contrainte critique que le suffixe du nom de domaine est bien évidemment odieux.
Par exemple, laissez n'importe qui dans votre coporation créer des sous-domaines arbitraires comme X-untrustworthy-danger-danger-danger.company.com où X est ce qu'ils veulent (ASCII uniquement, de préférence). Cela devrait suffire pour tester sans tromper personne.
Envisagez de restreindre les certificats délivrés aux développeurs avec le champ extendedKeyUsage uniquement à ce qui est absolument nécessaire. S'il n'y a aucun objectif d'authentification de serveur, il sera rejeté lorsqu'il sera présenté par un serveur Web.
Pensez également à utiliser des extensions. Par exemple, l'extension basicConstraints fera la différence entre les certificats qui peuvent signer des certificats supplémentaires (CA:TRUE) et ceux qui ne le peuvent pas (CA:FALSE). De cette façon, si un autre certificat est émis par un employé malveillant utilisant son certificat, il sera rejeté partout qui prend en charge cette extension (donc tout X509v3).
De cette façon, si vous avez un employé malveillant avec un certificat restreint de la manière suivante, il ne pourra pas en abuser de tant de façons:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement