Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Conformidad
El cumplimiento es una responsabilidad compartida entre AWS y los consumidores de sus servicios. En términos generales, AWS es responsable de la «seguridad de la nube», mientras que sus usuarios son responsables de la «seguridad en la nube». La línea que define de qué son responsables AWS y sus usuarios variará en función del servicio. Por ejemplo, con Fargate, AWS es responsable de administrar la seguridad física de sus centros de datos, el hardware, la infraestructura virtual (Amazon EC2) y el tiempo de ejecución de los contenedores (Docker). Los usuarios de Fargate son responsables de proteger la imagen del contenedor y su aplicación. Saber quién es responsable de qué es una consideración importante a la hora de ejecutar cargas de trabajo que deben cumplir con las normas de conformidad.
En la siguiente tabla se muestran los programas de conformidad a los que se ajustan los distintos servicios de contenedores.
| Programa de cumplimiento | Amazon ECS Orchestrator | Amazon EKS Orchestrator | Fargate ECS | Amazon ECR |
|---|---|---|---|---|
|
PCI DSS nivel 1 |
1 |
1 |
1 |
1 |
|
Cumplimiento de requisitos de 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 Moderate (East/West) |
1 |
1 |
0 |
1 |
|
FedRamp High () GovCloud |
1 |
1 |
0 |
1 |
|
¿CC SRG |
1 |
Reseña de 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 |
El estado de cumplimiento cambia con el tiempo. Para ver el estado más reciente, consulte siempre https://aws.amazon.com/compliance/services-in-scope/
Para obtener más información sobre los modelos de acreditación en la nube y las prácticas recomendadas, consulte el documento técnico de AWS, Modelos de acreditación para la adopción segura
Girando a la izquierda
El concepto de girar a la izquierda implica detectar las infracciones y los errores de las políticas en una fase más temprana del ciclo de vida del desarrollo del software. Desde el punto de vista de la seguridad, esto puede resultar muy beneficioso. Un desarrollador, por ejemplo, puede solucionar los problemas de configuración antes de implementar la aplicación en el clúster. Detectar errores como este antes ayudará a evitar que se desplieguen configuraciones que infrinjan sus políticas.
La política como código
La política puede considerarse como un conjunto de reglas que rigen los comportamientos, es decir, los comportamientos permitidos o prohibidos. Por ejemplo, puedes tener una política que indique que todos los Dockerfiles deben incluir una directiva USER que haga que el contenedor se ejecute como un usuario no root. Como documento, una política como esta puede ser difícil de descubrir y aplicar. También puede quedar desactualizada a medida que cambien sus requisitos. Con las soluciones Policy as Code (PaC), puede automatizar los controles de seguridad, cumplimiento y privacidad que detectan, previenen, reducen y contrarrestan las amenazas conocidas y persistentes. Además, le proporcionan un mecanismo para codificar sus políticas y gestionarlas del mismo modo que lo hace con otros artefactos de código. La ventaja de este enfoque es que puede reutilizar sus GitOps estrategias para gestionar DevOps y aplicar políticas de forma coherente en todas las flotas de clústeres de Kubernetes. Consulte Pod Security
Utilice policy-as-code herramientas en proceso para detectar infracciones antes del despliegue
-
OPA
es un motor de políticas de código abierto que forma parte de la CNCF. Se utiliza para tomar decisiones políticas y se puede gestionar de diferentes maneras, por ejemplo, como una biblioteca de idiomas o un servicio. Las políticas de la OPA están redactadas en un lenguaje específico de dominio (DSL) denominado Rego. Si bien suele ejecutarse como parte de un controlador de admisión dinámico de Kubernetes como el proyecto Gatekeeper , la OPA también se puede incorporar a una canalización de CI/CD. Esto permite a los desarrolladores recibir comentarios sobre su configuración al principio del ciclo de lanzamiento, lo que puede ayudarlos a resolver los problemas antes de que pasen a la fase de producción. En el GitHub repositorio de este proyecto se encuentra un conjunto de políticas de OPA comunes. -
Contest
se basa en OPA y proporciona una experiencia centrada en los desarrolladores para probar la configuración de Kubernetes. -
Kyverno
es un motor de políticas diseñado para Kubernetes. Con Kyverno, las políticas se gestionan como recursos de Kubernetes y no se necesita ningún idioma nuevo para redactarlas. Esto permite utilizar herramientas conocidas como kubectl, git y kustomize para gestionar las políticas. Las políticas de Kyverno pueden validar, mutar y generar recursos de Kubernetes, además de garantizar la seguridad de la cadena de suministro de imágenes de OCI. La CLI de Kyverno se puede utilizar para probar políticas y validar recursos como parte de una canalización de CI/CD. Todas las políticas de la comunidad de Kyverno se encuentran en el sitio web de Kyverno y, para ver ejemplos de cómo utilizar la CLI de Kyverno para escribir pruebas en canalizaciones, consulte el repositorio de políticas.
Herramientas y recursos
-
Taller de inmersión en seguridad de Amazon EKS: cumplimiento normativo
-
Revisión de seguridad de Kubernetes Una evaluación de seguridad
de Kubernetes 1.13.4 (2019) realizada por terceros -
NeuVector de SUSE
, una plataforma de seguridad de contenedores de código abierto y de confianza cero, que proporciona informes de conformidad y comprobaciones de conformidad personalizadas
