--- Titel: „Systemeinstellungen“ Beschreibung: „Sicherheitsarchitektur, Anwendungskonfiguration und Bereitstellungsoptionen“ ---

Systemeinstellungen

Die Systemeinstellungen steuern das anwendungsweite Verhalten, die Sicherheitsparameter und die Bereitstellungskonfiguration. Dieser Abschnitt behandelt die Sicherheitsarchitektur, die App-Konfiguration und alternative Bereitstellungsmodelle.

Sicherheitsarchitektur

Aptli verwendet ein vierstufiges Sicherheitsmodell mit serverseitiger Rendering-Durchsetzung (SSR):

Ebene 1: Authentifizierung Wer Sie sind – überprüft die Identität des Benutzers vor dem Zugriff. – Passwortbasierte Anmeldung (mit Komplexitätsanforderungen) – OAuth-Anbieter (GitHub, Google) – Zwei-Faktor-Authentifizierung (TOTP) – E-Mail-Validierung erforderlich – Sitzungsverwaltung mit Ablauf – Harte Sperre nach fehlgeschlagenen Versuchen

Ebene 2: Administratorrechte (freizügig) Was Sie ändern können – explizite Berechtigungen. – Berechtigungen pro Modell erstellen/aktualisieren/löschen – Superrechte: `appSettingSchemasModify`, `adminRightsModify`, `viewDeleted` – Auf Aktionen beschränkt (kann erstellen, aber nicht löschen) – Standard: Nur-Lese-Zugriff

Ebene 3: Rollenbeschränkungen (restriktiv) Was Sie NICHT sehen können – Datenfilter auf Feldebene. – Modell + Feld + Vergleich + Wertfilter – Wird vor der Datenbankabfrage serverseitig angewendet – Kann nicht über API-Aufrufe, Exporte oder Screenshots umgangen werden – Mehrere Beschränkungen werden kombiniert (UND-Logik)

Ebene 4: Server-seitige Rendering-Durchsetzung (SSR) auf API-Ebene – Daten sind für nicht autorisierte Benutzer tatsächlich nicht vorhanden. – Alle Abfragen werden serverseitig gefiltert (Nuxt-Server-API). – Rollenbeschränkungen werden vor der MongoDB-Suche angewendet. – Keine clientseitige Filterung (kann nicht umgangen werden). – Die API gibt 404 für nicht autorisierte Datensätze zurück (auch wenn der Angreifer die ID kennt).

Warum SSR wichtig ist: - Clientseitige Filterung: An den Browser gesendete Daten, mit JavaScript versteckt (über Entwicklertools umgehbar) - Serverseitige Filterung: Daten werden niemals an unbefugte Benutzer gesendet (sicher)

Aptli verwendet SSR – unbefugte Daten gelangen niemals zum Kunden.

Anwendungseinstellungen

Übersicht über die App-Einstellungen Seite mit den Anwendungseinstellungen, auf der Konfigurationsoptionen und Sicherheitsparameter angezeigt werden

Zugriff erforderlich: Administratorrecht appSettingSchemasModify

Navigieren Sie zu: Admin → App-Einstellungen

Authentifizierungseinstellungen

Zulässige Domänen: - Liste der E-Mail-Domänen, die Konten registrieren können - Beispiel: ["company.com", "contractor.com"] - Nur E-Mails von diesen Domänen können sich anmelden - Standard: Ihre Bereitstellungsdomäne

Registrierung zulassen: - true - Benutzer können sich selbst registrieren, wenn die Domain übereinstimmt - false - Der Administrator muss Konten manuell erstellen - Standard: false (kontrollierter Zugriff)

Aktive Anmeldemethoden: - Benutzername/Passwort (Kontrollkästchen) - GitHub OAuth (Kontrollkästchen) - Google OAuth (Kontrollkästchen) - Mindestens eine Methode muss aktiviert sein - Standard: Nur Benutzername/Passwort

Zwei-Faktor-Authentifizierung erforderlich: - true – Alle Benutzer müssen 2FA aktivieren (Gnadenfrist konfigurierbar) - false – 2FA optional - Standard: false

Sitzungssicherheit

Maximale Anzahl von Anmeldeversuchen: - Anzahl der fehlgeschlagenen Anmeldeversuche vor der vollständigen Sperrung - Gültiger Bereich: 3–10 Versuche - Standardwert: 5

Automatische Abmeldezeit: - Zeitlimit für Inaktivität in Sekunden - Lesen/Schreiben von Daten setzt den Countdown zurück - Gültiger Bereich: 1 Stunde - 7 Tage - Standard: 86400 (1 Tag)

CSRF-Token-Ablauf: - Zeitüberschreitung der Serversitzung in Minuten - Erzwingt eine erneute Anmeldung unabhängig von der Aktivität - Gültiger Bereich: 1 Stunde - 4 Wochen - Standard: 10080 (1 Woche)

Ablauf der Sitzung: - Absolute maximale Sitzungsdauer - Entspricht dem CSRF-Token für Benutzer mit einem einzigen Gerät - Benutzer mit mehreren Geräten können unterschiedliche Ablaufzeiten haben - Standard: 10080 Minuten (1 Woche)

Datenaufbewahrung

Aufbewahrungsdauer für vorläufig gelöschte Daten: - Wie lange vorläufig gelöschte Datensätze in der Datenbank verbleiben - Optionen: 30 Tage, 90 Tage, 1 Jahr, unbegrenzt - Standard: 90 Tage - Gilt für Zuweisungen, Berichte, Benutzer, Funktionen (wenn deletedAt festgelegt)

Zeitplan für die Versionskomprimierung: - Wie oft sollen alte Funktionsversionen komprimiert werden? - Optionen: Wöchentlich, monatlich, vierteljährlich - Standard: Monatlich - Komprimierte Versionen sind weiterhin rekonstruierbar (verlustfreie Komprimierung)

Transaktionsverlauf: - Bestands-Transaktionen werden niemals gelöscht (unveränderlicher Prüfpfad) - Kann in einer separaten Datenbank archiviert werden (erweiterte Konfiguration)

Neue Benutzervorgaben

Rollen für neue Benutzer: - Array von automatisch zugewiesenen Rollen-IDs - Leeres Array = keine automatischen Einschränkungen - Standard: [] (vom Administrator manuell zugewiesen)

Administratorrechte für neue Benutzer: - Objekt mit Berechtigungsgewährung - Leeres Objekt = Nur-Lesezugriff - Standard: {} (keine Schreibberechtigungen)

Beispielkonfigurationen:

Standards für Außendienstmitarbeiter: json { "roles": ["field_worker_role_id"], "adminRights": { "reportsCreate": true } }

Standardeinstellungen für Bürokoordinatoren: json { "roles": [], "adminRights": { "assignmentsCreate": true, "ordersCreate": true, "stockItemsView": true } }

Selbst gehostete Bereitstellung

Aptli unterstützt die selbst gehostete Bereitstellung (erfordert eine Lizenz im selbst gehosteten Modus).

Bereitstellungsmodi

SaaS-Modus (Standard): bash NUXT_REQUIRE_LICENSE=false - Keine Lizenzvalidierung - Aptli verwaltet die Infrastruktur - Automatische Updates - Professioneller Support inklusive

Selbst gehosteter Modus: bash NUXT_REQUIRE_LICENSE=true NUXT_LICENSE_PUBLIC_KEY="-----BEGIN PUBLIC KEY-----..." - Lizenzvalidierung erforderlich - Kunde verwaltet Infrastruktur - Manuelle Updates (Ordner .output ersetzt) - Lizenzschlüssel von Aptli erforderlich

Lizenzsystem

So funktioniert es: 1. Stellen Sie den Ordner „.output/“ auf Ihrem Server bereit. 2. Der Server generiert eine eindeutige Bereitstellungs-ID (Hardware-Fingerabdruck + Hostname). 3. Die 30-tägige Testphase beginnt automatisch. 4. Senden Sie die Bereitstellungs-ID per E-Mail an [email protected]. 5. Aptli generiert eine JWT-Lizenz mit autorisierten Bereitstellungs-IDs. 6. Aktivieren Sie die Lizenz über die Seite „/admin/license“ oder die Umgebungsvariable „NUXT_LICENSE_KEY“.

Mehrfachbereitstellung: - Jeder Server verfügt über eine eindeutige Bereitstellungs-ID - Die Lizenz listet alle autorisierten Bereitstellungs-IDs auf - Ohne neue Lizenz kann der Server nicht geklont werden - Verhindert unbefugte Weitergabe

Lizenzvalidierung: - Wird beim Serverstart überprüft - Ungültige Lizenz = Anwendung startet nicht - Testversion abgelaufen = 7 Tage lang Warnung, dann Sperrung - Lizenzverlängerung per E-Mail

Umgebungsvariablen (selbst gehostet)

Erforderlich: bash NUXT_MONGODB_URI=mongodb://localhost:27017/aptli NUXT_SESSION_PASSWORD=min-32-char-random-string

Optional – OAuth:bash NUXT_OAUTH_GITHUB_CLIENT_ID=... NUXT_OAUTH_GITHUB_CLIENT_SECRET=... NUXT_OAUTH_GOOGLE_CLIENT_ID=... NUXT_OAUTH_GOOGLE_CLIENT_SECRET=...

Optional – E-Mail: bash NUXT_RESEND_API_KEY=... [email protected]

Optional – Datei-Scan: bash NUXT_ENABLE_FILE_SCAN=true NUXT_CLAMAV_HOST=localhost NUXT_CLAMAV_PORT=3310

Optional – Lizenz: bash NUXT_REQUIRE_LICENSE=true NUXT_LICENSE_PUBLIC_KEY="-----BEGIN PUBLIC KEY-----..." NUXT_LICENSE_KEY=eyJhbGc... (auto-activate)

Infrastrukturanforderungen

Mindestanforderungen: - 2 CPU-Kerne - 4 GB RAM - 20 GB Speicherplatz (wächst mit den Daten) - MongoDB 5.0+ - Node.js 20+

Empfohlen: - 4 CPU-Kerne - 8 GB RAM - 100 GB SSD-Speicher - MongoDB-Replikatsatz (hohe Verfügbarkeit) - Load Balancer (horizontale Skalierung)

Optionale Dienste: - ClamAV-Daemon (Datei-Scan) - Redis (Sitzungs-Caching – Leistungsverbesserung) - SMTP-Server (E-Mail-Benachrichtigungen)

Bereitstellungsschritte

Anwendung erstellen: bash npm run build
Ausgabe kopieren: bash scp -r .output/ user@server:/aptli/
Umgebungsvariablen festlegen: Erstellen Sie /aptli/.env mit den erforderlichen Variablen.
Server starten: bash cd /aptli/.output node server/index.mjs
Lizenz aktivieren: - Navigieren Sie zu https://your-domain/admin/license - Kopieren Sie die Bereitstellungs-ID - Senden Sie eine E-Mail an [email protected] - Fügen Sie den erhaltenen Lizenzschlüssel ein - Klicken Sie auf „Aktivieren“
Reverse-Proxy konfigurieren: Nginx/Apache als Proxy für Port 3000 → HTTPS
Setup Process Manager: PM2 oder systemd, um den Server am Laufen zu halten

Updates (selbst gehostet)

Manueller Aktualisierungsprozess: 1. Datenbank sichern: mongodump 2. Sichern Sie die Datei .env. 3. Laden Sie den neuen Ordner .output/ von Aptli herunter. 4. Stoppen Sie den Server: pm2 stop aptli. 5. Ersetzen Sie den Ordner .output/. 6. Stellen Sie die Datei .env wieder her. 7. Starten Sie den Server: pm2 start aptli. 8. Überprüfen Sie die Version unter /admin/license.

Aptli bietet: - Versionshinweise mit wesentlichen Änderungen - Migrationsskripte (bei Datenbankänderungen) - Anweisungen zum Rollback - Professioneller Support während der Updates

Best Practices für Sicherheit

SSL/TLS erforderlich: - Verwenden Sie HTTPS in der Produktion (nicht HTTP) - Kostenlose Zertifikate: Let's Encrypt - HTTP-Verbindungen ablehnen (Weiterleitung zu HTTPS)

Firewall-Konfiguration: - Zulassen: HTTPS (443), SSH (22) - Verweigern: MongoDB-Port (27017) aus dem öffentlichen Internet - Einschränken: Admin-Seiten auf VPN oder IP-Whitelist

Sicherheit der Sitzung: - NUXT_SESSION_PASSWORD - mindestens 32 zufällige Zeichen - Vierteljährliche Änderung des Sitzungspassworts - Kurze Sitzungsdauer für Umgebungen mit hohen Sicherheitsanforderungen

Datenbanksicherheit: - MongoDB-Authentifizierung aktiviert - Separate Benutzeranmeldedaten (nicht root) - Verschlüsselte Verbindungen (MongoDB TLS) - Regelmäßige Backups (automatisiert, getestete Wiederherstellung)

OAuth-Geheimnisse: - In Umgebungsvariablen speichern (nicht im Code) - Vierteljährlich rotieren - Nicht verwendete OAuth-Apps widerrufen

Sicherheit beim Hochladen von Dateien: - ClamAV-Scan in der Produktion aktiviert - Dateigrößenbeschränkungen durchgesetzt - Zulässige Dateitypen eingeschränkt - Speicherquarantäne für verdächtige Dateien

Überwachung: - Fehlgeschlagene Anmeldeversuche (Erkennung von Brute-Force-Angriffen) - Autorisierungsfehler (Erkennung von unbefugten Zugriffsversuchen) - Ungewöhnliche API-Nutzungsmuster - Fehler bei der Datenbankverbindung

Compliance-Überlegungen

Datenresidenz: Der selbst gehostete Modus ermöglicht die Kontrolle über den Speicherort der Daten: - Hosting in einer bestimmten geografischen Region - Erfüllung gesetzlicher Anforderungen (DSGVO, HIPAA usw.) - Physische Kontrolle über den Datenzugriff

Audit-Trail: Aptli führt Audit-Trails für folgende Vorgänge: - Authentifizierungsversuche (erfolgreich/fehlgeschlagen) - Nutzung von Administratorrechten (wer hat was geändert) - Änderungen der Rollenbeschränkungen - Transaktionsverlauf (Bestandsbewegungen) - Versionsverlauf (Änderungen an Funktionen) - Vorläufige Löschungen (wer hat was wann gelöscht)

Datenexport: Alle Daten können zur Einhaltung von Vorschriften exportiert werden: - CSV-Export für Nicht-Geodaten - GeoJSON-Export für Funktionen (über die Schaltfläche „Datentransfer“ in der Symbolleiste der Karte) - Transaktionsberichte (Bestandsprüfung) - Benutzerzugriffsprotokolle

Datenaufbewahrung: Konfigurierbare Aufbewahrungsrichtlinien: - Aufbewahrungsfrist für vorläufige Löschungen - Versionskomprimierung (verlustfrei) - Transaktionsverlauf (unveränderlich – wird nie gelöscht) - Audit-Protokolle (konfigurierbare Archivierung)