Login-Aktivität

Die Seite Login-Aktivität beantwortet zwei Fragen: Wie viele Daten bekommt jeder Login geliefert — und ist das für diesen Login zu dieser Stunde der Woche ungewöhnlich?

Sie existiert vor allem als Signal für Datenabfluss. Ein Auswertungskonto, das dienstags um 09:00 zwei Millionen Zeilen zieht, macht seine Arbeit; dasselbe Konto sonntags um 03:00 nicht. Kein absoluter Grenzwert kann diese beiden Fälle trennen — deshalb ist die Baseline nach Wochentag und Stunde gegliedert und nicht eine einzelne Zahl.

Was gemessen wird

Alle paar Minuten liest der Monitor sys.dm_exec_sessions und aggregiert je Login:

  • Gelieferte Zeilen — die Leitgröße. Das Nächste, was SQL Server zu „wie viele Daten hat dieser Login mitgenommen" anbietet.
  • Logische Lesevorgänge und CPU — ergänzende Mengenangaben.
  • Sessions und aktive Anfragen.
  • Host und Clientprogramm — ein Login, der von einer nie zuvor genutzten Maschine kommt, ist einer der stärkeren Hinweise und oft aussagekräftiger als die Menge selbst.

Warum die Zahlen eine Untergrenze sind, kein exakter Wert

Die Zähler dieser DMV laufen über die gesamte Lebensdauer einer Session aufwärts, und bei Connection Pooling bleibt eine Session wochenlang offen. Der Monitor speichert deshalb die Differenz zwischen zwei aufeinanderfolgenden Messungen, je Session.

Die Folge ist bewusst in Kauf genommen: Was eine Session zwischen der letzten Messung und ihrem Ende getan hat, wird nicht gezählt. Die Werte bedeuten also „mindestens so viel". Das ist bei einem Sicherheitssignal die richtige Richtung — es kann zu wenig melden, aber es kann keinen Verkehr erfinden, den es nie gab.

Anlaufzeit

Ein Wochentag-Stunde-Bucket braucht eine Mindestzahl an Beobachtungen (standardmäßig 20), bevor überhaupt etwas daran gemessen wird — ungefähr zwei Wochen. Bis dahin meldet die Seite absichtlich nichts: Zwei Wochen Rauschen, während sich die Baselines füllen, bringt allen bei, das Feature zu ignorieren, bevor es je funktioniert hat.

Das Banner oben auf der Seite zeigt den Fortschritt. Lesen Sie es, bevor Sie eine leere Liste als Entwarnung deuten — „nichts Auffälliges" und „kann es noch nicht beurteilen" sind sehr verschiedene Aussagen.

Die Meldeschwelle

Mengen unter 50.000 Zeilen werden nie gemeldet, egal wie ungewöhnlich sie sind. Von zwei auf zwanzig Zeilen ist ein Zehn-Sigma-Ereignis und völlig belanglos; ein Detektor, der so etwas meldet, wird binnen einer Woche stummgeschaltet — mitsamt den echten Funden.

Schwelle und Mindestbeobachtungen sind unter LoginActivity in appsettings.json einstellbar.

Stufen

Stufe Bedeutung
High Fünf oder mehr Standardabweichungen über der üblichen Menge dieses Buckets, das Zehnfache bei perfekt flacher Baseline, oder ein Login, der zu dieser Stunde der Woche noch nie Zeilen gelesen hat. Löst einen Alarm aus.
Notable Drei bis fünf Standardabweichungen darüber. Wird erfasst und hier angezeigt, alarmiert standardmäßig aber nicht.

Funde lassen sich quittieren; das wird im Audit-Log festgehalten — die Prüfung eines möglichen Datenabflusses ist selbst eine Spur wert.

Was die Seite nicht kann

Sie sieht Menge und Herkunft, nicht Inhalt. Sie kann nicht sagen, welche Tabellen gelesen wurden oder was das Haus verlassen hat — dafür braucht es SQL Server Audit oder Extended Events. Ein Fund hier ist ein Grund nachzusehen, kein Beweis.

Dienstkonten sind standardmäßig ausgenommen (ExcludedLogins); ihre Lesemengen sind riesig und ohne Aussage. Tragen Sie eigene Sicherungs- oder ETL-Konten dort ein, wenn sie das Signal übertönen.

Berechtigungen

Das Lesen von sys.dm_exec_sessions erfordert VIEW SERVER STATE — ab SQL Server 2022 VIEW SERVER PERFORMANCE STATE. Fehlt sie, meldet die Seite, dass nichts gesammelt wurde, statt ein leeres Ergebnis zu zeigen.