Saltar al contenido principal

Buenas prácticas de seguridad de los contenedores para equipos de DevSecOps

La seguridad de los contenedores ofrece los mejores resultados cuando está integrada en el pipeline de entrega, se aplica durante la implementación y se supervisa en tiempo de ejecución. Ese es el significado práctico de DevSecOps en los entornos con contenedores: los controles de seguridad deben aplicarse lo suficientemente pronto como para impedir que artefactos inseguros avancen en el proceso, pero también mantenerse activos para detectar aquello que los controles realizados durante la fase de compilación no logran identificar.

¿Qué prácticas son más importantes?

Comenzar con imágenes base fiables y minimalistas
: utilice imágenes base bien mantenidas que incluyan únicamente los paquetes, las bibliotecas y las utilidades que la aplicación necesita. Esto reduce la superficie de ataque y facilita la aplicación de parches.

Analizar imágenes y dependencias antes de la implementación
: el análisis debe identificar vulnerabilidades conocidas, información confidencial expuesta y errores de configuración obvios antes de que los artefactos avancen más en la canalización. Esto no abarca toda la seguridad de los contenedores, pero sigue siendo uno de los controles más prácticos para reducir los riesgos evitables desde las primeras etapas.

Tratar los manifiestos de Kubernetes y la infraestructura como código (IaC) como artefactos críticos para la seguridad
: las definiciones de las cargas de trabajo (por ejemplo, de Kubernetes: pods y permisos), los gráficos Helm (configuraciones de Kubernetes empaquetadas), Terraform (aprovisionamiento de infraestructura, como recursos en la nube y redes) y otros artefactos de implementación (cualquier configuración utilizada para aprovisionar sistemas) pueden introducir problemas de privilegios, redes y exposición mucho antes del entorno de ejecución.

Aplicar privilegios mínimos en el clúster
: el RBAC de Kubernetes debe diseñarse cuidadosamente para los usuarios, las cuentas de servicio y las cargas de trabajo. El exceso de privilegios aumenta el riesgo de uso indebido y de escalada de privilegios.

Usar el control de admisiones y la aplicación de directivas
: las reglas de seguridad son más eficaces cuando se aplican automáticamente en el momento de la implementación. Los controles de admisión pueden detener recursos de riesgo antes de que sean admitidos en el clúster, mientras que los motores de políticas pueden ayudar a estandarizar los requisitos entre equipos y entornos.

Segmentar las redes para reducir el alcance potencial del impacto
: las políticas de red deben reflejar la forma en que las aplicaciones se comunican entre sí, al tiempo que limitan el movimiento este-oeste innecesario.

Supervisar el comportamiento del tiempo de ejecución
: el análisis durante la fase de compilación no detectará todos los problemas que pueden surgir en tiempo de ejecución. Los equipos aún necesitan visibilidad sobre el comportamiento de los procesos, las conexiones, el consumo de recursos, la desviación de políticas y la actividad sospechosa dentro de los contenedores en ejecución. Por este motivo, la supervisión en tiempo de ejecución debe ir más allá del estado de las imágenes y abarcar las aplicaciones en ejecución, la actividad del orquestador y las comunicaciones entre contenedores.

Registrar lo suficiente para investigar:
los entornos de contenedor y Kubernetes generan registros en varias capas, y esa telemetría es importante para la detección y la investigación posterior al incidente.

¿Cómo deberían los equipos de DevSecOps aplicar estos controles sin ralentizar la entrega?

El enfoque más eficaz es poner el control correcto en la etapa correcta.

Durante la fase de compilación, céntrese en la higiene de las imágenes, el análisis de dependencias, la detección de secretos y la procedencia del software.

En la fase de implementación, céntrese en la validación del manifiesto, la aplicación de la política y el control de admisión.

Durante el tiempo de ejecución, céntrese en la supervisión del comportamiento, la generación de alertas, la detección de desviaciones y la preparación para la investigación de incidentes.

Un enfoque por etapas es importante porque no todos los problemas deben abordarse en el mismo punto de control. Algunas comprobaciones deberían bloquear la implementación, mientras que otras deberían activar la revisión, la corrección o la supervisión del tiempo de ejecución. Los equipos con un mayor grado de madurez distinguen entre las vulneraciones que deben corregirse y los problemas de menor riesgo, para que la seguridad siga siendo aplicable sin convertirse en un cuello de botella. Un enfoque por etapas ofrece los mejores resultados cuando los equipos utilizan puntos de control de calidad para las imágenes y el código de infraestructura y, luego, los complementan con controles en tiempo de ejecución y controles de cumplimiento a lo largo de todo el ciclo de vida.

¿Cómo son las buenas prácticas en las operaciones diarias?

En los entornos mejor gestionados, la seguridad de los contenedores no es una actividad aislada al final del ciclo de lanzamiento, sino una parte integral de la forma en que se desarrolla y se entrega el software. Los desarrolladores saben que imágenes base están aprobadas, las canalizaciones de CI ejecutan controles de forma automática, los equipos de plataforma definen claramente las medidas de protección del clúster y los equipos de seguridad analizan las tendencias, las excepciones y las debilidades recurrentes, en lugar de depender únicamente de revisiones puntuales.

Ese ritmo operativo es importante porque DevSecOps funciona mejor cuando los controles son predecibles. Es mucho más probable que los equipos acepten los requisitos de seguridad cuando están integrados en las herramientas y el flujo de trabajo, en lugar de presentarse como objeciones en una etapa avanzada.

¿Qué deberían revisar los equipos periódicamente?

Los buenos programas de seguridad de los contenedores se mantienen en el tiempo; no basta con ponerlos en marcha. Los equipos deben revisar periódicamente lo siguiente:

  • Qué imágenes están aprobadas y todavía en uso
  • Si las vulnerabilidades antiguas se están trasladando a nuevas compilaciones
  • Si las excepciones a la política aumentan con el tiempo
  • Si las cuentas de servicio y las funciones siguen teniendo privilegios excesivos
  • Si las políticas de red siguen correspondiendo a la forma en que realmente se comunican las cargas de trabajo
  • Si las alertas en tiempo de ejecución generan investigaciones útiles o solo ruido
  • Si el registro es suficiente para la respuesta ante incidentes y la revisión posterior al incidente.

Estos puntos de revisión ayudan a prevenir la desviación de los controles; sin ellos, incluso políticas de seguridad bien diseñadas pueden quedar desactualizadas o aplicarse de manera inconsistente.

Dónde se equivocan las organizaciones

Un error habitual consiste en desplazar la seguridad demasiado hacia la izquierda y asumir que el tiempo de ejecución deja de ser importante. El enfoque shift left es valioso, pero los contenedores son dinámicos y la visibilidad en tiempo de ejecución sigue siendo fundamental para detectar comportamientos sospechosos, el uso indebido de privilegios y los fallos en los controles que solo se manifiestan después de la implementación.

Otro error es tratar la política de seguridad como una etapa de revisión externa, en lugar de algo integrado en el proceso de entrega. Si los desarrolladores solo se enteran de los incumplimientos al final del proceso, la corrección se vuelve más lenta y conflictiva.

Un tercer error es tratar de asegurar contenedores sin asegurar la plataforma alrededor de ellos. Los equipos de DevSecOps pueden mejorar la calidad de la imagen, pero el control de acceso a nivel de clúster, las políticas de admisión, el registro y la segmentación aún requieren una estrecha alineación con la plataforma y los equipos de seguridad.

¿Qué debe incluir una lista de comprobación práctica de DevSecOps?

Una lista de comprobación viable generalmente incluye lo siguiente:

  • Imágenes base aprobadas y procedencia de la imagen
  • Análisis de imágenes y dependencias en CI
  • Detección de secretos antes de la fusión o compilación
  • Manifiesto y revisión de IaC para la configuración de seguridad
  • RBAC de privilegios mínimos y diseño de cuentas de servicio
  • Control de admisión para las medidas de seguridad de la implementación
  • Políticas de red para el aislamiento de la carga de trabajo
  • Supervisión del tiempo de ejecución para la actividad del contenedor y del clúster
  • Registro centralizado y preparación para la investigación
  • Revisión regular de políticas y excepciones y reglas desactualizadas.

Conclusión clave

La mejor práctica de seguridad de los contenedores para los equipos de DevSecOps consiste en un modelo de entrega: proteger las entradas, aplicar medidas de protección durante la implementación, supervisar el comportamiento en tiempo de ejecución y mantener un ciclo de retroalimentación lo suficientemente ágil para que los equipos de ingeniería puedan corregir los problemas antes de que se conviertan en un riesgo para producción.



Añada seguridad de contenedores a su canalización de DevSecOps

La eficacia de DevSecOps depende de los controles de seguridad que funcionan dentro del proceso de desarrollo de software. Kaspersky Container Security ayuda a los equipos a comprobar las imágenes de los contenedores, detectar vulnerabilidades en los contenedores en ejecución, supervisar el consumo de recursos y las comunicaciones y automatizar las comprobaciones de seguridad y cumplimiento.

Fuentes y lecturas adicionales:

Buenas prácticas de seguridad de los contenedores para equipos de DevSecOps

La seguridad de los contenedores ofrece los mejores resultados cuando está integrada en la canalización de entrega, se aplica durante la implementación y se supervisa en tiempo de ejecución. Ese es el significado práctico de DevSecOps en los entornos con contenedores: los controles de seguridad deben aplicarse lo suficientemente pronto como para impedir que artefactos inseguros avancen en el proceso, pero también mantenerse activos para detectar aquello que los controles realizados durante la fase de compilación no logran identificar.
Kaspersky logo

Artículos relacionados