Skip to content

Modul 9: Security Architecture — Schutz auf jeder Schicht

OWASP Top 10, Authentifizierung, Autorisierung, Zero Trust, Secrets Management. Sicherheit als Architekturentscheidung, nicht als Nachrüstung.

Fortschritt0/5 Lektionen
41

Security Architecture — Schutz auf jeder Schicht

Lektion 41 von 5

Sicherheit ist Architektur

Sicherheit, die man nachrüstet, ist teuer und lückenhaft. Sicherheit im Design ist billig und ganzheitlich. Die wichtigsten Maßnahmen sind nicht kryptografisch, sondern strukturell: Input-Validierung, Least Privilege, Defense in Depth, Secrets Management.

Lesson 1: OWASP Top 10 — die häufigsten Lücken

Injection (SQL, NoSQL, Command), Broken Authentication, Sensitive Data Exposure, XXE, Broken Access Control, Security Misconfiguration, XSS, Insecure Deserialization, Known Vulnerabilities, Insufficient Logging. Die Top 10 ändern sich langsam — die Prinzipien bleiben: Input validieren, Output encodieren, Least Privilege, Secrets nicht im Code.

Lesson 2: Authentifizierung vs. Autorisierung

Authentifizierung: Wer bist du? (Login, Token, MFA). Autorisierung: Darfst du das? (Rollen, Permissions). JWT (Stateless): Server signiert Token, Client schickt es bei jedem Request. Session (Stateful): Server speichert Session. OAuth 2.0 / OIDC: Delegierte Autorisierung (Third-Party-Login). MFA: Etwas, das man hat, plus etwas, das man weiß. RBAC: Rollen -> Permissions. ABAC: Attribute -> Permissions (flexibler).

// AuthN: Wer? — Token validieren (Filter, vor dem Controller)
@GetMapping("/api/claims/{id}")
@PreAuthorize("hasRole('SACHBEARBEITER')")   // AuthZ: Darf er?
public ClaimDto getClaim(@PathVariable Long id, Authentication auth) {
    // auth.getName() == Subject aus dem JWT (AuthN)
    // Rolle entscheidet über Zugriff (AuthZ) — nicht die Identität allein
    return claimService.findFor(auth.getName(), id);
}

Achtung: AuthN ohne AuthZ ist eine Tür ohne Schlösser — jeder Eingelassene darf alles.

Lesson 3: Zero Trust

„Never trust, always verify." Kein implizites Vertrauen aufgrund von Netzwerkgrenzen. Jeder Request wird authentifiziert und autorisiert, ob aus dem internen Netz oder extern. Microsegmentation: Services authentifizieren sich gegenseitig (mTLS). Keine offenen internen Endpoints. Defense in Depth: Mehrere Schichten (WAF, API-Gateway, Service-Level, DB-Level), nicht nur eine Außenmauer.

Lesson 4: Secrets Management

Secrets (API-Keys, Passwörter, Zertifikate) gehoren nie in den Code, nie in Environment-Variablen in Klartext, nie in Container-Images. Lösung: Ein Secrets-Manager (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets mit Encryption). Rotierung: Secrets werden regelmäßig gewechselt. Audit: Wer hat wann auf welches Secret zugegriffen? Spring Cloud Config mit Vault ist ein verbreiteter Stack.

Lesson 5: Input Validation und Output Encoding

Jede Eingabe ist bis zum Beweis des Gegenteils feindlich. Validierung: Whitelist über Blacklist (erlaube bekannte Werte, nicht verbiete bekannte Angriffe). Typ-Prüfung, Range-Prüfung, Format-Prüfung. Output Encoding: Je nach Kontext — HTML (XSS), SQL (Injection), LDAP, Command. ORM mit Prepared Statements verhindert SQL-Injection. Frameworks (Spring Validation, Bean Validation) zentralisieren die Validierung.

Least Privilege ist das Fundament

Jeder Service, jeder Benutzer, jeder Token hat genau die Rechte, die er braucht — nicht mehr. Ein Read-Only-API-Endpunkt braucht keinen DB-Schreibzugriff. Ein Microservice für Empfehlungen braucht keinen Zugriff auf die Payment-Tabelle. Least Privilege begrenzt den Schaden bei einem Kompromittierung: Wer nur lesen darf, kann nicht löschen.

Praxis-Szenario: Authentifizierung für eine Versicherungs-API

Du baust eine API mit drei Rollen: Kunden (sehen eigene Policen), Sachbearbeiter (sehen alle Policen, bewerten Schaden), Admins (verwalten Benutzer). Wie strukturierst du Auth und Authz?

✅ Wichtige Erkenntnisse

Haken setzen, um deinen Lernfortschritt zu markieren:

    This site uses essential cookies for Stripe payments. No tracking cookies.