Cybersecurity Grundlagen: Best Practices für die Amazon Web Services (AWS) Cloud-Sicherheit

Was ist der Unterschied zwischen der herkömmlichen IT-Sicherheit und der Cloud-Sicherheit?

Auf oberster Ebene sind die Grundlagen der Sicherung der Cloud-Infrastruktur den Grundlagen der Sicherung eines lokalen Netzwerks ähnlich. So trifft beispielsweise das NIST Cybersecurity Framework weiterhin zu: Sie möchten identifizieren, was Sie für die Sicherung dieser Assets benötigen, wie Sie bösartige Aktivitäten erkennen und auf Sicherheitsvorfälle reagieren und im Anschluss daran eine Wiederherstellung in Angriff nehmen können. Allerdings ist die Art und Weise, wie Sie unter den einzigartigen Aspekten einer Cloud-Umgebung diese Funktionen durchführen, mitunter ganz anders.

In einer Cloud-Umgebung liegt der offensichtlichste, aber häufig nicht verstandene Unterschied möglicherweise 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 gemeinsame Verantwortungsmodell sieht vor, dass AWS für die Sicherung der seiner Cloud zugrundeliegenden Infrastruktur verantwortlich ist. Das bedeutet, dass es für die Wartung und Aktualisierung von Hardware sowie für die physische Sicherheit dieser Hardware zuständig 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. Mehr erfahren über die Sicherung von AWS Umgebungen.

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.

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 Sicherheitsteams die Kontrolle über die gesamte neue Infrastruktur, die hinzukommt. In einem Cloud-Netzwerk kann neue Infrastruktur von jeder beliebigen Person oder jedem System mit den passenden Zugriffsberechtigungen sofort hinzugefügt werden. Dies vereinfacht es, ein Cloud-Netzwerk zu ändern, aber ohne die richtigen Leitplanken und eine bestehende Überwachung erhöht es auch die Möglichkeit, dass neue Infrastruktur nicht sicher konfiguriert wurde und somit anfällig ist.

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. Das lässt die Vermutung zu, dass das Asset auch nicht lange genug vorhanden ist, um ein Risiko darzustellen, aber Daten aus unserem globalen Honeypot-Netzwerk Project Heisenberg zeigen, dass neue Assets von böswilligen Quellen innerhalb weniger Stunden nach deren Auftreten 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 Situationen muss das Sicherheitsteam zwischen verschiedenen Systemen hin und her springen, um seine Sicherheitsmaßnahmen zu verwalten. 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?

Ähnlich wie ein lokales Netzwerk ist auch ein AWS nur so sicher, wie Sie es gestalten. Zuvor haben wir bereits das gemeinsame Verantwortungsmodell und die Tatsache angesprochen, dass AWS für die Sicherheit der ihr zugrundeliegenden Infrastruktur zuständig 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-Sicherheit

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 Beweis für den hohen Wert einer starken AWS-Sicherheit liegt in der Rufschädigung, die ein vermeidbarer Vorfall auslösen kann. Gartner prognostiziert, dass 95 % aller Cloud-Sicherheitsvorfälle bis Ende 2020 auf das Konto des Kunden gehen. Wenn Kunden herausfinden, dass ein Unternehmen aufgrund eines leicht vermeidbaren Fehlers kompromittiert wurde, kann es deren Vertrauen derart erschüttern, dass sie ihre Aufträge anderweitig vergeben.

Best Practices für die AWS Cloud-Sicherheit

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) = Objektspeicherung
• EC2 (Elastic Compute Cloud) Instanz = Virtueller Rechner/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

Im Idealfall sollten Sie sich bereits vor der Implementierung Gedanken über die Sicherung Ihrer AWS machen. Wenn der Zug bereits abgefahren ist, keine Sorge: gegebenenfalls müssen Sie nur ein paar zusätzliche Vorkehrungen treffen, um einige Best Practices zu implementieren.

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

Ihre Sicherheits- und DevOps-Teams sollten zusammenarbeiten, um die Gestaltung der AWS-Umgebung aus der Sicherheitsperspektive zu definieren. Die Baseline sollte klar alle Verfahren beschreiben, angefangen bei der Konfiguration der Assets bis hin zum Maßnahmenplan bei Vorfällen. Die Teams sollten als Ausgangspunkte den Einsatz von Ressourcen wie das AWS Well-Architected Framework und die CIS Benchmarks für AWS in Erwägung ziehen. Es empfiehlt sich möglicherweise auch, die Unterstützung eines AWS Solutions Architect anzufordern, der als technischer Experte den Kunden beim Aufbau ihrer AWS-Umgebung behilflich sein kann. Achten Sie darauf, dass Ihre Baseline auf Ihre Produktionsumgebung sowie alle Test- und Vorproduktionsumgebungen angewandt wird. Überprüfen Sie die Baseline mindestens alle sechs Monate, um Dinge wie neue Bedrohungen und Veränderungen in Ihrer Umgebung einzubeziehen.

4. Durchsetzung Ihrer Baseline

Sobald Ihre Sicherheits- und DevOps-Teams die Struktur Ihre AWS-Sicherheitsgrundlagen definiert haben, müssen Sie sie umsetzen. Erleichtern Sie Ihren Entwicklern die Einhaltung der Baseline, indem sie ihnen Infrastrukturvorlagen zur Verfügung stellen, die bereits richtig konfiguriert wurden. Das können Sie mithilfe von AWS CloudFormation oder durch Nutzung eines Anbieters einer Infrastruktur-als-Code wie Terraform durchführen.

Sie benötigen auch eine Überwachungslösung, um Compliance-Verstöße gegen die Baseline zu erkennen (entweder weil etwas fehlkonfiguriert bereitgestellt wurde oder weil nach der Bereitstellung eine Änderung vorgenommen wurde). Eine Option dafür ist die Verwendung von AWS Security Hub , aber mehrere Vulnerability-Management-Lösungen von Drittanbietern enthalten integrierte Überwachung auf Fehlkonfigurationen in der Cloud. Der Einsatz einer VM-Lösung mit integrierter Fehlkonfigurationserkennung hat zwei Vorteile. Zunächst konsolidiert sie zwei Arten der Risikoüberwachung (Asset-Schwachstellen und Fehlkonfigurationen der Cloud-Infrastruktur) in einem Tool. Zweitens werden in den meisten Vulnerability-Management-Lösungen alle Fehlkonfigurationsregeln und -erkennungen vom Anbieter verwaltet, während Sie im AWS Security Hub die Regeln selbst einrichten und verwalten müssen. Erfahren Sie mehr über InsightVM für die Schwachstellenbewertung und die Cloud-Konfiguration.

Eine weitere Option zur Durchsetzung Ihrer Sicherheits-Baseline ist eine Cloud Security Posture Management (CSPM) Lösung. Eine hochwertige CSPM ist in der Lage, Konten von mehreren Cloud-Anbietern auf Fehlkonfigurationen zu überwachen. Das ist eine große Sache, da Ihr Unternehmen dann in der Lage ist, eine Sicherheits-Baseline für alle Ihre Cloud-Anbieter einzurichten und sie mit einem einzigen Tool umzusetzen. Neben der Fähigkeit zur Überwachung von Cloud-Konten auf Fehlkonfigurationen sollte die CSPM auch in der Lage sein, die Fehlkonfigurationen automatisch zu beheben, sobald sie erkannt werden. Das ist eine erhebliche Entlastung Ihres Sicherheitsteams und sorgt dafür, dass nichts übersehen wird.

Andere Fähigkeiten einer CSPM, auf die es sich lohnt, zu achten, sind die Fähigkeit, die Probleme in der Infrastruktur-als-Code zu markieren, bevor etwas bereitgestellt wird, IAM Governance (siehe den nächsten Abschnitt zu IAM) und Compliance Audits . CSPMs sind in der Regel eher teuer, aber für Unternehmen, die mehrere Cloud-Anbieter nutzen oder eine große Anzahl von Konten bei einem einzigen Anbieter haben, bietet eine CSPM die Möglichkeit, das Chaos, alle Konten verwalten zu wollen, zu strukturieren.

5. Zugriffsrechte beschränken

Was bei der Einrichtung einer sicheren AWS-Umgebung zählt, ist die Beschränkung der Zugriffsrechte auf die Benutzer und Systeme, die Zugriff haben müssen. Dies erzielen Sie mit dem AWS Identity Access Management (IAM) . IAM setzt sich aus folgenden Komponenten zusammen:

• Benutzer: Einzelpersonen oder Systeme, die mit dem AWS interagieren müssen. Ein Benutzer besteht aus einem Namen und Zugangsdaten.
• Zugangsdaten: Die Art, wie ein Benutzer auf das AWS zugreifen kann. Zu den Zugangsdaten zählen Konsolenpasswörter, Zugriffsschlüssel, SSH-Schlüssel und Serverzertifikate.
• Gruppen: Eine Sammlung von Benutzern. 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 sind vergleichbar mit Benutzern, verfügen aber nicht über langfristige Zugangsdaten wie ein Passwort oder einen Zugriffsschlüssel. Eine Rolle kann von einem Benutzer oder einem Dienst übernommen werden. Wenn eine Rolle übernommen wird, werden temporäre Zugangsdaten für die Sitzung erteilt. Nur die von Ihnen festgelegten Benutzer, Rollen, Konten oder Dienste können eine Rolle übernehmen. Rollen geben Ihnen die Möglichkeit, einem Benutzer Zugriff auf mehrere AWS-Konten zu gewähren oder einer Anwendung Zugang zu AWS-Diensten zu erteilen, ohne dazu langfristige Zugangsdaten 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-Richtlinien“ 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:

• Nicht den Root-Benutzer verwenden: Der Root-Benutzer ist der Benutzer, der mit der E-Mail-Adresse assoziiert ist, mit der das AWS-Konto eingerichtet wurde. Der Root-Benutzer kann Dinge ausführen, die selbst ein voller Administrator nicht ausführen kann. Wenn ein böswilliger Akteur die Zugangsdaten eines Root-Benutzers aufdeckt, kann es zu enormen Schäden kommen. Denken Sie daran, ein sehr komplexes Passwort für Ihren Root-Benutzer zu verwenden, MFA zu aktivieren (idealerweise mit der Hardware MFA) und das MFA-Gerät in einem Safe einzuschließen. Ja, das ist ganz wortwörtlich gemeint: schließen Sie das MFA-Gerät ein. Löschen Sie zudem die Zugriffsschlüssel, die für den Root-Benutzer erstellt wurden. Setzen Sie den Root-Benutzer nur in den seltenen Fällen ein, in denen er gebraucht wird.
• Benutzerverwaltung über föderiertes SSO: Es gilt als Best Practice im Sicherheitsbereich, das föderierte SSO zur Verwaltung des Mitarbeiterzugriffs auf die Ressourcen einzusetzen, und dazu gehört auch AWS. Nutzen Sie die IAM-Funktionalität Identity Provider , damit Sie den individuellen Zugriff auf AWS über Ihre bestehende SSO-Lösung zentral verwalten können.
• Richtlinien nicht an einzelne Benutzer binden: Wenden Sie sie stattdessen auf Gruppen und Rollen an. Das macht es weitaus einfacher, die Visibility zu erhalten, die Ihnen zeigt, wer auf was Zugriff hat, und minimiert die Chancen, dass ein einzelner Benutzer übersehen wird, der auf viel mehr zugreifen kann, als er benötigt.
• Starkes Passwort anfordern: Sie sollten IAM so konfigurieren, dass ein starkes Passwort erforderlich ist . CIS empfiehlt, IAM auf eine Passwortlänge von mindestens 14 Zeichen einzurichten, wobei das Passwort mindestens einen Groß- und Kleinbuchstaben, eine Zahl und ein Symbol enthalten muss. CIS empfiehlt auch, dass die Passwörter mindestens alle 90 Tage verfallen und zuvor verwendete Passwörter nicht erneut eingesetzt werden können.
• MFA als Pflicht: Neben einem starken Passwort sollten Sie sicherstellen, dass alle Benutzer MFA aktiviert haben 
• Ungenutzte Zugangsdaten löschen: IAM kann einen Zugangsdatenbericht erstellen , der zeigt, wann die Zugangsdaten eines Benutzers zuletzt verwandt wurden. Sehen Sie sich diesen Bericht regelmäßig an und deaktivieren bzw. löschen Sie Zugangsdaten, die seit 90 Tagen nicht mehr im Einsatz waren.
• 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 Sicherheitslücken achten

Viele sind sich nicht bewusst, dass nicht behobene Schwachstellen immer noch eine Bedrohung darstellen – selbst in der Cloud. Um Schwachstellen in EC2-Instanzen zu erkennen, können Sie AWS Inspector oder eine Vulnerability Management-Lösung von Drittanbietern verwenden. Durch die Verwendung einer Vulnerability Management-Lösung können Sie Ihre Arbeit besser priorisieren, Ihre Reporting-Fähigkeiten verbessern, die Kommunikation mit den Infrastrukturinhabern erleichtern und jedem dabei helfen, die Fortschritte des Risikomanagement zu messen. Darüber hinaus bevorzugen Sicherheitsteams bei der Arbeit mit einer Hybrid- oder Multi-Cloud-Umgebung häufig eine Lösung von Drittanbietern, da sie ihnen ermöglicht, das Vulnerability- und Risikomanagement in allen Umgebungen zentral zu überwachen (mehr dazu im Best-Practices-Artikel Nr. 9).

Auch wenn die meisten Cybersicherheitsexperten mit dem Schwachstellenmanagement vertraut sein sollten, gibt es einige, recht einzigartige Aspekte eines VM 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 von einer Minute zur nächsten. In einer derartig dynamischen Umgebung reichen wöchentliche oder gar tägliche Scans nicht aus, um sich ein genaues Bild von den Sicherheitslücken und Ihrer Risikoexponierung zu machen. Es ist wichtig, zu wissen, wie Sie sich ein komplettes Bild von den EC2-Instanzen machen können, und die Möglichkeit haben, die Instanzen während ihrer gesamten Lebensdauer kontinuierlich zu überwachen. Investieren Sie für einen vollständigen Überblick über Ihre EC2-Instanzen in eine Vulnerability Management-Lösung mit dynamischer Asset-Erkennung, die automatisch neue Instanzen erkennt, sobald diese bereitgestellt werden. Eine ähnliche Fähigkeit kann mit AWS Inspector unter Einsatz von CloudWatch Events erzielt werden, obwohl das Setup ein wenig mehr Eigenbeteiligung erfordert.

Wenn Schwachstellen in einer EC2-Instanz erkannt werden, können sie auf unterschiedliche Weise behoben werden. Eine Option ist die Verwendung des Patch Manager im AWS Systems Manager. Dieser Ansatz kommt der herkömmlichen Verwaltung von Sicherheitslücken in lokalen Netzwerken am nächsten. Viele Cloud-Umgebungen wurden jedoch als unveränderlich konzipiert. Mit anderen Worten, Assets wie EC2-Instanzen sollten nach ihrer Bereitstellung nicht mehr verändert werden. Wenn jedoch eine Änderung vorgenommen werden muss, wird das vorhandene Asset beendet und durch das neue ersetzt, das 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.

Ein weiterer Ansatz ist die Verwendung eines Infrastruktur-Automationstools wie Chef oder Puppet , um die AMIs zu aktualisieren und erneut bereitzustellen. Dieser Ansatz ergibt Sinn, wenn Sie zur Wartung Ihrer EC2-Instanzen bereits eines dieser Tools verwenden.

7. Protokolle erfassen und schützen

Genau wie in jedem anderen System auch sollten Sie alle Aktivitäten protokollieren, die in Ihrer AWS-Umgebung auftreten. Protokolle sind nicht nur für die Überwachung und Compliance von Bedeutung, sondern sind, wenn wir uns das NIST Cybersecurity Framework kurz ins Gedächtnis rufen, ein entscheidender Bestandteil, um bösartige Aktivitäten zu erkennen (insbesondere, wenn diese in ein modernes SIEM fließen), auf Sicherheitsverstöße zu reagieren und die anschließende Wiederherstellung zu vollziehen.

In AWS werden die meisten Protokolle mit CloudTrail erfasst. Dieser Dienst erfasst automatisch und kostenfrei die API-Aktivität im AWS als das, was AWS als Management Events in Ihrem AWS-Konto bezeichnet (Sie zahlen nach wie vor die Speicherkosten). CloudTrail erfasst Zehntausende von Vorfällen, einschließlich kritischer Sicherheitsinformationen wie Logins und Konfigurationsänderungen bei AWS-Diensten. Für eine Gebühr können Sie in CloudTrail auch „Trails“ erstellen, mit denen Sie zusätzliche Aktivitäten erfassen und Ihre Protokolle zur langfristigen Speicherung und/oder für den Export an S3 senden. Hier sind einige Best Practices für die Einrichtung von CloudTrail in Ihrem AWS-Konto:

• Trail für alle Regionen : Obwohl es Geld kostet, sollten Sie einen Trail in CloudTrail erstellen, damit Sie alle Ihre Protokolle an einen S3-Sammelspeicher (Bucket) senden können. Auf diese Weise können Sie Ihre Protokolle unbefristet speichern (CIS empfiehlt eine Aufbewahrung von mindestens 365 Tagen). Wenn Sie Ihren Trail erstellen , achten Sie darauf, dass die Option Apply trail to all regions (Trail auf alle Regionen anwenden) aktiviert ist. Dann kann Ihr Trail Ihnen Aktivitäten aus allen AWS-Regionen anzeigen. Wenn Sie diese Option nicht aktivieren, erfasst Ihr Trail nur Protokolle von Aktivitäten in der AWS-Region, in der Sie sich bei der Erstellung des Trails befinden. Die Erfassung von Daten aus allen Regionen ist wichtig, um Transparenz zu haben, sollte ein suspekter Vorfall in einer Region auftreten, die Sie normalerweise nicht verwenden. Wenn Sie mehrere AWS-Konten verwenden, empfiehlt sich möglicherweise auch der Einsatz nur eines Buckets zur Speicherung der Protokolle aus allen Konten.
• Schutz des S3-Buckets mit den Protokollen: Da Ihre Protokolle ein wichtiger Bestandteil der Erkennung und Behebung eines Vorfalls sind, ist der S3-Bucket, in dem Sie Ihre Protokolle speichern, für den Angreifer ein zentrales Ziel. Daher sollten Sie ihn so gut wie möglich schützen. Achten Sie darauf, dass der Bucket nicht öffentlich zugänglich ist und beschränken Sie die Zugriffsrechte auf die Benutzer, die unbedingt Zugriff brauchen. Protokollieren Sie jeden Zugriff auf den Bucket und achten Sie darauf, dass dieser S3-Protokoll-Bucket nur für Benutzer zugänglich ist, die keinen Zugang zum CloudTrail Log-Bucket haben. Überlegen Sie auch MFA zur Pflicht zu machen , um die Protokoll-Buckets zu löschen.
• Verschlüsselung der Log-Dateien mit SSE-KMS: Obwohl CloudTrails standardmäßig verschlüsselt sind, können Sie eine zusätzliche Schutzstufe hinzufügen, die die serverseitige Verschlüsselung mit AWS KMS ermöglicht . Unter dieser Option benötigt der Benutzer nicht nur Zugriffsrechte auf den S3-Bucket mit Ihren Protokolldateien, sondern auch Zugang zum Customer Master Key (CMK), um die besagten Dateien zu entschlüsseln. Das ist eine großartige Lösung, um sicherzugehen, dass nur ganz wenige Personen Zugang zu den Protokollen haben. Wenn Sie Ihre CMK erstellen, denken Sie an die Aktivierung der automatischen Schlüsselrotation
• 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.

Auch wenn die meisten Protokolle in CloudTrail gesammelt werden, sollten Sie auch noch ein paar andere Protokolle erfassen. VPC Flow Logs zeigen Daten über den IP-Datenverkehr, der über die Netzwerkschnittstellen in Ihre virtuelle private Cloud (VPC) fließt und von ihr abgeht. Sie helfen Ihnen, Intra-VPC-Port-Scans, Anomalien im Netzwerkverkehr und bekannte bösartige IP-Adressen aufzudecken. Wenn Sie die AWS Route 53 als DNS verwenden, sollten Sie auch DNS-Abfragen protokollieren . Diese Logs können Sie mit Intelligence-Angaben zu Bedrohungen abgleichen und bekannte böswillige oder sich schnell verbreitende Bedrohungen identifizieren. Denken Sie daran, dass Sie zur Ansicht von DNS-Logs die AWS CloudWatch brauchen.

8. Überwachen, erkennen und reagieren

Da Sie nun wissen, wie Sie Logs verwenden, um Einblick in die Aktivitäten in Ihrer AWS-Umgebung zu haben, stellt sich die nächste Frage, wie Sie diese Visibility nutzen können. Eine (sehr manuelle) Option ist die Verwendung von AWS CloudWatch Alarms . Mit diesem Ansatz bauen Sie Warnmeldungen für verschiedene suspekte Handlungen wie nicht autorisierte API-Aufrufe, Änderungen im VPC usw. auf. Eine Liste der empfohlenen Warnmeldungen finden Sie in den CIS Benchmarks für AWS. Die Herausforderung dieses Ansatzes ist, dass jede Warnmeldung manuell aufgebaut und gepflegt werden muss.

Eine weitere Option ist die Verwendung von AWS GuardDuty . GuardDuty verwendet CloudTrail, VPC Flow Logs und DNS-Logs, um verdächtige Verhaltensweisen zu erkennen und auf sie aufmerksam zu machen. Was GuardDuty so praktisch macht, ist, dass es von einer AWS-verwalteten Liste der Ergebnisse (d. h. potenzielle Sicherheitsprobleme) sowie von maschinellem Lernen betrieben und gespeist wird. Das bedeutet, dass kein manuelles Setup und keine manuelle Wartung für den Empfang von Warnmeldungen über verdächtige Aktivitäten erforderlich sind. Die Erkennung verdächtiger Aktivitäten ist jedoch nur der erste Schritt der ergriffenen Maßnahmen bei einem 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 zentrale Bündlung aller relevanten Daten bei der Untersuchung ist nur einer der Gründe, warum viele Sicherheitsteams sich für ein modernes SIEM- und Vorfallerkennungs-Tool entscheiden. Eine gute SIEM-Lösung enthält eine CloudTrail-Integration und gibt Ihnen die Möglichkeit, alle Logs von AWS neben Logs aus lokalen Netzwerken und von anderen Cloud-Anbietern wie Azure und Google Cloud Platform (GCP) zu speichern. Diese Fähigkeit, alle Daten zu zentralisieren, kann bei beschleunigten Untersuchungen enorm hilfreich sein, insbesondere wenn Sie einen böswilligen Akteur verfolgen müssen, der durch Ihre Umgebungen gezogen ist.

Ein gutes SIEM bietet auch eine Vielzahl anderer Funktionen, die Ihr Sicherheitsteam befähigen, einen Angriff besser zu erkennen, zu bestätigen und auf ihn zu reagieren. So verwenden die fortschrittlichsten SIEMs verschiedene Methoden, um verdächtiges Verhalten zu erkennen. Zu den anderen interessanten Funktionen zählen die Möglichkeit zur Erstellung benutzerdefinierter Warnmeldungen, Täuschungstechnologie (Dinge wie vorintegrierte Honeypots und Honey-User, die bei Zugriff Warnmeldungen auslösen) und das File Integrity Monitoring (FIM). Alle diese Kapazitäten bieten zusätzliche Erkennungsebenen. Empfehlenswert ist auch ein SIEM, das Visualisierungsfunktionen wie benutzerdefinierte Dashboards und Untersuchungszeitrahmen bietet, die ihre zentralisierten Daten stärker nutzbar machen. Achten Sie zudem darauf, dass das von Ihnen ins Auge gefasste SIEM über integrierte Automation verfügt, da sie die Reaktionszeiten bei Vorfällen enorm reduzieren kann. Abschließend nutzen viele Teams für die Sicherung ihrer AWS-Umgebung gerne sowohl AWS als auch Tools von Drittanbietern. In dem Fall ist es wichtig, ein SIEM zu wählen, 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. Diese Tools können auch Infrastruktur automatisch markieren oder beenden, wenn sie die Compliance-Werte nicht erfüllt.

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. Damit Ihr Team dafür gewappnet ist, sollten Sie die Wahl eines Tools der Sicherheitsorchestrierung, -automatisierung und Reaktion (SOAR) erwägen. Mit SOAR ist es möglich, Daten zwischen lokalen und Cloud-Diensten zu übermitteln, was einen einheitlichen Überblick über die gesamte IT-Infrastruktur des Unternehmens ermöglicht. Ein SOAR kann auch Fleißarbeit wie Onboarding und Offboarding genau wie arbeitsintensive Prozesse wie die Aggregation von Daten in den ersten Untersuchungsphasen verkürzen. Die Verwendung eines SOAR reduziert die Arbeitslast des Sicherheitsteams und hilft ihm, effizienter zu arbeiten. Mit einem SOAR hat Ihr Sicherheitsteam mehr Zeit, um sich auf bedeutendere Aufgaben zu konzentrieren. Gleichzeitig gelingt eine Untersuchung von Vorfällen in kürzerer Zeit.

Quelle: Cybersecurity Grundlagen Rapid7