Was ist AWS Cloud Security?

AWS Cloud Security ist das Paket aus Protokollen und Prüfungen, die standardmäßig erstellt wurden, sodass die Infrastruktur der Cloud, in der Sie arbeiten, so sicher wie möglich ist. Für die Cloud-Sicherheit bei AWS sind AWS und der Kunde gemeinsam verantwortlich. AWS sichert die Cloud selbst und der Kunde sichert seinen Betrieb innerhalb der Cloud.

Wie funktioniert AWS Cloud Security?

Die AWS Cloud Security schützt die Infrastruktur, die Services in der AWS Cloud ausführt. Sie besteht aus Hardware, Software, Netzwerk und Einrichtungen, die AWS Cloud-Services ausführen. AWS ist verantwortlich für Security-Prozesse wie Patch-Management und Konfigurationsmanagement, die Behebung von Schwachstellen in der Infrastruktur der Cloud sowie die Aufrechterhaltung der Konfiguration seiner Infrastrukturgeräte.

Traditionelle IT-Security vs. Cloud-Security

Auf oberster Ebene sind die Grundlagen der Sicherung der Cloud-Infrastruktur den Grundlagen der Sicherung eines lokalen Netzwerks ähnlich. So gilt beispielsweise das NIST Cybersecurity Framework nach wie vor: Sie versuchen zu ermitteln, was Sie sichern müssen, diese Assets zu schützen, böswillige Aktivitäten zu erkennen, auf Sicherheitsereignisse zu reagieren und den Normalzustand danach wiederherzustellen. Allerdings ist die Art und Weise, wie Sie unter den einzigartigen Aspekten einer Cloud-Umgebung diese Funktionen durchführen, mitunter ganz anders.

Shared Responsibility Model: Modell der gemeinsamen Verantwortung

In einer Cloud-Umgebung liegt der offensichtlichste, aber häufig nicht verstandene Unterschied darin, dass der Cloud-Anbieter (CSP) für die Sicherheit einiger Elemente dieser Umgebung verantwortlich ist. Die Missverständnisse treten genau im Zuständigkeitsbereich des CSP auf. CSPs wie AWS haben ein gemeinsames Verantwortungsmodell entwickelt, um das Ganze zu klären.

Dieses Modell der geteilten Verantwortung besagt, dass AWS für die Sicherung der seiner Cloud zugrundeliegenden Infrastruktur verantwortlich ist. Das bedeutet, dass AWS für Dinge wie die Wartung und Aktualisierung der Hardware verantwortlich ist. Der Kunde, der die AWS-Infrastruktur nutzt, ist für die Sicherung aller Dinge, die er in AWS speichert, zuständig. Das bedeutet, dass er für die Aktualisierung und das Patching von Betriebssystemen verantwortlich ist genau wie für die ordnungsgemäße Konfiguration der von ihm genutzten AWS-Dienste, und die Zugriffsberechtigung aller Personen kontrolliert, die auf diese Dienste zugreifen. 

Sollte jemand in Ihrem Unternehmen fälschlicherweise annehmen, dass Ihr Cloud-Anbieter sich um einen Sicherheitsaspekt kümmert, könnte dies zu unsachgemäß gesicherten Cloud-Assets führen. Daher ist es sehr wichtig, dass alle Personen, die eine Cloud-Umgebung modifizieren können, zunächst über die Bedeutung des gemeinsamen Verantworungsmodells unterrichtet werden und wissen, für welche Teile der Sicherheit Ihres Unternehmens sie zuständig sind.

Cloud Asset Management

Ein weiterer einzigartiger Aspekt einer Cloud-Umgebung ist die Leichtigkeit, mit der neue Assets erstellt und bereitgestellt werden können. In einem lokalen Netzwerk haben die IT- und Sicherheits-Teams den Überblick über neue Infrastruktur. In einem Cloud-Netzwerk kann neue Infrastruktur von jeder beliebigen Person oder jedem System mit den passenden Zugriffsberechtigungen sofort hinzugefügt werden. Das macht den Netzwerkausbau sehr viel einfacher, vergrößert jedoch ohne entsprechende Richtlinien und aktives Monitoring auch das Risiko, dass neue Infrastruktur nicht auf Sicherheit konfiguriert wurde und daher Schwachstellen aufweist.

Gleichzeitig verändern sich Cloud-Umgebungen sehr schnell. Beim Einsatz von Technologien wie Autoscaling und serverlosem Computing tauchen Assets in einem Cloud-Netzwerk ständig neu auf und verschwinden dann wieder. Herkömmliche Sicherheitsmaßnahmen wie Vulnerability Scans sind nicht mehr ausreichend, da anfällige Assets möglicherweise nur für wenige Minuten oder Stunden bestehen, d.h. es wird von dem wöchentlichen oder sogar dem täglichen Scan nicht erkannt.

Man könnte meinen, dass das auch bedeutet, dass das Asset nicht lange genug existiert, um ein Risiko darzustellen, aber Daten aus unserem globalen Honeypot-Netzwerk Project Lorelei zeigen, dass neue Assets innerhalb weniger Stunden nach ihrer Erstellung von bösartigen Quellen gescannt werden.

Durch die einfache Bereitstellung und hohe Veränderungsrate wird es für Sicherheits-Teams sehr viel schwieriger, einen vollständigen Überblick über die Cloud-Umgebung aufrechtzuerhalten. Erschwert wird dies in Hybrid-Umgebungen (IT-Umgebungen, in denen sowohl lokale als auch Cloud-Netzwerke vorhanden sind) und Multi-Cloud-Umgebungen (IT-Umgebungen mit Cloud-Netzwerken von mehreren Cloud-Anbietern), in denen verschiedene Informationen in unterschiedlichen Systemen gespeichert werden, die häufig mit verschiedenen Sicherheitstools geschützt werden.

In diesen Umgebungen muss das Sicherheitsteam zwischen verschiedenen Systemen hin und her springen, um seine Sicherheitsmaßnahmen umzusetzen. Der Mangel an vereinheitlichten Daten erschwert oder verhindert es sogar, sich einen genauen Überblick über die gesamte Sicherheitslage des Unternehmens zu verschaffen oder einen böswilligen Akteur zu verfolgen, der zwischen der Cloud und den lokalen Netzwerken hin und her wechselt.

Wie sicher ist AWS?

Die Sicherheit auf AWS ist so stark, wie Sie sie machen. Oben haben wir das Modell der gemeinsamen Verantwortung besprochen und dass AWS für die Sicherheit der zugrunde liegenden Infrastruktur verantwortlich ist. Tatsächlich investiert AWS mehr Ressourcen in seinen Anteil des gemeinsamen Verantwortungsmodells als die Mehrzahl der Organisationen mit lokalen Netzwerken. Ein Wechsel zu AWS kann bei diesen Organisationen Aspekte ihrer Sicherheitslage verbessern. 

Allerdings bringt der Wechsel zu AWS oder einem anderen öffentlichen Cloud-Anbieter auch neue Risiken mit sich. Wie oben erwähnt, haben Cloud-Umgebungen individuelle Herausforderungen. Es ist nicht möglich, die vorhandenen Sicherheitstaktiken einfach auf die Cloud zu übertragen. Trotz alledem kann AWS genauso sicher sein wie ein lokales Netzwerk (oder sogar noch sicherer), vorausgesetzt, Sie machen sich mit den einzigartigen Aspekten der Cloud-Sicherheit vertraut und wenden Best Practices an.

Bedeutung von starker AWS Cloud Security

Starke AWS-Sicherheit ist aus denselben Gründen wichtig, die auch Cybersicherheit im Allgemeinen betreffen. Sie müssen Ihre Organisation und Ihre Kunden vor böswilligen Akteuren schützen. In vielen Unternehmen steigt die Wertschätzung einer starken AWS-Sicherheit, je mehr wertvolle Workloads und vertrauliche Daten in die Cloud verlagert werden.

Ein weiterer Grund, warum eine starke AWS-Sicherheit wichtig ist, ist der Reputationsschaden, der durch einen vermeidbaren Vorfall entstehen kann. Gartner prognostiziert, dass bis Ende 2020 95 % der Cloud-Sicherheitsausfälle auf Fehler des Kunden zurückzuführen sein werden. Sollten Kunden erfahren, dass ein Unternehmen aufgrund eines leicht vermeidbaren Fehlers kompromittiert wurde, könnte dies ihr Vertrauen soweit erschüttern, dass sie ihr Unternehmen an einen anderen Anbieter verlagern.

Best Practices für AWS Cloud Security

Eine kurze Anmerkung vor dem Einstieg: Wie Sie aus dem Firmennamen ablesen können, nutzt AWS sehr gerne Abkürzungen. Das kann verwirrend sein, wenn wir versuchen, die Funktionen der verschiedenen AWS-Dienste zu erkennen, darum hier eine kurze Erläuterung:

  • S3 (Simple Storage Service) = Objektspeicher
  • EC2-Instanz (Elastic Compute Cloud) = Virtuelle Maschine/Server
  • AMI (Amazon Machine Image)= Ein Rechner-Image, das ein Betriebssystem und manchmal zusätzliche Software enthält, die auf einer EC2-Instanz ausgeführt werden.
  • VPC (Virtual Private Cloud) = Virtuelles Netzwerk, das dem Netzwerk eines geläufigen Rechenzentrums stark ähnelt.Alle modernen EC2-Instanzen laufen in einem VPC.

Weiter unten gehen wir noch näher auf zusätzliche AWS-Dienste ein, aber wir wollten Sie zunächst mit diesen Grundlagen vertraut machen. Nun aber zu den Best Practices:

1. Vorausplanen

Idealerweise sollten Sie bereits vor der Einführung darüber nachdenken, wie Sie Ihre AWS-Umgebung sichern. Wenn das Kind bereits in den Brunnen gefallen ist, ist das kein Grund zur Sorge – die Implementierung einiger Best Practices erfordert möglicherweise nur etwas mehr Aufwand.

2. In die Cloud einsteigen

Wenn ein Unternehmen zum ersten Mal in die Cloud-Umgebung einsteigt, versuchen einige Sicherheitsteams, die von ihnen betreute lokale Umgebung so gut wie möglich in der Cloud widerzuspiegeln, indem sie beispielsweise Entwickler daran hindern, Infrastrukturänderungen umzusetzen. In fast allen Fällen kommt es dann dazu, dass das Team seiner Aufgaben für die Cloud-Sicherheit entbunden wird, oder die Engineers Wege finden, die Einschränkungen zu umgehen (siehe Best Practices Nr. 9, weshalb das keine geeignete Vorgehensweise ist).

Sicherheitsteams müssen erkennen, dass potenziell riskante Aspekte der Cloud, wie z.B. die rasanten Veränderungen und die einfache Bereitstellung zugleich die größten Vorteile für die Nutzung der Cloud-Infrastruktur darstellen. Für ihren Erfolg müssen Sicherheitsteams versuchen, zu Wegbereitern der Cloud zu werden. Sie müssen Wege finden, um die Cloud-Infrastruktur zu sichern, ohne die Aspekte übermäßig zu unterdrücken, die den Nutzen der Cloud für das Unternehmen ausmachen. Das beginnt mit Offenheit und mit der Erkenntnis, dass ein erfolgreiches Risikomanagement einer Cloud-Umgebung neue Taktiken und Prozesse erfordert. 

3. Definition einer Sicherheitsgrundlage für Ihre AWS-Umgebung

IhreSicherheits- und DevOps-Teams sollten zusammenarbeiten, um zu definieren, wie Ihre AWS-Umgebung aus Sicherheitssicht aussehen soll. Die Baseline sollte alles klar beschreiben, von der Konfiguration von Assets bis hin zu einem Incident-Response-Plan. Die Teams sollten die Verwendung von Ressourcen wie dem AWS Well-Architected Framework und den CIS-Benchmarks für die Sicherheit auf AWSals Ausgangspunkt in Betracht ziehen . Möglicherweise möchten sie auch einen AWS-Lösungsarchitekten um Unterstützung bitten, bei dem es sich um einen technischen Experten handelt, der in der Lage ist, Kunden beim Aufbau ihrer AWS-Umgebung zu unterstützen.

Stellen Sie sicher, dass Ihre Baseline sowohl auf Ihre Produktionsumgebung als auch auf alle Test- und Vorproduktionsumgebungen angewendet wird. Bewerten Sie Ihre Baseline mindestens alle sechs Monate neu, um Dinge wie neue Bedrohungen und Änderungen in Ihrer Umgebung zu berücksichtigen.

4. Durchsetzung Ihrer Baseline

Sobald Ihre Sicherheits- und DevOps-Teams definiert haben, wie Ihre AWS-Sicherheitsstandard aussieht, müssen Sie sie durchsetzen. Erleichtern Sie Entwicklern die Einhaltung Ihrer Sicherheitsstandards, indem Sie ihnen bereits ordnungsgemäß konfigurierte Infrastrukturvorlagen zur Verfügung stellen. Sie können dies mit AWS CloudFormation oder einem Infrastructure-as-Code-Anbieter wie Terraformtun

Sie benötigen außerdem eine Überwachungslösung, um zu erkennen, wenn etwas nicht mit der Baseline-Standard übereinstimmt (entweder weil es mit einer Fehlkonfiguration bereitgestellt wurde oder weil nach der Bereitstellung eine Änderung vorgenommen wurde).Hierfür bietet sich beispielsweise die Nutzung von AWS Security Huban . Es gibt jedoch auch mehrere Drittanbieter-Vulnerability-Management-Lösungen, die eine integrierte Überwachung für Cloud-Fehlkonfigurationen bieten..

Die Verwendung einer VM-Lösung mit integrierter Fehlkonfigurationserkennung bietet zwei Vorteile. Erstens werden zwei Arten der Risikoüberwachung (Asset-Schwachstellen und Fehlkonfigurationen der Cloud-Infrastruktur) in einem Tool zusammengefasst. Zweitens werden bei den meisten Schwachstellenmanagementlösungen alle Fehlkonfigurationsregeln und -erkennungen vom Anbieter für Sie verwaltet, während Sie bei AWS Security Hub die Regeln selbst einrichten und verwalten müssen. Erfahren Sie mehr über InsightVM zur Schwachstellenbewertung und Cloud-Konfiguration.

Eine weitere Option zur Durchsetzung Ihrer Sicherheitsgrundlinie ist eine Cloud Security Posture Management (CSPM)-Lösung. Ein hochwertiges CSPM wird in der Lage sein,Konten von mehreren Cloud-Anbietern auf Fehlkonfigurationen zu überwachen. Dies ist besonders wichtig, da es Ihrer Organisation ermöglicht, einen Sicherheitsstandard für alle Ihre Cloud-Anbieter festzulegen und diese dann mit einem einzigen Tool durchsetzen kann. Neben der Möglichkeit,Cloud-Konten auf Fehlkonfigurationen zu überwachen, sollten Sie nach einem CSPM suchen, das in der Lage ist,Fehlkonfigurationen automatisch zu beheben, sobald sie erkannt werden. Dadurch wird die Belastung Ihres Sicherheitsteams erheblich reduziert und sichergestellt, dass nichts durchs Raster fällt. 

Zu den weiteren Funktionen, nach denen Sie in einem CSPM suchen sollten, gehören die Möglichkeit,Probleme in der Infrastruktur als Code zu kennzeichnen, bevor etwas bereitgestellt wird, IAM-Governance (weitere Informationen zu IAM finden Sie im nächsten Abschnitt) und Compliance-Auditing. CSPMs sind in der Regel etwas teuer, aber für Unternehmen, die mehrere Cloud-Anbieter nutzen oder eine große Anzahl von Konten bei einem einzigen Anbieter haben, ist ein CSPM die Möglichkeit, das Chaos bei der Verwaltung all dieser Konten in Ordnung zu bringen.

5. Zugriffsrechte beschränken

Für die Schaffung einer sicheren AWS-Umgebung gibt es kaum etwas Wichtigeres, als den Zugriff auf die Benutzer und Systeme zu beschränken, die ihn wirklich benötigen. Dies wird mithilfe von AWS Identity Access Management (IAM)erreicht. IAM besteht aus folgenden Komponenten:

  • Benutzer: Einzelpersonen oder Systeme, die mit dem AWS interagieren müssen. Ein Benutzer besteht aus einem Namen und Zugangsdaten.
  • Zugangsdaten: Die Möglichkeiten, wie ein Benutzer auf AWS zugreifen kann. Zu den Zugangsdaten zählen Konsolenpasswörter, Zugriffsschlüssel, SSH-Schlüssel und Serverzertifikate.
  • Gruppen: Bei Gruppen können Sie die Rechte aller Benutzer in der Gruppe gleichzeitig verwalten und müssen nicht die Berechtigungen der Benutzer einzeln ändern.
  • Rollen: Diese ähneln Benutzern, haben aber keine langfristigen Zugangsdaten wie ein Passwort oder einen Zugangsschlüssel. Eine Rolle kann von einem Benutzer oder Dienst übernommen werden. Wenn eine Rolle übernommen wird, stellt sie temporäre Anmeldeinformationen für die Sitzung bereit. Nur Benutzer, Rollen, Konten und Dienste, die Sie angeben, können eine Rolle übernehmen. Mit Rollen können Sie beispielsweise einem Benutzer Zugriff auf mehrere AWS-Konten gewähren oder einer Anwendung Zugriff auf AWS-Services gewähren, ohne langfristige Anmeldeinformationen in der App speichern zu müssen.
  • Richtlinien: Dies sind JSON-Dokumente, die die Berechtigung erteilen, eine oder mehrere Aktionen in bestimmten AWS-Diensten auszuführen.Damit ein Benutzer, eine Gruppe oder eine Rolle in der Lage ist, etwas in AWS auszuführen, müssen Sie eine Richtlinie hinzufügen.AWS stellt mehrere Hundert vordefinierte „AWS Managed Policies“ zur Auswahl, oder Sie können Ihre eigenen erstellen.

Da Sie jetzt einen Überblick über die Komponenten haben, aus denen sich ein IAM zusammensetzt, wollen wir uns die Best Practices ansehen. AWS verfügt über eine Liste der IAM Best Practices, die Sie sich durchlesen sollten. Ähnliche Praktiken sind in den CIS Benchmarks für AWS erwähnt. Obwohl alle Best Practices durchaus von Bedeutung sind, wollen wir an dieser Stelle nur die entscheidendsten Richtlinien (die am häufigsten missachtet werden) erwähnen:

  • Verwenden Sie nicht den Root-Benutzer: Der Root-Benutzer ist der Benutzer, der mit der E-Mail-Adresse verknüpft ist, die zur Erstellung eines AWS-Kontos verwendet wurde. Der Root-Benutzer kann Dinge tun, die selbst ein Volladministrator nicht kann. Wenn ein böswilliger Akteur die Root-Benutzerdaten in die Hände bekommt, kann massiver Schaden angerichtet werden. Stellen Sie sicher, dass Sie ein sehr komplexes Passwort für Ihren Root-Benutzer verwenden, MFA aktivieren (idealerweise mit Hardware-MFA) und sperren Sie das MFA-Gerät in einem Safe. Ja, sperren Sie das MFA-Gerät buchstäblich weg. Sie sollten auch alle Zugriffsschlüssel löschen, die für den Root-Benutzer erstellt wurden. Verwenden Sie den Root-Benutzer nur in den sehr seltenen Fällen, in denen er erforderlich ist.
  • Verwalten Sie Benutzer über föderiertes SSO: Es ist eine bewährte Sicherheitsmethode, föderiertes SSO zu verwenden, um den Mitarbeiterzugriff auf Ressourcen zu verwalten, und dazu gehört auch AWS. Sie solltendie Identity Provider-Funktionalität von IAM nutzen , damit Sie den individuellen Zugriff auf AWS über Ihre vorhandene SSO-Lösung zentral verwalten können.
  • Weisen Sie Richtlinien nicht einzelnen Benutzern zu: Wenden Sie sie stattdessen auf Gruppen und Rollen an. Dies macht es viel einfacher, den Überblick darüber zu behalten, wer auf was zugreifen kann, und minimiert die Wahrscheinlichkeit, dass eine Person mit Zugriff auf mehr als das, was sie benötigt, unter dem Radar bleibt.
  • Ein sicheres Passwort erzwingen: Sie sollten IAM so konfigurieren, dass ein starkes Passwort erforderlich ist. CIS empfiehlt, dass Sie IAM so einrichten, dass ein Passwort aus mindestens 14 Zeichen mit mindestens einem Groß- und Kleinbuchstaben, einer Zahl und einem Symbol erforderlich ist. CIS empfiehlt außerdem, dass Passwörter mindestens alle 90 Tage ablaufen und dass vorherige Passwörter nicht wiederverwendet werden können.
  • MFA als Pflicht: Neben einem starken Passwort sollten Sie sicherstellen, dass alle Benutzer MFA aktiviert haben.
  • Nicht verwendete Zugangsdaten löschen: IAM kann einen Zugangsdatenbericht erstellen, der anzeigt, wann Zugangsdaten für jeden Benutzer zuletzt verwendet wurden. Sie sollten diesen Bericht regelmäßig aufrufen und Zugangsdaten deaktivieren oder löschen, die in den letzten 90 Tagen nicht verwendet wurden.
  • Regelmäßiges Rotieren der Zugriffsschlüssel: In vielen Fällen können Sie (bzw. sollten) für den programmatischen Zugriff auf AWS anstelle von Zugriffsschlüsseln IAM-Rollen verwenden.Stellen Sie in Fällen, in denen Sie Zugriffsschlüssel verwenden, sicher, dass diese mindestens alle 90 Tage rotiert werden.Der IAM Zugangsdatenbericht zeigt an, wann die Zugriffsschlüssel zuletzt rotiert wurden.Verwenden Sie diesen Bericht, um sicherzugehen, dass überfällige Zugriffsschlüssel geändert werden.

6. Auf Schwachstellen achten

Vielen Menschen ist nicht bewusst, dass ungepatchte Schwachstellen auch in der Cloud immer noch eine Bedrohung darstellen. Um Schwachstellen in EC2-Instanzen zu erkennen, können Sie AWS Inspector oder eine Schwachstellenmanagementlösung eines Drittanbieters verwenden. Durch den Einsatz einer Schwachstellenmanagementlösung können Sie Ihre Arbeit besser priorisieren, Ihre Berichtsfunktionen verbessern, die Kommunikation mit Infrastruktureigentümern erleichtern und allen dabei helfen, den Fortschritt bei der Risikoreduzierung zu überwachen. Darüber hinaus bevorzugen Sicherheitsteams, die mit einer Hybrid- oder Multi-Cloud-Umgebung zu tun haben, häufig die Verwendung einer Lösung eines Drittanbieters, da sie damit das Schwachstellen- und Risikomanagement für alle ihre Umgebungen an einem Ort überwachen können (mehr dazu im Artikel „Best Practice“) Nr. 9).

Obwohl das Vulnerability Management den meisten Cybersicherheitsexperten vertraut sein sollte, gibt es einige einzigartige Aspekte von VMs in einer Cloud-Umgebung wie AWS, die Sie kennen sollten. Wie bereits erwähnt, kann sich eine Cloud-Umgebung schnell ändern. Assets erscheinen und verschwinden minütlich. In einer so dynamischen Welt reichen wöchentliche oder sogar tägliche Scans nicht aus, um ein genaues Verständnis von Schwachstellen und Ihrer Risikoexposition zu erhalten. Es ist wichtig, sicherzustellen, dass Sie ein vollständiges Bild davon haben, welche EC2-Instances vorhanden sind, sowie eine Möglichkeit, die Instances während ihrer gesamten Lebensdauer kontinuierlich zu überwachen. Um sicherzustellen, dass Sie ein vollständiges Bild Ihrer EC2-Instances haben, investieren Sie in eine Schwachstellen-Management-Lösung mit dynamischer Asset-Erkennung, die neue Instanzen automatisch erkennt, sobald sie bereitgestellt werden. Eine ähnliche Funktion kann mit AWS Inspector durch die Verwendung von CloudWatch Events erreicht werden, obwohl die Einrichtung etwas manueller ist.

Wenn Sicherheitslücken in einer EC2-Instance entdeckt werden, können sie auf verschiedene Arten behoben werden. Eine Option ist die Verwendung des Patch Managers in AWS Systems Manager. Dieser Ansatz ist der herkömmlichen Verwaltung von Sicherheitslücken in einem lokalen Netzwerk am ähnlichsten. Viele Cloud-Umgebungen sind jedoch so konzipiert, dass sie unveränderlich sind. Mit anderen Worten, Ressourcen wie EC2-Instances sollten nicht geändert werden, sobald sie bereitgestellt wurden. Stattdessen wird, wenn eine Änderung vorgenommen werden muss, die bestehende Anlage gekündigt und durch eine neue ersetzt, die die Änderung beinhaltet. 

In unveränderlichen Umgebungen setzen Sie also keine Patches ein, sondern setzen neue Instanzen mit diesen Patches ein. Dies lässt sich erreichen, indem Sie ein Basis-AMI erstellen und pflegen, das regelmäßig aktualisiert wird und die neueste Version des von Ihnen verwendeten Betriebssystems ausführt. Wenn unter diesem Ansatz eine Sicherheitslücke erkannt wird, können Sie eine neue Baseline-AMI aufbauen, die die Patches für die Sicherheitslücke enthält. So beseitigen Sie die Sicherheitslücke aus zukünftigen EC2-Instanzen, die Sie bereitstellen, müssen aber darauf achten, dass Sie auch alle derzeit laufenden EC2-Instanzen erneut bereitstellen. 

Eine weitere Möglichkeit ist die Verwendung eines Infrastruktur-Automatisierungstools wie Chef oder Puppet, um AMIs zu aktualisieren und neu zu implementieren. Dieser Ansatz ist sinnvoll, wenn Sie bereits eines dieser Tools zur Wartung Ihrer EC2-Instanzen verwenden.

7. Logs erfassen und schützen

Wie bei jedem anderen System sollten Sie alle Aktivitäten, die in Ihrer AWS-Umgebung stattgefunden haben, protokollieren. Logs sind nicht nur für die Überwachung und Einhaltung von Vorschriften wichtig, sondern sie sind, wenn man an das NIST Cybersecurity Frameworkzurückdenkt, ein entscheidender Bestandteil bei der Erkennung bösartiger Aktivitäten (insbesondere, wenn sie in ein SIEMeingespeist werden), bei der Reaktion auf ein Sicherheitsereignis und bei der anschließenden Wiederherstellung.

In AWS werden die meisten Logs mit CloudTrailerfasst. Dieser Service erfasst und speichert automatisch AWS-API-Aktivitäten als so genannte Management-Ereignisse in Ihrem AWS-Konto, und zwar kostenlos (allerdings müssen Sie die Kosten für die Speicherung tragen). CloudTrail erfasst Zehntausende von Ereignissen, darunter wichtige Sicherheitsinformationen wie Anmeldungen und Konfigurationsänderungen an AWS-Services. Gegen eine Gebühr können Sie in CloudTrail auch Trails ("Pfade") erstellen, mit denen Sie z.B. zusätzliche Aktivitäten erfassen und Ihre Logs zur langfristigen Speicherung und/oder zum Export an S3 senden können. Hier finden Sie einige bewährte Verfahren für die Einrichtung von CloudTrail in Ihrem AWS-Konto:

  • Erstellen Sie einen Trail für alle Regionen: Obwohl es Geld kostet, sollten Sie einen Trail in CloudTrail erstellen, damit Sie alle Ihre Protokolle an einen S3-Bucket senden können. Auf diese Weise können Sie Ihre Protokolle auf unbestimmte Zeit speichern (CIS empfiehlt eine Aufbewahrung von mindestens 365 Tagen). Wenn Sie Ihren Trailerstellen, sollten Sie darauf achten, dass die Option Trail auf alle Regionen anwenden aktiviert ist. Dadurch können Sie in Ihrem Trail die Aktivitäten aus jeder AWS-Regionanzeigen. Wenn Sie diese Option nicht aktivieren, sammelt Ihr Trail nur Protokolle für Aktivitäten, die in der AWS-Region stattfinden, die Sie beim Erstellen des Trails verwenden. Es ist wichtig, Daten aus allen Regionen zu erfassen, damit Sie den Überblick behalten, falls etwas Verdächtiges in einer Region passiert, die Sie normalerweise nicht nutzen. Wenn Sie mehrere AWS-Konten verwenden, sollten Sie auch einen Bucket verwenden, um Logs für alle Ihre Konten zu speichern.
  • Schützen Sie den S3-Bucket, der Ihre Logs enthält: Da Ihre Logs eine wichtige Rolle bei der Erkennung und Behebung eines Vorfalls spielen, ist der S3-Bucket, in dem Sie Ihre Logs speichern, ein Hauptziel für einen Angreifer. Daher sollten Sie sicherstellen, dass Sie alles Mögliche tun, um es zu schützen. Stellen Sie sicher, dass der Bucket nicht öffentlich zugänglich ist und beschränken Sie den Zugriff nur auf die Benutzer, die ihn unbedingt benötigen. Protokollieren Sie den gesamten Zugriff auf den Bucket und stellen Sie sicher, dass dieser S3-Log-Bucket nur für Benutzer zugänglich ist, die nicht auf den CloudTrail-Log-Bucket zugreifen können. Sie sollten auch erwägen , MFA zu verlangen, um Ihre Log-Buckets zu löschen.
  • Log-Dateien mit SSE-KMS verschlüsseln: Obwohl CloudTrail-Logs standardmäßig verschlüsselt sind, können Sie eine zusätzliche Verteidigungsebene hinzufügen, die die serverseitige Verschlüsselung mit AWS KMS ermöglicht. Mit dieser Option benötigt ein Benutzer nicht nur die Berechtigung, auf den S3-Bucket zuzugreifen, der Ihre Log-Dateien enthält, sondern benötigt auch Zugriff auf einen Kundenstammschlüssel (Customer Master Key, CMK), um diese Dateien zu entschlüsseln. Dies ist eine großartige Möglichkeit, sicherzustellen, dass nur wenige wenige Benutzer auf Ihre Protokolle zugreifen können. Stellen Sie beim Erstellen Ihres CMK sicher, dass Sie auch die automatische Schlüsselrotation aktivieren.
  • Log-Validierung: CloudTrail kann automatisch Validierungsdateien erstellen, die verwendet werden, um zu erkennen, ob ein CloudTrail-Log manipuliert wurde.Da die Manipulation von Protokolldateien ein beliebtes Vorgehen von Angreifern ist, um ihre Spuren zu verwischen, sollte die Log-Validierung für Ihren Trail unbedingt aktiviert sein.

Obwohl die meisten Protokolle in CloudTrail erfasst werden, gibt es noch einige andere Protokolle, die Sie unbedingt erfassen sollten. VPC Flow Logs zeigen Daten zum IP-Verkehr zu und von den Netzwerkschnittstellen in Ihrer Virtual Private Cloud (VPC). Sie können Ihnen dabei helfen, Intra-VPC-Port-Scans, Anomalien im Netzwerkverkehr und bekannte bösartige IP-Adressen zu identifizieren. Wenn Sie AWS Route 53 als DNS verwenden, sollten Sie auch DNS-Anfragen protokollieren. Mithilfe dieser Protokolle können Sie Bedrohungsinformationen abgleichen und bekanntermaßen schädliche oder sich schnell ausbreitende Bedrohungen identifizieren. Beachten Sie, dass Sie AWS CloudWatch verwenden müssen, um Ihre DNS-Protokolle anzuzeigen.

8. Überwachen, erkennen und reagieren

Da Sie nun wissen, wie Sie Logs verwenden können, um Einblicke in die Aktivitäten in Ihrer AWS-Umgebung zu erhalten, besteht die nächste Frage darin, wie Sie diese Transparenz nutzen können. Eine (sehr manuelle) Option ist die Verwendung von AWS CloudWatch-Alarmen. Mit diesem Ansatz erstellen Sie Alarme für verschiedene verdächtige Aktionen wie unautorisierte API-Aufrufe, VPC-Änderungen usw. Eine Liste der empfohlenen Alarme ist in den CIS-Benchmarks für AWS enthalten. Die Herausforderung bei diesem Ansatz besteht darin, dass jeder Alarm manuell erstellt und gewartet werden muss.

Eine weitere Option ist die Verwendung von AWS GuardDuty. GuardDuty verwendet CloudTrail, VPC-Flow Logs und DNS-Protokolle, um verdächtiges Verhalten zu erkennen und darauf hinzuweisen. Das Schöne an GuardDuty ist, dass es auf einer von AWS verwalteten Liste von Ergebnissen (auch potenziellen Sicherheitsproblemen genannt) sowie maschinellem Lernen basiert. Das bedeutet, dass keine manuelle Einrichtung oder Wartung erforderlich ist, um Benachrichtigungen über verdächtige Aktivitäten zu erhalten. Das Erkennen verdächtiger Aktivitäten ist jedoch nur der erste Schritt bei der Reaktion auf einen Vorfall.

Ihr Sicherheitsteam muss die relevanten Log-Dateien und andere Daten aufrufen, um zu überprüfen, ob ein Vorfall aufgetreten ist, und dann die beste Reaktion und Wiederherstellung bestimmen. Wenn das Team mehrere verschiedene Datenquellen durchsuchen muss, um diese Informationen zu finden, kann dies einen beträchtlichen Zeitaufwand für die Untersuchung bedeuten. In Hybrid- oder Multi-Cloud-Umgebungen ist diese Herausforderung sogar noch größer.

Die automatische Zentralisierung aller relevanten Daten während einer Untersuchung ist nur einer der Gründe, warum sich viele Sicherheitsteams für ein modernes SIEM- und Incident Detection-Toolentscheiden. Eine gute SIEM-Lösung verfügt über eine CloudTrail-Integration und ermöglicht es Ihnen, alle Protokolle von AWS neben den Protokollen von On-Prem-Netzwerken und anderen Cloud-Anbietern wie Azure und Google Cloud Platform (GCP) zu speichern. Diese Möglichkeit, alle Daten zu zentralisieren, kann die Ermittlungen enorm beschleunigen, insbesondere wenn Sie einen böswilligen Akteur verfolgen müssen, der sich in Ihren Umgebungen bewegt hat. 

Ein gutes SIEM bietet auch eine Vielzahl anderer Funktionen, um die Fähigkeit Ihres Sicherheitsteams zu verbessern, einen Angriff zu erkennen, zu bestätigen und darauf zu reagieren. Beispielsweise verwenden die fortschrittlichsten SIEMs mehrere Techniken, um verdächtiges Verhalten zu erkennen. Andere Funktionen, auf die Sie achten sollten, sind die Möglichkeit, benutzerdefinierte Warnungen zu erstellen, Täuschungstechnologie (Dinge wie vorgefertigte Honeypots und Honey-Benutzer, die Warnungen auslösen, wenn darauf zugegriffen wird) und File Integrity Monitoring (FIM).

Alle diese Funktionen bieten zusätzliche Erkennungsebenen. Sie sollten auch nach einem SIEM suchen, das Visualisierungsfunktionen wie anpassbare Dashboards und Untersuchungszeitplänebietet, die Ihre zentralisierten Daten besser nutzbar machen. Stellen Sie außerdem sicher, dass jedes SIEM, das Sie in Betracht ziehen, über eine integrierte Automatisierungverfügt, da dies die Reaktionszeiten bei einem Vorfall erheblich verkürzen kann. Schließlich nutzen viele Teams gerne sowohl AWS als auch Tools von Drittanbietern, um ihre AWS-Umgebung zu sichern. In diesem Fall ist es wichtig, ein SIEM zu finden, das eine GuardDuty-Integration beinhaltet.

9. Vereinheitlichung von AWS mit lokaler und anderer Cloud-Sicherheit

Ein häufig auftretender Fehler ist der Ansatz, die AWS-Sicherheit eigenständig und getrennt von allen anderen Maßnahmen zum Schutz der vorhandenen IT-Infrastruktur zu sichern. Dadurch entsteht eine Lücke, die böswillige Akteure ausnutzen können. So haben wir beispielsweise Situationen gesehen, in denen die lokale und die AWS-Sicherheit eines Unternehmens so gestaltet wurden, dass sie unterschiedliche potenzielle Bedrohungen angehen. Die daraus resultierenden Lücken machten beide Netzwerke anfällig.

Ein einzelnes Team mit Zuständigkeit für die Sicherung der gesamten IT-Infrastruktur sorgt dafür, dass keine Vermutungen aufgestellt werden, was das „andere“ Sicherheitsteam tut oder unterlässt. Stattdessen gibt es ein Team, das sich seiner Zuständigkeit für alle Aspekte der Cybersicherheit Ihres Unternehmens bewusst ist. Die Verknüpfung Ihrer Sicherheitsmaßnahmen unter Aufsicht eines Teams kann auch während eines Vorfalls äußerst wichtig sein. Das Team hat unmittelbaren Zugriff auf weit mehr Daten. Zudem ist es sehr viel einfacher, Klarheit über die Zuständigkeiten der einzelnen Teammitglieder zu schaffen.

Die Vereinheitlichung zählt nicht nur, weil ein Team die Verantwortung übernimmt, sondern sie bringt auch alle Sicherheitsdaten in einem Tool-Satz zusammen. Die überragende Mehrheit der Unternehmen beschränkt ihren Einsatz von AWS nicht auf die einfache Nutzung. Sie verfügen in den allermeisten Fällen über lokale Netzwerke und Endgeräte der Mitarbeiter, die gesichert werden sollen. In vielen Fällen nutzen Unternehmen auch mehrere Cloud-Anbieter.

Wenn Sie verschiedene Sicherheitslösungen für die einzelnen Umgebungen verwenden, erhöht sich die Wahrscheinlichkeit der toten Winkel. Zudem gilt, je mehr Tools Ihr Sicherheitsteam einsetzt, desto höher ist deren Arbeitsbelastung, da sie ständig die Tools wechseln müssen, um sich manuell ein vollständiges Bild von der aktuellen Cybersicherheitslage des Unternehmens machen zu können.

10. Automatisieren

Angesichts so vieler Best Practices zur Sicherung des AWS ist es illusorisch, dass die Benutzer jederzeit alle beachten. Selbst wenn das möglich wäre, würden Fehler auftreten. Damit in Ihrer AWS-Umgebung die Sicherheitsgrundlagen kontinuierlich beachtet werden, sollten Sie auf Automatisierung setzen.

So können Sie beispielsweise eine Kombination von CloudFormation und Lambda oder einem Tool wie Terraform oder eine der fortschrittlicheren CSPMs verwenden, um die Bereitstellung neuer AWS-Infrastruktur zu automatisieren, und sichergehen, dass alles mit der von Ihnen etablierten Baseline konform ist. Sie können diese Tools auch automatisch markieren oder kündigen, wenn die Infrastruktur nicht konform ist.

Ein weiterer Vorteil der Automatisierung steckt in der Kapazität, die dadurch für Ihr Sicherheitsteam frei wird. Der kontinuierliche Mangel an Sicherheitsfachkräften bedeutet, dass Teams überfordert sind. Diese Lage wird nur noch schlimmer, wenn ein Unternehmen in die Cloud wechselt, was den Fußabdruck der vom Team zu sichernden Infrastruktur enorm ausdehnt.

Um Ihrem Team einen Vorteil gegenüber den Angreifern zu verschaffen, sollten Sie auch SOARin Betracht ziehen. Mit SOAR können Sie Daten problemlos zwischen lokalen und Cloud-Diensten austauschen und so eine einheitliche Sicht auf die gesamte IT-Infrastruktur des Unternehmens erhalten. Ein SOAR kann auch arbeitsintensive Aufgaben wie Onboarding und Offboarding sowie die Zusammenführung von Daten in der Anfangsphase einer Untersuchung erleichtern.

Die Verwendung eines SOAR-Tools reduziert die Arbeitslast des Sicherheitsteams und hilft ihm, effizienter zu arbeiten. Mit einem SOAR hat Ihr Sicherheitsteam mehr Zeit, sich auf hochwertige Aufgaben zu konzentrieren, und verkürzt den Zeitaufwand für die Untersuchung von Vorfällen.

Erfahren Sie mehr über AWS & Cloud Security

Fordern Sie eine AWS-Risikoanalyse an

Erfahren Sie mehr über die Cloud Security Lösung von Rapid7: InsightCloudSec

AWS Security: Aktuelles aus dem Blog