Unzureichendes Logging und Monitoring

Was ist Unzureichendes Logging und Monitoring?

Hierbei handelt es sich eher um einen Erkennungsfehler als um einen Zugriffsfehler. Wenn eine Anfrage autorisiert ist, wird sie von keiner Zugriffskontrolle abgelehnt, sodass nur der Audit-Trail einen Missbrauch erkennen kann. Sie verwenden ein gültiges Support-Agent-Token, um das Geburtsdatum, den Personalausweis und den Kontostand eines Kunden abzulesen, ohne dass hinter der Anfrage ein Ticket steht. Dann werden Sie gefragt, welcher Agent diesen Datensatz gelesen hat, können es aber nicht sagen. Der Fix protokolliert Akteur, Betreff, Aktion, Ticket, Quell-IP und Zeitstempel in einer Nur-Anhänge-Senke und warnt bei einem Lesevorgang ohne Ticket.

Was Sie lernen in Unzureichendes Logging und Monitoring

• Unzureichendes Logging und Monitoring als Versagen der Erkennung einordnen: Sensible Zugriffe werden nicht mit genug Kontext aufgezeichnet oder nicht überwacht, sodass Missbrauch unbemerkt bleibt und sich nicht rekonstruieren lässt
• Verstehen, dass sich ein autorisierter Zugriff — also missbräuchlich genutzte, gültige Zugangsdaten — nur über einen Audit-Trail und Alarmierung auffangen lässt, weil ihn keine Zugriffskontrolle abweist
• Die Schwachstelle von Fehlern in Zugriffskontrolle, Datenoffenlegung und Rate Limiting abgrenzen: Hier ist ein einzelner autorisierter Lesezugriff erlaubt, und es fehlen Zurechenbarkeit und Sichtbarkeit — keine Sperre und keine Obergrenze
• Die Lösung anwenden: ein unveränderliches Audit-Event (Akteur, betroffener Datensatz, Aktion, Ticket oder Anlass, Quell-IP, Zeitstempel) in einen Append-only-Speicher schreiben und bei verdächtigen Zugriffen Alarm schlagen, etwa bei einem sensiblen Lesezugriff ohne Ticket
• Verstehen, dass die Lösung Erkennung und Nachvollziehbarkeit bringt, nicht Verhinderung: Ein legitimer Lesezugriff bleibt erlaubt und liefert weiterhin 200, während sein Missbrauch zurechenbar und alarmfähig wird

Unzureichendes Logging und Monitoring — Trainingsschritte

1. Ein Mitarbeiter mit Zugriff

   Norvane ist eine Digitalbank. Ihre Support-Mitarbeiter rufen den ganzen Tag Kundenkonten ab, um Tickets zu bearbeiten — über eine interne Konsole, hinter der die Kunden-API steckt. Bob ist einer dieser Mitarbeiter, und er verkauft, woran er herankommt. Ein Betrügerring hat ihn für eine komplette Identität bezahlt, also hat er sich eine Norvane-Kundin mit hohem Kontostand herausgesucht: jemanden, für den er kein Ticket und keinerlei Anlass hat. Sein Zugriff ist echt, sein Token gültig, deshalb wird nichts von dem, was er gleich tut, abgewiesen. Er öffnet die Support-Konsole, um ihren Datensatz abzurufen.

2. Der Abfrage-Endpunkt

   Die Kundenabfrage liefert ein vollständiges Profil zurück, und Bobs Mitarbeiter-Token darf sie aufrufen. Eigentlich soll jede Abfrage auf das Ticket verweisen, das der Mitarbeiter gerade bearbeitet — die API selbst verlangt aber keines.

3. Den Datensatz abrufen

   Bob ruft den Abfrage-Endpunkt für die Kundin auf, für deren Daten er bezahlt wurde — mit seinem Mitarbeiter-Token und ohne Ticket. Eine einzelne, völlig unauffällige Anfrage, derselbe Aufruf, den er täglich dutzendfach für echte Tickets macht. Genau deshalb wird sie niemandem auffallen.

4. Das ganze Leben eines Menschen

   Das Token funktioniert. Der Server hat den vollständigen Datensatz der Kundin zurückgegeben.

5. Wissenscheck

   Sie haben gerade gesehen, wie ein Support-Mitarbeiter mit gültigem Token und ohne Ticket die komplette Identität einer Kundin abgerufen hat. Prägen Sie sich ein, um welche Art von Versagen es sich handelt.

6. Welcher Mitarbeiter hat das gelesen?

   Audit-Logging und Monitoring der Kunden-API von Norvane liegen bei Ihnen. Einer Kundin wurde die Identität gestohlen und für Betrug missbraucht, und die Daten dafür können nur aus Norvane selbst stammen. Trust & Safety hat Ihnen eine E-Mail mit einer Frage geschickt, die das Team allein nicht beantworten kann.

7. Das Anwendungslog lesen

   Bevor Sie Code anfassen, sehen Sie nach, was die API überhaupt aufgezeichnet hat. Lassen Sie sich das Ende des Anwendungslogs ausgeben und suchen Sie nach irgendetwas, das eine Abfrage mit einem Mitarbeiter oder mit der Kundin verknüpft, deren Daten abgeflossen sind.

8. Keine Antwort möglich

   Mehr hat die API über diese Abfragen nicht aufgezeichnet.

9. Den Abfrage-Handler öffnen

   Öffnen Sie den Handler für die Kundenabfrage und sehen Sie sich an, was er aufzeichnet, wenn er eine Anfrage beantwortet.

10. Die Schwachstelle finden

    Der Handler prüft das Mitarbeiter-Token, liest den Kundendatensatz und gibt das vollständige Profil zurück. Die einzige Zeile, die er dabei ins Log schreibt, ist genau die, die Sie gerade gesehen haben: der Hinweis, dass eine Abfrage stattgefunden hat — ohne jeden Kontext, der daraus einen Audit-Eintrag machen würde.