Alexander Kaserbacher
27.03.2023
Security muss in Systemen von Anfang an mitgedacht werden. Die Security-Pillar der drei großen Architektur-Frameworks von Amazon Web Services (AWS), Microsoft Azure und Google Cloud beinhaltet eine Menge an Erfahrung und Wissen zu diesem wichtigen Cloud-Thema. Dieser Blogpost ist der dritte der Reihe "Well Architected Cloud" und beleuchtet das Thema genauer.
Sicherheit spielt für alle Systeme in der Cloud eine wichtige Rolle – deswegen ist die zugehörige Pillar so bedeutend. Im folgenden Beitrag hebe ich die Designprinzipien rund um Security heraus und diskutiere einige Themenfelder, die in der Pillar durch Best Practices abgedeckt sind. Falls Sie weiter in die Tiefe gehen möchten, finden Sie an den entsprechenden Stellen Referenzen. Die Namenskürzel der Verweise haben eine Bedeutung: Kürzel, die mit A beginnen, beziehen sich auf AWS, M auf Microsoft Azure und G auf Google Cloud.
Abbildung 1: Zusammengefasste Designprinzipien der Security-Pillar
Das Shared Responsibility Modell bildet die Grundlage unserer Überlegungen zum Thema Sicherheit in der Cloud. Es beschreibt die Aufteilung von Verantwortung über bestimmte Elemente, die für den Betrieb eines Systems notwendig sind. Dabei kann für jede dieser Verantwortlichkeiten entweder der Cloud-Anbieter oder der System-Betreiber (also der Kunde des Cloud-Anbieters) zuständig sein. Abbildung 2 zeig eine schematische Darstellung des Modells und ordnet wichtige Begriffe ein.
Abbildung 2: Das Shared Responsibility Modell - Je weiter rechts in der Betriebsart, umso so mehr Verantwortlichkeiten übernimmt der Cloud-Anbieter
Die Auslegung des Modells und die Wahl der Betriebsart (also z.B. On-Premises oder Serverless) hat gravierenden Einfluss auf Ihre Sicherheitsarchitektur als System-Betreiber. Je weiter links Sie sich einordnen, desto mehr Aufgaben haben Sie und desto mehr Expertise im Sicherheitsbereich brauchen Sie. Das liegt daran, dass die jeweiligen Verantwortlichkeiten unterschiedliche Skills zur Absicherung benötigen. Beispielsweise brauchen Sie zur Absicherung von Hardware und Rechenzentren anderes Know-How als zur Absicherung Ihres Anwendungscodes. Die Frameworks legen Ihnen als Best Practice somit nahe, Betriebsarten zu nehmen, die eher rechts im Modell angeordnet sind [AMS] [MAC]. Diese Betriebsarten geben Ihnen weniger Konfigurationsspielraum, da sie viele Verantwortlichkeiten and den Cloud-Betreiber auslagern.
Nach dem “Defense in depth”-Prinzip aus dem Abschnitt “Designprinzipien” sollen Sie Sicherheit auf all den Ebenen bedenken, die in Ihrer Verantwortung sind. Das ist ein Grund, wieso Betriebsarten auf der rechten Seite des Shared Responsibility Modells mit weniger Aufwand betreibbar sind. Erstens müssen Sie weniger Verantwortlichkeiten abdecken und zweitens sind die Cloud-Anbieter auf die Absicherung Ihrer Verantwortlichkeiten enorm spezialisiert und investieren dort viele Ressourcen. Entscheiden Sie Ihre Betriebsarten daher je nach Anforderung an Konfigurierbarkeit, bevorzugen Sie nach Möglichkeit aber Services, bei denen der Cloud-Anbieter viel operative Arbeit abnimmt.
Beachten Sie auch, dass wahrscheinlich nicht Ihr gesamtes System dieselbe Betriebsart hat. Vielleicht haben einige Module höhere Anforderungen an Konfigurationsmöglichkeiten auf allen Verantwortlichkeitsebenen. Somit betreiben Sie Teile Ihres Systems direkt auf virtuellen Maschinen, andere Teile in einem Kubernetes-Cluster und wiederum andere Teile serverless. Das führt dazu, dass sich Ihr System im Shared Responsibility Modell an verschiedenen Stellen wiederfindet. Dementsprechend müssen Sie Security für verschiedene Teile des Systems unterschiedlich auslegen.
Das Shared Responsibility Modell bildet die Grundlage der Security-Pillars in AWS und Azure [ASR] [MSR]. Auch für die Google Cloud spielt das Modell eine grundlegende Rolle, die Autoren des Architecture Frameworks haben allerdings das Modell weitergedacht und den Begriff “shared fate” [GSF] eingeführt. Viele Elemente aus diesem Konzept finden Sie in den Security-Pillars der drei Anbieter wieder.
Ein Ansatz, unsere Daten vor Missbrauch zu schützen ist, einfach alle möglichen Daten zu verschlüsseln und unter strikte Zugriffsbeschränkungen zu stellen. Diese maximale Sicherheit leuchtet ein, hat aber auch Nachteile. Das Schützen von Daten kostet Zeit und Geld. Je mehr Daten wir mit maximalem Schutz versehen, desto mehr Ressourcen müssen wir in die Schutzmechanismen stecken. Beispielsweise müssen Sie sich um die Verwaltung von Schlüsseln und Zertifikaten kümmern oder Zugriffsrechte verwalten und aktuell halten. Deswegen macht es Sinn, wenn Sie sich in einem ersten Schritt Gedanken über eine Klassifizierung von Daten machen. Dabei ordnen Sie bestimmte Arten von Daten einer Kategorie zu und definieren je Kategorie entsprechende Schutzmechanismen. Zur Kategorisierung können Sie eigene Schemata entwerfen oder auf existierende (standardisierte) Schemata zurückgreifen. Eine gute Übersicht gibt es im “Data Classification Whitepaper” von AWS [ACW] . Allgemeine Best Practices zur Klassifizierung finden Sie ebenso in den Architekturframeworks [ADC] [MDC] [GDC] .
Tabelle 1 zeigt ein Klassifizierungsschema angelehnt an Vorschläge aus dem Google Cloud Framework [GDC]und ergänzt um Beispieldaten und Vorschläge zu Ansätzen, die Daten zu schützen.
| Klasse | Beispiel für Daten | Ideen für Schutzmechanismen |
| Public (Daten für allgemeinen, öffentlichen Zugriff) | Öffentliche Wetterdaten | Nicht verschlüsseln, allgemein zugänglich |
| Internal (Nicht-sensitive Daten, die nicht öffentlich zugreifbar sind) | Geschützte Wetterdaten (nur für Premium-Nutzer) | Nicht verschlüsseln, intern zugänglich für Entwickler und Administratoren |
| Confidential (Sensitive Daten, die unternehmensintern geteilt werden dürfen) | Standort-Daten der Nutzer bei Wetterabfrage | Verschlüsseln, intern zugänglich nur für Administratoren |
| Restricted (Hochsensitive Daten, die auch unternehmensintern nur in Ausnahmefällen geteilt werden dürfen) | Urlaubsfotos von Nutzern | Nach hohen Standards verschlüsseln, intern zugänglich nur für Administratoren nach Genehmigung |
Es gibt zusätzlich noch Werkzeuge, die Ihnen bei der Klassifizierung helfen. Diese Werkzeuge sind in der Lage, personenbezogene Daten zu erkennen und geben Ihnen Hinweise, auf eventuell falsch klassifizierte Daten. Abbildung 4 zeigt eine Übersicht solcher Tools.
In meinem Blogpost zur “Operational Excellence”-Pillar habe ich über die Wichtigkeit von Observability und die Sammlung von Metriken, Logs und Traces gesprochen. Auch hier im Security-Pillar kommen uns diese Themen zugute. Neben den grundlegenden Datenquellen für Telemetrie gibt es im Cloud-Umfeld noch zusätzliche, sicherheitsspezifische Quellen:
Best Practices zu Audit-Logs und Security-Scans finden Sie unter [ASL], [MSL] oder [GLD]. Unterstützende Werkzeuge habe ich in Abbildung 4 zusammengefasst.
Integrieren Sie diese Daten in ein Werkzeug zur Log-Analyse, das mittels automatisierter Erkennung von Anomalien dynamisch Sicherheitslücken und Angriffe auf Ihr System erkennen kann. Abbildung 3 zeigt diesen Prozess.
Abbildung 3: Schematischer Umgang mit Metriken, Logs und Security-Events
Telemetrie-Daten von Anwendungen, Netzwerk- und Audit-Logs füttern diese Log-Analyse-Tools mit relevanten Informationen. Im Falle eines Angriffs oder ungewöhnlichen Log-Daten erzeugt das Analyse-Tool ein Security-Event und stuft dieses ein, beispielsweise nach Dringlichkeit (High/Medium/Low). Je nach Einstufung des Events werden automatisierte betriebliche Vorgänge zur Behebung des Security-Events angestoßen, relevante Personen informiert oder das Event wird in einem SIEM-System (Security Information and Event Management) als Ticket abgelegt.
Zusätzlich scannt das SIEM-System die Cloud-Anwendung und -Infrastruktur kontinuierlich nach gefährlicher Konfiguration und Sicherheitslücken – diesen Vorgang haben wir weiter oben als “Security-Scans” bereits kennengelernt. Auffälligkeiten hält das SIEM-System ebenfalls als Ticket fest. Best Practices zu diesem Prozess finden Sie in den Architektur-Frameworks von AWS [ADE] oder Microsoft Azure [MMR].
Diese Automatisierung ermöglicht eine ständige Überwachung auf Sicherheitsprobleme. Dadurch können Sicherheitsvorfälle automatisch erkannt und behoben werden. Abbildung 4 zeigt nützliche Werkzeuge, die Sie als Log-Analyse einsetzen können.
Abbildung 4: Werkzeuge für Security in der Cloud
Übung macht den Meister! Das ist bei Security-Vorfällen nicht anders, vor allem, weil Sie in solchen Situationen üblicherweise unter Zeitdruck stehen und schnell Maßnahmen einleiten müssen.
Machen Sie aus diesen Übungen gerne Events – AWS nennt diese übrigens “Game Days”. Blockieren Sie einen halben Tag mit Ihrem Team, bestellen Sie Pizza (oder gesunden Salat ;-) ) und üben Sie ein konkretes Szenario eines Angriffes auf Ihr System und dessen Behebung. Sammeln Sie alle Optimierungspotentiale, die Ihnen auffallen und verbessern sie damit Automatismen, Playbooks und Runbooks. Best Practices zu diesen Trockenübungen finden Sie in den Well-Architected Frameworks von AWS [AGD] und Microsoft [MSA].
Das war der dritte Beitrag der Blogreihe “Well Architected Cloud”. Im nächsten Artikel werden wir die Pillar “Reliability” beleuchten.
Sie möchten sich zum Thema Security oder den Architektur-Frameworks der Cloud-Anbieter austauschen? Melden Sie sich gerne, meine Kontaktdaten finden Sie hier.
“Well Architected Cloud: ein Überblick über drei Architektur-Ratgeber”
‘Well Architected Cloud: die “Operational Excellence”-Pillar’
“Well Architected Cloud: die Reliability-Pillar”
‘Well Architected Cloud: die “Performance Efficiency”-Pillar’
“Well Architected Cloud: die Pillars “Cost Optimization” und Sustainability”
“Well Architected Cloud: die Architektur-Frameworks effektiv und effizient einsetzen”
“Die Pillar im AWS Well-Architected Framework”
“Die Pillar im Azure Well-Architected Framework”
“Die Pillar im Google Cloud Architecture Framework”
[ACW] “Data classification models and schemes”
[ADC] “Data classification”
[ADE] “Detection”
[AGD] “Run game days”
[AMS] “Implement managed services”
[ASL] “Configure service and application logging”
[ASR] “Shared responsibility”
[GDC] “Automatically classify your data”
[GLD] “Implement logging and detective controls”
[GSF] “Shared responsibilities and shared fate on Google Cloud”
[MAC] “Application classification for security”
[MDC] “Data classification”
[MMR] “Security monitoring and remediation in Azure”
[MSA] “Simulate attacks”
[MSL] “Security logs and alerts using Azure services”
[MSR] “Overview of the security pillar”