Consideraciones de gobernanza para la implementación segura en Azure

Los procesos automatizados de integración continua y entrega continua (CI/CD) deben tener una gobernanza integrada que autorice y autentique las identidades para realizar las tareas dentro de un ámbito definido.

Puntos clave

Minimización del acceso

Minimice el número de personas que tienen acceso a información o recursos seguros. Esta estrategia reducirá la posibilidad de que un actor malintencionado obtenga acceso o de que un usuario autorizado altere accidentalmente un recurso confidencial. A continuación, se indican algunas consideraciones:

• Use el principio de privilegios mínimos al asignar roles y permisos. Solo los usuarios responsables de las versiones de producción deben iniciar el proceso y solo los desarrolladores deben acceder al código fuente.

  Una canalización debe usar una o varias entidades de servicio. Lo ideal es que sean identidades administradas y entregadas por la plataforma y que nunca se definan directamente dentro de una canalización. La identidad solo debe tener los permisos de RBAC de Azure necesarios para realizar la tarea. Todas las entidades de servicio deben estar enlazadas a esa canalización y no compartirse entre canalizaciones.

  ¿Cómo se definen los roles y permisos de CI/CD?

  ---

  Azure DevOps ofrece roles integrados que se pueden asignar a usuarios individuales de grupos. Si los roles integrados no son suficientes para definir los privilegios mínimos para una canalización, considere la posibilidad de crear roles de RBAC de Azure personalizados. Asegúrese de que esos roles se alinean con la acción y con los equipos y responsabilidades de la organización.

  Para dar soporte técnico a las operaciones de la canalización, puede agregar los usuarios a un grupo de seguridad integrado, establecer los permisos individuales de un usuario o grupo, o bien agregar usuarios a roles predefinidos. La seguridad de los siguientes objetos se administra desde Azure Pipelines en el portal web, desde el contexto de usuario o del administrador.

  Para más información, consulte Introducción a los permisos, el acceso y los grupos de seguridad.

• En el caso de los permisos, estos se pueden conceder o restringir estableciendo el estado de permiso en Permitir o Denegar, ya sea para un grupo de seguridad o un usuario individual. En el caso de un rol, agregue un usuario o grupo al mismo.

• Use identidades de canalización independientes entre entornos de preproducción y producción. Si está disponible, aproveche las características de canalización, como Entornos, para encapsular la autenticación de la última milla externa a la canalización que lleva a cabo la ejecución.

• Si la canalización se ejecuta con poca frecuencia y tiene privilegios elevados, considere la posibilidad de quitar permisos permanentes de esa identidad. Use asignaciones de roles Just-In-Time (JIT) y la activación de roles basada en tiempo y basada en aprobación. Esta estrategia mitigará los riesgos de permisos de acceso excesivos, innecesarios o usados indebidamente en recursos cruciales. Azure AD Privileged Identity Management admite todos esos modos de activación.

• Examine la canalización de integración continua y entrega continua de la organización y refine la asignación de roles para crear una delineación clara entre las responsabilidades de desarrollo y de producción.

Más información

Para más información sobre los roles de seguridad y permisos de la canalización, consulte el artículo sobre el establecimiento de distintos niveles de permisos de canalización.

Ámbito de ejecución

Si resulta práctico, limite el ámbito de ejecución de las canalizaciones.

Considere la posibilidad de crear una canalización de varias fases. Divida el trabajo en unidades discretas y que se pueda aislar en una canalización independiente. Limite las identidades solo al ámbito de la unidad para que tenga privilegios mínimos suficientes para realizar la acción. Por ejemplo, puede tener dos unidades, una para implementar y otra para compilar el código fuente. Solo permita que la unidad de implementación tenga acceso a la identidad, no la unidad de compilación. Si la unidad de compilación estuviera en peligro, podría empezar a manipular la infraestructura.

Proceso de aprobación canalizado

¿Tiene las aprobaciones de la puerta de lanzamiento configuradas en el proceso de lanzamiento de DevOps?

Las solicitudes de extracción y las revisiones de código sirven como primera línea de aprobaciones durante el ciclo de desarrollo. Antes de lanzar una actualización a producción, debe tener un proceso que exija la revisión y la aprobación de seguridad.

Asegúrese de implicar al equipo de seguridad en el proceso de planeamiento, de diseño y de DevOps. Esta colaboración les ayudará a implementar controles de seguridad, auditoría y procesos de respuesta.

¿Se usan directivas de rama en la administración del control de código fuente de esta carga de trabajo? ¿Cómo están configuradas?

Establezca directivas de rama que proporcionen un nivel adicional de control sobre el código confirmado en el repositorio. La falta de una directiva de rama segura puede hacer que se proteja e implemente código deficiente, no autorizado o roto. Es una práctica común denegar las inserciones en la rama principal si el cambio no se aprueba. Por ejemplo, puede requerir la solicitud de incorporación de cambios (PR) con revisión de código antes de combinar los cambios al menos de un revisor que no sea el autor del cambio.

Se recomienda tener varias ramas cada una de las cuales tenga un propósito y un nivel de acceso. Por ejemplo, los desarrolladores crean ramas de características que están abiertas para la inserción. La rama de integración requiere la revisión del código y la solicitud de incorporación de cambios. La rama de producción requiere otra aprobación del líder del equipo antes de la combinación.

Acciones sugeridas

• Configure las aprobaciones de puertas de calidad en el proceso de versiones de DevOps.
• Siga la guía de los artículos vinculados para implementar y adoptar la estrategia de ramas.

Más información

• Acerca de las ramas y las directivas de rama
• Adopción de una estrategia de bifurcación de Git
• Control de implementación de versiones mediante puertas

Siguientes

Vínculos relacionados

Vuelva al artículo principal: Implementación y pruebas seguras en Azure