Journalisation et surveillance insuffisantes

Qu'est-ce que Journalisation et surveillance insuffisantes?

Il s’agit d’un échec de détection plutôt que d’un échec d’accès. Lorsqu'une demande est autorisée, aucun contrôle d'accès ne la rejettera, la piste d'audit est donc la seule chose qui détecte les abus. Vous utiliserez un jeton d'agent d'assistance valide pour lire la date de naissance, la carte d'identité nationale et les soldes des comptes d'un client sans aucun ticket derrière la demande. Ensuite, on vous demande quel agent a lu cet enregistrement, et vous ne pouvez pas le dire. Le correctif enregistre l'acteur, le sujet, l'action, le ticket, l'adresse IP source et l'horodatage dans un récepteur d'ajout uniquement, et alerte en cas de lecture sans ticket.

Ce que vous apprendrez dans Journalisation et surveillance insuffisantes

• Reconnaître une journalisation et une surveillance insuffisantes comme un échec de détection : les accès sensibles ne sont pas enregistrés avec suffisamment de contexte, ou ne sont pas surveillés, de sorte que les utilisations abusives restent invisibles et ne peuvent pas être reconstruites.
• Comprendre qu'un accès autorisé (un identifiant valide utilisé de manière abusive) ne peut être détecté que par une piste d'audit et des alertes, puisqu'aucun contrôle d'accès ne le rejettera
• Distinguez-le des failles de contrôle d’accès, d’exposition des données et de limitation de débit ; ici, une seule lecture autorisée est autorisée et le contrôle manquant est l'attribution et la visibilité, pas un bloc ou un plafond
• Appliquez le correctif : émettez un événement d'audit immuable (acteur, sujet, action, ticket ou raison, adresse IP source, horodatage) vers un récepteur d'ajout uniquement et alertez en cas d'accès suspect tel qu'une lecture sensible sans ticket
• Comprenez que la solution réside dans la détection et la responsabilisation, et non dans la prévention : une lecture légitime reste autorisée et renvoie toujours 200, tandis que son abus devient attribuable et alertable.

Journalisation et surveillance insuffisantes — Étapes de la formation

1. Un agent avec accès

   Norvane est une banque numérique. Ses agents d'assistance recherchent toute la journée les comptes clients pour gérer les tickets, à l'aide d'une console interne soutenue par l'API client. Bob est l'un de ces agents et il vend ce qu'il peut atteindre. Un réseau de fraudeurs l'a payé pour une identité complète, il a donc choisi un client Norvane avec un solde important, quelqu'un pour qui il n'a aucun ticket et aucune raison de toucher. Son accès est réel et son jeton est valide, donc rien de ce qu'il est sur le point de faire ne sera rejeté. Il ouvre la console de l'agent pour extraire son dossier.

2. Le point de terminaison de la recherche

   La recherche de client renvoie un profil complet et le jeton d'agent de Bob est autorisé à l'appeler. Les recherches sont destinées à référencer le ticket sur lequel l'agent travaille, mais l'API elle-même n'en nécessite pas.

3. Tirez le disque

   Bob appelle le point de terminaison de recherche pour le client pour lequel il a été payé, portant son jeton d'agent et aucun ticket. Il s’agit d’une simple demande d’apparence ordinaire, le même appel qu’il passe des dizaines de fois par jour pour obtenir de vrais billets, c’est exactement pourquoi elle ne se démarquera pas.

4. Toute la vie d'une personne

   Le jeton fonctionne. Le serveur a renvoyé le dossier complet du client.

5. Contrôle des connaissances

   Vous venez de voir un agent d'assistance extraire l'identité complète d'un client avec un jeton valide et aucun ticket. Verrouillez de quel type d’échec il s’agit.

6. Quel agent a lu ça ?

   Vous possédez la journalisation d'audit et la surveillance de l'API client de Norvane. L'identité d'un client a été volée et utilisée à des fins frauduleuses, et les détails ne peuvent provenir que de Norvane. Trust & Safety vous a envoyé un e-mail avec une question à laquelle il ne peut pas répondre seul.

7. Lire le journal des candidatures

   Avant de toucher au code, vous vérifiez ce que l'API a réellement enregistré. Suivez le journal des applications et recherchez tout ce qui lie une recherche à un agent ou au client dont les données ont été divulguées.

8. Pas moyen de répondre

   C'est tout ce que l'API a enregistré à propos de ces recherches.

9. Ouvrez le gestionnaire de recherche

   Ouvrez le gestionnaire de recherche de client et regardez ce qu'il enregistre lorsqu'il répond à une demande.

10. Repérez le défaut

    Le gestionnaire vérifie le jeton de l'agent, lit le client et renvoie le profil complet. La seule ligne qu'il enregistre est la ligne que vous venez de voir : une note indiquant qu'une recherche a eu lieu, sans aucun contexte qui en ferait un enregistrement d'audit.