# Phase 4 : exploitation journalière, journaux et incidents

**Pour qui :** équipe sécurité / SOC (au quotidien), plateforme (correctifs), PM (indicateurs).
**But :** savoir chaque matin, en 10 minutes, si quelque chose d'anormal s'est passé ; savoir **où** trouver
chaque journal ; savoir **quoi faire** quand une alerte sonne.

---

## 1. La routine

| Quand | Quoi | Outil | Durée |
|---|---|---|---|
| **Chaque jour** | Lire le journal quotidien ; traiter chaque ligne au-dessus du seuil | `scripts/daily_report.sh` | 10 min |
| Chaque jour | Traiter les alertes reçues (e-mail / SIEM) | Monitoring → Alerting | selon alertes |
| Chaque semaine | Faux positifs Model Armor (demandes légitimes bloquées) ; nouveaux agents dans le registre | Log Analytics (§4), Agent Registry | 30 min |
| Chaque mois | Conformité + inventaire Shadow AI, archivés | `verify_controls.sh`, `shadow_ai_inventory.sh` | 1 h |
| Chaque trimestre | Revue des groupes, de la liste blanche de sortie, des durées de conservation, des exceptions | Console IAM, `terraform.tfvars` | 2 h |

### Le journal quotidien

```bash
./scripts/daily_report.sh > rapports/$(date +%F).md      # dernières 24 h
SINCE=7d ./scripts/daily_report.sh                         # la semaine
```

Il produit un tableau Markdown :

| Indicateur | Seuil d'action |
|---|---|
| Modifications de garde-fous (Model Armor, clés, IAM, assistant) | > 0 **sans PR** correspondante = incident |
| Blocages Model Armor | pic ×3 par rapport à la moyenne = attaque possible ou faux positif massif |
| Réponses bloquées par la politique (journaux d'usage) | idem |
| Signaux Shadow AI (agent créé, outil enregistré) | > 0 sans PR = enquête |
| Accès refusés (`PERMISSION_DENIED`) | pic = tentative d'accès |
| Violations VPC-SC | avant enforcement : à analyser une par une |
| Requêtes utilisateurs | tendance d'adoption (pour le PM) |

Plus : qui a modifié la configuration, filtres les plus déclenchés, méthodes refusées.

**Automatiser :** exécuter le script chaque matin depuis la CI (tâche planifiée) avec un compte qui a
`roles/logging.viewAccessor` sur les vues des buckets, et poster le rapport dans le canal de l'équipe sécurité.

---

## 2. Où se trouve chaque journal

| Journal | Contenu | Où le lire | Conservation |
|---|---|---|---|
| Audit **admin** (toujours actif) | Création/modification de ressources, droits | Bucket `ge-security` (et `_Required`) | 365 j (400 j dans `_Required`) |
| Audit **accès aux données** | Qui a lu / interrogé quoi (GE, Agent Platform, Model Armor, Secret Manager, Agent Registry) | `ge-security` | 365 j |
| Verdicts **Model Armor** | Filtre déclenché, (option) contenu analysé | `ge-security` | 365 j |
| **Usage** Gemini Enterprise (`gemini_enterprise_user_activity`) | Question, sources, motif de blocage. **Contient des questions** | `ge-usage` (sécurité seulement) | 90 j |
| Texte complet questions/réponses (`gen_ai.*`, option) | Contenu intégral | `ge-usage` | 90 j |
| **Access Transparency** | Accès d'un ingénieur Google | `_Required` / `ge-security` | 400 j |
| **VPC-SC** (dry-run ou appliqué) | Requête qui serait/est bloquée par le périmètre | `ge-security` | 365 j |
| Journaux de l'**agent** (Agent Runtime) | Exécution, erreurs, confirmations | `_Default`, ressource `aiplatform.googleapis.com/ReasoningEngine` | 30 j |
| **SIEM** | Copie temps réel de `ge-security` | Pub/Sub → outil du SOC | selon SOC |

**Ouvrir un bucket :** 🔎 « Logs Explorer » → *Affiner la portée* → *Stockage* → cocher `ge-security` ou `ge-usage`.
**SQL :** 🔎 « Log Analytics » → choisir la vue `ge-security._AllLogs`.

---

## 3. Requêtes Logs Explorer prêtes à l'emploi

### Qui a modifié un garde-fou

```
logName:"cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName=("modelarmor.googleapis.com" OR "cloudkms.googleapis.com" OR "discoveryengine.googleapis.com")
protoPayload.methodName=~"(Update|Delete|SetIamPolicy|Destroy)"
```

### Ce que Model Armor a bloqué (ou aurait bloqué, en inspection)

```
jsonPayload.@type="type.googleapis.com/google.cloud.modelarmor.logging.v1.SanitizeOperationLogEntry"
jsonPayload.sanitizationResult.filterMatchState="MATCH_FOUND"
```

### Réponses de l'app bloquées par la politique

```
logName:"gemini_enterprise_user_activity"
"CUSTOMER_POLICY_VIOLATION"
```

### Shadow AI : agents créés, services rendus publics

```
logName:"cloudaudit.googleapis.com%2Factivity"
(protoPayload.methodName=~"ReasoningEngineService.CreateReasoningEngine"
 OR (protoPayload.serviceName="run.googleapis.com" AND protoPayload.methodName=~"SetIamPolicy"))
```

### VPC-SC

```
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
```

Ajouter `protoPayload.metadata.dryRun=true` pour ne voir que le mode observation. Le champ
`protoPayload.metadata.violationReason` indique pourquoi.

### Accès de Google (Access Transparency)

```
logName:"cloudaudit.googleapis.com%2Faccess_transparency"
```

---

## 4. Requêtes Log Analytics (SQL) pour les tableaux de bord

Remplacer `PROJET` par l'ID du projet.

```sql
-- Blocages Model Armor par jour et par filtre (30 jours)
SELECT DATE(timestamp) AS jour,
       JSON_VALUE(json_payload, '$.sanitizationResult.filterMatchState') AS verdict,
       COUNT(*) AS n
FROM `PROJET.eu.ge-security._AllLogs`
WHERE JSON_VALUE(json_payload, '$."@type"') LIKE '%SanitizeOperationLogEntry'
  AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY jour, verdict ORDER BY jour;
```

```sql
-- Qui change la configuration de sécurité (90 jours)
SELECT proto_payload.audit_log.authentication_info.principal_email AS qui,
       proto_payload.audit_log.method_name AS action,
       COUNT(*) AS n
FROM `PROJET.eu.ge-security._AllLogs`
WHERE log_name LIKE '%cloudaudit.googleapis.com%2Factivity'
  AND proto_payload.audit_log.service_name IN ('modelarmor.googleapis.com','cloudkms.googleapis.com','discoveryengine.googleapis.com')
  AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
GROUP BY qui, action ORDER BY n DESC;
```

```sql
-- Adoption : utilisateurs actifs par jour (pour le PM ; pas de contenu)
SELECT DATE(timestamp) AS jour,
       COUNT(DISTINCT JSON_VALUE(json_payload, '$.userPseudoId')) AS utilisateurs
FROM `PROJET.eu.ge-usage._AllLogs`
WHERE log_name LIKE '%gemini_enterprise_user_activity'
GROUP BY jour ORDER BY jour;
```

> Les noms exacts des champs JSON des journaux d'usage sont à confirmer sur les premiers journaux réels
> (*Logs Explorer* → déplier une entrée). Ajuster les chemins `$.…` en conséquence.

**Tableau de bord :** avec `link_logs_to_bigquery = true`, ces requêtes alimentent Looker Studio sans copie de données.

---

## 5. Que faire quand une alerte sonne

### A. « Modification d'un garde-fou de sécurité »

1. Ouvrir l'alerte → *Voir les journaux* : qui (`principalEmail`), quoi (`methodName`), quand.
2. **Une PR Terraform correspond ?** (compte de la CI, heure du `apply`). Oui → clore.
3. Non → **incident** : annuler en relançant `terraform apply` (le code remet la configuration validée),
   retirer les droits de l'auteur si nécessaire, prévenir le RSSI.

### B. « Pic de requêtes bloquées »

1. Log Analytics : quel filtre, quel(s) utilisateur(s) ?
2. Un seul utilisateur, injections répétées → tentative d'abus : prévenir le manager et le RSSI selon la charte.
3. Beaucoup d'utilisateurs, filtre SDP ou RAI → **faux positif** probable (ex. nouveau format de document) :
   ajuster le template par PR, jamais en console.

### C. « Service public, agent ou outil créé / modifié » (Shadow AI)

1. Identifier la ressource et son auteur dans le journal.
2. PR et inscription dans Agent Registry ? Oui → clore.
3. Non → contacter l'auteur. Selon le risque : retirer `allUsers`, arrêter le service, ou régulariser
   (identité dédiée, Model Armor, Agent Registry, déploiement par la CI). Inscrire au rapport mensuel.

### D. Demande Access Approval reçue

1. Lire la justification de Google (numéro de ticket support).
2. Vérifier avec l'équipe qui a ouvert le ticket. Approuver pour la durée minimale, ou refuser.
3. L'accès apparaît ensuite dans Access Transparency : le rapprocher de la demande.

### E. Fuite de données suspectée (incident majeur)

1. Retirer les utilisateurs concernés du groupe, ou suspendre l'app (désactiver le groupe utilisateurs).
2. Si nécessaire, **désactiver la version de clé KMS** (données illisibles en ≤ 15 min, réversible 30 jours).
3. Exporter les journaux `ge-security` et `ge-usage` de la période (preuve) ; prévenir le DPO (délai CNIL de 72 h
   si des données personnelles sont concernées).

---

## 6. Indicateurs mensuels (pour le comité)

| Indicateur | Source | Cible |
|---|---|---|
| Contrôles `verify_controls.sh` au vert | Script | 100 % |
| Changements de garde-fous sans PR | Journal quotidien | 0 |
| Ressources IA hors Agent Registry | `shadow_ai_inventory.sh` | 0 (ou exception écrite) |
| Ressources ouvertes à Internet | idem | 0 |
| Taux de faux positifs Model Armor | Revue hebdomadaire | < 1 % des requêtes |
| Délai de traitement d'une alerte | Alerting | < 4 h ouvrées |
| Utilisateurs actifs | Log Analytics | suivi d'adoption |