Documentation Index

Fetch the complete documentation index at: https://snakysec.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

​

LOGGING — Journalisation de preuve numérique

​

1. Cadre normatif

​

2. Politique zéro donnée sensible

​

Denylist (appliquée par le writer, non-contournable)

• Clés matching : *secret*, *token*, *password*, *key (sauf allowlist), *auth*, cookie, authorization, bearer, vault*, encryption_key, pem, private_key, hmac_key, nonce, refresh_token, access_token, session, credential, client_secret
• Patterns valeur : JWT, PEM block, Vault token (hvs.*, hvb.*), GitLab PAT (glpat-*), GitHub PAT (ghp_*, ghs_*), Slack token, base64 long (≥ 64 chars sans séparateurs)
• Allowlist identifiants publics : keyId, keyVersion, publicKeyId, sessionId, tokenId, secretId, keyPrefix

​

Truncation

​

Whitelist par resourceType

​

Scope unifié

• PlatformAuditLog (journal d’évidence)
• Pino (logs stdout) via PINO_REDACT_PATHS
• Sentry via beforeSend hook

​

3. Schéma d’événement (PlatformAuditLog)

​

Qui · Quoi · Où · Comment · Changement · Destination

​

Actions normalisées (extrait)

auth.login · auth.logout · auth.mfa_challenge
client.create · client.update · client.delete · client.secret.rotate
audit.trigger · audit.cancel · audit.complete
control.review · control.override
grc.document.generate · report.download
vault.read · vault.rotate
audit_log.verify · audit_log.tampering_detected · audit_log.tampering_acknowledged

​

Exemple — MFA challenge réussi

{
  "seq": 184221,
  "timestamp": "2026-04-14T09:12:04.021Z",
  "recordedAt": "2026-04-14T09:12:04.087Z",
  "actorType": "USER",
  "actorId": "user_01HR...",
  "actorDisplay": "alice@snakysec.fr",
  "actorIp": "203.0.113.42",
  "actorUserAgent": "Mozilla/5.0 ...",
  "authMethod": "sso.entra",
  "action": "auth.mfa_challenge",
  "outcome": "SUCCESS",
  "severity": "INFO",
  "resourceType": "User",
  "resourceId": "user_01HR...",
  "sourceService": "next-app",
  "requestId": "req_01HR...",
  "route": "/api/auth/callback/entra-id",
  "previousHash": "a3f9...c21b",
  "entryHash": "7d4e...0089",
  "chainHash":   "12af...ffab",
  "preChain": false
}

​

Exemple — Rotation de secret client

{
  "action": "client.secret.rotate",
  "outcome": "SUCCESS",
  "severity": "WARNING",
  "resourceType": "ClientSecret",
  "resourceId": "cs_01HR...",
  "resourceLabel": "SnakySec — Graph cert",
  "clientId": "cl_01HR...",
  "changeSummary": "X.509 cert rotated",
  "before": { "keyId": "kid_2025", "keyVersion": 3 },
  "after":  { "keyId": "kid_2026", "keyVersion": 4 },
  "reason": "annual rotation",
  "destinationKind": "VAULT",
  "destinationRef": "mssp/clients/snakysec"
}

​

4. Chaîne d’intégrité

​

Canonicalisation

​

Hachage

• entryHash = SHA-256( JCS(payload) )
• chainHash = SHA-256( previousChainHash || entryHash )
• Genèse : genesisHash( "mssp-platform" ) (ou process.env.DEPLOYMENT_ID)

​

Sérialisation des écritures

​

Ancrage quotidien Ed25519

1. Sélectionne toutes les entrées de J-1 (firstSeq, lastSeq)
2. Calcule rootHash = SHA-256( chainHash(firstSeq) || chainHash(lastSeq) )
3. Signe le message canonique mssp-audit-anchor:v1|date|firstSeq|lastSeq|rootHash avec la clé privée Ed25519 chargée depuis Vault (mssp/platform/log_anchor_private_key)
4. Insère une ligne LogAnchor { anchorDate, firstSeq, lastSeq, rootHash, signature, publicKeyId, algo, tsaToken? }
5. Écrit un événement audit_log.anchor dans le journal (méta-trace)

​

5. Vérification

​

Worker automatique — vérification quotidienne

1. Parcourt toutes les entrées dans l’ordre seq asc
2. Re-calcule entryHash et chainHash de chaque ligne
3. Compare à la valeur stockée
4. Vérifie chaque LogAnchor avec la clé publique Ed25519
5. Rupture détectée → trigger lockdown (voir §6)

​

Endpoint manuel

POST /api/v1/admin/audit-log/verify
Authorization: Bearer <MSSP_ADMIN session>

{ "ok": true, "entriesVerified": 184221, "anchorsVerified": 97 }

{
  "ok": false,
  "brokenAtSeq": 182014,
  "expectedHash": "7d4e...",
  "actualHash":   "3b2a...",
  "lockdown": true
}

​

Runbook — vérification à froid

# Export journal
docker exec -i platform-postgres-1 psql -U mssp -d mssp \
  -c "COPY (SELECT * FROM \"PlatformAuditLog\" ORDER BY seq) TO STDOUT WITH CSV HEADER" \
  > audit-log-$(date +%Y%m%d).csv

# Export ancres
docker exec -i platform-postgres-1 psql -U mssp -d mssp \
  -c "COPY (SELECT * FROM \"LogAnchor\" ORDER BY \"anchorDate\") TO STDOUT WITH CSV HEADER" \
  > log-anchors-$(date +%Y%m%d).csv

# Clé publique (à fournir au vérifieur tiers)
vault kv get -field=log_anchor_public_key mssp/platform > mssp-log-public.pem

# Vérification : script tiers utilise canonicalize + sha256 + ed25519-verify

​

6. Détection et gestion de tampering

​

Lockdown automatique

1. Upsert PlatformState { key: "audit_log_lockdown", value: { locked: true, detectedAt, brokenAtSeq, expectedHash, actualHash } }
2. Le writer recordAuditEvent() vérifie isAuditLogLocked() avant chaque écriture et bloque (AuditLogLockedError) si verrouillé
3. Une alerte Sentry critique est levée (audit_log.tampering_detected)

​

Reconnaissance (acknowledgement)

POST /api/v1/admin/audit-log/acknowledge-tampering
Content-Type: application/json
{
  "reason": "Justification ≥ 10 caractères — cause identifiée, corrective action engagée"
}

1. Calcul newGenesisHash = SHA-256( "ack:<userId>:<detectedAt>:<brokenAtSeq>" )
2. Signature Ed25519 du bloc ack
3. Insertion AuditLogAcknowledgement { detectedAt, brokenAtSeq, expectedHash, actualHash, reason, acknowledgedById, newGenesisHash, signature }
4. Déverrouillage PlatformState.audit_log_lockdown.locked = false
5. Écriture audit_log.tampering_acknowledged comme première entrée de la nouvelle ère

• Les entrées pré-rupture restent immuables (leurs chainHash d’origine ne changent pas)
• La rupture reste documentée (ligne AuditLogAcknowledgement signée, traçable)
• La nouvelle ère démarre depuis un genesis déterministe dérivé de l’incident (pas d’effacement)
• L’ack lui-même est scellé dans la nouvelle chaîne

​

7. Rétention

​

8. Operational runbook

​

Rotation de la clé d’ancrage Ed25519

1. Générer nouvelle paire (openssl genpkey -algorithm ed25519)
2. vault kv put mssp/platform log_anchor_private_key=@new.pem log_anchor_public_key=@new.pub log_anchor_key_id=kid_YYYY-MM
3. Redéploiement worker — publicKeyId utilisé par l’ancrage suivant est le nouveau
4. Ne jamais supprimer l’ancienne clé publique — la vérification rétroactive en dépend. Archivage sous mssp/platform/archive/log_anchor_public_key_<kid>

​

Ajout / modification d’une action

1. Étendre le type AuditAction + ACTION_LABELS dans audit-log.ts
2. Revue : scope du champ before/after conforme à la whitelist RESOURCE_LOGGABLE_FIELDS ?
3. Écrire au moins un call-site avec recordAuditEvent — jamais passer par logAction legacy

​

Revue à froid d’un incident (forensic)

1. Snapshot DB (backup point-in-time)
2. Export journal CSV (cf §5)
3. Vérification chaîne complète (worker ou script tiers)
4. Filtrage action, actorId, resourceId, timestamp range
5. Corrélation avec journaux externes : Traefik access logs, GitLab pipeline logs, Sentry events
6. Production du rapport d’analyse signé (DOCX + PDF via générateur GRC incident procedure)

​

9. Références implémentation

​

10. Limites connues

• Ancrage TSA non-qualifié — Ed25519 signé par SnakySec suffit pour eIDAS “avancé”. Pour passer “qualifié” : intégration RFC 3161 avec TSA qualifiée ANSSI (Q3 2026)
• Pas de transparency log public — la clé publique est publiée mais aucun registre indépendant n’atteste encore des ancres. Option Rekor / Trillian à évaluer
• Horodatage serveur — basé sur NTP OS. Pour exigences renforcées : horodatage TSA systématique par entrée (coût vs bénéfice à évaluer)
• Backfill pré-chaîne — entrées antérieures au déploiement du système portent preChain: true et sont exclues de la vérification chaîne (voir migration backfill)