Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Conformité d'
La conformité est une responsabilité partagée entre AWS et les consommateurs de ses services. D'une manière générale, AWS est responsable de la « sécurité du cloud » alors que ses utilisateurs sont responsables de la « sécurité dans le cloud ». La ligne qui définit les responsabilités d'AWS et de ses utilisateurs varie en fonction du service. Par exemple, avec Fargate, AWS est responsable de la gestion de la sécurité physique de ses centres de données, du matériel, de l'infrastructure virtuelle ( EC2Amazon) et de l'environnement d'exécution des conteneurs (Docker). Les utilisateurs de Fargate sont responsables de la sécurisation de l'image du conteneur et de son application. Savoir qui est responsable de quoi est un élément important à prendre en compte lors de l'exécution de charges de travail qui doivent respecter les normes de conformité.
Le tableau suivant présente les programmes de conformité auxquels se conforment les différents services de conteneurs.
Programme de conformité | Amazon ECS Orchestrator | Amazon EKS Orchestrator | Fargate ECS | Amazon ECR |
---|---|---|---|---|
PCI DSS niveau 1 |
1 |
1 |
1 |
1 |
Éligible HIPAA |
1 |
1 |
1 |
1 |
SOC I |
1 |
1 |
1 |
1 |
SOC II |
1 |
1 |
1 |
1 |
SOC III |
1 |
1 |
1 |
1 |
ISO 27001:2013 |
1 |
1 |
1 |
1 |
ISO 9001: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 Modérée (Est/Ouest) |
1 |
1 |
0 |
1 |
FedRAMP Élevé () GovCloud |
1 |
1 |
0 |
1 |
DOD CC SRG |
1 |
Revue DISA () 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 |
L'état de conformité évolue au fil du temps. Pour le dernier statut, reportez-vous toujours à https://aws.amazon.com/compliance/services-in-scope/
Pour plus d'informations sur les modèles d'accréditation du cloud et les meilleures pratiques, consultez le livre blanc d'AWS, Modèles d'accréditation pour une adoption sécurisée
Déplacement vers la gauche
Le concept du déplacement vers la gauche implique de détecter les violations des politiques et les erreurs plus tôt dans le cycle de vie du développement logiciel. Du point de vue de la sécurité, cela peut être très bénéfique. Un développeur, par exemple, peut résoudre les problèmes liés à sa configuration avant que son application ne soit déployée sur le cluster. En détectant de telles erreurs plus tôt, vous éviterez le déploiement de configurations qui enfreignent vos politiques.
La politique en tant que code
La politique peut être considérée comme un ensemble de règles régissant les comportements, c'est-à-dire les comportements autorisés ou interdits. Par exemple, vous pouvez avoir une politique stipulant que tous les Dockerfiles doivent inclure une directive USER qui permet au conteneur de s'exécuter en tant qu'utilisateur non root. En tant que document, une telle politique peut être difficile à découvrir et à appliquer. Il peut également devenir obsolète à mesure que vos besoins changent. Avec les solutions Policy as Code (PaC), vous pouvez automatiser les contrôles de sécurité, de conformité et de confidentialité qui détectent, préviennent, réduisent et neutralisent les menaces connues et persistantes. En outre, ils vous fournissent un mécanisme pour codifier vos politiques et les gérer comme vous le feriez pour les autres artefacts de code. L'avantage de cette approche est que vous pouvez réutiliser vos GitOps stratégies DevOps et pour gérer et appliquer de manière cohérente des politiques dans les flottes de clusters Kubernetes. Veuillez consulter Pod Security
Utiliser policy-as-code des outils dans les pipelines pour détecter les violations avant le déploiement
-
OPA
est un moteur de politique open source qui fait partie de la CNCF. Il est utilisé pour prendre des décisions politiques et peut être géré de différentes manières, par exemple en tant que bibliothèque de langues ou en tant que service. Les politiques OPA sont rédigées dans un langage spécifique au domaine (DSL) appelé Rego. Bien qu'il soit souvent exécuté dans le cadre d'un contrôleur d'admission dynamique Kubernetes en tant que projet Gatekeeper , l'OPA peut également être intégré à votre pipeline CI/CD. Cela permet aux développeurs d'obtenir des commentaires sur leur configuration plus tôt dans le cycle de publication, ce qui peut les aider à résoudre les problèmes avant de passer à la production. Une collection de politiques OPA communes se trouve dans le GitHub référentiel de ce projet. -
Conftest
est basé sur OPA et fournit une expérience axée sur les développeurs pour tester la configuration de Kubernetes. -
Kyverno
est un moteur de politiques conçu pour Kubernetes. Avec Kyverno, les politiques sont gérées comme des ressources Kubernetes et aucun nouveau langage n'est nécessaire pour écrire des politiques. Cela permet d'utiliser des outils familiers tels que kubectl, git et kustomize pour gérer les politiques. Les politiques de Kyverno peuvent valider, modifier et générer des ressources Kubernetes, tout en garantissant la sécurité de la chaîne d'approvisionnement en images OCI. La CLI Kyverno peut être utilisée pour tester les politiques et valider les ressources dans le cadre d'un pipeline CI/CD. Toutes les politiques de la communauté Kyverno sont disponibles sur le site Web de Kyverno , et pour des exemples d'utilisation de la CLI Kyverno pour écrire des tests dans des pipelines, consultez le référentiel des politiques.
Outils et ressources
-
Atelier d'immersion sur la sécurité Amazon EKS - Conformité réglementaire
-
Examen de la sécurité de Kubernetes Une évaluation de la sécurité
de Kubernetes 1.13.4 (2019) réalisée par un tiers -
NeuVector par SUSE
, plateforme open source de sécurité des conteneurs Zero-Trust, fournit des rapports de conformité et des contrôles de conformité personnalisés