Résolution des problèmes de sécurité

Vue d’ensemble — à quoi sert cet écran

Sécurité ▸ Résolution des problèmes gère la réponse aux incidents et aux compromissions de sécurité sous la forme d’un tableau de cas unique doté d’un pipeline à cinq étapes :

open → investigating → cause_identified → resolved → closed

Chaque cas porte une structure de rapport 500 (cause directe / cause racine / résolution / action préventive) ainsi qu’une chronologie auditable. Cet écran est le miroir du contrôleur Service ▸ Résolution des problèmes : il partage la même table infr_incident mais filtre sur area='security', afin de séparer les cas de sécurité des incidents de service.

Les cas arrivent sur ce tableau par deux voies :

Saisie manuelle — un opérateur crée le cas. Sources sélectionnables : manual · agency · quarantine.
Promotion depuis le diagnostic — les constats fail + crit du Diagnostic de sécurité sont automatiquement promus en cas (source=detection). Il s’agit d’une source réservée au système, qu’un opérateur ne peut pas choisir manuellement.

Cette console ne touche jamais directement au crontab ni aux pare-feu distants. C’est un outil de flux de travail qui consigne et suit le processus de réponse humain. Les actions réelles de blocage et de mise en quarantaine se trouvent dans Liste de blocage et Blocage automatique.

Quand l’utiliser

Pour promouvoir une suspicion de compromission confirmée issue de la détection IDS/IA (Menaces, Détections · JA3) en un cas formel doté d’une trace d’investigation et de résolution.
Pour suivre les demandes de coopération ou les signalements de compromission d’une agency (CERT, forces de l’ordre).
Pour piloter un hôte depuis la quarantine jusqu’à sa restauration et sa remise en service.
Pour recevoir sous forme de cas créés automatiquement les risques de durcissement ou de rootkit signalés fail+crit par le Diagnostic de sécurité, puis en attribuer le suivi.
Pour calculer a posteriori le MTTR et le temps d’indisponibilité cumulé, et documenter les causes directes et racines ainsi que les actions préventives.

Disposition

Bandeau d’indicateurs

KPI	Définition
total	Nombre total de cas où `area='security'`
active	Somme de `open + investigating + cause_identified`
resolved	Somme de `resolved + closed`
MTTR	Durée moyenne en minutes des cas disposant à la fois de `occurred_at` et de `resolved_at`
downtime	Somme de `downtime_min` sur l’ensemble des cas
uptime target	`OpsPolicy::slaDefaults()['uptime_target']`

Tableau de cas

Les cas sont triés par :

Rang de statut — open → investigating → cause_identified → resolved → closed
Rang de gravité — crit → warn → info
Les plus récents d’abord — id décroissant

Chaque carte affiche le titre, la gravité, le statut, le badge de source, le projet ou service lié, l’heure de survenue, la durée d’indisponibilité et le nombre d’événements.

Fenêtre de détail

L’ouverture d’un cas répartit l’écran en deux volets :

Rapport — champs résumé, cause directe, cause racine, résolution et action préventive.
Chronologie — historique de infr_incident_event (création, note, changement de statut, …) par ordre chronologique.

Un clic sur le pipeline de statuts en haut ouvre une boîte de dialogue de transition d’étape : elle affiche les conseils « que faire à cette étape » et permet de mettre à jour sur place les champs de rapport propres à cette étape.

Comment l’utiliser

Créer un cas (manuel)

Cliquez sur [Enregistrer un cas] en haut de l’écran.
Saisissez le titre (obligatoire), la gravité et la source (manual / agency / quarantine).
Renseignez éventuellement le projet, le service, l’URL, l’heure de survenue, l’impact et la durée d’indisponibilité (en minutes).
[Enregistrer] — un nouveau cas est créé avec status=open, area=security et detected_at=now(), et un événement created est inscrit dans la chronologie.

detection n’est pas proposé dans la liste des sources : c’est une source réservée au système, que le Diagnostic de sécurité génère automatiquement.

Transitions de statut (pipeline)

Cliquez sur le statut visé dans le pipeline de la fenêtre de détail. Travail recommandé pour chaque étape :

Étape	Que faire à cette étape
open	Ramener le cas à la prise en charge (avant l’analyse)
investigating	Confirmer les symptômes, cerner l’impact, rédiger le résumé
cause_identified	Déterminer et consigner la cause directe et la cause de fond (racine)
resolved	Consigner la méthode de rétablissement et l’action préventive
closed	Vérifier que les actions et la prévention sont en place, puis clôturer le cas

Règles de transition côté serveur :

Le passage à resolved renseigne resolved_at avec now() si le champ était vide.
Le passage à closed utilise la valeur de date de clôture saisie dans la boîte de dialogue le cas échéant ; sinon, now() s’applique par défaut lorsque aucune valeur n’existe.
Lorsque le statut change effectivement, un événement status_change (from→to) est inscrit dans la chronologie ; l’ajout d’une note crée en outre un événement note.

Notes de collaboration

Ajouter une note dans la fenêtre de détail enregistre un événement kind=note dans la chronologie. Il n’existe pas de table de notes distincte : les notes sont regroupées dans infr_incident_event.

Suppression

La suppression d’un cas supprime aussi ses lignes infr_incident_event et est inscrite au journal d’audit. (L’analyse de diagnostic à l’origine d’un cas promu est indépendante et n’est pas supprimée.)

Résolution automatique des cas promus

Lorsque le Diagnostic de sécurité ingère le résultat d’une sonde, DiagnosticsService::reconcileCases() réconcilie les cas hôte par hôte :

Un constat fail + crit → crée ou met à jour (upsert) un cas ouvert identifié par fingerprint (une récurrence incrémente occurrence_count).
Lorsqu’une analyse ultérieure valide ce point ou le fait disparaître → le cas ouvert est résolu automatiquement (status=resolved, resolved_at, resolution=auto-resolved text), avec un événement status_change dans la chronologie.

La résolution automatique ne se déclenche que lorsque le contrôle de diagnostic repasse au vert. Les cas créés manuellement (manual/agency/quarantine) ne sont jamais résolus automatiquement : un opérateur doit les faire progresser dans le pipeline.

Sources de données

Tables

Table	Rôle
`infr_incident`	Corps du cas (filtré sur `area='security'`). Statut, gravité, source, champs du rapport 500, heures de survenue/résolution/clôture, `fingerprint`, `occurrence_count`
`infr_incident_event`	Chronologie du cas (création, note, changement de statut, …)
`infr_project`	Liste des projets pour l’association
`infr_service`	Liste des services pour l’association

Énumérations

STATUSES   = [open, investigating, cause_identified, resolved, closed]
SEVERITIES = [info, warn, crit]
SOURCES    = [manual, pulse, alert, agency, quarantine, detection]   # toutes
manual-selectable sources = [manual, agency, quarantine]
OPEN_STATUSES (dedup targets) = [open, investigating, cause_identified]
AREAS = [service, security]   # axe de partage de la table commune

Champs du rapport (structure 500)

Champ	Signification
`summary`	Résumé du symptôme et de l’impact
`direct_cause`	Cause immédiate (p. ex. MySQL Too many connections)
`root_cause`	Cause de fond / racine (p. ex. fuite de connexions d’un script)
`resolution`	Rétablissement appliqué pendant l’incident
`action_taken`	Action préventive pour l’avenir
`downtime_min`	Durée d’indisponibilité (minutes) — source de l’indicateur downtime
`impact`	Périmètre affecté

Points d’entrée de l’API

Méthode · chemin	Objet
`GET /security/resolution`	Rendu initial du tableau
`GET /security/resolution/live`	Rafraîchissement par interrogation (cas, KPI, horodatage)
`POST /security/resolution/save`	Créer / mettre à jour un cas
`POST /security/resolution/transition`	Transition de statut (+ note / mise à jour de rapport facultatives)
`POST /security/resolution/note`	Ajouter une note de collaboration
`POST /security/resolution/delete`	Supprimer un cas

Accès

Lecture : tout le groupe Sécurité est protégé par le middleware infr.level:2. Seuls les utilisateurs de niveau 2 et plus (staff=5 · admin=10) peuvent y entrer ; la démo (1) est bloquée.
Écriture (enregistrement/transition/note/suppression) : la méthode canWrite() du contrôleur revérifie le infr_user_level >= 2 de la session. En dessous, elle renvoie 403 (resolution.err.forbidden).
Audit : toute écriture est consignée dans infr_audit_log — sec.incident_create · sec.incident_update · sec.incident_transition · sec.incident_delete. Les transitions stockent {from,to} et les enregistrements {title,severity} dans les métadonnées. Voir Journal d’audit.

Dépannage et FAQ

Q. Un cas que je vois sur le tableau Service est absent ici. Les deux tableaux partagent la même table infr_incident mais se répartissent selon area. Cet écran n’affiche que area='security'. Vous trouverez les incidents de service dans Service ▸ Résolution des problèmes.

Q. Je n’arrive pas à créer un cas avec la source detection. C’est le comportement attendu. detection est une source réservée au système, que le Diagnostic de sécurité crée automatiquement à partir des constats fail+crit. La saisie manuelle ne propose que manual, agency et quarantine.

Q. Un cas promu automatiquement est passé tout seul à l’état résolu. Lorsque le contrôle de diagnostic sous-jacent repasse au vert lors d’une analyse ultérieure, reconcileCases() résout automatiquement le cas ouvert : resolution est renseigné avec le texte de résolution automatique et un événement de changement de statut est ajouté.

Q. Le MTTR est vide. Le MTTR n’est calculé que pour les cas qui possèdent à la fois occurred_at et resolved_at. Les cas sans heure de survenue, ou non encore résolus, sont exclus.

Q. Puis-je indiquer une date de clôture antérieure ? Oui. Saisissez une valeur dans le champ date de clôture de la boîte de dialogue de clôture (même interface que l’heure de survenue) : elle est enregistrée telle quelle. Si vous le laissez vide, le serveur inscrit now() uniquement si aucune valeur n’existe encore.

Q. La suppression d’un cas supprime-t-elle son analyse de diagnostic ? Non. Un cas promu et l’analyse de diagnostic qui lui a donné naissance sont indépendants. Supprimer un cas ne retire que les événements de chronologie qui lui sont liés.

Voir aussi

Diagnostic de sécurité — la source qui promeut automatiquement les constats fail+crit vers ce tableau.
Résolution des problèmes de service — le miroir du même flux de travail côté service (area='service').
Vue d’ensemble de la sécurité — le récit de l’entonnoir de défense menace → détection → réponse.
Menaces · Détections · JA3 — sources de compromissions candidates à promouvoir en cas.
Journal d’audit — la trace persistante des actions d’écriture sur les cas.