Harden authentication, tenant isolation and security boundaries
This commit is contained in:
@@ -1,60 +1,37 @@
|
||||
# Production Checklist
|
||||
# Production-Checkliste
|
||||
|
||||
## 1. Domain & Basis-URLs
|
||||
## Vor dem Rollout
|
||||
|
||||
- [ ] Produktionsdomain festlegen: `https://[deine-domain.de]`
|
||||
- [ ] `NEXT_PUBLIC_SITE_URL` auf die Produktionsdomain setzen
|
||||
- [ ] `AUTH_URL` und `NEXTAUTH_URL` auf die Produktionsdomain setzen
|
||||
- [ ] Nach Deployment die WhatsApp-/LinkedIn-Vorschau mit der finalen URL testen
|
||||
- [ ] Datenbank und Uploads gesichert; Wiederherstellung geprüft.
|
||||
- [ ] Alte App gestoppt; Wartungsfenster und erneute Anmeldung angekündigt.
|
||||
- [ ] Bestehendes Schema mit Baseline verglichen; Tenant-Preflight ohne Befunde.
|
||||
- [ ] Baseline nur bei bestehender passender DB markiert; anschließend alle Migrationen angewendet.
|
||||
- [ ] Runtime-Rolle mit separatem Passwort bereitgestellt; App verwendet `APP_DATABASE_URL`.
|
||||
- [ ] Upload-Größen nachgetragen; gemeldete fehlende Dateien geprüft.
|
||||
- [ ] Upload- und Cache-Volumes für UID/GID 1001 beschreibbar; Upload-Pfad unverändert.
|
||||
|
||||
## 2. Datenbank
|
||||
## Hosting und Konfiguration
|
||||
|
||||
- [ ] Interne `DATABASE_URL` der bestehenden Coolify-Postgres-DB kopieren
|
||||
- [ ] `DATABASE_URL` in der Coolify-App eintragen
|
||||
- [ ] Beim ersten App-Start wird das Schema automatisch mit `npx prisma db push --skip-generate` angewendet
|
||||
- [ ] Fuer spaetere Releases idealerweise Prisma-Migrationen einfuehren
|
||||
- [ ] Drei öffentliche Basis-URLs auf dieselbe kanonische HTTPS-Origin gesetzt.
|
||||
- [ ] Starkes `AUTH_SECRET`; echte Secrets nur in Hosting-Konfiguration.
|
||||
- [ ] TLS und Proxy-Header korrekt; kein öffentlicher DB-/App-/pgAdmin-Port.
|
||||
- [ ] Request-Limits, Timeouts und Upload-Body-Limit am Proxy eingerichtet.
|
||||
- [ ] Trusted-IP-Header nur bei garantierter Überschreibung aktiviert.
|
||||
- [ ] Maildomain bei Resend verifiziert; Produktionsabsender gesetzt.
|
||||
- [ ] Optionale Analytics nur auf öffentlichen Marketingseiten; keine Token-/Login-/Dashboard-Daten.
|
||||
- [ ] Upload-Speicher und Backups überwacht; Löschfristen festgelegt.
|
||||
- [ ] Impressum und Datenschutztexte an tatsächliche Betreiber/Anbieter angepasst.
|
||||
|
||||
## 3. Auth & Sicherheit
|
||||
## Nach dem Rollout
|
||||
|
||||
- [ ] `AUTH_SECRET` neu generieren: `openssl rand -base64 32`
|
||||
- [ ] Keine `.env`-Dateien mit echten Secrets committen
|
||||
- [ ] Dashboard ist per Metadata auf `noindex,nofollow` gesetzt
|
||||
- [ ] Produktionsdomain auf HTTPS betreiben
|
||||
- [ ] Anmeldung und Registrierung mit Mailbox-Bestätigung getestet.
|
||||
- [ ] Einladungen, Adressänderung und erneutes Senden getestet.
|
||||
- [ ] Administrative Sperre entwertet bestehende Sitzung; Entsperrung verlangt neue Anmeldung.
|
||||
- [ ] Zwei getrennte Kitas: Anhänge, Kalender und Mutationen bleiben isoliert.
|
||||
- [ ] Anhänge heruntergeladen; Quotas und persistentes Volume geprüft.
|
||||
- [ ] Privates Dashboard ohne Analytics und ohne Cache; CSP ohne Browserfehler.
|
||||
- [ ] Kontakt-/Notdienst-Mailfluss und Fehlerbehandlung geprüft.
|
||||
- [ ] Build, Lint, Typprüfung, Sicherheitstests und Runtime-Audit erfolgreich.
|
||||
- [ ] Offenes Entwicklungs-Advisory und fixierte Image-Digests weiter beobachten.
|
||||
|
||||
## 4. Mail
|
||||
|
||||
- [ ] Eigene Versanddomain bei Resend verifizieren
|
||||
- [ ] `RESEND_API_KEY` fuer Produktion setzen
|
||||
- [ ] `EMAIL_FROM` auf eine verifizierte Absenderadresse setzen
|
||||
- [ ] `ADMIN_EMAIL` fuer Kontaktformular setzen
|
||||
- [ ] Kontaktformular und Einladung/E-Mail-Flows einmal in Produktion testen
|
||||
|
||||
## 5. Uploads
|
||||
|
||||
- [ ] Coolify-Volume `kita_planer_uploads` fuer `/app/uploads` verwenden
|
||||
- [ ] Sicherstellen, dass Uploads nicht aus Versehen oeffentlich ausgeliefert werden
|
||||
- [ ] Backup-Strategie fuer Uploads klaeren
|
||||
|
||||
## 6. Rechtliches
|
||||
|
||||
- [ ] Platzhalter im Impressum ersetzen
|
||||
- [ ] Platzhalter in der Datenschutzerklaerung ersetzen
|
||||
- [ ] Hosting-Anbieter und Mail-Anbieter in Datenschutztext eintragen
|
||||
- [ ] Rechtliche Texte vor Livegang pruefen lassen
|
||||
|
||||
## 7. Build & Smoke Test
|
||||
|
||||
- [ ] Dependencies installieren: `npm ci`
|
||||
- [ ] Production Build erstellen: `npm run build:prod`
|
||||
- [ ] App starten: `npm run start:prod`
|
||||
- [ ] Startseite, Login, Dashboard und Kontaktformular testen
|
||||
|
||||
## 8. Coolify
|
||||
|
||||
- [ ] Code nach Gitea pushen
|
||||
- [ ] In Coolify eine Application aus dem Gitea-Repository anlegen
|
||||
- [ ] Build Pack `Docker Compose` waehlen
|
||||
- [ ] Compose-Datei `docker-compose.coolify.yml` verwenden
|
||||
- [ ] Environment Variables in Coolify eintragen, nicht ins Repo committen
|
||||
- [ ] Domain auf den `app`-Service und Container-Port `3000` routen
|
||||
- [ ] Upload-Volume `kita_planer_uploads` bleibt zwischen Deployments erhalten
|
||||
Details und Befehle stehen in [README.md](README.md). Lokale Tests ersetzen nicht die Kontrolle der produktiven TLS-, Proxy-, Backup-, Mail- und Container-Konfiguration.
|
||||
|
||||
Reference in New Issue
Block a user