# 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 `gcloud` connecté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 service `gcp-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>`).

1. 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.

2. **Adaptez les variables.** `PROJECT_ID` est le projet qui hébergera le compte de service (son « projet d’accueil »), `ORG_ID` l’identifiant numérique de votre organisation (inutile sans organisation).

   ```bash
   PROJECT_ID="my-project-id"
   SA_NAME="cisapp-readonly"
   SA_EMAIL="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
   ORG_ID="123456789012"
   ```

3. **Créez le compte de service**, avec le jeton de vérification comme **description** : il prouve que vous contrôlez ce compte.

   ```bash
   gcloud 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 :

   ```bash
   gcloud iam service-accounts update "$SA_EMAIL" --project="$PROJECT_ID" \
     --description="<JETON_DE_VERIFICATION>"
   ```

4. **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.

   ```bash
   gcloud iam service-accounts add-iam-policy-binding "$SA_EMAIL" \
     --project="$PROJECT_ID" \
     --member="serviceAccount:<COMPTE_DE_SERVICE_CISAPP>" \
     --role="roles/iam.serviceAccountTokenCreator"
   ```

5. **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.

   ```yaml
   title: 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.list
   ```

6. **Cré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.

     ```bash
     gcloud 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-b` par vos projets, **sans oublier le projet d’accueil du compte de service**. Le rôle est créé dans chacun.

     ```bash
     for 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
     ```

7. **Activez les API dans le projet d’accueil** du compte de service : ses appels y sont comptabilisés et limités.

   ```bash
   gcloud 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/browser`
- `roles/compute.networkViewer`
- `roles/cloudsql.viewer`
- `roles/container.clusterViewer`
- `roles/iam.serviceAccountViewer`
- `roles/cloudfunctions.viewer`
- `roles/run.viewer`
- `roles/cloudkms.viewer`
- `roles/bigquery.metadataViewer`
- `roles/serviceusage.serviceUsageViewer`
- `roles/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

1. Dans le panneau de configuration, cliquez **J’ai terminé**.
2. Indiquez l’**e-mail du compte de service** (par exemple `cisapp-readonly@mon-projet.iam.gserviceaccount.com`).
3. 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.
4. **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.
5. 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.

  ```bash
  gcloud 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](https://docs.cisapp.eu/organisation/connecteurs).