A legtöbb B2B titokkezelő semmilyen alkalmazáson belüli eszköztárat nem nyújt egy incidens kezeléséhez: support jegyet kell nyitni, emberi beavatkozásra várni és elmagyarázni a helyzetet egy értékesítőnek. Az ARDNTECH az ellenkező döntést hozza: dedikált panel a szervezet beállításaiban, két fokozatos művelet, kötelező írásos indoklás, megváltoztathatatlan HMAC audit lánc. Úgy tervezve, hogy egy CISO néhány másodperc alatt reagálhasson, csapatunktól való függőség nélkül.
Egy titokkezelő felépítéséből adódóan egy szervezet legérzékenyebb értékét koncentrálja. Amikor egy incidens gyanús, a reakcióidő szabja meg a kár mértékét. Három helyzet azonnali alkalmazáson belüli eszköztárat igényel, a support megkerülése nélkül.
Egy alkalmazott gyanús viselkedést jelez a munkaállomásán, a munkamenet-cookie-ját talán lecsapolta egy rosszindulatú bővítmény, a telefonját éppen ellopták. Blokkolnia kell a hozzáférését a szervezet titkaihoz anélkül, hogy hatással lenne más szakmai kötelezettségeire, és a forenzikus nyom elvesztése nélkül.
Azonosított tömeges phishing, adminisztrátori hitelesítők ellopása, mélyreható beszivárgás gyanúja: néhány másodperc alatt be kell fagyasztania egy szervezet összes hozzáférését, anélkül hogy egy tagot kihagyna, és egy megváltoztathatatlan nyommal az utólagos vizsgálathoz.
A GDPR előírja egy személyes adatokat érintő jogsértés bejelentését a felügyeleti hatóságnak 72 órán belül, és bizonyos esetekben az érintett személyeknek. A DPO-nak és a CISO-nak számon kérhető, dátumozott és hamisíthatatlan naplóra van szüksége, amely felsorolja a megtett intézkedéseket és azok írásos indoklását.
Az 1. szint a leggyakoribb helyzetre válaszol: egy adott szervezetre irányuló célzott gyanú, egy szélesebb körű kompromittálódás bizonyossága nélkül. A hatás szigorúan körülhatárolt marad. Egyetlen felhasználót sem jelentkeztetnek ki a többi szervezetéből.
A szolgáltatás hozzáférés-vég időbélyeget állít be a szervezet minden tagjára. Minden útvonal dedikált 403-as kódot ad vissza, egy <code>X-ARDNTECH-Org-Suspended</code> fejléccel kísérve. A böngésző és a bővítmény oldali helyi metaadat-gyorsítótár a következő kérésnél ürül erre a szervezetre nézve.
Egy tanácsadó, aki három ügyfélszervezethez tartozik, felfüggeszthető az egyiken anélkül, hogy elveszítené a hozzáférést a másik kettőhöz. Webes munkamenete érvényes marad, személyes széfje feloldva marad, egy másik szervezet titkai olvashatók maradnak. Szigorú körülhatárolás, járulékos károk nélkül.
Miután a helyzet tisztázódott, ugyanaz a panel újraaktiválást kínál egy dedikált gombbal. Maga a művelet is bekerül az audit láncba (<code>org_membership_resumed</code>). Semmilyen kézi adatbázis-manipuláció, semmilyen függőség az ARDNTECH supporttól.
Minden felfüggesztett tag e-mailt kap, amely tartalmazza az adminisztrátor által írt indokot. A szervezet többi adminisztrátora társadalmi kontroll értesítést kap, hogy egy visszaélésszerű kiváltás azonnal láthatóvá váljon a társaik számára.
Jogosult szerepkörök
Kizárólag az érintett szervezet <strong>Owner</strong> és <strong>Admin</strong> szerepkörei. Egyetlen Member szerepkör sem válthatja ki a felfüggesztést, még véletlenül sem. Egy másik szervezet adminisztrátorainak semmilyen láthatóságuk vagy cselekvési hatalmuk nincs az érintett szervezet felett.
Kötelező írásos indoklás
A kiváltónak részletes indokot kell megadnia egy szabad szöveges mezőben. Nem létezik "nincs ok" lehetőség. Az indok szó szerint bekerül a HMAC audit láncba, és megjelenik az érintett felhasználóknak küldött értesítő e-mailekben.
Kétlépéses megerősítés
A megerősítő modál megköveteli a szervezet nevének újbóli beírását, a GitHub "type the repo name to delete" mintája szerint. Ez a szándékos súrlódás megakadályoz minden véletlen, reflexes kattintással történő kiváltást.
MFA újrahitelesítés
Az alkalmazás előtt az adminisztrátornak újra be kell írnia a jelszavát, és érvényesítenie kell egy MFA lépést (TOTP, WebAuthn vagy e-mail backup). Egy ellopott munkamenet-cookie nem elég a felfüggesztés kiváltásához.
Minden kiváltás egy típusos <code>org_membership_suspended_emergency</code> bejegyzést hoz létre a HMAC-SHA-256 audit láncban. A bejegyzés tartalmazza a szervezet azonosítóját, a cselekvő adminisztrátor azonosítóját, az írásos indokot, az érintett felhasználók listáját (azonosító és az e-mail SHA-256 hash-e szerint), az érintett tagok számlálóját és az időbélyeget. A lánc nyilvános parancssorból ellenőrizhető a <a href="{link}">HMAC audit lánc oldalon</a> leírt mechanizmus szerint.
A 2. szint azokra a helyzetekre válaszol, ahol a kompromittálódás meghaladja egy szervezet kerületét: malware-rel fertőzött felhasználói munkaállomás, teljes lemeztitkosítás nélkül ellopott számítógép, egy támadó tartós jelenlétének gyanúja. A művelet szándékosan szélesebb és pusztítóbb. Csak végső esetben szabad kiváltani.
A tagok minden aktív webes munkamenete megszűnik a szerver oldalán. Az érintett felhasználók helyi széfjei a következő lapfrissítéskor újrazáródnak. Az "emlékezz rám" funkció visszavonásra kerül. A felhasználók kénytelenek teljesen újrahitelesíteni, beleértve a többi szervezetükből is.
Amikor maga a felhasználó munkaállomása gyanús, a kompromittálódás már nem korlátozódik egy szervezetre: a támadónak valószínűleg hozzáférése van minden szervezethez, amelyhez a felhasználó tartozik. Egy sebészi felfüggesztés nem lenne elegendő. A szervezetek közötti hatás vállalt és dokumentált.
Egy eszköz fizikai ellopása képernyő-visszafejtés nélkül, egy kulcsfontosságú munkatárs munkaállomásán azonosított malware, egy EDR endpoint erős jelzése, egy a munkaállomáshoz hozzáféréssel rendelkező belső támadó jelenlétének erős gyanúja. A körülhatároltabb gyanúknál az 1. szint marad a jó választás.
Az 1. szint három védőkorlátja azonos módon vonatkozik a 2. szintre is: kötelező szöveges indok, a szervezet nevének átmásolása a megerősítéshez, az adminisztrátor jelszó és MFA újrahitelesítése. A súrlódás szándékos, arányos a hatással.
A kiváltás egy <code>org_security_emergency_lockout</code> bejegyzést hoz létre a HMAC láncban, amely tartalmazza a felhasználónként megszüntetett munkamenetek számát. Ugyanazon szervezeten egy órán belüli három kiváltáson túl belső riasztás kerül az ARDNTECH support csapatához, és e-mail megy a szervezet számlázási kapcsolattartójához, hogy egy adminisztrátori visszaélés gyorsan felismerésre kerüljön. Semmilyen automatikus blokkolás: egy valódi vészhelyzet több egymást követő kiváltást igényelhet.
Egy a vészleállás pillanatában már az alkalmazáson megnyitott lap megőrizhet metaadatokat a gyorsítótárban az automatikus zárolásig vagy a frissítéséig. A webes munkamenet megszűnik, így minden későbbi fetch újrabejelentkezést kényszerít ki. Ez a korlátozás dokumentálva van az architektúra-jegyzetekben, és WebSocket push-sal kerül kezelésre a V2-ben. A meglévő SharedWorkerben a memóriában feloldott széf ugyanazt az életciklust követi: a következő lapfrissítéskor újrazáródik.
Az operatív biztonsági oldal a fenyegetési modellben már közzétett átfogó reagálási tervhez kapcsolódik. Az alábbi táblázat összefoglalja a három standard szintet, a sebészitől a külső kommunikációig.
| Szint | Kiváltó ok | Művelet |
|---|---|---|
| <span class="m-tag m-tag--info">L1</span> Sebészi felfüggesztés | Egy szervezetre irányuló célzott gyanú: kompromittált felhasználói fiók, HR-bejelentés, audit napló anomália. | A szervezet titkaihoz és mappáihoz való hozzáférés blokkolása minden tag számára. Semmilyen szervezetek közötti hatás. Visszafordítható egy dedikált gombbal. |
| <span class="m-tag m-tag--warning">L2</span> Vészleállás | Felhasználói munkaállomás kompromittálódása, eszköz ellopása, a munkaállomáshoz hozzáféréssel rendelkező belső támadó erős gyanúja. | Minden webes munkamenet érvénytelenítése, a széfek újrazárása, az "emlékezz rám" visszavonása. Vállalt szervezetek közötti hatás. |
| <span class="m-tag m-tag--danger">L3</span> Külső kommunikáció | A belső vagy külső vizsgálat által megerősített technikai kompromittálódás személyes adatok kitettségével. | CNIL és ANSSI értesítés 72 órán belül (GDPR 33. cikk), közzétett átláthatósági jelentés, megbízott külső forenzikus audit. |
Az L1 és L2 szintek alkalmazáson belül vannak felszerelve a szervezet beállításai panelben. Az L3 szint a DPO és a kiadó által közösen vezérelt szervezeti eljárás alá tartozik, írásos döntéssel kiváltva és az audit láncban nyomonkövetve (<code>incident_l3_external_notification</code>).
Az ARDNTECH egy olyan reagálási tervet vállal, amely igazodik a személyes adatokat érintő incidensek GDPR-kötelezettségeihez. A terv összhangban van a fenyegetési modell nyilvános pozíciójával és az adatvédelmi szabályzattal.
Egy személyes adatokat érintő L3 incidens esetén az ARDNTECH a GDPR 33. cikkében előírt határidőn belül értesíti a CNIL-t. Az értesítés tartalmazza a jogsértés jellegét, az érintett személyek kategóriáit, a valószínű következményeket és a megtett intézkedéseket. Az ügyfél adatkezelőket párhuzamosan tájékoztatjuk, hogy teljesíthessék saját kötelezettségeiket.
Minden L3 incidensről átláthatósági jelentés jelenik meg a webhelyen, a hatóságok jóváhagyása és az anonimizálás után. Ez a jelentés részletezi az időrendet, a technikai okokat, a bevezetett javító intézkedéseket és a levont tanulságokat. Az átláthatóság tartós kötelezettségvállalás, nem kereskedelmi opció.
Egy L3 incidens esetén független forenzikus auditot bízunk meg egy ANSSI-referált PASSI szolgáltatónál vagy egy egyenértékű irodánál. Az összefoglaló jelentést a Business és Enterprise ügyfelekkel NDA alatt osztjuk meg, és egy nyilvános anonimizált összefoglaló kerül az átláthatósági jelentésbe.
Az alábbi táblázat összehasonlítja az alkalmazáson belüli incidensreagálási eszköztár elérhetőségét több B2B titokkezelőben. Az információk a(z) 2026-08-01 napi nyilvános dokumentáció alapján készültek, és változhatnak. Az említett termékek általános minőségéről semmilyen minőségi ítéletet nem mondunk, mindegyik elismert a saját kategóriájában.
| Kiadó | Sebészi szervezetfelfüggesztés | Globális vészleállás | Az audit láncban kötelező indoklás |
|---|---|---|---|
| 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. |
Források: a kiadók nyilvános termékdokumentációja, megtekintve a(z) 2026-08-01 napon. A legtöbb versenytárs hatékony felhasználó-eltávolítást kínál az offboardinghoz; az ARDNTECH sajátossága, hogy formálisan megkülönbözteti az "incidensfelfüggesztés" műveletet a "felhasználó-eltávolítás" művelettől, dedikált panellel, kötelező indoklással, ellenőrizhető HMAC audit lánccal és kétszintű, fokozatos munkafolyamattal. Ha egy információ pontatlannak tűnik, lépjen kapcsolatba a legal@aegirex.eu címmel: ezt az oldalt gyorsan frissítjük.
Az incidensreagálási modul minden ARDNTECH ajánlatban benne van, az ingyenes csomagot is beleértve. Része a nyilvánosan vállalt "biztonság a fizetős fal nélkül" alapnak. Kérjen hozzáférést a privát bétához a sebészi felfüggesztés és a vészleállás teszteléséhez egy pilot szervezeten, vagy olvassa el a teljes fenyegetési modellt az átfogó védelmi pozíció megértéséhez.
