La réussite d'authentification, un tunnel établi et un RADIUS accounting Start sont trois affirmations différentes, et un e-mail de connexion ne veut dire quelque chose qu'une fois que vous en avez choisi une. La plupart des conceptions d'alertes VPN mélangent les trois et produisent une boîte de réception à laquelle personne ne fait confiance. La décision dépend de qui lit l'alerte et de ce qu'il peut faire dans les cinq minutes qui suivent. Si vous vous trompez, l'alerte devient un bruit qui masque le seul événement dont vous aviez besoin.

Trois questions décident du déclencheur

Demandez qui la recevra, ce qu'il fera et à quelle vitesse l'action doit se produire. Une équipe de sécurité qui surveille l'usage abusif des identifiants veut un schéma d'échec puis de réussite depuis un compte en quelques minutes. Une équipe d'exploitation qui surveille la capacité veut la durée de session et les motifs de déconnexion, pas les connexions. Un service d'assistance veut l'identité de session pour pouvoir la rattacher à un ticket.

Ces réponses pointent vers des événements différents, et aucune règle unique ne satisfait les trois. Si l'action du destinataire est « appelle l'utilisateur », l'authentification suffit. Si l'action est « libère une licence » ou « vérifie que le tunnel a transporté du trafic », seul l'établissement ou l'accounting Start conviendra. Si l'action est « facture le temps », il vous faut des enregistrements Stop plutôt qu'une connexion.

Écrivez la réponse en une seule phrase avant de configurer quoi que ce soit. « Cet e-mail indique à l'ingénieur d'astreinte que le compte X a ouvert un tunnel depuis le réseau Y à l'heure Z, afin qu'il puisse vérifier si la fenêtre de maintenance a été utilisée. » Si vous ne pouvez pas remplir chaque case, le déclencheur n'est pas encore choisi.

Faites correspondre l'événement à l'affirmation que vous portez

RecordWhat it provesWhat it leaves open
Rejected credentialsThe attempt failed at the credential stepWhether it was a stale client or a real person
Access-AcceptCredentials passed for this attemptAnything about tunnel state or policy
Policy match recordA rule matched the requestWhether later steps completed
Tunnel establishedThe gateway accepted a sessionWhether traffic flowed or the user got an address
Accounting StartUser service began at the accounting layerWhether the application behind it worked
Accounting StopThat session was closed, with a reason fieldWhether the reason is meaningful on your release

Le tableau cache une dépendance : chaque ligne n'est fiable que si la passerelle l'émet de manière fiable et si votre collecteur conserve le champ dont vous avez besoin. Lisez la définition de l'événement pour la version exacte que vous exploitez, car le nom de « session établie » change entre les versions et le sens change plus souvent que le nom. Quand une définition est vague, demandez une capture de session plutôt que de deviner d'après l'étiquette.

Considérer un Access-Accept comme l'achèvement de tout ce qui suit est l'erreur la plus courante. C'est un verdict sur les identifiants, pas une session. L'erreur miroir consiste à lire une correspondance de politique comme une preuve d'autorisation, alors qu'une règle peut correspondre et que l'étape suivante peut quand même échouer.

Une session, une notification

Un compte, plusieurs appareils, des retransmissions et des reconnexions : un e-mail par événement sera faux dans les deux sens, dupliquant une session tout en en divisant une autre. Indexez la notification sur la passerelle plus un identifiant de session, et traitez le nom de compte comme un attribut plutôt que comme la clé. Un utilisateur avec un ordinateur portable et un téléphone peut détenir deux tunnels à la fois, et les deux méritent leur propre ligne.

Les enregistrements comptables retransmis sont normaux, alors dédupliquez sur l'id de session et l'horodatage avant de rendre le message. Les sessions successives du même appareil doivent rester séparées, et une reconnexion pendant une fenêtre de maintenance doit rester visible au lieu de se fondre dans la précédente. Si votre collecteur réécrit les horodatages à l'ingestion, dédupliquez sur les champs de l'enregistrement d'origine, pas sur les champs stockés.

Un enregistrement Stop manquant est une incertitude, pas une session permanente. Les redémarrages de passerelle, les pannes de collecteur et les pertes UDP laissent tous des trous, donc l'alerte a besoin d'un chemin de réconciliation qui interroge la table des sessions actives avant que quiconque conclue qu'un tunnel est toujours actif.

Gardez l'audit et la notification séparés

Le flux d'audit et le flux d'alertes ont des rôles différents. Conservez les enregistrements bruts, y compris compte, passerelle, id de session, horodatages et motif de terminaison, même lorsque les e-mails de routine sont regroupés, supprimés ou envoyés à une petite liste d'astreinte. Un seuil de gravité est un filtre de distribution, pas une sélection de l'événement de cycle de vie que vous vouliez annoncer.

Envoyez le contexte minimal dont le destinataire a besoin pour retrouver l'enregistrement protégé. Les noms de compte, les adresses internes et les détails de session sont sensibles, et un e-mail qui se transfère bien est un e-mail qui fuit bien.

Prouvez-le ensuite de bout en bout. Exécutez une connexion et une déconnexion normales, une reconnexion, deux sessions simultanées et un échec de distribution forcé, puis tracez un événement de la passerelle à travers le collecteur jusqu'au message distribué. Si l'e-mail arrive sans id de session, le contrat est incomplet. Si deux e-mails décrivent une session, la corrélation est cassée. Aucun des deux problèmes n'apparaît quand la seule chose que vous testez est que la distribution du courrier fonctionne.

Articles similaires