Consumir artefactos de software de terceros en la cadena de suministro solo cuando se comprueba y se marca como seguro para su uso, mediante procesos bien definidos. Este patrón es un sidecar operativo para el proceso de desarrollo. El consumidor de este patrón invoca este proceso para comprobar y bloquear el uso de software que podría introducir vulnerabilidades de seguridad.
Contexto y problema
Las soluciones en la nube suelen basarse en software de terceros obtenido de orígenes externos. Los archivos binarios de código abierto, las imágenes de contenedor públicas, las imágenes del sistema operativo del proveedor son algunos ejemplos de estos tipos de artefactos. Todos estos artefactos externos deben tratarse como que no sean de confianza.
En un flujo de trabajo típico, el artefacto se recupera de un almacén fuera del ámbito de la solución y, a continuación, se integra en la canalización de implementación. Hay algunos problemas potenciales en este enfoque. Es posible que el origen no sea de confianza, que el artefacto contenga vulnerabilidades o que no sea adecuado de alguna otra manera para el entorno de desarrollador.
Si estos problemas no se abordan, la integridad de los datos y las garantías de confidencialidad de la solución podrían estar en peligro o provocar inestabilidad debido a la incompatibilidad con otros componentes.
Algunos de esos problemas de seguridad se pueden evitar agregando comprobaciones a cada artefacto.
Solución
Tenga un proceso que valide el software para la seguridad antes de introducirlo en la carga de trabajo. Durante el proceso, cada artefacto se somete a un rigor operativo exhaustivo que lo comprueba en condiciones específicas. Solo después de que el artefacto cumpla esas condiciones, el proceso lo marca como de confianza.
El proceso de cuarentena es una medida de seguridad, que consta de una serie de puntos de control que se emplean antes de que se consuma un artefacto. Esos puntos de control de seguridad se aseguran de que un artefacto pasa de un estado que no es de confianza a un estado de confianza.
Es importante tener en cuenta que el proceso de cuarentena no cambia la composición del artefacto. El proceso es independiente del ciclo de desarrollo de software y lo invocan los consumidores, según sea necesario. Como consumidor del artefacto, bloquee el uso de artefactos hasta que hayan pasado la cuarentena.
Este es un flujo de trabajo de cuarentena típico:
El consumidor indica su intención, especifica el origen de entrada del artefacto y bloquea su uso.
El proceso de cuarentena valida el origen de la solicitud y obtiene los artefactos del almacén especificado.
Un proceso de comprobación personalizado se realiza como parte de la cuarentena, lo que incluye comprobar las restricciones de entrada y comprobar los atributos, el origen y el tipo con respecto a los estándares establecidos.
Algunas de estas comprobaciones de seguridad pueden ser el examen de vulnerabilidades, la detección de malware, etc., en cada artefacto enviado.
Las comprobaciones reales dependen del tipo de artefacto. Evaluar una imagen del sistema operativo es diferente de evaluar un paquete NuGet, por ejemplo.
Si el proceso de comprobación se realiza correctamente, el artefacto se publica en un almacén seguro con anotaciones claras. De lo contrario, sigue sin estar disponible para el consumidor.
El proceso de publicación puede incluir un informe acumulativo que muestre la prueba de comprobación y la importancia de cada comprobación. Incluya la expiración en el informe más allá del cual el informe no debe ser válido y el artefacto se considera no seguro.
El proceso marca el final de la cuarentena mediante la señalización de un evento con información de estado acompañada de un informe.
En función de la información, los consumidores pueden optar por realizar acciones para usar el artefacto de confianza. Esas acciones están fuera del ámbito del patrón cuarentena.
Problemas y consideraciones
Como equipo que consume artefactos de terceros, asegúrese de que se obtiene de un origen de confianza. Su elección debe estar alineada con los estándares aprobados por la organización para los artefactos que se adquieren de proveedores de terceros. Los proveedores deben poder cumplir los requisitos de seguridad de la carga de trabajo (y su organización). Por ejemplo, asegúrese de que el plan de divulgación responsable del proveedor cumple los requisitos de seguridad de su organización.
Cree una segmentación entre recursos que almacene artefactos de confianza y que no son de confianza. Use controles de identidad y red para restringir el acceso a los usuarios autorizados.
Tener una manera confiable de invocar el proceso de cuarentena. Asegúrese de que el artefacto no se consuma involuntariamente hasta que se marque como de confianza. La señalización debe automatizarse. Por ejemplo, las tareas relacionadas con la notificación a las partes responsables cuando se ingiere un artefacto en el entorno del desarrollador, confirmando cambios en un repositorio de GitHub, agregando una imagen a un registro privado, etc.
Una alternativa a la implementación de un patrón de cuarentena es subcontratarla. Hay profesionales de cuarentena que se especializan en la validación de activos públicos como su modelo de negocio. Evalúe los costos financieros y operativos de la implementación del patrón frente a la subcontratación de la responsabilidad. Si los requisitos de seguridad necesitan más control, se recomienda implementar su propio proceso.
Automatice el proceso de ingesta de artefactos y también el proceso de publicación del artefacto. Dado que las tareas de validación pueden tardar tiempo, el proceso de automatización debe poder continuar hasta que se completen todas las tareas.
El patrón sirve como primera validación momentánea de oportunidad. Pasar correctamente la cuarentena no garantiza que el artefacto permanezca de confianza indefinidamente. El artefacto debe seguir someterse a exámenes continuos, validación de canalización y otras comprobaciones de seguridad rutinarias que sirvan como últimas validaciones de oportunidad antes de promover la versión.
Los equipos centrales de una organización o un equipo de carga de trabajo individual pueden implementar el patrón. Si hay muchas instancias o variaciones del proceso de cuarentena, estas operaciones deben ser estandarizadas y centralizadas por la organización. En este caso, los equipos de carga de trabajo comparten el proceso y se benefician de la descarga de la administración de procesos.
Cuándo usar este patrón
Use este patrón cuando:
La carga de trabajo integra un artefacto desarrollado fuera del ámbito del equipo de carga de trabajo. Entre los ejemplos comunes se incluyen:
Un artefacto de Open Container Initiative (OCI) de registros públicos, como DockerHub, GitHub Container Registry, Registro de contenedor de Microsoft
Una biblioteca de software o un paquete de orígenes públicos como, por ejemplo, la Galería de NuGet, el índice de paquetes de Python, el repositorio de Apache Maven
Un paquete externo de infraestructura como código (IaC), como módulos de Terraform, cookbooks de Chef de la comunidad, módulos comprobados de Azure
Una imagen de sistema operativo o un instalador de software proporcionados por el proveedor
El equipo de cargas de trabajo considera el artefacto como un riesgo que merece la pena mitigar. El equipo entiende las consecuencias negativas de integrar artefactos comprometidos y el valor de cuarentena para garantizar un entorno de confianza.
El equipo tiene una comprensión clara y compartida de las reglas de validación que se deben aplicar a un tipo de artefacto. Sin consenso, es posible que el patrón no sea eficaz.
Por ejemplo, si se aplica un conjunto diferente de comprobaciones de validación cada vez que se ingiere una imagen del sistema operativo en cuarentena, el proceso de comprobación general de las imágenes del sistema operativo se vuelve incoherente.
Este patrón podría no ser útil cuando:
El equipo de cargas de trabajo o un equipo asociado de confianza crean el artefacto de software.
El riesgo de no comprobar el artefacto es menos costoso que el costo de crear y mantener el proceso de cuarentena.
Diseño de cargas de trabajo
Un arquitecto y el equipo de cargas de trabajo deben evaluar cómo se puede usar el patrón de cuarentena como parte de las prácticas de DevSecOps de la carga de trabajo. Los principios subyacentes se tratan en los pilares de Azure Well-Architected Framework.
| Pilar | Cómo este patrón admite objetivos de pilar |
|---|---|
| El patrón cuarentena atiende la primera responsabilidad de la validación de seguridad. La validación en un artefacto externo se realiza en un entorno segmentado antes de que lo consuma el proceso de desarrollo. - ciclo de vida de desarrollo protegido se:02 - de pruebas y validación SE:11 |
|
| El patrón de cuarentena admite prácticas de implementación seguras (SDP) asegurándose de que la carga de trabajo no consume artefactos en peligro, lo que podría provocar infracciones de seguridad durante las implementaciones de exposición progresiva. - procedimientos de desarrollo de software de OE:03 - de pruebas y validación de OE:11 |
Al igual que con cualquier decisión de diseño, considere cualquier inconveniente con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.
Ejemplo
En este ejemplo se aplica el flujo de trabajo de solución a un escenario en el que el equipo de cargas de trabajo quiere integrar artefactos de OCI desde registros públicos a una instancia de Azure Container Registry (ACR), que es propiedad del equipo de cargas de trabajo. El equipo trata esa instancia como un almacén de artefactos de confianza.
El entorno de carga de trabajo usa Azure Policy para Kubernetes para aplicar la gobernanza. Restringe las extracción de contenedor solo de su instancia de registro de confianza. Además, las alertas de Azure Monitor se configuran para detectar las importaciones en ese registro desde orígenes inesperados.
El equipo de carga de trabajo realiza una solicitud de una imagen externa a través de una aplicación personalizada hospedada en Azure Web Apps. La aplicación recopila la información necesaria solo de los usuarios autorizados.
Punto de control de seguridad: se comprueba la identidad del solicitante, el registro de contenedor de destino y el origen de imagen solicitado.
La solicitud se almacena en Azure Cosmos DB.
Punto de control de seguridad: se mantiene una pista de auditoría en la base de datos, realizando un seguimiento del linaje y las validaciones de la imagen. Este rastro también se usa para los informes históricos.
La solicitud se controla mediante un orquestador de flujo de trabajo, que es una función duradera de Azure. El orquestador usa un enfoque de recopilación de dispersión para ejecutar todas las validaciones.
punto de control de seguridad: el orquestador tiene una identidad administrada con acceso suficiente para realizar las tareas de validación.
El orquestador realiza una solicitud para importar la imagen en la cuarentena de Azure Container Registry (ACR) que se considera un almacén que no es de confianza.
El proceso de importación en el registro de cuarentena obtiene la imagen del repositorio externo que no es de confianza. Si la importación se realiza correctamente, el registro de cuarentena tiene una copia local de la imagen para ejecutar validaciones.
Punto de control de seguridad: el registro de cuarentena protege contra la manipulación y el consumo de cargas de trabajo durante el proceso de validación.
El orquestador ejecuta todas las tareas de validación en la copia local de la imagen. Las tareas incluyen comprobaciones como, detección de vulnerabilidades comunes y exposiciones (CVE), evaluación de la factura de software de material (SBOM), detección de malware, firma de imágenes y otros.
El orquestador decide el tipo de comprobaciones, el orden de ejecución y el tiempo de ejecución. En este ejemplo, usa Azure Container Instance como ejecutores de tareas y los resultados están en la base de datos de auditoría de Cosmos DB. Todas las tareas pueden tardar mucho tiempo.
Punto de comprobación de seguridad: este paso es el núcleo del proceso de cuarentena que realiza todas las comprobaciones de validación. El tipo de comprobaciones podría ser soluciones personalizadas, de código abierto o compradas por el proveedor.
El orquestador toma una decisión. Si la imagen pasa todas las validaciones, el evento se indica en la base de datos de auditoría, la imagen se inserta en el registro de confianza y la copia local se elimina del registro de cuarentena. De lo contrario, la imagen se elimina del registro de cuarentena para evitar su uso accidental.
punto de control de seguridad: el orquestador mantiene la segmentación entre ubicaciones de recursos de confianza y que no son de confianza.
Nota
En lugar de tomar la decisión del orquestador, el equipo de carga de trabajo puede asumir esa responsabilidad. En esta alternativa, el orquestador publica los resultados de validación a través de una API y mantiene la imagen en el registro de cuarentena durante un período de tiempo.
El equipo de carga de trabajo toma la decisión después de revisar los resultados. Si los resultados cumplen su tolerancia a riesgos, extraen la imagen del repositorio de cuarentena en su instancia de contenedor. Este modelo de extracción es más práctico cuando este patrón se usa para admitir varios equipos de carga de trabajo con diferentes tolerancias de riesgo de seguridad.
Todos los registros de contenedor están cubiertos por Microsoft Defender para contenedores, que examina continuamente los problemas recién encontrados. Estos problemas se muestran en Administración de vulnerabilidades de Microsoft Defender.
Pasos siguientes
Es posible que las instrucciones siguientes sean pertinentes al implementar este patrón:
Recomendaciones para proteger un ciclo de vida de desarrollo proporciona instrucciones sobre el uso de unidades de código de confianza a través de todas las fases del ciclo de vida de desarrollo.
Procedimientos recomendados para una cadena de suministro de software segura especialmente cuando tiene dependencias de NuGet en la aplicación.
proteger contra paquetes públicos malintencionados mediante Azure Artifacts.