Sicherheit

Diese Seite beschreibt, wie wir pegnitz.city absichern und wie Du uns eine Sicherheitslücke meldest. Wir sind ehrlich, was bereits umgesetzt ist und was sich noch in Vorbereitung befindet: Unsere Maßnahmen sind an die Prinzipien der ISO/IEC 27001 ausgerichtet — eine formale Zertifizierung nach ISO/IEC 27001 oder SOC 2 besteht ausdrücklich nicht. pegnitz.city ist ein Forschungsprojekt der XBANQ® GmbH und kein offizielles Angebot der Stadt Pegnitz.

Rechtlicher Rahmen

Die XBANQ® GmbH ist der rechtliche Betreiber von pegnitz.city. Die GmbH schafft die Grundlage, um Sicherheit, Datenschutz, Verträge, Haftung und Finanzierung professionell zu führen. Geschäftsführer ist Daniel Boran; Prokura hat Karolina Parot. XBANQ® GmbH ist ein Unternehmen der Boran & Parot Family GmbH.

Unser Sicherheitsanspruch

Wir verarbeiten so wenige Daten wie möglich und schützen sie auf mehreren Ebenen (Defense in Depth). Der verbindliche Release-Prozess verlangt für jede Auslieferung technische Tests sowie Sicherheits- und Datenschutzprüfung; offene Gates halten den Prelaunch-Schutz aktiv. Wir orientieren uns an den Prinzipien der ISO/IEC 27001 (Vertraulichkeit, Integrität, Verfügbarkeit), sind aber nicht zertifiziert.

Zugriffsschutz auf der Datenbank (Row-Level Security)

Für Tabellen mit schützenswerten Konto-, Betriebs- oder Mediendaten gelten Row-Level-Security (RLS) und zweckgebundene Rollenregeln. Öffentliche Wissensprojektionen sind bewusst lesbar; die in V1 zurückgehaltenen Beiträge und Medien erlauben dagegen keine anonymen Schreibzugriffe. Privilegierte Betriebs- und Moderationszugriffe laufen serverseitig mit eigenen Rollen. Ausgewählte kontobezogene Funktionen schreiben erst nach bestätigter Anmeldung über RLS-geschützte Wege oder authentifizierte SECURITY INVOKER-Funktionen — und nur in Datensätze des eigenen Kontos. Der öffentliche Media Vault bleibt geschlossen; Nachweise und Widerruf für Eigentümer sowie Reviewer- und Service-Role-Zugriffe bleiben getrennt erhalten.

Schutz personenbezogener Daten (DSGVO-Scrub)

Die Wissens-Intelligence beschreibt Organisationen, Orte und öffentliche, quellenbelegte Fakten — keine privaten personenbezogenen Daten. Dafür greifen mehrere Schichten: (1) ein Quellen-Scrub, der identifizierbare private bzw. kleingewerbliche Personen in den KI-Freitexten verallgemeinert, während öffentliche Amtsträger in ihrer dienstlichen Rolle rechtmäßig erhalten bleiben (Art. 6 Abs. 1 lit. f DSGVO); (2) ein nicht-destruktiver Warn-Scan beim Graph-Export, der bei Personen-Knoten eine private Provider-E-Mail (z. B. gmail, gmx, web.de) markiert und zur DSGVO-Prüfung meldet; (3) die oben beschriebene RLS. Wichtig: Der Wert „privacy_risk_score" eines Knotens ist ein Themen-Sensitivitätsmaß, kein Personen-PII-Flag — der Personenschutz läuft über Quellen-Scrub, Warn-Scan und RLS.

Bürgerbeiträge werden erst nach Freigabe sichtbar

Beiträge aus „Deine Vision" gelten als nicht vertrauenswürdige Eingaben. Jeder Beitrag wird mit der Herkunft „citizen", dem Status „pending" und der einreichenden Nutzer-ID gespeichert, erhält ehrliche, nicht aufgeblähte Qualitätswerte und wird vom öffentlichen Graphen zurückgehalten, bis ein Mensch ihn auf „approved" setzt. Es gibt keine automatische Veröffentlichung. Eingaben sind in der Länge begrenzt, und die rechenintensive Planungs-Route ist pro Nutzer ratenbegrenzt (In-Memory-Sliding-Window mit Alterung der Schlüssel).

Verschlüsselung und Übertragung

Der öffentliche Produktionszugang läuft über HTTPS (TLS), also verschlüsselt in Transit. Externe Bilder in der 3D-INTELLIGENCE werden mit referrerPolicy „no-referrer" geladen, sodass keine Herkunfts-URL mitgesendet wird. Sicherheits-Header sind gesetzt: Content-Security-Policy mit per-Request-Script-Nonce, X-Frame-Options, X-Content-Type-Options, Referrer-Policy und Permissions-Policy. Die Style-Richtlinie erlaubt derzeit noch Inline-Styles; diese Einschränkung wird nicht als vollständige CSP-Härtung ausgegeben.

Least Privilege und Authentifizierung

Wir folgen dem Prinzip der minimalen Rechte. Der öffentliche (anon) Schlüssel erreicht nur ausdrücklich freigegebene Lesepfade; für die zurückgehaltenen Beitrags- und Medienpfade ist kein anonymer Schreibzugriff vorgesehen. Admin- und Reviewer-Aktionen werden serverseitig und rollenbezogen geprüft. Kontobezogene Änderungen — zum Beispiel das atomare Speichern verschlüsselter Mentor-Züge — laufen erst nach bestätigter Anmeldung über RLS-geschützte Routen oder authentifizierte SECURITY INVOKER-Funktionen; der Service-Role-Schlüssel wird nicht an den Browser ausgegeben. Die Funktion „Deine Vision" ist durch Anmeldung geschützt (Supabase, SSR) und zusätzlich per Middleware sowie pro Anfrage über auth.getUser() abgesichert. Der Plan-Generator wird als Argument-Array gestartet (keine Shell-Injection möglich) und sauber beendet, wenn Du die Seite verlässt.

Protokollierung und Nachvollziehbarkeit

Als Integritäts-Prinzip gilt: Daten, die in den Graphen gelangen, müssen quellenverifiziert sein. Verifikations-Läufe der selbstprüfenden Engine werden samt Ergebnis und Ablehnungsgrund in operativen Tabellen protokolliert (für anonyme Zugriffe gesperrt). Der Build des Graphen ist reproduzierbar und in der CI abgesichert. In Vorbereitung: ein erweitertes, zentralisiertes Zugriffs-Audit-Logging über die operativen Protokolle hinaus.

Abhängigkeiten und Secrets

Geheimnisse werden nie eingecheckt (.gitignore; .env.example als Vorlage); Hosting-Tokens sind ausschließlich auf das Projekt pegnitz.city und seine Domain beschränkt. In der CI prüft bei jedem Push und wöchentlich ein Gate die Produktiv-Abhängigkeiten auf bekannte Schwachstellen (npm audit, Level „high"); Dependabot aktualisiert wöchentlich. Eine statische Sicherheitsanalyse (CodeQL) ist eingerichtet und läuft manuell; die automatischen Auslöser aktivieren sich, sobald das Repository öffentlich ist bzw. GitHub Advanced Security nutzt.

Eine Sicherheitslücke melden

Wenn Du eine Schwachstelle findest, melde sie uns bitte vertraulich und öffne kein öffentliches Issue. Schreib an security@pegnitz.city (alternativ hello@pegnitz.city) und nenne die betroffene URL bzw. den Endpunkt, die Schritte zur Reproduktion, die Auswirkung und — falls vorhanden — einen Proof of Concept. Wir bestätigen den Eingang in der Regel innerhalb von 72 Stunden und beheben kritische Probleme zügig. Wir bevorzugen Coordinated Disclosure und danken allen, die sich daran halten.

Was noch in Vorbereitung ist

Ehrlichkeit gehört zur Sicherheit: Eine formale ISO/IEC-27001- oder SOC-2-Zertifizierung besteht nicht und ist derzeit nicht geplant — wir richten uns an den Prinzipien aus. Ein global harter Rate-Limit über mehrere Instanzen hinweg (statt pro Instanz), ein zentrales Zugriffs-Audit-Log und die automatische SAST-Auslösung sind in Vorbereitung.