La plupart des gestionnaires de secrets B2B ne fournissent aucun outillage in-app pour gérer un incident : il faut ouvrir un ticket support, attendre une intervention humaine et expliquer la situation à un commercial. Aegirex fait le choix inverse : un panneau dédié dans les paramètres organisation, deux actions graduées, justification écrite obligatoire, audit chain HMAC inaltérable. Conçu pour qu'un RSSI puisse réagir en quelques secondes, sans dépendance de notre équipe.
Un gestionnaire de secrets concentre par construction la valeur la plus sensible d'une organisation. Quand un incident est suspecté, le temps de réaction conditionne l'ampleur du dommage. Trois situations exigent un outillage in-app immédiat, sans détour par le support.
Un employé signale un comportement suspect sur son poste, son cookie de session a peut-être été siphonné par une extension malveillante, son téléphone vient d'être volé. Vous devez bloquer son accès aux secrets de l'organisation sans impacter ses autres engagements professionnels et sans perdre la trace forensique.
Phishing massif identifié, vol de credentials administrateurs, suspicion d'infiltration en profondeur : vous devez geler l'ensemble des accès d'une organisation en quelques secondes, sans risquer d'omettre un membre, et avec une trace inaltérable pour l'enquête a posteriori.
Le RGPD impose la notification d'une violation de données à caractère personnel à l'autorité de contrôle dans un délai de 72 heures, et dans certains cas aux personnes concernées. Le DPO et le RSSI ont besoin d'un journal opposable, daté et non-falsifiable, listant les actions menées et leur justification écrite.
Le niveau 1 répond à la situation la plus fréquente : suspicion ciblée sur une organisation précise, sans certitude d'une compromission plus large. L'impact reste strictement périmétré. Aucun utilisateur n'est déconnecté de ses autres organisations.
Le service positionne un horodatage de fin d'accès sur
chaque membre de l'organisation. Toutes les routes
retournent un code 403 dédié, accompagné d'un en-tête
X-Aegirex-Org-Suspended. Le cache de
métadonnées local côté navigateur et côté extension
est purgé pour cette organisation à la prochaine
requête.
Un consultant qui appartient à trois organisations clientes peut être suspendu sur l'une d'elles sans perdre l'accès aux deux autres. Sa session web reste valide, son vault personnel reste déverrouillé, ses secrets d'une autre organisation restent lisibles. Périmétrage strict, sans dégâts collatéraux.
Une fois la situation clarifiée, le même panneau
propose une réactivation par bouton dédié. L'action
est elle-même inscrite dans la chaîne d'audit
(org_membership_resumed). Aucune
manipulation manuelle de base, aucune dépendance au
support Aegirex.
Chaque membre suspendu reçoit un email reprenant le motif écrit par l'administrateur. Les autres administrateurs de l'organisation reçoivent une notification de contrôle social, pour qu'un déclenchement abusif soit visible immédiatement par leurs pairs.
Rôles habilités
Uniquement les rôles Owner et Admin de l'organisation concernée. Aucun rôle Member ne peut déclencher la suspension, même par accident. Les administrateurs d'une autre organisation n'ont aucune visibilité ni aucun pouvoir d'action sur l'organisation impactée.
Justification écrite obligatoire
Le déclencheur doit saisir un motif détaillé dans un champ texte libre. Aucune option « pas de raison » n'existe. Le motif est inscrit verbatim dans la chaîne d'audit HMAC et reproduit dans les emails de notification envoyés aux utilisateurs concernés.
Confirmation à deux étapes
La modale de confirmation impose de retaper le nom de l'organisation, sur le pattern GitHub « type the repo name to delete ». Cette friction délibérée évite tout déclenchement accidentel par clic réflexe.
Re-authentification MFA
Avant l'application, l'administrateur doit re-saisir son mot de passe et valider une étape MFA (TOTP, WebAuthn ou email backup). Un cookie de session volé ne suffit pas à déclencher la suspension.
Chaque déclenchement produit une entrée typée
org_membership_suspended_emergency dans la
chaîne d'audit HMAC-SHA-256. L'entrée contient
l'identifiant de l'organisation, l'identifiant de
l'administrateur acteur, le motif écrit, la liste des
utilisateurs affectés (par identifiant et hash SHA-256
de l'email), le compteur de membres impactés et
l'horodatage. La chaîne est vérifiable en ligne de
commande publique selon le mécanisme décrit sur la
page audit chain HMAC.
Le niveau 2 répond aux situations où la compromission dépasse le périmètre d'une organisation : poste utilisateur infecté par un malware, ordinateur volé sans chiffrement complet du disque, suspicion de présence persistante d'un attaquant. L'action est volontairement plus large et plus destructrice. Elle ne doit être déclenchée qu'en dernier recours.
Toutes les sessions web actives des membres sont tuées côté serveur. Les coffres locaux des utilisateurs concernés sont reverrouillés au prochain refresh d'onglet. La fonction « se souvenir de moi » est révoquée. Les utilisateurs sont contraints de se ré-authentifier intégralement, y compris depuis leurs autres organisations.
Quand le poste utilisateur lui-même est suspecté, la compromission ne se limite plus à une organisation : l'attaquant a vraisemblablement accès à toutes les organisations auxquelles l'utilisateur appartient. Une suspension chirurgicale serait insuffisante. L'effet cross-org est revendiqué et documenté.
Vol physique d'un device sans déchiffrement d'écran, malware identifié sur le poste d'un collaborateur clé, signal fort d'un endpoint EDR, suspicion forte de présence d'un attaquant interne avec accès au poste. Pour les suspicions plus circonscrites, le niveau 1 reste le bon choix.
Les trois garde-fous du niveau 1 s'appliquent identiquement au niveau 2 : motif texte obligatoire, recopie du nom de l'organisation pour confirmer, re-authentification password et MFA de l'administrateur. La friction est volontaire, proportionnelle à l'impact.
Le déclenchement produit une entrée
org_security_emergency_lockout dans la
chaîne HMAC, contenant le décompte des sessions tuées
par utilisateur. Au-delà de trois déclenchements sur la
même organisation en moins d'une heure, une alerte
interne est remontée à l'équipe support
ARDNTECH EI et un email est envoyé au contact
billing de l'organisation, pour qu'un abus
administrateur soit détecté rapidement. Aucun blocage
automatique : une véritable urgence peut nécessiter
plusieurs déclenchements consécutifs.
Un onglet déjà ouvert sur l'application au moment du lockout peut conserver des métadonnées en cache jusqu'à son auto-lock ou son rafraîchissement. La session web est tuée, donc tout fetch ultérieur force un re-login. Cette limitation est documentée dans les notes d'architecture et sera traitée par WebSocket push en V2. Le coffre déverrouillé en mémoire dans un SharedWorker existant suit le même cycle de vie : il se reverrouille au prochain rafraîchissement d'onglet.
La page sécurité opérationnelle s'articule avec le plan de réponse global déjà publié dans le threat model. Le tableau ci-dessous récapitule les trois niveaux standards, du chirurgical à la communication externe.
| Niveau | Déclencheur | Action |
|---|---|---|
| L1 Suspension chirurgicale | Suspicion ciblée sur une organisation : compte utilisateur compromis, signalement RH, anomalie audit log. | Blocage de l'accès aux secrets et folders de l'organisation pour tous ses membres. Aucun impact cross-org. Réversible par un bouton dédié. |
| L2 Lockout d'urgence | Compromission de poste utilisateur, vol de device, suspicion forte d'attaquant interne avec accès au poste. | Invalidation de toutes les sessions web, reverrouillage des coffres, révocation « remember me ». Impact cross-org assumé. |
| L3 Communication externe | Compromission technique confirmée par l'investigation interne ou externe avec exposition de données personnelles. | Notification CNIL et ANSSI sous 72 heures (RGPD Art. 33), rapport de transparence publié, audit forensique externe mandaté. |
Les niveaux L1 et L2 sont outillés in-app dans le panneau
paramètres organisation. Le niveau L3 relève d'une procédure
organisationnelle pilotée conjointement par le DPO et
l'éditeur, déclenchée par décision écrite et tracée dans la
chaîne d'audit (incident_l3_external_notification).
ARDNTECH EI s'engage sur un plan de réponse aligné avec les obligations RGPD pour les incidents impliquant des données personnelles. Le plan est aligné avec la posture publique du threat model et avec la politique de confidentialité.
En cas d'incident L3 affectant des données personnelles, ARDNTECH EI notifie la CNIL dans le délai prévu à l'article 33 du RGPD. La notification inclut la nature de la violation, les catégories de personnes concernées, les conséquences probables et les mesures prises. Les responsables de traitement clients sont informés en parallèle afin de pouvoir satisfaire leurs propres obligations.
Chaque incident L3 fait l'objet d'un rapport de transparence publié sur le site, après accord des autorités et anonymisation. Ce rapport détaille la chronologie, les causes techniques, les mesures correctives mises en place et les leçons retenues. La transparence est un engagement durable, pas une option commerciale.
En cas d'incident L3, un audit forensique indépendant est mandaté auprès d'un prestataire PASSI référencé ANSSI ou d'un cabinet équivalent. Le rapport synthétique est partagé avec les clients Business et Enterprise sous NDA, et un résumé public anonymisé est intégré au rapport de transparence.
Le tableau ci-dessous compare la disponibilité d'un outillage in-app de réponse à incident dans plusieurs gestionnaires de secrets B2B. Les informations sont établies à partir de la documentation publique en date du 2026-06-16 et peuvent évoluer. Aucun jugement qualitatif n'est porté sur la qualité globale des produits cités, tous reconnus dans leur catégorie.
| Éditeur | Suspension chirurgicale d'org | Lockout d'urgence global | Justification obligatoire en audit chain |
|---|---|---|---|
| Aegirex | Oui · in-app · panneau dédié | Oui · in-app · panneau dédié | Oui · HMAC-SHA-256 vérifiable en commande publique |
| Bitwarden | Selon documentation publique : suspension manuelle par retrait de l'utilisateur, pas de panneau dédié « incident ». | Selon documentation publique : pas d'action « kill all sessions for org » en console admin self-service. | Audit log présent, sans chaînage cryptographique vérifiable hors plateforme. |
| 1Password Business | Suspension d'utilisateur granulaire, sans bouton « gel d'organisation » dédié dans la documentation publique consultée. | Selon documentation publique : déconnexion par utilisateur, pas d'action de masse automatisée pour une équipe entière. | Audit log présent avec horodatage, signature cryptographique chaînée non documentée publiquement. |
| Dashlane Business | Suspension utilisateur via la console admin, sans panneau « réponse à incident » identifié dans la documentation publique. | Selon documentation publique : pas d'action de déconnexion globale dédiée avec justification obligatoire. | Audit log présent, modèle de chaînage cryptographique non documenté publiquement. |
| NordPass Business | Suspension utilisateur classique en console admin, pas de panneau « réponse à incident » dédié dans la documentation publique. | Selon documentation publique : pas d'action « lockout global org » en self-service avec garde-fous documentés. | Activity log présent, modèle de chaînage cryptographique non documenté publiquement. |
| Proton Pass Business | Gestion des accès par espace partagé, suspension utilisateur disponible dans la console admin selon documentation publique. | Selon documentation publique : pas d'action de déconnexion globale dédiée avec workflow distinct du retrait d'utilisateur. | Audit log présent, modèle de chaînage cryptographique non documenté publiquement à date. |
| Passbolt | Suspension utilisateur en console admin, outillage incident-response dédié non documenté à date dans la documentation publique consultée. | Selon documentation publique : pas d'action « kill all sessions for org » en self-service avec justification obligatoire. | Activity log présent, chaînage HMAC public non documenté à date. |
Sources : documentation produit publique des éditeurs consultée en date du 2026-06-16. La plupart des concurrents proposent un retrait d'utilisateur efficace pour l'offboarding ; la spécificité d'Aegirex est de distinguer formellement l'opération « suspension d'incident » de l'opération « retrait d'utilisateur », avec un panneau dédié, une justification obligatoire, une chaîne d'audit HMAC vérifiable et un workflow gradué en deux niveaux. Si une information vous semble inexacte, contactez legal@aegirex.eu : cette page est mise à jour rapidement.
Le module de réponse à incident est inclus dans toutes les offres Aegirex, y compris le plan gratuit. Il fait partie du socle « sécurité hors paywall » revendiqué publiquement. Demandez l'accès à la bêta privée pour tester la suspension chirurgicale et le lockout d'urgence sur une organisation pilote, ou lisez le threat model complet pour comprendre la posture défensive globale.
