Optimización de permisos para el rendimiento

servicios de Azure DevOps

Las comprobaciones de permisos forman parte de muchas operaciones de Azure DevOps Services. A gran escala, muchas asignaciones de permisos explícitas, excepciones de nivel de recurso y pertenencias a grupos pueden ralentizar la evaluación y las actualizaciones de permisos. Las listas de control de acceso de gran tamaño también requieren que el servicio recupere y resuelva más datos de permisos e identidades.

Use las recomendaciones de este artículo para reducir la cantidad de datos de permisos que Azure DevOps Services procesa.

Límites de rendimiento flexible

Use los límites siguientes como objetivos de planeamiento para organizaciones grandes. Azure DevOps Services no aplica estos límites ni bloquea los cambios de permisos que los superan. Sin embargo, superarlos aumenta el riesgo de que las consultas de permisos, las evaluaciones y las actualizaciones de membresía sean lentas.

Una entrada de control de acceso (ACE) almacena los permisos asignados a un usuario o grupo. En el caso de los grupos anidados, tenga en cuenta la pertenencia efectiva total al usar la guía de tamaño de grupo.

Prácticas recomendadas

Asigne permisos a grupos

Use grupos de seguridad integrados o personalizados Azure DevOps para representar roles, equipos y cohortes de acceso. La asignación de un permiso a un grupo crea una ACE. Asignar el mismo permiso directamente a muchos usuarios crea una ACE para cada usuario.

• Prefiere grupos integrados como lectores, colaboradores y administradores de Project cuando sus permisos coincidan con el acceso necesario.
• Cree un grupo personalizado cuando un grupo integrado no coincida con el acceso necesario.
• No sustituyas un grupo por cientos o miles de asignaciones directas a usuarios.

Utiliza el ámbito de coincidencia más amplio y la herencia

Establece un permiso una sola vez en el ámbito más alto admitido que se ajuste al requisito de acceso. Deja que los recursos secundarios hereden los permisos y mantén la herencia activada, a menos que un recurso secundario requiera un acceso diferente.

Por ejemplo:

Evita configurar permisos idénticos por separado en cada repositorio, rama, canalización u otro recurso secundario. En el caso de los repositorios de Git, los repositorios individuales heredan los permisos de la entrada de repositorios de Git de nivel superior.

Desactiva la herencia solo cuando un recurso necesite un acceso diferente al de su recurso padre. Deshabilitar la herencia en múltiples recursos normalmente requiere asignaciones más explícitas.

Use Deny only for exceptions (Usar denegar solo para excepciones)

Conceda acceso a través de un grupo y deje los permisos como No establecido para las identidades que no deben recibir la concesión. En lugar de conceder acceso amplio y, a continuación, agregar muchas entradas Deny , cree un grupo con los permisos exactos necesarios.

Use Denegar solo cuando deba invalidar un permiso heredado para una excepción específica. Una sola entrada Deny no es inherentemente un problema de rendimiento. Sin embargo, muchas excepciones añaden ACE y a menudo requieren más asignaciones de permisos a nivel de objeto.

Use grupos de identidad del tamaño adecuado

Use grupos que se alineen con los requisitos de acceso, como una unidad de negocio, un proyecto, un producto o una función de trabajo. Ni los grupos entra ni los grupos de Azure DevOps ofrecen un mejor rendimiento. Aplique la misma guía de tamaño y anidamiento a ambos tipos de grupo.

• Evite agregar un grupo de inquilinos o de toda la empresa, como un grupo Todos los empleados .
• Evite estructuras de grupo muy anidadas o que cambian con frecuencia cuando un grupo más sencillo proporciona el mismo acceso.
• Divida un grupo muy grande en cohortes de acceso más pequeñas cuando sus miembros no requieran el mismo acceso.
• Si cada miembro necesita el mismo acceso, asigne un grupo en un ámbito primario heredado en lugar de usar asignaciones individuales o grupos duplicados.

Los grupos con más de 10 000 miembros son un riesgo de rendimiento. El anidamiento, los cambios frecuentes en la pertenencia y el acceso a muchos recursos con permisos pueden aumentar el impacto. Reduzca la pertenencia innecesaria y divida el grupo en cohortes de acceso más pequeñas donde sea práctico.

Equilibrio de recursos entre proyectos y organizaciones

Evite concentrar miles de repositorios y la mayoría de los recursos protegidos con permisos en un proyecto, mientras que otros proyectos solo contienen unos pocos. Es posible que las operaciones que detecten recursos accesibles necesiten evaluar los permisos en todo el conjunto.

Distribuya grandes conjuntos de repositorios y otros recursos entre proyectos antes de que se acumulan demasiados recursos en un proyecto. No cree un proyecto por repositorio; el recuento de proyectos también tiene límites prácticos de rendimiento.

A escala empresarial extrema, varias organizaciones más pequeñas pueden funcionar mejor que una organización que contenga la mayoría de los recursos de la empresa y los datos de permisos. Divida las organizaciones a lo largo de límites de producto o negocio estables para distribuir la carga de recursos y permisos. Use este enfoque solo cuando la ventaja de escala supere la sobrecarga de administración de recursos en organizaciones independientes.

Reduzca la rotación de la automatización de permisos

Si gestiona permisos mediante scripts, API REST o flujos de trabajo de configuración como código:

• Aplique solo los cambios necesarios para alcanzar el estado previsto. No borre ni recompile las asignaciones de permisos sin cambios en cada ejecución.
• Configure los permisos en un ámbito de recurso padre en lugar de generar entradas equivalentes para cada recurso secundario.
• Realice cambios por lotes cuando sea posible y siga las prácticas recomendadas de la API REST de Azure DevOps.
• Evite bucles de conciliación de permisos de alta frecuencia.
• Evite crear y eliminar de forma rutinaria un gran número de proyectos o recursos con permisos.
• Quite las asignaciones explícitas obsoletas para reducir la lista de control de acceso (ACL) y el volumen ACE.

Véase también

• Acerca de los permisos y los grupos de seguridad
• Acerca de los proyectos y el escalado de la organización
• Seguimiento del trabajo, proceso y límites del proyecto
• Procedimientos recomendados de la API REST de Azure DevOps