AWS Security Serie: Teil 1 – Shared Responsibility Model

Während vor einigen Jahren oftmals noch debattiert wurde, wann und in welcher Form „die Cloud“ auch in Unternehmen ein Thema wird, kann mittlerweile wohl niemand mehr leugnen, dass dieses nebulöse Geschöpf der Technik bereits allgegenwärtig ist. Während Cloud Infrastrukturen in vielen Unternehmen bereits Gang und Gebe sind, legen andere Unternehmen derzeit noch eine gewisse Portion Vorsicht an den Tag. Auch wir werden immer häufiger mit diesen und vielen weiteren exemplarischen Fragen innerhalb unserer Cloud Projekte konfrontiert:

• „Wie sicher ist das denn?“
• „Darf ich das überhaupt?“
• „Wo liegen meine Daten denn überhaupt?“
• „Wie kann ich selbst für Sicherheit in der Cloud sorgen?“

Versteht mich nicht falsch: ein gesundes Maß an Misstrauen in Technologien ist mehr als angemessen, doch gerne stelle ich die Gegenfrage: „Wenn die Daten in der Cloud nun unsicher sein sollen, wie sicher sind sie denn bei dir?“. Da das natürlich eine eher ketzerisch zu verstehende Gegenfrage darstellt, möchte ich in den folgenden Wochen auf die Grundlagen der Cloud Security eingehen. Um genauere Beispiele liefern zu können, werde ich diese Blog Serie auf das Thema Security in Amazon Web Services eingrenzen. Azure ist euch lieber? Keine Angst, die meisten Grundlagen sind relativ universell einsetzbar und unterscheiden sich nicht großartig zwischen den verschiedenen Hyperscalern.

Welche Themenfelder wollen wir also im Zuge der kommenden Blogposts bearbeiten?

• AWS Security: Shared Responsibility Model
• AWS Security: Location and Physical Access
• AWS Security: Identity and Access Management
• AWS Security: Keys
• AWS Security: Network
• AWS Security: Storage
• AWS Security: Compute
• AWS Security: Serverless

Shared Responsibility Model

Sobald wir mit unseren Kunden in das Thema AWS Security einsteigen, steht zumeist die Frage im Raum, wer denn nun für welchen Part der Security zuständig ist. Muss ich als Kunde alles machen oder kann ich mich ganz entspannt zurücklehnen und AWS den Job erledigen lassen? Naja, die Wahrheit liegt bei dieser Frage irgendwo in der Mitte. Wie andere Anbieter hat AWS hierfür ein sogenanntes Shared Responsibility Model entwickelt. Dieses regelt die Aufgabenbereiche des Providers und die des Konsumenten.

Aufgabenbereich AWS: Sicherheit DER Cloud

Im obigen Diagramm kann man relativ gut erkennen, wo die Aufgaben von AWS liegen. Es ist vermutlich keine große Überraschung, dass sich AWS zuerst einmal um die darunterliegende Physik der angebotenen Services kümmert. So liegen auch Themen wie die physikalische Zugangssicherheit oder auch die Stromversorgung der Rechenzentren in der Verantwortung von AWS. Auch um die grundlegende Sicherheit der Softwareworkloads der Hypervisoren von virtuellen Instanzen oder Storage Workloads unter S3 muss sich der Kunde nicht kümmern. Doch nur, weil die Cloud selbst sicher ist, ist noch lange keine Sicherheit IN der Cloud gegeben. 

Aufgabenbereich Kunde: Sicherheit IN DER Cloud

Stellen wir uns eine mittelalterliche Stadt mit hohen Mauern vor: wir haben einen Burggraben mit tiefem Wasser und weißen Haien, ein Tor aus Stahl und die kompetentesten Sicherheitskräften überhaupt. Diese relativ hohe (100 % schließen wir mal aus) Sicherheit DER Stadt, heißt natürlich keineswegs, dass es IN DER Stadt sicher ist. Ähnlich verhält es sich innerhalb des Shared Responsibility Models: der Provider AWS kann mir noch so viel grundsätzliche Sicherheit der Dienste bieten – wenn meine darüberliegenden Konfigurationen oder das Handeln versagen, wird es schmerzhaft werden. So ist innerhalb von EC2 AWS zwar für den Schutz des Hypervisors zuständig, allerdings nicht für das Patching oder das Hardening meiner darüberliegenden Betriebsysteme. Auch für andere Dinge wie die Authentifizierung, die Verschlüsselung von Daten oder die Konfiguration von Firewalls liegt in der Verantwortung des Kunden. Natürlich lässt AWS euch hier nicht alleine und bietet eine Vielzahl von Einstellungsmöglichkeiten, Add-On Services und Guidelines, allerdings muss der Kunde diese umsetzen. Auf viele dieser Optionen werden wir in den nächsten Artikeln dieser Serie tiefer eingehen und diese praktisch vorstellen.

Exkurs: Shared Responsibility Model unter GDPR

Kommen wir zum Ende dieses Blogs noch zu einem kleinen Exkurs ins Thema Datenschutz. Und ja ich weiß: das Thema GDPR ist mittlerweile etwas überreizt und wir alle können es kaum mehr hören. Trotzdem ist es insbesondere beim zentralen Thema Datenschutz wichtig zu verstehen, wer welche Daten verarbeitet. Auch das ist durch das Shared Responsibility Model geregelt.

GDPR führt spezifische Vorschriften und Verantwortlichkeiten für Datenverantwortliche und -verarbeiter ein. Wenn ein AWS-Kunde Dienste zur Verarbeitung personenbezogener Daten nutzt, ist der für die Verarbeitung Verantwortliche in der Regel der AWS-Kunde (und manchmal ist es der Kunde des AWS-Kunden). In all diesen Fällen ist AWS jedoch immer der Datenverarbeiter in Bezug auf diese Aktivität. Der Grund dafür ist, dass der Kunde die Verarbeitung der Daten durch seine Interaktion mit den AWS-Servicekontrollen steuert und AWS nur die Kundenanweisungen ausführt. Als Datenverarbeiter ist AWS allerdings für den Schutz der globalen Infrastruktur verantwortlich auf dieser aller Dienste basieren. Kunden, die AWS verwenden, behalten die Kontrolle über die auf dieser Infrastruktur gehosteten Daten, einschließlich der Sicherheitskonfigurationskontrollen für den Umgang mit Endbenutzerinhalten und personenbezogenen Daten. Der Bericht nach ISO 27018 ist ein gutes und einsehbares Beispiel, da er Sicherheitskontrollen testet, die sich insbesondere auf den Schutz personenbezogener Daten konzentrieren.

Fazit

Ich glaube immer noch, dass es für viele Unternehmen und Anwender sehr wichtig ist, dass sich Anbieter wie AWS um den Schutz der Plattform kümmern und die verschiedenen Verantwortungen klar aufteilen. So erspare ich mir als Kunde viel Arbeit und kann insbesondere in Themen wie Compliance auf eine solide Grundlage aufbauen. Ab dann verhält es sich wie in herkömmlichen Umgebungen auch, wofür ich meistens das folgende Beispiel heranziehe: ihr könnt die beste, teuerste und allgemein tollste Next-Gen Firewall der Welt haben – macht ihr die Tür durch Miskonfiguration weit auf, wird sie euch wenig helfen. Der Beginn einer jeden Cloud Security Beratung bei uns ist immer: back 2 basics. Natürlich werden wir in den kommenden Wochen viele Besonderheiten von Security innerhalb von AWS kennenlernen, doch oft hilft auch der gesunde Menschenverstand. Dass jeder User nach „Least Privilege“ eingerichtet werden sollte, man keine RDP Port Forwardings unternimmt und Patches nicht nur nervige Beikost sind, sollte in der Cloud wie On-Premise gegeben sein.

Ich hoffe der heutige Artikel hat etwas Lust auf mehr gemacht. Wie versprochen, werden wir in den nächsten Artikeln deutlich mehr ins Detail gehen und so die Sicherheitsoptionen von AWS besser kennen lernen.

Series Navigation

AWS Security Serie: Teil 2 – Location and Physical Access >>