Bonnes pratiques pour Certificate Manager

Cette page décrit les bonnes pratiques pour configurer et gérer les certificats sur Google Cloud à l'aide du gestionnaire de certificats et de Certificate Authority Service (CA Service). Cette page explique comment concevoir votre architecture de gestion des certificats.

Avant de lire cette page, assurez-vous de bien connaître les pages Présentation de Certificate Manager et Présentation de Certificate Authority Service.

Concevoir votre architecture de gestion des certificats

Lorsque vous concevez une stratégie de gestion des certificats d'entreprise, vous devez tenir compte des principaux cas d'utilisation de votre organisation et du cycle de vie complet de vos certificats. Ces décisions ont une incidence sur le coût, les frais opérationnels et la facilité d'implémentation des fonctionnalités de gestion des certificats, telles que l'émission, la révocation et la rotation.

Les sections suivantes expliquent nos recommandations pour chaque choix de conception.

Choisir un type de certificat

Lorsque vous créez un certificat, vous devez veiller à sélectionner un type de certificat adapté à votre cas d'utilisation, en fonction des exigences de votre application et des règles de sécurité de votre organisation.

Pour analyser le type de certificat qui pourrait vous convenir le mieux, consultez l'organigramme suivant :

Évaluez le type de certificat à choisir.
Évaluez le type de certificat à choisir (cliquez pour agrandir).

Voici quelques liens vers la documentation utile concernant les sujets mentionnés dans l'organigramme :

Simplifier la hiérarchie de votre service d'autorité de certification privée

Nous vous recommandons de simplifier au maximum la hiérarchie de votre service d'autorité de certification pour assurer le bon fonctionnement et le dépannage. Vous devez stocker votre autorité de certification racine dans son propre projet Google. L'autorité de certification racine signe quelques autorités de certification intermédiaires, qui émettent ensuite les certificats finaux.

Cette structure hiérarchique plate améliore la transparence, simplifie les processus de révocation des certificats et réduit le risque d'erreurs de configuration. Bien que CA Service soit un service régional, une autorité de certification racine d'une région peut signer des autorités de certification subordonnées situées dans d'autres régions.

Suivez ces bonnes pratiques dans la hiérarchie de votre service d'autorité de certification, comme indiqué dans le schéma :

  • Isolez votre autorité de certification racine dans son propre projet Google Cloud pour signer l'autorité de certification émettrice.

  • Créez des autorités de certification émettrices dans des pools d'autorités de certification hébergés dans des projets distincts. Hébergez ces pools dans des projets distincts et segmentez-les par zone géographique (région), cycle de vie du développement logiciel (développement, production, test) ou cas d'utilisation spécifique.

  • Configurez Certificate Manager pour qu'il utilise un pool d'autorités de certification émettrices pouvant émettre des certificats privés approuvés pour les ressources compatibles.

Conception recommandée de la hiérarchie des CA.
Conception recommandée pour votre hiérarchie d'AC (cliquez pour agrandir).

Utiliser une couverture complète des noms d'hôte

Nous vous recommandons de vous assurer que vos certificats couvrent suffisamment de noms d'hôte pour tous les domaines et sous-domaines que vos services doivent protéger. Une couverture de nom d'hôte inadéquate peut entraîner des avertissements de sécurité pour les utilisateurs, des interruptions de service et une expérience utilisateur négative.

Évitez d'utiliser un seul certificat pour plusieurs domaines. Si le certificat unique ne parvient pas à se renouveler ou est supprimé accidentellement, tous les domaines qu'il couvre deviennent non sécurisés. Nous vous recommandons de créer des certificats distincts pour différents domaines.

Si vous prévoyez d'ajouter des sous-domaines ou des services ultérieurement, utilisez des caractères génériques pour les inclure dans votre certificat dès le début. Par exemple, un certificat générique pour *.myorg.example.com ne sécurise que le premier niveau de sous-domaine, mais pas les niveaux de sous-domaine plus profonds tels que sub.subdomain.myorg.example.com.

Utiliser des certificats gérés par Google

Pour une gestion efficace et une utilisation facile des certificats publics, nous vous recommandons d'utiliser des certificats gérés par Google. Cette approche réduit considérablement les coûts opérationnels en automatisant des tâches telles que la rotation des certificats et en éliminant les risques associés aux renouvellements manuels.

De plus, les certificats gérés par Google s'intègrent parfaitement aux autres servicesGoogle Cloud . Les certificats gérés par Google sont valides pendant 90 jours. Le processus de renouvellement commence environ un mois avant leur expiration.

Développer et améliorer les performances de vos certificats

Les sections suivantes décrivent les bonnes pratiques pour mettre à l'échelle vos certificats et améliorer les performances des actions liées aux certificats, telles que le provisionnement et le renouvellement.

Appliquer un déploiement décentralisé pour Certificate Manager

Utilisez le gestionnaire de certificats par projet et par emplacement. Cela signifie que vos certificats sont stockés dans le même projet que leurs ressources associées, dans la même région. Cette stratégie améliore la fiabilité en empêchant la réutilisation des certificats dans différentes régions et en minimisant efficacement l'impact en cas de défaillance régionale (peu probable).

De plus, comme les quotas et les limites sont appliqués au niveau du projet Google Cloud , le déploiement de Certificate Manager dans plusieurs projets augmente vos quotas globaux. En effet, l'utilisation d'une ressource dans un projet n'affecte pas votre quota disponible dans un autre projet.

Utiliser des certificats avec des clés ECDSA

Cette section explique pourquoi nous recommandons ECDSA plutôt que RSA comme bonne pratique pour les clés de signature de certificat.

Quel type de clé utiliser ?

ECDSA P-256 est le type de clé recommandé pour la plupart des certificats TLS, car il offre une sécurité cryptographique renforcée, d'excellentes performances pour les opérations de signature et une utilisation efficace de la bande passante réseau.

Voici quelques raisons possibles d'utiliser d'autres types de clés de certificat :

  • Si vous devez prendre en charge les anciens clients qui ne sont pas compatibles avec les certificats ECDSA, vous pouvez fournir des certificats RSA-2048 en plus des certificats ECDSA P-256.
  • Si vous avez des exigences de conformité spécifiques qui vous obligent à utiliser des clés de taille plus importante ou des types de clés particuliers, vous pouvez utiliser les clés ECDSA P-384, RSA-2048, RSA-3072 et RSA-4096.

Pourquoi choisir ECDSA plutôt que RSA ?

Le principal avantage d'ECDSA réside dans sa capacité à fournir un niveau de sécurité cryptographique équivalent avec des clés beaucoup plus petites que celles de RSA. Cette efficacité se traduit par des avantages concrets en termes de performances et de ressources. Une clé plus petite n'implique pas une sécurité plus faible. ECDSA est basé sur le problème du logarithme discret de la courbe elliptique, qui offre une sécurité plus élevée par unité de clé et, dans certains cas, une meilleure efficacité de calcul par rapport à RSA.

Exemple :

  • Une clé ECDSA de 256 bits offre un niveau de sécurité similaire à celui d'une clé RSA-3072.
  • Une clé ECDSA 384 bits offre un niveau de sécurité supérieur à celui de n'importe quelle taille de clé RSA largement acceptée.

Principaux avantages d'ECDSA :

  • Performances : les opérations de signature ECDSA sont beaucoup moins gourmandes en ressources de calcul que les opérations RSA pour un niveau de sécurité équivalent. Cela réduit la charge du processeur et la latence, ce qui est essentiel pour les systèmes à haut débit ou sensibles à la latence.

  • Efficacité : les clés et les signatures plus petites nécessitent moins de bande passante et de stockage, ce qui est particulièrement utile pour les environnements aux ressources limitées, comme les appareils mobiles et IoT.

Vous pouvez créer la règle d'administration personnalisée suivante pour appliquer l'utilisation de types de clés spécifiques dans vos certificats. Cela ne s'applique qu'aux certificats gérés par Google provenant de CA Service (certificats privés gérés par la confiance), et non aux certificats autogérés ni aux certificats gérés par Google avec confiance publique.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
    resourceTypes: \
    - certificatemanager.googleapis.com/CertificateIssuanceConfig \
    methodTypes: \
    - CREATE \
    - UPDATE \
    condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
    actionType: ALLOW \
    displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
    description: Only ECDSA_P256 certificates are allowed from CA Service.

Utiliser un pool d'autorités de certification pour émettre des certificats à partir d'autorités de certification privées

Nous vous recommandons d'utiliser des pools d'AC pour vos AC émettrices. Un pool d'autorités de certification est une collection de plusieurs autorités de certification disposant d'une règle d'émission de certificats et d'une stratégie Identity and Access Management (IAM) communes. L'utilisation d'un pool d'autorités de certification augmente le nombre total de requêtes par seconde (RPS) effectives en équilibrant la charge et en distribuant les demandes de certificat entrantes sur toutes les autorités de certification activées du pool. Cela permet d'améliorer les performances sans impacter la charge de travail ni les modifications côté client.

Les pools d'autorités de certification fournissent un point de terminaison unique pour l'émission et la récupération de certificats. Vous pouvez utiliser des pools d'autorités de certification pour effectuer une rotation sécurisée de vos autorités de certification sans entraîner de temps d'arrêt en raison de l'expiration ou de la compromission des certificats.

Utiliser des mappages de certificats

Pour garantir une évolutivité optimale, nous vous recommandons d'utiliser des maps de certificats avec les ressources compatibles. Les mappages de certificats sont conçus pour évoluer. Ils acceptent des milliers d'entrées de certificat par défaut et peuvent gérer des millions de certificats. Lorsqu'elles sont utilisées par des équilibreurs de charge, les entrées de mappage de certificats ont la priorité sur les autres certificats, tels que les certificats SSL Compute Engine.

Les mappages de certificats vous permettent également de configurer la logique de sélection de vos certificats. Par exemple, lors d'un handshake, si le nom d'hôte d'un client ne correspond à aucune entrée dans le mappage de certificat provisionné, l'équilibreur de charge renvoie le certificat principal.

Choisir le bon type d'autorisation de domaine

Pour émettre des certificats gérés par Google, vous pouvez prouver que vous êtes propriétaire du domaine en utilisant l'autorisation de l'équilibreur de charge ou l'autorisation DNS.

Le tableau suivant décrit les points à prendre en compte pour chaque approche :

Fonctionnalité Autorisation d'équilibreur de charge Autorisation DNS
Complexité de la configuration Ne nécessite aucune étape de configuration supplémentaire ni aucune modification de votre configuration DNS. Vous devez créer une autorisation DNS et ajouter l'enregistrement CNAME correspondant à votre configuration DNS.
Sécurité du réseau L'équilibreur de charge doit être entièrement accessible via Internet sur le port 443, y compris la configuration DNS pour tous les domaines desservis par un certificat. L'autorisation de l'équilibreur de charge ne fonctionne pas avec d'autres configurations. L'autorisation DNS fonctionne avec des configurations très complexes, telles que des ports autres que le port 443 et des couches CDN devant le proxy cible.
Vitesse de provisionnement Vitesse de provisionnement plus rapide. Vous ne pouvez provisionner des certificats qu'une fois l'équilibreur de charge entièrement configuré et qu'il diffuse du trafic réseau. Vous pouvez provisionner des certificats à l'avance, avant que le proxy cible ne soit prêt à diffuser le trafic réseau.
Certificats génériques Non compatible Compatible

Automatiser la rotation des certificats autogérés

Contrairement aux certificats gérés par Google, les certificats autogérés doivent être remplacés manuellement avant leur expiration. Nous vous recommandons d'automatiser ce processus à l'aide des offres de gestion du cycle de vie des certificats (CLM) de votre choix. Cela permet de réduire les erreurs et les temps d'arrêt, et d'assurer l'efficacité opérationnelle.

Vous pouvez également utiliser des mappages de certificats pour orchestrer une rotation de certificats fluide. Ce processus comprend les étapes suivantes :

  1. Surveillez l'expiration des certificats à l'aide de Cloud Monitoring et des alertes. Nous vous recommandons de créer une alerte pour les certificats qui expirent dans les 15 à 30 prochains jours.
  2. Générez une requête de signature de certificat (CSR) et une clé privée à envoyer à votre autorité de certification.
  3. Envoyez votre CSR et votre clé privée à votre autorité de certification, puis récupérez le nouveau certificat.

  4. Importez le nouveau certificat dans le gestionnaire de certificats vers un mappage de certificats approprié.

    • Si les noms de domaine du nouveau certificat correspondent à ceux d'un certificat sur le point d'expirer, utilisez la méthode UpdateCertificate sur la ressource de certificat existante.
    • Si le nouveau certificat comporte des noms de domaine différents, utilisez d'abord la méthode CreateCertificateRequest avec les nouveaux fichiers PEM (Privacy-Enhanced Mail) pour le créer. Ensuite, utilisez la méthode UpdateCertificateMapEntry pour remplacer l'ancienne référence du certificat dans le mappage de certificats par la nouvelle.

    Important : Vous devez effectuer ce processus en un seul appel d'API, sans entraîner de temps d'arrêt.

Appliquer des contrôles d'accès appropriés

Nous vous recommandons de tenir compte des principes du moindre privilège et de séparation des tâches lorsque vous configurez vos contrôles d'accès. Les sections suivantes expliquent ces recommandations plus en détail.

Appliquer le principe du moindre privilège

Lorsque vous attribuez des autorisations pour gérer les certificats, tenez compte du principe du moindre privilège et n'accordez que les autorisations minimales nécessaires pour effectuer une tâche. Nous vous déconseillons vivement d'utiliser les rôles IAM de base. Attribuez plutôt des rôles Certificate Manager et CA Service prédéfinis ou personnalisés pour atténuer tout risque d'incident de sécurité lié à un accès trop privilégié.

Planifier la séparation des tâches

Nous vous recommandons de conserver des identités et des autorisations distinctes pour les administrateurs de certificats et les utilisateurs qui disposent du rôle d'émetteur ou de demandeur de certificats. Pour ce faire, créez des groupes d'administrateurs et de demandeurs distincts en haut de la hiérarchie des ressources pour vos utilisateurs.

Assurez-vous que votre groupe d'administrateurs est responsable des actions suivantes :

  • Gérez et entretenez votre infrastructure de certificats, comme le provisionnement de l'autorité de certification.
  • Configurez les modèles de certificat.
  • Gérez vos listes de révocation de certificats (CRL) et vos répondeurs OCSP (Online Certificate Status Protocol).
  • Implémentez des règles de sécurité pour votre AC.

Pour les projets qui hébergent une autorité de certification racine, évitez d'attribuer des rôles de base tels que Propriétaire (roles/owner), Éditeur (roles/editor) et Administrateur de services d'autorité de certification (roles/privateca.admin) à un utilisateur ou un groupe. Cette pratique permet d'éviter les suppressions accidentelles, les erreurs de configuration et la surexposition. À la place, utilisez Privileged Access Manager (PAM) pour un accès opportun (JIT, just-in-time) selon les besoins, avec justification et approbations après l'installation et la configuration de l'autorité de certification racine.

Assurez-vous que le groupe de demandeurs est responsable des opérations quotidiennes de traitement des demandes de certificat et d'émission des certificats en fonction de modèles prédéfinis.

Le tableau suivant répertorie les rôles IAM généralement associés à différentes fonctions :

Persona Description Rôles IAM
Administrateurs de certificats Configurer et gérer l'infrastructure d'AC et de certificats. Propriétaire du gestionnaire de certificats (roles/certificatemanager.owner),
Administrateur du service CA (roles/privateca.admin)
Demandeur de certificat Demandez des certificats pour les charges de travail. Demandeur de certificat du service Certificate Authority (roles/privateca.certificateRequester)
Charges de travail (comptes de service d'automatisation) Utilisé par les charges de travail ou dans les pipelines pour demander des certificats. Demandeur de certificat de charge de travail du service Certificate Authority (roles/privateca.workloadCertificateRequester)
Ingénieurs en sécurité ou propriétaires de l'infrastructure à clé publique Gérez les règles, la révocation et le cycle de vie des certificats. Responsable des opérations du service CA (roles/privateca.caManager), Gestionnaire de certificats du service d'autorité de certification (roles/privateca.certificateManager)
Ingénieurs DevOps ou de plate-forme Gérez le déploiement de certificats sur les équilibreurs de charge, et plus encore. Éditeur du gestionnaire de certificats (roles/certificatemanager.editor)
Auditeur ou responsable de la conformité Surveillez les certificats et leur utilisation. Lecteur du gestionnaire de certificats (roles/certificatemanager.viewer), Auditeur du service d'autorité de certification (roles/privateca.auditor)

Utiliser l'autorisation DNS par projet pour les déploiements multirégionaux et multicloud

Nous vous recommandons d'utiliser l'approche d'autorisation DNS par projet pour gérer indépendamment plusieurs autorisations pour des projets dans plusieurs régions, plusieurs clouds et tout au long du cycle de développement logiciel (SDLC).

La compartimentation des autorisations DNS permet de s'assurer que chaque projet conserve son propre ensemble distinct d'enregistrements et d'autorisations DNS. Ce niveau de contrôle permet à chaque projet de gérer ses configurations DNS de manière autonome, sans interférer avec les opérations des autres projets ni être affecté par celles-ci. Par exemple, une équipe de développement peut expérimenter de nouvelles configurations DNS pour son application spécifique sans risquer d'avoir un impact négatif sur les systèmes de production ou d'autres projets en cours.

Utiliser des enregistrements CAA pour protéger vos domaines

Les enregistrements d'autorisation pour l'autorité de certification (CAA) sont un mécanisme de sécurité du système de noms de domaine (DNS). Les enregistrements CAA permettent aux propriétaires de domaines de contrôler entièrement la configuration des autorités de certification publiques qui peuvent émettre des certificats pour leurs domaines. Ce contrôle est important pour empêcher l'émission non autorisée de certificats. Avec CAA, la surface d'attaque pour les certificats frauduleux est réduite, ce qui rend les sites Web plus sécurisés.

Pour les certificats gérés par Google, nous vous recommandons d'autoriser manuellement les éléments suivants pour une fiabilité optimale de vos demandes d'émission et de renouvellement de certificats :

Cloud Logging, Cloud Monitoring et visibilité

Les sections suivantes décrivent les bonnes pratiques concernant la journalisation des audits et la surveillance de l'utilisation et de l'expiration des certificats.

Activer et agréger la journalisation d'audit

Pour surveiller toutes les ressources de votre organisation, regroupez les journaux d'audit des activités d'administration de tous les services, y compris Certificate Manager, dans un emplacement centralisé.

Cela permet à votre équipe de sécurité ou à votre auditeur d'examiner toute l'activité liée à la création ou à la modification des ressources Certificate Manager et CA Service en un seul endroit. Pour en savoir plus sur la configuration des journaux agrégés, consultez Agréguer et stocker les journaux de votre organisation.

Surveiller l'utilisation et l'expiration des certificats

Nous vous recommandons de configurer des alertes basées sur les journaux pour les événements importants de Certificate Manager, tels que l'utilisation de l'autorité de certification racine, l'expiration et la suppression des certificats. Ces alertes vous aident à trier les opérations, comme un taux d'échec élevé de création de certificats, et peuvent déclencher un processus en aval pour demander un nouveau certificat ou augmenter le quota.

Configurez les alertes et les règles de journaux suivantes pour les opérations liées aux privilèges :

Exigences de conformité

En règle générale, les cadres de conformité spécifient des attentes et des objectifs de haut niveau pour la gestion des certificats, plutôt que pour des produits ou des configurations spécifiques.

Par exemple, la norme PCI DSS (Payment Card Industry Data Security Standard) et le NIST (National Institute of Standards and Technology) exigent des organisations qu'elles documentent et mettent en œuvre des périodes de rotation pour les clés de signature. Ils imposent également la surveillance continue de l'inventaire et de toutes les clés et certificats de signature de confiance qui protègent les données des titulaires de carte.

Pour en savoir plus sur la façon dont les services Google Cloud peuvent vous aider à répondre aux exigences de différents cadres de conformité, consultez les ressources suivantes :

Étapes suivantes