Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Al implementar soluciones basadas en la nube para las implementaciones de infraestructura, la seguridad siempre debe ser su preocupación más importante. Microsoft mantiene la infraestructura en la nube subyacente segura. La seguridad se configura en Azure DevOps o GitHub.
Prerrequisitos
Una vez que decida qué plantillas de zona de aterrizaje de Azure implementar, clonelas en su propio repositorio. Configure las canalizaciones de CI/CD. Para GitHub y Azure DevOps, hay varios métodos de autenticación disponibles, como tokens de acceso personal (PAT) e integración con un proveedor de identidades, como Microsoft Entra ID. Para obtener más información, consulte Uso de tokens de acceso personal.
Se recomienda que se integre con el identificador de Entra de Microsoft para usar todas sus funcionalidades. La integración ayuda a simplificar el proceso de asignación de roles y la administración del ciclo de vida de la identidad. Para obtener más información, consulte Conectar su organización a Microsoft Entra ID. Si usa GitHub, considere la posibilidad de integrar GitHub Enterprise con el identificador de Microsoft Entra.
Consideraciones generales de diseño
Se recomienda mantener un control estricto de los administradores y grupos de cuentas de servicio en microsoft Entra ID y la herramienta DevOps. Considere la posibilidad de implementar el principio de privilegios mínimos en todas las asignaciones de roles.
Por ejemplo, su organización podría tener un equipo de plataforma o excelencia en la nube que mantenga plantillas de Azure Resource Manager para las zonas de aterrizaje de Azure. Asigne usuarios de ese equipo a un Grupo de Seguridad en Microsoft Entra ID, suponiendo que lo use como proveedor de identidades. Asigne roles a ese grupo de seguridad en la herramienta DevOps para que esos usuarios puedan realizar sus trabajos.
Para cualquier administrador o cuentas con privilegios elevados en Active Directory, se recomienda que las credenciales no se sincronicen con el identificador de Entra de Microsoft y viceversa. Este enfoque reduce la amenaza del movimiento lateral. Si un administrador de Microsoft Entra ID está en peligro, el atacante no podrá acceder fácilmente a ningún recurso en la nube, como Azure DevOps. Esa cuenta no puede insertar potencialmente tareas malintencionadas en las canalizaciones de CI/CD. Este paso es especialmente importante para los usuarios a los que se les han asignado permisos elevados en el entorno de DevOps, como administradores de compilación o de proyectos o recopilación. Para obtener más información, consulte Procedimientos recomendados de seguridad en Microsoft Entra ID.
Consideraciones sobre el acceso basado en rol de Azure DevOps
Administre la seguridad en Azure DevOps con grupos de seguridad, directivas y configuración en el nivel de organización o colección, proyecto o objeto. Para integrarse con un proveedor de identidades como Microsoft Entra ID, considere la posibilidad de crear directivas de acceso condicional para aplicar la autenticación multifactor para todos los usuarios. Las directivas permiten el acceso a su organización de Azure DevOps y establecen restricciones más detalladas con respecto a la dirección IP, el tipo de dispositivo utilizado para el acceso y el cumplimiento de normativas de dispositivos.
Para la mayoría de los miembros del equipo de su plataforma que administran las zonas de aterrizaje de Azure, el nivel de acceso básico y el grupo de seguridad predeterminado Colaborador deben proporcionar acceso suficiente. El grupo de seguridad Colaborador les permite editar las plantillas de zona de aterrizaje de Azure en el repositorio y las canalizaciones de CI/CD que las validan e implementan.
Se recomienda asignar el equipo de plataforma al grupo de seguridad Colaborador en el nivel de proyecto de Azure DevOps. Este enfoque sigue el principio de privilegios mínimos. Estas asignaciones se pueden realizar a través de la página Configuración del proyecto que se muestra a continuación.
Otro procedimiento recomendado para Azure DevOps Projects y organizaciones es deshabilitar la herencia siempre que sea posible. Los usuarios heredan los permisos permitidos por sus asignaciones de grupos de seguridad. Debido a la naturaleza de la herencia permitida de forma predeterminada, los usuarios inesperados pueden obtener acceso o permisos.
Por ejemplo, si asigna la pertenencia al grupo de seguridad Colaborador del equipo de plataforma, compruebe sus permisos en el repositorio de zonas de aterrizaje de Azure. Debe tener directivas de rama en vigor para comprobar que el grupo de seguridad no puede omitir esas directivas durante las solicitudes de incorporación de cambios. Verifique esta configuración en Configuración del Proyecto>Repositorios.
Después de asignar permisos a los usuarios, revise periódicamente los eventos de auditoría para supervisar y reaccionar a patrones de uso inesperados por parte de los administradores y otros usuarios. Empiece por crear una secuencia de auditoría en un área de trabajo de Log Analytics. Si el área de trabajo usa Microsoft Sentinel, cree reglas de análisis para avisarle de eventos importantes, como el uso incorrecto de permisos.
Para obtener más información, consulte los siguientes recursos:
- Procedimientos recomendados de seguridad de Azure DevOps
- Grupos y permisos de Azure DevOps
- Niveles de acceso de Azure DevOps
Consideraciones sobre el acceso basado en rol de GitHub
Si la herramienta principal de DevOps es GitHub, puede asignar a los usuarios acceso a los recursos concediéndoles roles en el nivel de repositorio, nivel de equipo o organización. Después de bifurcar el repositorio de Azure Landing Zones e integrarlo con un proveedor de identidades, como Microsoft Entra ID, considere la posibilidad de crear un equipo en GitHub. Asigne a ese equipo acceso de escritura al nuevo repositorio de la zona de aterrizaje de Azure. Para la mayoría de los miembros del equipo de plataforma, que modifican e implementan las zonas de aterrizaje, el acceso de escritura debe ser suficiente. En el caso de los administradores de proyectos o los administradores de Scrum en el equipo, es posible que tenga que asignarles el rol de mantenimiento a ese repositorio.
Se recomienda administrar todas estas asignaciones de roles a través del proveedor de identidades integrado. Por ejemplo, podría sincronizar el equipo de plataforma para el repositorio de zonas de aterrizaje de Azure que creó en GitHub con el grupo de seguridad del equipo de plataforma correspondiente en Microsoft Entra ID. A continuación, a medida que agrega o quita miembros al grupo de seguridad de Microsoft Entra, esos cambios se reflejan en las asignaciones de roles de GitHub Enterprise Cloud.
Nota:
Una vez que conecte un equipo específico de GitHub a un proveedor de identidades integrado, está restringido a administrar la pertenencia al equipo a través de él.
Pasos siguientes
Para obtener más información sobre la administración de roles y equipos en GitHub, consulte estos recursos: