csa certificate authority service
1.0.0
This is not an officially supported Google product. This code creates PoC demo environment for CSA Certificate Authority Service demo. This demo code is not built for production workload.
Ce guide d'architecture permet un déploiement rationalisé et sécurisé du service d'autorité de certification (CAS). Il crée une autorité de certification racine ainsi que deux autorités de certification subordonnées et un certificat feuille. Ces autorités de certification sont hautement disponibles, évolutives et simples à maintenir, vous permettant de créer une infrastructure à clé publique (PKI) privée pour affirmer les identités via des certificats et établir une racine de confiance entre vos charges de travail.
Bien que ce guide d'architecture se concentre sur un déploiement CAS complet - désigné par l'architecture 1 dans la figure ci-dessous (c'est-à-dire une architecture dans laquelle toutes les autorités de certification sont hébergées dans Google Cloud) - CAS est extrêmement flexible et permet à votre organisation de créer une PKI privée dans une variété de domaines. de différentes manières, comme illustré dans le diagramme ci-dessous.
Nous fournirons également des détails sur la façon d'utiliser CSR (Certificate Signing Request) pour implémenter une architecture hybride, dans laquelle les autorités de certification peuvent résider en dehors de GCP (architectures 2 et 3).
Service d'autorité de certification (CAS) - Le service d'autorité de certification est un service Google Cloud hautement disponible et évolutif qui vous 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.
Service de gestion de clés (KMS) : le service de gestion de clés cloud vous permet de créer, d'importer et de gérer des clés cryptographiques et d'effectuer des opérations cryptographiques dans un seul service cloud centralisé. Vous pouvez utiliser ces clés et effectuer ces opérations en utilisant Cloud KMS directement, en utilisant Cloud HSM ou Cloud External Key Manager, ou en utilisant des intégrations de clés de chiffrement gérées par le client (CMEK) dans d'autres services Google Cloud.
Google Cloud Storage (GCS) – Cloud Storage est un service géré permettant de stocker des données non structurées. Stockez n'importe quelle quantité de données et récupérez-les aussi souvent que vous le souhaitez.
Lors de la conception d'une PKI avec GCP CAS, les limites suivantes doivent être prises en compte ainsi que les quotas, les limites et les limitations connues :
| Ressource | Unité | Valeur |
|---|---|---|
| AC en attente 1 | par emplacement par projet | 100 |
| AC | par emplacement par projet | 1 000 |
| Certificats révoqués non expirés 2 | par autorité de certification ou liste de révocation de certificats (CRL) | 500 000 |
1 autorité de certification (CA) en attente est une autorité de certification subordonnée qui a été créée mais pas encore activée et qui se trouve donc dans l'état AWAITING_USER_ACTIVATION.
2 CRL peut contenir au maximum 500 000 certificats révoqués non expirés. Si vous tentez de révoquer une valeur supérieure à cette limite, la demande de révocation échoue. Si vous devez révoquer plus de 500 000 certificats, nous vous recommandons d'attendre que les certificats révoqués existants aient expiré ou de révoquer le certificat de l'autorité de certification émettrice.
##Instructions Terraform :
Connectez-vous à votre organisation et attribuez-vous un rôle d'administrateur de service CA et d'administrateur Cloud KMS sur le projet à utiliser pour le déploiement.
Si un nouveau projet doit être créé et activer la facturation. Suivez les étapes de ce guide.
Ouvrez Cloud Shell et clonez le dépôt git suivant à l'aide de la commande ci-dessous :
git clone https://github.com/GCP-Architecture-Guides/csa-certificate-authority-service.git
Accédez au dossier csa-certificate-authority-service.
cd csa-certificate-authority-service</th>
Exporter l'identifiant du projet dans la variable Terraform
export TF_VAR_demo_project_id=[YOUR_PROJECT_ID]
Dans le dossier csa-certificate-authority-service, exécutez les commandes ci-dessous dans l'ordre.
terraform init terraform plan terraform apply
si vous y êtes invité, autorisez l’appel API.
Une fois le déploiement terminé, il publiera le résumé de sortie des actifs orchestrés. Il déploie les ressources en cinq minutes.
Après avoir terminé la démo, accédez au dossier certificate-authority-service et exécutez la commande ci-dessous pour détruire toutes les ressources de démonstration.
terraform destroy
##Résumé de Terraform :
| Piscine | Californie | Validité | État | Nom du sujet | Région | Étage |
|---|---|---|---|---|---|---|
| Pool racine de démonstration | Autorité de certification racine | 10 ans | Activé | Organisation : Démo CA CN : Démo ID de ressource : [par défaut] | us-central1 (Iowa) | Entreprise |
| Démo-Sous-Pool | Sous-autorité de certification avec autorité de certification racine dans Google Cloud | 3 ans | Activé | Organisation : Démo CA CN : Démo ID de ressource : [par défaut] | us-central1 (Iowa) | Entreprise |
| Démo-Sous-Pool-2 | Sous-autorité de certification avec autorité de certification racine dans Google Cloud | 3 ans | Activé | Organisation : Démo CA CN : Démo ID de ressource : [par défaut] | nous-est1 | Entreprise |
| Piscine | Méthodes RSE acceptées | Clés et algorithmes autorisés | Taille de clé et algorithme | Options de publication | Valeurs de base configurées | Contraintes d'extension configurées | Contraintes d'identité configurées |
|---|---|---|---|---|---|---|---|
| Pool racine de démonstration | Autoriser tout | Aucune restriction | RSA_PKCS1_4096_SHA256 | Vers le bucket GCS au format PEM | Aucun | Copiez toutes les extensions des demandes de certificat | Copier le sujet et les SAN des demandes de certificat |
| Démo-Sous-Pool | Autoriser tout | Aucune restriction | RSA_PKCS1_4096_SHA256 | Vers le bucket GCS au format PEM | Aucun | Copiez toutes les extensions des demandes de certificat | Copier le sujet et les SAN des demandes de certificat |
| Démo-Sous-Pool-2 | Autoriser tout | Aucune restriction | RSA_PKCS1_4096_SHA256 | Vers le bucket GCS au format PEM | Aucun | Copiez toutes les extensions des demandes de certificat | Copier le sujet et les SAN des demandes de certificat |
Meilleures pratiques pour le service d’autorité de certification
Le service d'autorité de certification de Google Cloud comporte plusieurs exigences en matière de journalisation et de surveillance pour garantir la sécurité et l'intégrité du service. Ces exigences comprennent les éléments suivants :
Journalisation d'audit : les opérations de journalisation effectuées sur le service, telles que l'émission, le renouvellement et la révocation de certificats, sont enregistrées et peuvent être auditées par les clients.
Notifications d'événements : les clients peuvent recevoir des notifications d'événements importants, tels que l'expiration d'un certificat, par e-mail ou via un webhook.
Transparence des certificats : tous les certificats émis sont enregistrés dans les journaux de transparence, ce qui permet un audit de l'émission et de la révocation des certificats.
Surveillance de la sécurité et de la disponibilité : les équipes de sécurité et d'exploitation surveillent en permanence le service pour détecter les menaces de sécurité potentielles et les problèmes de disponibilité.
Conformité : le service d'autorité de certification de Google Cloud est conforme à diverses normes qui spécifient les exigences de sécurité et de fonctionnement des autorités de certification.
Dans l’ensemble, ces exigences en matière de journalisation et de surveillance visent à offrir aux clients transparence et visibilité sur le service, tout en garantissant également la sécurité et la disponibilité du service.
Les services Google Cloud rédigent des journaux d'audit pour vous aider à répondre aux questions : "Qui a fait quoi, où et quand ?" au sein de vos ressources Google Cloud.
Les types de journaux d'audit suivants sont disponibles pour CA Service :
Journaux d'audit des activités d'administration
Inclut les opérations « admin write » qui écrivent des métadonnées ou des informations de configuration.
Vous ne pouvez pas désactiver les journaux d'audit des activités d'administration.
Journaux d'audit d'accès aux données
Inclut les opérations de « lecture administrateur » qui lisent les métadonnées ou les informations de configuration. Inclut également les opérations de « lecture de données » et « d'écriture de données » qui lisent ou écrivent des données fournies par l'utilisateur.
Pour recevoir les journaux d'audit d'accès aux données, vous devez les activer explicitement.
Pour les journaux d'audit spécifiques créés par le service d'autorité de certification, veuillez vous référer.
Les journaux d’audit des activités d’administration sont toujours activés ; vous ne pouvez pas les désactiver.
Les journaux d'audit d'accès aux données sont désactivés par défaut et ne sont écrits que s'ils sont explicitement activés.
Pour plus d’informations sur l’activation de tout ou partie de vos journaux d’audit d’accès aux données, consultez Activer les journaux d’audit d’accès aux données.
Dans la console Google Cloud, vous pouvez utiliser l'explorateur de journaux pour récupérer les entrées de votre journal d'audit pour votre projet, dossier ou organisation Cloud :
Dans la console Google Cloud, accédez à la page Journalisation > Explorateur de journaux.
Sélectionnez un projet, un dossier ou une organisation Cloud existant.
Dans le volet Générateur de requêtes, procédez comme suit :
protoPayload.serviceName="privateca.googleapis.com"
Cloud Monitoring peut être utilisé pour surveiller les opérations effectuées sur les ressources dans le service d'autorité de certification.
Utilisez les instructions suivantes pour activer les alertes recommandées.
Accédez à la page Présentation du service CA dans la console Google Cloud.
En haut à droite de la page Présentation, cliquez sur + 5 alertes recommandées .
Activez ou désactivez chaque alerte en lisant sa description.
Certaines alertes prennent en charge des seuils personnalisés. Par exemple, vous pouvez spécifier quand vous souhaitez être alerté en cas d'expiration d'un certificat d'autorité de certification ou le taux d'erreur en cas de taux élevé d'échecs de création de certificat.
Toutes les alertes prennent en charge les canaux de notification.
Cliquez sur Soumettre une fois que vous avez activé toutes les alertes souhaitées.
Documenter les politiques et les modèles de certificat
Contraintes d'identité
Contraintes d'extension
Conditions d'utilisation clés
Identificateurs de stratégie
Rallonges
Pour atténuer le risque d'abus, les politiques de certificat doivent être revues pour garantir que les modèles ont des fonctionnalités approuvées et définies.
Créer un plan de réponse aux compromissions de l'autorité de certification
Éduquer toutes les parties prenantes
Examiner les politiques de sécurité et de communication de l'AC au moins une fois par an
Établir des plans d'AC de secours
Inventaire des autorités de certification
Vérifiez que seules les autorités de certification approuvées sont utilisées
Assurez-vous que seules les racines approuvées sont fiables
Inventorier les autorités de certification racine fiables sur les systèmes des parties de confiance
Examiner et vérifier les autorisations pour les modèles de certificats existants
Appliquer la vérification de révocation sur les systèmes des parties utilisatrices
Activer les journaux d'audit et les alertes
Identifiez le compromis en fonction de la conception des alertes et des rapports
Établir une compréhension claire de ce qui s’est passé
Qui a détecté l'incident.
Si disponible, qui a commis l’incident.
Lorsque l'autorité de certification a été compromise.
Où l'incident s'est produit.
Quelles racines, sous-CA et nombre de certificats d'utilisateur final affectés par l'incident.
La cause sous-jacente présumée de l’incident.
Quelles mesures correctives ont été prises ou seront prises pour remédier à la cause sous-jacente de l'incident.
Une liste des certificats et des domaines impliqués dans la violation.
Comment l’incident a-t-il été détecté ?
Description détaillée de l'exploit.
Détails sur l'infrastructure qui a été compromise.
Détails sur la façon dont l’infrastructure a été compromise.
Une chronologie détaillée des événements.
La vulnérabilité a-t-elle été détectée par les opérations normales ? Si ce n’était pas le cas, pourquoi ?
La vulnérabilité a-t-elle été découverte lors de l’audit le plus récent ? Si oui, la vulnérabilité a-t-elle été corrigée ? Si la vulnérabilité n’a pas été corrigée, pourquoi pas ?
Cette vulnérabilité a-t-elle été détectée lors de l'audit le plus récent ? Dans la négative, veuillez expliquer pourquoi.
Quels changements politiques doivent être apportés ?
Toute autre information appropriée.
Activer l’équipe de réponse aux incidents
Contenir et isoler l'environnement d'autorité de certification concerné a. Pour empêcher une autorité de certification de délivrer des certificats, reportez-vous
Établir un plan pour communiquer l'impact et les prochaines étapes d'atténuation aux parties prenantes concernées (internes/externes)
Une fois l’enquête terminée et le confinement vérifié, effectuez les opérations suivantes :
Révoquez et réinitialisez les informations d'identification pour toutes les identités compromises qui ont été mappées à un rôle qui fournit des autorisations élevées pour les autorités de certification et les politiques/templates.reference-1 et reference-2 associés.
Révoquer les autorités de certification compromises et les certificats associés et établir une nouvelle référence d'autorités de certification
Ajouter au statut CRL/mettre à jour dans le répondeur OCSP (s'il n'est pas automatisé) pour informer les sujets, les parties utilisatrices et les fournisseurs
Révoquer les certificats existants et réémettre les certificats à partir de la nouvelle référence des autorités de certification
Supprimer/remplacer les certificats racine
Vérifier que la vérification de révocation est activée sur les systèmes des parties de confiance
Valider les remplacements de certificat et de racine
Suivre et rendre compte des progrès
Veuillez consulter ci-dessous le coût mensuel estimé pour exécuter cet environnement de démonstration. Notez que cela a été estimé au moment de la création du modèle, l'estimation peut changer avec le temps et varier selon la région. Veuillez consulter le coût de chaque ressource sur le calculateur de tarification Google Cloud.
| Référence DevOps | UGS Entreprise | |
|---|---|---|
| Frais CA mensuels | 20 $ | 200 $ |
| Frais de certificat | 0-50 000 à 0,3 $ 50 000 à 100 000 à 0,03 $ 100 000+ à 0,0009 $ Hiérarchisation à travers les autorités de certification | 0-50 000 à 0,5 $ 50 000 à 100 000 à 0,05 $ 100 000+ à 0,001 $ Hiérarchisation à travers les autorités de certification |
| Prise en charge HSM pour la clé CA | ||
| Clé BYO CA | X | |
| Certificats suivis et révocation | X | |
| RPS | 25 | 7 |
| Optimisé pour... | Volume élevé, durée de vie courte | Faible volume, longue durée de vie |
Présentation du CAS
Présentation du blog CAS
Vidéos pédagogiques CAS
Dépôt GitHub CAS
