Acessos de emergência: controlar sem bloquear a operação

Cibersegurança · 2 min

As contas de emergência ajudam a recuperar serviços, mas também podem criar riscos sérios. Saiba como governar acessos *break-glass* com controlo e rastreabilidade.

Acessos de emergência: controlar sem bloquear a operação

TL;DR

Acesso de emergência deve ser exceção, não atalho operacional.
Contas break-glass precisam de dono, âmbito, autenticação e registo.
O risco aumenta quando contas privilegiadas ficam permanentes e pouco monitorizadas.
Testes periódicos ajudam a confirmar que o acesso funciona quando necessário.
A revisão pós-utilização é tão importante como a autorização inicial.

A pergunta certa não é se deve existir acesso de emergência

Em ambientes empresariais, há cenários em que o acesso normal pode falhar: indisponibilidade do fornecedor de identidade, erro de configuração, perda de conectividade, incidente de segurança ou falha numa integração crítica. Nesses momentos, uma conta de emergência, muitas vezes designada por break-glass, pode permitir recuperar controlo. A pergunta relevante não é se estas contas devem existir, mas como evitar que se transformem numa porta privilegiada permanente, pouco vigiada e fora dos processos normais de governação.

O risco está no privilégio sem contexto

Uma conta de emergência concentra normalmente permissões elevadas e mecanismos de autenticação independentes dos fluxos habituais. Isso é útil quando o sistema de identidade está indisponível, mas também cria exposição se a conta for partilhada, reutilizada ou esquecida. A gestão deve começar por definir finalidade, âmbito técnico, sistemas abrangidos, responsáveis pela custódia e condições de utilização. Esta disciplina complementa práticas de deteção de risco em identidade, como as abordadas em [ITDR e riscos de identidade](/pt/blog/itdr-detetar-riscos-de-identidade-antes-do-incidente).

Separar acesso de rotina de acesso excecional

O erro mais comum é usar contas de emergência para tarefas administrativas frequentes. Quando isso acontece, deixa de existir distinção entre operação normal e exceção. Uma boa prática é manter os acessos quotidianos sujeitos a funções, aprovação, autenticação forte e rastreabilidade, reservando o mecanismo break-glass para situações documentadas. Em arquiteturas de acesso moderno, esta separação deve coexistir com princípios de [Zero Trust e ZTNA](/pt/solucoes/zero-trust-ztna), sem assumir que a emergência justifica ausência de controlo.

Definir custódia, autenticação e registo

Cada conta de emergência deve ter um proprietário funcional e técnico. As credenciais devem ser guardadas de forma controlada, com acesso limitado e processo de acesso documentado. As contas de emergência devem utilizar mecanismos de autenticação forte adequados ao cenário de contingência, evitando dependências que possam impedir o acesso durante uma falha. Devem ainda existir alertas automáticos e registo detalhado da sua utilização. Se a conta tiver de contornar dependências específicas, essa exceção deve ser explícita e justificada. A integração com práticas de [gestão de infraestrutura](/pt/servicos/gestao-infraestrutura) ajuda a manter inventário, responsabilidades e procedimentos alinhados.

Testar sem banalizar

Uma conta que nunca é testada pode falhar precisamente quando for necessária. Mas testes demasiado frequentes ou mal enquadrados podem normalizar o uso de privilégios elevados. O equilíbrio passa por exercícios periódicos, com janela definida, aprovação prévia, objetivos claros e validação de evidências. O teste deve confirmar que a credencial está acessível, que o acesso funciona, que os alertas disparam e que a atividade fica registada. Se algum destes pontos falhar, o processo precisa de correção antes de ser considerado fiável.

Rever depois de cada utilização

O momento pós-utilização é decisivo. Deve confirmar-se quem acedeu, porquê, durante quanto tempo, que alterações foram feitas e se as credenciais precisam de rotação. Quando a utilização ocorreu durante um incidente, a revisão deve ligar-se aos procedimentos de resposta e aos respetivos [runbooks operacionais](/pt/blog/runbooks-automatizacao-resposta-incidentes). O objetivo não é burocratizar a recuperação, mas garantir que a exceção foi necessária, proporcional e auditável. Acesso de emergência bem governado reduz improviso sem eliminar a responsabilidade.