Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Compliance
Die Einhaltung der Vorschriften ist eine gemeinsame Verantwortung von AWS und den Nutzern seiner Services. Im Allgemeinen ist AWS für die „Sicherheit der Cloud“ verantwortlich, während seine Benutzer für die „Sicherheit in der Cloud“ verantwortlich sind. Die Zeile, die beschreibt, wofür AWS und seine Benutzer verantwortlich sind, variiert je nach Service. Bei Fargate ist AWS beispielsweise für die Verwaltung der physischen Sicherheit seiner Rechenzentren, der Hardware, der virtuellen Infrastruktur (Amazon EC2) und der Container-Laufzeit (Docker) verantwortlich. Benutzer von Fargate sind für die Sicherung des Container-Images und ihrer Anwendung verantwortlich. Bei der Ausführung von Workloads, die den Compliance-Standards entsprechen müssen, ist es wichtig zu wissen, wer wofür verantwortlich ist.
Die folgende Tabelle zeigt die Compliance-Programme, denen die verschiedenen Container-Services entsprechen.
| Compliance-Programm | Amazon ECS Orchestrator | Amazon EKS-Orchestrator | ECS Fargate | Amazon ECR |
|---|---|---|---|---|
|
PCI DSS Stufe 1 |
1 |
1 |
1 |
1 |
|
HIPAA-konform |
1 |
1 |
1 |
1 |
|
SOCK IST |
1 |
1 |
1 |
1 |
|
SOC II |
1 |
1 |
1 |
1 |
|
SOC III |
1 |
1 |
1 |
1 |
|
ISO 27001:2013 |
1 |
1 |
1 |
1 |
|
ISO9001:2015 |
1 |
1 |
1 |
1 |
|
ISO 27017:2015 |
1 |
1 |
1 |
1 |
|
ISO 27018:2019 |
1 |
1 |
1 |
1 |
|
IRAP |
1 |
1 |
1 |
1 |
|
FedRAMP Moderate (Osten/West) |
1 |
1 |
0 |
1 |
|
FedRAMP Hoch () GovCloud |
1 |
1 |
0 |
1 |
|
DOD CC SRG |
1 |
DISA-Rezension () IL5 |
0 |
1 |
|
HIPAA BAA |
1 |
1 |
1 |
1 |
|
MTCS |
1 |
1 |
0 |
1 |
|
C5 |
1 |
1 |
0 |
1 |
|
K-ISMS |
1 |
1 |
0 |
1 |
|
ENS High |
1 |
1 |
0 |
1 |
|
OSPAR |
1 |
1 |
0 |
1 |
|
HITRUST CSF |
1 |
1 |
1 |
1 |
Der Compliance-Status ändert sich im Laufe der Zeit. Den aktuellen Status finden Sie immer unter https://aws.amazon.com/compliance/services-in-scope/
Weitere Informationen zu Cloud-Akkreditierungsmodellen und bewährten Methoden finden Sie im AWS-Whitepaper Accreditation Models for Secure Cloud
Verlagerung nach links
Das Konzept der Linksverlagerung beinhaltet das Aufdecken von Richtlinienverstößen und Fehlern zu einem früheren Zeitpunkt im Lebenszyklus der Softwareentwicklung. Aus Sicht der Sicherheit kann dies sehr vorteilhaft sein. Ein Entwickler kann beispielsweise Probleme mit seiner Konfiguration beheben, bevor seine Anwendung im Cluster bereitgestellt wird. Wenn Sie solche Fehler früher erkennen, können Sie verhindern, dass Konfigurationen bereitgestellt werden, die gegen Ihre Richtlinien verstoßen.
Richtlinie als Code
Politik kann als eine Reihe von Regeln zur Regelung von Verhaltensweisen betrachtet werden, d. h. Verhaltensweisen, die erlaubt oder verboten sind. Möglicherweise haben Sie eine Richtlinie, die besagt, dass alle Dockerfiles eine USER-Direktive enthalten sollten, die bewirkt, dass der Container als Nicht-Root-Benutzer ausgeführt wird. Als Dokument kann es schwierig sein, eine solche Richtlinie zu entdecken und durchzusetzen. Sie kann auch veraltet sein, wenn sich Ihre Anforderungen ändern. Mit Policy-as-Code (PaC) -Lösungen können Sie Sicherheits-, Compliance- und Datenschutzkontrollen automatisieren, um bekannte und anhaltende Bedrohungen zu erkennen, zu verhindern, zu reduzieren und ihnen entgegenzuwirken. Darüber hinaus bieten sie Ihnen die Möglichkeit, Ihre Richtlinien zu kodifizieren und sie wie andere Code-Artefakte zu verwalten. Der Vorteil dieses Ansatzes besteht darin, dass Sie Ihre DevOps GitOps Strategien wiederverwenden können, um Richtlinien für Flotten von Kubernetes-Clustern zu verwalten und konsistent anzuwenden. Informationen zu den PaC-Optionen und der future von finden Sie unter Pod Security
Verwenden Sie policy-as-code Tools in Pipelines, um Verstöße vor der Bereitstellung zu erkennen
-
OPA
ist eine Open-Source-Policy-Engine, die Teil der CNCF ist. Es wird für politische Entscheidungen verwendet und kann auf verschiedene Arten betrieben werden, z. B. als Sprachbibliothek oder als Dienst. OPA-Richtlinien werden in einer domänenspezifischen Sprache (DSL) namens Rego geschrieben. OPA wird zwar häufig als Teil eines Kubernetes Dynamic Admission Controllers wie das Gatekeeper-Projekt ausgeführt, kann aber auch in Ihre CI/CD-Pipeline integriert werden. Auf diese Weise können Entwickler zu einem früheren Zeitpunkt im Veröffentlichungszyklus Feedback zu ihrer Konfiguration erhalten, das ihnen anschließend bei der Lösung von Problemen helfen kann, bevor sie mit der Produktion beginnen. Eine Sammlung gängiger OPA-Richtlinien finden Sie im GitHub Repository für dieses Projekt. -
Conftest
baut auf OPA auf und bietet eine auf Entwickler ausgerichtete Erfahrung zum Testen der Kubernetes-Konfiguration. -
Kyverno
ist eine Policy-Engine, die für Kubernetes entwickelt wurde. Mit Kyverno werden Richtlinien als Kubernetes-Ressourcen verwaltet, und es ist keine neue Sprache erforderlich, um Richtlinien zu schreiben. Dies ermöglicht die Verwendung vertrauter Tools wie kubectl, git und kustomize zur Verwaltung von Richtlinien. Kyverno-Richtlinien können Kubernetes-Ressourcen validieren, mutieren und generieren und gleichzeitig die Sicherheit der OCI-Image-Lieferkette gewährleisten. Die Kyverno CLI kann verwendet werden, um Richtlinien zu testen und Ressourcen als Teil einer CI/CD-Pipeline zu validieren. Alle Richtlinien der Kyverno-Community finden Sie auf der Kyverno-Website. Beispiele für die Verwendung der Kyverno-CLI zum Schreiben von Tests in Pipelines finden Sie im Polices-Repository.
Tools und Ressourcen
-
Amazon EKS Security Immersion Workshop — Einhaltung gesetzlicher Vorschriften
-
Kubernetes Security Review
Eine Sicherheitsbewertung von Kubernetes 1.13.4 (2019) durch Dritte -
NeuVector Die Open-Source-Zero-Trust-Container-Sicherheitsplattform von SUSE
bietet Compliance-Berichte und benutzerdefinierte Compliance-Prüfungen
