Chezlepro SOC 2 Type II Cockpit

Cockpit web React + API Node pour piloter une conformité opérationnelle SOC 2 Type II.

Cette version n’est plus seulement un prototype d’interface. Le dépôt contient maintenant :

• un frontend React/Vite ;
• un backend HTTP Node ;
• un registre JSON versionné dans compliance/soc2/registry/ ;
• des manifests dérivés ;
• un répertoire d’artefacts de preuves ;
• un contrat de connecteurs pour Forgejo / Icinga2 / Keycloak.

Structure

src/
  App.jsx
  model/
  lib/
  features/hooks/
  components/
server/
  index.js
  config.js
  lib/
    http.js
    store.js
  contracts/
    connectors.json
  scripts/
    seed-registry.mjs
compliance/soc2/
  registry/
    soc2-registry.json
    evidence-manifest.json
    auditor-pack-index.json
  evidence/
  packs/

Modes de fonctionnement

Mode local

Le frontend persiste le registre dans localStorage.

cp .env.example .env
# laisser VITE_SOC2_SYNC_MODE=local
npm install
npm run dev

Mode API

Le frontend devient client d’une source de vérité sur disque, servie par l’API locale.

cp .env.example .env
# définir VITE_SOC2_SYNC_MODE=api
npm install
npm run seed:registry
npm run server
npm run dev

API par défaut : http://localhost:4177/api

Endpoints backend

• GET /api/health
• GET /api/registry
• PUT /api/registry
• POST /api/registry/reset
• GET /api/evidence
• POST /api/evidence

Exemple : écrire le registre

curl -X PUT http://localhost:4177/api/registry \
  -H 'Content-Type: application/json' \
  --data @compliance/soc2/registry/soc2-registry.json

Exemple : pousser un artefact de preuve

python - <<'PY'
import base64, json
from pathlib import Path
payload = {
  "filename": "example-proof.txt",
  "contentBase64": base64.b64encode(b"preuve de test").decode(),
  "mimeType": "text/plain"
}
Path("payload.json").write_text(json.dumps(payload), encoding="utf-8")
PY

curl -X POST http://localhost:4177/api/evidence \
  -H 'Content-Type: application/json' \
  --data @payload.json

Connecteurs prévus

Le fichier server/contracts/connectors.json décrit les contrats attendus pour :

• Forgejo : changements, PR, approbations
• Icinga2 : disponibilité, incidents, tendances
• Keycloak : MFA, rôles admin, revues d’accès

Le dépôt n’effectue pas encore les collectes réelles sans les paramètres d’accès du site cible, mais l’architecture est prête pour les implémenter.

Ce qui rend cette version utile

• le registre n’est plus seulement stocké côté navigateur ;
• l’API peut servir de source de vérité locale ;
• les manifests sont régénérés à chaque écriture ;
• les artefacts de preuves ont un emplacement physique ;
• le front peut fonctionner en mode local ou mode API.

Séquence suivante recommandée

1. brancher les vrais accès Forgejo / Icinga2 / Keycloak ;
2. ajouter une authentification applicative ;
3. gérer le téléversement multipart réel ;
4. ajouter des jobs de collecte planifiés ;
5. produire des packs auditeur exportables en HTML/PDF.