SecOps / Dashboard local read-only

Dashboard SecOps local

Console SecOps locale en React et TypeScript : posture, preuves, timeline SQLite, Analytics, drill-down et durcissement systemd.

React TypeScript SQLite Express systemd read-only

Architecture publique du dashboard SecOps local — Chaîne publique expurgée : preuves privilégiées bornées, collecteur utilisateur, snapshot et historique SQLite, API loopback puis console de triage.

Collecter

Lire des preuves normalisées et bornées sans exposer les journaux bruts au service utilisateur.

Normaliser

Valider le contrat, calculer fraîcheur et posture, puis importer les événements de façon idempotente.

Analyser

Produire timeline, agrégats, clusters et drill-down sur des fenêtres strictement limitées.

Restituer

Servir une console locale read-only avec hiérarchie de risque, détails de preuve et états dégradés explicites.

Contexte

Le problème réel.

Les signaux audit, intégrité, boot trust, sauvegarde et santé plateforme existaient déjà, mais restaient dispersés entre widgets, rapports et journaux. Il fallait une vue opérateur unique sans donner au navigateur un accès aux sources privilégiées ni transformer l'interface en composant d'administration.

Objectifs

Ce que la solution devait garantir.

Réunir posture, intégrité, boot trust, sauvegarde et historique récent dans une vue locale.
Conserver une frontière stricte entre producteurs root, collecteur utilisateur, API et navigateur.
Permettre le triage sans acquittement, mutation d'incident ou commande système depuis l'interface.
Rendre les limites visibles : preuve absente, périmée ou inconnue ne devient jamais un faux état sain.

Architecture publique

Structure documentée, détails exploitables retirés.

Preuves bornées. Les producteurs privilégiés publient uniquement des métriques scalaires validées, jamais leurs sorties brutes.
Collecteur isolé. Un processus utilisateur construit atomiquement le snapshot et maintient l'historique SQLite avec rétention bornée.
API read-only. Express écoute uniquement en loopback, applique des limites strictes et n'expose aucune route de mutation.
Console de triage. React présente posture, couverture, timeline, Analytics et détails sans fabriquer de donnée absente.

Exemples anonymisés

Ce qui peut être montré sans exposer le système réel.

Posture normalisée

Le résumé combine gravité, couverture et qualité des preuves sans masquer les inconnues.

posture             OK / WARN / CRIT / UNKNOWN
couverture           preuves disponibles / attendues
fraîcheur            FRESH / STALE / UNKNOWN
menaces actives      compteur dédupliqué
contrôles dégradés   détail et runbook associé

API strictement locale

Les routes publiques du processus restent limitées à la consultation.

GET /healthz         santé du processus
GET /api/v1/state    posture courante
GET /api/v1/events   timeline filtrée
GET /api/v1/analytics agrégats bornés
POST /api/v1/events  route absente

Validation de release

La V1.1 est clôturée par une chaîne unique et reproductible.

contrats            PASS
TypeScript           PASS
tests                43 / 43
audit dépendances    0 vulnérabilité connue
build                423 modules
unités systemd       validation statique PASS

Runbook public

Commandes et états attendus issus de la documentation privée.

Les commandes ci-dessous sont volontairement anonymisées: chemins, noms de machines, interfaces, dépôts, périphériques et actions destructrices sont remplacés par des placeholders.

Dépôt public du dashboard SecOps

Validation applicative

Commandes anonymisées

npm run check

État attendu

contrats et typage validés
43 tests réussis
bundle de production généré
aucune donnée live modifiée

Runbook privé du dashboard local

Santé de l'API

Commandes anonymisées

curl --fail http://127.0.0.1:<port>/healthz

État attendu

réponse JSON locale
statut de service nominal
aucune route de mutation invoquée
aucun journal privilégié exposé

Threat model et procédure de release

Contrôle de release

Commandes anonymisées

npm run check:release

État attendu

tests, build et audit des dépendances réussis
unités systemd vérifiées
SBOM SPDX généré à la demande
release bloquée au premier échec

Travail réalisé

Décisions techniques publiables.

Contrats avant interface

JSON Schema, types TypeScript et cohérence sémantique précèdent le rendu pour éviter les états ambigus.

Analytics bornées

Les requêtes SQL sont paramétrées, les fenêtres limitées à sept jours et les classements plafonnés.

Durcissement local

Contrôle Host, en-têtes de sécurité, fichiers bornés, timeouts HTTP et unités systemd restrictives réduisent la surface.

Release reproductible

Une commande unique valide contrats, types, tests, build, dépendances, unités et génération de SBOM.

Validation

Preuves et contrôles retenus.

43 tests automatisés : API, contrats, stockage et collecteur.
Build de production validé sur 423 modules et audit npm sans vulnérabilité connue.
Unités utilisateur vérifiées statiquement et services locaux validés après intégration contrôlée.
Rendu réel relu dans le navigateur et navigation opérateur confirmée.

Preuves visuelles

Contrôles observables et portée de la preuve.

**Posture critique avant triage.** La vue d'ensemble consolide les menaces actives, la couverture et les contrôles dégradés sans réduire la posture à un score opaque.

**Analytics de sécurité.** Les volumes horaires, la répartition des risques, les scénarios, acteurs et exécutables sont agrégés ; les valeurs propres au poste sont masquées.

**Absence de télémétrie réseau explicite.** Le dashboard indique que Suricata et GeoIP ne sont pas configurés au lieu d'inventer des IP, protocoles ou origines.

**Console d'événements filtrée.** La recherche sur les événements corrélés démontre le filtrage local par niveau, risque et texte, avec les signaux sensibles anonymisés.

**Contrôles avant rebaseline.** Les cartes distinguent preuve inconnue, fraîcheur périmée, intégrité alignée et menaces actives avant la résolution opérateur.

**Posture après triage.** Après qualification des alertes, le compteur de menaces revient à zéro tandis que la couverture incomplète et le contrôle dégradé restent visibles.

**Contrôles après rebaseline.** Les preuves FIM système, dépôt et paquets sont à nouveau fraîches et alignées ; AppArmor et les preuves absentes conservent leur statut réel.

Résultats publics

Ce que le chantier démontre.

Console locale V1.1 opérationnelle et strictement read-only.
Posture et couverture reliées à des preuves fraîches, inconnues ou périmées explicites.
Timeline, Analytics et clusters disponibles sans exposer les logs source.
Threat model, procédure de release et retour arrière documentés.

Anonymisation

Ce qui reste privé.

Pas de journaux bruts, chemins privés, noms d'hôtes ou identifiants exploitables.
Les captures réelles du dashboard masquent les acteurs, exécutables et chemins de preuve propres au poste.
Pas de règle de détection complète ni de commande d'intégration système.
Suricata et la gestion mutable d'incidents restent hors périmètre V1.

Sources privées

Documentation d'origine.

Runbook privé du dashboard SecOps local V1.
Threat model et procédure de release du dépôt applicatif.
Documentation privée auditd, FIM, boot trust et preuves plateforme.
Rapports de validation live et tests automatisés.