Verteidigung in der Tiefe – Sicherheit
Überblick
Sicherheit ist mehrschichtig, geht davon aus, dass jede einzelne Schicht versagen kann, und gewährt die geringsten Privilegien, die funktionieren. Angreifer finden die Schicht, die Sie vergessen haben – ein System, das sich auf eine einzige Mauer verlässt, stürzt ein, wenn diese Mauer einen Fehler aufweist; überlappende Least-Privilege-Kontrollen überleben das Versagen einer einzelnen.
Die Prinzipien (universell)
- Erstellen Sie ein Bedrohungsmodell, bevor Sie etwas bauen, das nicht vertrauenswürdige Eingaben, Geheimnisse oder Benutzerdaten verarbeitet. Ein leichter STRIDE-Durchlauf (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) pro neuer Oberfläche. Halten Sie das Modell und die Gegenmaßnahmen fest (siehe
recording-decisions). - Verteidigung in der Tiefe. Keine einzelne Kontrolle ist "die" Sicherheit. Authentifizierung, Autorisierung, Eingabevalidierung und Durchsetzung auf Datenebene gehen jeweils davon aus, dass die anderen umgangen werden könnten.
- Geringste Privilegien überall – Rollen, Tokens, Dienstkonten, DB-Berechtigungen. Standardmäßig kein Zugriff; gewähren Sie das Minimum; widerrufen Sie das Ungenutzte.
- Geheimnisse leben niemals in Code, Images oder committeden Konfigurationen. Sie stammen zur Laufzeit aus einem Secret Store, werden rotiert und sind auf die Arbeitslast beschränkt, die sie benötigt.
- Validieren Sie alle Eingaben an der Vertrauensgrenze; behandeln Sie jede Ausgabe eines externen Systems als nicht vertrauenswürdige Daten, niemals als Anweisungen.
- Die Abhängigkeiten-Lieferkette ist eine Angriffsfläche. Lockfiles committed und auf Integrität geprüft; Abhängigkeiten gescannt und aktualisiert; Basis-Images eingefroren und gescannt.
- Sensible Aktionen werden protokolliert – wer hat was wann getan – so dass Missbrauch und Fehler rekonstruierbar sind.
Kurzreferenz
| Oberfläche | Erste Fragen |
|---|---|
| Neuer Endpunkt, der Benutzereingaben akzeptiert | Wie sieht das STRIDE-Modell aus? Wo ist die Validierung? Was ist die minimal benötigte Rolle? |
| Alles mit einem Geheimnis | Ist es im Secret Store (nicht in Code/Image)? Begrenzt? Rotierbar? |
| Neue Abhängigkeit | Ist die Lockdatei eingefroren? Gescant? Wird es gut unterstützt? |
| Privilegierte Mutation | Wird sie protokolliert? Ist der Akteur auf Datenebene autorisiert, nicht nur in der App? |
Stack-Mechanismen
RLS als letzte Durchsetzungsschicht, GraphQL-Tiefen-/Kostenbegrenzung als DoS-Schutz, Key Vault für Geheimnisse, pnpm audit/Trivy in CI – siehe postgres-postgraphile-rls-and-sql und cloud-delivery-aks.
Durchsetzung: Abhängigkeits-Audit + Image-Scanning + Secret-Scanning in CI (blockierend); Bedrohungsmodelle und Audit-Abdeckung sind Prüferentscheidung.
Vollständige Begründung: Artikel X & XIV der Verfassung, gebündelt in engineering-constitution/references/engineering-constitution.md.