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

Le journal quotidien

./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 :

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

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.

-- 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;

-- 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;

-- 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é)