Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Conformité d' - Amazon EKS

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.

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 du cloud

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 pour plus d'informations sur les options PaC et le futur de PSPs.

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

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.