Security
In verteilten Systemen wächst die Angriffsfläche mit jeder Schnittstelle.
Microservices erhöhen:
- Anzahl APIs
- Anzahl Netzwerkverbindungen
- Anzahl Deployables
- Anzahl Credentials
Security ist deshalb kein Feature –
sie ist ein architektonisches Fundament.
Grundprinzip
Jeder Service ist potenziell ein Angriffspunkt.
Vertrauen ist niemals implizit.
1️⃣ Identität und Zugriff
Service-to-Service-Authentisierung
- mTLS oder signierte Tokens (z. B. JWT)
- Keine implizite Vertrauenszone im internen Netzwerk
- Zero-Trust-Grundprinzip
Autorisierung
- Rollen oder Claims pro Service
- Keine „All-Access“-Tokens
- Kontextbasierte Zugriffskontrolle
2️⃣ Secrets Management
- Keine statischen Credentials im Code
- Keine Secrets in Repositories
- Nutzung eines zentralen Secret-Stores
- Rotation von Tokens/Keys
Typischer Fehler: Hardcodierte Service-Accounts in Config-Dateien.
3️⃣ Least Privilege
Jeder Service erhält nur:
- Zugriff auf seine eigenen Daten
- Minimal notwendige Rechte
- Kein breites Netzwerk-Trust-Level
Wenn ein Service kompromittiert wird,
muss der Schaden isolierbar sein.
4️⃣ Verschlüsselung
- TLS für alle externen und internen Verbindungen
- Verschlüsselung sensibler Daten at Rest
- Key-Management klar geregelt
Interner Traffic ist nicht automatisch vertrauenswürdig.
5️⃣ API-Härtung
- Rate Limiting
- Input Validation
- Schema-Validierung
- Schutz gegen Injection-Angriffe
- CORS-Strategie definiert
Jede Schnittstelle ist öffentlich – mindestens intern.
Ergänzungen bei erhöhtem Risiko
Wenn regulatorische oder geschäftliche Risiken hoch sind:
- Threat Modeling pro kritischem Flow
- Regelmäßige Penetrationstests
- Dependency Scans (SCA)
- Container-Image-Scans
- Access Reviews
- Audit Trails
Mindest-Gates für produktive Systeme
- Service-to-Service Authentisierung ist verpflichtend.
- Secrets werden zentral verwaltet und rotiert.
- Kein Service hat globale Datenbankrechte.
- TLS ist durchgängig aktiviert.
- Logging enthält sicherheitsrelevante Events.
- Dependency-Scanning ist Teil der CI.
Typische Anti-Patterns
- „Internes Netzwerk ist sicher“
- Shared DB mit breiten Credentials
- Keine Token-Validierung bei internen Calls
- Hardcodierte API-Keys
- Keine Rotation von Secrets
- Keine Zugriffstrennung zwischen Umgebungen
Architekturelle Realität
In einem Monolithen ist die Angriffsfläche zentralisiert.
In Microservices ist sie verteilt.
Jede zusätzliche Schnittstelle erhöht:
- potenzielle Angriffsfläche
- Komplexität von Zugriffskontrolle
- Risiko von Credential-Leaks
Security muss deshalb von Anfang an:
- standardisiert
- automatisiert
- überprüfbar
sein.
Fazit
Microservices ohne konsequente Security-Standards sind:
- operativ riskant
- compliance-gefährlich
- schwer auditierbar
Security ist kein Add-on.
Sie ist eine systemische Eigenschaft verteilter Architektur.