Consuma artefactos de software de terceros en su cadena de suministro solo cuando estén verificados y marcados como seguros 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 o las imágenes del sistema operativo del proveedor son algunos ejemplos de estos tipos de artefactos. Todos estos artefactos externos deben tratarse como no 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. Puede que el origen no sea de confianza, que el artefacto contenga vulnerabilidades o que no sea adecuado de alguna otra forma para el entorno del desarrollador.
Si no se abordan estos problemas, las garantías de integridad y confidencialidad de los datos de la solución podrían verse comprometidas o provocar inestabilidad debido a la incompatibilidad con otros componentes.
Algunos de esos problemas de seguridad se pueden evitar añadiendo comprobaciones a cada artefacto.
Solución
Disponga de un proceso que valide la seguridad del software antes de introducirlo en su carga de trabajo. Durante el proceso, cada artefacto se somete a un exhaustivo rigor operativo que lo comprueba en función de unas condiciones específicas. Solo después de que el artefacto satisfaga esas condiciones, el proceso lo marca como de confianza.
El proceso de cuarentena es una medida de seguridad que consiste en una serie de puntos de control que se emplean antes de consumir un artefacto. Estos puntos de control de seguridad garantizan que un artefacto pase de un estado no de confianza a un estado de confianza.
Es importante señalar 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.
Como parte de la cuarentena se realiza un proceso de verificación personalizado, que incluye la comprobación de las restricciones de entrada y la comprobación de los atributos, del origen y del tipo con respecto a los estándares establecidos.
Algunas de estas comprobaciones de seguridad pueden ser el análisis 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, no estará disponible para el consumidor.
El proceso de publicación puede incluir un informe acumulado que muestre la prueba de verificación y la criticidad de cada comprobación. Incluya en el informe la caducidad más allá de la cual el informe no debe ser válido y el artefacto se considera inseguro.
El proceso marca el final de la cuarentena señalando un evento con información de estado acompañado de un informe.
Basándose en la información, los consumidores pueden optar por tomar medidas para utilizar el artefacto de confianza. Esas acciones están fuera del ámbito del patrón de la cuarentena.
Problemas y consideraciones
Como equipo que consume artefactos de terceros, asegúrese de que se obtienen de un origen de confianza. Su elección debe estar en consonancia con los estándares aprobados por la organización para los artefactos adquiridos a terceros. Los proveedores deben ser capaces de cumplir los requisitos de seguridad de su carga de trabajo (y de 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 los recursos que almacenan artefactos de confianza y no de confianza. Use controles de identidad y red para restringir el acceso a los usuarios autorizados.
Disponga de una forma fiable 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 un artefacto se ingiere en el entorno de desarrollo, la confirmación de cambios en un repositorio de GitHub, la adición de una imagen a un registro privado, etc.
Una alternativa a la implementación de un patrón de cuarentena es subcontratarla. Hay profesionales de la cuarentena que se especializan en la validación de activos públicos como modelo de negocio. Evalúe los costos financieros y operativos de implementar el patrón frente a subcontratar la responsabilidad. Si sus requisitos de seguridad requieren más control, se recomienda implementar un proceso propio.
Automatice el proceso de ingestión de artefactos y también el proceso de publicación del artefacto. Dado que las tareas de validación pueden llevar tiempo, el proceso de automatización debe poder continuar hasta que se completen todas las tareas.
El patrón sirve como validación momentánea de primera oportunidad. Pasar con éxito la cuarentena no garantiza que el artefacto siga siendo de confianza indefinidamente. El artefacto debe seguir sometiéndose a continuos procesos de análisis, validación de canalizaciones y otras comprobaciones de seguridad rutinarias que sirvan como validaciones de última oportunidad antes de promover la versión.
El patrón lo pueden implementar equipos centrales de una organización o un equipo individual de carga de trabajo. Si hay muchas instancias o variaciones del proceso de cuarentena, estas operaciones las debe estandarizar y centralizar la organización. En este caso, los equipos de carga de trabajo comparten el proceso y se benefician de la descarga de la gestión del proceso.
Cuándo usar este patrón
Use este patrón en los siguientes supuestos:
La carga de trabajo integra un artefacto desarrollado fuera del ámbito del equipo de carga de trabajo. Algunos ejemplos frecuentes son:
Un artefacto de la Open Container Initiative (OCI) de registros públicos como, DockerHub, Container Registry de GitHub o Container Registry de Microsoft
Una biblioteca o paquete de software de orígenes públicos como, por ejemplo, la Galería de NuGet, el índice de paquetes de Python o el repositorio de Apache Maven
Un paquete externo de infraestructura como código (IaC), como módulos Terraform, libros de cocina de la comunidad Chef o módulos verificados de Azure.
Imagen de sistema operativo proporcionada por el proveedor
El equipo de carga de trabajo considera el artefacto como un riesgo que merece la pena mitigar. El equipo comprende las consecuencias negativas de integrar artefactos comprometidos y el valor de la 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 una imagen del sistema operativo se ingiere en la cuarentena, el proceso general de verificación de las imágenes del sistema operativo se vuelve incoherente.
Este modelo podría no ser útil en las situaciones siguientes:
El artefacto de software lo crea el equipo de carga de trabajo o el equipo de un socio de confianza.
El riesgo de no verificar el artefacto es menor que el costo de crear y mantener el proceso de cuarentena.
Diseño de cargas de trabajo
Un arquitecto y el equipo de la carga de trabajo deben evaluar cómo se puede utilizar 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 del Marco de buena arquitectura de Azure.
| Fundamento | Cómo apoya este patrón los objetivos de los pilares |
|---|---|
| Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo. | El patrón de cuarentena atiende la primera responsabilidad de la validación de seguridad. La validación de un artefacto externo se realiza en un entorno segmentado antes de que se consuma en el proceso de desarrollo. - SE:02 Ciclo de vida de desarrollo protegido - SE:11 Prueba y validación |
| La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos. | El patrón de cuarentena es compatible con las prácticas de implementación segura (SDP), ya que garantiza que la carga de trabajo no consuma los artefactos comprometidos, lo que podría provocar brechas de seguridad durante las implementaciones de exposición progresiva. - OE:03 Prácticas de desarrollo de software - OE:11 Prueba y validación |
Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas 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 la solución a un escenario en el que el equipo de carga 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 carga de trabajo. El equipo trata esa instancia como un almacén de artefactos de confianza.
El entorno de carga de trabajo utiliza Azure Policy para Kubernetes para aplicar la gobernanza. Restringe la extracción de contenedores solo desde su instancia de registro de confianza. Además, las alertas de Azure Monitor están configuradas para detectar cualquier importación a ese registro desde orígenes inesperados.
La solicitud de una imagen externa la realiza el equipo de carga de trabajo 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 verifica la identidad del solicitante, el registro del contenedor de destino y el origen de la imagen solicitada.
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, que hace un seguimiento del linaje y las validaciones de la imagen. Esta pista de seguimiento también se utiliza para los informes históricos.
La solicitud se gestiona mediante un orquestador de flujo de trabajo, que es una Azure Function duradera. El orquestador utiliza un enfoque de dispersión y recopilación para ejecutar todas las validaciones.
Punto de control de seguridad: el orquestador tiene una identidad administrada con el acceso justo para realizar las tareas de validación.
El orquestador realiza una solicitud para importar la imagen al Azure Container Registry (ACR) en cuarentena 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 dispone de una copia local de la imagen para ejecutar las 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. Entre las tareas se incluyen comprobaciones como la detección de vulnerabilidades y exposiciones comunes (CVE), la evaluación de la lista de materiales de software (SBOM), la detección de malware o la firma de imágenes.
El orquestador decide el tipo de comprobaciones, el orden de ejecución y el tiempo de ejecución. En este ejemplo, utiliza Azure Container Instance como ejecutores de tareas y los resultados se encuentran en la base de datos de auditoría de Cosmos DB. Todas las tareas pueden llevar mucho tiempo.
Punto de control de seguridad: este paso es el núcleo del proceso de cuarentena que realiza todas las comprobaciones de validación. El tipo de controles puede ser personalizado, de código abierto o soluciones compradas a proveedores.
El orquestador toma una decisión. Si la imagen supera todas las validaciones, el evento se anota en la base de datos de auditoría, la imagen se transfiere al registro de confianza y la copia local se elimina del registro de cuarentena. En caso contrario, la imagen se elimina del registro de cuarentena para evitar su uso involuntario.
Punto de control de seguridad: el orquestador mantiene la segmentación entre ubicaciones de recursos de confianza y no de confianza.
Nota:
En lugar de que el orquestador tome la decisión, el equipo de carga de trabajo puede asumir esa responsabilidad. En esta alternativa, el orquestador publica los resultados de la 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 tras revisar los resultados. Si los resultados se ajustan a su tolerancia al riesgo, extraen la imagen del repositorio de cuarentena a su instancia de contenedor. Este modelo de extracción es más práctico cuando este patrón se utiliza para dar soporte a varios equipos de carga de trabajo con diferentes tolerancias al riesgo de seguridad.
Todos los registros de contenedores están cubiertos por Microsoft Defender para contenedores, que analiza continuamente los nuevos problemas detectados. Estos problemas se muestran en Administración de vulnerabilidades de Microsoft Defender.
Pasos siguientes
Las directrices siguientes también pueden ser pertinentes a la hora de implementar este patrón:
Recomendaciones para proteger un ciclo de vida de desarrollo proporciona orientación sobre el uso de unidades de código de confianza a través de todas las etapas 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.
La documentación de Azure Artifacts es una biblioteca de información relacionada con la administración de paquetes de software con Azure Artifacts.