Compartir a través de

Recomendaciones para proteger un ciclo de vida de desarrollo

  • Artículo

Se aplica a esta recomendación de lista de comprobación de seguridad de Azure Well-Architected Framework:

SE:02 Mantenga un ciclo de vida de desarrollo seguro mediante una cadena de suministro de software protegida, principalmente automatizada y auditable. Incorpore un diseño seguro mediante el modelado de amenazas para proteger contra implementaciones de derrota de seguridad.

Guía relacionada: Análisis de amenazas

En esta guía se describen las recomendaciones para proteger el código, el entorno de desarrollo y la cadena de suministro de software mediante la aplicación de procedimientos recomendados de seguridad a lo largo del ciclo de desarrollo. Para comprender esta guía, debe tener conocimiento de DevSecOps.

Diagrama del ciclo de seguridad.

DevSecOps integra la seguridad en los procesos de DevOps mediante:

  • Automatización de pruebas y validación de seguridad.

  • Implementación de herramientas como canalizaciones de seguridad para examinar el código y la infraestructura como código (IaC) para detectar vulnerabilidades.

En el núcleo de una carga de trabajo se encuentra el código de aplicación que implementa la lógica de negocios. El código y el proceso de desarrollo de código deben estar libres de defectos de seguridad para garantizar la confidencialidad, la integridad y la disponibilidad.

No basta con proteger solo el plano de infraestructura mediante el uso de controles de identidad y redes y otras medidas. Evite la implementación incorrecta del código o un bloque de código en peligro para reforzar la posición general de seguridad. El plano de uso, es decir, el código de la aplicación, también debe protegerse. El proceso de integración de la seguridad en el ciclo de vida de desarrollo es esencialmente un proceso de protección. Al igual que la protección de recursos, el ajuste del desarrollo de código también es independiente del contexto. El enfoque es mejorar la seguridad y no los requisitos funcionales de la aplicación. Para obtener información relacionada con la protección, consulte Recomendaciones para proteger los recursos.

Definiciones

Término Definición
Ciclo de vida del desarrollo de seguridad de Microsoft Conjunto de prácticas proporcionadas por Microsoft que admiten requisitos de cumplimiento y garantía de seguridad.
Ciclo de vida de desarrollo de software (SDLC) Un proceso multistage, sistemático para desarrollar sistemas de software.

Estrategias de diseño principales

Las medidas de seguridad deben integrarse en varios puntos en el ciclo de vida de desarrollo de software (SDLC) existente para garantizar:

  • Las opciones de diseño no conducen a brechas de seguridad.

  • El código y la configuración de la aplicación no crean vulnerabilidades debido a la implementación aprovechable y a prácticas de codificación incorrectas.

  • El software adquirido a través de la cadena de suministro no presenta amenazas de seguridad.

  • El código de aplicación, la compilación y los procesos de implementación no se manipulan.

  • Las vulnerabilidades reveladas a través de incidentes se mitigan.

  • Los recursos sin usar se retiran correctamente.

  • Los requisitos de cumplimiento no están en peligro ni se reducen.

  • El registro de auditoría se implementa en entornos de desarrollador.

En las secciones siguientes se proporcionan estrategias de seguridad para las fases habituales de SDLC.

Recopilación y documentación de los requisitos de seguridad

El objetivo de la fase de requisitos es recopilar y analizar los requisitos funcionales y no funcionales de una aplicación o una nueva característica de una aplicación. Esta fase es importante porque facilita la creación de barreras de protección adaptadas a los objetivos de la aplicación. La protección de los datos e integridad de la aplicación debe ser un requisito básico en todas las fases del ciclo de vida de desarrollo.

Por ejemplo, considere una aplicación que necesita admitir flujos de usuario críticos que permitan al usuario cargar y manipular datos. Las opciones de diseño de seguridad deben cubrir garantías para la interacción del usuario con la aplicación, como la autenticación y autorización de la identidad del usuario, lo que solo permite acciones permitidas en los datos y evita la inyección de CÓDIGO SQL. De forma similar, cubre los requisitos no funcionales, como disponibilidad, escalabilidad y mantenimiento. Las opciones de seguridad deben incluir límites de segmentación, entrada y salida del firewall y otros problemas de seguridad transversales.

Todas estas decisiones deben dar lugar a una buena definición de la posición de seguridad de la aplicación. Documentar los requisitos de seguridad en una especificación acordada y reflejarlo en el trabajo pendiente. Debe indicar explícitamente las inversiones de seguridad y los inconvenientes y riesgos que la empresa está dispuesta a asumir si las inversiones no están aprobadas por las partes interesadas empresariales. Por ejemplo, puede documentar la necesidad de usar un firewall de aplicaciones web (WAF) delante de la aplicación, como Azure Front Door o App de Azure lication Gateway. Si las partes interesadas de la empresa no están preparadas para aceptar el costo adicional de ejecutar un WAF, deben aceptar el riesgo de que los ataques de capa de aplicación puedan dirigirse a la aplicación.

La recopilación de requisitos de seguridad es una parte fundamental de esta fase. Sin este esfuerzo, las fases de diseño e implementación se basarán en opciones no estadísticas, lo que puede provocar brechas de seguridad. Es posible que tenga que cambiar la implementación más adelante para dar cabida a la seguridad, lo que puede ser costoso.

Traducción de los requisitos de seguridad a los requisitos técnicos

Durante la fase de diseño, los requisitos de seguridad se convierten en requisitos técnicos. En la especificación técnica, documente todas las decisiones de diseño para evitar la ambigüedad durante la implementación. Estas son algunas tareas típicas:

Definir la dimensión de seguridad de la arquitectura del sistema

Superponga la arquitectura con controles de seguridad. Por ejemplo, los controles que son prácticos en los límites de aislamiento según la estrategia de segmentación, los tipos de identidades necesarios para los componentes de la aplicación y el tipo de métodos de cifrado que se van a usar. Para ver algunas arquitecturas de ejemplo, vea las ilustraciones de las secciones Ejemplo de los artículos Administración de identidades y acceso y redes .

Evaluación de las prestaciones proporcionadas por la plataforma

Es importante comprender la división de responsabilidades entre usted y el proveedor de nube. Evite la superposición con controles de seguridad nativos de Azure, por ejemplo. Obtendrá una mejor cobertura de seguridad y podrá reasignar los recursos de desarrollo a las necesidades de la aplicación.

Por ejemplo, si el diseño llama a un firewall de aplicaciones web en la entrada, puede descargar esa responsabilidad a un equilibrador de carga como Application Gateway o Azure Front Door. Evite replicar características como código personalizado en la aplicación.

Elija solo marcos de confianza, bibliotecas y software de cadena de suministro. El diseño también debe especificar el control de versiones seguro. Las dependencias de la aplicación deben provengarse de partes de confianza. Los proveedores de terceros deben poder cumplir sus requisitos de seguridad y compartir su plan de divulgación responsable. Se debe notificar rápidamente cualquier incidente de seguridad para que pueda realizar las acciones necesarias. Además, ciertas bibliotecas podrían estar prohibidas por su organización. Por ejemplo, el software podría estar protegido frente a vulnerabilidades, pero aún no se permite debido a restricciones de licencia.

Para asegurarse de que esta guía va seguida de todos los colaboradores del software, mantenga una lista de marcos, bibliotecas y proveedores aprobados o no aprobados. Cuando sea posible, coloque límites de protección en las canalizaciones de desarrollo para admitir la lista. Tanto como sea posible, automatice el uso de herramientas para examinar las dependencias en busca de vulnerabilidades.

Determine los patrones de diseño de seguridad que debe implementar el código de la aplicación.

Los patrones pueden admitir problemas de seguridad como segmentación y aislamiento, autorización sólida, seguridad uniforme de aplicaciones y protocolos modernos. Algunos patrones operativos, como el patrón cuarentena, pueden ayudar a comprobar y bloquear el uso de software que podría introducir vulnerabilidades de seguridad.

Para más información, consulte Patrones de diseño en la nube que admiten la seguridad.

Almacenamiento de secretos de aplicación de forma segura

Implemente de forma segura el uso de secretos de aplicación y claves previamente compartidas que usa la aplicación. Las credenciales y los secretos de aplicación nunca deben almacenarse en el árbol de código fuente. Use recursos externos como Azure Key Vault para asegurarse de que, si el código fuente está disponible para un posible atacante, no se puede obtener más acceso. En general, busque formas de evitar secretos. El uso de identidades administradas, siempre que sea posible, es una manera de lograr ese objetivo. Para obtener más información, consulte Recomendaciones para administrar secretos de aplicación.

Definición de planes de prueba

Defina casos de prueba claros para los requisitos de seguridad. Evalúe si puede automatizar esas pruebas en las canalizaciones. Si el equipo tiene procesos para pruebas manuales, incluya requisitos de seguridad para esas pruebas.

Nota:

Realice el modelado de amenazas durante esta fase. El modelado de amenazas puede confirmar que las opciones de diseño están alineadas con los requisitos de seguridad y exponer brechas que debe mitigar. Si la carga de trabajo controla datos altamente confidenciales, invierta en expertos en seguridad que puedan ayudarle a realizar el modelado de amenazas.

El ejercicio de modelado de amenazas inicial debe producirse durante la fase de diseño cuando se definen la arquitectura del software y el diseño de alto nivel. Hacerlo durante esa fase le ayuda a identificar posibles problemas de seguridad antes de incorporarlos a la estructura del sistema. Sin embargo, este ejercicio no es una actividad única. Es un proceso continuo que debe continuar a lo largo de la evolución del software.

Para obtener más información, consulte Recomendaciones para el análisis de amenazas.

Procedimientos de desarrollo y pruebas seguros

Durante la fase de desarrollo y pruebas, el objetivo es evitar defectos de seguridad y alteraciones en las canalizaciones de código, compilación e implementación.

Estar bien entrenado en prácticas de código seguras

El equipo de desarrollo debe tener formación formal y especializada en prácticas de codificación seguras. Por ejemplo, es posible que los desarrolladores de api y web necesiten entrenamiento específico para protegerse frente a ataques de scripting entre sitios y los desarrolladores de back-end pueden beneficiarse del entrenamiento detallado para evitar ataques de nivel de base de datos, como ataques por inyección de código SQL.

Los desarrolladores deben tener que completar este entrenamiento para poder acceder al código fuente de producción.

También debe realizar revisiones internas del código del mismo nivel para promover el aprendizaje continuo.

Uso de herramientas de prueba de seguridad

Realice el modelado de amenazas para evaluar la seguridad de la arquitectura de la aplicación.

Use pruebas estáticas de seguridad de aplicaciones (SAST) para analizar el código de las vulnerabilidades. Integre esta metodología en el entorno del desarrollador para detectar vulnerabilidades en tiempo real.

Use pruebas dinámicas de seguridad de aplicaciones (DAST) durante el tiempo de ejecución. Esta cadena de herramientas puede comprobar si hay errores en dominios de seguridad y simular un conjunto de ataques para probar la resistencia de seguridad de la aplicación. Cuando sea posible, integre esta herramienta en las canalizaciones de compilación.

Siga los estándares del sector para las prácticas de codificación seguras. Para obtener más información, consulte la sección Recursos de la comunidad de este artículo.

Use linters y analizadores de código para evitar que las credenciales se inserte en el repositorio de código fuente. Por ejemplo, los analizadores de .NET Compiler Platform (Roslyn) inspeccionan el código de la aplicación.

Durante el proceso de compilación, use complementos de canalización para detectar credenciales en el código fuente. Examine todas las dependencias, como bibliotecas de terceros y componentes del marco, como parte del proceso de integración continua. Investigue los componentes vulnerables marcados por la herramienta. Combine esta tarea con otras tareas de exploración de código que inspeccionen la renovación de código, los resultados de las pruebas y la cobertura.

Use una combinación de pruebas. Para obtener información sobre las pruebas de seguridad en general, consulte Recomendaciones para las pruebas de seguridad.

Escribir código suficiente

Al reducir la superficie de código, también se reducen las posibilidades de defectos de seguridad. Reutilizar código y bibliotecas que ya están en uso y han pasado por validaciones de seguridad en lugar de duplicar código.

Aprovechar las características de Azure es otra manera de evitar código innecesario. Una manera es usar servicios administrados. Para obtener más información, vea Uso de las opciones de plataforma como servicio (PaaS).

Escriba código con un enfoque deny-all de forma predeterminada. Cree listas de permitidos solo para las entidades que necesitan acceso. Por ejemplo, si tiene código que necesita determinar si se debe permitir una operación con privilegios, debe escribirlo para que el resultado de denegación sea el caso predeterminado y el resultado de permitir solo se produzca cuando el código lo permita específicamente.

Protección de entornos de desarrollador

Las estaciones de trabajo de desarrollador deben protegerse con controles de red e identidad seguros para evitar la exposición. Asegúrese de que las actualizaciones de seguridad se aplican diligentemente.

Los agentes de compilación tienen privilegios elevados y tienen acceso al servidor de compilación y al código. Deben protegerse con el mismo rigor que los componentes de carga de trabajo. Esto significa que el acceso a los agentes de compilación debe autenticarse y autorizarse, deben estar segmentados por la red con controles de firewall, deben estar sujetos al examen de vulnerabilidades, etc. Los agentes de compilación hospedados por Microsoft deben preferirse sobre los agentes de compilación autohospedados. Los agentes hospedados por Microsoft proporcionan ventajas como máquinas virtuales limpias para cada ejecución de una canalización.

Los agentes de compilación personalizados agregan complejidad de administración y pueden convertirse en un vector de ataque. Las credenciales de la máquina de compilación deben almacenarse de forma segura y debe quitar periódicamente los artefactos de compilación temporales del sistema de archivos. Para lograr el aislamiento de red, solo se permite el tráfico saliente del agente de compilación, ya que usa el modelo de extracción de comunicación con Azure DevOps.

También se debe proteger el repositorio de código fuente. Conceda acceso a repositorios de código de forma necesaria y reduzca la exposición de vulnerabilidades tanto como sea posible para evitar ataques. Realice un proceso exhaustivo para revisar el código de las vulnerabilidades de seguridad. Use grupos de seguridad para ese propósito e implemente un proceso de aprobación basado en justificaciones empresariales.

Protección del código en canalizaciones de implementación

No basta con proteger el código. Si se ejecuta en canalizaciones que se pueden aprovechar, todos los esfuerzos de seguridad son inútiles e incompletos. Los entornos de compilación y versión también deben protegerse porque quiere impedir que los actores incorrectos ejecuten código malintencionado en la canalización.

Mantenimiento de un inventario actualizado de todos los componentes integrados en la aplicación

Cada nuevo componente integrado en una aplicación aumenta la superficie expuesta a ataques. Para garantizar la responsabilidad adecuada y las alertas cuando se agregan o actualizan nuevos componentes, debe tener un inventario de estos componentes. Almacénelo fuera del entorno de compilación. De forma periódica, compruebe que el manifiesto coincide con lo que hay en el proceso de compilación. Esto ayuda a garantizar que no se agreguen nuevos componentes que contengan puertas traseras u otro malware inesperadamente.

Tareas de canalización

  • Extraiga tareas en la canalización de orígenes de confianza, como Azure Marketplace. Ejecute tareas escritas por el proveedor de canalización. Se recomiendan tareas de GitHub o Acciones de GitHub. Si usa flujos de trabajo de GitHub, prefiera tareas creadas por Microsoft. Además, valide las tareas porque se ejecutan en el contexto de seguridad de la canalización.

  • Secretos de canalización. Los recursos de implementación que se ejecutan dentro de una canalización tienen acceso a todos los secretos de esa canalización. Tener la segmentación adecuada en su lugar para diferentes fases de la canalización para evitar la exposición innecesaria. Use almacenes de secretos integrados en la canalización. Recuerde que puede evitar el uso de secretos en algunas situaciones. Explore el uso de identidades de carga de trabajo (para la autenticación de canalización) e identidades administradas (para la autenticación entre servicios).

Mantener diferentes entornos independientes

Los datos usados en entornos diferentes deben mantenerse separados. Los datos de producción no deben usarse en entornos inferiores, ya que es posible que esos entornos no tengan los estrictos controles de seguridad que tiene la producción. Evite conectarse desde una aplicación que no sea de producción a una base de datos de producción y evite conectar componentes que no son de producción a redes de producción.

Exposición progresiva

Use la exposición progresiva para publicar características en un subconjunto de usuarios en función de los criterios elegidos. Si hay problemas, el impacto se minimiza a esos usuarios. Este enfoque es una estrategia común de mitigación de riesgos porque reduce el área expuesta. A medida que la característica madura y tiene más confianza en las garantías de seguridad, puede publicarla gradualmente en un conjunto más amplio de usuarios.

Protección del código en producción

La fase de producción presenta la última oportunidad responsable de corregir las brechas de seguridad. Mantenga un registro de la imagen dorada que se publica en producción.

Mantener los artefactos con versiones

Mantenga un catálogo de todos los recursos implementados y sus versiones. Esta información es útil durante la evaluación de prioridades de incidentes, cuando se mitigan los problemas y cuando se vuelve al estado de trabajo del sistema. Los recursos con versión también se pueden comparar con los avisos publicados de puntos vulnerables y exposiciones comunes (CVE). Debe usar la automatización para realizar estas comparaciones.

Correcciones de emergencia

El diseño de canalización automatizada debe tener la flexibilidad necesaria para admitir implementaciones periódicas y de emergencia. Esta flexibilidad es importante para admitir correcciones de seguridad rápidas y responsables.

Normalmente, una versión está asociada a varias puertas de aprobación. Considere la posibilidad de crear un proceso de emergencia para acelerar las correcciones de seguridad. El proceso puede implicar la comunicación entre los equipos. La canalización debe permitir implementaciones rápidas de puesta al día y reversión que aborden correcciones de seguridad, errores críticos y actualizaciones de código que se producen fuera del ciclo de vida de implementación normal.

Nota:

Priorice siempre las correcciones de seguridad sobre la comodidad. Una corrección de seguridad no debe introducir una regresión ni un error. Si desea acelerar la corrección a través de una canalización de emergencia, considere cuidadosamente qué pruebas automatizadas se pueden omitir. Evalúe el valor de cada prueba con respecto al tiempo de ejecución. Por ejemplo, las pruebas unitarias suelen completarse rápidamente. Las pruebas de integración o de un extremo a otro se pueden ejecutar durante mucho tiempo.

Mantenimiento de la seguridad del código a lo largo de su ciclo de vida

El objetivo de esta fase es asegurarse de que la posición de seguridad no se desintegra con el tiempo. SDLC es un proceso ágil en curso. Los conceptos descritos en las fases anteriores se aplican a esta fase porque los requisitos cambian con el tiempo.

Administración de revisiones. Mantenga actualizados los componentes de software, bibliotecas e infraestructura con las revisiones y actualizaciones de seguridad.

Mejora continua. Evalúe y mejore continuamente la seguridad del proceso de desarrollo de software teniendo en cuenta las revisiones de código, los comentarios, las lecciones aprendidas y las amenazas en evolución.

Retirar los recursos heredados obsoletos o que ya no están en uso. Al hacerlo, se reduce el área expuesta de la aplicación.

El mantenimiento también incluye correcciones de incidentes. Si los problemas se encuentran en producción, deben integrarse rápidamente en el proceso para que no se repitan.

Mejore continuamente las prácticas de codificación seguras para mantenerse al día con el panorama de amenazas.

Facilitación de Azure

El ciclo de vida de desarrollo de seguridad (SDL) de Microsoft recomienda prácticas seguras que se pueden aplicar al ciclo de vida de desarrollo. Para obtener más información, consulte Ciclo de vida de desarrollo de seguridad de Microsoft.

Defender para DevOps y las herramientas de SAST se incluyen como parte de GitHub Advanced Security o Azure DevOps. Estas herramientas pueden ayudarle a realizar un seguimiento de una puntuación de seguridad para su organización.

Siga las recomendaciones de seguridad de Azure que se describen en estos recursos:

Para buscar credenciales en el código fuente, considere la posibilidad de usar herramientas como GitHub Advanced Security y herramientas de análisis de código fuente de OWASP.

Valide la seguridad de cualquier código de código abierto en la aplicación. Estas herramientas y recursos gratuitos pueden ayudarle con su evaluación:

Lista de comprobación de seguridad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de seguridad