Sicherheit & Datenschutz für IT-Teams

Diese Seite richtet sich an die Menschen, die CalDAVconnect freigeben müssen: IT-Administratoren, Sicherheitsteams und Datenschutzbeauftragte. Sie beschreibt, was der Dienst speichert, wie diese Daten geschützt sind und was er nicht tut. Die rechtlichen Dokumente - Datenschutzerklärung, AGB und Auftragsverarbeitungsvertrag (Art. 28 DSGVO) - liegen auf Deutsch und Englisch vor.

In einem Absatz: CalDAVconnect synchronisiert Kalender zwischen einem CalDAV-Server und Google Calendar oder Microsoft 365. Gespeichert werden die Zugangsdaten für beide Seiten und zu jedem synchronisierten Termin eine verschlüsselte Kopie seines letzten bekannten Zustands, damit Änderungen und Konflikte erkannt werden können. Alles Sensible ist mit AES-256-GCM verschlüsselt, die Schlüssel liegen auf einem separaten Server. Gehostet wird ausschließlich bei Hetzner in Deutschland. Deine Kalender bleiben das führende System - CalDAVconnect hält eine Zuordnung, nicht die Originaldaten.

Was gespeichert wird - und was nicht

Pro Benutzerkonto: Name, E-Mail-Adresse und ein bcrypt-gehashtes Passwort. Zwei-Faktor-Authentifizierung (TOTP) steht zur Verfügung.

Pro Verbindung:

Die URL des CalDAV-Servers, Benutzername und Passwort (verschlüsselt). Wo der Server es anbietet, empfehlen wir ein App-spezifisches Passwort.
Bei Google oder Microsoft: die OAuth-Access- und Refresh-Tokens (verschlüsselt) sowie die E-Mail-Adresse des verbundenen Kontos.
Die Kalenderliste beider Seiten mit Namen, URLs bzw. IDs und Änderungsmarken.

Pro synchronisiertem Termin:

Die Kennungen des Termins auf beiden Seiten (CalDAV-UID und -URL, Google- bzw. Microsoft-Event-ID).
Eine verschlüsselte Kopie des zuletzt synchronisierten Zustands - Titel, Zeiten, Beschreibung, Ort, Teilnehmer - der Schatten. Er macht die bidirektionale Änderungserkennung und die Drei-Wege-Konfliktauflösung möglich.
Ein SHA-256-Hash der bereinigten Termindaten für die schnelle Änderungserkennung. Der Hash ist nicht umkehrbar und enthält keinen Klartext.

Ein Sync-Protokoll hält Aktion (angelegt, geändert, gelöscht), Richtung und technische Kennungen mit Zeitstempel fest.

Nicht gespeichert, nicht abgerufen: E-Mails, Kontakte, Dateien oder Kalender, die nicht als Paar verbunden sind. Es gibt keine Auswertung von Termininhalten. Termindaten werden ausschließlich verarbeitet, um sie auf die andere Seite eines Paars zu schreiben.

Verschlüsselung

Übertragung. Alle Verbindungen laufen über TLS: die Webanwendung, der CalDAV-Server, die APIs von Google und Microsoft. Die Zertifikatsprüfung ist standardmäßig aktiv; sie lässt sich pro Verbindung nur für selbstsignierte Zertifikate auf privaten Servern wie einem NAS abschalten.

Speicherung. CalDAV-Passwörter, OAuth-Tokens und die Termin-Schatten sind mit AES-256-GCM verschlüsselt. Der Schlüssel ist vom Anwendungsschlüssel des Frameworks getrennt - eine Kompromittierung der Session- oder Cookie-Verschlüsselung legt keine Zugangsdaten offen.

Schlüsselverwaltung. Der Datenschlüssel selbst liegt nur in verpackter Form vor: verschlüsselt mit einem Schlüsselverschlüsselungsschlüssel, der auf einem separaten Server in einem privaten Netz liegt und nur vom Anwendungsserver erreichbar ist. Die Anwendung holt ihn beim Start und hält ihn im Arbeitsspeicher. Eine Kopie der Datenbank - oder eines Backups - ist ohne Zugriff auf dieses zweite System wertlos.

Zugriff auf deine Kalender

CalDAVconnect fragt die minimalen Berechtigungen an, die zum Lesen und Schreiben von Terminen nötig sind.

Google Calendar: https://www.googleapis.com/auth/calendar (Kalender lesen und schreiben) sowie openid email, nur um anzuzeigen, welches Konto verbunden ist. Keine Berechtigungen für Gmail, Drive oder Kontakte.

Microsoft 365 / Outlook.com: Calendars.ReadWrite, User.Read (Anzeigename und Adresse des verbundenen Kontos), MailboxSettings.Read (die Zeitzone des Postfachs, nötig für korrekte Serientermine) und offline_access (Refresh-Token). Keine Berechtigungen für E-Mail, Dateien oder Kontakte.

CalDAV: Deine Zugangsdaten werden nur für die Kalendersammlungen verwendet, die du als Paar verbindest. Der Client prüft Weiterleitungsziele und verbindet sich nicht zu Adressen in privaten Netzen.

Push-Benachrichtigungen von Google und Microsoft werden über ein geheimes Token pro Kanal verifiziert. Die Benachrichtigungen selbst enthalten keine Termininhalte - sie signalisieren nur, dass sich etwas geändert hat; die Daten werden anschließend über die API geholt.

Privatsphäre-Modi begrenzen, was den Quellkalender verlässt. Pro Paar kannst du wählen, ob alle Details synchronisiert werden, ob der Titel durch „Busy“ (oder einen selbst gewählten Text) ersetzt wird und nur der Organisator sichtbar bleibt, oder Strikt: nur Frei/Belegt-Blöcke, kein Titel, keine Details, kein Organisator. Bei sensiblen Kalendern sieht die Cloud-Seite dann nie mehr als das Zeitfenster.

Anmeldung: Single Sign-on und Zwei-Faktor-Authentifizierung

Single Sign-on (OpenID Connect 1.0). Nutzer können sich mit ihrem Google-Workspace-Konto anmelden. CalDAVconnect ordnet das Konto über die vom Identitätsanbieter verifizierte E-Mail-Adresse zu, bindet es an die Subject-Kennung des Anbieters (eine spätere Änderung der E-Mail-Adresse kann so nicht zur Kontoübernahme genutzt werden) und legt noch nicht vorhandene Konten bei der ersten Anmeldung an - nachdem die Bedingungen akzeptiert wurden. Für SSO-Nutzer setzt dein Identitätsanbieter die Mehrfaktor-Authentifizierung durch, nicht CalDAVconnect; der lokale zweite Faktor wird nicht abgefragt. Für die Anmeldung fordert CalDAVconnect nur die Scopes openid email profile an; das ist unabhängig von der oben beschriebenen Kalender-Autorisierung. SAML 2.0 wird nicht unterstützt. Organisationen können Anmeldung und Kontoanlage auf ihre eigenen Domains beschränken (geprüft wird der hd-Claim von Google Workspace, nicht nur die E-Mail-Adresse) und Single Sign-on verpflichtend machen; Passwort-Login und Passwort-Zurücksetzen werden für ihre Mitglieder dann abgelehnt - siehe Teams unten.

Passwort-Login. Passwörter haben mindestens 12 Zeichen und werden bei der Vergabe gegen bekannte Datenlecks geprüft (Have I Been Pwned, k-Anonymität: nur die ersten fünf Zeichen des SHA-1-Hashes verlassen den Server, das Passwort selbst nie). Gespeichert werden sie als bcrypt-Hashes. Der Login ist pro Konto und pro IP-Adresse ratenbegrenzt; jeder Nutzer kann einen zweiten Faktor (TOTP, mit Wiederherstellungscodes) aktivieren. Sitzungen sind cookiebasiert, Secure, HttpOnly und SameSite=Lax.

Teams: Mitglieder, Rollen und automatisierte Einrichtung

Organisation und Rollen. Jedes Konto gehört zu einer Organisation mit einem Inhaber (dem Rechnungskontakt, der weder entfernt noch herabgestuft werden kann), Admins und Mitgliedern. Inhaber und Admins sehen alle Mitglieder mit Anmeldeverfahren, letztem Login und dem Zustand ihrer Verbindungen, ändern Rollen und entfernen Mitglieder zentral. Das Entfernen deprovisioniert das Konto: Seine Verbindungen stoppen, Cloud-Webhooks werden abgemeldet, OAuth-Tokens widerrufen und die gespeicherten Zugangsdaten gelöscht. Mitglieder sehen und verwalten nur ihre eigenen Verbindungen; jeder Zugriff auf eine Verbindung wird serverseitig von einer Autorisierungs-Policy geprüft, nicht nur in der Oberfläche ausgeblendet.

Einladungslinks. Admins erstellen Einladungslinks (offene Links mit maximaler Nutzungszahl oder persönliche Links für eine Adresse), jeweils mit Ablaufdatum. Gespeichert wird nur ein Hash des Link-Tokens. Wer einen Link öffnet, meldet sich mit dem Google-Konto seiner Organisation an und landet direkt in der Organisation; für Mitglieder wird nie eine eigene Organisation angelegt.

Login-Domains und SSO-Pflicht. Eine Organisation kann ihre Login-Domains hinterlegen. Dann dürfen nur Identitäten dieser Domains beitreten oder sich anmelden, eine Passwort-Registrierung mit einer solchen Adresse wird auf den Einladungslink verwiesen, und mit Single Sign-on verpflichtend werden Passwort-Login und Passwort-Zurücksetzen für alle Mitglieder abgelehnt. Wer die Organisation verlässt, verliert den Zugang über deinen Identitätsanbieter; das Entfernen in CalDAVconnect löscht zusätzlich die Daten.

Geführtes Setup. Mitglieder einer Organisation mit vorkonfiguriertem Kalenderserver bekommen statt des Assistenten ein zweistufiges Setup: Der Server ist vorausgefüllt, die Hauptkalender werden automatisch in beide Richtungen gekoppelt und die erste Synchronisierung startet sofort.

Nextcloud ohne App-Passwörter. Für Nextcloud nutzt das geführte Setup den Nextcloud Login Flow v2: Das Mitglied meldet sich in einem neuen Tab bei Nextcloud an (auch über euer SSO, z. B. SURFconext), und Nextcloud stellt CalDAVconnect ein App-Passwort aus. Niemand tippt oder kopiert ein Passwort; das App-Passwort erscheint in den Nextcloud-Sicherheitseinstellungen des Mitglieds als „CalDAVconnect“ und kann dort jederzeit widerrufen werden. Der Flow wird nur gegen öffentliche Hostnamen gestartet, und Login- wie Poll-Endpunkt müssen auf demselben Host liegen wie der konfigurierte Server.

Google Workspace ohne Zustimmungsdialog (domainweite Delegierung). Statt dass jedes Mitglied CalDAVconnect im Google-Zustimmungsdialog autorisiert, kann eine Organisation ein Google-Dienstkonto hinterlegen (die Schlüsseldatei wird wie Passwörter mit dem Credential-Key verschlüsselt gespeichert und nie wieder angezeigt). Euer Workspace-Admin autorisiert die Client-ID des Dienstkontos in der Admin-Konsole für den einzigen Scope https://www.googleapis.com/auth/calendar. CalDAVconnect erzeugt dann pro Mitglied ein kurzlebiges Zugriffstoken, signiert mit dem Dienstkonto-Schlüssel und begrenzt auf den Kalender dieses Mitglieds; Refresh-Tokens werden für diese Konten nicht gespeichert. Mitglieder, die Google bereits selbst verbunden haben, behalten ihre eigene Autorisierung. Das Entfernen des Dienstkontos schaltet die Delegierung für alle auf einmal ab.

Hosting und Unterauftragsverarbeiter

CalDAVconnect läuft bei der Hetzner Online GmbH in Nürnberg - der Anwendungsserver ebenso wie der separate Schlüsselserver. Tägliche PostgreSQL-Backups gehen in den Hetzner Object Storage in Deutschland, Aufbewahrung 14 Tage. Backups enthalten dieselben verschlüsselten Felder wie die Datenbank; die zum Entschlüsseln nötigen Schlüssel sind in keinem Backup enthalten.

Unterauftragsverarbeiter gemäß Auftragsverarbeitungsvertrag:

Hetzner Online GmbH (Deutschland) - Hosting und Infrastruktur.
Lettermint (Niederlande, EU) - transaktionale E-Mails wie Registrierung und Einladungen.
Plausible Analytics (EU) - cookielose Webanalyse nur auf den öffentlichen Seiten, keine personenbezogenen Daten.
ntfy.sh (Deutschland) - Betriebsalarme an den Betreiber; die Nachrichten enthalten keine personenbezogenen Daten.
Laravel Holdings Inc. (Laravel Forge, USA, Standardvertragsklauseln) - Serverprovisionierung und Deployment. Forge kann SSH-Sitzungen auf dem Anwendungsserver öffnen, verarbeitet im Normalbetrieb aber keine personenbezogenen Daten.
Google LLC und Microsoft Corporation (USA, Standardvertragsklauseln) - nur, wenn du ein Google- oder Microsoft-Konto verbindest, und nur über deren Kalender-APIs.

Änderungen an dieser Liste werden mindestens 30 Tage im Voraus angekündigt.

Betrieb, Zugriffskontrolle und Verfügbarkeit

Der administrative Zugriff auf die Produktion ist auf den Betreiber beschränkt, über ein VPN mit SSH-Schlüsselauthentifizierung und eine Cloud-Firewall. Einziger weiterer SSH-Zugang ist der Deployment-Dienst (Laravel Forge), den die Firewall nur von dessen festen IP-Adressen zulässt. Der Schlüsselserver nimmt Anfragen nur vom Anwendungsserver an; jede Anfrage wird protokolliert.

Das Monitoring erfasst Fehler, den Zustand der Warteschlangen und die Push-Kanäle in Echtzeit; Nutzer werden per E-Mail informiert, wenn eine Verbindung wiederholt fehlschlägt oder neu autorisiert werden muss.

Patch-Management. CalDAVconnect überwacht seine Abhängigkeiten automatisch auf veröffentlichte Schwachstellen (GitHub Dependabot Alerts und Security-Update-Pull-Requests sowie ein täglicher composer audit- / npm audit-Lauf, der den Betreiber bei Funden der Schwere „high“ oder „critical“ alarmiert) und installiert Sicherheitsupdates des Betriebssystems täglich über Ubuntu unattended-upgrades auf Anwendungs- und Schlüsselserver. Schwachstellen werden innerhalb eines Arbeitstags bewertet und innerhalb von 48 Stunden (kritisch oder direkt exponiert), 7 Tagen (hoch) oder in der monatlichen Update-Runde (mittel/niedrig, spätestens nach 30 Tagen) behoben. Sicherheitspatches bleiben minimal (nur betroffene Pakete), durchlaufen die vollständige automatisierte Testsuite (~1.670 Tests) und werden ohne Wartungsfenster per atomarem Release-Wechsel ausgerollt. Kernel- und libc-Updates werden spätestens 14 Tage nach Verfügbarkeit per Neustart aktiviert; eine wöchentliche Prüfung meldet ausstehende Neustarts. Ausnahmen werden mit Grund, kompensierender Maßnahme und Zieldatum dokumentiert. Letzte vollständige Prüfung der Abhängigkeiten: 15. September 2026, keine offenen Advisories. Die schriftliche Richtlinie stellen wir auf Anfrage bereit.

Incident Response. Vorfälle werden über Echtzeit-Push-Alarme (SSH-Logins, kritische Anwendungsfehler, Warteschlangen, Authentifizierungsfehler am Schlüsselserver), Anwendungs-Monitoring, Schwachstellen-Alerts und Kundenmeldungen erkannt. Jeder Vorfall wird in einem internen Register mit Erkennungszeitpunkt, Schwere (S1–S4), Umfang, Ursache, Behebung und informierten Stellen erfasst. Zur Eindämmung stehen das Pausieren einzelner Verbindungen, ein Release-Rollback, der Widerruf von OAuth-Tokens, die Rotation des Schlüsselserver-Tokens (stoppt sofort jede Entschlüsselung) und die Isolation von Servern zur Verfügung. Betroffene Kunden werden per E-Mail informiert; eine Verletzung des Schutzes personenbezogener Daten wird dem Kunden unverzüglich und innerhalb von 72 Stunden nach Bekanntwerden mit den Inhalten nach Art. 33 Abs. 3 DSGVO gemeldet, und der zuständigen Aufsichtsbehörde, soweit CalDAVconnect Verantwortlicher ist. S1/S2-Vorfälle erhalten innerhalb von 7 Tagen ein schriftliches Post-Mortem. Die Prozedur stellen wir auf Anfrage bereit.

Verfügbarkeit, offen gesagt: CalDAVconnect läuft auf einem einzelnen Anwendungsserver mit täglichen Backups; einen Hot-Standby gibt es nicht. Handhabbar macht das der Umstand, dass CalDAVconnect kein führendes System ist. Deine Termine liegen in deinem CalDAV-Server und bei Google oder Microsoft. Ist der Dienst nicht erreichbar, pausiert die Synchronisation und holt danach anhand der Änderungsmarken inkrementell auf - nichts geht verloren, nichts muss wiederholt werden.

Daten löschen

Eine Verbindung löschen stoppt die Push-Kanäle bei Google bzw. Microsoft und entfernt sofort ihre Zugangsdaten, Tokens, Kalenderliste, Terminzuordnungen, Schatten und das Sync-Protokoll.
Ein Konto löschen entfernt all das für sämtliche Verbindungen sowie die Benutzer- und Organisationsdatensätze. Einladungsdatensätze werden anonymisiert.
Backups verfallen nach 14 Tagen.
Tokens beim Anbieter: Gelöschte Tokens kann CalDAVconnect nicht mehr verwenden. Zur Sicherheit kannst du den Zugriff der App zusätzlich in deinem Google-Konto oder Microsoft-Konto widerrufen.
Ausstieg und Export: Weil deine Kalender das führende System sind, erfordert ein Ausstieg keine Datenmigration - die Kalender bleiben auf beiden Seiten vollständig, die Synchronisation endet einfach. Auf Anfrage stellen wir vor der Löschung einen maschinenlesbaren JSON-Export der Konfiguration und Sync-Historie deiner Organisation bereit (Nutzer und Rollen, Verbindungen, Kalenderlisten, Kalenderpaare mit Einstellungen, Terminzuordnungen, Sync-Protokoll). Der Export enthält bewusst keine Zugangsdaten, Tokens oder verschlüsselten Terminkopien.

Fragen

Sicherheitsfragebögen, Lieferantenbewertungen oder konkrete Fragen deiner Datenschutzbeauftragten: Schreib an support@caldavconnect.de. Die Antwort kommt von der Person, die das System betreibt.