Administración de cambios de Microsoft 365

Microsoft 365 aplica procedimientos de administración de cambios cuando se realizan cambios de código y no de código en sus sistemas para mantener su posición de seguridad. Cualquier desfase de configuración desde la posición inicial puede introducir vulnerabilidades, interrumpir la funcionalidad o interrumpir la disponibilidad. Una vez que se ha implementado un sistema de información dentro de Microsoft 365 con una postura de seguridad sólida, se aplican procesos detallados de administración de cambios para ayudar a mantener la integridad del sistema.

Hay muchos factores de cambio en Microsoft 365, incluidos los nuevos requisitos funcionales o de seguridad, los comentarios de los clientes, las vulnerabilidades identificadas y los resultados de auditoría. Independientemente del controlador para el cambio, los equipos de servicio usan herramientas de control de código fuente o de vales para documentar pruebas de aprobación y realizar un seguimiento de todos los cambios.

Cambios en el código fuente

Los cambios se implementan en consonancia con el ciclo de vida de desarrollo seguro (SDL) de Microsoft, que va seguido de todos los proyectos de ingeniería y desarrollo de Microsoft 365. Este es un modelo de desarrollo de software que incluye consideraciones de seguridad específicas relacionadas con revisiones de código, pruebas y aprobaciones antes de que se publiquen sistemáticamente en el entorno de Microsoft 365.

El SDL actúa como marco e incluye la identificación de posibles riesgos para el proyecto de desarrollo finalizado y estrategias de mitigación que se pueden implementar y probar durante las fases de desarrollo. También se incluyen puntos de control críticos de revisión de seguridad y aprobación.

Cambiar la identificación y el planeamiento

Los equipos de servicio se reúnen periódicamente para analizar los cambios propuestos, como la justificación, el ámbito, el impacto en la seguridad, la prioridad, las dependencias, los planes de implementación, los roles y las responsabilidades. Esta información se documenta en el sistema de seguimiento de la administración de cambios. Si se rechaza el cambio, la justificación se documenta explícitamente en el vale para futuras referencias.

Revisiones de código de personal

Antes de que se pueda incluir cualquier código nuevo en una nueva compilación e implementación, debe pasar la revisión del código de personal. La aplicación de estas revisiones se controla a través de una canalización de código automatizada adjunta a cada repositorio de código y no se puede eludir. Una vez recibida la aprobación necesaria, el código puede pasar a la fase siguiente.

Los revisores de código comprueban si hay errores de codificación, comprueban que los cambios cumplen los requisitos y realizan un análisis de impacto de seguridad. Las revisiones deben ser realizadas por alguien distinto de las personas que desarrollaron el código, aplicando el principio de separación de tareas. Impedir que las mismas personas envíen y aprueben su propio código es un control crítico que Microsoft aplica estrictamente. Esto reduce en gran medida la posibilidad de que las personas liberen de forma individual, ya sea de forma intencionada o involuntaria, código dañino o malintencionado. Si los revisores encuentran problemas durante la revisión de código, detienen el cambio y hacen que los desarrolladores vuelvan a enviar el código con cambios sugeridos y pruebas adicionales. Los revisores de código también pueden decidir rechazar la protección por completo para el código que no cumple los requisitos identificados. Una vez que el revisor considera que el código es satisfactorio, se proporciona la aprobación y el código se registra en la rama principal para incluirlo en la siguiente compilación.

Comprobaciones automatizadas de seguridad y canalización de compilación

Una vez que todos los cambios del sprint se confirman en la rama principal, se inicia el proceso de compilación automatizada. El código está sujeto a varias comprobaciones de seguridad automatizadas, como el análisis de código estático, el análisis binario, el examen de credenciales y secretos y el análisis de cifrado. Microsoft 365 define un conjunto de pruebas esenciales que cada compilación debe pasar antes de la implementación en entornos de preproducción. Las compilaciones que no se pasan se rechazan y se envían al equipo de desarrollo donde se realizan ajustes hasta que se superan todas las comprobaciones. Las compilaciones correctas continúan en el entorno de preproducción a través de una canalización de implementación automatizada.

Versión de compilación

Las compilaciones se publican inicialmente solo para el equipo de servicio que desarrolló la característica. La estabilidad y la funcionalidad se prueban antes de su lanzamiento en grupos de prueba progresivamente más grandes en entornos de nube aislados lógicamente denominados anillos. Después del equipo de servicio, la compilación se publica en todos los grupos internos de Microsoft 365, seguido de la versión de la compilación en todos los grupos internos de Microsoft. Esta prueba, a menudo denominada internamente dogfooding, permite a Microsoft identificar errores en el entorno de producción real antes de que la compilación se publique para clientes externos. Estos métodos de prueba garantizan que el código de Microsoft es seguro y funciona según lo esperado antes de que llegue a los clientes y a la implementación en todo el mundo. Las compilaciones anteriores siempre se conservan con fines de reversión.

Los equipos de ingeniería determinan la cantidad de tiempo que una compilación pasa en cada anillo, por lo general permanecen durante varios períodos de carga alta antes de pasar al siguiente anillo. Si todas las pruebas se realizan correctamente en cada anillo interno, la compilación se publica para los clientes de todo el mundo, primero como versión dirigida a los inquilinos de clientes que han optado por ese anillo, seguido de una versión estándar mundial.

Cambios que no son de código

Los cambios no relacionados con el código se definen como modificaciones en sistemas de Microsoft 365 que no implican la creación o edición de código fuente del servicio. Esto puede incluir la apertura de puertos, el cambio de Access Control Listas (ACL) u otros cambios en el sistema subyacente. En comparación, los cambios que no son de código se producen con menos frecuencia que los cambios de código, pero todavía requieren un alto nivel de examen.

Se documenta una descripción del cambio junto con los pasos de implementación, los pasos de validación y un plan de reversión. Antes de implementar el cambio, al menos una persona revisa los planes para comprobar la precisión y el impacto en la seguridad. Una vez aprobados, se implementan los planes documentados. Si todos los pasos de validación se superan correctamente, los resultados se documentan en el vale y se marcan como resueltos.

Si la implementación del cambio no se realiza correctamente, se desencadenan los planes de reversión y el equipo vuelve a la fase de planeación y repite el proceso hasta que se realice correctamente.

Recursos

• Guía de cambios de Microsoft 365: Implementación de Office