Serviço MFA fora do ar: decida o acesso VPN antes da falha

O acesso VPN para, e o alerta diz que o serviço de segundo fator está inacessível. Se alguém ainda consegue conectar é uma questão de política que deveria ter sido respondida antes da interrupção, não durante. Um verificador indisponível não é prova de que um fator passou, e um desafio rejeitado não é o mesmo evento que um inacessível. O runbook abaixo transforma essa distinção numa regra escrita que você pode testar.

Passo 1: nomeie os três resultados separadamente

Escreva três estados e recuse fundi-los: a autenticação primária falhou, o desafio do segundo fator foi negado ou expirou, e o serviço MFA nunca respondeu. Cada um tem um proprietário diferente, uma linha de log diferente e uma resposta correta diferente. Uma única mensagem genérica de tempo esgotado esconde em qual você está, e é essa ambiguidade que transforma uma interrupção em discussão. Nomeie os estados no runbook antes de precisar deles.

Uma negação significa que o verificador respondeu e disse não, o que é um resultado de política e não um problema de disponibilidade. Uma tentativa expirada significa que o desafio existia e ninguém o concluiu a tempo. Um serviço inacessível significa que a pergunta nunca foi respondida. Apenas o terceiro é uma interrupção.

Passo 2: leia o modo de falha que o proxy realmente usa

Encontre a configuração que governa o comportamento quando o serviço não pode ser contactado e leia-a a partir da configuração em execução, não de um modelo. No proxy RADIUS da Duo, os valores documentados de failmode são safe e secure, com safe permitindo uma tentativa apenas quando a autenticação primária tem êxito e secure rejeitando a tentativa nessa condição.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

O nome safe descreve uma escolha de disponibilidade, não uma garantia de que cada sessão admitida teve um segundo fator recente. Essa frase pertence ao registro de riscos, porque é exatamente a troca que a configuração faz. Não generalize o valor para outro fornecedor, outra integração ou outro modo de proxy; leia a documentação desse produto para o seu próprio equivalente. Uma configuração copiada de um exemplo de fornecedor sem esta compreensão é uma surpresa à espera da próxima interrupção.

Pare se ninguém consegue dizer qual modo está ativo. O resto do runbook depende dessa resposta.

Passo 3: faça as novas tentativas corresponderem ao fluxo

Alinhe o tempo limite e o comportamento de nova tentativa do gateway com o fluxo de autenticação que ele conduz. Novas tentativas não coordenadas criam vários pedidos, confundem o emparelhamento de tentativas e deixam o log incapaz de dizer qual resultado pertence a qual início de sessão. Um tempo limite muito longo não é um desenho de disponibilidade; é uma espera mais longa pela mesma resposta.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

O tempo limite próprio do pedido no proxy é um limite separado: um pedido de autenticação emitido e nunca concluído é rejeitado, e essa rejeição não é uma interrupção da qual se recua. Trate uma negação, um desafio inacabado e um serviço inacessível como três entradas diferentes na sua tabela de decisão. Depois torne a tabela explícita: que estado admite, que estado retém e que estado escala para uma pessoa.

Se dois componentes ambos repetem, corrija primeiro a propriedade das novas tentativas. Pedidos duplicados são sintoma de dois proprietários, não de um serviço lento.

Passo 4: governe o acesso de emergência em separado

Se for necessário acesso de emergência, dê-lhe o seu próprio âmbito, identidade, autorização e rasto de auditoria. Desativar MFA em silêncio para todos os utilizadores não é um procedimento de emergência; é um enfraquecimento permanente com um incidente anexado. O proprietário de segurança aprova antecipadamente a regra de admissão, a visibilidade e o caminho de escalada.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Teste toda a matriz num ambiente que não seja de produção: falha primária, rejeição deliberada, expiração do desafio e indisponibilidade do serviço. Para cada um, registe o resultado de admissão e o motivo que ficou registado. Não crie uma interrupção de produção para descobrir o comportamento configurado, e não teste o caminho de emergência pela primeira vez durante o incidente para o qual foi escrito. Um procedimento de recuperação que nunca foi executado é um documento, não um controlo.

O runbook termina quando os três estados estão nomeados, o modo de falha foi lido do sistema em execução, as novas tentativas têm um único proprietário e o acesso de emergência tem a sua própria aprovação e revisão. A aplicação previsível mais um caminho de recuperação conhecido é o resultado que vale a pena documentar.