A maioria dos gestores de segredos B2B não fornece qualquer ferramenta in-app para gerir um incidente: é preciso abrir um ticket de suporte, aguardar uma intervenção humana e explicar a situação a um comercial. A ARDNTECH faz a escolha inversa: um painel dedicado nas definições da organização, duas ações graduadas, justificação escrita obrigatória, audit chain HMAC inalterável. Concebido para que um RSSI possa reagir em alguns segundos, sem dependência da nossa equipa.
Um gestor de segredos concentra por construção o valor mais sensível de uma organização. Quando um incidente é suspeito, o tempo de reação condiciona a amplitude do dano. Três situações exigem uma ferramenta in-app imediata, sem desvio pelo suporte.
Um colaborador sinaliza um comportamento suspeito no seu posto, o seu cookie de sessão pode ter sido sifonado por uma extensão maliciosa, o seu telemóvel acabou de ser roubado. Tem de bloquear o seu acesso aos segredos da organização sem impactar os seus outros compromissos profissionais e sem perder o rasto forense.
Phishing massivo identificado, roubo de credenciais de administradores, suspeita de infiltração em profundidade: tem de congelar a totalidade dos acessos de uma organização em alguns segundos, sem arriscar omitir um membro, e com um rasto inalterável para a investigação a posteriori.
O RGPD impõe a notificação de uma violação de dados pessoais à autoridade de controlo num prazo de 72 horas, e em certos casos às pessoas em causa. O DPO e o RSSI precisam de um registo oponível, datado e não falsificável, que liste as ações realizadas e a sua justificação escrita.
O nível 1 responde à situação mais frequente: suspeita dirigida a uma organização precisa, sem certeza de um comprometimento mais alargado. O impacto permanece estritamente delimitado. Nenhum utilizador é desconectado das suas outras organizações.
O serviço posiciona um carimbo temporal de fim de acesso sobre cada membro da organização. Todas as rotas devolvem um código 403 dedicado, acompanhado de um cabeçalho <code>X-ARDNTECH-Org-Suspended</code>. A cache de metadados local no navegador e na extensão é purgada para esta organização no próximo pedido.
Um consultor que pertence a três organizações clientes pode ser suspenso numa delas sem perder o acesso às outras duas. A sua sessão web permanece válida, o seu cofre pessoal permanece desbloqueado, os seus segredos de outra organização permanecem legíveis. Delimitação estrita, sem danos colaterais.
Uma vez clarificada a situação, o mesmo painel propõe uma reativação por botão dedicado. A ação é ela própria inscrita na cadeia de auditoria (<code>org_membership_resumed</code>). Nenhuma manipulação manual de base de dados, nenhuma dependência do suporte ARDNTECH.
Cada membro suspenso recebe um e-mail com o motivo escrito pelo administrador. Os outros administradores da organização recebem uma notificação de controlo social, para que um acionamento abusivo seja imediatamente visível pelos seus pares.
Papéis habilitados
Apenas os papéis <strong>Owner</strong> e <strong>Admin</strong> da organização em causa. Nenhum papel Member pode acionar a suspensão, mesmo por acidente. Os administradores de outra organização não têm qualquer visibilidade nem qualquer poder de ação sobre a organização impactada.
Justificação escrita obrigatória
Quem aciona deve introduzir um motivo detalhado num campo de texto livre. Não existe qualquer opção « sem motivo ». O motivo é inscrito verbatim na cadeia de auditoria HMAC e reproduzido nos e-mails de notificação enviados aos utilizadores em causa.
Confirmação em duas etapas
A janela modal de confirmação obriga a reescrever o nome da organização, segundo o padrão GitHub « type the repo name to delete ». Esta fricção deliberada evita qualquer acionamento acidental por clique reflexo.
Reautenticação MFA
Antes da aplicação, o administrador deve reintroduzir a sua palavra-passe e validar uma etapa MFA (TOTP, WebAuthn ou e-mail de backup). Um cookie de sessão roubado não basta para acionar a suspensão.
Cada acionamento produz uma entrada tipada <code>org_membership_suspended_emergency</code> na cadeia de auditoria HMAC-SHA-256. A entrada contém o identificador da organização, o identificador do administrador autor, o motivo escrito, a lista dos utilizadores afetados (por identificador e hash SHA-256 do e-mail), o contador de membros impactados e o carimbo temporal. A cadeia é verificável por linha de comando pública segundo o mecanismo descrito na <a href="{link}">página audit chain HMAC</a>.
O nível 2 responde às situações em que o comprometimento ultrapassa o perímetro de uma organização: posto de utilizador infetado por malware, computador roubado sem cifragem completa do disco, suspeita de presença persistente de um atacante. A ação é voluntariamente mais alargada e mais destrutiva. Só deve ser acionada como último recurso.
Todas as sessões web ativas dos membros são terminadas no servidor. Os cofres locais dos utilizadores em causa são novamente bloqueados no próximo refresh de separador. A função « lembrar-me » é revogada. Os utilizadores são obrigados a reautenticar-se integralmente, incluindo a partir das suas outras organizações.
Quando o próprio posto do utilizador é suspeito, o comprometimento já não se limita a uma organização: o atacante tem provavelmente acesso a todas as organizações às quais o utilizador pertence. Uma suspensão cirúrgica seria insuficiente. O efeito cross-org é assumido e documentado.
Roubo físico de um dispositivo sem cifragem de ecrã, malware identificado no posto de um colaborador-chave, sinal forte de um endpoint EDR, suspeita forte de presença de um atacante interno com acesso ao posto. Para as suspeitas mais circunscritas, o nível 1 continua a ser a boa escolha.
Os três limites de segurança do nível 1 aplicam-se de forma idêntica ao nível 2: motivo de texto obrigatório, cópia do nome da organização para confirmar, reautenticação por palavra-passe e MFA do administrador. A fricção é voluntária, proporcional ao impacto.
O acionamento produz uma entrada <code>org_security_emergency_lockout</code> na cadeia HMAC, contendo a contagem das sessões terminadas por utilizador. Para além de três acionamentos sobre a mesma organização em menos de uma hora, um alerta interno é enviado à equipa de suporte ARDNTECH e um e-mail é enviado ao contacto de faturação da organização, para que um abuso de administrador seja detetado rapidamente. Nenhum bloqueio automático: uma verdadeira emergência pode exigir vários acionamentos consecutivos.
Um separador já aberto na aplicação no momento do lockout pode conservar metadados em cache até ao seu auto-lock ou ao seu refrescamento. A sessão web é terminada, pelo que qualquer fetch posterior força um re-login. Esta limitação está documentada nas notas de arquitetura e será tratada por WebSocket push na V2. O cofre desbloqueado em memória num SharedWorker existente segue o mesmo ciclo de vida: bloqueia-se novamente no próximo refrescamento de separador.
A página de segurança operacional articula-se com o plano de resposta global já publicado no threat model. A tabela abaixo recapitula os três níveis padrão, do cirúrgico à comunicação externa.
| Nível | Acionador | Ação |
|---|---|---|
| <span class="m-tag m-tag--info">L1</span> Suspensão cirúrgica | Suspeita dirigida a uma organização: conta de utilizador comprometida, sinalização RH, anomalia no audit log. | Bloqueio do acesso aos segredos e folders da organização para todos os seus membros. Nenhum impacto cross-org. Reversível por um botão dedicado. |
| <span class="m-tag m-tag--warning">L2</span> Lockout de emergência | Comprometimento de posto de utilizador, roubo de dispositivo, suspeita forte de atacante interno com acesso ao posto. | Invalidação de todas as sessões web, novo bloqueio dos cofres, revogação do « remember me ». Impacto cross-org assumido. |
| <span class="m-tag m-tag--danger">L3</span> Comunicação externa | Comprometimento técnico confirmado pela investigação interna ou externa com exposição de dados pessoais. | Notificação CNIL e ANSSI em 72 horas (RGPD Art. 33), relatório de transparência publicado, auditoria forense externa mandatada. |
Os níveis L1 e L2 estão equipados in-app no painel de definições da organização. O nível L3 decorre de um procedimento organizacional pilotado conjuntamente pelo DPO e pelo editor, acionado por decisão escrita e rastreado na cadeia de auditoria (<code>incident_l3_external_notification</code>).
A ARDNTECH compromete-se com um plano de resposta alinhado com as obrigações RGPD para os incidentes que envolvam dados pessoais. O plano está alinhado com a postura pública do threat model e com a política de privacidade.
Em caso de incidente L3 que afete dados pessoais, a ARDNTECH notifica a CNIL no prazo previsto no artigo 33 do RGPD. A notificação inclui a natureza da violação, as categorias de pessoas em causa, as consequências prováveis e as medidas tomadas. Os responsáveis pelo tratamento clientes são informados em paralelo a fim de poderem satisfazer as suas próprias obrigações.
Cada incidente L3 é objeto de um relatório de transparência publicado no site, após acordo das autoridades e anonimização. Este relatório detalha a cronologia, as causas técnicas, as medidas corretivas implementadas e as lições retiradas. A transparência é um compromisso duradouro, não uma opção comercial.
Em caso de incidente L3, uma auditoria forense independente é mandatada junto de um prestador PASSI referenciado pela ANSSI ou de um gabinete equivalente. O relatório sintético é partilhado com os clientes Business e Enterprise sob NDA, e um resumo público anonimizado é integrado no relatório de transparência.
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.
