Projet 08 : Gemini Enterprise conforme à la note de sécurité Acme

Pour qui : toute l'équipe projet. Développeurs, DevOps / plateforme, chefs de projet, sécurité, DPO. Objectif : appliquer les 10 mesures de la Security Advice Note Acme à l'application Gemini Enterprise. D'abord avec ce que Google Cloud offre nativement (console, quelques clics, effet immédiat), puis en Terraform (reproductible, relu, auditable).

Ce projet part du projet 06 (le socle : identité, CMEK, connecteurs, Model Armor, journaux). Le socle reste valable et il est documenté dans docs/00-socle-securite.md. Ce README ne décrit que ce qui change pour la note et comment procéder.

Sommaire

1. En une page
2. Qui fait quoi
3. Les 10 mesures et notre réponse
4. Comment procéder : 4 phases
5. Ce que le projet contient
6. Démarrage rapide
7. Pourquoi d'abord la console, puis Terraform ?
8. Corrections à apporter à la note
9. Vérifié / à valider
10. Documentation détaillée

1. En une page

Le constat. La note Acme fixe 10 mesures pour l'IA générative. Le socle 06 en couvrait le cœur (Model Armor, audit, identité). Il manquait la protection des agents personnalisés, la lutte contre le Shadow AI, l'export SIEM, Access Approval, l'analyse des documents avant indexation, le contrôle de sortie, le niveau d'accès VPC-SC et l'usage réel d'Agent Registry.

Ce que fait le projet 08.

Le principe. Chaque mesure est d'abord activée dans la console (phase 1) pour voir son effet sur des cas réels. Elle est ensuite reprise dans Terraform (phase 2), qui devient la seule source de vérité. Rien n'est construit « à côté » de Google : chaque brique est un service Google Cloud natif.

2. Qui fait quoi

Règle de séparation des rôles (mesure 8) : un administrateur Gemini Enterprise ne peut pas affaiblir Model Armor, toucher aux clés ou lire les journaux privés. Seul le groupe sécurité le peut.

3. Les 10 mesures et notre réponse

Légende : 🟢 natif console (phase 1), 🔷 Terraform (phase 2), 🧰 script fourni, ⚪ hors périmètre de l'app.

Le détail mesure par mesure (ce que la note demande, ce qu'on fait, la preuve) est dans docs/05-correspondance-note.md.

4. Comment procéder : 4 phases

 Semaine 1         Semaine 2-3                 Semaine 3-4             Ensuite, chaque jour
┌──────────┐    ┌──────────────────┐    ┌─────────────────────┐    ┌────────────────────┐
│ PHASE 1  │───▶│ PHASE 2          │───▶│ PHASE 3             │───▶│ PHASE 4            │
│ Console  │    │ Terraform        │    │ Tests (recette)     │    │ Exploitation       │
│ natif    │    │ paliers A→D      │    │ 22 tests + preuves  │    │ journal quotidien  │
│ observer │    │ importer, figer  │    │ verify_controls.sh  │    │ revue mensuelle    │
└──────────┘    └──────────────────┘    └─────────────────────┘    └────────────────────┘
  Effet immédiat,   Seule source de       Chaque mesure prouvée    Détecter, réagir,
  sans risque       vérité ensuite        par un test et un log    prouver à l'audit

Phase 1 : activer le natif (console), semaine 1

But : obtenir tout de suite la protection que Google fournit, et observer avant de bloquer. Toutes ces actions sont réversibles et sans effet sur les utilisateurs, sauf mention contraire.

Pas à pas, avec le chemin exact dans la console et la vérification : docs/01-phase1-console.md.

Phase 2 : figer en Terraform, semaines 2 et 3

But : tout ce qui a été activé à la main devient du code relu, déployé par la CI (même circuit que le projet 07 : PR → plan → validation sécurité → apply). Les réglages faits en console sont importés : Terraform les reprend sans les recréer.

Détails, fichiers et commandes, une fiche par palier : docs/phase2-terraform/.

Phase 3 : prouver, semaines 3 et 4

22 tests, chacun avec le résultat attendu et le journal qui le prouve. Deux scripts automatisent l'essentiel :

./scripts/test_model_armor.sh       # filtrage : légitime accepté, attaques bloquées
./scripts/verify_controls.sh        # conformité : chaque mesure est-elle réellement en place ?

Plan complet : docs/03-plan-de-tests.md.

Phase 4 : exploiter, chaque jour

Où trouver chaque journal, requêtes prêtes à l'emploi, réponses aux incidents : docs/04-exploitation-journaliere.md.

5. Ce que le projet contient

08-gemini-enterprise-securite-acme/
├── README.md                      ← ce guide
├── docs/
│   ├── 00-socle-securite.md       le socle hérité du 06 (6 couches, détaillées)
│   ├── 01-phase1-console.md       activer le natif, pas à pas : clics, valeurs, gcloud, vérifier, annuler
│   ├── phase2-terraform/          8 fiches : import, paliers A→D, CI/CD, mesure par mesure, développeurs
│   ├── 03-plan-de-tests.md        22 tests + preuves
│   ├── 04-exploitation-journaliere.md  journal quotidien, requêtes, incidents
│   ├── 05-correspondance-note.md  les 10 mesures une par une + corrections
│   └── 06-dlp-cmek-agent-gateway.md  les 3 briques expliquées : console puis Terraform
├── terraform/                     socle 06 + fichiers 75, 85, 90, 95 (nouveaux)
│   └── docs/                      une fiche par fichier .tf (débutant)
├── agent/secure_agent/            agent exemple : Model Armor + validation humaine
├── scripts/
│   ├── test_model_armor.sh        recette du filtrage
│   ├── verify_controls.sh         contrôle de conformité (lecture seule)
│   ├── daily_report.sh            journal quotidien (Markdown)
│   ├── shadow_ai_inventory.sh     inventaire Shadow AI (Asset Inventory)
│   ├── scan_before_ingest.py      analyse des documents avant indexation
│   ├── register_agent.sh, pack.py publication de l'agent
│   └── build_pdf.py, build_pptx.js  génération du PDF et du deck
├── Gemini-Enterprise-Note-securite-Acme.pdf
└── Gemini-Enterprise-Note-securite-Acme.pptx

6. Démarrage rapide

cd terraform
cp terraform.tfvars.example terraform.tfvars    # projet, groupes, connecteurs, paliers
terraform init
terraform plan                                   # LIRE le plan
terraform apply

cd ..
./scripts/test_model_armor.sh
PROJECT_ID=... APP_ID=... ./scripts/verify_controls.sh
./scripts/daily_report.sh > rapport-$(date +%F).md

Agent exemple, en local (sans Model Armor) puis sur Agent Runtime :

cd agent && LOCAL_DEV=1 python secure_agent/agent.py      # autotest des outils
LOCAL_DEV=1 adk web .                                      # essai : « rembourse 10 € sur CMD-1002 »
# puis deploy_secure_agent = true dans terraform.tfvars et terraform apply

7. Pourquoi d'abord la console, puis Terraform ?

C'est la question qu'on nous posera. La réponse tient en quatre points :

1. La protection n'attend pas le code. Activer les journaux d'audit ou Model Armor prend dix minutes en console. Attendre deux semaines de développement, c'est rester deux semaines sans protection.
2. Observer avant de bloquer. Le plancher Agent Platform en mode inspection et VPC-SC en dry-run montrent ce qui serait bloqué. On règle les seuils sur des cas réels, sans casser un service en production.
3. Le code ensuite, pour durer. Un réglage manuel se perd, se modifie sans trace, ne se reproduit pas dans le projet du domaine suivant. Terraform le rend relu (PR), traçable (Git), reproductible (un projet par domaine, mesure 8) et vérifiable (le plan montre toute dérive).
4. Rien n'est perdu entre les deux. Les ressources créées en console sont importées dans Terraform (blocs import, fiche 01). Après la phase 2, plus aucun changement en console : l'alerte « garde-fou modifié » signale toute exception.

8. Corrections à apporter à la note

La note est solide sur le fond. Six points sont inexacts techniquement et méritent d'être corrigés avant qu'elle serve de référence d'audit. Le détail et les sources sont dans docs/05 §2.

9. Vérifié / à valider

Vérifié : terraform validate OK (provider hashicorp/google 8.5) ; tous les types et champs Terraform contrôlés dans le schéma du provider ; Access Approval couvre Gemini Enterprise, Agent Runtime, Model Armor et KMS (doc Google, GA) ; autotests de l'agent (secure_agent OK), du scanner (self-test OK) et du contrôle de conformité. Pas encore déployé sur un projet Acme.

10. Documentation détaillée

Supports