Blog
Wie funktioniert das AWS-Modell der geteilten Verantwortung?
Wenn Sie Ihre Anwendung in AWS ausführen möchten, kann die schiere Anzahl der Services es schwierig machen zu verstehen, wo Ihre Sicherheitsverantwortung in der Cloud liegt. Das
Die Grundlagen
Lassen Sie uns mit den Grundlagen beginnen. Das AWS-Modell der geteilten Verantwortung besteht aus zwei Arten von Verantwortlichkeiten: Sicherheit der Cloud und Sicherheit in der Cloud. Theoretisch ist AWS nur für die Sicherheit der Cloud verantwortlich: mit anderen Worten, für den Schutz der physischen Sicherheit der Infrastruktur und der Einrichtungen der Plattform. Der Kunde hingegen sollte dafür sorgen, dass die Anwendung, die auf der Plattform selbst läuft, ausreichend sicher ist. In der Praxis können sich die genauen Verantwortlichkeiten je nach genutztem Service stark ändern! Das kann das Modell schwer verständlich machen. Zur Vereinfachung können wir AWS-Services grob in nicht verwaltete (auch bekannt als "Infrastructure as a Service"), verwaltete oder serverlose Services einteilen. Im Folgenden erkläre ich Ihnen, wie das Modell in der Praxis funktioniert, indem ich vier Arten des Hostings einer Anwendung betrachte: AWS EC2, AWS Elastic Container Service, AWS Fargate und AWS Lambda.
Nicht verwaltete Dienste: AWS EC2
Nehmen wir an, wir möchten eine skalierbare Anwendung erstellen, die wir nach Belieben anpassen können. Eine Lösung könnte darin bestehen, sie in einem Container auf unserem eigenen Kubernetes-Cluster in AWS unter Verwendung von EC2 auszuführen und Kubernetes die Container hochskalieren zu lassen, wenn unsere Anwendung mehr Datenverkehr erhält.
Ein Vorteil einer selbst gehosteten Plattform wie dieser ist also, dass Sie die vollständige Kontrolle darüber haben, wo und wie Ihre Container ausgeführt werden. Die zentrale Komponente, die sich um die Konfiguration unserer Container-Orchestrierung kümmert, wird als Control Plane bezeichnet. Wie wir noch sehen werden, verfügen auch die AWS-Services über Control Plane.
Lassen Sie uns einen Blick darauf werfen, was dies für das Modell der geteilten Verantwortung bedeutet:
In einem vollständig selbstverwalteten Cluster ist AWS nur für die Sicherung von zwei Dingen verantwortlich: die Einrichtungen des Rechenzentrums (in Form von Regionen und Verfügbarkeitszonen) und die zugrunde liegende Serverhardware, auf der unsere Anwendung läuft. Alles andere - und das ist, wie Sie sehen können, eine ganze Menge! - müssen wir selbst verwalten.
Verwaltete Dienste: AWS ECS
Da es ziemlich viel Aufwand erfordert, unser eigenes Orchestrierungs-Framework einzurichten und zu pflegen, entscheiden wir uns, dies AWS zu überlassen. Ein verwalteter Service wie 
AWS übernimmt nun die Verantwortung, böswillige Benutzer am Zugriff auf unsere Kontrollebene zu hindern und sicherzustellen, dass die richtige Anzahl von Instanzen verfügbar ist. Großartig!
Wenn jedoch eine Sicherheitslücke im zugrunde liegenden Betriebssystem unserer Instanzen gefunden wird, müssen wir diese immer noch selbst beheben! Was, wenn wir das nicht tun wollen? Glücklicherweise bietet AWS zusätzliche Services für die Patch-Verwaltung.
Serverlos: AWS Fargate
Eine Möglichkeit wäre, AWS Fargate für unseren ECS-Cluster zu aktivieren. Da die Preisgestaltung auf der CPU- und Speichernutzung und nicht auf der Anzahl der EC2-Instanzen basiert, nennt AWS dieses Modell "Serverless". Die genaue Konfiguration unserer Server liegt nun in den Händen von AWS, und wir müssen uns nicht mehr um die Wartung der Betriebssysteme unserer Server kümmern. Unser Modell sieht wie folgt aus:
Einer der Vorteile von Fargate ist, dass Patches für Schwachstellen in Betriebssystemen automatisch bereitgestellt werden. Als beispielsweise die Sicherheitslücken Spectre und Meltdown veröffentlicht wurden, mussten AWS-Kunden, die eine nicht verwaltete oder verwaltete Container-Orchestrierungslösung verwendeten, ihre Systeme selbst patchen, während AWS-Ingenieure dieses Problem für Kunden, die AWS Fargate verwenden, automatisch behoben haben.
Serverlos: AWS Lambda
Aber selbst bei einem Dienst wie Fargate sind wir immer noch für die Verwaltung unserer Container verantwortlich! Wenn wir einen Containerisierungsdienst wie Docker verwenden, liegt es in unserer Verantwortung, die Container-Software, auf der unsere Anwendung ausgeführt wird, zu pflegen und zu aktualisieren. Mit AWS Lambda können wir noch mehr Verantwortung auf AWS übertragen. Das endgültige Modell sieht wie folgt aus:
Wie funktionieren Lambda-Funktionen also unter der Haube? Einfach ausgedrückt, hat AWS Lambda eine Steuerungsebene und eine Datenebene. Die Steuerebene ist die Verwaltungs-API, die alle Aufrufe zum Erstellen und Aktualisieren des Lambda-Funktionscodes verarbeitet. Die Datenebene (auch Invoke-API genannt) ist für die Zuweisung der Ausführungsumgebung Ihrer Funktion an eine verfügbare Lambda Worker-Instanz zuständig.
Lambda Worker sind EC2 Nitro-Instanzen, die von einem EC2 Instance Store für die temporäre Speicherung unterstützt werden. Sie sind den Worker Nodes sehr ähnlich, die wir bei den selbst gehosteten und vollständig verwalteten Servicemodellen gesehen haben. Für jede Lambda-Ausführungsumgebung (die von mehreren Aufrufen wiederverwendet werden kann) initiiert ein Hypervisor, der auf einem der Lambda-Arbeitsknoten läuft, eine
Mitbringsel
Wie wir gesehen haben, können Ihre Sicherheitsverantwortlichkeiten in der Cloud je nach dem von Ihnen gewählten Service sehr unterschiedlich sein. Es ist leicht zu erkennen, wie auch die offizielle AWS-Dokumentation zu Verwirrung führen kann: Obwohl Fargate und Lambda beide als "Serverless" bezeichnet werden, sind unsere Sicherheitsverantwortlichkeiten nicht identisch! Letztendlich hat jeder AWS-Service seinen eigenen Satz an gemeinsamen Verantwortlichkeiten. Wenn Sie Ihre Anwendungsarchitektur in AWS entwerfen und das Modell der geteilten Verantwortung berücksichtigen möchten, kann es hilfreich sein, sich die folgende Frage zu stellen: Wie viele Ressourcen stehen mir zur Verfügung, um meine Anwendung selbst angemessen zu sichern?
Unsere Ideen
Weitere Blogs
Contact