Otimizar permissões para desempenho

Serviços do Azure DevOps

As verificações de permissão fazem parte de muitas operações do Azure DevOps Services. Em grande escala, muitas atribuições de permissão explícitas, exceções no nível de recurso e associações de grupo podem reduzir a avaliação e as atualizações de permissões. Listas de controle de acesso grande também exigem que o serviço recupere e resolva mais dados de permissão e identidades.

Use as recomendações neste artigo para reduzir a quantidade de dados de permissões que o Azure DevOps Services processa.

Limites de desempenho suaves

Use os limites a seguir como metas de planejamento para grandes organizações. Azure DevOps Services não impõe esses limites nem bloqueia as alterações de permissão que os excedem. No entanto, excedê-las aumenta o risco de consultas de permissão lentas, avaliações e atualizações de associação.

Uma ACE (entrada de controle de acesso) armazena as permissões atribuídas a um usuário ou grupo. Para grupos aninhados, considere o total de membros efetivos ao usar a diretriz de tamanho do grupo.

Práticas recomendadas

Atribuir permissões a grupos

Use grupos de segurança Azure DevOps internos ou personalizados para representar funções, equipes e coortes de acesso. Atribuir uma permissão a um grupo cria um ACE. Atribuir a mesma permissão diretamente a muitos usuários cria uma ACE para cada usuário.

• Prefira grupos internos como Leitores, Colaboradores e Administradores de Project quando suas permissões corresponderem ao acesso necessário.
• Crie um grupo personalizado quando um grupo integrado não atender ao acesso necessário.
• Não substitua um grupo por centenas ou milhares de atribuições diretas a usuários.

Use o escopo de correspondência mais amplo e a herança

Defina uma permissão uma única vez no escopo mais alto compatível com o requisito de acesso. Permita que os recursos secundários herdem a permissão e mantenha a herança habilitada, a menos que um recurso secundário exija um acesso diferente.

Por exemplo:

Evite configurar permissões idênticas separadamente em cada repositório, ramificação, pipeline ou qualquer outro recurso filho. Para repositórios Git, repositórios individuais herdam permissões da entrada de repositórios Git de nível superior.

Desabilite a herança somente quando um recurso precisar de acesso diferente de seu pai. Desabilitar a herança em muitos recursos geralmente requer atribuições mais explícitas.

Use Deny apenas para exceções

Conceda acesso por meio de um grupo e deixe permissões como Não definidas para identidades que não devem receber a concessão. Em vez de conceder acesso amplo e adicionar muitas entradas deny , crie um grupo com as permissões exatas necessárias.

Use Negar somente quando você precisar substituir um Allow herdado para uma exceção específica. Uma única entrada deny não é inerentemente um problema de desempenho. No entanto, muitas exceções adicionam ACEs e geralmente exigem mais atribuições de permissão no nível do objeto.

Use grupos de identidade dimensionados adequadamente

Use grupos que se alinham aos requisitos de acesso, como uma unidade de negócios, projeto, produto ou função de trabalho. Nem os grupos do Entra nem os grupos do Azure DevOps oferecem melhor desempenho. Aplique as mesmas diretrizes de tamanho e aninhamento a ambos os tipos de grupo.

• Evite adicionar um grupo de locatários ou de toda a empresa, como um grupo All Employees .
• Evite estruturas de grupo muito aninhadas ou que mudam com frequência quando um grupo mais simples fornece o mesmo acesso.
• Divida um grupo muito grande em coortes de acesso menores quando seus membros não exigem o mesmo acesso.
• Se cada membro precisar do mesmo acesso, atribua um grupo em um escopo pai herdado em vez de usar atribuições individuais ou grupos duplicados.

Grupos com mais de 10.000 membros são um risco de desempenho. Aninhamento, alterações frequentes de associação e acesso a muitos recursos autorizados podem aumentar o impacto. Reduza a associação desnecessária e divida o grupo em coortes de acesso menores, quando prático.

Balancear recursos entre projetos e organizações

Evite concentrar milhares de repositórios e a maioria dos recursos protegidos por permissão em um projeto, enquanto outros projetos contêm apenas alguns. As operações que descobrem recursos acessíveis podem precisar avaliar permissões em todo o conjunto.

Distribua grandes conjuntos de repositórios e outros recursos entre projetos antes que muitos recursos se acumulem em um projeto. Não crie um projeto por repositório; A contagem de projetos também tem limites práticos de desempenho.

Em escala empresarial extrema, várias organizações menores podem ter um desempenho melhor do que uma organização que contém a maioria dos dados de permissão e recursos da empresa. Divida as organizações com base em fronteiras estáveis de produto ou de negócios para distribuir a carga de recursos e de permissões. Use essa abordagem somente quando o benefício de escala superar a sobrecarga de gerenciamento de recursos em organizações separadas.

Reduza a instabilidade na automação de permissões

Se você gerenciar permissões por meio de scripts, APIs REST ou fluxos de trabalho de configuração como código:

• Aplique apenas as alterações necessárias para alcançar o estado pretendido. Não apague nem recrie atribuições de permissão inalteradas em cada execução.
• Defina permissões em um escopo pai em vez de gerar entradas equivalentes para cada recurso filho.
• Faça alterações em lote quando houver suporte e siga as práticas recomendadas da API REST do Azure DevOps.
• Evite ciclos de reconciliação de permissões de alta frequência.
• Evite criar e excluir rotineiramente um grande número de projetos ou recursos com permissão.
• Remova atribuições explícitas obsoletas para reduzir o volume da lista de controle de acesso (ACL) e das ACEs.

Consulte também

• Sobre permissões e grupos de segurança
• Sobre projetos e dimensionamento de sua organização
• Acompanhamento de trabalho, processo e limites de projeto
• práticas recomendadas da API REST Azure DevOps