Security Architecture: Frameworks, Patterns und Praktische Umsetzung

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

1. Defense in Depth (Tiefenverteidigung): Mehrere Schutzschichten sorgen dafür, dass beim Versagen einer Schicht die nächste schützt. Die Schichten verlaufen von Perimeter über Netz und Endpoint bis hin zu Anwendung und Daten. Ein Angreifer muss jede Schicht überwinden.

2. Least Privilege (minimale Rechte): Jede Komponente erhält nur die Rechte, die sie tatsächlich braucht. Service-Accounts erhalten nur SELECT-Rechte auf bestimmten Tabellen. Admin-Accounts sind getrennt von Benutzer-Accounts. Zeitlich begrenzte Privilegien (Just-in-Time Access) reduzieren das Angriffsfenster.

3. Separation of Duties: Kritische Aktionen erfordern mehrere Akteure. Niemand kann alleine kritische Systeme kompromittieren. Das 4-Augen-Prinzip für Produktions-Deployments ist ein typisches Beispiel.

4. Fail Secure (sicheres Versagen): Bei Fehler oder Ausfall wird Zugang verweigert statt gewährt. Ein Firewall-Ausfall bedeutet keinen Durchlass, sondern Downtime. IPS im Fail-Closed-Modus bevorzugt Downtime gegenüber ungeschütztem 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 und Kontext.

6. Economy of Mechanism (Einfachheit): Komplexe Systeme haben mehr Angriffsfläche. Einfache, überprüfbare Mechanismen sind zu bevorzugen. Jede unnötige Komponente sollte entfernt werden.

7. Complete Mediation: Jeder Zugriff auf jede Ressource wird geprüft. Kein Caching von Berechtigungsentscheidungen - das kostet Performance, ist aber kritisch für Sicherheit.

Netzwerk-Segmentierung - Architekturgrundlage

Eine traditionelle flache Netzarchitektur ist gefährlich: Alle Systeme (Workstations, Server, Datenbanken, Drucker, IoT) liegen im selben Subnetz hinter einer Firewall. Ein einziger kompromittierter Rechner bedeutet Zugang zu allem.

Eine moderne segmentierte Netzarchitektur trennt dagegen strikt nach Funktion:

DMZ (10.0.1.0/24): Öffentlich erreichbare Dienste - Web-Server, Mail-Gateway, VPN-Gateway
Server-Zone (10.0.2.0/24): Interne Server, Anwendungsserver, File-Server, AD-Controller
Datenbank-Zone (10.0.3.0/24): Nur von der App-Zone erreichbar - SQL-Server, ERP-DB
Client-Zone (10.0.10.0/23): Workstations, aufgeteilt in Management-VLAN und User-VLAN
Management-Zone (10.0.100.0/24): Out-of-Band-Management, IPMI/iDRAC, SIEM, Jump-Host
IoT/OT-Zone (10.0.200.0/24): Keine Verbindung ins Büronetz - Drucker, Kameras, Produktionsanlagen

Die Firewall-Regeln zwischen Zonen erlauben nur definierte Verbindungen: Clients dürfen auf Server nur über spezifische Ports, Server dürfen Datenbanken nur auf DB-Ports von definierten App-Servern erreichen. IoT hat keinen ausgehenden Traffic (nur Internet-Updates über Proxy). Die DMZ hat keinen direkten Zugriff ins interne Netz. Die Management-Zone ist ausschließlich vom Jump-Host erreichbar.

Zero Trust Architecture (ZTA)

Zero Trust Architecture nach NIST SP 800-207 basiert auf drei Kernkomponenten:

Policy Engine (PE): Entscheidet ob ein Zugriff erlaubt oder abgelehnt wird, basierend auf Identität, Gerätezustand, Kontext und Risiko. Beispiel: Microsoft Entra Conditional Access.

Policy Administrator (PA): Setzt die Entscheidung des PE um, erstellt oder löscht Kommunikationspfade und verwaltet Sitzungs-Tokens.

Policy Enforcement Point (PEP): Sitzt zwischen Resource und Subject, blockiert Traffic bis der PE erlaubt. Beispiel: ZTNA-Gateway, API-Gateway.

Bei jedem Zugriffsversuch werden nacheinander geprüft: Identität (Ist der User bekannt? Ist MFA erfüllt? Ist der Account nicht kompromittiert?), Gerät-Compliance (Ist das Gerät im MDM registriert? Ist das OS aktuell? Ist EDR aktiv?), Kontext (Normaler Arbeitsort? Normale Uhrzeit? Normales Verhaltensmuster? Risikowert aus UEBA?). Das Ergebnis ist entweder Zugriff auf genau diese eine Anwendung - aber nicht das gesamte Netzwerk - oder eine Step-up-Authentifizierung bzw. vollständige Ablehnung.

Identity-zentrierte Security Architecture

IAM ist das Fundament moderner Security Architecture. Der Identitätsprovider (IdP) ist die Single Source of Truth für alle Identitäten: On-Premises mit Active Directory oder LDAP, in der Cloud mit Microsoft Entra ID, Okta oder Google Workspace, hybrid mit AD plus Azure AD Sync.

Privileged Access Management (PAM) verwaltet alle Admin-Accounts in einem PAM-Vault (CyberArk, BeyondTrust, HashiCorp Vault) mit Just-in-Time-Rechten (z.B. 30 Minuten), Session Recording aller Admin-Sessions und automatisch rotierenden Passwörtern über Credential Checkout.

Service Account Management bedeutet, dass kein Mensch das Service-Account-Passwort kennt. Ein Secrets Manager (Vault, AWS Secrets Manager) verwaltet die Credentials mit automatischer Rotation alle 90 Tage oder bei Verdacht. Jeder Service erhält nur die Rechte, die er benötigt.

Eine typische Conditional Access Matrix:

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	Ablehnung

Cloud Security Architecture

Eine AWS Multi-Account-Strategie (Landing Zone) trennt zwischen dem Management Account (Billing, Org SCPs), dem Security Account (GuardDuty, SecurityHub, CloudTrail) und Workload-Accounts nach Umgebung (Dev, Prod) innerhalb von AWS Organizations.

Der Security Account konsolidiert alle Sicherheitsdaten: GuardDuty-Findings aus allen Accounts, CloudTrail-Logs in einem unveränderlichen zentralen S3-Bucket, SecurityHub für aggregierte Findings und Config für Compliance-Regeln über alle Accounts.

Wichtige AWS-Sicherheitsservices im Überblick:

GuardDuty: ML-basierte Threat Detection
SecurityHub: Compliance und Finding-Aggregation
Macie: S3-Datenschutz mit PII-Erkennung
IAM Access Analyzer: Externe Zugriffe auf Ressourcen
CloudTrail: Unveränderliches API-Audit-Log
VPC Flow Logs: Netzwerkverkehr in AWS
Config: Ressourcen-Änderungs-Tracking

Azure-Äquivalente: Microsoft Defender for Cloud (GuardDuty), Azure Activity Log + Diagnostic Settings (CloudTrail), Microsoft Sentinel (SecurityHub), Azure AD + Azure RBAC (IAM), NSG Flow Logs (VPC Logs).

NIST Cybersecurity Framework 2.0

Das NIST CSF 2.0 (2024) definiert sechs Funktionen:

GOVERN (neu in 2.0): Cybersecurity-Risikomanagement-Strategie, Rollen und Verantwortlichkeiten, Policies und Prozesse.

IDENTIFY: Asset Management (alle Assets inventarisieren), Risk Assessment, 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, Kommunikation während Recovery.

Für Security Architecture ist der Zusammenhang entscheidend: IDENTIFY liefert ohne vollständiges Asset-Inventar keine Basis für Architekturentscheidungen. PROTECT beschreibt die technischen Kontrollen. DETECT beschreibt die Monitoring-Schicht. Die Architektur muss alle Funktionen bedienen.