Control de acceso basado en rol para herramientas de DevOps
Al implementar soluciones basadas en la nube para las implementaciones de infraestructura, la seguridad siempre debe ser su principal preocupación. Microsoft mantiene segura la infraestructura en la nube subyacente. La seguridad se configura en Azure DevOps o GitHub.
Requisitos previos
Una vez que decida qué plantillas de zona de aterrizaje de Azure implementar, clónelas en su propio repositorio. Configure las canalizaciones de CI/CD. Para GitHub y Azure DevOps, hay varios métodos de autenticación disponibles, como los 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 realizar la integración con Microsoft Entra ID 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 Conexión de la organización a Microsoft Entra ID. Si usa GitHub, considere la posibilidad de integrar GitHub Enterprise con Microsoft Entra ID.
Consideraciones generales de diseño
Se recomienda mantener un control estricto de los administradores y los 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 esté usando como proveedor de identidades. Asigne roles a ese grupo de seguridad en la herramienta DevOps para que los usuarios puedan realizar sus trabajos.
Para cualquier administrador o para las cuentas con privilegios elevados de Active Directory, se recomienda que las credenciales no se sincronicen con Microsoft Entra ID y viceversa. Este enfoque reduce la amenaza del movimiento lateral. Si un administrador de Microsoft Entra ID estuviera en peligro, el atacante no podrá acceder fácilmente a los recursos 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 cualquier permiso elevado asignado por los usuarios en el entorno de DevOps, como Administradores de compilación o de proyecto/colección. Para obtener más información, consulte Procedimientos recomendados de seguridad en Microsoft Entra ID.
Consideraciones sobre el acceso basado en roles de Azure DevOps
Administre la seguridad en Azure DevOps mediante grupos de seguridad, directivas y configuraciones a nivel de organización/colección, proyecto u objeto. Para realizar la integración con un proveedor de identidades como Microsoft Entra ID, considere la posibilidad de crear directivas de acceso condicional para aplicar la autenticación multifactor a todos los usuarios. Las directivas admiten el acceso a la organización de Azure DevOps y restricciones más pormenorizadas en torno a la dirección IP, el tipo de dispositivo usado para el acceso y el cumplimiento de los dispositivos.
Para la mayoría de los miembros del equipo de la 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 las 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. Compruebe esta configuración en Configuración del proyecto>Repositorios.
Una vez que haya asignado permisos a los usuarios, revise periódicamente los eventos de auditoría para supervisar patrones de uso inesperados por parte de los administradores y otros usuarios y para reaccionar ante ellos. 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 sobre eventos importantes, como el uso incorrecto de permisos.
Para obtener más información, vea 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 roles de GitHub
Si la herramienta principal de DevOps es GitHub, puede asignar a los usuarios acceso a los recursos concediéndoles roles a nivel de repositorio, nivel de equipo o nivel de organización. Después de bifurcar el repositorio de zonas de aterrizaje de Azure 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 del 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 agregue miembros al grupo de seguridad de Azure AD o los quite, esos cambios se reflejarán 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 más información sobre cómo administrar roles y equipos en GitHub, consulte estos recursos: