Security Architecture: Frameworks, Patterns und Praktische Umsetzung
Umfassender Guide zur Security Architecture: Zero Trust, Defense in Depth, NIST CSF, Cloud Security Architecture, Netzwerk-Segmentierung und wie Security-Architektur-Entscheidungen Angriffe verhindern oder erschweren. Mit konkreten Architektur-Diagrammen und Implementierungshinweisen.
Inhaltsverzeichnis (6 Abschnitte)
Security Architecture ist die disziplinierte Praxis, Sicherheitsprinzipien in technische und organisatorische Strukturen zu übersetzen. Gute Security Architecture erschwert Angriffe systematisch - statt einzelne Maßnahmen isoliert zu implementieren, schafft sie ein kohärentes Schutzgefüge, das auch beim Versagen einzelner Kontrollen trägt.
Die wichtigsten Security-Architektur-Prinzipien
Grundprinzipien (zeitlos, unabhängig von Technologie):
1. Defense in Depth (Tiefenverteidigung):
→ Mehrere Schutzschichten: wenn eine versagt, schützt die nächste
→ Nicht: "Firewall ist sicher, dahinter kein Schutz nötig"
→ Schichten: Perimeter → Netz → Endpoint → Anwendung → Daten
→ Angreifer muss JEDE Schicht überwinden
2. Least Privilege (minimale Rechte):
→ Jede Komponente bekommt NUR die Rechte die sie braucht
→ Service-Account für DB: nur SELECT auf bestimmten Tabellen
→ Admin-Accounts: getrennt von Benutzer-Accounts
→ Zeitlich begrenzte Privilegien (Just-in-Time Access)
3. Separation of Duties:
→ Kritische Aktionen brauchen mehrere Akteure
→ Niemand kann alleine kritische Systeme kompromittieren
→ Beispiel: 4-Augen-Prinzip für Produktions-Deployments
4. Fail Secure (sicheres Versagen):
→ Bei Fehler/Ausfall: Zugang verweigern statt gewähren
→ Firewall-Ausfall: kein Traffic durch (nicht alle durch!)
→ IPS Fail-Closed: lieber Downtime als ungeschützter Traffic
5. Zero Trust (kein implizites Vertrauen):
→ "Never trust, always verify"
→ Kein Vertrauen aufgrund von Netzwerk-Position
→ Jeder Zugriff wird verifiziert: Identität + Gerät + Kontext
6. Economy of Mechanism (Einfachheit):
→ Komplexe Systeme haben mehr Angriffsfläche
→ Einfache, überprüfbare Mechanismen bevorzugen
→ Jede unnötige Komponente entfernen
7. Complete Mediation:
→ JEDER Zugriff auf JEDE Ressource wird geprüft
→ Kein Caching von Berechtigungsentscheidungen
→ Kann Performance kosten - aber kritisch für SicherheitNetzwerk-Segmentierung - Architekturgrundlage
Traditionelle (flache) Netzarchitektur - GEFÄHRLICH:
Internet → Firewall → [ Alles im selben /16 Netz ]
→ Workstations
→ Server
→ Datenbanken
→ Drucker
→ IoT-Geräte
Problem: ein kompromittierter Rechner → Zugang zu allem!
---
Moderne segmentierte Netzarchitektur:
Internet
│
▼
[Perimeter-Firewall / UTM]
│
├── DMZ (10.0.1.0/24) - öffentlich erreichbare Services
│ ├── Web-Server (10.0.1.10)
│ ├── Mail-Gateway (10.0.1.20)
│ └── VPN-Gateway (10.0.1.30)
│
├── Server-Zone (10.0.2.0/24) - interne Server
│ ├── Anwendungsserver (10.0.2.10-50)
│ ├── File-Server (10.0.2.60)
│ └── AD-Controller (10.0.2.70-71)
│
├── Datenbank-Zone (10.0.3.0/24) - nur von App-Zone erreichbar
│ ├── SQL-Server (10.0.3.10)
│ └── ERP-DB (10.0.3.20)
│
├── Client-Zone (10.0.10.0/23) - Workstations
│ ├── Management-VLAN (10.0.10.0/24)
│ └── User-VLAN (10.0.11.0/24)
│
├── Management-Zone (10.0.100.0/24) - Out-of-Band-Management
│ ├── IPMI/iDRAC (Server-Management)
│ ├── SIEM (10.0.100.10)
│ └── Jump-Host (10.0.100.20) - einziger Weg in Server-Zone
│
└── IoT/OT-Zone (10.0.200.0/24) - keine Verbindung ins Büronetz
├── Drucker, Kameras
└── Produktionsanlagen (OT)
Firewall-Regeln zwischen Zonen:
Client → Server: nur spezifische Ports (HTTP/HTTPS, SMB für Fileserver)
Server → DB: nur DB-Ports von definierten App-Servern
IoT → Alles: KEIN ausgehender Traffic (nur Internet-Updates über Proxy)
DMZ → intern: KEIN direkter Zugriff (DMZ muss gebrochen werden zuerst)
Management: nur vom Jump-Host erreichbarZero Trust Architecture (ZTA)
Zero Trust Architecture nach NIST SP 800-207:
Kernkomponenten:
Policy Engine (PE):
→ Entscheidet: Zugriff erlaubt oder abgelehnt?
→ Berücksichtigt: Identität, Gerätezustand, Kontext, Risiko
→ Beispiel: Microsoft Entra Conditional Access
Policy Administrator (PA):
→ Setzt Entscheidung des PE um
→ Erstellt/löscht Kommunikationspfade
→ Verwaltet Sitzungs-Tokens
Policy Enforcement Point (PEP):
→ Sitzt zwischen Resource und Subject
→ Blockiert Traffic bis PE erlaubt
→ Beispiel: ZTNA-Gateway, API-Gateway
Zero Trust Evaluation für jeden Zugriffsversuch:
Request: User → Anwendung
│
▼
[Identity Broker (z.B. Entra ID)]
→ Ist User bekannt?
→ Ist MFA erfüllt?
→ Ist Account nicht kompromittiert? (UEBA-Signal)
│
▼
[Device Compliance (z.B. Intune)]
→ Ist Gerät im MDM registriert?
→ Ist OS aktuell gepatcht?
→ Ist EDR aktiv?
→ Kein Jailbreak/Rooting?
│
▼
[Context Engine]
→ Normaler Arbeitsort? (Geo-IP)
→ Normale Uhrzeit?
→ Normales Verhaltensmuster?
→ Risikowert aus UEBA?
│
▼
[Policy Decision]
→ Alle Checks OK → Zugriff auf DIESE App gewährt
→ Check fehlgeschlagen → Step-up Auth (MFA) oder Ablehnung
→ Hochrisiko → Quarantäne, SOC-Alert
Ergebnis: User kann DIESE App benutzen
ABER NICHT das gesamte Netzwerk!Identity-zentrierte Security Architecture
IAM als Fundament moderner Security Architecture:
Identitätsprovider (IdP):
→ Single Source of Truth für alle Identitäten
→ On-Premises: Active Directory, LDAP
→ Cloud: Microsoft Entra ID, Okta, Google Workspace
→ Hybrid: AD + Azure AD Sync
Privileged Access Management (PAM):
→ Alle Admin-Accounts in PAM-Vault (CyberArk, BeyondTrust, Hashicorp Vault)
→ Just-in-Time (JIT): Admin-Rechte nur für 30 Minuten
→ Session Recording: alle Admin-Sessions aufgezeichnet
→ Credential Checkout: automatisch rotierende Passwörter
Service Account Management:
→ Kein Mensch kennt Service-Account-Passwort
→ Secrets Manager (Vault, AWS Secrets Manager) verwaltet Credentials
→ Automatic Rotation: alle 90 Tage oder bei Verdacht
→ Least Privilege: Service darf nur was er braucht
Conditional Access Matrix Beispiel:
User-Typ App Device Location Ergebnis
Admin AD-Konsole Managed PC Büro Erlaubt
Admin AD-Konsole Unmanaged Extern Ablehnung
User Office365 Managed PC Überall Erlaubt
User Office365 Unmanaged Extern MFA-Pflicht + Browser-only
User SAP ERP Unmanaged Extern AblehnungCloud Security Architecture
AWS Multi-Account-Strategie (Landing Zone):
┌─────────────────────────────────────────────────────────────────┐
│ AWS Organizations │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Management │ │ Security │ │ Workload │ │
│ │ Account │ │ Account │ │ OU │ │
│ │ (Billing, │ │ (GuardDuty, │ │ ┌────┐ ┌────┐ │ │
│ │ Org SCPs) │ │ SecurityHub,│ │ │Dev │ │Prod│ │ │
│ └─────────────┘ │ CloudTrail) │ │ │ │ │ │ │ │
│ └──────────────┘ │ └────┘ └────┘ │ │
│ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Security Account konsolidiert:
→ GuardDuty: alle Accounts → Security Account
→ CloudTrail: alle Accounts → zentrales S3 (unveränderlich)
→ SecurityHub: alle Findings aggregiert
→ Config: Compliance-Regeln für alle Accounts
Wichtige AWS-Sicherheitsservices:
GuardDuty: Threat Detection (ML-basiert)
SecurityHub: Compliance + Finding-Aggregation
Macie: S3-Datenschutz (PII-Erkennung)
IAM Access Analyzer: externe Zugriffe auf Ressourcen
CloudTrail: API-Audit-Log (UNVERÄNDERLICH!)
VPC Flow Logs: Netzwerkverkehr in AWS
Config: Ressourcen-Änderungs-Tracking
Azure-Äquivalent:
GuardDuty → Microsoft Defender for Cloud
CloudTrail → Azure Activity Log + Diagnostic Settings
SecurityHub → Microsoft Sentinel
IAM → Azure AD + Azure RBAC
VPC Logs → NSG Flow LogsNIST Cybersecurity Framework 2.0
NIST CSF 2.0 (2024) - 6 Funktionen:
GOVERN (neu in 2.0):
→ Cybersecurity-Risikomanagement-Strategie
→ Rollen und Verantwortlichkeiten
→ Policies, Prozesse, Verfahren
IDENTIFY:
→ Asset Management: alle Assets inventarisieren
→ Risk Assessment: was sind unsere Risiken?
→ Supply Chain Risk Management
→ Vulnerability Management
PROTECT:
→ Identity Management und Access Control
→ Awareness Training
→ Data Security (Verschlüsselung, DLP)
→ Platform Security (Patches, Härtung)
→ Technology Infrastructure Resilience
DETECT:
→ Continuous Monitoring
→ Adverse Event Analysis
→ SIEM/NDR/EDR
RESPOND:
→ Incident Response Plan
→ Incident Analysis
→ Incident Mitigation
→ Improvements
RECOVER:
→ Disaster Recovery
→ Backup und Restore
→ Communication während Recovery
Für Security Architecture relevant:
→ IDENTIFY: ohne vollständiges Asset-Inventar keine Architektur
→ PROTECT: die technischen Kontrollen (was wir bauen)
→ DETECT: die Monitoring-Schicht (was wir sehen können)
→ Zusammenhang: Architektur muss alle 5 Funktionen bedienenFragen zu diesem Thema?
Unsere Experten beraten Sie kostenlos und unverbindlich.
Über den Autor
Geschäftsführender Gesellschafter der AWARE7 GmbH mit langjähriger Expertise in Informationssicherheit, Penetrationstesting und IT-Risikomanagement. Absolvent des Masterstudiengangs Internet-Sicherheit an der Westfälischen Hochschule (if(is), Prof. Norbert Pohlmann). Bestseller-Autor im Wiley-VCH Verlag und Lehrbeauftragter der ASW-Akademie. Einschätzungen zu Cybersecurity und digitaler Souveränität erschienen u.a. in Welt am Sonntag, WDR, Deutschlandfunk und Handelsblatt.
10 Publikationen
- Einsatz von elektronischer Verschlüsselung - Hemmnisse für die Wirtschaft (2018)
- Kompass IT-Verschlüsselung - Orientierungshilfen für KMU (2018)
- IT Security Day 2025 - Live Hacking: KI in der Cybersicherheit (2025)
- Live Hacking - Credential Stuffing: Finanzrisiken jenseits Ransomware (2025)
- Keynote: Live Hacking Show - Ein Blick in die Welt der Cyberkriminalität (2025)
- Analyse von Angriffsflächen bei Shared-Hosting-Anbietern (2024)
- Gänsehaut garantiert: Die schaurigsten Funde aus dem Leben eines Pentesters (2022)
- IT Security Zertifizierungen — CISSP, T.I.S.P. & Co (Live-Webinar) (2023)
- Sicherheitsforum Online-Banking — Live Hacking (2021)
- Nipster im Netz und das Ende der Kreidezeit (2017)
IT-Grundschutz-Praktiker (TÜV) IT Risk Manager (DGI) § 8a BSIG Prüfverfahrenskompetenz Ausbilderprüfung (IHK)
