Por que uma saída VPN compartilhada dispara avisos de login que você não causou
Um bloqueio de login costuma ser uma pontuação de risco, não um veredito sobre o seu túnel. Saídas compartilhadas mudam quem mais entra nessa pontuação e quanto isso lhes custa.
Abra um site conhecido por meio de uma VPN e receba um desafio extra, e a explicação tentadora é que o túnel foi detectado. Algo foi detectado, mas não era você. O site pontuou um conjunto de sinais, um dos quais é o endereço de origem, e esse endereço é compartilhado com estranhos que talvez estivessem gerando logins falhos um minuto antes. Ler a decisão como um veredito sobre a sua conexão interpreta mal para que serve a pontuação.
O que um endereço de origem pode e não pode resolver
Um endereço IP descreve um caminho pela rede em um determinado momento. Ele não identifica uma pessoa, um dispositivo nem mesmo uma única conta, e com NAT de operadora ou um pool de VPN movimentado pode representar milhares de sessões não relacionadas ao mesmo tempo. Um site que trata o endereço como identidade na verdade o trata como reputação, o que é uma afirmação estatística e não um fato.
Duas pessoas podem compartilhar uma saída e produzir evidências opostas: uma entra com sucesso com um segundo fator, a outra tenta quarenta senhas. O endereço é idêntico, então nenhuma regra baseada apenas no endereço pode distingui-las, e qualquer resposta acionada vale para ambas.
Isso não é um argumento para ignorar endereços. É um argumento para lembrar o que o sinal mede, porque a maior parte do comportamento surpreendente em torno de logins por VPN vem de aplicar um controle na granularidade errada, e não de uma observação errada.
Por que bloquear a saída pune estranhos
Um bloqueio no nível do endereço é barato de implementar e caro de mirar. Seu raio de ação é cada sessão por trás daquele endereço, e é por isso que o comportamento de endereços compartilhados e do NAT tem sua própria história na documentação operacional: o mesmo raciocínio aparece no trabalho da IETF sobre endereços de origem compartilhados e os efeitos colaterais da filtragem baseada em endereço.
| Signal | What it provides evidence about | What it cannot settle |
|---|---|---|
| Source address and its reputation | The network path, and how that path behaved recently for others | Which account or person is behind the request |
| Authenticator result | Whether the account claim was proved at the required strength | Whether the account's owner initiated it |
| Request timing and volume | Whether the pattern looks automated or burst-like | Whether the intent was malicious or a shared client |
| Application event history | What this account has done while signed in | Anything about requests that never authenticated |
Considere as duas falhas que um bloqueio cria. Um cliente legítimo atrás da mesma saída tem o serviço negado e abre um ticket de suporte que custa mais do que o abuso. Um atacante real se muda para a próxima saída em um pool de milhares e continua, sem ter gasto nada além de uma reconexão.
A proporcionalidade é o passo que falta. Logins falhos repetidos, uma rajada de solicitações automatizadas e uma violação de permissão autenticada são três eventos diferentes, e só o segundo é plausivelmente um problema com forma de endereço. Aplicar a mesma proibição de rede para todo o site aos três é como um controle de segurança se torna uma fila de suporte.
Coloque a decisão onde está a evidência
Controles no nível da conta seguem a conta pelos endereços, o que corresponde à entidade com que você realmente se importa. A limitação de taxa, os períodos de espera após falhas repetidas e a autenticação escalonada para ações sensíveis operam todos sobre a conta ou a ação, não sobre o caminho de rede. Isso se encaixa melhor na entidade que você realmente protege. Também remove o incentivo do atacante de procurar um endereço de saída novo.
As diretrizes de autenticação do NIST tratam esses itens como entradas de uma avaliação de risco e listam endereço, geolocalização e horário da solicitação entre os sinais, que é exatamente o quadro a tomar emprestado: um sinal informa uma decisão, não substitui um autenticador. Leia essa lista como entradas, não como um menu de coisas a proibir. O autenticador continua fazendo a prova, e os outros sinais só decidem quanta fricção colocar ao redor dele.
Duas restrições de projeto impedem que a abordagem no nível da conta se torne sua própria queda. Os limites de taxa precisam de um caminho de revisão seguro para que um usuário possa relatar uma classificação errada sem publicar credenciais, e os desafios escalonados não devem poder ser respondidos com uma senha ou um código de uso único entregue a um contato de suporte não verificado.
Como uma política justa se parece por fora
Anote qual decisão cada controle apoia e depois verifique se a granularidade do controle corresponde. Controles de endereço respondem a perguntas sobre tráfego de uma rede; controles de conta respondem a perguntas sobre uma conta; eventos de aplicação respondem a perguntas sobre comportamento após a autenticação. Uma política que nomeia os três é auditável, e uma que nomeia apenas tráfego VPN não é.
Depois meça o resultado em vez do número de regras. As tentativas não autorizadas devem cair, os usuários legítimos devem manter um caminho suportado, e o número de contatos de suporte por mil logins não deve subir. Um bloqueio que melhora o primeiro número enquanto arruína os outros dois moveu o problema, não o resolveu.
Aceitar conexões VPN e aplicar controles de abuso são objetivos compatíveis. A versão que funciona trata o endereço de origem como uma entrada entre várias, aplica o controle mais estreito que se ajusta às evidências e deixa um caminho honesto para a pessoa classificada incorretamente. A versão que falha trata um endereço como suspeito e chama isso de política.