Większość menedżerów sekretów B2B nie zapewnia żadnych narzędzi in-app do obsługi incydentu : trzeba otworzyć zgłoszenie do supportu, czekać na interwencję człowieka i tłumaczyć sytuację handlowcowi. ARDNTECH postawił na odwrotne podejście : dedykowany panel w ustawieniach organizacji, dwie stopniowane akcje, obowiązkowe uzasadnienie pisemne, niezmienialny łańcuch audytu HMAC. Zaprojektowane tak, aby CISO mógł zareagować w kilka sekund, bez zależności od naszego zespołu.
Menedżer sekretów z założenia koncentruje najbardziej wrażliwą wartość organizacji. Gdy podejrzewany jest incydent, czas reakcji decyduje o skali szkody. Trzy sytuacje wymagają natychmiastowych narzędzi in-app, bez obchodzenia przez support.
Pracownik zgłasza podejrzane zachowanie na swoim stanowisku, jego plik cookie sesji mógł zostać przechwycony przez złośliwe rozszerzenie, jego telefon właśnie został skradziony. Musisz zablokować jego dostęp do sekretów organizacji, nie wpływając na pozostałe zaangażowania zawodowe i nie tracąc śladu śledczego.
Zidentyfikowany masowy phishing, kradzież poświadczeń administratorów, podejrzenie głębokiej infiltracji : musisz zamrozić wszystkie dostępy organizacji w kilka sekund, bez ryzyka pominięcia członka i z niezmienialnym śladem dla późniejszego dochodzenia.
RODO wymaga powiadomienia o naruszeniu danych osobowych organu nadzorczego w terminie 72 godzin, a w niektórych przypadkach także osób, których dane dotyczą. IOD i CISO potrzebują wiarygodnego, datowanego i niefałszowalnego dziennika, wymieniającego podjęte działania i ich pisemne uzasadnienie.
Poziom 1 odpowiada na najczęstszą sytuację : ukierunkowane podejrzenie wobec konkretnej organizacji, bez pewności co do szerszego naruszenia. Wpływ pozostaje ściśle ograniczony. Żaden użytkownik nie zostaje wylogowany ze swoich pozostałych organizacji.
Usługa ustawia znacznik czasu zakończenia dostępu dla każdego członka organizacji. Wszystkie trasy zwracają dedykowany kod 403 wraz z nagłówkiem <code>X-ARDNTECH-Org-Suspended</code>. Lokalna pamięć podręczna metadanych po stronie przeglądarki i rozszerzenia zostaje wyczyszczona dla tej organizacji przy następnym żądaniu.
Konsultant należący do trzech organizacji klienckich może zostać zawieszony w jednej z nich, nie tracąc dostępu do dwóch pozostałych. Jego sesja webowa pozostaje ważna, jego osobisty sejf pozostaje odblokowany, jego sekrety z innej organizacji pozostają czytelne. Ścisłe ograniczenie zakresu, bez szkód ubocznych.
Po wyjaśnieniu sytuacji ten sam panel oferuje ponowną aktywację za pomocą dedykowanego przycisku. Akcja sama w sobie jest zapisywana w łańcuchu audytu (<code>org_membership_resumed</code>). Bez ręcznej manipulacji bazą danych, bez zależności od supportu ARDNTECH.
Każdy zawieszony członek otrzymuje e-mail zawierający powód napisany przez administratora. Pozostali administratorzy organizacji otrzymują powiadomienie kontroli społecznej, aby nadużycie było natychmiast widoczne dla ich współpracowników.
Uprawnione role
Wyłącznie role <strong>Owner</strong> i <strong>Admin</strong> danej organizacji. Żadna rola Member nie może uruchomić zawieszenia, nawet przez przypadek. Administratorzy innej organizacji nie mają żadnej widoczności ani możliwości działania wobec dotkniętej organizacji.
Obowiązkowe uzasadnienie pisemne
Osoba uruchamiająca musi wpisać szczegółowy powód w polu tekstowym. Nie istnieje opcja "bez powodu". Powód jest zapisywany dosłownie w łańcuchu audytu HMAC i powielany w e-mailach z powiadomieniami wysyłanych do dotkniętych użytkowników.
Potwierdzenie dwuetapowe
Okno potwierdzenia wymaga ponownego wpisania nazwy organizacji, na wzór GitHuba "type the repo name to delete". To celowe utrudnienie zapobiega przypadkowemu uruchomieniu przez odruchowe kliknięcie.
Ponowne uwierzytelnienie MFA
Przed zastosowaniem administrator musi ponownie wpisać hasło i zatwierdzić krok MFA (TOTP, WebAuthn lub kopia zapasowa e-mail). Skradziony plik cookie sesji nie wystarczy do uruchomienia zawieszenia.
Każde uruchomienie tworzy wpis typu <code>org_membership_suspended_emergency</code> w łańcuchu audytu HMAC-SHA-256. Wpis zawiera identyfikator organizacji, identyfikator administratora wykonującego akcję, pisemny powód, listę dotkniętych użytkowników (po identyfikatorze i hashu SHA-256 adresu e-mail), licznik dotkniętych członków oraz znacznik czasu. Łańcuch jest weryfikowalny w publicznej linii poleceń zgodnie z mechanizmem opisanym na <a href="{link}">stronie łańcucha audytu HMAC</a>.
Poziom 2 odpowiada na sytuacje, w których naruszenie wykracza poza zakres jednej organizacji : stanowisko użytkownika zainfekowane malware, skradziony komputer bez pełnego szyfrowania dysku, podejrzenie trwałej obecności atakującego. Akcja jest celowo szersza i bardziej destrukcyjna. Powinna być uruchamiana wyłącznie w ostateczności.
Wszystkie aktywne sesje webowe członków są kończone po stronie serwera. Lokalne sejfy dotkniętych użytkowników są ponownie blokowane przy następnym odświeżeniu karty. Funkcja "zapamiętaj mnie" zostaje unieważniona. Użytkownicy są zmuszeni do pełnego ponownego uwierzytelnienia, również ze swoich pozostałych organizacji.
Gdy podejrzewane jest samo stanowisko użytkownika, naruszenie nie ogranicza się już do jednej organizacji : atakujący prawdopodobnie ma dostęp do wszystkich organizacji, do których należy użytkownik. Chirurgiczne zawieszenie byłoby niewystarczające. Efekt cross-org jest zamierzony i udokumentowany.
Fizyczna kradzież urządzenia bez szyfrowania ekranu, zidentyfikowane malware na stanowisku kluczowego współpracownika, silny sygnał z endpointa EDR, mocne podejrzenie obecności wewnętrznego atakującego z dostępem do stanowiska. W przypadku bardziej ograniczonych podejrzeń poziom 1 pozostaje właściwym wyborem.
Trzy zabezpieczenia poziomu 1 stosują się identycznie do poziomu 2 : obowiązkowy powód tekstowy, przepisanie nazwy organizacji w celu potwierdzenia, ponowne uwierzytelnienie hasłem i MFA administratora. Utrudnienie jest celowe, proporcjonalne do wpływu.
Uruchomienie tworzy wpis <code>org_security_emergency_lockout</code> w łańcuchu HMAC, zawierający liczbę zakończonych sesji na użytkownika. Po przekroczeniu trzech uruchomień w tej samej organizacji w czasie krótszym niż godzina, wewnętrzny alert trafia do zespołu supportu ARDNTECH, a e-mail jest wysyłany do kontaktu rozliczeniowego organizacji, aby szybko wykryć nadużycie ze strony administratora. Brak automatycznej blokady : prawdziwa sytuacja awaryjna może wymagać kilku kolejnych uruchomień.
Karta już otwarta w aplikacji w momencie lockoutu może zachować metadane w pamięci podręcznej aż do auto-blokady lub odświeżenia. Sesja webowa zostaje zakończona, więc każde kolejne pobranie wymusza ponowne logowanie. To ograniczenie jest udokumentowane w notatkach architektonicznych i zostanie rozwiązane przez WebSocket push w V2. Sejf odblokowany w pamięci w istniejącym SharedWorker podlega temu samemu cyklowi życia : zostaje ponownie zablokowany przy następnym odświeżeniu karty.
Strona bezpieczeństwa operacyjnego łączy się z globalnym planem reakcji opublikowanym już w threat modelu. Poniższa tabela podsumowuje trzy standardowe poziomy, od chirurgicznego po komunikację zewnętrzną.
| Poziom | Wyzwalacz | Akcja |
|---|---|---|
| <span class="m-tag m-tag--info">L1</span> Chirurgiczne zawieszenie | Ukierunkowane podejrzenie wobec organizacji : naruszone konto użytkownika, zgłoszenie HR, anomalia w logu audytu. | Zablokowanie dostępu do sekretów i folderów organizacji dla wszystkich jej członków. Brak wpływu cross-org. Odwracalne za pomocą dedykowanego przycisku. |
| <span class="m-tag m-tag--warning">L2</span> Awaryjny lockout | Naruszenie stanowiska użytkownika, kradzież urządzenia, mocne podejrzenie wewnętrznego atakującego z dostępem do stanowiska. | Unieważnienie wszystkich sesji webowych, ponowne zablokowanie sejfów, unieważnienie "remember me". Świadomy wpływ cross-org. |
| <span class="m-tag m-tag--danger">L3</span> Komunikacja zewnętrzna | Naruszenie techniczne potwierdzone przez dochodzenie wewnętrzne lub zewnętrzne z ekspozycją danych osobowych. | Powiadomienie organu nadzorczego i ANSSI w ciągu 72 godzin (RODO Art. 33), opublikowany raport transparentności, zlecony zewnętrzny audyt śledczy. |
Poziomy L1 i L2 są obsługiwane in-app w panelu ustawień organizacji. Poziom L3 należy do procedury organizacyjnej prowadzonej wspólnie przez IOD i wydawcę, uruchamianej na podstawie pisemnej decyzji i śledzonej w łańcuchu audytu (<code>incident_l3_external_notification</code>).
ARDNTECH zobowiązuje się do planu reakcji zgodnego z obowiązkami RODO dla incydentów dotyczących danych osobowych. Plan jest zgodny z publiczną postawą threat modelu oraz z polityką prywatności.
W przypadku incydentu L3 dotyczącego danych osobowych ARDNTECH powiadamia organ nadzorczy w terminie przewidzianym w artykule 33 RODO. Powiadomienie obejmuje charakter naruszenia, kategorie osób, których dane dotyczą, prawdopodobne konsekwencje oraz podjęte środki. Administratorzy danych będący klientami są informowani równolegle, aby mogli wypełnić własne obowiązki.
Każdy incydent L3 jest przedmiotem raportu transparentności publikowanego na stronie, po uzgodnieniu z organami i anonimizacji. Raport szczegółowo opisuje chronologię, przyczyny techniczne, wdrożone środki naprawcze oraz wyciągnięte wnioski. Transparentność to trwałe zobowiązanie, a nie opcja handlowa.
W przypadku incydentu L3 zlecany jest niezależny audyt śledczy u dostawcy PASSI z referencjami ANSSI lub w równoważnej firmie. Raport syntetyczny jest udostępniany klientom Business i Enterprise na podstawie NDA, a publiczne, zanonimizowane podsumowanie jest włączane do raportu transparentności.
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.
