Automatisation de la conformité des SAN avec CMS 5.0

Le correctif de Chrome 58 suscite la controverse et l'agitation

Il y a quelques mois, Google a publié un correctif (v.58) pour son navigateur Chrome, largement utilisé. Ce correctif nous a tous obligés à remettre en question la façon dont nous émettons les certificats et a rompu rétroactivement un grand nombre de connexions de navigateurs et de serveurs web simultanément.

Figure - 1

L'équipe de support de Certified Security Solutions (CSS) a traité un afflux de tickets et a conseillé nos clients sur la manière de traiter ce sujet brûlant à l'époque. Après avoir observé l'augmentation des besoins d'assistance suite à ce correctif, nous avons publié un article de blog détaillant la manière dont nous pouvions traiter ce problème à court et à long terme. La solution à long terme consistait à remédier aux entrées d'attributs Subject Alternative Names (SANs) dans l'environnement et à adopter certaines bonnes pratiques en matière d'émission de certificats. Ce serait en fin de compte la meilleure solution pour l'avenir, puisque l'attribut "CommonName" (CN=nom de la machine) ne serait plus conforme à la RFC 2818 (champ utilisé dans un certificat pour le cryptage TLS ) pour permettre le cryptage TLS et forcer au moins un attribut SAN du système de noms de domaine (DNS) à terme. Ces efforts étant considérés comme une solution, et alors que les pannes étaient résolues, un autre problème s'est présenté.

Les administrateurs et les responsables de la délivrance des certificats sont désormais confrontés à de nouveaux défis dans le cadre de l'adoption de ces meilleures pratiques au sein de l'organisation. Des processus antérieurs avaient été définis et l'automatisation de la délivrance des certificats était en place depuis de nombreuses années. Certains de ces processus adoptés remontent à mai 2000, lorsque l'attribut "CommonName" était encore accepté pour le cryptage de TLS . L'équipe de soutien du SOC a documenté divers cas d'utilisation et procédures des clients. Grâce aux conseils du client, aux experts internes de l'infrastructure à clé publique (PKI) et aux conclusions de l'équipe de développement, CSS a pu élaborer une solution viable autour des processus existants PKI et des certificats disponibles dans la nouvelle version de la plateforme de gestion des certificats numériques et PKI , CMS 5.0, leader du secteur.

La fluidité est vraiment le mot clé ici. Avec l'infrastructure et les politiques existantes et nouvellement construites de PKI , il est primordial de pouvoir résoudre un problème sans devoir procéder à un "rip & replace" long et fastidieux des processus ou de PKI pour réparer un problème déjà en train de sombrer. Comment la CMS peut-elle être utilisée pour remédier à cette situation ?

Dans la plupart des cas, pour mettre fin à un problème persistant, il faut d'abord comprendre d'où vient le problème et cesser de l'alimenter. Avec le correctif Chrome 58, le coupable s'est révélé être l'inscription initiale des certificats. Les équipes chargées des serveurs web et des administrateurs doivent cesser d'enregistrer et d'émettre des certificats qui n'ont pas fait l'objet d'une réclamation. Cela semble assez facile à mettre en œuvre, mais le défi s'est posé dans les grandes organisations où les processus et l'automatisation ont été définis depuis des années. Il est également facile de délivrer des certificats qui ne satisfont pas aux nouvelles exigences en matière d'attributs SAN. CSS a placé une option dans CMS 5.0 qui ne permettra pas l'inscription pour un certificat sur une autorité de certification particulière (CA) définie sur l'un de ses portails CMSAdminEnroll (fonctionnalité de CMS 5.0 utilisée pour émettre des PFX et des CSR).

Figure - 2

Cela crée une frontière transparente de conformité en utilisant le produit CMS 5.0 comme un simple interrupteur d'activation et de désactivation d'une AC donnée à laquelle sont déléguées les opérations d'inscription (AC définie dans le CMS pour l'inscription). Ainsi, si une émission passe par le portail CMSAdminEnroll, CMS échouera à toute tentative d'émission d'un certificat qui n'a pas au moins une entrée dans le SAN DNS .

Pour aller plus loin, CSS a également créé un module de politique d' autorité de certification qui ajoute automatiquement au moins un SAN à une demande de certificat.

Les modules de politique sont des programmes qui reçoivent des demandes des services de certification, évaluent ces demandes et spécifient les propriétés optionnelles des certificats qui sont construits pour répondre à ces demandes.

Figure - 3

Pour ce faire, le Policy Handler RFC 2818 est installé sur l'autorité de certification et des modèles particuliers sont définis dans la configuration du handler. Lorsqu'une demande de certificat est reçue par l'autorité de certification pour ce modèle particulier, elle prend l'attribut "CommonName" de la demande de certificat et le place en tant qu'attribut SAN DNS , ce qui rend le certificat conforme.

Figure - 4

Automatisation transparente des réseaux de stockage SAN Récapitulatif de la conformité

Nous avons abordé certains des points problématiques de la génération d'attributs SAN et de l'intégration transparente qui aiderait à tenir les rênes de l'émission et de la conformité. Nous avons également présenté la toute dernière version de CMS 5.0 (entrées de plaintes forcées et module de politique) qui peut être utilisée pour rendre possible la résistance aux pannes et aux temps d'arrêt des applications.

Autres grandes fonctionnalités et améliorations de CMS 5.0 :

• des flux de travail plus robustes pour le renouvellement des certificats
• prise en charge de la gestion des certificats NetScaler
• options améliorées de protection des bases de données
• plans de l'agent
• API web (interface de programmation d'applications) SDK PowerShell
• refonte complète de l'interface utilisateur

Grâce à ces nouvelles fonctionnalités, la plateforme de gestion des certificats numériques et de PKI de CSS, CMS, n'est pas seulement une nécessité, mais une force pour toute organisation ou entreprise.