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 verificación de seguridad bien diseñada: Power Platform

SE:02 Mantenga un ciclo de vida de desarrollo seguro mediante la utilización de una cadena de suministro de software reforzada, automatizada en su mayor parte y auditable. Incorpore un diseño seguro utilizando el modelado de amenazas para protegerse de las implementaciones que ponen en peligro la seguridad.

Esta guía describe las recomendaciones para proteger su código y entorno de desarrollo aplicando los procedimientos recomendados de seguridad durante todo el ciclo de desarrollo.

En el centro de una carga de trabajo se encuentran los componentes que implementan la lógica de negocios. Estos componentes pueden ser una combinación de elementos de poco código, como flujos y aplicaciones de lienzo, y elementos de código primero, como complementos. Todos los componentes que componen su carga de trabajo deben estar libres de defectos de seguridad para garantizar la confidencialidad, integridad y disponibilidad.

Proteger el plano de infraestructura con controles de identidad y redes es importante, pero no es suficiente. Prevenga la implementación deficiente de cargas de trabajo de Power Platform y actividades comprometidas en esas cargas de trabajo para reforzar su postura de seguridad general. El proceso de integrar seguridad en su ciclo de vida de desarrollo es esencialmente un proceso de refuerzo. Al igual que el refuerzo de recursos, el fortalecimiento del desarrollo de código también es independiente del contexto. La atención se centra en mejorar la seguridad, no en los requisitos funcionales de la aplicación.

Definiciones

Término Definición
Ciclo de vida de desarrollo de seguridad (SDL) Un conjunto de prácticas proporcionadas por Microsoft que respaldan la garantía de seguridad y los requisitos de cumplimiento.
Ciclo de vida de desarrollo del software (SDLC) Proceso sistemático de varias fases para desarrollar sistemas de software.

Estrategias clave de diseño

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

  • Las opciones de diseño no generan infracciones de seguridad.
  • Los componentes con poco código y de código primero, así como la configuración, no crean vulnerabilidades debido a una implementación vulnerable y a prácticas de codificación inadecuadas.
  • Los componentes y procesos de implementación con poco código y de código primero no se manipulan.
  • Se mitigan las vulnerabilidades reveladas a través de incidentes.
  • Los requisitos de cumplimiento no se comprometen ni reducen.
  • El registro de auditoría se implementa en todos los entornos.

Las siguientes secciones proporcionan estrategias de seguridad para las fases practicadas comúnmente de SDLC.

Fase de requisitos

El objetivo de la fase de requisitos es recopilar y analizar los requisitos funcionales y no funcionales de una carga de trabajo o una nueva característica de una carga de trabajo. Esta fase es importante porque facilita la creación de barreras que se adaptan a los objetivos de la carga de trabajo. Proteger los datos y la integridad de su carga de trabajo debería ser un requisito fundamental en cada fase del ciclo de vida de desarrollo.

Por ejemplo, considere una carga de trabajo en la que los usuarios ingresarán y modificarán datos dentro de una aplicación. Las opciones de diseño de seguridad deben cubrir garantías para la interacción del usuario con los datos, como autenticar y autorizar la identidad del usuario, y autorizar solo acciones permitidas sobre los datos. Los requisitos no funcionales cubren disponibilidad, facilidad de uso y facilidad de mantenimiento. Las opciones de seguridad deben incluir límites de segmentación, entrada y salida del firewall y otros aspectos de seguridad transversales.

Todas estas decisiones deberían llevar a una buena definición de la postura de seguridad de la carga de trabajo. Documente los requisitos de seguridad en una especificación acordada y refléjelos en el trabajo pendiente. El documento debe indicar explícitamente las inversiones en seguridad y los compromisos y riesgos que la empresa está dispuesta a asumir si las inversiones no son aprobadas por las partes interesadas de la empresa. Por ejemplo, podría documentar la necesidad de utilizar un firewall IP en entornos de Power Platform para proteger los datos de su organización restringiendo el acceso a Dataverse solo a ubicaciones IP permitidas. Si las partes interesadas de la empresa no están dispuestas a asumir el costo adicional de utilizar una solución como Entornos administrados, deben estar preparadas para aceptar el riesgo de que se acceda a los recursos de la organización desde lugares públicos, como una cafetería. Otro ejemplo: imagine que su aplicación debe conectarse a un origen de datos de terceros. Power Platform puede tener un conector listo para ello, pero es posible que no admita los requisitos de autenticación aprobados por sus equipos de seguridad. En este caso, las partes interesadas en la seguridad pueden estar dispuestas a aceptar el riesgo de utilizar un método de autenticación no aprobado. Alternativamente, puede explorar el uso de un conector personalizado, mientras sopesa los beneficios de un mayor tiempo de desarrollo y un posible retraso en el proyecto.

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 elecciones no declaradas, lo que puede generar infracciones de seguridad o requisitos cambiantes que aumentarán el tiempo de desarrollo. Es posible que deba cambiar la implementación más adelante para dar cabida a la seguridad, lo que puede resultar costoso.

Fase de diseño

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

  • Defina la dimensión de seguridad de la arquitectura. Superponga la arquitectura con controles de seguridad. Por ejemplo, controles que sean prácticos sobre los límites de aislamiento de la red, los tipos de identidades y métodos de autenticación necesarios para los componentes de la carga de trabajo y el tipo de métodos de cifrado que se van a utilizar.

  • Evalúe las prestaciones que brinda la plataforma. Es importante comprender la división de responsabilidad entre usted y Power Platform. Evite la superposición o duplicación con controles de seguridad nativos de Power Platform. Obtendrá mejor cobertura de seguridad y podrá reasignar recursos de desarrollo a las necesidades de la aplicación.

    Por ejemplo, en lugar de crear lógica personalizada que identifique y alerte reactivamente ante patrones de uso no aprobados en aplicaciones y flujos, utilice directivas de Prevención de pérdida de datos para categorizar cómo se pueden usar los conectores.

    Elija únicamente implementaciones de referencia, plantillas, componentes de código, scripts y bibliotecas confiables. Su diseño también debe especificar un control de versiones seguro. Las dependencias de las aplicaciones deben provenir de partes fiables. Los proveedores externos deben poder cumplir con sus requisitos de seguridad y Compartir su plan de divulgación responsable. Cualquier incidente de seguridad debe comunicarse de inmediato para que puedan tomarse las medidas necesarias. Además, su organización podría prohibir determinadas bibliotecas o implementaciones de referencia. Por ejemplo, incluso aunque sean seguras y estén libres de vulnerabilidades, es posible que aún no esté permitidas porque utilizan características que aún no están aprobadas por su organización, restricciones de licencia o el modelo de soporte de la implementación de referencia.

    Para garantizar que se siga esta guía, mantenga una lista de marcos, bibliotecas y proveedores aprobados y/o no aprobados, y asegúrese de que sus creadores estén familiarizados con esta lista. Cuando sea posible, coloque barreras en las canalizaciones de desarrollo para respaldar la lista. En la medida de lo posible, automatice el uso de herramientas para escanear dependencias en busca de vulnerabilidades.

  • Almacene los secretos de las aplicaciones de forma segura. Implemente de forma segura el uso de secretos de las aplicaciones y claves previamente compartidas que utilice su aplicación. Las credenciales y los secretos de las aplicaciones nunca deben almacenarse en el código fuente de la carga de trabajo (aplicación o flujo). Utilice recursos externos como Azure Key Vault para garantizar que, si su código fuente queda disponible ante un atacante potencial, no se pueda obtener más acceso.

  • Conéctese a sus datos de forma segura. Utilice las sólidas características de seguridad que Microsoft Dataverse ofrece para proteger sus datos, como seguridad basada en roles y de nivel de columnas. Para otras fuentes de datos, utilice conectores que tengan métodos de autenticación seguros. Evite consultas que almacenen nombre de usuario y contraseña en texto sin formato. Evite HTTP para crear conectores personalizados.

  • Defina cómo interactuarán los usuarios finales con la carga de trabajo y los datos. Considere si los usuarios tendrán acceso directo a los datos, qué nivel de acceso requieren y desde dónde accederán a los datos. Piense en cómo se compartirán las aplicaciones con los usuarios finales. Asegúrese de que solo aquellos que necesiten acceso a la aplicación y a los datos tengan acceso. Evite modelos de seguridad complejos que fomenten soluciones alternativas para evitar bloqueadores de seguridad.

  • Evite la codificación rígida. Evite la codificación rígida de URL y claves. Por ejemplo, evite la codificación rígida de la URL o la clave del servicio backend en una acción HTTP de Power Automate. En su lugar, utilice un conector personalizado o una variable de entorno para la URL y Azure Key Vault para la clave de API.

  • Defina planes de prueba. Defina casos de prueba claros para requisitos de seguridad. Evalúe si puede automatizar esas pruebas en sus canalizaciones. Si su equipo tiene procesos para pruebas manuales, incluya requisitos de seguridad para esas pruebas.

Nota

Realice 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 infracciones que se deben mitigar. Si su carga de trabajo gestiona datos altamente confidenciales, invierta en expertos en seguridad que puedan ayudarlo a realizar modelado de amenazas.

El ejercicio inicial de modelado de amenazas debe realizarse 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 que se incorporen 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 más información, consulte Recomendaciones sobre análisis de amenazas.

Fase de desarrollo y pruebas

En esta fase, el objetivo es prevenir defectos de seguridad y manipulación de código, compilación y canalizaciones de implementación.

Adquiera una formación adecuada en prácticas de código seguro

El equipo de desarrollo debería tener formación en prácticas de codificación segura. Por ejemplo, los desarrolladores deben estar familiarizados con los conceptos de seguridad de Microsoft Dataverse para implementar un modelo de seguridad con privilegios mínimos, directivas de seguridad de contenido para aplicaciones basadas en modelos para restringir la incorporación a dominios fiables y métodos de autenticación de conector/puerta de enlace local.

Se debe exigir a los desarrolladores que completen esta formación antes de comenzar a trabajar en cargas de trabajo de Power Platform.

Realice revisiones internas entre pares del código para promover un aprendizaje continuo.

Utilice herramientas de análisis de código

Debe usarse Comprobador de soluciones para recursos de Power Platform, y podría verificarse el código fuente de cualquier código tradicional para detectar posibles errores de seguridad, incluida la presencia de credenciales en el código. Identifique posibles casos de exposición de credenciales y secretos en el código fuente y los archivos de configuración. Este es un buen momento para revisar cómo se gestionarán las credenciales de conexión en producción.

Realizar pruebas de vulnerabilidad ante datos aleatorios o inesperados

Utilice datos inesperados y con formato incorrecto para buscar vulnerabilidades y validar la gestión de errores, algo particularmente importante con soluciones que incluyan Power Pages.

Escriba justo el código necesario

Cuando reduce la superficie del código, también reduce las posibilidades de que se produzcan defectos de seguridad. Reutilice código y bibliotecas que ya están en uso y han pasado por validaciones de seguridad en lugar de duplicar el código. Detección de software de código abierto y comprobación de versión, vulnerabilidad y obligaciones legales. Hay una cantidad creciente de recursos de Power Platform de código abierto, algo que no debe pasarse por alto. Cuando sea posible, este asunto debe analizarse en la fase de diseño para evitar problemas de último momento.

Proteger los entornos de desarrollo

Las estaciones de trabajo de los desarrolladores deben protegerse con fuertes controles de red e identidad para evitar la exposición. Asegúrese de que las actualizaciones de seguridad se apliquen con diligencia.

El repositorio del código fuente también debe protegerse. Otorgue acceso a los repositorios de código según sea necesario y reduzca la exposición de vulnerabilidades tanto como sea posible para evitar ataques. Disponer de un proceso exhaustivo para revisar el código en busca de vulnerabilidades de seguridad. Utilice grupos de seguridad para ese fin e implemente un proceso de aprobación basado en justificaciones comerciales.

Proteger las implementaciones de código

No basta con proteger el código. Si se ejecuta en canalizaciones vulnerables, todos los esfuerzos de seguridad serán inútiles e incompletos. Los entornos de compilación y lanzamiento también deben estar protegidos porque desea evitar que actores maliciosos ejecuten código malicioso en su canalización.

Mantenga un inventario actualizado de cada componente integrado en su aplicación

Cada nuevo componente que se integra en una aplicación aumenta la superficie de ataque. Para garantizar la asunción adecuada de responsabilidades y alertar cuando se agregan o actualizan nuevos componentes, debe tener un inventario de estos componentes. De forma regular, verifique que su manifiesto coincida con lo que hay en su proceso de compilación. De este modo ayudará a garantizar que no se agreguen inesperadamente nuevos componentes que contengan puertas traseras u otro malware.

Recomendamos usar Canalizaciones para Power Platform en sus implementaciones. Amplíe las canalizaciones con Acciones de GitHub. Si utiliza flujos de trabajo de GitHub, prefiera las tareas creadas por él mismo. Microsoft Además, valide las tareas porque se ejecutan en el contexto de seguridad de su canalización.

Explore el uso de entidades de servicio para implementación.

Fase de producción

La fase de producción presenta la última oportunidad responsable para solucionar infracciones de seguridad. Mantenga un registro de la imagen dorada que se lanza en producción.

Mantener artefactos con versiones

Mantenga un catálogo de todos los activos implementados y sus versiones. Esta información resulta útil durante la clasificación de incidentes, cuando se mitigan problemas y cuando se devuelve el sistema a un estado funcional. Los activos con versiones también se pueden comparar con los avisos publicados de Vulnerabilidades y exposiciones comunes (CVE). Debe utilizar la automatización para realizar estas comparaciones.

Correcciones de emergencia

El diseño de canalización automatizado debe tener la flexibilidad necesaria para admitir implementaciones tanto regulares como de emergencia. Esta flexibilidad es importante como ayuda de correcciones de seguridad rápidas y responsables.

Una versión suele estar asociada con varios controles de aprobación. Considere la posibilidad de crear un proceso de emergencia para acelerar las correcciones de seguridad. El proceso podría implicar comunicación entre equipos. La canalización debería permitir implementaciones rápidas de avance y retroceso que aborden correcciones de seguridad, errores críticos y actualizaciones de código que se producen fuera del ciclo de vida de implementación regular.

Nota

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

Mantenga separados los entornos diferentes

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.

Usar la exposición progresiva

Utilice la exposición progresiva para lanzar características a un subconjunto de usuarios según criterios elegidos. Si hay problemas, el impacto se minimiza para esos usuarios. Este enfoque es una estrategia común de mitigación de riesgos porque reduce la superficie. A medida que la característica madure y usted tenga más confianza en las garantías de seguridad, podrá lanzarla gradualmente a un conjunto más amplio de usuarios.

Fase de mantenimiento

El objetivo de esta fase es asegurarse de que la postura de seguridad no decaiga con el tiempo. SDLC es un proceso ágil y continuo. Los conceptos cubiertos en las fases anteriores se aplican a esta fase porque los requisitos cambian con el tiempo.

Actualización continua. Evalúe y mejore continuamente la seguridad del proceso de desarrollo de software teniendo en cuenta revisiones de código, comentarios, lecciones aprendidas y amenazas en evolución, así como nuevas características introducidas por Power Platform.

Desmantelar activos heredados que estén obsoletos o que ya no se utilicen. De este modo se reduce la superficie de la aplicación.

El mantenimiento también incluye la corrección de incidentes. Si se encuentran problemas en producción, es necesario volver a integrarlos rápidamente en el proceso para que no vuelvan a ocurrir.

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

SDL en Microsoft Power Platform

Power Platform se basa en una cultura y una metodología de diseño seguro. Tanto la cultura como la metodología se refuerzan constantemente a través de las prácticas de ciclo de vida de desarrollo de seguridad (SDL) y modelado de amenazas líderes del sector de Microsoft.

El sólido proceso de revisión de modelos de amenazas garantiza que se identifican durante la fase de diseño, se mitigan y se validan para asegurarse de que se hayan mitigado.

Threat Modeling también da cuenta de todos los cambios en los servicios que ya están activos a través de revisiones periódicas continuas. Confiando en el modelo STRIDE ayuda a abordar los problemas más comunes con el diseño inseguro.

MicrosoftEl SDL de es equivalente al modelo de madurez de garantía de software OWASP (SAMM). Ambos se basan en la premisa de que el diseño seguro es parte integral de la seguridad de las aplicaciones web. Para obtener más información, consulte Los 10 riesgos principales de OWASP: Mitigaciones en Power Platform.

Facilitación de Power Platform

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

Las herramientas de Defender for DevOps y SAST (Pruebas de seguridad estática de las aplicaciones) se incluyen como parte de la Seguridad avanzada de GitHub y Azure DevOps. Estas herramientas pueden ayudarle a realizar un seguimiento de la puntuación de seguridad de su organización.

Con la característica del comprobador de soluciones puede realizar una completa verificación de análisis estático de sus soluciones con un conjunto de reglas de prácticas recomendadas e identificar rápidamente estos patrones problemáticos. Consulte Use el comprobador de soluciones para validar sus soluciones.

Lista de verificación de seguridad

Consulte el conjunto completo de recomendaciones.

Lista de verificación de seguridad