Dashboard

Emona MFT Dashboard

Eine Webseite für alle Ihre Emona-MFT-Server und -Clients: wer online ist, was wann gesendet wurde, was fehlgeschlagen ist, wie viel Speicherplatz frei ist, Alarme per E-Mail oder Syslog – und ein Vorfallregister für jeden Alarm.

Vom BLUEGEM-Team · Aktualisiert am 4. November 2026

So funktioniert's

Das Dashboard ist ein eigenes Programm, das Sie neben Ihren Emona-MFT-Servern installieren. Jeder Server und jeder Client erhält einen eigenen Schlüssel und sendet seine Ereignisse und ein Lebenszeichen (Heartbeat) über eine verschlüsselte Agent-Verbindung an das Dashboard (standardmäßig TCP-Port 9100). Das Dashboard öffnen Sie im Browser.

• Nur lesend gegenüber Servern und Clients. Das Dashboard ändert nie deren Einstellungen und sendet ihnen nie Befehle. Agents senden nur; das Dashboard antwortet nur mit einer Bestätigung.
• Hält nie eine Übertragung auf. Ist das Dashboard nicht erreichbar, warten die Ereignisse im Speicher (bis zu 10.000) und werden gesendet, sobald es wieder da ist. Ein gestopptes Dashboard oder ein falscher Schlüssel zeigt sich nur im Log.
• Keine Datenbank, kein Framework. Eine JAR-Datei, Daten in einfachen Dateien auf Ihrer Festplatte. Agents werden in einer einfachen Datei eingetragen, und Änderungen gelten ohne Neustart.
• Ereignisse werden genau einmal gespeichert. Jedes Ereignis trägt eine Sequenznummer, sodass nach einer verlorenen Bestätigung erneut gesendete Ereignisse übersprungen werden – auch nach einem Absturz oder Neustart des Dashboards.

Was Sie sehen

• Übersicht: Server und Clients online, heute gespeicherte Dateien und Probleme, der geringste freie Speicherplatz, offene Alarme, gespeicherte Dateien der letzten 24 Stunden und die neuesten Übertragungen. Die Zahl der Übertragungen wird in 15-Minuten-Intervallen geführt, daher richten sich die Tagessummen nach Ihrer Zeitzone.
• Clients und Client-Details: letzter Kontakt, letzte Datei, wartende Dateien, Quellverzeichnisse sowie Dateien und Probleme der letzten Tage.
• Server: Speicher und freier Platz pro Client, laufende Übertragungen und Einstellungen.
• Übertragungen: Suche nach Tag, Client, Dateiname und Ergebnis über alle aufbewahrten Tage. Die Seite zeigt die neuesten 500 Übertragungen eines Tages zusammen mit der Tagessumme, und der CSV-Export enthält alle.
• Alarme: offene und vergangene Alarme. Operatoren und Admins bestätigen sie.
• Agents (Admins): jeder Server und Client mit Agent-ID, Schlüssel-Fingerprint, Rolle, Status, letztem Kontakt und Adresse.
• Vorfallregister: jeder Alarm mit Bestätigung, Lösung, Notizen und Verlauf, für einen Zeitraum als CSV oder JSON exportierbar (Admins und Auditoren).
• Audit, Benutzer, Lizenz (Admins) und Konto für jeden Benutzer, mit Zwei-Faktor-Anmeldung.

Die Seiten aktualisieren sich alle 30 Sekunden selbst.

Ereignisprotokoll und Audit-Trail

Server und Clients von Emona MFT schreiben ein maschinenlesbares Ereignisprotokoll: eine JSON-Zeile pro Ereignis, eine Datei pro Tag. Es erfasst jede abgeschlossene, abgelehnte oder fehlgeschlagene Übertragung mit Client, Dateiname, Größe, SHA-256-Hash, Protokoll und Dauer, außerdem Starts und Stopps, einen nicht erreichbaren Server und ein fehlendes Quellverzeichnis. Schlüssel und Dateiinhalte werden nie hineingeschrieben.

• An den echten Agent gebunden. Das Dashboard speichert jedes Ereignis unter der Agent-ID der authentifizierten Verbindung, sodass kein Server oder Client Ereignisse im Namen eines anderen senden kann. Rolle und Client-Label eines Agents sind fest, nur Server melden Übertragungen, und die Ereignisse eines Clients zählen immer für sein eigenes Label.
• Hashverkettetes Audit-Log. Jede Anmeldung, fehlgeschlagene Anmeldung, Benutzeränderung, Alarmbestätigung, Alarmnotiz, jeder Export und jede Lizenzänderung landet im Audit-Log des Dashboards. Jede Zeile enthält den SHA-256-Hash der vorherigen Zeile, sodass eine in der Mitte einer Datei geänderte oder entfernte Zeile auffällt.
• Siegel. Ereignisprotokolle, das Audit-Log und das Vorfallregister erhalten stündlich (konfigurierbar), am Ende jedes Tages und beim Stopp Siegelzeilen. Im Vergleich mit der Kopie in Ihrem SIEM zeigen die Siegel auch Zeilen, die am Ende einer Datei entfernt wurden, und eine neu berechnete Kette.
• Stündliche Selbstprüfung. Server, Clients und das Dashboard prüfen ihre eigenen Hash-Ketten beim Öffnen einer Datei und jede Stunde. Eine unterbrochene Kette löst einen kritischen Alarm aus: „Event log changed“, „Audit log changed“ oder „Incident register changed“.
• Überprüfung. Die Seite „Audit“ zeigt die Integrität jeder Tagesdatei, markiert versiegelte Dateien, und Admins und Auditoren können sie herunterladen. Eine Prüfung auf der Kommandozeile verifiziert jede Ereignis-, Audit- oder Vorfalldatei, auf Wunsch gegen die SIEM-Kopie.

Die Logs sind manipulationserkennend, nicht manipulationssicher: Wer Schreibzugriff auf die Dateien hat, kann sie weiterhin ändern. Die Siegel machen eine solche Änderung sichtbar, wenn die Dateien mit einer anderswo aufbewahrten Kopie verglichen werden; behandeln Sie daher die Kopie in Ihrem SIEM als maßgeblich.

SIEM- und Syslog-Weiterleitung

• Jede Zeile an Ihr SIEM. Ist siem.host gesetzt, sendet das Dashboard jedes Ereignis aller Server und Clients und jede Audit-Zeile als RFC-5424-Syslog über UDP, TCP oder TLS an Ihr SIEM oder Ihren Log-Server.
• Nichts geht bei einem Ausfall verloren. Zeilen werden aus den Dateien gelesen und die Position wird gespeichert, sodass Zeilen, die während eines SIEM-Ausfalls oder eines Dashboard-Neustarts geschrieben wurden, danach gesendet werden. Ein SIEM, das nicht mehr liest, wird erkannt, und der Alarm „SIEM forwarding failing“ wird geöffnet.
• Auch ohne Dashboard. Server und Clients können ihre eigenen Ereigniszeilen direkt an einen Syslog-Empfänger senden.
• Fertige Suchabfragen. Die Dokumentation nennt die Ereignisse, für die sich eine Regel lohnt, mit Beispielabfragen für Splunk, Elastic und Microsoft Sentinel.

Alarme

Jeder Alarm wird einmal beim Öffnen und einmal beim Ende gesendet, per E-Mail über Ihr SMTP-Relay und an Syslog (RFC 5424), sofern konfiguriert. Wiederholungen werden gezählt, nicht erneut gesendet. Operatoren und Admins bestätigen Alarme und fügen Notizen hinzu, etwa was gefunden und getan wurde.

Vorfallregister

Jeder Alarm ist auch ein Vorfall. Das Dashboard hält jedes Öffnen, erneute Öffnen, Bestätigen, Lösen und jede Notiz fest, mit dem Benutzer und dem Zustand des Vorfalls zu diesem Zeitpunkt, in Dateien, die nur der Eigentümer lesen kann, hashverkettet und versiegelt, standardmäßig drei Jahre aufbewahrt.

• Für NIS2-Meldungen. Das Register liefert die Zeitpunkte (geöffnet, bestätigt, gelöst), wer den Vorfall bearbeitet hat, die Notizen und den Verlauf, die Sie für eine Frühwarnung, eine Meldung oder einen Abschlussbericht brauchen (Art. 21 und 23 NIS2). Ob ein Vorfall erheblich ist und ob Sie ihn melden, entscheiden Sie; nichts wird an eine Behörde gesendet.
• Export für einen Zeitraum. Admins und Auditoren exportieren alle Vorfälle eines Zeitraums als CSV oder JSON auf der Seite „Alerts“. Jeder Export wird im Audit-Log festgehalten.

Benutzer, Rollen und Anmeldung

• Rollen. Viewer sehen die Seiten, die sie sehen dürfen. Operatoren bestätigen zusätzlich Alarme und fügen Notizen hinzu. Admins verwalten außerdem Benutzer, sehen das Audit-Log und die Agents, installieren die Lizenz und exportieren das Vorfallregister. Auditoren – für interne oder externe Prüfer und Datenschutzbeauftragte – sehen das Audit-Log, laden es herunter und exportieren das Vorfallregister, können aber nichts ändern. Ein Benutzer kann auf bestimmte Clients beschränkt werden und sieht dann nur diese Clients und ihre Übertragungen.
• Zwei-Faktor-Anmeldung. Jeder Benutzer kann Anmeldecodes aus einer Authenticator-App (TOTP: Google Authenticator, Microsoft Authenticator, Aegis, 1Password und andere) per QR-Code einschalten und erhält 10 einmalige Wiederherstellungscodes. Admins legen fest, welche Rollen sie nutzen müssen; neue Installationen verlangen sie für Admins.
• Single Sign-on. Benutzer können sich über Microsoft Entra ID, Okta, Keycloak, Google Workspace, ADFS oder jeden OpenID-Connect-Anbieter anmelden (Code-Flow mit PKCE). Gruppen des Anbieters werden Rollen und Clients zugeordnet, und ein reiner SSO-Modus behält lokale Admins als Notfallzugang.
• Passwörter. Mindestens 10 Zeichen, gespeichert als PBKDF2-SHA256-Hashes. Beim ersten Start legt das Dashboard einen Benutzer admin mit zufälligem Passwort an, das bei der ersten Anmeldung geändert werden muss.
• Sperre pro Benutzer und Adresse. Nach 5 falschen Passwörtern oder Codes von einer Adresse wird der Benutzer für 15 Minuten nur von dieser Adresse gesperrt; von anderen Adressen kann er sich weiterhin anmelden.
• Drosselung bei Angriffen. Nach 20 falschen Passwörtern für einen Benutzer von allen Adressen zusammen teilen sich neue Browser auf neuen Adressen einen geprüften Versuch pro 5 Sekunden für diesen Benutzer. Das begrenzt das Raten auf etwa 12 Versuche pro Minute, egal wie viele Adressen ein Angreifer nutzt. Browser und Adressen, von denen sich der Benutzer schon angemeldet hat, werden weiterhin geprüft, das richtige Passwort funktioniert also weiter.
• Hinter einem Reverse Proxy. Setzen Sie ui.trusted.proxy auf die Adresse des Proxys, dann zählt die Sperre jede Benutzeradresse aus ihrem Header X-Forwarded-For. Ohne diese Einstellung wird der Header ignoriert.
• Sitzungen und Seiten. Sitzungen enden nach 30 Minuten ohne Nutzung. Cookies sind HttpOnly und SameSite=Strict (und unter HTTPS Secure), jedes Formular hat ein CSRF-Token, und die Seiten werden mit einer strikten Content Security Policy und X-Frame-Options: DENY ausgeliefert.

Installation und Grenzen

• Java 8u92 oder neuer unter Linux, macOS oder Windows, mit Apache Log4j 2 als einziger Abhängigkeit. Ein Heap von 256 MB reicht für die Standardeinstellungen.
• Standardmäßig lokal. Die Weboberfläche lauscht nur auf 127.0.0.1, sofern Sie nichts anderes konfigurieren. HTTPS funktioniert mit Ihrem eigenen Keystore.
• Agent-Verbindung. Ein Schlüssel pro Agent, HKDF-SHA256-Sitzungsschlüssel und AES-256-GCM, sodass eine aufgezeichnete Verbindung nicht erneut an das Dashboard gesendet werden kann.
• Dateien nur für den Eigentümer. Unter Linux und macOS kann alles, was das Dashboard in seinen Datenordner schreibt, nur das Konto lesen, unter dem es läuft, und Schlüsseldateien, die andere Benutzer lesen können, werden beim Start und als Alarm gemeldet.
• Lizenz offline geprüft. Die Lizenzdatei von BLUEGEM ist signiert und wird ohne Internetverbindung geprüft. Emona-MFT-Server und -Clients stoppen nie und ändern ihr Verhalten nicht wegen der Dashboard-Lizenz.
• Für langsame Verbindungen gebaut. Der Webserver schließt Verbindungen, die nicht innerhalb von 5 Sekunden eine vollständige Anfrage gesendet haben, und startet bei Bedarf weitere Threads, bis zu etwa 1.000 langsame Verbindungen gleichzeitig. Ist das Dashboard aus dem Internet erreichbar, schalten Sie einen Reverse Proxy (nginx, Apache, IIS) davor.
• CSV-Exporte. Höchstens zwei laufende Downloads pro Benutzer, mit einem konfigurierbaren Limit für den belegten temporären Speicher, sodass ein Konto die Festplatte nicht füllen kann.
• E-Mail. Alarme werden über ein SMTP-Relay ohne TLS gesendet; nutzen Sie daher ein Relay in Ihrem lokalen Netz.