Більшість B2B-менеджерів секретів не надають жодного вбудованого інструментарію для керування інцидентом: потрібно відкрити тікет у підтримці, чекати на втручання людини та пояснювати ситуацію менеджеру з продажів. ARDNTECH робить протилежний вибір: спеціальна панель у налаштуваннях організації, дві градуйовані дії, обов'язкове письмове обґрунтування, незмінний ланцюг аудиту HMAC. Створено так, щоб RSSI міг відреагувати за кілька секунд, без залежності від нашої команди.
Менеджер секретів за своєю конструкцією концентрує найчутливішу цінність організації. Коли підозрюється інцидент, час реакції визначає масштаб шкоди. Три ситуації вимагають негайного вбудованого інструментарію, без звернення до підтримки.
Співробітник повідомляє про підозрілу поведінку на своєму пристрої, його cookie сесії, можливо, було викрадено шкідливим розширенням, його телефон щойно вкрали. Вам потрібно заблокувати його доступ до секретів організації, не впливаючи на інші його професійні зобов'язання і не втрачаючи форензичний слід.
Виявлено масовий фішинг, викрадення облікових даних адміністратора, підозра на глибоку інфільтрацію: вам потрібно заморозити всі доступи організації за кілька секунд, не ризикуючи пропустити учасника, і з незмінним слідом для подальшого розслідування.
RGPD вимагає сповіщення про порушення персональних даних наглядовому органу у строк 72 години, а в деяких випадках і відповідним особам. DPO та RSSI потребують протиставного, датованого та нефальсифікованого журналу, що перелічує вжиті дії та їхнє письмове обґрунтування.
Рівень 1 відповідає на найпоширенішу ситуацію: цільова підозра щодо конкретної організації без впевненості у ширшій компрометації. Вплив залишається строго обмеженим. Жодного користувача не відключають від його інших організацій.
Сервіс встановлює часову мітку завершення доступу для кожного учасника організації. Усі маршрути повертають спеціальний код 403 разом із заголовком <code>X-ARDNTECH-Org-Suspended</code>. Локальний кеш метаданих на боці браузера та розширення очищується для цієї організації під час наступного запиту.
Консультант, який належить до трьох клієнтських організацій, може бути призупинений в одній з них без втрати доступу до двох інших. Його вебсесія залишається дійсною, його особисте сховище залишається розблокованим, його секрети іншої організації залишаються читабельними. Строге обмеження периметра, без побічної шкоди.
Щойно ситуацію з'ясовано, та сама панель пропонує реактивацію спеціальною кнопкою. Сама дія записується у ланцюг аудиту (<code>org_membership_resumed</code>). Жодних ручних маніпуляцій з базою, жодної залежності від підтримки ARDNTECH.
Кожен призупинений учасник отримує лист із причиною, написаною адміністратором. Інші адміністратори організації отримують сповіщення соціального контролю, щоб зловмисне спрацювання було негайно помітним для їхніх колег.
Уповноважені ролі
Лише ролі <strong>Owner</strong> та <strong>Admin</strong> відповідної організації. Жодна роль Member не може запустити призупинення, навіть випадково. Адміністратори іншої організації не мають жодної видимості чи можливості діяти щодо ураженої організації.
Обов'язкове письмове обґрунтування
Ініціатор має ввести детальну причину у вільне текстове поле. Жодного варіанту «без причини» не існує. Причина записується дослівно у ланцюг аудиту HMAC і відтворюється у листах-сповіщеннях, надісланих відповідним користувачам.
Дворівневе підтвердження
Модальне вікно підтвердження вимагає повторно ввести назву організації, за патерном GitHub «type the repo name to delete». Це навмисне тертя запобігає будь-якому випадковому спрацюванню рефлекторним кліком.
Повторна автентифікація MFA
Перед застосуванням адміністратор має повторно ввести свій пароль і підтвердити крок MFA (TOTP, WebAuthn або резервний email). Викраденого cookie сесії недостатньо для запуску призупинення.
Кожне спрацювання створює типізований запис <code>org_membership_suspended_emergency</code> у ланцюгу аудиту HMAC-SHA-256. Запис містить ідентифікатор організації, ідентифікатор адміністратора-актора, письмову причину, перелік уражених користувачів (за ідентифікатором та хешем SHA-256 електронної пошти), лічильник уражених учасників і часову мітку. Ланцюг можна перевірити публічною командою у командному рядку за механізмом, описаним на <a href="{link}">сторінці ланцюга аудиту HMAC</a>.
Рівень 2 відповідає на ситуації, коли компрометація виходить за межі однієї організації: пристрій користувача заражено шкідливим ПЗ, викрадено комп'ютер без повного шифрування диска, підозра на стійку присутність зловмисника. Дія навмисно ширша і руйнівніша. Її слід запускати лише в крайньому разі.
Усі активні вебсесії учасників завершуються на боці сервера. Локальні сховища відповідних користувачів повторно блокуються під час наступного оновлення вкладки. Функцію «запам'ятати мене» відкликано. Користувачі змушені повністю повторно автентифікуватися, зокрема й зі своїх інших організацій.
Коли підозра падає на сам пристрій користувача, компрометація вже не обмежується однією організацією: ймовірно, зловмисник має доступ до всіх організацій, до яких належить користувач. Хірургічного призупинення було б недостатньо. Крос-організаційний ефект заявлено та задокументовано.
Фізичне викрадення пристрою без шифрування екрана, виявлене шкідливе ПЗ на пристрої ключового співробітника, сильний сигнал від EDR-ендпойнта, серйозна підозра на присутність внутрішнього зловмисника з доступом до пристрою. Для більш обмежених підозр рівень 1 залишається правильним вибором.
Три запобіжники рівня 1 застосовуються однаково й до рівня 2: обов'язкова текстова причина, перепис назви організації для підтвердження, повторна автентифікація паролем і MFA адміністратора. Тертя навмисне, пропорційне впливу.
Спрацювання створює запис <code>org_security_emergency_lockout</code> у ланцюгу HMAC, що містить підрахунок завершених сесій на кожного користувача. У разі понад трьох спрацювань на одній організації менш ніж за годину внутрішнє сповіщення передається команді підтримки ARDNTECH і надсилається лист контакту білінгу організації, щоб зловживання адміністратора було швидко виявлено. Жодного автоматичного блокування: справжня аварійна ситуація може вимагати кількох послідовних спрацювань.
Вкладка, вже відкрита в застосунку на момент блокування, може зберігати метадані в кеші до свого автоблокування або оновлення. Вебсесію завершено, тож будь-яке подальше отримання даних змушує повторний вхід. Це обмеження задокументовано в архітектурних нотатках і буде усунено через WebSocket push у V2. Сховище, розблоковане в пам'яті в наявному SharedWorker, проходить той самий життєвий цикл: воно повторно блокується під час наступного оновлення вкладки.
Сторінка операційної безпеки узгоджується із загальним планом реакції, вже опублікованим у моделі загроз. Таблиця нижче підсумовує три стандартні рівні, від хірургічного до зовнішньої комунікації.
| Рівень | Тригер | Дія |
|---|---|---|
| <span class="m-tag m-tag--info">L1</span> Хірургічне призупинення | Цільова підозра щодо організації: скомпрометований обліковий запис користувача, сигнал від HR, аномалія в журналі аудиту. | Блокування доступу до секретів і тек організації для всіх її учасників. Жодного крос-організаційного впливу. Оборотно спеціальною кнопкою. |
| <span class="m-tag m-tag--warning">L2</span> Аварійне блокування | Компрометація пристрою користувача, викрадення пристрою, серйозна підозра на внутрішнього зловмисника з доступом до пристрою. | Анулювання всіх вебсесій, повторне блокування сховищ, відкликання «remember me». Свідомий крос-організаційний вплив. |
| <span class="m-tag m-tag--danger">L3</span> Зовнішня комунікація | Технічна компрометація, підтверджена внутрішнім або зовнішнім розслідуванням, з розкриттям персональних даних. | Сповіщення CNIL та ANSSI протягом 72 годин (RGPD Ст. 33), опублікований звіт прозорості, призначений зовнішній форензичний аудит. |
Рівні L1 та L2 оснащені вбудованим інструментарієм у панелі налаштувань організації. Рівень L3 належить до організаційної процедури, керованої спільно DPO та видавцем, що запускається письмовим рішенням і фіксується у ланцюгу аудиту (<code>incident_l3_external_notification</code>).
ARDNTECH бере на себе зобов'язання щодо плану реакції, узгодженого з вимогами RGPD для інцидентів, що стосуються персональних даних. План узгоджено з публічною позицією моделі загроз та з політикою конфіденційності.
У разі інциденту L3, що зачіпає персональні дані, ARDNTECH сповіщає CNIL у строк, передбачений статтею 33 RGPD. Сповіщення включає характер порушення, категорії відповідних осіб, ймовірні наслідки та вжиті заходи. Контролери даних клієнтів інформуються паралельно, щоб мати змогу виконати власні зобов'язання.
Кожен інцидент L3 є предметом звіту прозорості, опублікованого на сайті, після погодження з органами та анонімізації. Цей звіт детально описує хронологію, технічні причини, вжиті коригувальні заходи та засвоєні уроки. Прозорість - це тривале зобов'язання, а не комерційна опція.
У разі інциденту L3 призначається незалежний форензичний аудит у постачальника PASSI, акредитованого ANSSI, або в еквівалентної фірми. Стислий звіт надається клієнтам Business та Enterprise під NDA, а публічне анонімізоване резюме включається до звіту прозорості.
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-08-01 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 |
|---|---|---|---|
| ARDNTECH | 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-08-01. La plupart des concurrents proposent un retrait d'utilisateur efficace pour l'offboarding ; la spécificité d'ARDNTECH 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 ARDNTECH, 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.
