ActiSignal

Das Projekt in einem Absatz

ActiSignal ist unser eigenes Produkt: ein System zum Monitoring der Mitarbeiteraktivität und des Zustands von Firmenrechnern unter Windows. Es besteht aus einem Agent, der als Windows-Dienst läuft, einer ASP.NET-Core-API mit PostgreSQL, einer App für die Administratoren des Kunden, einer internen Konsole für den Betrieb des Dienstes und einer Produktwebsite in Next.js. Alles ist um eine Prämisse herum gebaut: einem Unternehmen zeigen, was es zur Arbeitsorganisation und zum Betrieb seiner Rechner braucht — und genau dort aufhören, wo die Privatsphäre der Mitarbeiter beginnt.

Das Problem: Transparenz ohne Überwachung

Software zur Mitarbeiterüberwachung hat einen schlechten Ruf, und das nicht ohne Grund. Viele Werkzeuge machen alle paar Minuten Screenshots, protokollieren Tastenanschläge und speichern jede vollständige URL. Dieser Umfang ist unter DSGVO und Arbeitsrecht schwer zu rechtfertigen und erzeugt Misstrauen im Team.

Dabei sind die meisten Fragen eines Inhabers oder einer IT-Abteilung viel einfacher: Hat die Arbeit begonnen, wie lange wurde der Rechner genutzt, werden bezahlte Lizenzen verwendet, welcher Laptop meldet seit einer Woche nichts. Keine davon erfordert, den Bildschirminhalt zu kennen.

Deshalb erfasst ActiSignal Metadaten, keine Inhalte — und das ist keine Einstellung, die sich umschalten lässt, sondern eine Grenze in der Architektur. Code, der einen Fenstertitel oder getippten Text lesen könnte, existiert schlicht nicht.

Architektur — vier Anwendungen, eine API

Windows-Agent (Dienst + Sitzungsprozess)  ──HTTPS──┐
Admin-App des Kunden (WPF)                ──HTTPS──┤
Web-Panel des Kunden (Next.js, BFF)       ──HTTPS──┼──>  API (ASP.NET Core)  ──>  PostgreSQL
Betreiberkonsole des Dienstes (WPF)       ──HTTPS──┘

Das Backend folgt Clean Architecture: Domain (Entitäten und Regeln, ohne Abhängigkeiten), Application (jede Operation als expliziter Use Case), Infrastructure (EF Core, PostgreSQL, Sicherheit) und Api als Composition Root. Der Agent folgt derselben Disziplin: Logik und Zustandsautomaten liegen in einem Projekt, das ohne Windows testbar ist, Win32-, SQLite- und HTTP-Aufrufe in einer eigenen Infrastrukturschicht.

Von Anfang an haben wir zwei Welten getrennt: Kundenfunktionen (Rechner, Sitzungen und Berichte der eigenen Organisation) und Betreiberfunktionen (Organisationen, Lizenzen, Agent-Releases). Es sind zwei getrennte Apps und zwei getrennte API-Bereiche — eine Funktion der einen Seite gelangt nie in die andere.

Der Windows-Agent — Systemdienst und Prozess pro Sitzung

Ein Windows-Dienst läuft in der isolierten Sitzung 0 und sieht den Desktop des Benutzers nicht. Für jede angemeldete Sitzung startet er einen eigenen, schlanken Worker-Prozess, überwacht ihn und startet ihn bei Bedarf neu — ein fehlender Worker wird dem Panel als Problem gemeldet.

Der Worker in der Benutzersitzung gilt als nicht vertrauenswürdig: Er spricht nie mit der API, sondern übergibt Messwerte über einen lokalen, berechtigungsbeschränkten Kanal an den Dienst, wobei beide Seiten einander prüfen. Netzwerkzugang und Zugangsdaten hat nur der Dienst.

Aktive Zeit ohne Tastaturerfassung

Für die aktive Zeit genügt es zu wissen, dass der Rechner benutzt wird — nicht was getippt wurde. Der Agent fragt alle paar Sekunden das System, wie lange die letzte Interaktion her ist, und installiert keine Tastatur- oder Maus-Hooks. Der Zustand hat eine einfache Rangfolge: gesperrt > inaktiv > aktiv, Inaktivität beginnt standardmäßig nach 5 Minuten.

Website-Domains liefert eine Browsererweiterung (Edge, Chrome, Firefox), die nur den Hostnamen weitergibt. Eine Website zählt nur, solange der Browser im Vordergrund ist, Adressen werden per Public Suffix List zur registrierbaren Domain zusammengefasst, und die Funktion ist standardmäßig aus — der Administrator der Organisation schaltet sie bewusst ein.

Remote-Arbeit: keine Datenverluste, wenn der Laptop offline ist

Der Laptop eines Remote-Mitarbeiters ist manchmal stundenlang ohne Netz. Der Agent schreibt Ereignisse in eine lokale SQLite-Warteschlange und lädt sie komprimiert in Stapeln hoch, auf getrennten Kanälen für Sitzungsereignisse und Aktivität. Die Warteschlange hat feste Größen- und Altersgrenzen, und falls sie je etwas verwerfen muss, geht die Zahl der verworfenen Ereignisse im Heartbeat ans Panel — Datenverlust ist nie still. Der Server nimmt Stapel idempotent an, sodass ein erneuter Versand nach Verbindungsabbruch keine Duplikate erzeugt.

Mandantenfähigkeit, die im Zweifel verweigert

Alle Organisationen teilen ein Datenbankschema, die Isolation ist mehrschichtig: ein globaler EF-Core-Abfragefilter, der sicher fehlschlägt, wenn kein Organisationskontext gesetzt ist, ein Wächter beim Speichern, zusammengesetzte Fremdschlüssel und ein Test, der die kurze Liste der Stellen überwacht, die den Filter umgehen dürfen. Eine Id einer fremden Organisation liefert einfach 404.

Rollen, Audit und automatisches Löschen

• Rollen — Inhaber, Administrator, Analyst und Auditor, jeweils mit festen Berechtigungen.

• Audit-Log — Domänenereignisse in derselben Transaktion wie die Änderung, in einer Tabelle, an die nur angehängt wird. Selbst das Lesen der Aktivität einer Person wird protokolliert.

• Aufbewahrung — die Organisation wählt 30, 90, 180 oder 365 Tage für Rohdaten. Ein Hintergrundjob löscht sie automatisch, übrig bleiben nur aggregierte Tageswerte.

• Admin-Anmeldung — verpflichtender zweiter Faktor (TOTP) und Wiederherstellungscodes.

Einführung und Updates

Der Agent wird als MSI-Installer (WiX) ausgeliefert, den die IT still per Intune, GPO oder RMM-Tool verteilen kann. Die Geräteregistrierung nutzt ein kurzlebiges Token: Das Gerät tauscht es gegen ein eigenes, per DPAPI gespeichertes Geheimnis und dieses gegen ein kurzlebiges Zugriffstoken, das regelmäßig erneuert wird. Ein widerrufenes Gerät ist binnen etwa einer Minute gesperrt.

Updates durchlaufen Stufen — Entwurf, Pilot, Veröffentlichung mit gestaffeltem Rollout. Der Agent lädt Pakete nur von der eigenen API, prüft die Prüfsumme, und der Updater installiert nur Pakete mit gültiger digitaler Signatur.

Qualität als Teil des Produkts

• fast 60 festgehaltene Architekturentscheidungen (ADRs), die erklären, warum etwas so funktioniert,

• mehr als 11.000 Testmethoden, darunter Integrationstests gegen echtes PostgreSQL in Containern und Architekturtests, die die Abhängigkeitsrichtung prüfen,

• Compiler-Warnungen als Fehler und ein Analyzer, der direktes Lesen der Uhr an der Zeitabstraktion vorbei verbietet — so bleibt die Aufbewahrungs- und Sitzungslogik vollständig testbar.

Die Produktwebsite

actisignal.pl ist eine statisch exportierte Next.js-16-Website auf Polnisch und Englisch, mit animierter Vorschau des Panels auf Beispieldaten, Preisen und ausführlichen FAQ. Analytics läuft erst nach Einwilligung (Consent Mode), und die Texte sind auf die Suchbegriffe geschrieben, mit denen Unternehmen solche Software tatsächlich suchen.

Was dieses Projekt gelehrt hat

Die wichtigste Entscheidung bei ActiSignal betraf nicht die Technologie, sondern den Datenumfang. Die Beschränkung auf Metadaten macht das Produkt leichter rechtskonform einzuführen, leichter dem Team zu erklären und leichter abzusichern — Daten, die nie erhoben werden, können nicht abfließen. Dieselbe Regel, „nur erfassen, was eine konkrete Frage beantwortet", gilt für jedes System, das Daten über Menschen verarbeitet.