Alertas de login VPN: qual evento deveria realmente acioná-los?
O sucesso da autenticação, um túnel estabelecido e um RADIUS accounting Start são três afirmações diferentes. Escolha a que o destinatário pode atender e depois correlacione.
O sucesso da autenticação, um túnel estabelecido e um RADIUS accounting Start são três afirmações diferentes, e um e-mail de login só significa algo quando você escolhe uma delas. A maioria dos projetos de alertas de VPN mistura as três e produz uma caixa de entrada em que ninguém confia. A decisão depende de quem lê o alerta e do que essa pessoa pode fazer nos próximos cinco minutos. Se errar isso, o alerta vira ruído que esconde o único evento de que você precisava.
Três perguntas decidem o gatilho
Pergunte quem o recebe, o que fará e com que rapidez a ação precisa acontecer. Uma equipe de segurança que monitora o uso indevido de credenciais quer um padrão de falha e depois sucesso de uma conta em poucos minutos. Uma equipe de operações que monitora capacidade quer duração de sessão e motivos de desconexão, não logins. Um helpdesk quer a identidade da sessão para casá-la com um ticket.
Essas respostas apontam para eventos diferentes, e nenhuma regra única satisfaz as três. Se a ação do destinatário for «ligue para o usuário», a autenticação basta. Se a ação for «libere uma licença» ou «verifique se o túnel transportou tráfego», só o estabelecimento ou o accounting Start serve. Se a ação for «fature o tempo», você precisa de registros Stop em vez de um login.
Escreva a resposta em uma única frase antes de configurar qualquer coisa. «Este e-mail informa o engenheiro de plantão que a conta X abriu um túnel a partir da rede Y no momento Z, para que ele possa verificar se a janela de manutenção foi usada.» Se não conseguir preencher cada campo, o gatilho ainda não foi escolhido.
Combine o evento com a afirmação que você faz
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
A tabela esconde uma dependência: cada linha só é confiável se o gateway a emitir de forma confiável e o seu coletor mantiver o campo de que você precisa. Leia a definição do evento para a versão exata que você executa, porque o nome «sessão estabelecida» muda entre versões e o significado muda com mais frequência que o nome. Quando uma definição é vaga, peça uma captura de sessão em vez de adivinhar pelo rótulo.
Tratar um Access-Accept como a conclusão de tudo que vem depois é o erro mais comum. É um veredicto sobre credenciais, não uma sessão. O erro espelho é ler uma correspondência de política como prova de autorização, quando uma regra pode corresponder e o passo seguinte ainda pode falhar.
Uma sessão, uma notificação
Uma conta, vários dispositivos, reenvios e reconexões: um e-mail por evento estará errado nas duas direções, duplicando uma sessão enquanto divide outra. Chaveie a notificação no gateway mais um identificador de sessão, e trate o nome da conta como atributo em vez de chave. Um usuário com notebook e telefone pode manter dois túneis ao mesmo tempo, e ambos merecem a própria linha.
Os registros contábeis reenviados são normais, então desduplique pelo id de sessão e pelo carimbo de data e hora antes de renderizar a mensagem. Sessões consecutivas do mesmo dispositivo devem permanecer separadas, e uma reconexão durante uma janela de manutenção deve continuar visível em vez de colapsar na anterior. Se o seu coletor reescreve carimbos de data e hora na ingestão, desduplique pelos campos do registro original, não pelos armazenados.
Um registro Stop ausente é incerteza, não uma sessão permanente. Reinicializações do gateway, quedas do coletor e perda de UDP deixam lacunas, então o alerta precisa de um caminho de reconciliação que consulte a tabela de sessões ativas antes que alguém conclua que um túnel ainda está de pé.
Mantenha auditoria e notificação separadas
O fluxo de auditoria e o fluxo de alertas têm funções diferentes. Preserve os registros brutos, incluindo conta, gateway, id de sessão, carimbos de data e hora e motivo de encerramento, mesmo quando os e-mails de rotina são agrupados, suprimidos ou enviados a uma pequena lista de plantão. Um limite de severidade é um filtro de entrega, não uma seleção do evento do ciclo de vida que você queria anunciar.
Envie o contexto mínimo de que o destinatário precisa para encontrar o registro protegido. Nomes de conta, endereços internos e detalhes de sessão são sensíveis, e um e-mail que se encaminha bem é um e-mail que vaza bem.
Depois prove isso de ponta a ponta. Execute um login e logout normais, uma reconexão, duas sessões simultâneas e uma falha de entrega forçada, e rastreie um evento do gateway pelo coletor até a mensagem entregue. Se o e-mail chegar sem um id de sessão, o contrato está incompleto. Se dois e-mails descrevem uma sessão, a correlação está quebrada. Nenhum dos dois problemas aparece quando a única coisa que você testa é que a entrega de correio funciona.