Aller au contenu

Piste d'audit et suivi d'utilisation

AKKO fournit un systeme complet de piste d'audit et de suivi d'utilisation qui offre aux administrateurs une visibilite totale sur l'activite de la plateforme. Essentiel pour la conformite (RGPD, SOC 2, ISO 27001) et l'allocation des couts.

Ce qui est suivi

Source Donnees collectees Methode de collecte
Trino Utilisateur, requete SQL, tables touchees, lignes scannees, duree, statut Event listener -> stdout -> log shipper -> logs layer
LiteLLM Utilisateur, modele, tokens consommes, latence, cout estime Metriques Prometheus + logs JSON -> logs layer
JupyterHub Utilisateur, demarrage/arret serveur, noyau, duree session, memoire Metriques Prometheus (jupyterhub_*)
object storage Utilisation par bucket, nombre d'objets, stockage par bucket Metriques Prometheus (storage_bucket_*)
Keycloak Connexion, deconnexion, changement de mot de passe, inscription, sessions actives Event listeners (jboss-logging, metrics-listener)
OPA Decisions d'autorisation (autoriser/refuser), masquage de colonnes, filtres de lignes Logs de decisions -> logs layer
PostgreSQL Tailles des bases de donnees par instance Metriques Prometheus (pg_database_size_bytes)

Dashboard Dashboards

Le dashboard AKKO Audit Trail & Usage (akko-audit-usage) contient 14 panneaux :

  1. Timeline d'activite -- Journal unifie de toutes les sources (table, filtrable)
  2. Top utilisateurs par requetes Trino -- Jauge a barres, fenetre 24h
  3. Top utilisateurs par tokens LLM -- Jauge a barres, fenetre 24h
  4. Sessions JupyterHub actives -- Panneau statistique
  5. Total utilisateurs JupyterHub -- Panneau statistique
  6. Utilisateurs en ligne vs total -- Sessions actives Keycloak vs inscrits
  7. Stockage par bucket -- Utilisation object storage par bucket (diagramme a barres)
  8. Utilisation CPU par pods utilisateur -- Pods JupyterHub singleuser (serie temporelle)
  9. Utilisation memoire par pods utilisateur -- Pods JupyterHub singleuser (serie temporelle)
  10. Evenements d'authentification Keycloak -- Panneau de logs connexion/deconnexion
  11. Journal de requetes Trino -- Requetes SQL avec utilisateur et duree
  12. Decisions d'autorisation OPA -- Logs de decisions de politiques
  13. Taux de requetes LiteLLM -- Requetes de la passerelle IA par modele (serie temporelle)
  14. Volume d'evenements d'audit -- Diagramme a barres empilees de tous les types d'evenements

Acces via : Dashboards > dossier AKKO > "AKKO Audit Trail & Usage"

Page Usage du Cockpit

Le cockpit inclut une page Usage dediee (barre laterale > Usage, administrateurs uniquement) qui fournit :

  • Cartes KPI : Utilisateurs totaux, utilisateurs en ligne, requetes Trino (24h), requetes LLM (24h), notebooks actifs
  • Onglet Vue d'ensemble : Dashboard Dashboards d'audit integre en mode kiosque
  • Onglet Requetes Trino : Table du journal de requetes recent
  • Onglet Utilisation LLM : Consommation de tokens, latence, utilisation des modeles, taux d'erreur
  • Onglet Sessions : Sessions JupyterHub actives + evenements d'authentification Keycloak
  • Onglet Stockage : Utilisation des buckets object storage + tailles des bases PostgreSQL avec diagramme
  • Onglet Ressources : Consommation CPU et memoire par pod utilisateur

Configuration

Event Listener Trino

Configure dans values.yaml et values-trino.yaml :

trino:
  eventListenerProperties:
    - event-listener.name=log
    - log.query-created=true
    - log.query-completed=true
    - log.split-completed=false

Ceci enregistre les evenements de requetes sur stdout, que log shipper collecte et envoie a logs layer.

Suivi d'utilisation LiteLLM

LiteLLM est configure avec des callbacks Prometheus dans la configuration :

litellm_settings:
  success_callback: ["prometheus"]
  failure_callback: ["prometheus"]
  json_logs: true
  store_audit_logs: true

Quand database_url est defini (pointant vers PostgreSQL), LiteLLM persiste egalement les donnees d'utilisation pour l'analyse historique.

Evenements Keycloak

Le realm a les evenements actives avec deux listeners :

  • jboss-logging -- Ecrit les evenements dans les logs serveur (collectes par log shipper)
  • metrics-listener -- Expose les compteurs d'evenements comme metriques Prometheus

Types d'evenements actives : LOGIN, LOGOUT, REGISTER, TOKEN_EXCHANGE, CLIENT_LOGIN, UPDATE_PASSWORD, UPDATE_PROFILE, RESET_PASSWORD, et plus.

Les evenements d'administration sont egalement actives (adminEventsEnabled: true) pour le suivi des operations administratives.

Logs de decisions OPA

OPA est configure avec la journalisation des decisions activee. Toutes les decisions d'autorisation Trino (autoriser/refuser, masquage de colonnes, filtrage de lignes) sont journalisees et collectees par log shipper.

Audit gouvernance cockpit (OCSF 1.3)

Le Sprint 66 a ajouté un émetteur d'audit production-grade dans akko-cockpit-backend qui capture chaque action de gouvernance déclenchée depuis le cockpit (composite de rôle, attribution ou retrait de rôle/groupe/membre). Les événements suivent le schéma OCSF 1.3 (Open Cybersecurity Schema Framework, OASIS 2024) — le même modèle utilisé par Splunk, AWS Security Lake, Cisco SecureX et Microsoft Sentinel.

Champ OCSF Signification
class_uid 3005 user-access mgmt, 3006 group mgmt, 3007 data access (Sprint 67), 3008 LLM (Sprint 68)
activity_id 1 create, 4 delete, 3 update, 2 read
actor.user.uid claim OIDC sub — identifiant utilisateur stable
actor.user.type_id 1 humain, 2 compte de service
resources[] liste typée, ex. realm-role:akko-admin, realm-role-mirror:AD_engineer
status Success / Failure / Unknown
correlation_id relie la ligne cockpit → flux VictoriaLogs → trace Tempo
app toujours akko-audit

Chaque événement est diffusé en parallèle vers deux puits redondants pour une livraison at-least-once :

  • puits stdout — ligne AKKO_AUDIT {json compact} sur le stdout du pod cockpit-backend, captée par le DaemonSet fluent-bit → VL.
  • push HTTP direct VL — POST /insert/jsonline avec le label de flux app=akko-audit, retry 3× exp backoff (200ms → 800ms → 3.2s).

L'onglet Gouvernance > Audit du cockpit interroge /api/governance/audit?since=24h&activity=role&actor=alice et rend chaque ligne avec un libellé humain en français, le nom + email de l'acteur, des puces typées par ressource, une pastille de statut et un correlation ID copiable.

Pour l'intégration SIEM, transférez le flux VL {app="akko-audit"} vers votre collecteur OCSF — aucune traduction de schéma nécessaire. Voir ADR-052.

Retention des donnees

  • VictoriaLogs : rétention par défaut de 14 jours (configurable via logs.victorialogs.retention dans helm/akko/charts/akko-observability/values.yaml ; chart vlogs, service akko-victorialogs sur le port 9428)
  • Prometheus : rétention par défaut de 15 jours (configurable via helm/akko/values.yaml sous monitoring)
  • LiteLLM PostgreSQL : Persistant, suit le calendrier de sauvegarde de la base de donnees

Pour des exigences de conformite depassant ces valeurs par defaut, augmentez la retention ou configurez le transfert de logs vers un SIEM externe.

Controle d'acces

La page Usage et le dashboard Dashboards sont restreints aux utilisateurs ayant le role akko-admin. Les utilisateurs non-administrateurs ne peuvent pas acceder aux donnees d'audit.