Ajout d'un journal d'authentification central à Discourse

[supermathie (Michael Brown)]

Résumé

Nous devrions ajouter un système de journalisation d’authentification standardisé à Discourse qui stocke les événements d’authentification de toutes les méthodes d’authentification activées pour l’analyse et le dépannage.

Détails

Nous fournirons un fournisseur de journalisation d’authentification auquel chaque système d’authentification se connectera et enverra des événements.

À titre d’exemple, le fournisseur de connexion locale pourrait avoir la liste d’événements suivante (non exhaustive) :

• quelqu’un de [IP] a échoué à la connexion en tant qu’utilisateur fhqwhgads qui n’existe pas
• quelqu’un de [IP] a échoué à la connexion en tant qu’utilisateur supermathie, a été limité en débit
• quelqu’un de [IP] a échoué à la connexion en tant qu’utilisateur supermathie, mais a fourni un mot de passe invalide
• quelqu’un de [IP] s’est connecté avec succès en tant qu’utilisateur supermathie, a fourni un mot de passe valide
• quelqu’un de [IP] a échoué à la connexion en tant qu’utilisateur supermathie, a fourni un mot de passe valide, mais nécessite une authentification multifacteur (MFA) pour continuer
• quelqu’un de [IP] a échoué à la connexion en tant qu’utilisateur supermathie, a fourni un mot de passe valide, a fourni un code TOTP invalide
• quelqu’un de [IP] s’est connecté avec succès en tant qu’utilisateur supermathie, a fourni un mot de passe valide, a fourni un code TOTP valide pour le jeton vault-work

Le problème avec la dépendance aux journaux existants (journaux Web) est qu’à l’exception de celui limité en débit, ils ont tous l’air exactement pareils ([200] POST /session HTTP/1.1). Il n’y a pas de sens qui parvient au journal.

Préoccupations

Il y a une préoccupation concernant les événements anonymes générant des entrées de journal et l’équilibre entre cela et la détection d’événements intéressants du point de vue de l’analyse SIEM, par exemple les attaques par pulvérisation de mots de passe.

Journaliser TOUT signifie que n’importe qui sur Internet peut remplir vos journaux… mais il est discutable de savoir si c’est réellement un problème ou non. Notez la rétention ci-dessous - peut-être que les échecs sont conservés pendant une période plus courte dans le journal de l’application.

Une question similaire se pose concernant les journaux basés sur des jetons à usage unique, par exemple la connexion par e-mail. Les jetons incorrects ne sont probablement pas “intéressants” à enregistrer, mais les jetons rejoués le sont absolument, à la fois du point de vue du SIEM et du support utilisateur.

Questions

Rétention : tout garder pour toujours ? 30 jours ? 90 jours ? effacer les événements anonymes plus tôt ?

Authentification par clé API : les appels avec des clés API utilisateur ou administrateur incorrectes doivent-ils être enregistrés ici ? Probablement - cela aidera au débogage.

Quelle part devrait être configurable ? par exemple, activer les journaux de débogage pour tout ou juste un fournisseur ?

Considérations d’implémentation

L’implémentation doit être suffisamment flexible pour permettre l’ajout d’un autre fournisseur de stockage d’événements au pipeline de journalisation. Un exemple d’un tel fournisseur pourrait être un fichier journal brut, une file d’attente de messages ou un compartiment S3. Les détails exacts d’un tel fournisseur sont hors de portée de ce sujet, mais l’implémentation doit être suffisamment flexible pour qu’un plugin puisse s’enregistrer pour recevoir les journaux tels qu’ils sont générés.

Contexte

Un client nous a demandé cela dans le but d’alimenter les événements dans son SIEM et nous avons réalisé qu’il s’agissait d’une lacune fonctionnelle dans Discourse.

Lors de discussions internes, nous avons également découvert que ces informations seraient utiles aux administrateurs de site et à nos propres défenseurs de support, car les journaux d’authentification peuvent se trouver à divers endroits et il faut savoir où chercher pour les trouver. Cela repose sur des connaissances personnelles et un journal central allégerait grandement ce fardeau.

Un moyen pratique de visualiser ces journaux depuis la console Rails serait bénéfique pour nous et les administrateurs de site.