Bildquelle: Bildquelle: Pexels / Foto-ID 5380642 / Digitaler Sicherheitsbildschirm als Motiv für Sicherheitslogs, Zugriffsspuren und Incident-Aufklärung / https://www.pexels.com/photo/5380642/
Ein Sicherheitslog ist im Vorfall nur dann wertvoll, wenn der Betrieb es rechtzeitig findet. Der Service Desk muss keine forensische Spezialanalyse leisten. Er braucht aber einen klaren Weg von der ersten Störungsmeldung zu den Spuren, die zeigen, ob ein Login, eine Rechteänderung oder ein Cloud-Zugriff zur Lage passt.
Sicherheitslogs sind Aufzeichnungen über sicherheitsrelevante Ereignisse. Dazu gehören Anmeldungen, fehlgeschlagene Logins, Änderungen an Berechtigungen, neue Geräte, Admin-Aktionen, verdächtige Zugriffe und Meldungen aus Cloud-Diensten. Für ITSM-Generalisten ist der Kern einfach: Logs sind keine Technikablage im Hintergrund, sondern ein Betriebsnachweis im Ernstfall.
Der Unterschied wird sichtbar, sobald eine Störung nicht eindeutig technisch wirkt. Ein Nutzer meldet gesperrte Konten. Ein Fachbereich sieht ungewöhnliche Änderungen. Ein Cloud-Dienst verhält sich anders als erwartet. Dann reicht die Frage „läuft das System?“ nicht mehr. Der Betrieb muss klären, ob ein Sicherheitsereignis beteiligt sein könnte und welche Spuren diese Entscheidung stützen.
Der Service Desk braucht einen Suchweg, keine Rohdatenflut
Ein Service Desk sollte nicht alle Logs selbst lesen müssen. Das wäre fachlich falsch und praktisch gefährlich. Trotzdem braucht er einen einfachen Suchweg. Welche Ereignisse werden bei verdächtigem Login geprüft? Wer sieht Admin-Änderungen? Wo liegen Cloud-Zugriffe? Welche Zeitspanne ist wichtig? Welche Stichwörter gehören in das Ticket, damit Security oder Betrieb schnell weiterarbeiten können?
Ohne diese Übersetzung entsteht Zeitverlust. Der erste Bearbeiter sammelt Screenshots, ein Admin sucht in einem anderen Portal, Security fragt später nach Uhrzeit, Konto und Zielsystem. Jeder Schritt ist nachvollziehbar, aber zusammen entsteht Hektik. Ein fester Log-Weg reduziert diese Reibung. Er sagt nicht, dass der Service Desk zum Security Operations Center wird. Er sagt, welche Informationen im ersten Fenster nicht fehlen dürfen.
Cloud-Dienste machen die Spurensuche verteilter
Früher lagen zentrale Spuren oft in wenigen Systemen. Heute entstehen sicherheitsrelevante Ereignisse in Identitätsdiensten, Cloud-Plattformen, SaaS-Anwendungen, Endgeräten, Netzwerkdiensten und Ticketwerkzeugen. Genau deshalb betont die CISA in ihrem Microsoft Expanded Cloud Logs Implementation Playbook, dass zusätzliche Cloud-Logs für Erkennung, Untersuchung und Reaktion praktisch nutzbar gemacht werden müssen.
Für den Betrieb heißt das nicht, jeden Spezialbegriff zu beherrschen. Wichtig ist die Zuordnung. Wenn ein Cloud-Zugang auffällig ist, muss bekannt sein, in welchem Portal die Anmelde- und Auditspur liegt. Wenn ein Dienstleisterkonto plötzlich Berechtigungen erhält, muss klar sein, wer die Änderung nachvollzieht. Wenn ein Konto gesperrt wird, braucht das Ticket einen Hinweis, ob vorher ungewöhnliche Login-Versuche sichtbar waren.
Admin-Aktionen brauchen eine eigene Spur
Besonders kritisch sind privilegierte Konten. Ein normales Benutzerkonto kann Daten sehen oder Arbeitsschritte auslösen. Ein Admin-Konto kann Berechtigungen ändern, Schutzregeln abschalten, Datenzugriffe öffnen oder ganze Dienste beeinflussen. Deshalb beschreibt Microsoft in den Best Practices für Rollen und Berechtigungen in Microsoft Entra, dass privilegierte Rollen bewusst begrenzt und überwacht werden sollen.
Für ITSM bedeutet das: Admin-Aktionen gehören nicht nur in ein Security-Dashboard. Sie müssen im Incident-Prozess wiedergefunden werden. Wer hat eine Rolle vergeben? Wann wurde ein privilegierter Zugang aktiviert? War die Änderung genehmigt? Gibt es ein Ticket, einen Change oder eine Notfallfreigabe dazu? Wenn diese Fragen erst nach Stunden gestellt werden, verliert der Betrieb die Chance, einen Sicherheitsverdacht früh sauber einzuordnen.
Logs brauchen Besitzer und Aufbewahrungsregeln
Ein Log, das niemand verantwortet, ist im Ernstfall fast so schwach wie kein Log. Der Dienst mag technisch Daten schreiben, aber niemand weiß, ob die Aufbewahrung reicht, ob die richtigen Felder enthalten sind oder wer rechtzeitig Zugriff bekommt. Das ist vor allem bei SaaS- und Cloud-Diensten riskant, weil Standardpakete, Lizenzstufen und Exportmöglichkeiten unterschiedlich sein können.
Der praktische Betriebscheck beginnt mit wenigen Fragen. Welche drei bis fünf Logquellen sind bei Sicherheitsverdacht zuerst relevant? Wer ist Owner je Quelle? Wie lange bleiben die Ereignisse verfügbar? Wer darf sie im Notfall einsehen? Wie wird ein Auszug in einem Ticket dokumentiert, ohne sensible Daten unnötig breit zu verteilen? Solche Regeln gehören in die Servicebeschreibung und nicht erst in die Nachbereitung eines Vorfalls.
Ein Log-Hinweis muss in die Störungsarbeit passen
Der Service Desk braucht klare Formulierungen. Statt „bitte Logs prüfen“ sollte das Ticket sagen: Konto, Dienst, Uhrzeit, beobachtete Wirkung, letzter normaler Zeitpunkt, bekannte Änderung und gewünschte Prüfung. Diese Struktur hilft Security und Betrieb, ohne dass der erste Bearbeiter die Analyse vorwegnimmt. Sie trennt Beobachtung, Verdacht und Entscheidung.
Gleichzeitig muss der Rückweg geregelt sein. Wenn Security eine auffällige Anmeldung findet, muss diese Information verständlich in die Störungsarbeit zurückfließen. Ist der Dienst weiter nutzbar? Muss ein Konto gesperrt werden? Wird ein Change gestoppt? Braucht der Kunde eine andere Meldung? Logs haben nur dann operativen Wert, wenn daraus eine klare nächste Handlung entsteht.
Eine kleine Probe zeigt die Lücken schnell
Der beste Test ist keine große Übung. Ein Team nimmt ein realistisches Szenario: ungewöhnliche Admin-Anmeldung, gesperrtes Konto, verdächtiger SaaS-Zugriff oder unerklärte Rechteänderung. Dann wird geprüft, ob der Service Desk innerhalb von 30 Minuten weiß, welche Spuren gebraucht werden, wer sie liefert und wie das Ergebnis ins Ticket kommt.
Wenn diese Probe stockt, ist das kein Scheitern. Es zeigt nur, dass Logzugriff, Zuständigkeit oder Ticketstruktur noch nicht betrieblich übersetzt sind. Genau dort entsteht der Nutzen. Ein fester Weg zu Sicherheitslogs verkürzt nicht jede Untersuchung. Er verhindert aber, dass der erste wertvolle Vorfallszeitraum mit Suchen nach Zuständigkeiten verloren geht.
Quellen und Einordnung: CISA Microsoft Expanded Cloud Logs Implementation Playbook, Microsoft Entra Best Practices für Rollen und Berechtigungen, Microsoft zu Emergency Access Accounts, NIST Cybersecurity Framework. Stand der Quellenprüfung: 19.07.2026. Bildquelle: Pexels, Foto-ID 5380642.
