Avvisi di accesso VPN: quale evento dovrebbe davvero attivarli?
Il successo dell'autenticazione, un tunnel stabilito e un RADIUS accounting Start sono tre affermazioni diverse. Scegliete quella su cui il destinatario può agire, poi correlatele.
Il successo dell'autenticazione, un tunnel stabilito e un RADIUS accounting Start sono tre affermazioni diverse, e un'e-mail di accesso significa qualcosa solo quando ne scegliete una. La maggior parte dei progetti di avvisi VPN mescola tutte e tre e produce una casella di posta di cui nessuno si fida. La decisione dipende da chi legge l'avviso e da cosa può fare nei cinque minuti successivi. Se sbagliate, l'avviso diventa rumore che nasconde l'unico evento che vi serviva.
Tre domande decidono l'innesco
Chiedete chi lo riceverà, cosa farà e con quanta rapidità deve avvenire l'azione. Un team di sicurezza che sorveglia l'abuso delle credenziali vuole uno schema di fallimento e poi successo da un account nel giro di minuti. Un team operativo che sorveglia la capacità vuole la durata della sessione e i motivi di disconnessione, non gli accessi. Un helpdesk vuole l'identità della sessione per poterla abbinare a un ticket.
Queste risposte puntano a eventi diversi, e nessuna regola singola soddisfa tutte e tre. Se l'azione del destinatario è «chiama l'utente», l'autenticazione basta. Se l'azione è «libera una licenza» o «verifica che il tunnel abbia trasportato traffico», servono solo la stabilizzazione o l'accounting Start. Se l'azione è «fattura il tempo», vi servono record Stop anziché un accesso.
Scrivete la risposta in una sola frase prima di configurare qualsiasi cosa. «Questa e-mail dice all'ingegnere di turno che l'account X ha aperto un tunnel dalla rete Y all'ora Z, così può verificare se è stata usata la finestra di manutenzione.» Se non riuscite a riempire ogni casella, l'innesco non è ancora scelto.
Abbinate l'evento all'affermazione che fate
| 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 |
La tabella nasconde una dipendenza: ogni riga è affidabile solo se il gateway la emette in modo affidabile e il vostro collector conserva il campo che vi serve. Leggete la definizione dell'evento per la versione esatta che eseguite, perché il nome «sessione stabilita» cambia tra le versioni e il significato cambia più spesso del nome. Quando una definizione è vaga, chiedete una cattura di sessione invece di indovinare dall'etichetta.
Trattare un Access-Accept come il completamento di tutto ciò che segue è l'errore più comune. È un verdetto sulle credenziali, non una sessione. L'errore speculare è leggere una corrispondenza di policy come prova di autorizzazione, quando una regola può corrispondere e il passo successivo può comunque fallire.
Una sessione, una notifica
Un account, più dispositivi, ritrasmissioni e riconnessioni: un'e-mail per evento sarà sbagliata in entrambe le direzioni, duplicando una sessione mentre ne divide un'altra. Impostate la notifica sulla chiave gateway più un identificatore di sessione, e trattate il nome dell'account come attributo anziché come chiave. Un utente con portatile e telefono può tenere due tunnel contemporaneamente, ed entrambi meritano la propria riga.
I record contabili ritrasmessi sono normali, quindi deduplicate sull'id di sessione e sul timestamp prima di rendere il messaggio. Le sessioni consecutive dallo stesso dispositivo devono restare separate, e una riconnessione durante una finestra di manutenzione deve rimanere visibile invece di collassare nella precedente. Se il vostro collector riscrive i timestamp all'ingestione, deduplicate sui campi del record originale, non su quelli memorizzati.
Un record Stop mancante è incertezza, non una sessione permanente. Riavvii del gateway, interruzioni del collector e perdite UDP lasciano tutti dei vuoti, quindi l'avviso ha bisogno di un percorso di riconciliazione che interroghi la tabella delle sessioni attive prima che qualcuno concluda che un tunnel è ancora attivo.
Tenete separati audit e notifica
Il flusso di audit e il flusso di avvisi hanno compiti diversi. Conservate i record grezzi, inclusi account, gateway, id di sessione, timestamp e motivo di terminazione, anche quando le e-mail di routine vengono raggruppate, soppresse o inviate a una piccola lista di reperibilità. Una soglia di gravità è un filtro di consegna, non una selezione dell'evento del ciclo di vita che volevate annunciare.
Inviate il contesto minimo che il destinatario necessita per trovare il record protetto. I nomi degli account, gli indirizzi interni e i dettagli di sessione sono sensibili, e un'e-mail che si inoltra bene è un'e-mail che perde bene.
Poi dimostratelo da un capo all'altro. Eseguite un accesso e un'uscita normali, una riconnessione, due sessioni simultanee e un errore di consegna forzato, e tracciate un evento dal gateway attraverso il collector fino al messaggio consegnato. Se l'e-mail arriva senza id di sessione, il contratto è incompleto. Se due e-mail descrivono una sessione, la correlazione è rotta. Nessuno dei due problemi emerge quando l'unica cosa che testate è che la consegna della posta funzioni.