Connecter un compte Google Cloud
Autoriser CISAPP en lecture seule sur un environnement Google Cloud (GCP) grâce à un compte de service dont CISAPP emprunte l’identité, pour inventorier les ressources cloud et remonter les constats de posture de sécurité.
Accès : administrateur d’entreprise. Fonctionnalité en bêta ; le connecteur doit être activé sur votre plateforme.
Comment ça fonctionne
Aucune clé n’est échangée ni stockée. Vous créez dans l’un de vos projets un compte de service en lecture seule et vous autorisez le compte de service de la plateforme CISAPP à emprunter son identité (rôle « Créateur de jetons du compte de service », sur ce compte de service uniquement). À chaque synchronisation, CISAPP obtient auprès de Google un jeton d’accès de courte durée (environ une heure) au nom de votre compte de service et lit vos configurations. Ce jeton n’est jamais enregistré : il reste en mémoire chez CISAPP et est réutilisé au plus une heure (renouvelé 5 minutes avant son expiration). Retirer l’autorisation côté Google Cloud empêche d’en obtenir de nouveaux : l’accès prend fin au plus tard à l’expiration du jeton en cours (une heure au maximum), sous réserve de la propagation IAM de Google. Pour un arrêt immédiat côté CISAPP, utilisez Déconnecter.
Prérequis
- Être administrateur de l’entreprise dans CISAPP.
- Disposer, dans Google Cloud, des droits pour créer un compte de service, créer un rôle personnalisé et attribuer des rôles IAM : par exemple Administrateur IAM de l’organisation (ou du projet), ou le propriétaire du projet. Sans organisation Google Cloud, ces droits sont requis sur chaque projet à analyser.
- Disposer de la CLI
gcloudconnectée à un compte habilité, ou de Cloud Shell. - Un compte de service ne peut être connecté qu’à une seule organisation CISAPP. Plusieurs comptes de service (donc plusieurs connexions) restent possibles dans une même organisation CISAPP.
- Le compte de service doit être un compte que vous avez créé (
nom@projet.iam.gserviceaccount.com). Les comptes gérés par Google (agents de servicegcp-sa-…et anciens agents de service Google, compte Compute par défaut…-compute@developer.gserviceaccount.com, compte App Engine) et les projets à nom de domaine hérités (exemple.com:projet) ne sont pas pris en charge. Il ne doit pas appartenir au projet de CISAPP.
Configurer Google Cloud
Les commandes ci-dessous sont celles du panneau de configuration de CISAPP. Le panneau les affiche déjà préremplies avec le jeton de vérification de votre connexion et l’adresse du compte de service de CISAPP : copiez-les depuis le panneau plutôt que d’utiliser les valeurs génériques de cette page (<JETON_DE_VERIFICATION> et <COMPTE_DE_SERVICE_CISAPP>).
Ouvrez Mon entreprise → Connecteurs, puis Connecter sur la carte Google Cloud. Le panneau Configurer Google Cloud affiche deux valeurs à copier :
- le compte de service CISAPP (plateforme) : l’adresse à autoriser ;
- le jeton de vérification : propre à cette connexion, de la forme
cisapp-verify-suivi de 32 caractères hexadécimaux.
Adaptez les variables.
PROJECT_IDest le projet qui hébergera le compte de service (son « projet d’accueil »),ORG_IDl’identifiant numérique de votre organisation (inutile sans organisation).bashPROJECT_ID="my-project-id" SA_NAME="cisapp-readonly" SA_EMAIL="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" ORG_ID="123456789012"Créez le compte de service, avec le jeton de vérification comme description : il prouve que vous contrôlez ce compte.
bashgcloud iam service-accounts create "$SA_NAME" --project="$PROJECT_ID" \ --display-name="CISAPP read-only" \ --description="<JETON_DE_VERIFICATION>"Si le compte de service existe déjà, mettez seulement sa description à jour :
bashgcloud iam service-accounts update "$SA_EMAIL" --project="$PROJECT_ID" \ --description="<JETON_DE_VERIFICATION>"Autorisez CISAPP à emprunter l’identité du compte de service, sur ce compte de service uniquement. Ne l’accordez jamais sur le projet, un dossier ou l’organisation : CISAPP refuse la connexion si ce rôle est accordé plus largement.
bashgcloud iam service-accounts add-iam-policy-binding "$SA_EMAIL" \ --project="$PROJECT_ID" \ --member="serviceAccount:<COMPTE_DE_SERVICE_CISAPP>" \ --role="roles/iam.serviceAccountTokenCreator"Enregistrez la définition du rôle personnalisé dans un fichier
role.yaml. Il ne contient que des permissions de lecture de métadonnées (voir la liste plus bas) : aucun accès aux données.yamltitle: CISAPP Posture Reader description: Read-only metadata access for CISAPP security posture scans. No data-plane access. stage: GA includedPermissions: - resourcemanager.projects.get - resourcemanager.projects.getIamPolicy - compute.instances.list - compute.firewalls.list - compute.networks.list - compute.subnetworks.list - compute.projects.get - storage.buckets.list - storage.buckets.getIamPolicy - cloudsql.instances.list - container.clusters.list - iam.serviceAccounts.get - iam.serviceAccounts.list - iam.serviceAccountKeys.list - cloudfunctions.functions.list - cloudfunctions.functions.getIamPolicy - run.locations.list - run.services.list - run.services.getIamPolicy - cloudkms.locations.list - cloudkms.keyRings.list - cloudkms.cryptoKeys.list - bigquery.datasets.get - bigquery.datasets.getIamPolicy - serviceusage.services.listCréez le rôle et attribuez-le au compte de service. Le rôle doit couvrir le projet d’accueil du compte de service (il doit pouvoir se lire lui-même) et les projets à analyser.
Avec une organisation Google Cloud : une seule attribution au niveau de l’organisation couvre tous ses projets, y compris le projet d’accueil.
bashgcloud iam roles create cisappPostureReader --organization="$ORG_ID" \ --file=role.yaml gcloud organizations add-iam-policy-binding "$ORG_ID" \ --member="serviceAccount:$SA_EMAIL" \ --role="organizations/$ORG_ID/roles/cisappPostureReader"Sans organisation : projet par projet. Remplacez
project-a project-bpar vos projets, sans oublier le projet d’accueil du compte de service. Le rôle est créé dans chacun.bashfor P in project-a project-b; do gcloud iam roles create cisappPostureReader --project="$P" \ --file=role.yaml gcloud projects add-iam-policy-binding "$P" \ --member="serviceAccount:$SA_EMAIL" \ --role="projects/$P/roles/cisappPostureReader" done
Activez les API dans le projet d’accueil du compte de service : ses appels y sont comptabilisés et limités.
bashgcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com serviceusage.googleapis.com \ --project="$PROJECT_ID"Les API des produits (Compute Engine, Cloud Storage, Cloud SQL…) n’ont pas à être activées pour CISAPP : un produit désactivé dans un projet n’a simplement rien à inventorier.
Rôles prédéfinis de secours
Si votre organisation interdit les rôles personnalisés, attribuez plutôt ces rôles prédéfinis au compte de service, sur l’organisation ou sur chaque projet (sans oublier le projet d’accueil) :
roles/browserroles/compute.networkViewerroles/cloudsql.viewerroles/container.clusterViewerroles/iam.serviceAccountViewerroles/cloudfunctions.viewerroles/run.viewerroles/cloudkms.viewerroles/bigquery.metadataViewerroles/serviceusage.serviceUsageViewerroles/storage.bucketViewer
Limite : ces rôles ne permettent pas de lire les règles d’accès (IAM) des buckets. Le contrôle des buckets publics reste alors « inconnu » : il ne crée ni ne résout de constat.
Connecter dans CISAPP
- Dans le panneau de configuration, cliquez J’ai terminé.
- Indiquez l’e-mail du compte de service (par exemple
cisapp-readonly@mon-projet.iam.gserviceaccount.com). - Indiquez éventuellement les projets à analyser, un identifiant par entrée (50 au maximum). Vide : tous les projets actifs que le compte de service peut lire, dans la limite d’un plafond fixé par la plateforme (100 par défaut) ; au-delà, seuls les premiers sont analysés et la synchronisation le signale.
- Vérifier l’accès : CISAPP contrôle que le compte de service existe, qu’il peut en emprunter l’identité, que le jeton figure dans sa description et que les projets sont lisibles.
- Contrôlez le compte de service affiché (son identifiant numérique), puis Connecter. La connexion devient active et la première synchronisation démarre.
Si vous fermez l’assistant avant la confirmation, la connexion reste En attente et le panneau de configuration est repris depuis sa fiche (le jeton de vérification reste le même). Une connexion en attente depuis plus de 7 jours sans activité est supprimée automatiquement.
Les droits IAM de Google se propagent avec un léger délai (de quelques secondes à quelques minutes). Si la vérification échoue juste après les commandes, patientez puis recommencez. De même, la première synchronisation peut signaler quelques erreurs partielles « non accordé » : la suivante les corrige.
Une fois la connexion active, la liste des projets est modifiable depuis la fiche de la connexion (Modifier le périmètre) ; l’e-mail du compte de service ne l’est pas.
Ce que CISAPP collecte
CISAPP n’effectue que des lectures (requêtes GET ; les lectures de politiques IAM utilisent la méthode POST de l’API Google, sans rien modifier) et ne lit que des configurations, jamais de contenu. Pour chaque projet analysé :
- projets Google Cloud (identifiant, état) et politique IAM du projet, résumée en compteurs (aucune adresse de membre n’est conservée) ;
- Compute Engine : instances, règles de pare-feu VPC, réseaux et sous-réseaux ;
- Cloud Storage : buckets (configuration et règles d’accès IAM, pas les objets) ;
- Cloud SQL : instances ;
- Google Kubernetes Engine (GKE) : clusters ;
- comptes de service et leurs clés gérées par l’utilisateur (métadonnées : âge, état) ;
- Cloud Functions et services Cloud Run (configuration et qui peut les invoquer) ;
- Cloud KMS : clés de chiffrement (métadonnées de rotation) ;
- BigQuery : jeux de données (configuration et accès publics) ;
- la liste des API activées dans chaque projet.
Les ressources sont visibles dans le menu Sécurité opérationnelle → Patrimoine cloud et sa Cartographie, avec leur région et leur localisation. Un produit que le compte de service ne peut pas lire est signalé comme non accordé dans le résultat de la synchronisation.
Ce que CISAPP ne lit jamais
CISAPP ne modifie rien dans votre environnement. Le rôle n’inclut aucune permission d’écriture ni de lecture de données. CISAPP ne lit jamais, et ne stocke donc jamais :
- le contenu des buckets (objets), les tables, lignes et requêtes BigQuery ;
- le matériel des clés de compte de service (aucune clé n’est créée, téléchargée ni utilisée), les secrets (Secret Manager), les clés KMS elles-mêmes (aucun chiffrement, déchiffrement ni signature) ;
- les variables d’environnement et les secrets des fonctions et services Cloud Run, les images et arguments des conteneurs ;
- les identifiants des clusters GKE (certificats, jetons), les mots de passe, certificats et valeurs d’options des instances Cloud SQL ;
- les clés de chiffrement des disques, les libellés, les sorties du port série, captures d’écran et attributs invités ;
- les adresses IP publiques elles-mêmes (seule l’existence d’une adresse publique est conservée) et les adresses des membres des politiques IAM.
Les métadonnées des instances et du projet Compute (par exemple scripts de démarrage, clés SSH) sont lues pour trois indicateurs seulement : enable-oslogin, block-project-ssh-keys et serial-port-enable. Google ne permet pas de demander une seule clé : les éléments sont donc demandés sous forme de paires clé/valeur et les valeurs transitent en mémoire pendant la lecture de la réponse ; seuls ces trois indicateurs sont conservés et rien d’autre n’est converti, stocké ni journalisé. Rien d’autre n’est stocké, journalisé ni transmis.
Constats de posture
Les constats apparaissent dans les constats de sécurité avec la source Posture Google Cloud. Une règle ne se déclenche que si l’information est certaine : un état inconnu (produit non accordé, lecture impossible, valeur absente de la réponse) ne crée ni ne résout de constat. 20 règles sont évaluées.
| Titre du constat | Gravité |
|---|---|
| Rôle de base Propriétaire ou Éditeur attribué dans le projet | Élevée ; moyenne si seuls des utilisateurs détiennent le rôle |
| Politique IAM du projet ouverte à allUsers ou allAuthenticatedUsers | Critique |
| Clé de compte de service gérée par l'utilisateur de plus de 90 jours | Moyenne |
| Instance de calcul exposée avec une adresse IP publique | Moyenne |
| Instance utilisant le compte de service par défaut avec accès complet aux API | Élevée |
| Connexion OS Login désactivée sur l'instance | Moyenne |
| Accès à la console série activé sur l'instance | Moyenne |
| Règle de pare-feu ouverte à Internet sur un port d'administration | Élevée |
| Règle de pare-feu ouverte à Internet sur un port de base de données | Élevée |
| Règle de pare-feu autorisant tout le trafic depuis Internet | Critique |
| Bucket de stockage accessible publiquement | Critique ; élevée si seuls des rôles de lecture sont publics |
| Accès uniforme au niveau du bucket désactivé | Moyenne |
| Instance Cloud SQL accessible depuis Internet | Critique |
| Instance Cloud SQL n'imposant pas le chiffrement TLS | Élevée ; moyenne si l’instance n’a pas d’adresse publique |
| Sauvegardes automatiques désactivées sur l'instance Cloud SQL | Moyenne |
| Autorisation ABAC héritée activée sur le cluster GKE | Élevée |
| Point d'accès du plan de contrôle GKE ouvert à Internet | Élevée |
| Fonction ou service serverless invocable publiquement | Moyenne ; élevée si l’ingress est ouvert à tous et que le compte Compute par défaut l’exécute |
| Clé de chiffrement KMS sans rotation automatique | Moyenne |
| Dataset BigQuery accessible publiquement | Critique |
Précisions :
- Pare-feu : seules les règles VPC classiques d’entrée, actives, sont évaluées. Administration = ports 22 et 3389 ; bases de données = 1433, 1521, 3306, 5432, 6379, 9200, 9300, 11211 et 27017. Une règle qui ouvre tous les ports n’est signalée qu’une fois, par la règle « tout le trafic ».
- Fonctions et services serverless : un accès public est souvent voulu (API publique) ; le constat est indicatif. Un ingress limité au réseau interne est considéré comme conforme.
- Buckets : seule la politique IAM est évaluée. Les anciennes ACL d’objets ou de bucket ne sont pas lues.
- KMS : seules les clés symétriques à rotation possible sont concernées ; une rotation de plus de 365 jours est aussi signalée.
Limites
- Les politiques d’organisation (par exemple
compute.requireOsLogin,compute.disableSerialPortAccess, l’interdiction de l’accès public aux buckets) et les politiques de pare-feu hiérarchiques ou de réseau ne sont pas évaluées : un constat peut être neutralisé à votre niveau organisation, et une règle de refus n’est pas prise en compte. Les constats décrivent les configurations de chaque ressource. - Les politiques d’audit héritées d’un dossier ou de l’organisation ne sont pas visibles pour un projet rattaché à une organisation.
- Les droits IAM de Google sont cohérents à terme : un rôle accordé ou retiré peut mettre quelques minutes à produire son effet.
- Deux organisations CISAPP peuvent voir les mêmes projets au travers de deux comptes de service différents : la connexion est exclusive pour un compte de service, pas pour un projet.
- Un périmètre vide est plafonné ; un projet inaccessible est signalé et ses ressources ne sont pas supprimées de l’inventaire.
- Si le compte de service voit plus de projets que le plafond (100 par défaut) en mode « tous les projets », seuls les premiers sont analysés et la résolution automatique des constats est suspendue pour toute la connexion : les constats continuent d’être créés et mis à jour, mais aucun n’est résolu, et la synchronisation le signale. Listez explicitement les projets à analyser pour la rétablir.
Révoquer l’accès
Côté Google Cloud : retirez le rôle « Créateur de jetons du compte de service » accordé à CISAPP sur votre compte de service. CISAPP ne peut plus obtenir de nouveau jeton ; le jeton déjà émis reste utilisable jusqu’à son expiration (une heure au maximum), sous réserve de la propagation IAM de Google.
bashgcloud iam service-accounts remove-iam-policy-binding "$SA_EMAIL" \ --project="$PROJECT_ID" \ --member="serviceAccount:<COMPTE_DE_SERVICE_CISAPP>" \ --role="roles/iam.serviceAccountTokenCreator"Côté CISAPP, Déconnecter supprime la connexion et l’inventaire cloud associé, passe ses constats de posture en résolus et supprime le jeton gardé en mémoire : c’est l’arrêt immédiat côté CISAPP. Il n’y a rien à révoquer chez Google : aucun identifiant n’est stocké. Retirez ensuite le rôle d’emprunt d’identité, puis supprimez le compte de service et le rôle personnalisé s’ils ne servent plus.
Difficultés courantes
| Message | Que faire |
|---|---|
| Le connecteur Google Cloud est indisponible sur cette instance | Le compte de service de la plateforme n’est pas encore configuré sur votre plateforme : contactez le support. |
| Google Cloud a refusé l’accès | Voir les causes détaillées ci-dessous. |
| Ce compte de service est déjà connecté à une autre organisation CISAPP, ou ne correspond pas au compte de cette connexion | Un compte de service n’a qu’une connexion : déconnectez-le d’abord de l’autre organisation CISAPP. Sinon, le compte a été supprimé puis recréé (nouvel identifiant : ce n’est plus le compte de service connecté précédemment) : vérifiez l’e-mail saisi, déconnectez la connexion et reconnectez-la. Le même message apparaît si la connexion a été modifiée pendant la vérification : rechargez la page. |
| Impossible de confirmer : ce compte de service a changé depuis la vérification | Relancez la vérification. |
| Trop de tentatives | Trop de tentatives de connexion rapprochées (10 par minute au maximum) : patientez une minute. |
| L’e-mail n’est pas valide (message sous le champ) | Saisissez un compte de service que vous avez créé (nom@projet.iam.gserviceaccount.com). Les comptes gérés par Google, y compris les anciens agents de service Google, sont refusés. Il s’agit d’une erreur de saisie, pas d’un refus de Google Cloud. |
Quand Google Cloud refuse l’accès, la vérification s’arrête à la première cause rencontrée, dans cet ordre :
| Cause | Que faire |
|---|---|
| Le compte de service appartient au projet de CISAPP | Créez-le dans l’un de vos projets. |
| CISAPP ne peut pas emprunter l’identité de ce compte de service | Vérifiez l’e-mail et que le compte de service de CISAPP détient roles/iam.serviceAccountTokenCreator sur ce compte de service. Google ne distingue pas un compte absent d’un droit manquant. Attendez la propagation IAM. |
| Le compte de service ne peut pas se lire lui-même | Attribuez-lui le rôle personnalisé sur son projet d’accueil. |
| Activez une API dans le projet d’accueil | Activez cloudresourcemanager, iam et serviceusage dans le projet d’accueil (étape 7). |
| Un périmètre VPC Service Controls bloque le compte de service | Autorisez le compte de service dans le périmètre. |
| Le compte de service est introuvable, ne correspond pas à l’e-mail, n’appartient pas à son projet ou est désactivé | Vérifiez l’e-mail, réactivez le compte de service. |
| Le jeton de vérification est introuvable dans la description du compte de service | Mettez à jour la description avec la valeur exacte du panneau (aucun texte en plus). Le jeton n’est vérifié que tant que la connexion n’est pas active. |
roles/iam.serviceAccountTokenCreator est accordé sur le projet, un dossier ou l’organisation | Retirez ces attributions larges et accordez le rôle sur le compte de service uniquement. |
| Le compte de service ne voit aucun projet, ou un projet n’est pas lisible | Attribuez le rôle personnalisé sur les projets à analyser (ou sur l’organisation) et vérifiez que chaque projet est actif. |
Après la connexion, dans les synchronisations :
| Symptôme | Cause probable |
|---|---|
| Produit « non accordé » dans le résultat | Une permission du rôle manque sur ce projet : attribuez-le sur ce projet ou sur l’organisation. |
Erreur SERVICE_DISABLED dans le résultat | Une API du projet d’accueil du compte de service est désactivée (étape 7). |
| Connexion en erreur « identifiants refusés » | L’emprunt d’identité est refusé (rôle retiré, compte supprimé ou désactivé) : rétablissez-le puis relancez la vérification depuis la fiche. |
| Connexion en erreur « le compte de service a été remplacé » | Le compte de service a été recréé : déconnectez puis reconnectez le compte. |
| Limite de projets atteinte | Sélectionnez explicitement les projets à analyser (tant que la liste est vide, aucun constat n’est résolu automatiquement). |
Résultat attendu
La connexion est active, l’inventaire cloud est alimenté et les constats de posture Google Cloud remontent dans CISAPP.
Voir aussi : Configurer les connecteurs.