Sicherheit, die Sie vor Vertragsabschluss prüfen können.

• Hetzner Cloud mit deutschen Rechenzentren in Falkenstein/Sachsen und Nürnberg/Bayern
• ISO 27001 zertifiziert (physische Sicherheit, biometrische Zutrittskontrolle, 24/7-Bewachung, Videoüberwachung)
• Keine Datenübermittlung außerhalb der EU. Keine US-Cloud-Provider, kein CLOUD-Act-Risiko.
• Backups bleiben innerhalb der Hetzner-Infrastruktur in Deutschland

Eine der häufigsten Schwächen in Multi-Tenant-SaaS-Systemen ist Cross-Tenant-Leakage: ein Bug in der Anwendung, und plötzlich sehen Träger A die Daten von Träger B. Bei uns nicht. Wir trennen Mandanten auf zwei Ebenen:

Schicht 1: Anwendungs-Layer

Subdomain → Tenant-ID-Auflösung in der Middleware. Jeder Request landet im richtigen Tenant-Kontext. Wenn das fehlschlägt, wäre noch nichts passiert — die zweite Schicht greift.

Schicht 2: Datenbank-Layer

PostgreSQL Row-Level Security auf jeder einzelnen Datentabelle, mandantengetrennt via tenant_id. Der Anwendungs-User bknl_app hat kein SUPERUSER-Recht und kein BYPASSRLS-Privileg — er kann die Policies nicht umgehen, selbst wenn er wollte.

Konkret: Selbst wenn ein Bug in unserem Code einen SQL-Query ohne Tenant-Filter abschickt, gibt die Datenbank keine fremden Daten heraus. Die Policy verlangt einen gültigen Tenant-Kontext (per SET LOCAL app.current_tenant_id). Ohne Kontext: 0 Zeilen. Mit falschem Kontext: 0 Zeilen.

Verifikation

Automatisierte Cross-Tenant-Access-Tests in der Test-Suite. Vor jedem Release wird verifiziert, dass kein einziger Endpoint einer Rolle in Tenant A Daten aus Tenant B liefert. Die Test-Suite läuft im CI/CD und in der Versionsfreigabe-Prüfung.

Verschlüsselung at Rest

• Server-Disk vollverschlüsselt mit LUKS
• Backups AES-256 verschlüsselt
• Passwörter mit Bcrypt (12 Salt-Runden, one-way)

Verschlüsselung in Transit

• TLS 1.3 erzwungen, kein Fallback auf älteres TLS
• HSTS mit max-age=31536000, includeSubDomains, preload
• Automatische Zertifikate über Let's Encrypt (Caddy)

Session-Sicherheit

• Session-Cookies HttpOnly, Secure, SameSite=Lax
• 256-Bit zufällig erzeugte Tokens
• Rate-Limit gegen Brute-Force-Login (5 Versuche / 15 Min)

• Externer Datenschutzbeauftragter wird vor Echtbetrieb benannt. Kontakt-Postfach: datenschutz@bknl.de
• ISB (Informationssicherheitsbeauftragter): Rudolf Wagner intern. Verantwortlich für ISMS und technische Sicherheit.
• Zuständige Aufsichtsbehörde: Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Rheinland-Pfalz (LfDI RLP), Prof. Dr. Dieter Kugelmann — der gleichzeitig den Vorsitz der KI-Taskforce der Datenschutzkonferenz innehat. Wir sind also unter der Aufsicht eines der bundesweit führenden Experten zur KI-Compliance.

Sie erhalten alle diese Dokumente bevor Sie unterschreiben:

• AVV-Mustervertrag nach Art. 28 DSGVO — Auftragsverarbeitung. Online einsehen
• TOM-Liste (Technische und Organisatorische Maßnahmen) — Anlage 1 zur AVV nach Art. 32 DSGVO
• DPIA — Datenschutz-Folgenabschätzung speziell für Kinderdaten (Art. 35 DSGVO)
• Verarbeitungsverzeichnis nach Art. 30 DSGVO — Teil A (BKNL) und Teil B (Träger-Vorlage)
• ISMS-Sicherheitskonzept — orientiert an BSI-Grundschutz und ISO 27001
• Incident-Response-Plan — mit 24h-Meldekette an Aufsichtsbehörde
• Backup-Konzept — 3-2-1-Regel, RTO 4h, RPO 1h, vierteljährliche Restore-Tests
• Zugriffsmanagement-Konzept — RBAC mit 6 Rollen, MFA-Empfehlung, Audit-Logging

Bei Interesse: info@bknl.de — wir schicken Ihnen die Sammlung als PDF zu.

KI-Pentesting kontinuierlich

Statische Code-Analyse (Bandit, Semgrep) und Dependency-Vulnerability-Scanning (pip-audit) bei jedem Commit. Erkennt SQL-Injection, XSS, CSRF, unsichere Patterns.

Jährlicher externer Pentest

Durch unabhängige Sicherheitsexperten (Kandidaten: SySS, usd AG, mgm Security Partners). Erster externer Pentest vor Echtbetrieb in Q3 2026. Bericht für Träger einsehbar.

Bug-Bounty-Programm

security@bknl.de — verantwortlicher Umgang mit Responsible Disclosure. Belohnungen für ernsthafte Findings nach Schweregrad.

BSI-Grundschutz

Selbsterklärung in Vorbereitung (Q4 2026). ISO 27001 Zertifizierung perspektivisch 2027.

Wir nutzen KI ausschließlich für interne Sicherheitsmaßnahmen (Code-Review, Vulnerability-Detection). Niemals für Profiling von Kinderdaten, Verhaltens-Analyse oder automatische Entscheidungen über Personen.

KI-Übersetzung — vollständig lokal, kein Drittland

Die optionale Übersetzung von Aushängen / Nachrichten in die bevorzugte Elternsprache läuft als lokales Sprachmodell (Ollama, gemma2:2b) auf demselben Hetzner-Server. Keine API zu OpenAI, Anthropic, Google, Azure oder anderen Anbietern. Texte verlassen den Server zu keinem Zeitpunkt.

• Opt-in pro Träger über die App-Einstellungen — der Träger kann die Funktion jederzeit aktivieren oder deaktivieren.
• 16 Zielsprachen (DE, EN, TR, AR, RU, FR, ES, IT, PL, RO, SQ, SR, UK, FA, PT, VI).
• Per-Nachricht-Cache in der Tenant-Datenbank — jede Sprache nur einmal übersetzt.
• Kein Profiling, keine Bewertung, keine automatisierte Entscheidung — das Modell führt ausschließlich eine textuelle Übertragung durch.

Unsere Aufsichtsbehörde — der LfDI Rheinland-Pfalz, Prof. Dr. Dieter Kugelmann — führt den Vorsitz der KI-Taskforce der Datenschutzkonferenz. Wir sind also unter der Aufsicht eines der bundesweit führenden Experten zur KI-Compliance. Das ist für uns Verpflichtung, nicht nur Schmuck.

3-2-1-Regel

• 3 Kopien der Daten (Produktion + Hot-Backup + Cold-Backup)
• 2 verschiedene Medien (SSD Produktion, Object-Storage Backup)
• 1 Offsite-Kopie (zweiter Hetzner-Standort)

RTO & RPO

RTO (Recovery Time Objective): 4 Stunden — maximale Zeit zur Wiederherstellung des Service nach einem Totalausfall.

RPO (Recovery Point Objective): 1 Stunde — maximaler Datenverlust im Notfall. Stündliche DB-Dumps + tägliche Snapshots.

Backup-Restore-Procedure dokumentiert und vierteljährlich getestet.