AUDITEUR · PREUVES

Examiner un tenant sans accès à la production

Le client ne vous donne aucun shell, aucun admin tableau de bord. Mais : des preuves cryptographiquement signées que vous vérifiez hors-ligne. Cinq checks concrets qu'un auditeur effectue chaque trimestre.

Docs complètes
01

Vérifier l'Audit Pack mensuel hors-ligne

Le client vous envoie un .jsonl.gz + .pdf + .sig. Comment savez-vous que le PDF provient du runtime monsys, et non de l'éditeur du client ?

  1. Sidebar → Audit Packs
  2. Télécharger .jsonl.gz + .sig pour le mois
  3. Cliquer 'Download verify-CLI'
  4. Lancer CLI localement — checkmarks vertes

manifest_hash, hash-chain root, et signature Ed25519 sont tous dans le même fichier .sig. Validable indépendamment.

Idem via API (bash) — pour automatisation
wget https://get.monsys.ai/monsys-verify-eat-linux-x64
chmod +x monsys-verify-eat-linux-x64

./monsys-verify-eat-linux-x64 verify-pack \
  --pack 2026-04.jsonl.gz \
  --sig  2026-04.sig \
  --pubkey  https://transparency.monsys.ai/pubkeys/hub.pub
# ✓ manifest_hash matches signature
# ✓ hash chain root matches manifest
# ✓ Ed25519 signature valid against pubkey 7c34a9e2b1f0…
# ✓ 1247 entries in pack, 0 tampered
02

Prouver que CVE-2026-XXXX a été patchée en 7 jours

L'auditeur veut par hôte : quand détectée pour la première fois, quand patchée, qui a exécuté l'action, et combien de temps entre.

  1. Sidebar → CVE noyau → rechercher CVE-2026-XXXX
  2. Onglet 'Timeline' → par hôte : detected, patched, operator
  3. Filtre 'Time to patch > 7 jours'
  4. Bouton 'Export for audit' → CSV

Chaque redémarrage déclenché par EAT est dans kernel_reboot_history avec expected=true + lien vers eat_id pour la trace opérateur.

Idem via API (sql) — pour automatisation
WITH first_detected AS (
  SELECT agent_id, MIN(detected_at) AS first_seen
    FROM kernel_cve_findings
   WHERE tenant_id = $1::UUID AND cve_id = 'CVE-2026-XXXX'
   GROUP BY agent_id
),
patched AS (
  SELECT r.agent_id, MIN(r.boot_time) AS rebooted_at, r.eat_id
    FROM kernel_reboot_history r
    JOIN first_detected fd ON fd.agent_id = r.agent_id
   WHERE r.tenant_id = $1::UUID
     AND r.expected = true AND r.boot_time > fd.first_seen
   GROUP BY r.agent_id, r.eat_id
)
SELECT a.hostname, fd.first_seen, p.rebooted_at,
       p.rebooted_at - fd.first_seen AS time_to_patch,
       u.email AS operator
  FROM first_detected fd
  LEFT JOIN patched p ON p.agent_id = fd.agent_id
  LEFT JOIN agents  a ON a.id = fd.agent_id
  LEFT JOIN emergency_tokens et ON et.id = p.eat_id
  LEFT JOIN users u ON u.id = et.user_id
 ORDER BY time_to_patch NULLS FIRST;
03

Lister chaque action privilégiée du trimestre

Question compliance : quelles actions humaines ont été exécutées en production entre X et Y, et qui était l'acteur.

  1. Sidebar → Audit log (sous MANAGE)
  2. Filtre : event_type='emergency_token_issued' + plage Q1
  3. Par ligne : operator, agent, actions, exit_code
  4. Bouton 'Verify in transparency log' ouvre verifier externe

Chaque nonce dans cette liste est aussi dans le transparency_log public. Re-vérifiable hors-ligne via le CLI verify-eat.

Idem via API (sql) — pour automatisation
SELECT et.issued_at, u.email AS operator,
       a.hostname AS target, et.level,
       et.actions::TEXT AS actions, et.reason,
       (et.result->>'exit_code')::INT AS exit_code
  FROM emergency_tokens et
  LEFT JOIN users  u ON u.id = et.user_id
  LEFT JOIN agents a ON a.id = et.agent_id
 WHERE et.tenant_id = $1::UUID
   AND et.issued_at >= '2026-01-01' AND et.issued_at < '2026-04-01'
 ORDER BY et.issued_at DESC;
04

Vérifier l'intégrité cryptographique d'une ligne spécifique

Le client pourrait modifier une ligne dans le JSONL.gz a posteriori avant de vous l'envoyer. Comment détectez-vous cela ?

  1. Ouvrir vue téléchargement Audit Pack
  2. Cliquer 'Tamper check tool' (verifier client-side)
  3. Coller la ligne JSONL suspecte
  4. UI affiche expected vs computed hash + verdict

La racine hash-chain est dans le manifest. Le hash du manifest est dans le .sig. La manipulation se propage donc jusqu'à la signature Ed25519.

Idem via API (bash) — pour automatisation
zcat 2026-04.jsonl.gz | sed -n '847p' > suspicious-line.json
sha256sum suspicious-line.json
# 7c34a9e2b1f0…

zcat 2026-04.jsonl.gz | \
  ./monsys-verify-eat-linux-x64 chain-position --line 847
# expected_position: 7c34a9e2b1f0…
# computed_position: 7c34a9e2b1f0…
# ✓ line 847 matches the chain
05

Combien de temps gardons-nous les preuves — minimum NIS2 12 mois

La transposition belge NIS2 exige minimum 12 mois de preuves d'audit. Le composant evidence_continuity du Trust Score pénalise les tenants en dessous.

  1. Sidebar → Trust Score → composant Evidence continuity
  2. Tableau montre plus ancienne/récente ligne par table de preuves
  3. Vert >12m, rouge <12m directement visible
  4. Cliquer ligne rouge → suggestions de remediation

La vue Trust Score v1.2 / tenant affiche le score evidence_continuity en direct — l'auditeur voit ce dashboard directement.

Idem via API (sql) — pour automatisation
SELECT 'audit_log' AS table_name,
       MIN(created_at) AS oldest,
       MAX(created_at) AS newest, COUNT(*) AS rows
  FROM audit_log WHERE tenant_id=$1::UUID
UNION ALL
SELECT 'emergency_tokens',
       MIN(issued_at), MAX(issued_at), COUNT(*)
  FROM emergency_tokens WHERE tenant_id=$1::UUID
UNION ALL
SELECT 'transparency_log',
       MIN(appended_at), MAX(appended_at), COUNT(*)
  FROM transparency_log WHERE tenant_id=$1::UUID;

Autres rôles

Lire la doc pratique détaillée