Security Architecture Review: Das 20-Punkte-Audit, das wir bei jedem Engagement durchfuehren

Jedes Engagement, das wir bei CC Conceptualise durchfuehren, beginnt mit einem strukturierten Security Architecture Review. Ueber Jahre der Durchfuehrung dieser Assessments in regulierten Branchen haben wir eine 20-Punkte-Checkliste verfeinert, die zuverlaessig die sicherheitsrelevanten Luecken identifiziert, die tatsaechlich zaehlen. Keine theoretischen Risiken — die tatsaechlichen Schwaechen, die Angreifer ausnutzen und Auditoren beanstanden.

Dieser Artikel teilt unsere Methodik, die 20 Kontrollen, die wir bewerten, und das Scoring Framework, das wir zur Priorisierung der Remediation verwenden.

Bewertungsmethodik

Jede Kontrolle wird auf einer 0-5-Skala bewertet:

Score	Reifegrad	Beschreibung
0	Nicht vorhanden	Keine Kontrolle implementiert
1	Ad-hoc	Einige Aktivitaeten existieren, aber inkonsistent und undokumentiert
2	In Entwicklung	Kontrolle ist teilweise implementiert mit signifikanten Luecken
3	Definiert	Kontrolle ist implementiert und dokumentiert, aber nicht konsistent ueberwacht
4	Gesteuert	Kontrolle ist implementiert, ueberwacht und regelmaessig getestet
5	Optimierend	Kontrolle ist vollstaendig automatisiert, kontinuierlich ueberwacht und regelmaessig verbessert

Gesamtbewertung:

• 80-100 (von 100): Starke Postur — Fokus auf Optimierung
• 60-79: Moderate Postur — kritische Luecken innerhalb von 90 Tagen adressieren
• 40-59: Schwache Postur — signifikante Remediation erforderlich
• Unter 40: Kritisch — sofortige Massnahmen ueber mehrere Domaenen erforderlich

Die 20-Punkte-Checkliste

Loading diagram...

1. Identity und Access Management

Was wir bewerten:

• Ist phishing-resistente MFA fuer alle Benutzer erzwungen?
• Sind Conditional Access Policies umfassend und ohne gefaehrliche Ausschluesse?
• Ist PIM fuer alle privilegierten Rollen konfiguriert?
• Gibt es ueberzaehlige Global Administrators?
• Sind Break-Glass-Accounts ordnungsgemaess konfiguriert und ueberwacht?

Red Flags:

• Mehr als 2 permanente Global Administrators
• Conditional Access Policies mit breiten Ausschlussgruppen
• Keine MFA-Durchsetzung fuer Gastbenutzer
• Legacy Authentication Protocols noch erlaubt

Ziel: Score 4+

2. Netzwerksegmentierung

Was wir bewerten:

• Ist der Netzwerkverkehr zwischen Tiers segmentiert (Web, Application, Data)?
• Kontrollieren NSGs oder Azure Firewall den East-West-Traffic?
• Ist eine Hub-Spoke- oder Virtual-WAN-Topologie durchgesetzt?
• Sind Management-Ports (RDP, SSH) aus dem Internet erreichbar?
• Ist DNS Filtering implementiert?

Red Flags:

• Flaches Netzwerk mit allen Ressourcen in einem einzelnen Subnet
• NSGs, die * eingehend von * erlauben
• RDP/SSH-Ports zum Internet exponiert (selbst mit "nur meine IP")
• Keine Netzwerksegmentierung zwischen Production und Non-Production

Ziel: Score 3+

3. Datenverschluesselung

Was wir bewerten:

• Ist Encryption at Rest fuer alle Storage Services erzwungen?
• Werden Customer-Managed Keys (CMK) fuer sensible Daten verwendet?
• Ist TLS 1.2+ fuer alle Data in Transit erzwungen?
• Sind Datenbankverbindungen verschluesselt?
• Wird Key Vault fuer Key Management verwendet (keine hartcodierten Keys)?

Red Flags:

• Storage Accounts mit deaktivierter Infrastructure Encryption
• Datenbanken ueber unverschluesselte Verbindungen erreichbar
• TLS 1.0 oder 1.1 auf einem Endpoint noch erlaubt
• Verschluesselungsschluessel in Anwendungskonfiguration gespeichert

Ziel: Score 4+

4. Key und Secret Management

Was wir bewerten:

• Wird Azure Key Vault fuer alle Secrets, Keys und Zertifikate verwendet?
• Ist der Zugriff auf Key Vault per RBAC eingeschraenkt (nicht Legacy Access Policies)?
• Werden Secrets nach einem definierten Zeitplan rotiert?
• Ist Key Vault Soft Delete und Purge Protection aktiviert?
• Werden Key Vault Access Logs ueberwacht?

Red Flags:

• Secrets in Environment Variables, App Settings oder Source Code gespeichert
• Key Vault nutzt Legacy Access Policies statt RBAC
• Keine Secret-Rotation-Policy
• Purge Protection deaktiviert (ermoeglicht permanentes Loeschen)

Ziel: Score 4+

5. Logging und Monitoring

Was wir bewerten:

• Sind Diagnostic Settings fuer alle kritischen Ressourcen konfiguriert?
• Empfaengt ein zentraler Log Analytics Workspace alle sicherheitsrelevanten Logs?
• Werden Activity Logs fuer alle Subscriptions weitergeleitet?
• Ist die Log-Aufbewahrung fuer Compliance-Anforderungen konfiguriert (mindestens 365 Tage)?
• Sind Logs gegen Manipulation geschuetzt (Immutable Storage fuer Archiv)?

Red Flags:

• Keine zentralisierte Logging-Strategie
• Kritische Ressourcen ohne Diagnostic Settings
• Log-Aufbewahrung unter 90 Tagen
• Kein Schutz gegen Log-Loeschung durch kompromittierte Admin-Accounts

Ziel: Score 4+

6. Incident Response

Was wir bewerten:

• Gibt es einen dokumentierten Incident-Response-Plan?
• Wurde der Plan in den letzten 12 Monaten getestet?
• Sind automatisierte Detection- und Response-Playbooks konfiguriert?
• Gibt es einen externen IR-Retainer?
• Sind DORA/NIS2-Meldefristen mit aktuellem Tooling erreichbar?

Red Flags:

• Kein dokumentierter IR-Plan
• Plan existiert, wurde aber nie getestet
• Kein SIEM deployed (kein Sentinel oder Aequivalent)
• Keine externe IR-Faehigkeit retainiert

Ziel: Score 3+

7. Backup und Disaster Recovery

Was wir bewerten:

• Sind Backups fuer alle kritischen Systeme konfiguriert?
• Sind Backup Vaults Immutable?
• Werden Restore-Tests regelmaessig durchgefuehrt (monatlich fuer kritische Systeme)?
• Ist Cross-Region-Replication fuer DR konfiguriert?
• Ist RTO/RPO dokumentiert und durch Tests validiert?

Red Flags:

• Keine Immutable-Vault-Konfiguration
• Backups nie getestet (keine Restore-Evidenz)
• Single-Region-Deployment ohne DR-Plan
• Backup-Daten in derselben Subscription wie Production (anfaellig fuer Ransomware)

Ziel: Score 4+

8. Secrets Management in Pipelines

Was wir bewerten:

• Verwenden Service Connections Workload Identity Federation (keine Secrets)?
• Sind Pipeline Variables verschluesselt und angemessen scoped?
• Gibt es Secrets, die in Source Control committed sind?
• Ist Secret Scanning auf allen Repositories aktiviert?
• Werden Service-Principal-Credentials regelmaessig rotiert?

Red Flags:

• Langlebige Secrets in Pipeline Variables
• Service Principals mit Password Credentials (nicht Zertifikate oder Federated)
• Kein Secret Scanning auf Repositories
• Service Principals mit ueberzogenen Berechtigungen (Owner, Contributor auf Subscription-Ebene)

Ziel: Score 3+

9. API Security

Was wir bewerten:

• Ist Azure API Management oder ein aequivalentes Gateway im Einsatz?
• Sind APIs authentifiziert und autorisiert (nicht offen)?
• Ist Rate Limiting konfiguriert?
• Ist Input Validation implementiert?
• Werden APIs versioniert mit einer Deprecation-Strategie?

Red Flags:

• APIs direkt exponiert ohne Gateway
• Keine Authentifizierung bei internen APIs ("sie sind hinter der Firewall")
• Kein Rate Limiting (anfaellig fuer Missbrauch)
• API Keys als einziger Authentifizierungsmechanismus

Ziel: Score 3+

10. Container Security

Was wir bewerten:

• Werden Container-Images vor dem Deployment auf Schwachstellen gescannt?
• Wird eine private Container Registry verwendet (kein Pull aus oeffentlichem Docker Hub)?
• Laufen Container als Non-Root?
• Ist Kubernetes RBAC ordnungsgemaess konfiguriert?
• Sind Network Policies im Cluster erzwungen?

Red Flags:

• Kein Image Scanning in der CI/CD-Pipeline
• Images direkt aus oeffentlichen Registries in Production gezogen
• Container laufen als Root
• Kubernetes Cluster ohne Network Policies (flaches Cluster-Netzwerk)
• Default Service Account von Pods verwendet

Ziel: Score 3+

11. Supply Chain Security

Was wir bewerten:

• Werden SBOMs fuer alle Artefakte generiert?
• Ist Dependency Scanning in allen Pipelines konfiguriert?
• Werden Artefakte signiert?
• Wird ein Private Package Feed mit Upstream Source Management verwendet?
• Werden Dependency Updates verfolgt und innerhalb SLA angewendet?

Red Flags:

• Kein Dependency Scanning
• Direkte Nutzung oeffentlicher NuGet/npm Feeds ohne Kuration
• Keine SBOM-Generierung
• Verwundbare Abhaengigkeiten in Production ohne Remediation-Timeline

Ziel: Score 3+

12. Compliance und Governance

Was wir bewerten:

• Wird Azure Policy fuer Guardrails ueber das gesamte Estate verwendet?
• Sind regulatorische Compliance-Anforderungen technischen Kontrollen zugeordnet?
• Wird Compliance kontinuierlich ueberwacht (nicht nur Point-in-Time)?
• Sind Management Groups und Subscriptions mit ordnungsgemaesser Hierarchie strukturiert?
• Ist Tagging fuer Kosten- und Ownership-Verantwortlichkeit erzwungen?

Red Flags:

• Keine Azure Policy zugewiesen
• Compliance nur bei jaehrlichen Audits bewertet
• Flache Subscription-Struktur ohne Management-Group-Hierarchie
• Keine Tagging-Strategie

Ziel: Score 3+

13. Datenklassifizierung

Was wir bewerten:

• Ist ein Datenklassifizierungsschema definiert und angewendet?
• Sind Sensitivity Labels in Microsoft Purview konfiguriert?
• Ist DLP fuer sensible Datentypen konfiguriert?
• Werden Datenbehandlungsregeln technisch durchgesetzt (nicht nur per Policy)?
• Wird Data Discovery/Scanning fuer nicht klassifizierte Datenspeicher durchgefuehrt?

Red Flags:

• Kein Datenklassifizierungsschema
• Klassifizierung existiert auf Papier, aber keine technische Durchsetzung
• Sensible Daten in ungeschuetzten Storage Accounts
• Keine DLP-Regeln fuer Finanz-, Gesundheits- oder personenbezogene Daten

Ziel: Score 3+

14. Endpoint Protection

Was wir bewerten:

• Ist EDR auf allen Endpoints deployed (Workstations und Server)?
• Ist EDR mit dem SIEM fuer Korrelation integriert?
• Ist Automated Investigation and Response aktiviert?
• Werden Device Compliance Policies ueber Conditional Access durchgesetzt?
• Ist Application Control fuer Hochrisikoumgebungen konfiguriert?

Red Flags:

• EDR-Abdeckung unter 95% der verwalteten Geraete
• EDR Alerts nicht mit SIEM integriert
• Keine Device Compliance Policies
• Automatisierte Remediation deaktiviert

Ziel: Score 4+

15. E-Mail-Sicherheit

Was wir bewerten:

• Ist Defender for Office 365 (oder Aequivalent) deployed?
• Ist DMARC auf p=reject fuer die primaere Domain konfiguriert?
• Sind Anti-Phishing-Policies mit Impersonation Protection konfiguriert?
• Ist User Reporting fuer verdaechtige E-Mails aktiviert und ueberwacht?
• Werden Attack Simulation Exercises regelmaessig durchgefuehrt?

Red Flags:

• Kein erweitertes E-Mail-Filtering (nur auf Basis-Exchange-Online-Protection angewiesen)
• DMARC auf p=none oder nicht konfiguriert
• Kein Phishing-Simulationsprogramm
• Keine Safe Links/Safe Attachments

Ziel: Score 4+

16. WAF und DDoS-Schutz

Was wir bewerten:

• Ist Azure WAF oder Aequivalent vor allen oeffentlich zugaenglichen Anwendungen deployed?
• Sind WAF-Regeln im Prevention Mode (nicht nur Detection)?
• Ist DDoS Protection Standard auf oeffentlichen VNets aktiviert?
• Werden WAF-Logs ueberwacht und regelmaessig getuned?
• Ist Bot Management konfiguriert?

Red Flags:

• Oeffentlich zugaengliche Anwendungen ohne WAF
• WAF im Detection-Only-Modus ueber laengere Zeitraeume
• Kein DDoS-Schutz (nur auf Azure-Basisinfrastrukturschutz angewiesen)
• WAF mit Default-Regeln ohne anwendungsspezifisches Tuning

Ziel: Score 3+

17. Vulnerability Management

Was wir bewerten:

• Ist kontinuierliches Vulnerability Scanning deployed (Infrastruktur und Anwendungen)?
• Werden Schwachstellen mit Remediation-SLAs verfolgt?
• Gibt es einen definierten Prozess fuer kritische/Zero-Day-Schwachstellen?
• Werden Vulnerability Trends verfolgt und an das Management berichtet?
• Wird die Scanning-Abdeckung validiert (werden alle Assets gescannt)?

Red Flags:

• Kein Vulnerability-Scanning-Programm
• Scan-Ergebnisse werden nicht verfolgt oder bearbeitet
• Kein SLA fuer Remediation
• Scanning-Abdeckung unter 90%

Ziel: Score 4+

18. Security Awareness Training

Was wir bewerten:

• Ist Security Awareness Training fuer alle Mitarbeiter verpflichtend?
• Wird das Training mindestens jaehrlich aufgefrischt?
• Werden Phishing-Simulationen regelmaessig durchgefuehrt (monatlich)?
• Werden Hochrisiko-Benutzer identifiziert und zusaetzlich geschult?
• Wird die Trainingseffektivitaet gemessen (nicht nur Abschluss)?

Red Flags:

• Kein verpflichtendes Security Training
• Training ist ein einmaliges Onboarding-Event ohne Auffrischung
• Keine Phishing-Simulationen
• Keine Messung der Trainingsauswirkung

Ziel: Score 3+

19. Third-Party-Risikomanagement

Was wir bewerten:

• Gibt es ein Register aller ICT-Drittanbieter?
• Werden Drittanbieter vor dem Onboarding sicherheitsbewertet?
• Sind vertragliche Sicherheitsanforderungen in Vereinbarungen enthalten?
• Werden kritische Drittanbieter kontinuierlich ueberwacht?
• Sind Exit-Strategien fuer kritische Anbieter dokumentiert?

Red Flags:

• Kein Drittanbieter-Inventar
• Keine Sicherheitsbewertung vor Engagement neuer Anbieter
• Keine vertraglichen Sicherheitsanforderungen
• Konzentrationsrisiko bei einem einzigen Anbieter ohne Exit-Plan

Ziel: Score 3+

20. Security Architecture-Dokumentation

Was wir bewerten:

• Sind Architekturdiagramme aktuell und enthalten Security Controls?
• Sind Data-Flow-Diagramme fuer kritische Anwendungen dokumentiert?
• Sind Trust Boundaries klar definiert?
• Ist das Shared-Responsibility-Modell fuer jeden Cloud Service dokumentiert?
• Werden Architekturentscheidungen (ADRs) mit Sicherheitsbegruendung aufgezeichnet?

Red Flags:

• Keine Architekturdokumentation
• Diagramme existieren, sind aber veraltet (aelter als 6 Monate)
• Keine Data-Flow-Diagramme fuer Anwendungen mit sensiblen Daten
• Keine klare Definition von Trust Boundaries

Ziel: Score 3+

Durchfuehrung des Assessments

Loading diagram...

Phase 1: Automatisierte Discovery (Tage 1-3)

Automatisiertes Scanning zur Erfassung faktischer Daten deployen:

• Defender for Cloud Secure Score und Empfehlungen
• Azure Policy Compliance State
• Azure Resource Graph Queries fuer Konfigurationsanalyse
• Sentinel Workbook fuer Security-Monitoring-Abdeckung
• Entra ID Reports fuer Identity Security State

Phase 2: Manuelle Validierung (Tage 4-8)

Automatisierte Findings validieren und Kontrollen bewerten, die menschliches Urteil erfordern:

• Security-, Platform- und Application-Teams interviewen
• Dokumentation pruefen (IR-Plan, Policies, Architekturdiagramme)
• Spezifische Kontrollen testen (Conditional Access umgehen versuchen, Backup Restore testen)
• Prozessreife ueber Tooldeployment hinaus bewerten

Phase 3: Scoring und Reporting (Tage 9-12)

• Jede Kontrolle 0-5 bewerten mit Evidenz und Begruendung
• Gesamtscore berechnen
• Top 5 der wirkungsvollsten Remediation-Massnahmen identifizieren
• Remediation-Anleitung mit Aufwandsschaetzungen liefern
• Stakeholdern mit Executive Summary und detaillierten Findings praesentieren

Nutzung der Ergebnisse

Das Review-Ergebnis sollte eine priorisierte Remediation-Roadmap antreiben:

1. Kritische Luecken (Score 0-1): Innerhalb von 30 Tagen adressieren
2. Signifikante Luecken (Score 2): Innerhalb von 90 Tagen adressieren
3. Verbesserungsmoeglichkeiten (Score 3): Fuer naechstes Quartal planen
4. Optimierung (Score 4): Continuous Improvement Backlog

Quartalsweise Nachbewertung der zuvor identifizierten Luecken, um die Remediation-Effektivitaet zu verifizieren und die Reifegradverbesserung ueber die Zeit zu verfolgen.

Fazit

Ein Security Architecture Review ist kein Audit, das man ueberleben muss — es ist eine Diagnose zur Verbesserung. Die 20 Kontrollen in dieser Checkliste repraesentieren die Baseline, die jede Enterprise-Azure-Umgebung erreichen sollte. Sie stimmen mit DORA, NIS2, ISO 27001 und den Anforderungen grosser Cyber-Versicherer ueberein.

Wenn Sie moechten, dass wir dieses Assessment in Ihrer Umgebung durchfuehren — oder wenn Sie interne Faehigkeiten aufbauen moechten, um es selbst durchzufuehren — kontaktieren Sie uns unter mbrahim@conceptualise.de. Wir liefern ehrliche Findings mit umsetzbarer Remediation-Anleitung, keinen 200-seitigen Bericht, der verstaubt.