AUDITOR · EVIDENCE

Een tenant doorlichten zonder productie-toegang

De cliënt geeft je géén shell, géén admin-dashboard. Wel: cryptografisch ondertekende evidence die je offline verifieert. Vijf concrete checks die een auditor elke kwartaal doet.

Volledige docs
01

Verifieer de maandelijkse Audit Pack offline

Cliënt mailt je een .jsonl.gz + .pdf + .sig. Hoe weet je dat de PDF van de monsys-runtime komt, niet uit de editor van de cliënt?

  1. Sidebar → Audit Packs
  2. Download .jsonl.gz + .sig voor de maand
  3. Klik 'Download verify-CLI' knop
  4. Run CLI lokaal — groene checkmarks

manifest_hash, hash-chain root, en Ed25519 sig zitten allemaal in dezelfde .sig file. Onafhankelijk te valideren.

Hetzelfde via API (bash) — voor automatisering
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

Bewijs dat CVE-2026-XXXX binnen 7 dagen is gepatched

Auditor wil per host: wanneer eerst gedetecteerd, wanneer gepatched, wie heeft de actie uitgevoerd, en hoe lang ertussen.

  1. Sidebar → Kernel CVE's → zoek CVE-2026-XXXX
  2. Tab 'Tijdlijn' → per host: detected, patched, operator
  3. Filter 'Time to patch > 7 days'
  4. Knop 'Export voor audit' → CSV

Elke EAT-getriggerde reboot zit in kernel_reboot_history met expected=true + link naar eat_id voor de operator-trail.

Hetzelfde via API (sql) — voor automatisering
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

Lijst elke privileged actie van het kwartaal

Compliance-vraag: welke menselijke acties zijn er uitgevoerd op productie tussen X en Y, en wie was de actor.

  1. Sidebar → Audit log (onder MANAGE)
  2. Filter: event_type='emergency_token_issued' + Q1 datum range
  3. Per rij: operator, agent, actions, exit_code
  4. 'Verify in transparency log' knop opent externe verifier

Elk nonce in deze lijst is ook in de publieke transparency_log. Offline her-verifiëren via verify-eat CLI.

Hetzelfde via API (sql) — voor automatisering
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

Verifieer cryptografische integriteit van één specifieke regel

Cliënt zou achteraf één regel kunnen wijzigen in de JSONL.gz voor hij hem doorstuurt. Hoe detecteer je dat?

  1. Open Audit Pack download view
  2. Klik 'Tamper check tool' (client-side verifier)
  3. Paste de verdachte JSONL regel
  4. UI toont expected vs computed hash + verdict

Hash-chain root zit in de manifest. Manifest hash zit in de .sig. Tampering propageert dus naar de Ed25519-signatuur.

Hetzelfde via API (bash) — voor automatisering
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

Hoe lang houden we evidence — NIS2 minimum 12 maanden

Belgische NIS2-transpositie eist minimum 12 maanden audit-evidence. Trust Score evidence_continuity-component straft tenants af die korter hebben.

  1. Sidebar → Trust Score → component Evidence continuity
  2. Tabel toont oudste/nieuwste rij per evidence-tabel
  3. Groen >12m, rood <12m direct zichtbaar
  4. Klik rode rij → remediation suggesties

Trust Score v1.2 / tenant view toont evidence_continuity score live — auditor ziet dit dashboard direct.

Hetzelfde via API (sql) — voor automatisering
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;

Andere rollen

Lees de uitgebreide praktijk-docs