# 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:
1. Apple Push Cert sofort auf identity.apple.com revoken
2. Neuen VPS aufsetzen (Phase A-D wiederholen)
3. Geräte re-enrollen mit neuem Push-Cert + neuem CA-Cert
4. 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

1. `push.key`, `ca.key`, DB-Passwort werden NIEMALS in Git committed
2. `/opt/nanomdm/.env` hat chmod 600 — Änderung würde nanomdm-Container-Restart erfordern
3. Keine Passwörter in Docker-Logs (env-vars sind als values gesetzt, nicht als --env in command-line args)
4. 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.