GIS Care — Lizenz- & Mandantenkonzept

1. Zusammenfassung

Dieses Dokument beschreibt das Multi-Tenant-Kundensystem mit Lizenzschlüsselverwaltung für GIS Care. Ziel ist es, mehrere Kunden (Firmen) mit strikter Datentrennung auf einer einzigen GIS Care Installation zu betreiben, wobei jeder Kunde durch Lizenzschlüssel begrenzt wird.

Kernkomponenten

Komponente	Beschreibung
Kunden (Tenants)	Firmen/Organisationen mit eigener Benutzer-Isolation
Lizenzen	Schlüsselbasierte Steuerung: max. Benutzer, Gültigkeit
Kundenverwaltungsuser	Rolle `customer_admin` — verwaltet Benutzer innerhalb seines Kunden
Kunden-Dashboard	Eigener Bereich unter `/server/dashboard/`
Admin-Panel	Admin verwaltet Kunden + Lizenzen über `/server/admin/`

2. Rollenmodell (3 Rollen)

Rolle	Scope	Beschreibung
admin	Global	Systemadministrator — sieht alles, verwaltet Kunden + Lizenzen
customer_admin	Kundengebunden	Verwaltungsuser für einen Kunden — erstellt/verwaltet Benutzer
user	Kundengebunden	Normaler App-Benutzer — nutzt Alleinarbeiterschutz

Berechtigungsmatrix

Aktion	admin	customer_admin	user
Kunden erstellen/bearbeiten/löschen	✅	❌	❌
Lizenzen erstellen/verwalten	✅	❌	❌
Verwaltungsuser erstellen	✅	❌	❌
Benutzer innerhalb Kunde erstellen	✅	✅*	❌
Alarme einsehen (eigener Kunde)	✅	✅	❌
Profile verwalten	✅	❌	❌
Systemkonfiguration	✅	❌	❌
Admin-Panel Zugang	✅	❌	❌
Kunden-Dashboard Zugang	✅	✅	❌

* Nur innerhalb der eigenen Kunden-Lizenzgrenzen

3. Lizenzschlüssel-System

Schlüsselformat

GC-STD-{KUNDENCODE}-{ZUFÄLLIG}
Beispiel: GC-STD-FIRMA001-A7K9X2M4

Es gibt einen einheitlichen Lizenztyp (standard). Die Lizenz wird über max_users und valid_from/valid_until gesteuert.

Lizenzprüfung

Bei jeder Benutzeranlage wird geprüft:

Hat der Kunde eine aktive Lizenz?
Ist die Lizenz nicht abgelaufen (valid_until >= TODAY)?
Ist das Benutzerlimit noch nicht erreicht?

4. Datenbank-Schema (Kurzübersicht)

Tabelle	Beschreibung
`customers`	Firmen/Organisationen (Tenants)
`licenses`	Lizenzschlüssel pro Kunde (`license_type ENUM('standard')`)
`users`	Benutzer mit `role ENUM('admin','customer_admin','user')` und `customer_id`

Alle kundenrelevanten Abfragen (Alarme, Heartbeats, Protokolle) werden über users.customer_id gefiltert.

Vollständiges Schema: server/database_schema.sql

5. Server-Architektur

server/
├── admin/               # Admin-Panel (nur admin)
├── dashboard/           # Kunden-Dashboard (customer_admin)
├── api/
│   ├── customers.php    # Kunden-CRUD
│   ├── licenses.php     # Lizenz-CRUD
│   ├── dashboard_api.php# Kunden-Dashboard-API
│   ├── auth.php         # Authentifizierung
│   ├── users.php        # Benutzerverwaltung
│   └── ...
├── db_config.php        # DB + Auto-Migration
└── database_schema.sql  # DB-Schema

6. Migration

Version	Änderung	Script
v2.3 → v2.4	Rollen reduziert (5→3), Lizenztypen vereinfacht (4→1)	`server/migrate_v2.4.sql`
v2.4 → v2.5	Impressum→Branding, deprecated Config entfernt	`server/migrate_v2.5.sql`

Auto-Migrationen werden bei jedem Server-Start über db_config.php::runAutoMigrations() ausgeführt.

7. Sicherheit

Strikte Mandantentrennung via customer_id
Kein Cross-Tenant-Zugriff für customer_admin
Lizenzprüfung bei jeder Benutzeranlage
Alarme und Heartbeats dürfen NIEMALS stille Fallbacks haben

🔑 Lizenz- & Mandantenkonzept