tostphoto - stock.adobe.com
Bewährte Sicherheitspraktiken für AWS-Container
Die Absicherung von in Containern untergebrachten Anwendungen ist von großer Bedeutung. Wir stellen drei Verfahren für AWS ECS sowie AWS EKS vor und geben weitere Tipps zum Schutz.
IT-Sicherheit ist heute eine der wichtigsten Komponenten in jeder Infrastruktur. In Amazon Web Series (AWS) untergebrachte Container sind da natürlich keine Ausnahme.
AWS-Container nutzen ein Modell, bei dem die Verantwortung gemeinsam getragen wird. Man nennt es auch das Shared Responsibility Model, das Prinzip der geteilten Verantwortung. Der Cloud-Provider und seine Kunden sind für verschiedene Aspekte des Stacks verantwortlich. AWS macht die in seiner Cloud-Infrastruktur angebotenen Container per se bereits recht sicher. Es ist aber die Aufgabe des für die Verwaltung der Container zuständigen Cloud-Administrators, die in ihnen untergebrachten Anwendungen und Workloads zu schützen.
AWS hat zwei hauptsächliche Angebote, wenn es um Container geht.
- Amazon Elastic Container Service (ECS): Dabei handelt es sich um einen vollständig gemanagten Dienst zur Orchestrierung der Container, mit dem sich die in ihnen untergebrachten Anwendungen bereitstellen und verwalten lassen.
- Amazon Elastic Kubernetes Service (EKS): Auch hier handelt es sich um einen vollständig gemanagten Dienst. Bei ihm können mit Kubernetes erstellte Cluster innerhalb der AWS-Infrastruktur aufgebaut, gesichert und gepflegt werden.
Beide sind sicher und nahezu austauschbar. ECS bietet aber eine enger kontrollierte und daher noch etwas sicherere Umgebung als EKS. Auch wenn die meisten angebotenen Sicherheitseinstellungen für beide Umgebungen gelten, empfiehlt Amazon deshalb allen Firmen, die noch unerfahren sind mit bei AWS gehosteten Containern, erst einmal mit ECS zu starten.
Für welchen Dienst auch immer Sie sich entscheiden, Sie sollten sich an die folgenden bewährten Sicherheitsverfahren halten. Sie gelten für
- das Account-Management,
- die Verfügbarkeit der Images sowie
- die Verwaltung der sogenannten Secrets.
Sicheres Account-Management
Eine sorgfältige Planung der gewünschten Account-Rollen und eine gewissenhafte Trennung ihrer Aufgaben gehören zur Basis jeder IT-Security-Strategie. AWS verwaltet Benutzerkonten über den hauseigenen IAM-Dienst (Identity and Access Management). Das bedeutet, dass die IAM-Funktionen zu jedem bei AWS erstellten Account gehören. Der Admin kann also Nutzer und Gruppen anlegen und verwalten sowie festlegen, wie sie auf bei AWS angelegte Ressourcen zugreifen dürfen. Um das Beste aus IAM herauszuholen, sollten Sie die folgenden Best Practices anwenden.
Rollen und Berechtigungen bewirken, dass die einzelnen Anwender nur dann auf bestimmte Daten zugreifen können, wenn sie dafür explizit autorisiert wurden. So sollten zum Beispiel gerade erst eingestellte Mitarbeiter in der Regel keinen Zugriff auf vertrauliche Finanzdaten erhalten, damit sie nicht etwa versehentlich Schaden an oder mit ihnen anrichten. Das lässt sich jedoch nur mit angemessenen Zugriffsberechtigungen erreichen.
Beim Erstellen Ihrer Richtlinien sollten Sie keine dauerhaft gültigen Berechtigungen erteilen. Das führt sonst über kurz oder lang zu einer unübersichtlichen Verwaltung der Konten.
Aktivieren Sie für alle Benutzerkonten eine Zwei-Faktor-Authentifizierung. Dank der Nutzung zweier unterschiedlicher Wege, über den sich die Anwender authentifizieren müssen, ist es erheblich weniger wahrscheinlich, dass Eindringlinge sich einen Zugang verschaffen und vertrauliche Daten stehlen können.
Verfügbarkeit von Images und ihre Sicherheit
ECS- und EKS-Nutzer müssen besonders darauf achten, was sie in ihre Container importieren. Davon hängt die gesamte Sicherheit ihrer Deployments ab.
Weder Administratoren noch Entwickler sollten den gerade verfügbaren Images in öffentlich zugänglichen Repositories vertrauen. Verwenden Sie nur bekannt vertrauenswürdige Quellen mit gründlich geprüftem und bekannt sicherem Code.
Das Herunterladen von Images direkt aus dem Internet birgt mehrere potenzielle Probleme. So können Sie nicht garantieren, ob eine Ressource oder eine Datei auch wirklich verfügbar ist, wenn Sie sie benötigen. Aber selbst, wenn sie zur Verfügung steht, könnte sich der enthaltene Code seit dem letzten Download verändert haben. Das führt dann zu unerwartetem Ereignissen und anderen möglichen Problemen.
Nutzer der Javascript-Plattform Node.js erlebten genau dies im Jahre 2016. Ein Entwickler hatte ein nur wenige Zeilen langes Softwarepaket mit dem Namen „left-pad“ entfernt, das als Node Package Manager eingesetzt werden konnte. Alle Anwendungen und Programme, die left-pad über das Internet eingebunden hatten, waren danach nicht mehr in der Lage, fehlerfrei zu laufen. Das Team von Node.js war daher gezwungen, den gelöschten Code aus einem Backup wiederherzustellen und selbst zur Verfügung zu stellen. Dieses Ereignis hat gezeigt, dass es riskant ist, davon auszugehen, dass eine eingebundene Datei jederzeit bereitsteht, wenn Sie sie benötigen.
Seien Sie daher besonders vorsichtig bei Ihren Basis-Images. Erstellen Sie sie und ihre produktiv genutzten Container besser selbst aus offiziellen, vom Hersteller angebotenen Quellen. Stellen Sie zudem sicher, dass die eingebundenen Applikationen tatsächlich vertrauenswürdig sind und keinen böswilligen Code enthalten.
Gerade für Container, die mit sensiblen oder geschäftskritischen Daten umgehen, sollten Sie nur vertrauenswürdige Quellen nutzen. AWS bietet mit der Amazon Elastic Container Registry (ECR) selbst ein sicheres Repository für seine Images an, das sowohl mit ECS als auch EKS genutzt werden kann.
Halten Sie Ihre Secrets geheim
Wenn es um das Management der benötigten Schlüssel geht, sollten Ihre Entwickler nur bewährte Best Practices einsetzen. Gehen Sie bei Passwörtern, bei der API-Autorisierung und bei der Speicherung der Secrets in Ihren Containern keine Risiken ein.
Prüfen Sie den Einsatz des AWS Systems Manager Parameter Store. Er kann Ihnen behilflich sein, Sicherheitsprobleme in Ihrer Umgebung zu vermeiden. Der Parameter Store ist ein verschlüsseltes Repository zur sicheren Verwaltung und Speicherung der Konfigurationen und Secrets.
Die IT-Mitarbeiter können Daten innerhalb des Parameter Stores zum Beispiel mit Tags klassifizieren und so etwa unterschiedliche Zugangsdaten für unterschiedliche Umgebungen vorgeben. So können die Administratoren etwa einen Satz mit Zugangsdaten für die Produktion und einen für die Entwicklung nutzen. Dann muss beim Start einer Instanz oder eines Service nur noch der richtige Tag angegeben werden, um eine spezielle Konfiguration zu verwenden. Diese betrifft dann beispielsweise die für die Zugriffe verwendeten Schlüssel sowie API-Keys.
Es ist allerdings nötig, die bereits vorhandenen Prozesse sowie Code zu überarbeiten, bevor Sie den Parameter Store einsetzen können. Aufgrund dieses Schrittes kann es ein wenig dauern, bis das System fehlerfrei funktioniert. Auf Dauer lohnt sich diese Mühe jedoch, da sich dann auch die für die Container benötigte Basis dynamischer nutzen lässt.
ECS und EKS für jeden Einsatzzweck
2021 hat AWS Erweiterungen für seinen Container-Dienst freigegeben, die ECS Anywhere beziehungsweise EKS Anywhere getauft wurden. Sie ermöglichen es AWS-Kunden, native ECS-Tasks in einer von AWS gemanagten oder auch in einer intern verwalteten Infrastruktur einzusetzen. Die Absicherung von ECS beziehungsweise EKS Anywhere ist aber aufwändiger und komplizierter als reine Standard-Deployments von AWS Containern. Die beiden Dienste können dafür aber auch in On-Premises-Umgebungen laufen und funktionieren dann ähnlich wie native AWS-Dienste. Aus Sicherheitssicht ändert sich dadurch allerdings das Responsibility-Modell.
Damit wird die Control Plane auf lokale Umgebungen ausgeweitet, kann aber trotzdem weiterhin von der AWS-Umgebung aus verwaltet werden. Die Kommunikation zu On-Premises-Servern erfolgt mit Hilfe eines installierbaren Clients, dem sogenannten Amazon ECS Agent. Die Hardware vor Ort bleibt aber weiterhin in der Verantwortung des lokalen Administrators. Er muss sich weiterhin etwa um das Einspielen von Patches und das Management der Server kümmern. Das ist anders als beim nativen ECS-Dienst auf den Computern von AWS. Beachten Sie jedoch, dass die in diesem Beitrag vorgestellten Best Practices auch für diese Erweiterungen gelten.
