Administración de seguridad mejorada

Con esta actualización, ahora tiene la opción de habilitar o deshabilitar Advanced Security para todo el proyecto u organización. También puede habilitar automáticamente Advanced Security para cualquier repositorio o proyecto recién creado.

En Azure Pipelines, hemos agregado un control centralizado para mejorar la seguridad de las solicitudes de incorporación de cambios creadas a partir de repositorios de GitHub bifurcados.

Consulte las notas de la versión para obtener más información sobre estas características.

General

• Habilitación de nivel de proyecto y organización para la seguridad avanzada

• Recuento estimado de confirmadores durante la habilitación de Advanced Security

Azure Pipelines

• Reintentar una fase cuando se agotan las aprobaciones y se agota el tiempo de espera

• Rol de administrador para todos los entornos

• Control centralizado para compilar solicitudes de incorporación de cambios desde repositorios de GitHub bifurcados

Azure Repos

• Nueva "directiva de rama" que impide que los usuarios aprueben sus propios cambios

Azure Artifacts

• Introducción a la compatibilidad de Azure Artifacts con contenedores de carga (versión preliminar pública)

General

Habilitación de nivel de proyecto y organización para la seguridad avanzada

Ahora puede habilitar o deshabilitar Advanced Security para todo el proyecto u organización. Junto con la nueva adición de la visualización del recuento de confirmadores antes de la habilitación, al seleccionar "Habilitar todo" en el proyecto o nivel de organización se le proporcionará una estimación del número de confirmadores activos nuevos por los que se puede facturar. También puede optar por habilitar automáticamente Advanced Security para cualquier repositorio o proyecto recién creado en su proyecto o organización respectivos. Los repositorios habilitados a través de esta configuración tendrán el examen de repositorios secretos y la protección de inserción activas.

Habilitación de nivel de proyecto:

Habilitación de nivel de organización:

Recuento estimado de confirmadores durante la habilitación de Advanced Security

Como parte de la experiencia de incorporación de Advanced Security , ahora puede ver una estimación del número de confirmadores activos que se pueden haber agregado como resultado de habilitar la seguridad avanzada para un repositorio, proyecto u organización determinados. Este recuento es una aproximación y es posible que vea ligeras discrepancias entre la estimación proporcionada y lo que se notifica para la facturación después de la habilitación. Esta estimación también se puede obtener a través de la API con documentación adicional que explica este proceso próximamente.

Azure Pipelines

Reintentar una fase cuando se agotan las aprobaciones y se agota el tiempo de espera

Cuando se agota el tiempo de espera de aprobaciones y comprobaciones, se omite la fase a la que pertenecen. También se omiten las fases que tienen una dependencia en la fase omitida.

Ahora puede volver a intentar una fase cuando las aprobaciones y comprueban el tiempo de espera. Anteriormente, esto solo era posible cuando se agotó el tiempo de espera de una aprobación.

Rol de administrador para todos los entornos

Los entornos de las canalizaciones de YAML representan un recurso de proceso en el que se implementa la aplicación, por ejemplo, un clúster de AKS o un conjunto de máquinas virtuales. Proporcionan controles de seguridad y rastreabilidad para las implementaciones.

La administración de entornos puede ser bastante difícil. Esto se debe a que, cuando se crea un entorno, la persona que la crea se convierte automáticamente en el único administrador. Por ejemplo, si desea administrar las aprobaciones y comprobaciones de todos los entornos de forma centralizada, debe pedir a cada administrador de entorno que agregue un usuario o grupo específico como administrador y, a continuación, use la API REST para configurar las comprobaciones. Este enfoque es tedioso, propenso a errores y no se escala cuando se agregan nuevos entornos.

Con este sprint, hemos agregado un rol de administrador en el nivel de centro de entornos. Esto hace que los entornos se analicen con conexiones de servicio o grupos de agentes. Para asignar el rol administrador a un usuario o grupo, ya debe ser un administrador del centro de entornos o propietario de la organización.

Un usuario con este rol de administrador puede administrar permisos, administrar, ver y usar cualquier entorno. Esto incluye la apertura de entornos a todas las canalizaciones.

Cuando se concede un rol de administrador de usuarios en el nivel de entornos-centro, se convierten en administradores para todos los entornos existentes y para cualquier entorno futuro.

Control centralizado para compilar solicitudes de incorporación de cambios desde repositorios de GitHub bifurcados

Si compila repositorios públicos desde GitHub, debe tener en cuenta su postura sobre las compilaciones de bifurcación. Las bifurcaciones son especialmente peligrosas, ya que proceden de fuera de la organización.

Puede mejorar la seguridad de las canalizaciones que compilan repositorios públicos de GitHub revisando nuestras recomendaciones sobre cómo compilar repositorios de GitHub y protección de repositorios. Desafortunadamente, la administración de numerosas canalizaciones y la garantía de su adhesión a los procedimientos recomendados puede requerir una cantidad considerable de esfuerzo.

Para mejorar la seguridad de las canalizaciones, hemos agregado un control de nivel de organización para definir cómo las canalizaciones compilan solicitudes de incorporación de cambios a partir de repositorios de GitHub bifurcados. La nueva configuración se denomina Limitar la creación de solicitudes de incorporación de cambios de repositorios de GitHub bifurcadas y funciona en el nivel de organización y proyecto.

La configuración de nivel de organización restringe los proyectos de configuración y la configuración de nivel de proyecto restringe las canalizaciones de configuración.

Veamos cómo funciona el botón de alternancia en el nivel de organización. El nuevo control está desactivado de forma predeterminada, por lo que no se aplica universalmente ninguna configuración.

Al activar el botón de alternancia, puede optar por deshabilitar la creación de solicitudes de incorporación de cambios desde repositorios de GitHub bifurcados. Esto significa que no se ejecutará ninguna canalización cuando se cree dicha solicitud de incorporación de cambios.

Al elegir la opción Solicitudes de incorporación de cambios de compilación segura de repositorios bifurcadas , todas las canalizaciones, en toda la organización, no pueden hacer que los secretos estén disponibles para las compilaciones de solicitudes de incorporación de cambios desde repositorios bifurcados, no pueden hacer que estas compilaciones tengan los mismos permisos que las compilaciones normales y deben desencadenarse mediante un comentario de solicitud de incorporación de cambios. Los proyectos todavía pueden decidir no permitir que las canalizaciones compilen dichas solicitudes de incorporación de cambios.

Al elegir la opción Personalizar , puede definir cómo restringir la configuración de canalización. Por ejemplo, puede asegurarse de que todas las canalizaciones requieren un comentario para crear una solicitud de incorporación de cambios a partir de un repositorio de GitHub bifurcado, cuando la solicitud de incorporación de cambios pertenece a miembros que no son de equipo y no colaboradores. Sin embargo, puede optar por permitirles que los secretos estén disponibles para dichas compilaciones. Los proyectos pueden decidir no permitir que las canalizaciones compilen dichas solicitudes de incorporación de cambios o que las compilen de forma segura o tengan aún más configuraciones más restrictivas que lo que se especifica en el nivel de organización.

Azure Repos

Nueva "directiva de rama" que impide que los usuarios aprueben sus propios cambios

Para mejorar el control sobre los cambios que el usuario aprueba y coincide con los requisitos normativos y de cumplimiento más estrictos, proporcionamos una opción para evitar que el usuario apruebe sus propios cambios a menos que se permita explícitamente.

El usuario con la capacidad de administrar las directivas de rama ahora puede cambiar la opción "Requerir al menos una aprobación en cada iteración" en "Cuando se insertan nuevos cambios". Cuando se selecciona esta opción, se requiere al menos un voto de aprobación para el último cambio de rama de origen. La aprobación del usuario no se cuenta con ninguna iteración no aprobada anterior insertada por ese usuario. Como resultado, es necesario que otro usuario realice la aprobación adicional en la última iteración.

En la imagen siguiente se muestra la solicitud de incorporación de cambios creada por el usuario A y otras 4 confirmaciones (iteraciones) realizadas a esa solicitud de incorporación de cambios por los usuarios B, C, A de nuevo y C. Una vez finalizada la segunda iteración (confirmación realizada por el usuario B), el usuario C lo aprobó. En ese momento, implicaba la aprobación de la primera confirmación del usuario A (cuando se creó la solicitud de incorporación de cambios) y la directiva recién introducida se realizará correctamente. Después de la quinta iteración (última confirmación del usuario C), el usuario A realizó la aprobación. Esta aprobación implícita para la confirmación anterior realizada por el usuario C, pero no implicaba la aprobación de la segunda confirmación realizada por el usuario A en la cuarta iteración. Para que la directiva recién introducida se realice correctamente, la iteración no aprobada cuatro debe aprobarse mediante la aprobación del usuario B, C o cualquier otro usuario que no haya realizado ningún cambio en la solicitud de incorporación de cambios.

Azure Artifacts

Introducción a la compatibilidad de Azure Artifacts con contenedores de carga (versión preliminar pública)

Nos complace anunciar que Azure Artifacts ahora ofrece compatibilidad nativa con cajas de carga. Esta compatibilidad incluye paridad de características con respecto a nuestros protocolos existentes, además de crates.io estar disponible como origen ascendente. Los desarrolladores y equipos de Rust ahora pueden consumir, publicar, administrar y compartir sus cajas de carga sin problemas, al tiempo que usan la sólida infraestructura de Azure y permanecen en el entorno familiar de Azure DevOps.

No se necesita registro para la versión preliminar; Para empezar, vaya al proyecto de Azure DevOps, seleccione Artefactos y siga las instrucciones para conectar el proyecto de Rust a la fuente de Azure Artifacts.

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Vaya a Azure DevOps.

Cómo enviar sus comentarios

Nos encantaría saber lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

También puede recibir consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

Gracias,

Silviu Andrica