Ich war gerade dabei eine Schulung zum Thema AWS Security vorzubereiten und bemerkte dabei schnell, dass dieses Thema sehr komplex und daher auch schwer zu fassen ist. Daher habe ich begonnen meine Gedanken in einer Mind-Map¹ zu sortieren. In wenigen Minuten² entstand folgendes Bild:

Was ist deine erste Reaktion auf dieses Bild? Ich war sehr überrascht:

Im Folgenden erkläre ich die einzelnen Themengebiete, die für Sicherheit in der AWS Cloud fundamental sind.

Hinweis: Dieser Artikel ist eine Übersetzung aus dem Englischen: AWS Security Primer.

Struktur deiner AWS-Konten

Ein einziger AWS Account ist ein ernsthaftes Risiko. So lautete auch mein 2015 verfasster Blog-Post zum Thema.

Seitdem hat AWS die sogenannten Organizations herausgebracht. Eine Organization beherbergt mehrere AWS-Konto. Dabei sollte man vor allem die Service Control Policies (SPCs) berücksichtigen, welche noch vor den IAM Policies ausgewertet werden. Das bedeutet, dass du ganz flexibel die Benutzung von bestimmten Services global für einen ganzen AWS Account einschränken kannst.

Die bewährten Sicherheitsmethoden zum Schutz des Root-Users gelten weiterhin:

1. Verwende nicht deinen Root-User
2. Aktiviere MFA
3. Verwende keinen Zugriffsschlüssel (Access Key)

AWS API

Ich möchte dieses Thema in zwei Blöcke aufteilen: Authentifizierung (wer du bist) und Autorisierung (was du tun darfst).

Authentifizierung

Was dir bereits bekannt sein müsste, sind die IAM User. Wenn du nicht den Root-User verwendest (was du nicht solltest), wirst du AWS höchstwahrscheinlich mit einem IAM User nutzen. Ein IAM User kann (optional) ein Login-Profil nutzen um sich in die Management Console einzuloggen. Wie du weißt, sollte dein Passwort nicht einfach zu erraten sei. So eignet sich dein Geburtstag sicher nicht als Passwort. Unsichere Passwörter kannst du durch eine Passwort Policy verhindern. Es hat sich außerdem als sinnvoll erwiesen, MFA für alle IAM User mit einem Login-Profil zu aktivieren. Wenn du die AWS CLI verwenden willst, wirst du auch einen Zugriffsschlüssel benötigen, den du auf deinen Laptop lädst. Das ist eine sehr heikle Information, weswegen es sinnvoll ist, den Zugriffschlüssel in regelmäßigen Abständen zu tauschen. Wenn du AWS CodeCommit verwendest, kannst du auch deinen öffentlichen SSH-Schlüssel für die Authentifizierung hochladen.

Nun haben wir über vieles gesprochen, aber noch nicht darüber, was der Benutzer tun darf. Dies wird im nächsten Abschnitt behandelt.

Doch zuerst wollen wir uns noch ein paar andere Punkte aus der Mind-Map anschauen.

• Eine IAM Group ist keine Identität (du kannst später nicht auf eine Gruppe verweisen), sondern sie gruppiert einfach nur IAM-Benutzer. Dadurch kannst du die Berechtigungen für die ganze Gruppe statt für einzelnen Benutzer verwalten, was sehr praktisch ist.
• Cognito ist ein Spezialfall für Mobile- und Web-Applikationen. Du kannst deinen eigenen Pool von Benutzern verwalten (nicht IAM-Benutzer) oder mit Facebook, Twitter, etc. verbinden. All diese Benutzer erhalten dann (abhängig von dem, was du autorisierst) Zugriff, zu Teilen (oder der Gesamtheit) deines AWS-Accounts.
• Ein EC2 Instance Profile dient zur Authentifizierung einer EC2 Instance. Dies ist praktisch, wenn deine EC2-Instanzen mit der AWS-API kommunizieren möchten. Es besteht keine Notwendigkeit für Zugriffsschlüssel auf deinen EC2 Instanzen.
• Federation kann dein Leben leichter machen, wenn du viele Benutzer in deinem Unternehmen hast, die AWS verwenden möchten. Du kannst einen externen Identity Provider wie deinen AD verwenden, um Benutzer zu authentifizieren.
• Mit einer IAM Rolle kannst du dich nicht anmelden. Eine IAM Rolle kannst du für kurze Zeit für eine bestimmte Aufgabe annehmen. Die coole Sache ist, dass nicht nur IAM Benutzer eine Rolle annehmen können sondern auch AWS-Dienste, um in deinem Namen zu agieren. Auch Rollen selbst können andere Rollen annehmen, was sehr nützlich ist, wenn du planst, dein Setup komplizierter zu gestalten. Hierbei ist es wichtig zu beachten, dass eine Rolle über eine Trust Policy kontrolliert, wer sie annehmen darf.
• Um die Dinge einfacher zu machen, hat AWS Service-Linked Roles eingeführt. Einige AWS-Dienste verwalten Teile deines AWS-Konto in deinem Auftrag. EMR erstellt beispielweise EC2-Instanzen, um Hadoop für dich zu starten. Bevor es Service-Linked-Rollen gab, musstest du eine IAM-Rolle mit der richtigen Trust Policy erstellen, um in deinem Konto zu arbeiten. Service-Linked-Rollen kommen hingegen vorkonfiguriert und werden von AWS verwaltet. Du musst sie daher nur einmal installieren.
• IoT Things sind ein weiterer Spezialfall. Dinge wie dein Thermostat authentifizieren sich mit einem Zertifikat. Ein Ding kann so (je nachdem was du autorisierst) Zugriff, zu Teilen (oder der Gesamtheit) deines AWS-Konto erhalten.

Dies ist eine Zusammenfassung, wer Zugriff auf dein AWS-Konto erhalten kann.

Autorisierung

Nachdem du dich, eine Maschine oder ähnliches erfolgreich authentifiziert hast, willst du jetzt sicherlich auch auf AWS Dienste zugreifen. Hier kommen die IAM Policies ins Spiel. Eine IAM Policy kannst du entweder direkt für einen Benutzer, eine Gruppe oder eine Rolle definieren (Inline Policy). Oder du legst eine eigenständige Managed Policy an. Desweiteren stellt AWS vordefinierte Policies für verschiedene Anwendungsfälle bereit. Das Problem mit den von AWS bereitgestellten Managend Policies ist, dass diese typischerweise weit mehr Berechtigungen vergeben, als unbedingt notwendig ist. Du solltest allerdings immer versuchen dem “Least-Privilige”-Prinzip zu folgen und nur die absolut notwendigen Berechtigungen vergeben. Das ist nicht immer ganz einfach. Ich habe daher die Complete AWS IAM Reference zusammengestellt, die dir bei dieser Aufgabe helfen wird.

Neben IAM Policies verwenden einige Dienste einen zusätzlichen Berechtigungsmechanismus. Die Dienste mit eigenem Berechtigungsmechanismus sind:

• SNS und SQS: Eine Topic Policy oder Queue Policy kann ein Topic oder eine Queue für Dinge wie IAM User, IAM Rollen, AWS-Konten oder einfach für jeden öffnen. Das kann praktisch sein, aber du solltest zweimal darüber nachdenken. Wahrscheinlich kannst du auch einfach eine IAM Rolle verwenden, um den Zugriff zu ermöglichen.
• Glacier: Glacier verwendet zwei Arten von Policies: eine, um den Zugang zu kontrollieren, und die andere, um die Änderung der Archive zu kontrollieren. Letzteres ist wichtig, wenn du sicherstellen musst, dass Daten aus rechtlichen Gründen nicht geändert werden können.
• IoT: Wie bereits erwähnt, kann IoT Dinge authentifizieren, und die Policy bestimmt, auf welche Dienste ein Ding in deinem AWS-Konto zugreifen darf.
• Lambda: Über eine Permission kann gesteuert werden, wer eine Lambda-Funktion aufrufen darf. Zum Beispiel musst du eine Berechtigung vergeben, wenn du eine Lambda-Funktion basierend auf einem Zeitplan automatisch aufrufen lassen willst.
• S3: Für S3 gibt es besonders viele verschiedene Wege um Zugriffsberechtigungen zu steuern.
  • Du kannst ACLs auf Bucket- und Objektebene verwenden, um Lese- und Schreibberechtigungen zu vergeben. Das kann ich allerdings nicht empfehlen. Zum einen gibt es keine einfache Möglichkeit die Berechtigungen für alle Objekte auf einmal zu ändern. Zum anderen, ist es nur selten nötig wirklich für jedes Objekt unterschiedliche Berechtigungen zu definieren.
  • Stattdessen kannst du auch eine Bucket Policy verwenden, um Lese- und Schreibberechtigungen für ein Bucket bzw. deine Objekte zu vergeben. Dies macht zum Beispiel dann Sinn, wenn dein Bucket und alle darin befindliche Objekte öffentlich zugänglich sein sollen.
  • Du kannst auch Pre-Signed URLs generieren, um temporäre Berechtigungen zum Lesen oder Hochladen von Objekten zu vergeben. Dies ist sinnvoll, wenn du möchtest, dass Benutzer direkt Dateien aus ihrem Browser hochladen können.
• KMS: Key Policies sind der primäre Weg, um den Zugriff auf Kunden-Master-Schlüssel (CMKs) in KMS zu kontrollieren. Darüber hinaus kannst du IAM Policies verwenden. Der zweite Weg zur Kontrolle des Zugangs sind Grants. Mit einem Grant kannst du einem anderen AWS-Principal (z. B. einem AWS-Konto) erlauben, ein CMK mit einigen Einschränkungen zu verwenden. Du könntest das auch mit einer Key Policy umsetzen, aber Grants sind flexibler zu kontrollieren.

Service API

Einige Dienste verwenden eine eigene API. Datenbanken wie zum Beispiel MySQL nutzen einen eigenen Authentifizierungs- und Autorisierungsmechanismus. Du authentifizierst dich normalerweise mit Benutzernamen und Passwort und der Datenbankbenutzer ist berechtigt, bestimmte Dinge zu tun (z.B. “SELECT” aber nicht “DROP TABLE”).

Zusätzlich gibt es noch die AWS API, mit der du eine Datenbank von außen steuern kannst. Die AWS API verwendet wiederum ihren eigenen Authentifizierungs-Mechanismus (siehe oben).

Wenn du deine Virtualle Maschine (Linux oder Windows) verwalten möchtest, verwendest du wahrscheinlich SSH oder RDP. Für Linux-Maschinen kann AWS einen öffentlichen SSH-Schlüssel bereitstellen. Du kannst dich dann über SSH mit dem privaten Schlüssel auf deinem Rechner anmelden. Für Windows-Rechner verschlüsselt AWS das Administrator-Passwort mit dem öffentlichen Schlüssel und du kannst den privaten Schlüssel verwenden, um das Passwort zu entschlüsseln. Mit dem Benutzernamen und Passwort kannst du dich dann über RDP anmelden.

Netzwerk

In vielen Fällen wird viel Aufwand in Netzwerksicherheit gesteckt. Das ist seltsam, da das Thema Netzwerk nur einen sehr kleinen Teil von Sicherheit in der AWS Cloud ausmacht.

Du solltest bei AWS mindestens ein privates Netzwerk (VPC) erstellen. Das VPC kannst du selbst in Subnetze aufteilen. Alle Subnetze innerhalb eines VPC sind miteinander verbunden. Um Netzwerkzugriffe einzuschränken empfiehlt sich die Verwendung von Security Gropups. Eine Security Group ist mit einer Netzwerkschnittstelle (ENI) verknüpft und regelt den eingehenden und ausgehenden Traffic. Standardmäßig erlauben Security Groups keinen eingehenden Datenverkehr, aber allen ausgehenden Datenverkehr. Neben der Identifizierung des Traffics durch IP-Adressbereiche, kannst du den Traffic auch über Security Group des Zieles bzw. der Quelle identifizieren. Security Groups sind stateful: wenn ein eingehendes Paket erlaubt ist, ist automatisch auch die Antwort erlaubt.

Es gibt auch ACLs, um eingehenden und ausgehenden Traffic für Subnetze zu steuern. Standardmäßig sind ACLs so konfiguriert, dass aller eingehende und ausgehende Datenverkehr erlaubt wird. ACLs sind stateless, also wirst du höchstwahrscheinlich alle High Ports öffnen müssen. Daher empfehle ich es nicht ACLs zu verwenden, es sei denn, du hast einen guten Grund dafür.

Letzendlich kannst du steuern, wer mit wem im Netzwerk reden kann, indem du Routen konfigurierst. Möglicherweise möchtest du dein Büro-Netzwerk mit deinem VPC verbinden. Dazu kannst du eine VPN-Verbindung verwenden. Das Routing bestimmt dann, welche Subnetze aus deinem Büro erreicht werden können.

Datenverschlüsselung

Fast alle Dienste, die Daten speichern (EBS, S3, SQS, …) unterstützen die Verschlüsselung auf dem Speichermedium. Was bedeutet, dass AWS die Daten auf der Festplatte verschlüsseln wird. Das ist praktisch, wenn du (oder dein Regulator) befürchten, dass ein anderer AWS-Kunde oder Dritte möglicherweise Zugang zu deinen Daten erhalten könnten. Wenn du beispielsweise ein EBS-Volume an AWS zurückgeben willst, weil du es nicht mehr benötigst, wird die zugrunde liegende Festplatte wiederverwendet. AWS vernichtet die Daten, aber es gibt eine sehr winzige Chance, dass jemand mit großen Ressourcen zumindest Teile der Daten rekonstruieren kann. Wenn du AWS nicht vertraust, solltest du die Daten besser verschlüsseln, bevor du sie an den Dienst schickst oder AWS erst gar nicht nutzen.

Spoiler: Ich bin kein Experte für Datenverschlüsselung!

Wenn Daten verschlüsselt oder entschlüsselt werden, wird ein Schlüssel - auch Geheimnis genannt - benötigt. Diese Schlüssel werden vom Key Management Service (KMS) verwaltet.

Du erstellst über KMS einen Hauptschlüssel (CMK). Vom Hauptschlüssel leitet KMS dann Schlüssel zum Verschlüsseln von Daten ab. Zum Beispiel, wenn EBS die Daten auf deiner Festplatte verschlüsseln oder entschlüsseln möchte. Der Schlüssel für die Daten wird zusammen mit den verschlüsselten Daten, ebenfalls verschlüsselt gespeichert. Wenn EBS die Daten wieder entschlüsseln möchte, wird der Schlüssel über KMS entschlüsselt. Mit dem entschlüsselten Schlüssel können dann die Daten entschlüsselt werden. Wichtig ist, dass der Hauptschlüssel (CMK) von KMS niemals herausgegeben wird. Wenn du den Hauptschlüssel löschst, sind alle damit verschlüsselten Daten nur noch Müll, da die Daten nicht mehr entschlüsselt werden können.

Wenn du nicht möchtest, dass AWS deinen Hauptschlüssel verwaltet, kannst du statt KMS eine Magic Box namens Hardware Security Module verwenden. CloudHSM bietet dir diese Boxen als Service. Der Trick ist, dass diese Hardware den Zugriff auf Schlüssel absichert und sich selbst zerstört, wenn jemand versucht die Hardware gewaltsam zu öffnen. CloudHSM führt auch den Verschlüsselungs- und Entschlüsselungsteil auf dedizierten Hardware aus.

Das war noch nicht alles. Daten, die von A nach B transportiert werden wollen ebenfalls verschlüsselt werden. Vor allem, wenn diese Daten durch das Internet reisen. Alle AWS-Dienste, die HTTP-Endpunkte bereitstellen (ELB, ALB, CloudFront, API Gateway), unterstützen auch die TLS bzw. SSL-Verschlüsselung mit Zertifikaten, die vom Certificate Manager verwaltet werden, welcher Zertifikate automatisch ohne Kosten bereitstellt.
Wenn du dein Büro mit deinem VPC verbinden möchtest, kannst du einen VPN-Tunnel verwenden, um die Daten zu verschlüsseln.
Die AWS API verschlüsselt alle Daten mit TSL/SSL.

Aber was passiert, wenn du mit deiner Datenbank von einer EC2-Instanz aus kommunizierst? Oder wenn du mit deinen Anwendungsservern sprichst. Hier solltest du zumindest wissen, welcher Verkehr (nicht) verschlüsselt ist und warum.

Governance

Dokumentation ist wichtig. Du kannst alle deine sicherheitsrelevanten Regeln in Confluence dokumentieren. Der erste Punkt in deiner Liste: MFA aktivieren. Ein Jahr später wirst du feststellen, dass die Hälfte deiner IAM Benutzer MFA noch nicht aktiviert hat. Vielleicht brauchst du eine bessere Vorgehensweise?

• AWS bietet einen Service, um ~~ alle (okay, das ist das, was das Marketing sagen würde) ~~ die meisten der API-Anrufe mit CloudTrail zu protokillieren. Mit Hilfe dieses Tools weißt du genau, wer was und wann getan hat. Du kannst auch Lambda verwenden, um dies in nahezu Echtzeit (5 Minuten Intervall) zu analysieren und z.B. eine Benachrichtigung zu senden, wenn ein Benutzer MFA deaktiviert.
• AWS Config erstellt Schnappschüsse aller deiner Konfiguration bei AWS, du kannst außerdem Regeln definieren, die automatisch überwacht werden.
• Trusted Advisor prüft, ob du den AWS Best Practices folgst. Stelle sicher, dass du die E-Mails vom Trusted Advisor erhältst und die Ergebnisse jede Woche überprüfst!
• VPC Flow Logs können Netzwerk-Pakete in deinem VPC aufzeichnen. So kannst du sie analysieren: Improve Security (Groups) using VPC Flow Logs & AWS Config

Zusammenfassung

Das war ein anspruchsvoller Überblick über AWS Security. Meiner Erfahrung nach verbringen Kunden die meiste Zeit damit, ihr Netzwerk zu sichern, weil sie wissen, wie man das macht. Ich empfehle, dass du deine Ressourcen ein wenig verschiebst, um sicherzustellen, dass du die AWS API Security richtig nutzt. Mit einer einzigen S3 Bucket Policy kannst du deine Daten zuversichtlich der ganzen Welt öffnen.

Ich habe ein paar Punkte vergessen. Einige von ihnen sind bekannt:

• Patching des Betriebssystems (AMI)
• Patching der Abhängigkeiten der Anwendung
• Absicherung der Anwendung (z.B. Eingabevalidierung)

Aber ich bin ziemlich sicher, dass ich auch andere Punkte vergessen habe. Kontaktiere mich wenn du Feedback hast!

Read on

• Mehr über AWS in unserem Buch Amazon Web Services in Action.
• Die 5 häufigsten Fehler auf AWS
• Beobachte deinen AWS Account in echtzeit um verdächtige Aktivitäten aufzuspüren

Michael Wittig