Auditing

Für den Betrieb eines Systems ist es auch immer wieder erforderlich, Konfigurationen zu ändern. Im Bezug auf Exchange bedeutet dies, dass z.B. Benutzer angelegt, Mailadressen ergänzt aber auch Konfigurationseinstellungen verändert werden. Sehr häufig erfolgt dies durch den Administrator und wird weder dokumentiert noch überwacht. Am Ende ist nicht mehr nachvollziehbar, welche Änderungen durchgeführt wurden.

Immer mehr Firmen und vielfach auch Aktionäre, Börsenaufsicht, Banken, Vorstände, Betriebsrat, Innenrevision fordern daher eine Überwachung und Protokollierung dieser Tätigkeiten. Häufig fallen dabei auch Begriffe wie "Sarbanes-Oxley" und "HIPAA".

Ziele

Die Ziele eines Auditing sind:

Letztlich dient ein Auditing auch dazu, dass der Spruch "Ich hab nichts geändert" so nicht mehr haltbar ist. Dabei darf ein Auditsystem nicht als Mittel zur Kontrolle oder Gängelung von Administratoren und IT-Abteilung verstanden werden, sondern kann gerade auch umgekehrt sehr gut belegen, wie eine Abteilung arbeitet und dass die Ursache für einen Fehler wo anders zu suchen ist.

Was ist zu überwachen ?

Es gibt zwei Benutzerkreise, die einem Audit unterworfen werden können

Für jede Gruppe gibt es passende Lösungen und Produkte.

Wie kann überwacht werden ?

Ich unterscheide hier drei Ansätze der Überwachung:

Nach der Ausführung

Gerade im Bereich der Revision ist es erforderlich, zu wissen, wer worauf Berechtigungen hat. Bei den meisten Systemen (und auch bei Windows) ist es kein Problem, ein Verzeichnis auszuwählen und zu dokumentieren, wer auf dieses Verzeichnis berechtigt ist. Aber der umgekehrte Weg ist mit Bordmitteln nicht einfach möglich. Auch im Active Directory ist dies nicht möglich.

Aber es gibt entsprechende Programme, die alle Berechtigungen einer Umgebung auslesen und daraus einen Bericht erstellen. Die meisten dieser Programme erlauben auch die Speicherung eines bestimmten Standes um im Nachhinein auch Veränderungen zu erkennen. Somit ist zumindest mit diesen Hilfsmitteln ein Schnappschuss und Vergleich bestimmter Zeitstände möglich. Allerdings fehlt dabei die Echtzeitüberwachung und die Aufzeichnung mehrere Änderungen am gleichen Objekt zwischen zwei Aufnahmen.

Während der Ausführung

Aus diesem Grund gibt es Programm, die entweder die in Windows eingebauten Überwachungsmechanismen nutzen oder eigene Module einbinden um die Aktivitäten in Echtzeit aufzuzeichnen. Einige der Programme haben hier auch die Möglichkeit, bestimmte Aktionen zu verhindern, weil diese gegen Richtlinien verstoßen. Damit sind sogar Änderungen durch den Administrator blockierbar.

Besonders interessant ist hierbei die Überwachung in Echtzeit, die über entsprechende Alarmierungen auch die Erkennung von Eindringversuchen (z.B. fehlerhafte Anmeldung) oder die versuchte Änderung kritischer Gruppen (z.B. Domänen Administratoren) meldet.

Vor der Ausführung

Eine dritte Variante ergibt sich, wenn das Programm, welches die Änderungen durchführt, selbst die Änderungen protokolliert. Nun ist es so, dass die MMC und viele anderen Zugriffe, z.B.: mit LDIFDE, ADSIEDIT etc. gar nicht entsprechend protokolliert werden. Aber vielen Firmen gehen mehr und mehr dazu über, dass die verschiedenen Veränderungen an Benutzern und Einstellungen nicht mehr direkt über die Administrationswerkzeuge von Microsoft durchgeführt werden, sondern über eigens für die Verwaltung angepasste administrative Programme. Dies können z.B. webbasierte Lösungen sein,  bei denen die ausführenden Personen (die nicht unbedingt Administratoren sein und auch nicht zur IT gehören müssen) in einem Browser die gewünschten Aktionen auswählen und Formulare ausfüllen. Nach dem Absenden kann dann die Webanwendung direkt die Aktionen mit ihren Berechtigungen durchführen oder die Eingaben als Auftrag an andere Personen weiter leiten. So könnte die Personalabteilung das Ausscheiden eines Mitarbeiters eingeben und das Skript setzt das Verfallsdatum des Kontos entsprechend. Zudem kann die Oberfläche entsprechende Hilfen anbieten, die Eingabe anhand von Vorlagen und Auswahlfeldern vereinfachen und nebenbei die Qualität der Daten verbessern.

Sobald ein eigenes anpassbares Programm jedoch letztlich die Änderungen durchführt und niemand mehr direkt per LDAP die Einträge ändern kann, dann kann diese Software ebenfalls ein "Changelog" mitschreiben, Missbrauchsversuche melden und Fehler protokollieren.

Damit ist natürlich nicht zu überwachen, welche Änderungen z.B. eine Softwareinstallation durchführt. Aber die alltäglichen administrativen Veränderungen sind nicht nur protokollierbar, sondern können zudem auf Plausibilität und Gültigkeit überprüft werden. Je nach Umsetzung muss der Anwender selbst gar nicht mehr die erforderlichen Berechtigungen auf den jeweiligen Objekten besitzen, da die Verwaltungsanwendung (z.B. eine ASP-Seite oder ein Serverprozess) die eigentlichen Einstellungen vornimmt. (Siehe auch Provisioning)

Auditing von Windows, Active Directory und Exchange

Ehe nun gleich der Weg zum nächsten Online Shop führt, stellt sich die Frage, was das Betriebssystem selbst schon kann. Microsoft hat das Active Directory und das Windows Dateisystem (NTFS) mit umfangreichen Eigenschaften für Auditing ausgestattet. So können Sie:

Alle Events dieser Überwachung landet im Security Eventlog des entsprechenden Servers.

Um darauf aussagekräftige Ergebnisse und Reports zu erstellen und eine gewisse Revisionssicherheit zu erhalten, sollten Sie dafür sorgen, dass die Einträge in diesem Eventlog z.B. in einer Datenbank konsolidiert werden. (z.B.: mit Syslog Überwachung, MOM2005 oder Eventlog auf Fehler 8528 überwachen.

Hier ein Beispiel eines Eintrags, der beschreibt, dass ein Benutzer "massuser-000004" in die Gruppe "MSXFSAQ\sgtest"aufgenommen wird.

Um aus diesen einzelnen Events aber letztlich ein "Protokoll der Änderungen" zu erstellen ist noch ein weiter Weg. Hier sind wieder eigene Skripte oder Reportdienste etc. erforderlich, um aus der Summe der Eventlogs die gewünschten Daten zu ermitteln.

Hinweis:
Die Programme AUDITPOL und AUDITUSR erlauben eine feinere Einstellung der Überwachungsrichtlinien per Kommandozeile.

Überwachung von Client Zugriffen für Internet Protokolle

Exchange stellt seine Dienste über verschiedene Internetprotokolle bereit, welche ebenfalls protokolliert und entsprechend ausgewertet werden können.

Überwachung per Eventlog und Diagnoseprotokoll

Es gibt allerdings schon Möglichkeiten, die Zugriffe der Benutzer auf Postfächer zu überwachen. Der Exchange Informationsspeicher kennt verschiedene Diagnosefunktionen, mit denen man bestimmte Zugriffe im Eventlog protokollieren lassen kann. Je nach Version sind die Daten an anderen

Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Access Control" -Level low

Beide Einträge bewirken, dass Exchange nun Zugriffe der Anwender im Eventlog ablegt

Ereignistyp:       Warnung
Ereignisquelle:    MSExchangeIS Mailbox Store
Ereigniskategorie: Zugriffssteuerung
Ereigniskennung:   1029
Datum:             28.10.2007
Zeit:              10:48:00
Benutzer:          Nicht zutreffend
Computer:          SRV01
Beschreibung:
user1@msxfaq.local konnte einen Vorgang nicht ausführen, da der Benutzer die folgenden Zugriffsrechte nicht besitzt:
 
'Delete' 'Read Property' 'Write Property' 'Create Message' 'View Item'
'Create Subfolder' 'Write Security Descriptor' 'Write Owner' 'Read Security Descriptor' 'Contact'
 
Der DN des zugehörigen Postfachs lautet /O=MSXFAQ/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=USER2. Die Ordner-ID befindet sich in dem Datenabschnitt dieses Ereignisses.
 
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Daten:
0000: 01 00 00 00 5c 5b f7 f9   ....\[÷ù

Generell muss natürlich auch beobachtet werden, welche zusätzliche Last solche eine Überwachung an das System stellt. Schließlich landen die Einträge im Application Log und könnten andere wichtige Einträge quasi schon verdecken.

Eventlog auswerten

Die Protokollierung im Eventlog ist natürlich nur der erste Schritt. Zum einen kommen nun natürlich sehr viele Events dort an, die über die klassische Eventlog Anzeige nicht mehr sinnvoll auszuwerten sind und zum anderen wird natürlich ein entsprechender "Angreifer" versuchen seine Spuren zu verwischen.

Daher ist es wichtig, diese Events möglichst schnell an ein anderes abgetrenntes System zu übermitteln, z.B. per Syslog Überwachung. Mit einer einfachen Kopie des Events ist es aber nicht getan, da alle Zugriffe auf Ordner protokolliert werden. Eine entsprechende Software muss also aus dem Event auch den Benutzer, das Zielpostfach und vielleicht anhand der Ordner-ID auch den entsprechenden auslesen.

Was ist ein Alarm wert ?

Wenn das System nun den Event hat, dann ist das immer noch nicht ausreichend, um Alarm zu schlagen, da es sehr viele "normale" Zugriffe gibt, z.B.:

Sie sehen also, dass es gar nicht so einfach ist, von einem "fehlgeschlagenen Zugriff" auf einen möglichen Vertrauensbruch zu schließen.

Exchange 2010 "Administrator Audit Logging"

Exchange 2010 nutzt wie Exchange 2007 die Powershell zur Administration der Konfiguration. Allerdings arbeitet Exchange 2010 mit RBAC. Die Powershell Befehle werden "remote" durch einen Agenten ausgeführt und dieser kann die ausgeführten Befehle auch protokollieren.

Das Logging muss ebenfalls über die Powershell aktiviert werden. Die Einstellungen landen dann im Active Directory und nachdem die AD-Replikation diese Einstellung auch überall verfügbar gemacht hat, werten die Exchange 2010 Server diese Konfiguration auch aus.

Die Logs landen in einem eigens anzulegenden Postfach. Damit ist zwar eine zentrale Ablage gegeben, aber ein Postfach wird ein Exchange Admin natürlich auch einfach öffnen und seine Spuren verwischen. Ich hätte hier ein Exchange Audit-Eventlog vorgezogen, was auch einfacher zentralisiert werden kann.

Eine Überwachung von Änderungen am Inhalt ist damit aber nicht abgedeckt.

Exchange 2007 SP2

Mit Exchange 2007 SP2 gibt es nun auch eine Überwachungsfunktion auf Änderungen. Im Eventlog finden Sie ein neues Eventlog, in welchem Änderungen nun auch mit gespeichert werden.

Mein Log ist erst mal leer, weil ich noch keine Überwachung aktiviert habe. Auch diese Überwachung wird über das Diagnoseprotokoll konfiguriert.

Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Message Access" -Level low
Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Folder Access" -Level low
Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Extended Send As" -Level low
Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Extended Send On Behalf Of" -Level low

Es sind die unterschiedlichen Level möglich, um mehr Details zu erhalten. Seit Exchange 2007 können die Parameter auch per GUI auf den Eigenschaften der Server eingestellt werden.

Eventlog Level für Auditing

Die Ausgabe erfolgt dann im Exchange Audit Eventlog.

Audit Software

Aufgrund dieser Komplexität ist es mir nicht einfach möglich, ein passendes Skript zu erstellen, welches in allen Fällen zuverlässig erlaubte, "irrtümliche" und illegal versuchte Zugriffe unterscheiden kann. Eine Lösung müsste schon über Häufigkeiten und natürlich den angesprochenen Ordner gehen.

Aber eines kann die Überwachung sehr einfach leisten: Es gibt oft Postfächer, auf die sicher nur eine handverlesene Anzahl von Benutzern Zugriff haben darf. So ist ein "Journalpostfach", in welchem letztlich die gesamte Kommunikation liegt.

Und dann muss es diese Zugriffsmuster noch auf "erlaubt" und "verboten" unterscheiden. Es ist natürlich legitim, dass ein Stellvertreter oder Sekretariat ein anderes Postfach öffnet. Es ist auch normal, dass z.B. ein Archivprozess oder Blackberry Server mit einem Dienstkonto sogar sehr viele Postfächer und Elemente liest. Eine Überwachung muss also nicht nur glücklicherweise "fehlgeschlagene" Zugriffsversuche sondern auch leider erfolgreiche Zugriffe in der Flut der normalen Fehler und OK-Meldungen heraus finden. Keine einfache Aufgabe.

Frage:'
Wie lösen Sie das Problem "Auditing" in ihrer Firma? Einfach totschweigen oder mit Drittsoftware ? Schreiben Sie mir!

Weitere Links

Keywords:Audit Überwachung Revision