--- 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

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 } }

API-Schlüssel

API-Schlüssel ermöglichen es einem externen System, Aptli ohne menschliche Anmeldung aufzurufen — für ArcGIS/Postgres-Synchronisation, Data-Warehouse-Export oder eigene Tools. Verwaltung unter Admin → App-Einstellungen → API-Schlüssel. Erfordert appSettingSchemasModify.

Grenzen

• Maximal 3 Schlüssel pro Deployment. Widerrufen Sie einen vorhandenen Schlüssel, bevor Sie einen neuen erstellen.
• Jeder Schlüssel hat seinen eigenen isolierten Rate-Limit-Bucket (gleiche Schwellenwerte wie ein interaktiver Benutzer: ~2.700 Anfragen/Minute für Lesevorgänge, ~900/Minute für Schreibvorgänge).

Nur-Lesen-Schlüssel

Beim Erstellen eines Schlüssels können Sie Nur Lesen aktivieren. Ein Nur-Lesen-Schlüssel blockiert alle Schreibanfragen (POST / PUT / PATCH / DELETE) auf Sitzungsebene — auch wenn Schreibrechte gewährt wurden.

Widerruf eines Schlüssels

Klicken Sie auf Widerrufen neben dem Schlüssel in der Tabelle. Der Widerruf ist sofort wirksam.

Kommunikationszustand

Die Einstellungsseite enthält einen eingeklappten Abschnitt Kommunikationszustand (zwischen der Umgebungsliste und der Gefahrenzone). Öffnen Sie ihn, um den Live-Status der Nachrichten-Pipelines zu sehen:

• E-Mail- / SMS- / Push-Zustellung — ob die Anbieter-Zugangsdaten konfiguriert sind und wie viele Nachrichten in jeder Warteschlange ausstehen oder erneut versucht werden. Ein fehlender Anbieter-Schlüssel erzeugt keine Fehler: Nachrichten reihen sich stillschweigend endlos in die Warteschlange ein, und in diesem Panel wird das sichtbar.
• SMS-Kontingent — wenn für die Bereitstellung eine monatliche SMS-Obergrenze festgelegt ist, zeigt die SMS-Zeile verbraucht/Obergrenze für den laufenden Monat an und wird bernsteinfarben, wenn die Obergrenze erreicht ist.
• Warteschlangen-Backend — ob der Job-Speicher (Valkey) verbunden ist; eine Warnung über einen In-Memory-Fallback bedeutet, dass Nachrichten in der Warteschlange bei einem Neustart verloren gehen.
• Empfänger von Sicherheitswarnungen — wie viele Adressen Warnungen zu Kontosperrungen und Kontingenten erhalten. Null bedeutet, dass diese Warnungen ins Leere laufen; konfigurieren Sie die Empfänger auf derselben Seite.
• E-Mail-Domain-Abdeckung — wenn eine Domain-Freigabeliste aktiv ist, die Anzahl der aktiven Benutzer, deren E-Mail-Domain nicht mehr auf der Liste steht (sie können keine E-Mails erhalten, bis die Liste aktualisiert wird oder sie archiviert werden).

Zeilen zeigen ein grünes Häkchen, wenn alles in Ordnung ist, andernfalls eine bernsteinfarbene Warnung. Verwenden Sie Aktualisieren, um nach Änderungen an der Umgebungskonfiguration erneut abzufragen.

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

1. Anwendung erstellen: bash npm run build
2. Ausgabe kopieren: bash scp -r .output/ user@server:/aptli/
3. Umgebungsvariablen festlegen: Erstellen Sie /aptli/.env mit den erforderlichen Variablen.
4. Server starten: bash cd /aptli/.output node server/index.mjs
5. 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“
6. Reverse-Proxy konfigurieren: Nginx/Apache als Proxy für Port 3000 → HTTPS
7. 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)