🔐 Privacy by Design

Keine Daten.
Kein Tracking.
Kein Kompromiss.

EduSlot wurde an einer echten Schule mit echten Schülerdaten entwickelt. Datenschutz ist kein Feature – er ist die Grundlage.

Keine Klarnamen in der DB Kein Tracking, kein Analytics Selbst gehostet auf Schulserver DSGVO-Werkzeuge integriert IServ-Login – kein neues Passwort
0
Tracking-Cookies
0
Klarnamen gespeichert
0
US-Cloud-Anbieter
100%
Schulserver / Deutschland
4
DSGVO-Werkzeuge integriert

Warum EduSlot?
Mal ganz einfach.

Kein IT-Studium nötig. Kein Blick ins Handbuch. Einfach einloggen und buchen – hier erklärt, warum das an Schulen so gut funktioniert.

🏫

Stell dir vor: Du willst die Sportoase für deine 7b buchen.

Früher Zettel ausfüllen → Sekretariat → warten → vielleicht schon vergeben → neu anfangen ☹
Heute IServ-Login → Stunde anklicken → Namen eintragen → fertig. 30 Sekunden.
🔑

Kein neues Passwort

Einfach mit dem IServ-Account einloggen, den du sowieso schon hast. Fertig. Kein Extra-Konto anlegen, kein weiteres Passwort merken.

📅

Live-Kalender – immer aktuell

Du siehst sofort, welche Stunden noch frei sind – live, ohne Nachfragen. Kein Telefonieren mit dem Sekretariat, kein „ich glaube, das ist noch frei".

🙈

Schülernamen bleiben privat

Du trägst einen Namen ein – das System kürzt ihn automatisch zu „Max M." bevor er gespeichert wird. Kein Klärnamen in der Datenbank, keine DSGVO-Sorgen.

👁️

Fremde Buchungen? Nur „Belegt".

Du siehst von Kollegen-Buchungen nur „Belegt" – keinen Namen, keine Klasse, keine Details. Genau das, was Datenschutz braucht.

🖥️

Türdisplay läuft von selbst

Am Zimmer-Display siehst du nur „Belegt" oder „Frei". Keine Namen, kein Login nötig. Einfach Tablet hinzeigen – fertig.

🇩🇪

Alles bleibt in Deutschland

Die Schüler-Daten liegen auf eurer eigenen Schule oder einem deutschen Server – nicht bei Google, Amazon oder sonst einem US-Konzern. Punkt.

📧

Automatische Bestätigungs-E-Mail

Nach der Buchung bekommst du sofort eine Bestätigung per E-Mail – mit Datum, Stunde und Raum. Kein Rätseln, ob es geklappt hat.

🔒

Der Admin hat alles im Blick

Die Schulleitung oder ein Koordinator kann Stunden sperren, freigeben und verwalten – ohne in jede Klasse zu rennen oder E-Mails zu beantworten.

Vier Garantien, die zählen

🙈

Keine Klarnamen – nirgends

Schülernamen werden bereits beim Buchen automatisch zu „Vorname + Anfangsbuchstabe" gekürzt und so in der Datenbank gespeichert. Vollständige Namen gelangen weder in die DB noch in E-Mails noch auf Displays.

✓ Technisch erzwungen
🏠

Ihre Schule – Ihr Server

EduSlot läuft auf Ihrer eigenen Infrastruktur. EduSlot als Anbieter hat keinen Zugriff auf die Produktivdaten Ihrer Schule. Kein US-Cloud-Anbieter, kein Drittanbieter, keine Datenweitergabe.

✓ Self-Hosting garantiert
🚫

Null Tracking

Weder Google Analytics, Matomo noch andere Dienste. Keine Verhaltensdaten, keine Reichweitenmessung. Nur ein technisch notwendiges Session-Cookie – nach dem Logout gelöscht.

✗ Kein einziges Tracker-Cookie
🔑

IServ-Login – kein neues Passwort

Anmeldung über den bestehenden IServ-Account per OAuth 2.0. EduSlot speichert kein IServ-Passwort – nur Benutzername, E-Mail und Rolle, die IServ nach erfolgreicher Anmeldung übermittelt.

✓ Kein Passwort gespeichert

Keine Klarnamen. Wirklich keine.

„Max Mustermann" landet nie in der Datenbank.

Sobald eine Lehrkraft einen Schülernamen einträgt, wird er vom System automatisch und unwiderruflich gekürzt – bevor er die Datenbank erreicht. Das ist keine Anzeigesache. Das ist technisch erzwungen.

Max Mustermann ❌ Eingabe im Formular
abbreviate() ⚙️ System kürzt
Max M. ✅ In Datenbank gespeichert
📋
Buchungsformular: Schülernamen werden vor dem DB-Insert automatisch auf „Vorname + Initial" reduziert.
✉️
E-Mail-Bestätigungen: Enthalten nur abgekürzte Namen – an keine Lehrkraft werden Klarnamen gesendet.
🖥️
Kiosk / Türdisplay: Zeigt nur „Belegt" oder „Frei" – keinerlei Personenbezug.
👁️
Lehrkraft-Ansicht: Fremde Buchungen erscheinen ausschließlich als „Belegt" – ohne Namen, ohne Klasse.

Wer sieht was?
Schwarz auf weiß.

Jede Rolle sieht exakt das, was sie für ihren Zweck braucht – und nichts mehr. Die Einschränkungen sind serverseitig erzwungen; kein Client-seitiger Trick kann sie umgehen.

🖥️
Kiosk-Display
Öffentliches Türdisplay – anonym
Raumstatus (frei/belegt)✓ Sichtbar
Name der Lehrkraft✗ Nicht sichtbar
Klasse / Schüler✗ Nicht sichtbar
Buchungsdetails✗ Nicht sichtbar
Anmeldung erforderlich✗ Kein Login
👩‍🏫
Lehrkraft
Eigene Buchungen verwalten
Eigene Buchungen (Details)✓ Vollständig
Schülernamen (eigene Buchung)~ Nur abgekürzt
Fremde Buchungen✗ Nur „Belegt"
Fremde Schüler / Klassen✗ Nicht sichtbar
Admin-Bereich✗ Kein Zugriff
🛡️
Administrator
Datenschutzverantwortl. Stelle
Alle Buchungen★ Vollständig
Schülernamen~ Nur abgekürzt (DB)
DSGVO-Export & Löschung★ Zugriff
Nutzer- & Raumverwaltung★ Zugriff
Verantwortlichkeit★ Schulintern
💡

Hinweis zur Adminrolle: Auch Admins sehen Schülernamen nur in der bereits abgekürzten Form (z. B. „Max M."), da Klarnamen gar nicht erst in der Datenbank gespeichert werden. Die Schule als datenschutzrechtlich verantwortliche Stelle trägt die Verantwortung für den Adminzugang.

Technische Schutzmaßnahmen

Keine Versprechen auf dem Papier – konkrete Implementierungen im Code.

✂️
Automatische Namenskürzung vor DB-Speicherung

Beim Anlegen und Bearbeiten einer Buchung werden alle Schülernamen serverseitig durch abbreviate_name() verarbeitet, bevor der Datensatz in die Datenbank geschrieben wird. Die Funktion greift an allen vier Buchungspfaden (Neu-Buchung, Bearbeiten, Admin-Neu, Admin-Bearbeiten). Ein Umgehen ist technisch nicht möglich.

Technisch erzwungen – 4 Codepfade
👁️‍🗨️
Ansichts-Anonymisierung im Kalender

Fremde Buchungen werden im Wochenplan für alle Lehrkräfte serverseitig als „Belegt" ohne jede Personenangabe ausgegeben. Die Einschränkung erfolgt in der Datenbankabfrage selbst – nicht erst im Template.

Serverseitig – kein JS-Trick umgeht das
🔒
Session-Sicherheit (HttpOnly, 8h Ablauf)

Das Session-Cookie ist mit HttpOnly gesetzt (kein JavaScript-Zugriff) und läuft nach 8 Stunden automatisch ab. Das Session-Secret ist ein kryptografisch zufälliger Wert ≥ 32 Byte aus der Serverumgebung.

HttpOnly · SameSite · 8h-Ablauf
🛡️
CSRF-Schutz auf allen schreibenden Routen

Jedes Formular, das Daten verändert, enthält ein kryptografisches CSRF-Token (secrets.token_hex(32)). Requests ohne gültiges Token werden mit 403 abgewiesen.

Alle POST-Routen gesichert
🔑
Brute-Force-Schutz bei lokalem Login

Nach einer konfigurierbaren Anzahl fehlgeschlagener Anmeldeversuche wird das Konto für eine definierte Sperrzeit gesperrt. Die Zählung ist atomare DB-Operation – concurrency-safe.

Atomare DB-Sperre · Concurrency-safe
🌐
Sicherheits-HTTP-Header auf allen Responses

Alle Antworten enthalten: X-Content-Type-Options: nosniff, X-XSS-Protection, Referrer-Policy: strict-origin-when-cross-origin und Permissions-Policy. HSTS wird via Nginx am Produktions-Proxy gesetzt.

OWASP-konforme Header
🚫
Kein Tracking, kein Analytics, keine Drittdienste

Die Anwendung bindet keinerlei externe Tracking-Dienste ein. Keine CDN-Ressourcen für personenbezogene Daten. E-Mails laufen ausschließlich über den SMTP-Server Ihrer Schule.

Zero Third-Party-Tracking
🏛️
Kiosk-Token – öffentliche Displays ohne Login

Die Türanzeige (Kiosk) verwendet ein 32-Byte kryptografisches URL-Token. Es zeigt nur „Belegt" / „Frei" – keinerlei Personen- oder Buchungsdaten. Das Token kann jederzeit durch den Admin rotiert werden.

32-Byte Random · Rotierbar

Betroffenenrechte. Direkt im System.

Keine externen Tools, kein Papierformular. Admins erfüllen DSGVO-Pflichten mit einem Klick direkt im Admin-Panel.

Art. 15 & 20 DSGVO

📦 Datenexport (JSON)

Auf Antrag vollständiger Export aller Nutzerdaten als strukturierte JSON-Datei – maschinenlesbar, mit Rechtsgrundsatz-Hinweis und Exportzeitpunkt.

Art. 17 DSGVO

🧹 Pseudonymisierung

Benutzername, E-Mail, Lehrkraft-Name und alle Schülernamen werden durch „[Anonymisiert]" ersetzt. Passwort gelöscht. Login danach unmöglich.

Art. 5 Abs. 1 lit. e DSGVO

🗑️ Automatische Bereinigung

Admin wählt Aufbewahrungsfrist (6–36 Monate). Alle älteren Buchungen werden endgültig gelöscht. Jede Löschung wird im Audit-Log protokolliert.

Art. 5 Abs. 2 DSGVO

📋 DSGVO-Audit-Log

Jede DSGVO-relevante Admin-Aktion (Export, Anonymisierung, Massenlöschung) wird in einem unveränderlichen Audit-Log mit Zeitstempel und Admin-ID festgehalten.

Was genau gespeichert wird

Pro Buchung speichert EduSlot ausschließlich diese Daten (Art. 6 Abs. 1 lit. b & e DSGVO – Vertragserfüllung / öffentliche Aufgabe der Schule):

Datenkategorie Gespeicherter Wert Schutzmaßnahme Zweck
Buchende Lehrkraft „Fr. Müller" Nur buchende Person & Admin Buchungsverantwortung
Klasse / Gruppe „9a" Nur buchende Person & Admin Kapazitätsprüfung
Schülernamen „Max M." ← automatisch 🔐 Vor DB-Speicherung gekürzt Anwesenheitsnachweis
Datum & Stunde „12.06.2026, 3. Std." Kein Personenbezug Belegungsplanung
Gebuchter Raum „Sportoase" Kein Personenbezug Ressourcenzuweisung

Rechtliche Details

Gemäß DSGVO, BDSG, TMG und TTDSG · Stand: Juni 2026