Le Certificate Authority Service simplifie, automatise et personnalise le déploiement, la gestion et la sécurité des autorités de certification (CA) privées. Découvrez trois options de conception pour votre Google Cloud Certificate Authority Service.
Trois façons d'articuler les autorités de certification racines et subordonnées dans vos projets et votre organisation Google Cloud
Certificate Authority Service est un service entièrement géré qui permet de simplifier, d'automatiser et de personnaliser le déploiement, la gestion et la sécurité des autorités de certification (CA) privées.
Si votre organisation provisionne et gère aujourd'hui des certificats privés pour des workloads et des Internal SSL load balancers dans Google Cloud, le Certificate Authority Service vous permet de supprimer la création et la rotation manuelles des certificats, tout en appliquant des contrôles d'accès stricts.
Cet article passe en revue les avantages et les inconvénients de trois options de conception pour la mise en œuvre d'un Certificate Authority Service, soit trois façons d'articuler les CA racines et subordonnées au sein de vos projets et de votre organisation Google Cloud.
Toutes s'appuient sur le niveau de service Enterprise CA pool (et non sur le niveau DevOps, plus limité) ainsi que sur une hiérarchie d'autorité de certification à deux niveaux. (Il est possible d'aller plus loin, mais je recommande de ne pas dépasser trois niveaux.)
Option 1 : configuration des CA à l'échelle de l'organisation
Dans cette architecture, on déploie une seule CA racine et une CA subordonnée par environnement. C'est l'approche la plus directe : elle permet de piloter l'ensemble des CA et des certificats de façon centralisée et d'appliquer les contrôles IAM nécessaires.
Une seule CA racine est à installer sur l'ensemble des clients. La politique d'émission de certificats permet de garantir que chaque CA subordonnée ne délivre des certificats que pour les domaines attendus.
Le revers de cette option : avec une seule CA racine, tous les clients font confiance à tous les certificats, quel que soit l'environnement (les systèmes de production feront par exemple confiance aux systèmes de pré-production, et réciproquement).
Une configuration à CA racine unique complique aussi les tests, puisque la moindre erreur de configuration se répercute sur toutes les CA subordonnées. Mieux vaut éviter de toucher à la CA racine et déployer plutôt de nouvelles CA subordonnées pour valider vos changements.
Option 2 : configuration des CA par type d'environnement
Ici, on met en place une CA racine et une CA subordonnée distinctes par type d'environnement. Toutes les CA sont regroupées dans un même projet, qui sépare production et pré-production, tandis que les autres ressources cloud sont réparties dans des projets dédiés (développement, pré-production, production, etc.).
Selon le type d'environnement, les services exécutés dans le projet récupèrent le certificat requis auprès de la CA subordonnée correspondante. Une politique d'émission de certificats garantit là encore que chaque CA subordonnée ne délivre des certificats que pour les domaines attendus.
Cette configuration permet de tester les changements dans un environnement amont avant de les passer en production.
Son inconvénient : il faut installer différentes CA racines sur les clients selon leur type d'environnement.
Option 3 : configuration des CA par projet
Dans cette architecture, on déploie une CA racine et une CA subordonnée distinctes pour chaque projet, afin d'assurer une séparation totale. Les changements peuvent être testés sans difficulté dans un environnement amont, sans impacter les autres configurations de CA.
Multiplier les CA racines implique d'en installer plusieurs sur les clients, selon l'environnement dans lequel ils évoluent.
Si une relation de confiance entre plusieurs environnements est nécessaire, il faut installer plusieurs CA racines sur le client concerné.
C'est l'option la plus complexe sur le plan de l'architecture et de la maintenance, mais c'est aussi celle qui offre le meilleur niveau de sécurité grâce à la séparation.
Pour conclure
Le choix d'une option de conception pour le Certificate Authority Service dépend de la façon dont votre organisation arbitre entre exigences de sécurité, simplicité de gestion et maîtrise des coûts.
Contactez-nous pour en savoir plus sur la collaboration avec DoiT. Nous sommes à vos côtés si vous avez besoin de conseils sur la conception d'un Certificate Authority Service (CAS) ou sur tout autre sujet lié au cloud.