Shop Projekt - Dokumentation

Security- & Compliance-Standards

Dokumentation der umgesetzten Sicherheitsgrundlagen sowie der vorgesehenen rechtlichen Rahmenbedingungen (Schweiz / EU).

🗺️ Stufe 0 | 📚 Entwurf | 📟 2026 06 15 | 📍 Steuerung

Transparenz zum Entwicklungs- und Rechtsstand

BRULSIM Shop ist öffentlich im Testbetrieb und befindet sich weiter in Entwicklung. Die beschriebenen technischen Massnahmen sind ein Sicherheitsfundament, aber keine Zusage absoluter Sicherheit, einer bestimmten Verfügbarkeit oder einer fehlerfreien Abwicklung; diese Seite ersetzt auch keine Rechtsberatung. Der Entwicklungsstand, neue Funktionen und die jeweils umgesetzten Sicherheitsmassnahmen werden offen kommuniziert. Vor einer vollwertigen Realbetriebs-Version müssen Datenschutzerklärung, AGB, Impressum, Aufbewahrungs- und Löschkonzept sowie die gesetzlichen Pflichten für das endgültige Angebot fachlich und rechtlich geprüft, umgesetzt und veröffentlicht werden.

Gesetzliche Vorgaben & AI Act Compliance

Aufgrund des im Jahr 2026 voll wirksamen AI Acts gelten für den Umgang mit generativen Medien folgende feste Vorgaben:

  • Kennzeichnungspflicht bei KI-Medien: Wenn künstliche Intelligenz für temporäre Platzhalter-Bilder genutzt wird, wird dies im Frontend transparent deklariert (z.B. durch den Text "Visualisierung (KI-generiert)").
  • Schweizer Impressum & Transparenz: Gewährleistung eines rechtskonformen Schweizer Impressums für den Standort Breitenbach (CH) mit direkter E-Mail-Erreichbarkeit.
  • Notice-and-Take-Down: Administrative Bereitschaft, bei berechtigten Bild-Reklamationen Assets sofort vom Server zu entfernen, um rechtliche Konflikte präventiv zu lösen.

Aktive Core-Architektur & Technische Absicherung

Das System folgt einem strikten "Security-by-Design"-Ansatz und implementiert folgende Schutzschichten standardmäßig im Code-Fundament:

  • Server- & Verzeichnis-Härtung: Konsequenter Einsatz von restriktiven `.htaccess`-Dateien zur Sperrung unbefugter Direktzugriffe auf Systemordner und Core-Inhalte.
  • Strikte Input-Validierung: Jede Formulareingabe und jeder Request durchläuft eine absolute Prüfung über das modulare Konfigurations- und Validierungs-Grid, bevor Daten weiterverarbeitet werden.
  • Konsequenter SQL-Injektions-Schutz: Die Datenbank-Klasse `cDatabase` erzwingt die ausschließliche Nutzung von Prepared Statements (PDO) mit gebundenen Parametern für alle relationalen Abfragen.
  • Kryptographischer Passwort-Schutz: Benutzerpasswörter werden niemals im Klartext verarbeitet, sondern über modernste, native PHP-Hashing-Algorithmen sicher in der Datenbank abgelegt.
  • Feingranulare Zugriffskontrolle: Isolierung kritischer Systembereiche und Routen durch die dedizierten Sicherheits- und Authentifizierungsservices `cSecurity` und `cAccess`.

Geplant: Rollenabhängige Kontosicherheit

Der aktuelle Kontoschutz (E-Mail-Bestätigungscode + Passwort, ohne zweiten Faktor) ist als Ausgangspunkt bewusst niedrigschwellig. Für höhere Rollen ist eine gezielte Verschärfung geplant, ohne normale Nutzer auszuschliessen:

  • Stärkere Absicherung für Verkäufer, Händler und höhere Rollen: Rollen mit erhöhtem finanziellem oder operativem Risiko (Verkäufer, Händler, Support, Admin) erhalten zusätzliche Schutzmassnahmen (z. B. zweiter Faktor), sobald diese ausgearbeitet sind.
  • Zugänglichkeit für normale Nutzer bleibt Pflicht: Für normale Nutzerkonten muss der Zugang einfach und zugänglich bleiben, insbesondere für ältere Menschen ohne Smartphone. Kein rein smartphonebasierter Zwangsfaktor als einzige Option für diese Gruppe.
  • Stufenweise Einführung: Verschärfungen werden schrittweise und nach Möglichkeit mit Übergangsfrist eingeführt, nicht als abrupter Zwang beim ersten Login nach der Umstellung.