Cloud design patterns
SANS Cloud Security Principles
Die CIS Controls (Center for Internet Security Controls) sind ein anbieterunabhängiges, praxisorientiertes Rahmenwerk zur systematischen Verbesserung der Informationssicherheit. Im Mittelpunkt stehen:
- die Inventarisierung und kontinuierliche Verwaltung von Hardware, Software und Datenbeständen,
- die Priorisierung von Risiken
- sowie die Implementierung wirksamer Schutzmaßnahmen gegen die häufigsten Angriffsmuster.
Im Gegensatz zu rein regulatorischen Standards legen die CIS Controls besonderen Wert auf umsetzbare, technisch konkrete Maßnahmen und eine priorisierte Einführung nach Reifegraden.
Link: https://www.sans.org/blog/cis-controls-v8
Well-Architected Framework
Neben anbieterunabhängigen Sicherheitsrahmenwerken stellen die großen Cloud-Service-Provider eigene Architekturleitlinien bereit, um bewährte Designprinzipien für ihre Plattformen zu vermitteln. Dazu zählen das AWS Well-Architected Framework, das Azure Well-Architected Framework, das Google Cloud Architecture Framework und das IBM Well-Architected Framework.
Diese Modelle definieren bewährte Verfahren für den Aufbau, den Betrieb und die kontinuierliche Verbesserung von Cloud-Architekturen innerhalb der jeweiligen Umgebung. Im Mittelpunkt stehen typischerweise mehrere zentrale Säulen (Pillars), darunter:
- Security: Schutz von Daten, Identitäten und Workloads
- Reliability: Ausfallsicherheit und Wiederherstellungsfähigkeit
- Performance Efficiency: optimale Ressourcennutzung
- Cost Optimization: Kostenkontrolle
- Operational Excellence: Automatisierung, Monitoring, Governance
Die genaue Ausgestaltung variiert je nach Anbieter, doch verfolgen alle Frameworks das gemeinsame Ziel, Architekturen zu entwickeln, die funktional, sicher, belastbar und wirtschaftlich tragfähig sind.
Die Well-Architected-Frameworks dienen dabei weniger als regulatorische Vorgaben, sondern vielmehr als kontinuierliches Bewertungs- und Verbesserungsinstrument für bestehende und neue Cloud-Workloads.
Links:
- https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
- https://learn.microsoft.com/en-us/azure/well-architected/
- https://www.ibm.com/think/architectures/well-architected
- https://docs.cloud.google.com/architecture/framework?hl=de
Cloud Security Alliance (CSA) Enterprise Architecture
Die Cloud Security Alliance (CSA) stellt mit ihrer Enterprise Architecture ein anbieterunabhängiges Rahmenwerk bereit, das die Cloud-Sicherheit in einen unternehmensweiten Kontext integriert. Im Gegensatz zu rein technischen Standards verfolgt die CSA einen ganzheitlichen Ansatz, der IT-Betrieb, Sicherheitsarchitektur und geschäftliche Anforderungen verbindet.
Die Schwerpunkte liegen unter anderem im Identitäts- und Zugriffsmanagement, im Schwachstellen- und Risikomanagement sowie im Datenschutz. Die Architektur gliedert sich in die Kernbereiche IT Operation Support Services (ITOSS), Technology Security Services (TSS) und Governance-orientierte Sicherheitsfunktionen. Das Ziel besteht darin, Sicherheitsmaßnahmen nicht isoliert technisch umzusetzen, sondern sie strategisch in die Unternehmensarchitektur zu integrieren.
Link: https://cloudsecurityalliance.org/artifacts/enterprise-architecture-reference-guide-v2
DevOps-Sicherheit
In diesem Abschnitt geht es um DevOps Security, auch bekannt als DevSecOps. Der Begriff steht für die Integration der drei Bereiche Development (Entwicklung), Security (Sicherheit) und Operations (Betrieb) in einen durchgängigen, iterativen Prozess.
Traditionell waren diese Bereiche oft voneinander isoliert: Die Entwicklungsabteilung programmierte, das Betriebsteam kümmerte sich um die Stabilität und die Sicherheitsabteilung kam erst am Ende hinzu.
Die Geschwindigkeit der modernen Softwareentwicklung kollidiert häufig mit traditionellen Sicherheitsprozessen und nachträglichen Sicherheitsmaßnahmen. Sicherheitsteams, die jedes Deployment manuell prüfen, werden zum Bottleneck. DevSecOps integriert Sicherheit in den Entwicklungsprozess selbst und löst genau dieses Problem, indem es:
- Sicherheitsverantwortung in jede Phase des Entwicklungszyklus integriert,
- kontinuierliche Zusammenarbeit zwischen allen beteiligten Teams fördert
- und Sicherheit wird so als gemeinsamer Qualitätsfaktor etabliert.
In einem Satz bedeutet DevSecOps: „Sicherheit ist kein nachgelagerter Kontrollschritt, sondern integraler Bestandteil des gesamten Entwicklungs- und Betriebsprozesses.“
DevSecOps-Lebenszyklus
Der DevSecOps-Zyklus ist ein kontinuierlicher Prozess, der alle Phasen von der Planung bis zum Betrieb umfasst (die Anzahl der Phasen kann abweisen). Er wird häufig in Form einer Endlosschleife (∞) dargestellt, um zu verdeutlichen, dass jede Phase in die nächste übergeht und durch kontinuierliches Feedback sowie automatisierte Sicherheitsprüfungen ergänzt wird.
Plan (Planung): In der Planungsphase werden Anforderungen, Ziele und Risiken definiert. Aus Sicherheitsperspektive werden in diesem Schritt Richtlinien, Compliance-Vorgaben sowie Bedrohungsmodelle (Threat Modeling) festgelegt. Diese Phase bildet die strategische Grundlage für alle weiteren Schritte.
Code (Entwicklung): Während der Entwicklung wird der Anwendungscode erstellt. Sicherheit zeigt sich hier in sicherer Programmierung, Code-Reviews und statischen Code-Analysen (SAST). Das Ziel besteht darin, Schwachstellen möglichst frühzeitig zu erkennen / zu vermeiden.
Build (Erstellung): Der Code wird kompiliert und in ausführbare Artefakte überführt. Sicherheitsmaßnahmen umfassen automatisierte Build-Prüfungen, Abhängigkeitsanalysen (Software Composition Analysis) und Integritäts-prüfungen, um manipulierte oder unsichere Komponenten frühzeitig zu erkennen.
Test (Testen): In der Testphase werden Funktionalität und Sicherheit validiert. Neben funktionalen Tests kommen dynamische Sicherheits-prüfungen (DAST), Schwachstellenscans und ggf. Penetrationstests zum Einsatz.
Release (Freigabe): Das geprüfte Build wird für die Bereitstellung vorbereitet. Sicherheitsrelevante Maßnahmen sind hier unter anderem die Signaturprüfung, formale Genehmigungsprozesse und definierte Security-Gates.
Bereitstellung (Deploy): Die Anwendung wird in die Produktionsumgebung ausgerollt. Automatisierte Konfigurations-Checks sowie Infrastructure-as-Code-Prüfungen stellen sicher, dass die Zielumgebung den definierten Sicherheitsanforderungen entspricht.
Betrieb (Operate): Im produktiven Betrieb greifen Nutzer auf die Anwendung zu. Laufendes Monitoring, Protokollanalyse und Intrusion Detection dienen dazu, Sicherheitsvorfälle frühzeitig zu erkennen.
Monitor (Überwachung und Feedback): In dieser Phase werden Betriebsdaten ausgewertet, Anomalien erkannt und Erkenntnisse für Verbesserungen gewonnen. SIEM-Integration, kontinuierliche Schwachstellenbewertung und Incident-Response-Prozesse unterstützen dabei. Die gewonnenen Erkenntnisse fließen zurück in die Planungsphase.
„Shift Left“ – Prinzip
Ein zentrales Prinzip von DevSecOps ist das sogenannte „Shift Left“, bei dem Sicherheitsprüfungen konsequent an den Beginn des Entwicklungs-prozesses verlagert werden. Im Shift-Left-Modell werden die Sicherheits-anforderungen bereits beim Entwurf und während der Programmierung berücksichtigt. Die Sicherheit wird somit nicht am Ende hinzugefügt, sondern von Anfang an integriert. Dadurch verbessert sich die Qualität der Software und das Risiko sicherheitsrelevanter Probleme in der Produktionsumgebung sinkt.
SAST und DAST sind die tragenden Säulen des Shift-Left-Prinzips:
SAST (Static Application Security Testing) analysiert den Quellcode direkt während der Entwicklung. So werden Schwachstellen wie Injection-Fehler oder Fehlkonfigurationen frühzeitig gefunden, sodass Entwickler diese sofort beheben können.
DAST (Dynamic Application Security Testing) prüft die laufende Anwendung dagegen von außen. Dazu werden reale Angriffe simuliert, um das Laufzeitverhalten zu testen.