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 las 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 conocimientos 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.

  • Implementar herramientas como canalizaciones de seguridad para examinar el código y la infraestructura como código (IaC) en busca de vulnerabilidades.

En el núcleo de una carga de trabajo se encuentra el código de la 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 es suficiente 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 de seguridad general. El plano de uso, es decir, el código de la aplicación, también se debe proteger. 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, reforzar el desarrollo de código también es independiente del contexto. El objetivo 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 Un conjunto de procedimientos proporcionados por Microsoft que admite los 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 lo siguiente:

  • 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 los procedimientos de codificación incorrectos.

  • 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.

  • Se mitigan las vulnerabilidades reveladas a través de incidentes.

  • 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.

Fase de requisitos

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 y la 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 permite solo las acciones permitidas en los datos y evita la inyección de CÓDIGO SQL. Del mismo modo, cubre los requisitos no funcionales, como la disponibilidad, la escalabilidad y el 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. Documente los requisitos de seguridad en una especificación acordada y revíselos en el trabajo pendiente. Debe indicar explícitamente las inversiones en seguridad y los inconvenientes y riesgos que la empresa está dispuesta a asumir si las inversiones no están aprobadas por las partes interesadas de la empresa. Por ejemplo, puede documentar la necesidad de usar un firewall de aplicaciones web (WAF) delante de la aplicación, como Azure Front Door o Azure Application 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 sin 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.

Fase de diseño

Durante esta fase, 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, consulte 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 los 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 tener como origen las entidades de confianza. Los proveedores de terceros deben poder cumplir sus requisitos de seguridad y compartir su plan de divulgación responsable. Cualquier incidente de seguridad debe notificarse rápidamente para que pueda realizar las acciones necesarias. Además, es posible que algunas bibliotecas estén prohibidas por su organización. Por ejemplo, el software podría estar protegido frente a vulnerabilidades, pero aún no se permite debido a las 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 la segmentación y el aislamiento, la autorización sólida, la seguridad uniforme de las aplicaciones y los 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 precompartidas 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 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 llevar a cabo el modelado de amenazas.

El ejercicio de modelado de amenazas inicial debe producirse durante la fase de diseño cuando se define 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.

Fase de desarrollo y pruebas

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

Estar bien entrenado en procedimientos de código seguros

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.

Es necesario que los desarrolladores completen este entrenamiento para poder obtener acceso 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 en busca de 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, .NET Compiler Platform analizadores (Roslyn) inspeccionan el código de la aplicación.

Durante el proceso de compilación, use complementos de canalización para capturar las 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 pruebas de seguridad.

Escribir solo 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 seguros de red e identidad 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 ser preferidos 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 en busca de vulnerabilidades de seguridad. Use grupos de seguridad para ese propósito e implemente un proceso de aprobación basado en justificaciones empresariales.

Implementaciones de código seguras

No basta con proteger el código. Si se ejecuta en canalizaciones aprovechables, todos los esfuerzos de seguridad son inútiles e incompletos. Los entornos de compilación y versión también deben protegerse porque quiere evitar que actores malintencionados 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 de forma inesperada.

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 la canalización. Se recomiendan tareas o Acciones de GitHub de GitHub. Si usa flujos de trabajo de GitHub, prefiera las 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 una 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 distintos entornos separados

Los datos usados en diferentes entornos deben mantenerse separados. Los datos de producción no deben usarse en entornos inferiores porque es posible que esos entornos no tengan los estrictos controles de seguridad que tiene 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 sean 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.

Fase de 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.

Mantenimiento de 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 versiones también se pueden comparar con los avisos de vulnerabilidades y exposiciones comunes publicados (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 por 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.

Fase de mantenimiento

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 constante evolución.

Retire los recursos heredados que están 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 puede 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 abierto de la aplicación. Estas herramientas y recursos gratuitos pueden ayudarle con la evaluación:

Lista de comprobación de seguridad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de seguridad