Llegamos a ustedes gracias a:



Noticias

El NIST presenta nueva guía para devsecops

Para ayudar a la transición a las aplicaciones nativas de la nube

[28/10/2021] El gobierno federal de los Estados Unidos, al igual que la industria, está avanzando hacia la adopción de la nube, Devsecops y arquitecturas basadas en microservicios para aplicaciones nativas de la nube. El Instituto Nacional de Estándares Tecnológicos (NIST) tiene la tarea de promover la innovación y proporcionar normas y orientación a la industria para facilitar las mejores prácticas.

En esa línea, el NIST publicó a finales de septiembre el documento "Implementación de devsecops para una aplicación basada en microservicios con malla de servicios (800-204C), que proporciona una guía completa para la implementación de devsecops y el uso de plataformas de referencia para alojar aplicaciones nativas de la nube en una arquitectura de microservicios utilizando una malla de servicios. El documento, actualmente en forma de borrador, fue creado en colaboración con el ex jefe de Software de la Fuerza Aérea de los Estados Unidos, Nicholas Challain, y con personas del líder de la malla de servicios Tetrate.

La guía utiliza los conceptos de primitivas, que pueden considerarse como bloques de construcción para la implementación exitosa de devsecops, en lo que respecta a devops. Se argumenta que las primitivas de devsecops son las más adecuadas para las aplicaciones basadas en microservicios que permiten un desarrollo ágil. También apoya la noción de que devsecops facilita los requisitos de agilidad empresarial que exigen las aplicaciones nativas de la nube.

A continuación, un análisis de lo que contiene cada sección de la guía del NIST.

Plataforma de referencia para la implementación de primitivas Devsecops          

La guía habla de una plataforma de referencia en el contexto de una plataforma de orquestación y gestión de contenedores. Esto se pone en marcha mediante la construcción en la parte superior de la infraestructura subyacente, ya sea física o virtual, como los entornos austeros clasificados o desconectados (físicos) o virtualizados, como los entornos de proveedores de servicios en la nube (CSP) como AWS y Azure.

La guía también aboga por el uso de plataformas de orquestación de contenedores y gestión de recursos, sobre todo Kubernetes, que es la plataforma de orquestación de contenedores de código abierto más popular. Kubernetes puede desplegar pods que alojan aplicaciones en contenedores en máquinas físicas o virtuales subyacentes. Al utilizar grupos de nodos que alojan pods, Kubernetes es capaz de distribuir las cargas de trabajo de los microservicios en la infraestructura subyacente para soportar el equilibrio de carga y el escalado.

Dicho esto, la plataforma subyacente de Kubernetes no está exenta de problemas de seguridad y rendimiento. Uno de ellos es la necesidad de poder manejar la división y el enrutamiento del tráfico entre los pods en varios formatos, como el round robin.

Aquí es donde entra en juego el software de malla de servicios como Istio. Facilita gran parte del enrutamiento del tráfico y la observabilidad que requieren las aplicaciones basadas en microservicios. La arquitectura de malla de servicios consta de dos componentes principales, un plano de datos y un plano de control. Las funciones que desempeñan incluyen una red segura, la aplicación de políticas y la observabilidad del tráfico y el rendimiento (plano de datos), así como la gestión de claves y certificaciones y la gestión de las conexiones entrantes y salientes (plano de control).

Devsecops - Preparación de la organización, primitivas clave e implementación

Esta sección expone cómo las organizaciones deben prepararse para implementar devsecops, la transición de devops a devsecops, y cuáles son los bloques de construcción (primitivas) de devsecops. Lógicamente, esta sección debería ser la primera del documento.

La guía hace hincapié en la necesidad de realizar un cambio en los departamentos de TI de la organización y en los flujos de trabajo para ayudar a facilitar el cambio a devsecops. Los equipos multifuncionales de desarrolladores, especialistas en seguridad y expertos en operaciones de TI son la clave para garantizar que las organizaciones logren el devsecops y rompan los silos que tradicionalmente existen.

El NIST se esfuerza por subrayar que hay una evolución de devops a devsecops y que tradicionalmente devops ha carecido de pruebas de seguridad y de integración de controles de seguridad, así como de garantía en tiempo real de las posturas de seguridad. Se trata de una afirmación interesante, teniendo en cuenta que muchos expertos defienden que devops y devsecops deberían ser lo mismo, y que devops debería haber incluido siempre la seguridad. ¿Importa lo que hay en el nombre o lo que más importa son los resultados y las prácticas?

Dicho esto, se argumenta que los bloques de construcción específicos que faltan en devops deben existir para devsecops. Entre ellos se encuentra la integración de las pruebas de seguridad en los canales de CI/CD, la garantía de los controles de seguridad tanto de lo que pasa por el canal como de la seguridad del propio canal, y la garantía de que la seguridad no queda relegada como una tarea separada, a menudo vista como algo que se "atornilla" al final del ciclo de vida del desarrollo.

Basándose en el debate sobre las canalizaciones, la guía subraya que las canalizaciones deben ser esencialmente un trabajo que fluye a través de las diversas etapas de construcción, pruebas, seguridad y entrega de código y valor a una organización. Dependiendo de si la organización está implementando la integración continua, la entrega continua o el despliegue continuo, puede haber puertas manuales adicionales entre las pruebas y el despliegue en entornos de producción, como se demuestra en las imágenes siguientes.

CI/CD se compone, en última instancia, de tres etapas principales, que son construir/probar, enviar/empaquetar y desplegar. Si bien los conductos pueden facilitar la CI/CD, también se componen de tareas y entidades que incluyen la configuración de un repositorio de código fuente, el proceso de construcción, la seguridad de ese proceso de construcción, el entorno de despliegue, el conducto de entrega y, por último, la prueba del código y la ejecución del flujo de trabajo del conducto.

Aunque los conductos CI/CD apoyan la automatización y el despliegue acelerado, el NIST subraya que los seres humanos siguen participando en diversas capacidades. Puede tratarse de equipos de desarrollo que incorporan nuevas funciones, equipos de seguridad que realizan auditorías y equipos que diseñan y crean pipelines para facilitar los flujos de trabajo.

La automatización es un componente clave de la implementación de devsecops y de la entrega acelerada. Dicho esto, determinar qué actividades automatizar podría ser problemático. La guía del NIST incluye centrarse en las tareas repetitivas de alta frecuencia, las tareas orientadas al cumplimiento y las actividades que tienen una secuencia temporal. Adoptar la automatización de este modo libera a los equipos para que se centren en la resolución analítica de problemas y en el ingenio, en lugar de en las tareas y actividades rutinarias.

Entre las consideraciones para integrar las herramientas en los pipelines se encuentran la facilidad de integración, las interfaces accesibles y la capacidad de admitir una amplia variedad de componentes de infraestructura de fondo. Esto es necesario debido a los entornos en los que podrían alojarse las aplicaciones en contenedores y a la necesidad de ser versátiles y dinámicas.

Implementación de primitivas Devsecops para la plataforma de referencia

La guía del NIST enfatiza que muchos pipelines de CI/CD pueden estar involucrados en una plataforma de referencia. Pueden ser conductos para el código de la aplicación, la infraestructura como código (IaC), la política como código o la observabilidad como código. Independientemente del tipo de código, todos estos pipelines requieren asegurar el propio pipeline, abordar los modelos de flujo de trabajo e integrar las pruebas de seguridad adecuadas. El documento expone los aspectos clave de las canalizaciones asociadas a cada tipo de código.

Aunque a menudo se promociona que el CI/CD mejora la seguridad del código que pasa por él, la propia canalización también debe estar asegurada para garantizar que no se inserte y distribuya ningún código malicioso (por ejemplo, SolarWinds). La seguridad del canal implica la autenticación, el registro, los informes de construcción para los desarrolladores y los equipos de seguridad, y la firma de artefactos por varias partes, como el uso de TUF e in-toto.

El NIST expone los modelos de flujo de trabajo en las canalizaciones de CI/CD, que son de tipo push o pull. Argumenta que los flujos de trabajo basados en push pueden ser inseguros debido a la exposición de las credenciales fuera del entorno de despliegue. En cambio, defiende el uso de un estilo GitOps facilitado por los flujos de trabajo basados en pull. Este enfoque utiliza un operador que se ejecuta en el entorno de despliegue y extrae nuevas imágenes en el entorno cuando el operador observa cambios en el repositorio de gestión de código fuente (SCM). GitOps se está convirtiendo cada vez más en un estándar de la industria, lo que permite a las organizaciones permitir que el SCM sea la fuente de la verdad y las funciones de lean-into. También puede ofrecer valores como el versionado, el control de la deriva y la eliminación de las interacciones manuales con los entornos en lugar de aprovechar un flujo de trabajo impulsado por Git.

Las pruebas de seguridad son fundamentales, independientemente del código de canalización con el que se trate. El NIST establece las pruebas de seguridad más comunes, entre las que se incluyen las pruebas de seguridad de aplicaciones estáticas (SAST), las pruebas de seguridad de aplicaciones dinámicas (DAST), las pruebas de seguridad de aplicaciones interactivas (IAST) y el análisis de la composición del software. Todos estos tipos de pruebas son fundamentales para reducir el riesgo e identificar las vulnerabilidades que preocupan. Estos análisis pueden buscar vulnerabilidades, problemas de imagen de los contenedores y problemas de cumplimiento. También es necesario escanear las plantillas de IaC en busca de problemas de seguridad y cumplimiento para detectarlos antes de que lleguen a un entorno de ejecución, lo que también se conoce como desplazamiento de la seguridad hacia la izquierda. Dicho esto, esto no niega la necesidad de mantener la visibilidad y el conocimiento de las vulnerabilidades en tiempo de ejecución que puedan ocurrir.

La guía del NIST habla de devsecops en el contexto de la autoridad continua para operar (cATO), que es la autorización para que un sistema esté en producción, pero es ligera en esta área. Se puede descubrir el código que cumple con las normas y los tableros de control pueden proporcionar visibilidad en tiempo de ejecución. Dicho esto, es probable que se encuentren orientaciones más sólidas sobre la cATO en la próxima Guía de la cATO del Departamento de Defensa de Estados Unidos (DoD), que será más completa y abarcará la autorización de plataformas, equipos y procesos. El DoD también ha publicado recientemente una serie de documentos sobre devsecops, como una estrategia empresarial, un libro de jugadas y un documento de fundamentos.

El NIST está solicitando comentarios sobre el borrador del documento SP 800-204C, que deben presentarse el 1 de noviembre.