Zero Trust in AWS – Sicherheit neu gedacht

In unserer Welt, in der sich digitale Bedrohungen schneller entwickeln als je zuvor, ist das klassische Sicherheitsmodell mit starren Perimetern nicht mehr zeitgemäß. Gerade in der Public Cloud – zum Beispiel bei einem Anbieter wie Amazon Web Services, nachfolgend AWS genannt – ist Zero Trust der neue Sicherheitsstandard. Doch was bedeutet das konkret und wie lässt sich Zero Trust in AWS sinnvoll aus Kundensicht umsetzen?

Das Prinzip von Zero Trust lautet:
„Never trust, always verify“

Anstatt davon auszugehen, dass alles innerhalb eines Netzwerks automatisch sicher ist, wird jeder Zugriff geprüft, unabhängig davon, ob er intern oder extern erfolgt. Es gibt keine impliziten Vertrauenszonen mehr. Jeder Nutzer, jedes Gerät, jeder Dienst muss sich jedes Mal erneut authentifizieren und autorisieren – und bekommt nur genau den Zugriff, der wirklich notwendig ist.

Die Public Cloud hat die Art und Weise, wie wir IT-Infrastrukturen planen und betreiben, grundlegend verändert. Es gibt keinen klar definierten Netzwerk-Perimeter mehr, der auf dem eigenen Rechenzentrum basiert – Anwendungen sind über verschiedene AWS-Accounts, Regionen und Services verteilt, Nutzer arbeiten ortsunabhängig und oft auch von privaten Geräten aus. Gleichzeitig kommunizieren APIs und Cloud-Services miteinander, was die Angriffsfläche deutlich vergrößert. In dieser neuen Realität reicht es nicht mehr aus, einem geschützten Netzwerk zu vertrauen. Sicherheit muss heute identitätsbasiert, fein segmentiert und lückenlos überwachbar sein.

In AWS lässt sich Zero Trust nicht nur theoretisch diskutieren, sondern konkret umsetzen. AWS stellt dafür eine breite Palette an Sicherheitsfunktionen bereit – von granularer Zugriffskontrolle bis zur kontinuierlichen Überwachung. Zunächst werden die fünf Zero-Trust-Prinzipien im Allgemeinen beleuchtet und anschließend die konkrete Umsetzung der fünf Zero-Trust-Säulen in AWS erklärt.

Zero Trust basiert auf fünf zentralen Prinzipien:

1. Explizite Verifizierung: Jede Identität – ob Nutzer oder Maschine – muss überprüft und authentifiziert werden, bevor Zugriff gewährt wird.
2. Least Privilege Access: Nutzer und Systeme sollten stets nur die minimal nötigen Berechtigungen erhalten.
3. Segmentierung: Die Mikrosegmentierung ist die Unterteilung der Infrastruktur in getrennte Sicherheitszonen.
4. Transparenz und Kontrolle: Um Vertrauen durch Kontrolle zu ersetzen, müssen alle Aktivitäten kontinuierlich überwacht werden.
5. Automatisierung und Reaktion: Da Angriffe jederzeit auftreten können, müssen Schutzmaßnahmen automatisiert umgesetzt werden.

Die oben genannten fünf Prinzipien sind eingebettet in die fünf zentralen Säulen von Zero Trust.

1. Identitäts- und Zugriffsmanagement – Wer greift zu?

Im Zero-Trust-Modell ist Identität das neue Perimeter. Egal ob Mensch oder Maschine – jeder Zugriff muss eindeutig authentifiziert und autorisiert sein. AWS stellt dafür umfangreiche Werkzeuge bereit:

• Mit AWS Identity and Access Management (IAM) lassen sich Berechtigungen präzise definieren, rollenbasiert verwalten und über Policies kontrollieren.
• IAM Identity Center erlaubt die zentrale Verwaltung von Benutzeridentitäten inklusive Integration in bestehende Verzeichnisse wie das Azure AD.
• Multi-Faktor-Authentifizierung (MFA) sorgt für zusätzliche Absicherung besonders sensibler Konten oder Aktionen.
• Für größere Organisationen bietet Access Analyzer eine gute Möglichkeit, zu weit gefasste Berechtigungen sichtbar zu machen.

Das Ziel: Jeder darf nur das sehen und tun, was für seine Rolle erforderlich ist – nicht mehr.

2. Geräte- und Endpunkt-Sicherheit – Womit wird zugegriffen?

• Nicht nur die Identität sondern auch das Gerät, mit dem auf Ressourcen zugegriffen wird, spielt eine zentrale Rolle. AWS ermöglicht hier in Kombination mit Drittanbieter-Lösungen eine Kontext-basierte Zugriffskontrolle:
• Mit AWS Verified Access können Zugriffe auf Web-Anwendungen auf Basis von Geräte- und Benutzerstatus freigegeben werden – ohne VPN.
• In sicherheitskritischen Umgebungen kommen Amazon WorkSpaces oder AppStream 2.0 zum Einsatz, um Benutzerinteraktionen auf isolierte, verwaltete Umgebungen zu verlagern.
• AWS lässt sich in Mobile-Device-Management-Systeme (z. B. Intune, Jamf) integrieren, um nur konforme Geräte zuzulassen.

Damit wird sichergestellt, dass sowohl die richtige Identität als auch ein sicheres Gerät zum Einsatz kommt.

3. Netzwerk-Segmentierung und Mikrosegmentierung – Woher kommt der Zugriff?

Im klassischen Modell war das interne Netzwerk per se vertrauenswürdig – in Zero Trust ist es das nicht mehr. Innerhalb von AWS bedeutet das: jede Verbindung wird hinterfragt und nur erlaubt, wenn sie ausdrücklich autorisiert ist.

AWS bietet dafür:

• Virtual Private Clouds (VPCs) zur logischen Isolierung von Ressourcen,
• Security Groups und Network Access Control Lists (NACLs), um Verbindungen gezielt zuzulassen oder zu blockieren,
• AWS PrivateLink, mit dem Dienste über das interne Netzwerk aufgerufen werden können, ohne das öffentliche Internet zu nutzen,
• sowie AWS Network Firewall zur Inspektion und Filterung des Datenverkehrs.

Das Ziel hierbei ist eine fein segmentierte Cloud-Architektur, in der kein Dienst implizit auf einen anderen zugreifen kann – jede Kommunikation ist ganz bewusst gestaltet und kontrolliert.

4. Daten-Sicherheit und Verschlüsselung – Was wird geschützt?

Daten sind das wertvollste Gut – und im Zentrum jeder Zero-Trust-Strategie. AWS bietet umfassende Möglichkeiten, um Datenzugriffe abzusichern, zu überwachen und zu verschlüsseln.

• Jede Anwendung bekommt eine eigene IAM-Rolle, die exakt auf ihre Anforderungen zugeschnitten ist.
• Amazon S3 in Kombination mit Bucket Policies und Access Points ermöglicht feingranulare Zugriffskontrolle auf Objekte.
• Mit dem AWS Key Management Service (KMS) lassen sich Daten systematisch verschlüsseln – auch serviceübergreifend.
• Amazon Macie erkennt automatisch sensible Daten (z. B. personenbezogene Informationen) und hilft beim Schutz vor ungewollter Freigabe.
• Zugangsdaten und Geheimnisse werden mit AWS Secrets Manager oder SSM Parameter Store sicher gespeichert – aber niemals im Code.

So wird jeder Workload als eigenständige Sicherheitsdomäne betrachtet – isoliert, überprüfbar und nur mit den Rechten ausgestattet, die er wirklich braucht.

5. Überwachung, Analyse und Automatisierung – Was läuft in der Cloud?

Vertrauen entsteht nicht durch Annahmen – sondern durch kontinuierliche Überprüfung. Monitoring, Erkennung von Anomalien und automatisierte Reaktionen sind ein essenzieller Bestandteil jeder Zero-Trust-Architektur. In AWS stehen dafür folgende Services zur Verfügung:

• Sicherheitslücken im Code oder in der Konfiguration lassen sich mit Amazon Inspector oder AWS CodeGuru frühzeitig erkennen.
• AWS CloudTrail zeichnet unter anderem jede API-Aktion in AWS Accounts auf – revisionssicher und detailliert.
• Amazon GuardDuty analysiert Logdaten, erkennt Anomalien und warnt vor potenziellen Angriffen.
• Der AWS Security Hub bündelt Sicherheitsmeldungen aus verschiedenen Quellen und stellt den Gesamtstatus übersichtlich dar.
• Mit AWS Config und Config Rules lassen sich Compliance-Vorgaben durchsetzen – etwa „alle Buckets müssen verschlüsselt sein“.
• Über Amazon EventBridge & AWS Lambda können sicherheitsrelevante Ereignisse automatisch behoben werden – z. B. durch Abschalten unsicher konfigurierter Ressourcen.

Das Ziel: Datenzugriffe sind stets kontextbasiert, transparent und mit technischen Kontrollen abgesichert.

In der Praxis zeigt sich Zero Trust in verschiedenen, klar definierten Anwendungsfällen – von der Absicherung des Fernzugriffs über Mikrosegmentierung bis hin zum Schutz cloud-nativer Workloads. Dabei geht es nicht nur um neue Technologien, sondern auch um neue Denkweisen in Architektur, Betrieb und Governance. Im Folgenden zeigen wir drei typische Use Cases, in denen Zero Trust besonders effektiv wirkt – praxisnah, wiederverwendbar und sofort umsetzbar.

Use Case 1: Admin-Zugriff absichern

• Nur per SSO via IAM Identity Center
• MFA verpflichtend
• Logging via CloudTrail + Alarmierung bei ungewöhnlichem Login-Verhalten

Use Case 2: Microservices voneinander trennen

• Kommunikation nur über PrivateLink + IAM-basierte Berechtigungen
• Keine "flachen" VPCs mit offenen Ports

Use Case 3: Zugriff auf S3 nur von definierten Quellen

• Bucket Policy: Zugriff nur von bestimmten VPCs/IPs
• VPC Endpoint + restriktive Endpoint Policy
• Kein Zugriff von außen - auch nicht versehentlich

1. Wildcard-Berechtigungen vermeiden (*:*)
   Beispielsweise sollten Berechtigungen wie "Action": “*" oder "Resource": "*" grundsätzlich vermieden werden. Sie geben einem Nutzer oder einer Rolle Zugriff auf alle Aktionen für alle Ressourcen. Dies stellt ein gravierendes Sicherheitsrisiko dar. Stattdessen sollten Richtlinien immer so spezifisch wie möglich formuliert werden. Nur so bleibt nachvollziehbar, wer auf was zugreifen darf.
2. Nutze Tags und ABAC für dynamische Zugriffskontrolle
   Mit Attribute-Based Access Control (ABAC) lassen sich Berechtigungen auf Basis von Ressourcen-Tags dynamisch steuern. Das bedeutet: Zugriffsrechte werden nicht mehr starr an einzelne Benutzer oder Rollen gebunden, sondern folgen Regeln wie „Der Nutzer darf nur Ressourcen bearbeiten, die er selbst erstellt hat“. Das ist besonders effizient in Multi-Team- oder Self-Service-Umgebungen.
3. Arbeite nach dem Prinzip „deny by default“
   Erst wenn etwas explizit erlaubt ist, darf es geschehen. Alle anderen Zugriffe werden standardmäßig blockiert. Dieses „deny by default“-Prinzip ist in AWS technisch leicht umzusetzen – zum Beispiel, indem IAM-Policies nur sehr gezielte „Allow“-Bedingungen enthalten, während sonstige Zugriffe unterbunden werden.
4. Verwende den AWS Access Analyzer zur Berechtigungsprüfung
   Mit dem AWS Access Analyzer kannst du überprüfen, welche Ressourcen versehentlich öffentlich oder für andere Konten zugänglich gemacht wurden. Er hilft dir dabei, Fehlkonfigurationen in IAM-Policies, S3-Bucket-Freigaben oder KMS-Schlüsseln frühzeitig zu erkennen – bevor sie zur Sicherheitslücke werden.
5. Automatisiere regelmäßige IAM-Reviews
   Berechtigungen sollten nicht einmalig vergeben und dann vergessen werden. Es empfiehlt sich, alle 90 Tage eine automatisierte Überprüfung durchzuführen: Welche Rollen sind noch aktiv? Welche Rechte werden gar nicht (mehr) genutzt? Tools wie der IAM Access Analyzer, AWS Config oder Third-Party-Lösungen helfen dabei, diese Prozesse effizient umzusetzen.
6. Reduziere die Angriffsfläche durch Blockierung ungenutzter Services
   Jeder aktive Service, der nicht genutzt wird, kann eine potenzielle Schwachstelle darstellen. Deshalb gilt: Aktiviere nur, was du wirklich brauchst. Über AWS Organizations oder Service Control Policies (SCPs) lassen sich nicht benötigte Services für ganze Accounts oder Organisationseinheiten gezielt blockieren.

Mit AWS hast du alle nötigen Werkzeuge zur Hand, um Zero Trust zu implementieren – aber du musst sie bewusst kombinieren. Es geht nicht darum, einem Trend zu folgen, sondern Sicherheit ganz neu zu denken: feingranular, dynamisch, identitätsbasiert und kontinuierlich überprüfbar. Zero Trust ist kein Projekt mit Enddatum. Es ist eine neue, langfristige Denkweise für sicheres Cloud Computing.

Sprechen Sie mit unseren Cloud Security Experten – wir zeigen Ihnen, wie Sie das Prinzip Zero Trust pragmatisch und skalierbar umsetzen.