Sicherheit & DSGVO.

01Architektur in einem Satz

Ein Browser im Internet spricht über eine TLS-verschlüsselte Verbindung mit der Plattform-Cloud, die wiederum eine dauerhafte, verschlüsselte Verbindung zum Vermittlungs-Agent im Kundennetz hält. Der Agent leitet die Daten weiter zum eigentlichen Zielsystem (Windows- oder Mac-Arbeitsplatz bzw. Terminalserver), das im Kundennetz steht.

Niemals besteht eine direkte Verbindung aus dem Internet zum Zielsystem. Jede Sitzung wird ausdrücklich autorisiert und protokolliert.

02Verschlüsselung der Datenübertragung

Browser ↔ Plattform-Cloud

Die Verbindung wird mit TLS (Transport Layer Security, derselbe Standard wie bei Online-Banking) in einer aktuellen Version verschlüsselt. Die Zertifikate stammen von einer öffentlichen, anerkannten Zertifizierungsstelle. Browser werden über den Sicherheits-Header HSTS angewiesen, niemals auf eine unverschlüsselte Verbindung zurückzufallen.

Plattform-Cloud ↔ Vermittlungs-Agent

Die Verbindung läuft über ein verschlüsseltes WebSocket-Protokoll (wss://). Jeder Agent authentifiziert sich gegenüber der Cloud mit einem eigenen kryptografischen Schlüssel — kompromittiert ein Angreifer einen Agent, betrifft das nur diesen einen, nicht die anderen.

Agent ↔ Zielsystem

Hier hängt das Schutzniveau am eingesetzten Zielsystem-Protokoll:

• RDP (Microsoft Remote Desktop) bringt von Haus aus moderne Verschlüsselung mit (Network Level Authentication, CredSSP). Die Plattform empfiehlt und nutzt diese.
• VNC ist in seiner Standardform unverschlüsselt. Für VNC-Verbindungen gilt deshalb die Vorgabe, dass Agent und Zielsystem im selben Vertrauensnetz liegen (gleiches LAN/VLAN, oder eine Netzwerk-Verschlüsselung dazwischen). Diese Verantwortung liegt beim Operator des Kundennetzes.

03Anmeldung & Identitätsprüfung

• Anmeldung mit E-Mail und Passwort. Passwörter werden mit dem aktuellen, NIST-empfohlenen Verfahren Argon2id verarbeitet — die Plattform speichert niemals ein Passwort im Klartext oder reversibel verschlüsselt.
• Account-Sperre nach mehreren Fehlversuchen zur Abwehr von Brute-Force-Angriffen.
• IP-basiertes Rate-Limit auf den Anmelde-, Zwei-Faktor- und Token-Erneuerungs-Endpunkten.
• Nach erfolgreichem Login erhält der Browser kurzlebige Zugangs-Tokens, die regelmäßig automatisch erneuert werden. Bei Verdacht auf Replay/Diebstahl werden alle aktuell gültigen Tokens des Kontos sofort invalidiert.
• Server-seitige Sicherheits-Header (CSP, HSTS, X-Frame-Options) schützen vor Cross-Site-Scripting, Clickjacking und ähnlichen Browser-basierten Angriffen.

04Zwei-Faktor-Authentifizierung

Jeder Account ist pflichtweise mit einem zweiten Faktor geschützt — nach dem ersten Login. Nutzer wählen zwischen zwei gleichwertigen Methoden und können beide parallel führen:

Authenticator-App (TOTP)

• Kompatibel mit gängigen Apps wie Google Authenticator, Microsoft Authenticator, Authy oder 1Password.
• Das geheime Stück, das beim Einrichten erzeugt wird, wird verschlüsselt in der Datenbank abgelegt (siehe Kapitel 09). Selbst bei Datenbankzugriff lässt es sich ohne den separaten Schlüssel nicht entziffern.

Sicherheitsschlüssel & Passkeys (WebAuthn / FIDO2)

• Unterstützt sowohl synchronisierte Passkeys (Touch ID, Face ID, Windows Hello, iCloud-Schlüsselbund, Google-Passwort-Manager) als auch Hardware-Sicherheitsschlüssel (YubiKey, Nitrokey & Co.).
• Phishing-resistent: Der Schlüssel signiert nur für die echte Portal-Adresse — moderne Phishing-Werkzeuge, die TOTP-Codes problemlos abfangen und weiterleiten, scheitern hier konstruktiv. Empfohlen für alle Nutzer mit erhöhtem Schutzbedarf.
• Der Privatschlüssel verlässt das Hardware-Modul (Secure-Enclave, TPM oder USB-Token) niemals.
• Beliebig viele Schlüssel pro Konto registrierbar — Empfehlung: Primärschlüssel + Backup-Schlüssel an räumlich getrenntem Ort.

Wiederherstellungscodes (universeller Notausgang)

• Bei der ersten 2FA-Aktivierung erhält der Nutzer einmalig 10 Wiederherstellungscodes für den Fall, dass alle Authenticators verloren gehen. Jeder Code ist nur einmal verwendbar.
• Beim Hinzufügen weiterer Schlüssel werden keine neuen Codes ausgestellt — die ursprüngliche Liste bleibt der Notausgang.

Schutz gegen Missbrauch

• Falsch eingegebene Codes (TOTP, Wiederherstellung oder Sicherheitsschlüssel-Verifikation) führen zu einer zeitweiligen Sperre. TOTP und WebAuthn teilen sich denselben Sperr-Zähler.
• Last-Factor-Schutz: Der letzte Faktor lässt sich nicht löschen, wenn dadurch kein zweiter Faktor mehr übrig wäre — die Plattform verhindert das aktiv.

05Sicherheit des Vermittlungs-Agents

Der Agent ist die Brücke zwischen Plattform-Cloud und Zielsystemen im Kundennetz. Er wird einmalig bei der Inbetriebnahme registriert:

• Erstregistrierung mit einem einmal verwendbaren Token, das nach erstem Gebrauch automatisch verbraucht und nach 24 Stunden ohnehin abgelaufen ist.
• Der Agent erzeugt sein eigenes Schlüsselpaar lokal und übermittelt nur den öffentlichen Teil an die Cloud — der private Teil verlässt den Agent-Host nie.
• Jede einzelne Verbindung des Agents zur Cloud wird mit diesem Schlüssel signiert und kann nicht erneut abgespielt werden.

06Verbindungs-Sitzungen

Wenn ein Nutzer auf einen Endpunkt verbindet, geschieht im Hintergrund:

1. Prüfung, ob der Nutzer für genau diesen Endpunkt freigeschaltet ist.
2. Erzeugung eines kurzlebigen Sitzungs-Tokens (5 Minuten Gültigkeit, einmalig verwendbar, kryptografisch zufällig).
3. Vermittlung der Verbindung an den entsprechenden Agent.
4. Eintrag im Audit-Log über den Beginn der Sitzung.

Bei Beendigung — egal ob durch Logout, Browser-Tab-Schließen oder Timeout — wird das Sitzungs-Token serverseitig sofort entwertet und das Ende ebenfalls protokolliert.

07Trennung zwischen Kundenorganisationen

Die Plattform ist mandantenfähig: mehrere Kundenorganisationen können dieselbe Installation nutzen, sehen aber niemals gegenseitige Daten.

• Jede Anfrage wird gegen die Organisations- bzw. Partner-Zuordnung des angemeldeten Nutzers geprüft.
• Die Datenbank stellt durch Fremdschlüssel-Beziehungen sicher, dass kein Datensatz „ohne Eigentümer" existieren kann.
• Endpunkte, Benutzer, Audit-Einträge und Agents einer Organisation sind außerhalb dieser Organisation prinzipiell unsichtbar.
• Diese Trennung wird durch automatisierte Tests bei jedem Software-Build verifiziert.

08Audit-Protokoll

Sicherheitsrelevante Aktionen werden lückenlos protokolliert. Beispiele:

• Anmelde-Versuche (erfolgreich / fehlgeschlagen / gesperrt)
• Aktivierung, Verifikation, Reset und Notfall-Bypass der Zwei-Faktor-Authentifizierung
• Erstellung, Änderung, Sperre und Löschung von Benutzerkonten
• Erstellung und Löschung von Endpunkten
• Beginn und Ende jeder Verbindungs-Sitzung
• Verdacht auf Token-Replay / Token-Diebstahl

Jeder Eintrag enthält Zeitstempel, Akteur, Ziel, Erfolgsstatus, IP-Adresse und einen kontextbezogenen Detail-Block. Die Aufbewahrungsdauer beträgt mindestens 365 Tage. Einträge sind aus Anwendungssicht schreibgeschützt — nachträgliches Ändern oder Löschen ist über die Benutzeroberfläche nicht möglich.

09Verschlüsselung gespeicherter Daten

Folgende Daten in der Plattform-Datenbank sind zusätzlich zur Festplatten-Verschlüsselung des Hosts auf Anwendungsebene geschützt:

Die symmetrischen Verschlüsselungsschlüssel werden vom Plattformbetreiber getrennt von der Datenbank verwaltet. Ein reiner Datenbank-Diebstahl reicht nicht aus, um z. B. TOTP-Geheimnisse zu rekonstruieren.

10Was die Plattform schützt — und was nicht

Wovor die Plattform schützt

Was außerhalb des Schutzes liegt

• Endgerät des Endnutzers: Wenn der Browser oder das Betriebssystem kompromittiert ist, kann ein Angreifer Sitzungen im Namen des Nutzers initiieren. Die Plattform erkennt das nur indirekt (anomale IP-Wechsel im Audit-Log).
• Sicherheit des Zielsystems: RDP- bzw. VNC-Zielsysteme müssen selbst aktuell gepatcht und sicher konfiguriert sein (Network Level Authentication, starke Passwörter).
• Sicherheit des Agent-Hosts: Wer auf dem Agent-Host Administrator ist, kann den Schlüssel auslesen.
• VNC-Wire-Verschlüsselung: VNC bietet protokoll-bedingt keine zuverlässige Wire-Verschlüsselung — durch die Trust-Boundary-Pflicht des Operators (gleiches LAN/VLAN) abzudecken.

11Geteilte Verantwortung

12Datenschutz & DSGVO

Verarbeitungsverhältnis

Die Plattform wird typischerweise im Auftragsverarbeitungs-Verhältnis nach Art. 28 DSGVO genutzt — der Plattformbetreiber ist Auftragsverarbeiter, der Endkunde Verantwortlicher. Ein entsprechender AV-Vertrag wird beim Vertragsabschluss bereitgestellt und ist auf Anfrage vorab verfügbar.

Welche personenbezogenen Daten verarbeitet werden

Aufbewahrungsfristen

• Audit-Protokoll: mindestens 365 Tage; danach Löschung je nach Vorgabe des Auftraggebers.
• Sitzungs-Token: sofort nach Sitzungsende ungültig; Audit-Eintrag bleibt im Rahmen der Audit-Aufbewahrung.
• Benutzerkonten: bestehen, solange das Nutzungsverhältnis besteht; physische Löschung auf Anweisung des Verantwortlichen.

Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Meldung von Datenschutzvorfällen

Im Falle eines Sicherheitsvorfalls mit potenziellem Personenbezug informiert der Plattformbetreiber den Verantwortlichen unverzüglich, sodass dieser seine Meldepflichten nach Art. 33/34 DSGVO erfüllen kann.

Sub-Auftragsverarbeiter

Die Plattform wird in einem Rechenzentrum innerhalb der EU betrieben. Die genaue Liste der Sub-Auftragsverarbeiter (Hosting-Dienstleister) wird im AV-Vertrag aktuell gehalten und dem Verantwortlichen bei Änderungen mitgeteilt.