Sicherheit & Datenschutz

Entrydeck wird von Kreativ Wolke entwickelt und betrieben — auf Servern in Deutschland, ohne Fremd-CDN, ohne Tracking auf den Produktseiten. Diese Seite fasst zusammen, wie Daten geschützt werden und welche Werkzeuge Sie selbst in der Hand haben.

Hosting

• Standort Deutschland: Rechenzentrum in Deutschland, Betrieb durch Kreativ Wolke. Keine Übermittlung in Drittländer für den Betrieb des CMS.
• Transport: TLS für alle Verbindungen (Admin, API, Skript-Auslieferung), upgrade-insecure-requests im Admin.
• Content Security Policy im Admin mit Nonce für Skripte, frame-ancestors 'none', keine Inline-Skripte ohne Nonce.
• Enterprise: Betrieb auf Ihrer Infrastruktur oder Self-Hosting.

Mandantentrennung

Jeder Kunde ist ein Mandant mit eigenen Benutzern, Rollen, Inhalten und Medien. Alle Datenbankabfragen sind an den Mandanten gebunden; die Delivery API antwortet nur mit Inhalten, die der authentifizierten Website zugewiesen sind. Ein gefälschter x-site-host-Header ohne Plattform-Schlüssel wird ignoriert.

Rollen und Rechte

Rechte hängen an Rollen, nicht an Personen. Eine Rolle bündelt Rechte wie content.publish, pages.edit, media.delete, settings.manage — je Website und Inhaltstyp einschränkbar. Typische Rollen: Redaktion (anlegen, bearbeiten, zur Prüfung geben), Chefredaktion (freigeben, veröffentlichen), Administration (Einstellungen, Benutzer). Super-Admins sehen alle Mandanten und sind nur für den Betrieb gedacht.

• Änderungen an Rollen greifen bei der nächsten Anmeldung.
• Konten lassen sich sperren statt löschen — sie bleiben im Audit-Log sichtbar.
• Passwörter: mindestens acht Zeichen, gespeichert nur als bcrypt-Hash; ein neues Passwort beendet aktive Sitzungen.
• Anmeldung mit Rate-Limit (fünf Versuche je Minute); Passwort-Zurücksetzen per E-Mail-Link.

Zwei-Faktor-Authentifizierung

Jedes Konto kann unter Einstellungen → Sicherheit einen zweiten Faktor einrichten — optional je Nutzer:

1. QR-Code mit einer Authenticator-App scannen (etwa Google Authenticator, Microsoft Authenticator, 1Password).
2. Den Bestätigungscode der App eingeben — damit ist der zweite Faktor aktiv.
3. Die zehn Backup-Codes sicher ablegen; jeder gilt einmal und ersetzt die App, wenn das Gerät fehlt.

Deaktivieren geht an derselben Stelle mit Passwort und aktuellem Code. Administratoren setzen unter Einstellungen → Sicherheit die Mandanten-Richtlinie „2FA erzwingen": Dann kommt niemand ohne zweiten Faktor ins Admin. Verliert ein Nutzer sein Gerät und die Backup-Codes, setzt ein Super-Admin den zweiten Faktor in der Nutzerverwaltung zurück.

Single Sign-on

Statt Passwörtern meldet sich das Team mit dem Firmenkonto an. Unter Einstellungen → Anmeldung & SSO legen Sie einen Provider an — global (nur Super-Admin, gilt für alle Mandanten) oder je Mandant:

Bei OpenID-Connect-Anbietern hinterlegen Sie die Redirect-URI, die das Formular zum Kopieren anzeigt:

https://entrydeck.app/api/v1/auth/sso/<provider-id>/callback

Zurück in Entrydeck tragen Sie Client-ID, Client-Secret und (bei OpenID Connect) die Issuer-URL ein. Weitere Optionen je Provider:

• Domain-Whitelist: nur Konten dieser E-Mail-Domains dürfen sich anmelden.
• Neue Nutzer automatisch anlegen mit einer Standardrolle — Kollegen brauchen keine Einladung.
• „Verbindung testen" prüft die Konfiguration, bevor der Provider live geht.

Auf der Login-Seite erscheint je Provider eine Schaltfläche. Scheidet jemand aus dem Unternehmen aus, endet mit dem Firmenkonto auch der Zugriff auf Entrydeck. Passkeys sind nicht enthalten.

SAML 2.0

Entrydeck tritt als Service Provider (SP) auf. Jeder SAML-Provider bekommt eigene Adressen, die das Formular zum Kopieren anzeigt — die Metadata-URL enthält alles, was der Identity Provider braucht (Entity-ID, ACS-URL, SP-Zertifikat):

https://entrydeck.app/api/v1/auth/sso/saml/<provider-id>/metadata   (SP-Metadata, Entity-ID)
https://entrydeck.app/api/v1/auth/sso/saml/<provider-id>/acs        (Assertion Consumer Service, HTTP-POST)
https://entrydeck.app/api/v1/auth/sso/saml/<provider-id>/slo        (Single Logout)

Umgekehrt importieren Sie die IdP-Metadata per URL oder Datei — Entity-ID, SSO-/SLO-Endpunkte und Signaturzertifikate werden daraus übernommen. Mehrere Zertifikate sind erlaubt, damit die Zertifikatsrotation beim IdP ohne Unterbrechung klappt. Weitere Einstellungen:

• Attribut-Mapping: aus welchen SAML-Attributen E-Mail, Vor- und Nachname und Gruppen gelesen werden (voreingestellt auf die Entra-ID-/ADFS-Claims; „LDAP“-Vorlage für Keycloak/Shibboleth).
• Gruppen → Rollen: Gruppenname oder Gruppen-ID aus dem IdP wird einer Entrydeck-Rolle zugeordnet. Die Zuordnung wird bei jedem Login abgeglichen; manuell vergebene Rollen bleiben unberührt.
• AuthnRequests signieren mit dem automatisch erzeugten SP-Schlüsselpaar (der private Schlüssel liegt verschlüsselt in der Datenbank), signierte Assertions verlangen, Toleranz für Zeitabweichungen.
• „Verbindung testen“ öffnet die Anmeldung beim IdP in einem neuen Tab und zeigt danach die gelieferten Attribute, Gruppen und die daraus abgeleiteten Rollen an — ohne jemanden anzumelden oder anzulegen.

Sicherheit: Jede Response muss vom IdP signiert sein (Response oder Assertion), Audience, Issuer, Zeitfenster und Zuordnung zum gestarteten Login (InResponseTo, signierter RelayState plus Cookie) werden geprüft, jede Assertion wird nur einmal akzeptiert. Die 2FA-Pflicht des Mandanten gilt für SAML-Logins genauso wie für OpenID Connect; ein Logout, das der IdP auslöst (Single Logout), beendet die Entrydeck-Sitzungen des Kontos.

#### Entra ID per SAML anbinden

1. Entrydeck: Unter *Einstellungen → Anmeldung & SSO* einen Anbieter vom Typ SAML 2.0 anlegen (Name, ggf. Mandant, erlaubte Domains) und speichern. Danach stehen Entity-ID, ACS-URL und Metadata-URL zum Kopieren bereit.
2. Entra Admin Center: *Unternehmensanwendungen → Neue Anwendung → Eigene Anwendung erstellen* (nicht aus dem Katalog) → *Single Sign-on → SAML*. In der *SAML-Basiskonfiguration* die Entity-ID als Bezeichner und die ACS-URL als Antwort-URL eintragen (alternativ die SP-Metadata-Datei hochladen).
3. Entra ID → Attribute & Ansprüche: Die Standard-Claims (emailaddress, givenname, surname) belassen; bei Bedarf einen Gruppenanspruch hinzufügen (Gruppen, die der Anwendung zugewiesen sind; Quellattribut *Gruppen-ID* oder *sAMAccountName*/*Cloud-Anzeigename*). Unter *SAML-Zertifikate* die App-Verbundmetadaten-URL kopieren.
4. Entrydeck: Im Anbieter die Metadata-URL einfügen und *Aus URL importieren* — Entity-ID, SSO-URL und Zertifikat werden gefüllt. Optional Gruppen → Rollen zuordnen (Gruppen-ID bzw. Name aus Schritt 3), „Konten automatisch anlegen“ mit Rolle wählen, aktiv schalten und speichern.
5. Prüfen: In Entra der Anwendung Benutzer oder Gruppen zuweisen, dann in Entrydeck „Verbindung testen“ — der neue Tab zeigt E-Mail, Namen, Gruppen und Rollen aus der Assertion. Stimmt alles, erscheint der Login-Button auf der Anmeldeseite (bei Mandanten-Anbietern nach Eingabe einer passenden E-Mail-Adresse oder über die Mandanten-Domain).

Persönliche API-Tokens

Für die Kommandozeile und eigene Skripte legt jeder Nutzer unter *Einstellungen → API-Tokens* persönliche API-Tokens an — vergleichbar mit Personal Access Tokens bei GitHub.

• Anlegen nur mit Re-Authentifizierung: Passwort oder 2FA-Code; der Klartext edk_… wird genau einmal angezeigt. Gespeichert wird nur ein SHA-256-Hash, der Vergleich läuft in konstanter Zeit.
• Rechte: höchstens die eigenen — optional auf einzelne Berechtigungen beschränkt (z. B. nur content.read). Sind Rollen später enger, gilt automatisch die Schnittmenge.
• Ablauf und Widerruf: 30, 90, 365 Tage oder unbegrenzt; jedes Token ist einzeln widerrufbar, maximal 20 aktive Tokens je Nutzer. Gesperrte Konten können keine Tokens mehr nutzen.
• Begrenzter Wirkungskreis: Mit einem API-Token lassen sich weder Passwort noch Zwei-Faktor ändern, keine Nutzer verwalten und keine weiteren Tokens anlegen oder löschen. Solche Versuche werden abgewiesen und protokolliert.
• Nachvollziehbar: Zeitpunkt und IP der letzten Nutzung stehen beim Token; Anlegen, Widerruf und abgewiesene Zugriffe erscheinen im Audit-Log (auth.token.create, auth.token.revoke, auth.token.used_denied). Tenant-Administratoren sehen die Tokens ihres Mandanten als Metadaten.
• Unabhängig von der Browser-Sitzung: Anders als das Refresh-Token beendet ein API-Token keine Sitzung und wird von einer neuen Anmeldung nicht ersetzt.

Audit-Log

Wer hat wann was geändert: Das Protokoll wird automatisch geschrieben und lässt sich nicht bearbeiten. Einträge enthalten Benutzer, Aktion, Objekt, Zeitpunkt und bei vielen Aktionen die geänderten Felder mit Vorher/Nachher. Filter nach Benutzer, Aktion und Zeitraum. Das Protokoll erklärt, was passiert ist — wiederherstellen muss man im jeweiligen Editor.

Schlüssel und Secrets

• API-Keys je Website, jederzeit neu erzeugbar; der alte verliert sofort seine Gültigkeit.
• Add-on-Secrets (SmartCaptcha, Hellolead) werden verschlüsselt gespeichert und nach dem Speichern nie wieder im Klartext angezeigt.
• Sitzungen laufen über signierte, ablaufende Tokens; die Abmeldung beendet die Sitzung.

Backups

Die Datenbank wird täglich automatisch auf dem Server gesichert. Mit eigenem S3-Bucket verantworten Sie die Sicherung der Medien selbst — oder wir richten die Versionierung des Buckets mit Ihnen ein.

Logs

Die Zugriffs- und Fehlerprotokolle des Webservers werden täglich rotiert und nach 14 Tagen gelöscht. Sie dienen der Fehlersuche und der Abwehr von Angriffen (Art. 6 Abs. 1 lit. f DSGVO). Es gibt keine Nutzungsprofile und keine Weitergabe.

Datenschutz auf den Produktseiten

Die Produktseiten unter entrydeck.app und consentdeck.app laden nichts von Dritten, setzen keine Cookies, für die eine Einwilligung nötig wäre, und binden Schriften lokal ein. Deshalb gibt es dort kein Einwilligungsbanner. Details in der Datenschutzerklärung.

Datenschutz in Consentdeck und im Widget

• Consentdeck speichert je Entscheidung einen Tages-Hash der IP, nie die IP selbst; keine Profile, keine Weitergabe; Aufbewahrung einstellbar, ältere Einträge werden automatisch gelöscht. Details unter Consentdeck.
• Accessdeck, das Barrierefreiheits-Widget, speichert Einstellungen ausschließlich im Browser des Besuchers, ohne Cookies und ohne Anfrage an Dritte.
• Formular-Einsendungen enthalten personenbezogene Daten. Löschen ist je Eintrag möglich; Benachrichtigungen gehen nur an hinterlegte Adressen.

Auftragsverarbeitung

Auf Wunsch schließen wir einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO mit Ihnen ab, inklusive Verzeichnis der technischen und organisatorischen Maßnahmen und der Liste der Subunternehmer (Rechenzentrum). Fragen Sie ihn über das Kontaktformular an.

Sicherheitsmeldungen

Wer eine Schwachstelle findet, meldet sie bitte über das Kontaktformular. Wir melden uns zurück und geben Bescheid, sobald die Lücke geschlossen ist.