In diesem Abschnitt befassen wir uns mit den spezifischen Architekturkomponenten, die eine Cloud-Anwendung sicher, isoliert und skalierbar machen.
Zusätzliche Sicherheitskomponenten
Auch wenn die hier beschriebenen Komponenten in der CCSP-Outline als „zusätzliche“ bezeichnet werden, da sie ergänzende Schutzschichten bieten, sind sie mittlerweile ein fester Bestandteil mehrschichtiger Sicherheitsarchitekturen (Defense in Depth) geworden. Unsere Komponenten sind:
- Web Application Firewalls (WAFs)
- Database Activity Monitoring (DAM)
- XML-Firewalls
- API-Gateways
Web Application Firewall (WAF)
Eine WAF ist eine Sicherheitskomponente, die Webanwendungen vor verschiedenen Angriffsarten schützt. Sie kann in verschiedenen Formfaktoren bereitgestellt werden: als Hardware- oder Software-Appliance oder als cloudbasierter Service (Cloudflare ist ein bekanntes Beispiel für Letzteres).
Die WAF agiert als Reverse Proxy auf Layer 7 des OSI-Modells und analysiert den eingehenden HTTPS-Verkehr. Auf Basis vordefinierter Sicherheitsregeln entscheidet sie, ob eingehende Anfragen zugelassen oder blockiert werden. Aus Sicht der Netzwerkarchitektur befindet sich die WAF zwischen dem Internet und der Webanwendung. Eine ist WAF keine klassische Netzwerk-Firewall, sondern eine Ergänzung auf Anwendungsebene.
Typische Angriffsarten, gegen die eine WAF schützt:
- SQL Injection
- Cross-Site Scripting (XSS)
- File Inclusion
- Cross-Site Request Forgery (CSRF)
Weitere WAF-Funktionen:
- Rate Limiting
- Geo-Blocking
- Bot-Erkennung
- Protokollvalidierung
Wichtig zu beachten: Eine WAF schützt nicht vor Sicherheitslücken im Anwendungscode selbst. Sie ist ein kompensierendes Kontrollinstrument, das Angriffe abmildert.
Database Activity Monitoring (DAM)
DAM dient der Überwachung und Analyse von Datenbankaktivitäten direkt auf Datenbankebene. Das Ziel besteht darin, unbefugte Zugriffe oder verdächtige Datenbankabfragen in Echtzeit zu erkennen und zu blockieren.
Technisch kann DAM auf zwei Arten (oft werden beide Methoden kombiniert) implementiert werden:
- agent-basiert – ein Software-Agent wird direkt auf dem Datenbankserver installiert und überwacht alle Aktivitäten, auch lokale Zugriffe aus dem SQL-Server selbst.
- netzwerk-basiert – ein passiver Sensor überwacht den Netzwerkverkehr zur Datenbank, ohne direkt auf dem Server installiert zu sein.
DAM ist ein gutes Beispiel für die Defense-in-Depth-Strategie: Wie die WAF schützt es dahinterliegende Datenbanken gegen SQL-Injections, allerdings auf einer anderen Ebene. Eine WAF erkennt SQL-Injections und blockiert sie, bevor die Anfrage die Datenbank erreicht. DAM erkennt hingegen direkt an der Datenbank bösartige SQL-Abfragen, also auch dann, wenn die WAF versagt hat.
XML-Firewalls
Eine XML-Firewall ist eine spezialisierte Firewall, die ebenfalls wie WAF zwischen Client und Anwendung platziert wird, um die jede eingehende XML-Anfragen zu überwachen und zu validieren.
API-Gateways
Die Funktionsweise von API-Gateways wurde bereits in Abschnitt 4.5 ausführlich beschrieben.
Kryptographie
Die Grundlagen der Kryptographie wie „Encryption in Transit“, „Encryption at Rest“ und Schlüsselmanagement wurden bereits in Abschnitt 1.3 ausführlich behandelt.
Im Kontext der Cloud-Anwendungsarchitektur ist der Aspekt „Encryption in Use“ (auch: Data in Use) relevant:
Wenn „Encryption in Transit“ und „Encryption at Rest” bereits zum Standard geworden ist, ist der Schutz von Daten während der aktiven Verarbeitung noch eine Herausforderung. Es liegt daran, dass die Daten während der Verarbeitung entschlüsselt werden müssen, was ein potenzielles Angriffsfenster öffnet.
Zwei untere Ansätze adressieren dieses Problem:
Confidential Computing – ist eine hardwarebasierte Technologie, die einen isolierten, verschlüsselten Bereich im Prozessor schafft, die sogenannte Trusted Execution Environment (TEE). Einfach erklärt bedeutet es, dass die Daten in einem abgeschlossenen Bereich verarbeitet werden, ohne dass der Hypervisor oder das Betriebssystem Einblick in die Daten haben. Mehr dazu auf den Seiten der jeweiligen Hersteller: Intel SGX, AMD SEV und ARM TrustZone.
Homomorphe Verschlüsselung – ist ein mathematisches Verfahren, das Berechnungen direkt auf verschlüsselten Daten ermöglicht, ohne sie vorher entschlüsseln zu müssen. Es ist aber eher ein theoretischer Einsatz.
Sandboxing
Eine Sandbox ist eine vollständig isolierte Umgebung, die vom restlichen System abgekapselt ist. Prozesse, Anwendungen oder Code werden innerhalb der Sandbox ausgeführt, ohne dass sie auf das darunterliegende System zugreifen können.
Sandboxing wird in verschiedenen Kontexten eingesetzt:
Sicherheitsanalyse. Die potenziell gefährlichen oder verdächtigen Dateien und Malware werden in einer Sandbox ausgeführt und analysiert. Viele Security-Produkte enthalten integrierte Sandboxing-Funktionalität oder lagern diese in die Cloud aus.
Softwareentwicklung. Je nach Situation können auch neue Features, APIs oder Updates vorab in einer Sandbox geprüft werden, bevor sie in die Produktion einfließen.
Browser und Betriebssystem. Moderne Browser mit integrierten Sandbox-Plugins in eigenen Sandboxes können dafür sorgen, dass bösartiger Web-Content auf das Betriebssystem zugreifen kann.
Application Virtualization und Orchestrierung
Die offizielle Bezeichnung „Application Virtualization“ aus dem Exam Outline klingt ein wenig irreführend und erinnert mich an ein Relikt aus der Vergangenheit: App-V von Microsoft.
Im modernen Cloud-Kontext steckt allerdings ein aktuelles Konzept dahinter: die Abstrahierung der Anwendung von der darunterliegenden Infrastruktur durch Containerisierung.
Container und Orchestrierung wurden bereits in Abschnitt 1.1 technisch ausreichend beschrieben. Aus Sicherheitsperspektive sind folgende Aspekte (nur ein Überblick!) besonders relevant:
Container-Sicherheit
Image-Scanning – Container-Images müssen vor dem Deployment auf bekannte Schwachstellen geprüft werden (z. B. mit Trivy, Snyk). Die Erfahrung zeigt aber, dass die Sicherheitslösungen auch nicht sicher sein können, mehr dazu hier.
Minimale Basis-Images – je weniger Komponenten ein Image enthält, desto kleiner die Angriffsfläche.
Keine privilegierten Container – Container sollten nie mit Root-Rechten laufen.
Immutable Infrastructure – Container sollten zur Laufzeit nicht verändert werden. Bei Bedarf muss ein neues Image deployed, aber nicht der laufende Container gepatcht.
Kubernetes-Sicherheit
- RBAC – strenge Zugriffskontrollen auf Cluster-Ebene.
- Network Policies – kontrollieren, welche Pods miteinander kommunizieren dürfen.
- Secrets Management – Kubernetes Secrets sollten verschlüsselt und idealerweise über externe Lösungen wie z.B. HashiCorp Vault verwaltet werden.
- Pod Security Standards – definieren, welche Sicherheitsanforderungen Pods erfüllen müssen.
Container- und Kubernetes-Sicherheit sind komplexe und umfangreiche Themen, die hier nur oberflächlich behandelt werden konnten. Wer tiefer einsteigen möchte, findet bei der CNCF (Cloud Native Computing Foundation) und im CIS Kubernetes Benchmark umfangreiche Ressourcen.
Orchestrierung
Mit einer immer wachsenden Anzahl von Containern und Microservices wird deren manuelle Verwaltung fast unmöglich. Um dieser Herausforderung entgegenzuwirken, kommen die Orchestrierungsplattformen zum Einsatz. Diese übernehmen die automatisierte Verwaltung, Skalierung, Verteilung und Überwachung von Containern. Kubernetes ist der De-facto-Standard für Container-Orchestrierung und sorgt dafür, dass die richtigen Container zur richtigen Zeit auf den richtigen Ressourcen laufen.