10 Sicherheitsaspekte bei der Migration zu AWS

Cloud-Datenspeicher bietet gegenüber herkömmlichen Rechenzentren viele praktische Vorteile. Ein Umzug bringt jedoch auch zahlreiche besondere Sicherheitsaspekte mit sich.

Beginnen Sie beim Umstieg auf AWS so, wie Sie weitermachen möchten. Unternehmen, die ihre Datenspeicherung in die Cloud verlagern, müssen ihren Ansatz zur Informationssicherheit anpassen, um ihre Daten zu schützen. Wenn Sie während der Migration geeignete Sicherheitspraktiken einführen, können zukünftige Teams Anwendungen und Funktionen sicher und effizient bereitstellen und zugleich gängige AWS-Risiken vermeiden. Wer hingegen an herkömmlichen Sicherheitspraktiken festhält, bremst Teams aus und schränkt ihren künftigen Erfolg ein.

Kürzlich haben wir unseren Bericht Snyk Top 10: Security Strategies when Migrating to AWS veröffentlicht. Er behandelt die wichtigsten Aspekte, damit der Umstieg einfach und sicher gelingt. In diesem Beitrag werfen wir einen kurzen Blick auf jeden davon:

1. AppSec und CloudSec gemeinsam angehen.

2. Sicherheitsteams in AppDev- und DevOps-Teams integrieren.

3. Die App-Entwicklung modernisieren und Sicherheit im gesamten SDLC verankern.

4. Cloud-Architekturen von Anfang an sicher konzipieren.

5. Entwickler und Cloud Engineers befähigen, sicher zu entwickeln.

6. Infrastructure as Code von Anfang an einsetzen und absichern.

7. Cloud-Sicherheitsleitplanken in Deployment-Pipelines einsetzen.

8. Cloud-Sicherheit auf einer Grundlage aus Policy as Code (PaC) aufbauen.

9. Identity- und Access-Management-Dienste (IAM) sicher nutzen.

10. Festlegen, was wichtig ist – und kontinuierlich messen.

1. AppSec und CloudSec ganzheitlich gemeinsam angehen

Früher ließen sich Cloud-Betrieb und App-Entwicklung in getrennte Ebenen unterteilen. Heute verschwimmen die Grenzen zwischen Anwendungssicherheit und Infrastruktursicherheit zunehmend. Angreifer können Schwachstellen überall in Ihrem Stack ausnutzen. Wenn AppSec- und CloudSec-Teams Anwendungen mit unterschiedlichen Tools auf Sicherheitsrisiken prüfen, besteht die reale Gefahr, Schwachstellen zu übersehen, die mehrere Ebenen betreffen, oder Fälle, in denen sich eine Ebene auf eine andere auswirkt.

Lassen Sie nicht zu, dass AppSec und CloudSec in Silos arbeiten. Ein umfassender DevSecOps-Ansatz sollte einen zentralisierten, konsolidierten Prozess zur Erkennung und Behebung von Risiken nutzen. So erhalten Sie nicht nur einen besseren Gesamtkontext für die Cloud-Umgebung und die Softwareentwicklung, sondern arbeiten auch effizienter und können Risiken im gesamten Unternehmen besser priorisieren.

2. Sicherheitsteams in AppDev- und DevOps-Teams integrieren

Silos bremsen sowohl die Full-Stack-Sicherheit als auch die agile Entwicklung. Wird Sicherheit traditionell als separate Funktion behandelt, kann das viel Zeit kosten, weil Teams ihre Arbeit unterbrechen müssen, um sich mit jedem neu auftretenden Risiko zu befassen.

Gehen Sie Sicherheitsrisiken stattdessen frühzeitig an, indem Sie Sicherheitspraktiken und Kontrollen in den Softwareentwicklungslebenszyklus integrieren. Der DevSecOps-Ansatz verankert Sicherheitsziele so früh wie möglich im Softwareentwicklungslebenszyklus (SDLC) und schafft eine Kultur der gemeinsamen Verantwortung für Sicherheit. Wenn Sicherheitsteams bei der Konzeption und Entwicklung cloudbasierter Systeme eng mit Entwicklern und Cloud Engineers zusammenarbeiten, können sie Sicherheit in jeder Phase des SDLC verankern und so die Effizienz maximieren.

Diese gemeinsame Verantwortung wird durch entwicklerorientierte Tools unterstützt, die sich in die Plattformen integrieren, mit denen Entwickler bereits arbeiten und vertraut sind. Für eine effektive Zusammenarbeit sind außerdem Plattformen wichtig, die einen zentralen Überblick und eine unkomplizierte teamübergreifende Kommunikation ermöglichen.

3. App-Entwicklung modernisieren und Sicherheit im gesamten SDLC verankern

Der Umstieg auf AWS bietet eine hervorragende Gelegenheit, eine durchgängige Sicherheitsabdeckung über den gesamten SDLC hinweg einzuführen.

Wenn Sicherheitstests erst später im App-Entwicklungsprozess stattfinden, kann das zu Verzögerungen führen. Verfolgen Sie stattdessen einen Shift-Left-Ansatz, um Sicherheit so früh wie möglich in den SDLC zu integrieren. So bleiben Sie agil und können neue Risiken, die durch Cloud-Technologie entstehen, besser steuern.

Führen Sie für jeden Pull Request automatisierte Sicherheitsprüfungen durch, um Sicherheitsprobleme zu erkennen, bevor neue Codeänderungen in Produktionsumgebungen übernommen werden. So erhalten Sie während der Entwicklung und beim Testen der Anwendung einen umfassenden Überblick über deren Sicherheitsstatus.

4. Cloud-Architekturen von Anfang an sicher konzipieren

Angreifer nutzen häufig Schwachstellen in der Architektur aus, um Zugriff auf wertvolle Daten zu erhalten. Denken Sie wie ein Angreifer und ermitteln Sie potenzielle Schwachstellen, um die Auswirkungen von Sicherheitsbedrohungen zu minimieren. Achten Sie auf gängige Cloud-Fehlkonfigurationen und vermeiden Sie diese proaktiv.

Stärken Sie die Kompetenzen Ihres Sicherheitsteams in der AWS-Sicherheitsarchitektur. Nutzen Sie Ressourcen wie den Cloud Security Podcast sowie AWS-Schulungsprogramme und Zertifizierungen. Erwägen Sie, eine eigene Position für einen Cloud-Sicherheitsarchitekten einzurichten, der sichere Cloud-Architekturen aufbaut und verwaltet.

5. Entwickler und Cloud Engineers befähigen, sicher zu entwickeln

Wenn Cloud-Fehlkonfigurationen auftreten, können Entwickler sie am besten beheben, ohne die Funktionalität zu beeinträchtigen. Häufig sind sie die Einzigen, die ihren Anwendungscode und ihre Infrastructure-as-Code-Vorlagen (IaC), etwa AWS CloudFormation, AWS CDK oder Terraform, vor der Bereitstellung absichern können.

Entwickler zu befähigen bedeutet, ihnen Entscheidungsfreiheit zu geben und sie für die Sicherheit ihrer Anwendungen verantwortlich zu machen. Dieser Wandel ist oft sowohl kultureller als auch organisatorischer Natur und erfordert Unterstützung durch klare Kommunikation von Führungskräften, Schulungen, Transparenz und teamübergreifenden Einblick sowie die richtigen Tools. Sorgen Sie dafür, dass Entwickler alles zur Hand haben, um Schwachstellen in ihrem eigenen Code zu erkennen und zu beheben.

6. Infrastructure as Code von Anfang an einsetzen und absichern

Infrastructure as Code (IaC) bedeutet, dass Infrastruktur nun wie Code behandelt werden kann. Für ihre Absicherung ist nicht länger das IT-Team, sondern sind die Entwickler verantwortlich. Am besten gelingt das, indem sie bewährte Programmierpraktiken befolgen und die Infrastruktur zusammen mit dem Anwendungscode prüfen.

IaC ermöglicht es, AWS-Umgebungen effizienter und einheitlicher aufzubauen und in großem Maßstab zu verwalten. Außerdem können Sie die Cloud-Sicherheit vor der Bereitstellung prüfen. Die Sicherheitsprüfung von IaC führt zu einer medianen Reduzierung von Cloud-Fehlkonfigurationen um 70 % und zu einer medianen Steigerung der Produktivität im Engineering sowie der Bereitstellungsgeschwindigkeit um 70 %.

Wenn Sie gleich zu Beginn Ihres AWS-Umstiegs Prozesse und Verfahren für die sichere Nutzung von IaC festlegen, schaffen Sie Klarheit und ermöglichen eine schnelle und effiziente Migration zu AWS. Amazon Web Services bietet AWS CloudFormation als native IaC-Lösung an. Auch unabhängige Optionen wie Terraform sind weit verbreitet.

7. Cloud-Sicherheitsleitplanken in Deployment-Pipelines einsetzen

Eine Folge des Shift-Left-Ansatzes ist, dass Sie Ihre Umgebung kontinuierlich überwachen müssen, um Sicherheitsprobleme zu erkennen. Sicherheitsprüfungen müssen in CI/CD automatisiert werden, um Fehlkonfigurationen vor der Bereitstellung zu verhindern. Mit IaC lassen sich Sicherheitsprüfungen für die Cloud in die Infrastruktur integrieren, die für die Bereitstellung von Anwendungen in AWS aufgebaut wird.

Ein DevSecOps-Ansatz für Cloud-Sicherheit sorgt dafür, dass Engineers bei auftretenden Problemen automatisiertes Feedback und klare Anweisungen erhalten, um sie schnell und sicher zu beheben. IaC hilft Engineers außerdem dabei, ähnliche Fehlkonfigurationen nicht immer wieder bereitzustellen.

8. Cloud-Sicherheit auf einer Grundlage aus Policy as Code aufbauen

Manuelle Compliance-Prüfungen sind zeitaufwendig und lassen sich nur schwer skalieren. Policy as Code (PaC)-Tools automatisieren den Prozess, indem sie Richtlinien als Code abbilden und durchsetzen. Das ist nicht nur schneller und effizienter: Da menschliche Fehler ausgeschlossen werden, ist es auch zuverlässiger und einheitlicher.

Nutzen Sie PaC, um eine zentrale Richtlinienquelle zu schaffen, an der sich Entwickler, Sicherheits-, DevOps- und Compliance-Teams orientieren können. Durch die Automatisierung von Richtlinien können Sicherheitsteams ihre Maßnahmen ausweiten, ohne mehr Personal einstellen zu müssen.

9. Identity- und Access-Management-Dienste sicher nutzen

Identity- und Access-Management (IAM) dient scheinbar ausschließlich der Verwaltung von Benutzerberechtigungen. Es bietet jedoch auch den besten Überblick über das gesamte cloudbasierte Netzwerk. Zu großzügig konfigurierte IAM-Berechtigungen öffnen Angreifern die Tür zur Cloud-Steuerungsebene.

Sichere IAM-Konfigurationen sollten ein zentraler Bestandteil Ihrer Cloud-Sicherheitsarchitektur sein. Prüfen Sie IAM-Konfigurationen kontinuierlich auf Schwachstellen und unterstützen Sie Engineers dabei, IAM-Dienste nach dem Prinzip der geringsten Berechtigungen sicher einzusetzen. Ein eigener Cloud-Sicherheitsexperte kann sicherstellen, dass IAM korrekt konfiguriert und verwaltet wird.

Darüber hinaus benötigen alle Benutzer individuelle Schulungen zum Sicherheitsbewusstsein, in denen die Bedeutung starker Passwörter und der Multi-Faktor-Authentifizierung (MFA) vermittelt wird.

10. Festlegen, was wichtig ist – und kontinuierlich messen

Kennzahlen sind entscheidend, um sicherzustellen, dass Ihre AWS-Sicherheitsmaßnahmen funktionieren. Es ist wichtig, die Wirksamkeit Ihrer Cloud-Sicherheitsprogramme zu messen. Teams, die AWS-Sicherheit erfolgreich umsetzen, integrieren sie in ihre Abläufe und messen konsequent, was wirklich zählt.

Sie sollten den Status Ihrer Sicherheitslage kennen und ihn anhand konkreter Zahlen belegen können. Diese Zahlen können sich von denen herkömmlicher Bereitstellungsmodelle unterscheiden. In einem CI/CD-Bereitstellungsmodell ist ein gewisses Maß an Schwachstellen akzeptabel und zu erwarten. Nur mit einem durchgängigen Sicherheitsansatz können Sie kritische von nicht kritischen Schwachstellen unterscheiden und das Wichtigste priorisieren. Belegen Sie Fortschritte nicht nur mit einer Verringerung des Risikos, sondern auch mit einer höheren Effizienz von Entwicklern und DevOps-Teams bei der Behebung dieser Schwachstellen.

Je nach den Prioritäten Ihres Unternehmens können Sie beispielsweise die Zeit bis zur Behebung, den Anteil offener Schwachstellen mit hohem Schweregrad, die Anzahl akzeptierter Risiken und den Anteil von Schwachstellen mit niedrigem Schweregrad messen. Keine Kennzahl ist eine einmalige Sache – das Ziel ist die ständige und kontinuierliche Verbesserung.