À 9 h 12, un vendeur signale que son compte a publié des offres qu’il ne reconnaît pas. À 9 h 25, l’équipe désactive le compte ; à 10 h 05, elle découvre que la même clé API sert aussi à synchroniser les commandes. Le confinement arrête les offres frauduleuses, mais bloque les confirmations de trente vendeurs légitimes et laisse des commandes dans trois états différents.
L’incident devient métier dès qu’une mesure technique touche catalogue, paiements, vendeurs ou acheteurs. Couper tout le trafic semble prudent, pourtant cette action peut effacer des indices, créer des doubles traitements à la reprise et déplacer la fraude vers le support. Continuer sans limite expose en revanche de nouvelles données et transactions.
Le vrai enjeu d’un incident de sécurité dans une marketplace opérateur consiste à réduire le dommage tout en gardant chaque décision explicable et réversible. Contre-intuitivement, la réponse la plus sûre n’est pas toujours l’arrêt général : un mode dégradé borné protège parfois mieux preuves, commandes et utilisateurs.
Vous allez comprendre comment qualifier, commander, préserver les preuves, contenir, informer et reconstruire avant de rouvrir. La démarche de sécurité et conformité marketplace relie entrées, sorties, owner, instrumentation, monitoring, dépendances, seuils, file, retry et rollback.
Qualifier l’incident sans attendre une certitude
Distinguer signal, événement et incident
Un signal est une observation non tranchée : connexion inhabituelle, export massif ou modification d’IBAN. L’événement regroupe les faits corrélés. L’incident est déclaré lorsque confidentialité, intégrité, disponibilité ou conformité peut être affectée et qu’une coordination dédiée devient nécessaire.
La déclaration précoce n’affirme pas la cause. Elle ouvre incident_id, severity_initiale, incident commander et canal réservé. Attendre la preuve parfaite laisse chaque équipe corriger localement, tandis que les journaux tournent et que la portée augmente.
Évaluer gravité et urgence séparément
La gravité combine données, privilèges, transactions, population, réversibilité et obligations possibles. L’urgence mesure la vitesse d’expansion. Une fuite limitée de document d’identité peut être très grave sans se propager ; un token vendeur utilisé en continu est urgent même si peu d’objets sont encore touchés.
La matrice choisit surveillance renforcée, réponse standard ou cellule de crise. Elle est réévaluée à chaque fait. Un score initial ne devient pas une étiquette définitive et ne remplace jamais le jugement du commander.
Par exemple, cinq changements de coordonnées bancaires avec paiements prévus dans deux heures imposent un gel financier immédiat. Les mêmes changements sur des comptes inactifs autorisent davantage de collecte avant action, à condition de bloquer toute nouvelle sortie de fonds.
Installer un commandement unique
Séparer commandement et investigation
Le commander tient objectifs, décisions, priorités et arbitrages. Le lead technique enquête et propose. Operations suit commandes et vendeurs, Legal ou DPO apprécie les obligations, Communication prépare les messages et un scribe maintient la chronologie.
La personne qui cherche la cause ne peut pas en même temps coordonner quinze parties prenantes. Chaque rôle possède un remplaçant et une cadence. Les contributeurs rejoignent la cellule par besoin, pas par statut hiérarchique.
Créer un rythme de décision
Un point initial toutes les trente minutes peut devenir horaire lorsque l’expansion est contenue. Chaque séquence ferme faits nouveaux, hypothèses, actions, risques métier et prochaine échéance. Les canaux opérationnels restent séparés du fil d’information général.
Le journal de décision contient heure, auteur, données disponibles, option choisie et critère de révision. Si une action irréversible est proposée, alors le commander demande l’alternative la plus étroite et la manière de préserver les preuves.
Préserver preuves et chronologie
Collecter sans contaminer
Logs d’accès, audit back-office, événements API, changements de droits, exports, paiements et messages sont copiés vers un espace immuable avec horodatage. Les sources, fenêtres de rétention et écarts d’horloge sont documentés avant qu’une rotation automatique ne supprime les faits.
La collecte cite collecteur, méthode, plage et hash lorsque pertinent. Les personnes habilitées accèdent au strict nécessaire. Une capture d’écran aide à comprendre, mais elle ne remplace pas l’événement source ni son contexte.
Les entrées incluent incident_id, source_system, time_range et legal_hold éventuel ; les sorties sont manifeste, objets collectés, lacunes et propriétaire. Le monitoring alerte si une source attendue cesse d’alimenter le dossier ou si sa rétention devient insuffisante.
Construire une timeline multi-systèmes
La chronologie aligne authentification, actions métier et effets externes. Un login à 08:42, un export à 08:45 et un changement d’IBAN à 08:51 doivent être reliés au même principal sans supposer qu’ils viennent de la même machine.
Les heures sont normalisées avec la précision connue. Une action absente n’est pas réputée inexistante si le log comporte un trou. Les hypothèses sont marquées comme telles et reçoivent une condition de confirmation ou de rejet.
Mesurer la portée réelle
Relier identités, objets et actions
L’analyse part des identifiants compromis puis traverse sessions, tokens, comptes, vendeurs, offres, commandes, paiements et données consultées. Elle distingue accès possible, accès observé et effet confirmé. Ces trois populations ne reçoivent pas la même réponse.
Le graphe conserve la provenance de chaque relation. Un token ayant le droit d’exporter n’est pas la preuve d’un export. À l’inverse, une action exécutée via un service partagé peut toucher davantage de comptes que l’identité visible.
Gérer l’incertitude explicitement
La portée porte une borne basse confirmée et une borne haute plausible. L’équipe cherche les faits qui réduisent cet intervalle : adresse source, scope du secret, journaux downstream ou réponses des partenaires. Elle ne présente pas une estimation comme un nombre définitif.
Un signal faible apparaît lorsque le volume d’actions revient à la normale mais que les refresh tokens continuent d’être utilisés. Un autre survient lorsque les commandes touchées partagent une intégration plutôt qu’un vendeur. Ces patterns élargissent l’enquête avant que l’incident ne redevienne visible.
Choisir un confinement proportionné
Réduire le blast radius
Les options sont révocation d’une session, rotation d’un secret, suspension d’un scope, gel d’un vendeur, désactivation d’une action sensible ou fermeture d’un domaine. Le commander choisit la plus petite mesure qui interrompt le chemin d’attaque connu.
Chaque action précise population, durée, effet métier, preuve attendue et rollback. Une feature flag peut désactiver les changements d’IBAN tout en gardant consultation et traitement des commandes. En revanche, une coupure globale devient nécessaire lorsque la frontière de confiance n’est plus déterminable.
Éviter les doubles effets
Un job déjà en file peut continuer après révocation de l’interface. Les workers, caches, webhooks et accès partenaires sont inclus dans le confinement. Le système marque les événements suspects et suspend leur effet externe avant de les rejouer ou compenser.
Les commandes et paiements conservent leur état opposable. Un retry de confinement utilise idempotency_key. Toute action manuelle rejoint le même journal afin que la reprise ne cumule pas correction humaine et compensation automatique.
Maintenir une promesse métier réduite
Définir les fonctions essentielles
La cellule classe recevoir une commande, protéger un paiement, informer un utilisateur, honorer une expédition et préserver une preuve. Le mode dégradé peut autoriser consultation et support tout en suspendant inscription vendeur, export et modification financière.
Les seuils sont définis avant la crise : nombre de commandes en attente, délai maximal sans confirmation, capacité de reprise et risque financier. La continuité n’est pas le maintien de toutes les fonctions ; elle protège les engagements déjà pris.
Traiter les files métier
Chaque commande touchée reçoit état, raison et owner. Les vendeurs ne doivent pas expédier un ordre suspendu, et l’acheteur ne doit pas repayer. Une file priorise produits urgents, montants élevés, délais et possibilités de compensation.
Le support utilise une vue commune plutôt que des exports. Les actions possibles sont attendre, confirmer, annuler, rembourser ou escalader. Chaque décision déclenche les événements idempotents nécessaires et garde l’historique.
Les engagements externes sont inventoriés séparément : collecte transporteur, ordre PSP, reversement vendeur, notification et promesse de délai. Le confinement peut arrêter l’écriture interne sans annuler un ordre déjà transmis. Operations confirme donc chaque accusé de réception, puis compense uniquement les effets réellement partis. Cette vérification évite qu’une commande soit remboursée côté marketplace alors que son expédition reste active chez un partenaire.
Coordonner information et obligations
Séparer faits internes et messages externes
Le brief interne contient hypothèses et données sensibles ; le message externe ne partage que faits confirmés, impact connu, actions demandées et point de contact. Les versions sont horodatées. Une correction ultérieure explique ce qui a changé sans effacer la première information.
Les populations sont segmentées : collaborateurs, vendeurs, acheteurs, partenaires, assureur et autorités éventuelles. Une personne non touchée ne reçoit pas un message alarmant ; une personne concernée obtient les gestes concrets pour se protéger et suivre le dossier.
Décider avec les fonctions compétentes
Legal, DPO et RSSI évaluent ensemble nature des données, juridictions, contrats et délais applicables. Le système fournit faits et population, mais il ne déduit pas automatiquement une obligation juridique depuis un score technique.
La décision de notification cite analyse, approbateur, heure et contenu envoyé. Si la portée reste incertaine, alors le dossier documente pourquoi une information préliminaire est nécessaire ou pourquoi l’attente reste proportionnée.
Révoquer accès et secrets compromis
Cartographier la chaîne de confiance
Un secret peut vivre dans CI, coffre, configuration, poste, logs ou documentation. Sa rotation couvre émetteur, consommateurs, scopes et dépendances. Changer seulement la valeur principale laisse parfois un token dérivé ou une session encore valide.
L’inventaire associe secret_id, owner, systèmes, date de dernière utilisation et procédure. Les secrets inconnus ou sans owner sont traités comme un risque de portée. Les nouveaux identifiants utilisent privilège minimal et durée réduite.
Rotater sans perdre le contrôle
La rotation passe par chevauchement court lorsque le contexte le permet, observation, bascule puis révocation. Pour une compromission active, la révocation immédiate prime et le mode dégradé absorbe la rupture. Le choix est noté dans la timeline.
Le déploiement vérifie qu’aucune ancienne clé n’est utilisée après l’échéance. Les appels refusés sont analysés pour identifier un consommateur oublié ou une tentative persistante. Le rollback ne réactive jamais un secret compromis ; il restaure la fonction avec une identité saine.
Reconstruire puis réconcilier
Repartir d’une base de confiance
La reprise ne consiste pas seulement à lever les flags. Elle corrige la cause exploitable, applique les patches, reconstruit les composants douteux et réémet les identités. Les artefacts sont signés et les configurations comparées au baseline attendu.
Une sauvegarde est restaurée seulement si son intégrité et sa date sont compatibles avec l’incident. Les changements métier légitimes postérieurs sont rejoués depuis les événements validés. Restaurer aveuglément peut réintroduire la faille ou perdre des commandes.
Réconcilier les objets touchés
Offres, commandes, paiements, coordonnées bancaires, permissions et notifications sont comparés à leur état attendu. Les anomalies sont classées : action hostile, effet du confinement, événement en retard ou incohérence antérieure. Chacune reçoit correction et preuve.
Les compensations utilisent référence et idempotence. Une commande remboursée ne repart pas vers le vendeur lors du rejeu. Un IBAN restauré ne déclenche aucun reversement tant qu’une seconde validation n’a pas confirmé son bénéficiaire.
Prouver la stabilité avant réouverture
Définir des critères de go
Le go exige vecteur contenu, identités réémises, monitoring actif, objets réconciliés et responsabilités disponibles. Les fonctions critiques passent des scénarios métier : modifier une offre, accepter une commande, rembourser, changer un accès et traiter une file.
Le taux d’erreur, les alertes, la latence et les actions refusées restent sous seuil pendant une fenêtre définie. Une absence d’alerte ne prouve rien si la télémétrie est incomplète. Le test provoque donc un signal contrôlé et vérifie sa remontée.
Rouvrir par cohortes
Un canary réactive collaborateurs internes, vendeurs pilotes puis population élargie. Les actions à fort risque restent séparées. Chaque cohorte possède métriques, durée et rollback vers le mode dégradé sans restauration d’anciens secrets.
Si un indicateur critique dérive ou si une action inexpliquée apparaît, alors la cohorte revient à l’état précédent. Le commander ne négocie pas le seuil pendant l’observation ; toute modification devient une nouvelle décision documentée.
Transformer l’incident en amélioration
Conduire un retour sans recherche de coupable
Le postmortem reconstruit conditions, décisions et défenses qui ont échoué ou fonctionné. Il sépare déclencheur, facteurs contributifs et impact. Une erreur humaine devient une question de droits, d’interface, de contrôle ou de charge plutôt qu’une conclusion.
Les coûts couvrent arrêt, reprises, support, remboursements, expertise et opportunité. Cette lecture justifie les corrections systémiques. Elle montre aussi les contrôles coûteux qui n’ont pas réduit la portée et doivent être repensés.
Fermer les actions durables
Chaque action possède owner, échéance, preuve et risque traité. Les tâches sont priorisées entre prévention, détection, confinement et récupération. Une action « améliorer les logs » devient une source précise, un champ, une rétention et un test d’alerte.
Le comité vérifie à trente et quatre-vingt-dix jours. Les actions non financées entraînent une acceptation de risque explicite. Le prochain exercice rejoue le scénario et mesure temps de qualification, portée, confinement et reprise.
Adapter la méthode et éviter les erreurs
Pour qui cette réponse à incident convient
Elle concerne toute marketplace qui traite identités, paiements, catalogue ou données personnelles, même avec une petite équipe. Le format varie : rôles cumulés au lancement, cellule dédiée à l’échelle. Commandement, preuves et décisions restent indispensables.
RSSI, Platform, Operations, Trust, Finance, Support, DPO, Legal et Communication doivent connaître leur rôle avant l’incident. Les prestataires critiques figurent dans l’annuaire avec canal d’urgence et responsabilités contractuelles.
Erreurs fréquentes pendant un incident
Supprimer un compte avant de préserver ses traces, discuter dans plusieurs canaux, publier une cause non confirmée et restaurer un secret compromis sont des erreurs majeures. Couper tout le site sans mesurer les engagements ouverts peut augmenter le dommage.
Une autre erreur consiste à déclarer l’incident clos dès que l’attaquant ne se voit plus. Enfin, un postmortem sans owner ni preuve devient un récit. La sortie exige stabilité métier, surveillance et actions suivies.
Plan d’action de réponse à incident
Heures 0 à 4 : commander et contenir
Les quinze premières minutes ouvrent incident, rôles, canal et conservation. La première heure qualifie gravité, portée basse et chemins actifs. Les heures suivantes appliquent le confinement minimal, protègent les fonctions essentielles et préparent les messages.
Les entrées sont alertes, logs, inventaire et dépendances ; les sorties sont timeline, portée, décisions et files métier. Le monitoring suit tentatives, accès, actions sensibles, erreurs et backlog. Chaque geste possède owner et rollback sûr.
Jours 1 à 30 : reconstruire et prouver
Le premier jour ferme collecte, rotation et réconciliation prioritaire. Les jours suivants reconstruisent la confiance, testent les parcours et rouvrent par cohortes. Sous dix jours, le retour d’expérience produit les corrections prioritaires et leur budget.
Un exercice trimestriel simule secret vendeur compromis, commandes déjà engagées, partenaire indisponible et obligation d’information. Une personne extérieure à la réponse doit retrouver les preuves, suspendre un scope, traiter la file et exécuter le rollback.
Le go final exige zéro action privilégiée inexpliquée, réconciliation complète de la population connue, monitoring éprouvé et capacité support dimensionnée. Si la portée haute reste trop large, alors la réouverture demeure limitée même si les composants semblent stables.
La direction accepte explicitement le risque résiduel, les contrôles compensatoires et leur durée. Une échéance transforme chaque mesure temporaire en retrait ou en capacité pérenne, plutôt qu’en dette invisible après la crise.
- À faire d’abord : déclarer, commander, préserver et contenir le chemin actif.
- À vérifier ensuite : portée, identités, objets métier, information et surveillance.
- À différer : l’optimisation non essentielle jusqu’à une base de confiance retrouvée.
- À refuser : toute réouverture sans critères, canary et rollback éprouvé.
Ressources complémentaires opérateur
Borner le périmètre exploitable
Le MVP marketplace avant ouverture aide à identifier les fonctions qui doivent survivre en mode dégradé.
La méthode pour ouvrir une première catégorie relie engagements commerciaux et capacité réelle.
Outiller preuves et reprise
Le catalogue PIM marketplace structure provenance, décisions et correction des offres touchées.
Les écrans du back-office opérateur réunissent timeline, actions, files et réconciliation.
Conclusion : reprendre sur des preuves
Une réponse solide qualifie tôt, installe un commandement et préserve les faits avant de modifier les systèmes.
Le confinement protège un chemin de confiance et une promesse métier réduite, sans multiplier les effets impossibles à réconcilier.
Reconstruction, canary, monitoring et retour d’expérience transforment la reprise en décision prouvée plutôt qu’en intuition rassurante.
Dawap peut vous accompagner pour intégrer cette capacité à votre marketplace opérateur.
