Zugriffs-Audit-Protokollierung

Die Mirox-Plattform führt einen kontinuierlichen, manipulationssicheren Audit-Trail über jeden Fernzugriff auf die Netzwerkgeräte einer Anlage — jede VPN-Tunnel-Sitzung (Layer 3/4) und jede Proxy-Anfrage (Layer 7, HTTP). Diese Seite beschreibt genau, was erfasst wird, wie granular die Details sind, wer darauf zugreifen darf und wie lange die Daten aufbewahrt werden.

Der Audit-Trail ist das, was den Zugriff der Plattform auf Anlagengeräte konform mit den deutschen KRITIS-Regeln und der EU-NIS2-Richtlinie macht. Diese Vorschriften geben das Mindestaufbewahrungsfenster sowie die Kategorien von Nachweisen vor, die der Betreiber vorlegen können muss — das Audit-Log ist jedoch in erster Linie ein Werkzeug zur Zugriffsverfolgung für den Anlagenbetreiber.

Warum es diese Audit-Protokollierung gibt

KRITIS und NIS2 verpflichten Betreiber kritischer Infrastruktur (in unserem Fall die Anlagennetze von Solarparks, Windparks und Batteriespeicherstandorten), für jeden Fernzugriff die folgenden Fragen vollständig und auch noch Monate später beantworten zu können:

Wer hat das interne Netzwerk dieser Anlage erreicht?
Wann wurde die Verbindung aufgebaut — und je Verbindung: wann wurde welches Subnetz / welches Gerät zuerst und zuletzt berührt?
Wie viel Datenverkehr wurde während der Verbindung übertragen?
Welches konkrete Gerät und welcher Dienst wurde berührt?
Was wurde dort getan (auf HTTP-Ebene: welche URLs, welche Methoden)?

Der Mirox-Audit-Trail deckt all diese Fragen ab und ist für den Anlagenbetreiber als die meldepflichtige Partei konzipiert — nicht für den zugreifenden Benutzer.

Zwei Zugriffswege, ein gemeinsames Audit

Beide Zugriffsmechanismen der Plattform werden zu einer einheitlichen Zugriffsübersicht pro Anlage zusammengeführt:

Weg	Erfasste Ebene	Welche Frage beantwortet er?
VPN	Layer 3/4 (IP-Verkehr)	„Wer hat von wo aus welches Subnetz und welches konkrete Gerät erreicht — wann zuerst, wann zuletzt, welches Volumen?"
Proxy	Layer 7 (HTTP)	„Was hat der Benutzer am Gerät konkret getan — welche URLs, welche Anfragen, wie viele Anfragen, welche Dauer?"

Beide Wege teilen sich dieselbe Identitätsbasis (das Mirox-Konto des Benutzers) sowie dieselbe rechtliche Aufbewahrungs- und Zugriffslogik. Aus Sicht des Anlagenbetreibers gibt es eine chronologische Zugriffsliste pro Anlage, in der beide Kanäle nebeneinander erscheinen und nach Bedarf eingegrenzt werden können.

Erfassungstiefe

Der Audit-Trail ist in mehreren Detailebenen organisiert. Je tiefer man in die Hierarchie vordringt, desto granularer werden die Informationen:

Ebene 1: Zertifikat / Identität

Die oberste Ebene erfasst pro VPN-Zertifikat eine Momentaufnahme der Benutzeridentität zum Zeitpunkt der Ausstellung und Rotation:

Anonymisierter Kontoname
E-Mail-Adresse
Eindeutige Zertifikatskennung

Selbst wenn der Benutzer später umbenannt, gelöscht oder das Zertifikat widerrufen wird, bleibt diese Identität erhalten.

Ebene 2: Sitzung

Jede Verbindung wird als Sitzung verfolgt. Eine Sitzung ist ein zusammenhängender Aktivitätsverlauf desselben Zertifikats von derselben Quelle. Kurze Unterbrechungen unter zehn Minuten zählen weiterhin als dieselbe Sitzung; längere Pausen erzeugen eine neue Sitzung.

Pro Sitzung erfassen wir:

Wer verbunden ist (Konto- und E-Mail-Momentaufnahme zum Verbindungszeitpunkt — bleibt erhalten, selbst wenn das Konto später gelöscht wird)
Verbindungszeitpunkt
Quell-IP-Adresse und geografische Zuordnung (Stadt, Land)
Region und Knoten, der die Verbindung terminiert hat (für die Latenzanalyse)
Gesamtdatenvolumen (eingehend und ausgehend)

Ebene 3: Subnetzvolumen (nur VPN)

Innerhalb einer Sitzung erfassen wir pro berührtem Anlagen-Subnetz:

Welcher Park und welches Subnetz berührt wurde
Übertragenes Datenvolumen und Paketanzahl pro Sitzung und Subnetz
Zeitpunkt der ersten und letzten Berührung
Momentaufnahmen des Park- und Organisationsnamens für den Fall, dass die Anlage später umbenannt oder gelöscht wird

Rauschen wie DNS-Abfragen, mDNS-Multicast, ICMP-Pings und portscan-artiges Verhalten wird gefiltert und/oder ratenbegrenzt, sodass der Audit-Trail nur tatsächliche Nutzungsereignisse enthält.

Ebene 4: Geräteberührungen (nur VPN)

Die feinste VPN-Ebene erfasst pro konkretem Zielgerät:

Geräte-IP, Protokoll (TCP, UDP, ICMP, ICMPv6, SCTP) und Port
Das zugeordnete Gerät aus dem Anlageninventar (Name, Typ) — sofern registriert
Zeitpunkt der ersten Berührung innerhalb der Sitzung
Anzahl der Verbindungsereignisse in dieser Sitzung
Momentaufnahmen aller Kennungen zum Zeitpunkt der ersten Berührung

Unterschwellige Interaktionen (z. B. einzelne TCP-Resets durch Fehlklicks) werden konservativ erfasst, sind aber als solche erkennbar.

Ebene 4': HTTP-Sitzungen (nur Proxy)

Parallel dazu erfasst der Proxy pro Sitzung auf HTTP-Ebene:

Konto und E-Mail des zugreifenden Benutzers
Welches Webziel oder welcher Standard-Gerätezugriff verwendet wurde
Zielgerät (Name, IP) — mit Momentaufnahme für spätere Lösch- oder Umbenennungsfälle
Browser, Betriebssystem, öffentliche IP-Adresse, geografischer Standort
Sitzungsbeginn und -ende (Sitzungsende: 10 Minuten Inaktivität)
Anzahl der Anfragen und ihre HTTP-Methoden (z. B. {"GET": 42, "POST": 3, "PUT": 1})
Eingehendes und ausgehendes Datenvolumen
Eine URL-basierte Aktivitätsspur der Sitzung (Query-Strings werden geschwärzt, begrenzt auf die jüngste Aktivität innerhalb eines festen Kontingents)
Eine KI-generierte Kurzbeschreibung der Sitzungsaktivität zur schnellen Triage. Ist die KI beim Schließen der Sitzung nicht verfügbar, wird die Beschreibung nachträglich ergänzt — sie ist nicht optional, sondern fester Bestandteil jeder abgeschlossenen Proxy-Sitzung.

Maximal mögliche Detailtiefe

Die maximale Detailtiefe ist somit:

Beispiel für einen VPN-Zugriff:

„Benutzer X hat sich am 13.05.2026 um 13:44 über VPN von der öffentlichen IP 198.51.100.7 (Region eu-central, München, DE) verbunden, hat während dieser Sitzung das Subnetz 10.90.69.0/24 des Parks ‚Solarpark Annaburg' angesprochen (12 MB übertragen, erste Berührung 13:45, letzte 13:54) und dabei konkret das Gerät ‚Wechselrichter-Block 3' (10.90.69.12, TCP/443) berührt (erste Berührung 13:45, 41 Verbindungen)."

Beispiel für einen Proxy-Zugriff:

„Benutzer Y hat am 13.05.2026 zwischen 13:46 und 13:55 über den Proxy auf das Webziel ‚Wechselrichter-Block 3 – Service-UI' von der öffentlichen IP 203.0.113.42 (Region eu-central, Frankfurt, DE) auf Mobile Safari 26.4 / iOS 18.7 zugegriffen (87 Anfragen, davon 84 GET, 3 POST; 2,3 MB Antwortvolumen, KI-Zusammenfassung: ‚Konfigurationsänderung an den MPP-Tracker-Einstellungen')."

Sowohl VPN als auch Proxy erfassen die öffentliche Quell-IP, die terminierende Region und die geografische Zuordnung (Stadt, Land) der Verbindung. Beim Proxy gelangen zusätzlich Browser- und Betriebssysteminformationen in den Audit-Trail (über den vom Browser gesendeten User-Agent), da diese ohnehin auf HTTP-Ebene mitwandern. Bei reinem VPN-basiertem Zugriff (Layer 3/4) sind diese Anwendungsclient-Informationen prinzipbedingt nicht verfügbar — dort sieht die Plattform nur den IP-Paketstrom, nicht den Client auf Anwendungsebene.

Eine tiefere Detailebene (Paketinhalte, vollständige HTTP-Bodies) wird bewusst nicht erfasst, da dies sowohl datenschutzrechtlich problematisch als auch betrieblich sinnlos wäre.

Wer darf das Audit einsehen?

Der Zugriff auf den Audit-Trail richtet sich nach der Job-Rolle, die ein Benutzer an der Anlage innehat:

Technische Betriebsführung oder höher an der Anlage kann den Audit-Trail dieser Anlage einsehen. In der Praxis bedeutet das einen Betreiber, eine Technische Betriebsführung oder einen Asset Manager an der Anlage. Admins und Moderatoren qualifizieren sich automatisch, da ihre Organisationsrolle auf jeder Anlage ihrer Organisation auf einen qualifizierenden Job abgebildet wird (siehe das Berechtigungssystem für die vollständige Zuordnung von Rolle zu Job).
Kooperationspartner sind eingeschlossen: Ein Techniker, der über eine Kooperation mit der erforderlichen Job-Rolle eine Anlage erreicht, kann den Audit-Trail dieser Anlage ebenfalls einsehen. Der Audit-Einblick folgt derselben Job-Rollen-Schranke wie die übrigen Steuerungen der Anlage.
Betrachter werden abgewiesen. Ein Betrachter (und alle unterhalb der Ebene der Technischen Betriebsführung) sieht keinen Audit-Trail. Das Frontend blendet den Zugriffsprotokoll-Tab für Benutzer unterhalb der Schwelle vollständig aus.

Die Plattform stellt die Audit-Ansicht über einen dedizierten Zugriffsprotokoll-API-Endpunkt und eine entsprechende UI-Ansicht bereit. Das Bearbeiten oder Löschen von Audit-Datensätzen wird nicht unterstützt.

Aufbewahrungsdauer und Manipulationssicherheit

Mindestens 730 Tage Aufbewahrung für alle Audit-Ebenen (Zertifikat, Sitzung, Subnetzvolumen, Geräteberührungen, HTTP-Sitzungen). Die Aufbewahrungsdauer ist über die Ebenen hinweg abgestimmt, sodass Querverweise zwischen ihnen stets innerhalb des vollständigen Audit-Fensters auflösbar bleiben.
Momentaufnahme-Felder in jedem Audit-Datensatz (z. B. Parkname, Gerätename, Organisationsname, Konto, E-Mail) sind write-once: Sie werden beim ersten Einfügen gestempelt und nie aktualisiert. Dies garantiert die forensische Identität, selbst wenn der ursprüngliche Datensatz (Benutzer, Anlage, Gerät) später gelöscht oder umbenannt wird.
Live-Auflösung mit Rückfall: Solange die referenzierten Entitäten (Benutzer, Park, Organisation, Gerät) noch existieren, zeigt die Audit-Ansicht ihren aktuellen Namen an (z. B. nachdem die Anlage umbenannt wurde). Sobald die Entität gelöscht ist, fällt die Ansicht automatisch auf die gestempelte Momentaufnahme zurück. Der Audit-Trail bleibt somit lesbar — selbst Monate oder Jahre später, nach Personalwechseln oder Anlagenverkäufen.
Keine für Benutzer zugänglichen Lösch- oder Bearbeitungspfade: Die Audit-Tabellen können nicht über reguläre UI- oder API-Operationen verändert werden. Sie werden nur durch automatisierte Audit-Ereignisse und durch den nächtlichen Aufbewahrungsdurchlauf nach Ablauf der 730 Tage berührt.

Verhalten bei Löschungen

Ereignis	Auswirkung auf den Audit-Trail
Benutzer wird gelöscht	Audit-Datensätze bleiben erhalten. Die Ansicht zeigt die Konto- und E-Mail-Momentaufnahme aus dem Zertifikat oder der Sitzung.
Zertifikat wird widerrufen	Audit-Datensätze bleiben erhalten. Das Zertifikat wird soft-widerrufen und bleibt 730 Tage lang als Auflösungsquelle verfügbar.
Anlage wird gelöscht	Audit-Datensätze bleiben erhalten. Die Ansicht zeigt die Parknamen-Momentaufnahme aus dem Audit-Datensatz.
Gerät wird gelöscht / umbenannt / mit geänderter IP versehen	Audit-Datensätze bleiben erhalten. Die Ansicht zeigt die Gerätenamen-Momentaufnahme; die IP im Datensatz ist die dauerhafte forensische Kennung.
Organisation wird gelöscht	Audit-Datensätze bleiben erhalten. Die Ansicht zeigt die Organisationsnamen-Momentaufnahme.

Schutz vor Manipulation von Audit-Daten

Sitzungen, die nicht zugeordnet werden können (z. B. weil ein Header entfernt wurde), werden dennoch mit leerer Identität erfasst, anstatt verworfen zu werden. Eine spätere Analyse kann diese Fälle dann gezielt untersuchen.
HTTP-Sitzungen werden nicht allein von SaaS-Komponenten geschlossen, sondern vom Anlagen-Agenten selbst geschlossen und gemeldet, sodass die SaaS-Plattform Anfragezahl oder Volumen nicht stillschweigend zu niedrig ausweisen kann.
Submillisekunden-Race-Conditions beim Auslesen von Zählerketten werden als „verlustbehaftet by design" akzeptiert und dokumentiert, um KRITIS-konform zu sein; sie können sich schlimmstenfalls auf einen einzelnen Zählerzyklus auswirken, niemals auf ganze Sitzungen oder Geräteberührungen.

Filtern und Suchen in der Audit-Ansicht

Die Audit-Ansicht erlaubt einem berechtigten Benutzer, die Ergebnismenge einzugrenzen:

Nach Benutzerkonto
Nach Subnetz oder Geräte-IP
Nach Protokoll oder Port (VPN-Weg)
Nach Webziel oder konkretem Gerät (Proxy-Weg)
Nach Zeitraum (von … bis …)
Standardsortierung nach „zuletzt gesehen"

Die Standardsortierung gruppiert natürlicherweise nach Sitzung, sodass die Frage „Benutzer X hat in dieser Sitzung 18:43–19:00 die Geräte A und B berührt und in einer zweiten Sitzung 13:44–14:30 das Gerät C" direkt sichtbar ist, ohne weitere clientseitige Gruppierung.

Datenschutz und Offenlegung

Was der Audit-Trail enthält:

Identitätsfelder, abgeleitet aus dem regulären Mirox-Konto (Konto, E-Mail)
Quell-IP-Adressen der Verbindung (gesetzlich für KRITIS erforderlich)
Geografische Zuordnung der Quelle (Stadt, Land)
Datenvolumen, Anfragezahl, Methodenverteilung, Zeitstempel

Was der Audit-Trail nicht enthält:

Inhalte einzelner HTTP-Bodies
VPN-Paketinhalte
Tastatureingaben oder Bildschirmaufzeichnungen
Daten, die nicht für die KRITIS-/NIS2-Meldung erforderlich sind

Was bei einer behördlichen Anfrage zu tun ist

Für vorfallgetriebene Auskunftsersuchen an die zuständige Behörde (z. B. das BSI im Rahmen von KRITIS) sind alle erforderlichen Daten innerhalb des 730-Tage-Fensters über die Audit-Ansicht verfügbar. Eine Exportfunktion (z. B. CSV) ist als separate, einzeln auditierte Aktion geplant und wird auf Anfrage bereitgestellt — ein solcher Export ist selbst ein auditierungswürdiger Vorgang, sodass dokumentiert wird, wer wann welche Audit-Daten exportiert hat („Audit des Audits").