Sheets via neuer KeyboardAwareSheet-Composable (in Modal pattern, auto-grow mit Tastatur, paddingBottom-Lift): EditMail, AddDomain, CreateRoom, ConnectMail. GameOverScreen behält Spring-Slide-In, nutzt RN Keyboard.addListener für Lift. - KeyboardAwareSheet.tsx — universal modal with sheet-grow + keyboard-padding - react-native-keyboard-controller installiert + KeyboardProvider in Root - Snake: time + ScoreProgressBar + useSnakeSounds (haptic, audio TODO) - Tetris: title weg, Buttons zentriert, kein Pressable mit style-fn - DPad-Buttons 60→48, more bg, no scale - useMe: pub-sub listener pattern für app-weite avatar/nickname-Updates - dm.tsx: resolveAvatar wrap (iron.png-Warning) - Mail-error-humanizer + locales Recovery-Doc-Update in docs/internal/RECOVERY_LOG_2026-05-10.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.2 KiB
3.2 KiB
MDM Server — Security
Was muss geheim bleiben
| Secret | Wo es liegt | Permissions | Wer hat Zugriff |
|---|---|---|---|
| PostgreSQL-Passwort | /root/.nanomdm_db_pass |
600 (root) | Chahine, Olfa |
| MDM CA Private Key | /opt/nanomdm/certs/ca.key |
600 (root) | Chahine, Olfa |
| Apple Push Private Key | /opt/nanomdm/certs/push.key |
600 (root) | Chahine, Olfa |
| nanomdm .env (enthält DB-Pass) | /opt/nanomdm/.env |
600 (root) | Chahine, Olfa |
| MDM-Admin-API-Key (nach Phase E) | Wird nach Phase E generiert | - | Chahine, Olfa, Ina* |
| Ina-Notfall-Credentials | Per Email (Phase E) + evt. Kopie | - | Ina |
(*) Ina bekommt nur den API-Key, keinen SSH-Zugriff.
Was NICHT geheim sein muss
push.csr— CSR ist öffentlich (geht ans Apple-Portal)ca.crt— CA-Zertifikat ist öffentlich (wird ans Gerät übertragen)- nginx-Config, docker-compose.yml (ohne Passwörter)
Threat-Modelle
Server-Kompromittierung
Was der Angreifer bekommt:
- DB-Pass → Zugriff auf nanomdm-DB (Device-Liste, Enrollment-Daten)
- push.key → Kann eigene MDM-Befehle an Geräte senden (mit Apple-Cert)
- ca.key → Kann eigene Device-Identity-Certs ausstellen
Was zu tun ist:
- Apple Push Cert sofort auf identity.apple.com revoken
- Neuen VPS aufsetzen (Phase A-D wiederholen)
- Geräte re-enrollen mit neuem Push-Cert + neuem CA-Cert
- Neues DB-Passwort aus
/root/.nanomdm_db_pass(von Chahine neu generiert)
Device-Verlust (gestohlen)
- MDM-Remote-Wipe triggern: löscht alle Daten auf Gerät
- Apple-ID-basiertes "Find My" als zusätzliche Schicht (unabhängig vom MDM)
- MDM-Profil ist nach Factory-Reset weg → Gerät ist dann nicht mehr enrollt
Angreifer hat Zugriff auf Ina's Email-Account
Ina's Notfall-Credentials (Phase E) geben nur Zugriff auf nanomdm-API um das Profil zu entfernen, keinen Server-SSH-Zugriff. Worst-case: Angreifer entfernt MDM-Profil vom Gerät. Das MDM kann dann re-enrollen wenn Chahine zustimmt.
Abgelaufenes Apple Push Cert
Wenn push.pem abläuft (nach 1 Jahr): nanomdm kann keine Befehle mehr ans Gerät schicken. Gerät ist aber noch enrollt (Profil ist drauf). Nach Cert-Renewal (gleicher push.key) funktioniert Kommunikation wieder.
Geheimhaltungs-Regeln
push.key,ca.key, DB-Passwort werden NIEMALS in Git committed/opt/nanomdm/.envhat chmod 600 — Änderung würde nanomdm-Container-Restart erfordern- Keine Passwörter in Docker-Logs (env-vars sind als values gesetzt, nicht als --env in command-line args)
- SSH-Zugriff nur via Key-Auth (kein Password-SSH auf dem Server)
Audit-Trail
Relevante Events zum Dokumentieren in /opt/nanomdm/SETUP-LOG.md auf dem Server:
- Wann wurde welcher Container deployed
- Wann wurde Apple Push Cert erneuert (Datum + Apple-ID die es ausgestellt hat)
- Wann wurde Enrollment durchgeführt (Gerät, Datum)
- Wann wurde Profil entfernt (wer hat entfernt, warum)
Format: [DATUM] [WER] [WAS] — plain text, kein JSON.