Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Serviços de DevOps do Azure
As verificações de permissões fazem parte de muitas operações do Azure DevOps Services. Em grande escala, muitas atribuições explícitas de permissões, exceções ao nível dos recursos e pertença a grupos podem tornar mais lentas a avaliação e as atualizações das permissões. Grandes listas de controlo de acesso também exigem que o serviço recupere e resolva mais dados de permissões e identidades.
Use as recomendações deste artigo para reduzir a quantidade de dados de permissões que o Azure DevOps Services processa.
Tip
Pode usar IA para ajudar com tarefas do Azure DevOps. Consulte Ative assistência de IA com Azure DevOps MCP Server para começar.
Limites de desempenho suaves
Use os seguintes limites como alvos de planeamento para grandes organizações. O Azure DevOps Services não aplica estes limites nem bloqueia alterações de permissões que os excedam. No entanto, ultrapassá-los aumenta o risco de consultas de permissões demoradas, avaliações e atualizações de associação.
| Medida | Máximo recomendado |
|---|---|
| ACEs num único espaço de nomes de segurança | 1,000,000 |
| Membros num grupo do Microsoft Entra ou do Azure DevOps | 10,000 |
Uma entrada de controlo de acesso (ACE) armazena as permissões atribuídas a um utilizador ou grupo. Para grupos aninhados, considere o número total efetivo de membros ao aplicar a orientação relativa à dimensão do grupo.
Práticas recomendadas
| Practice | Benefício de desempenho |
|---|---|
| Atribuir permissões a grupos em vez de utilizadores individuais | Substitui várias entradas de controlo de acesso de utilizador (ACEs) por uma única ACE de grupo. |
| Use o âmbito e a herança correspondentes mais abrangentes | Evita repetir ACEs idênticos em recursos filhos. |
| Use Negar apenas para exceções | Limita sobreposições explícitas e ACEs ao nível do objeto. |
| Utilize grupos de identidade adequados | Reduz o processamento desnecessário da adesão ao grupo. |
| Equilibrar os recursos entre projetos e organizações | Limita o número de recursos avaliados dentro de um limite. |
| Aplicar alterações de permissões de forma incremental | Reduz a carga causada por atualizações grandes ou frequentes do controlo de acesso. |
Atribuir permissões a grupos
Use grupos de segurança Azure DevOps incorporados ou personalizados para representar funções, equipas e coortes de acesso. Atribuir uma permissão a um grupo cria um ACE. Atribuir a mesma permissão diretamente a muitos utilizadores cria um ACE para cada utilizador.
- Prefira grupos incorporados como Leitores, Colaboradores e Administradores de Project quando as suas permissões correspondem ao acesso necessário.
- Crie um grupo personalizado quando um grupo predefinido não corresponder ao nível de acesso necessário.
- Não substitua um grupo por centenas ou milhares de atribuições diretas a utilizadores.
Use o âmbito de correspondência e herança mais amplos
Defina uma permissão apenas uma vez no âmbito suportado mais elevado que corresponda ao requisito de acesso. Permita que os recursos filhos herdem a permissão e mantenha a herança ativada, a menos que um recurso filho exija um acesso diferente.
Por exemplo:
| Requisito de acesso | Âmbito preferido |
|---|---|
| Realizar uma tarefa ao nível da organização | Nível organizacional, quando a permissão está disponível nesse nível |
| Aceda a todos os recursos de um tipo suportado num projeto | Nível do projeto ou o elemento principal ao nível do projeto do tipo de recurso |
| Aceder a todos os repositórios Git num projeto | Entrada dos repositórios Git de nível superior |
| Aceder a todas as ramificações num repositório | Nível de repositório |
| Acede a um repositório, ramo, pipeline, caminho de área ou outro recurso | Nível do objeto |
Evite atribuir permissões idênticas em separado a cada repositório, ramificação, pipeline ou outro recurso subordinado. Para repositórios Git, os repositórios individuais herdam permissões da entrada dos repositórios Git de topo.
Desative a herança apenas quando um recurso precisa de acesso diferente do pai. Desativar a herança em muitos recursos normalmente requer atribuições mais explícitas.
Utilize "Deny" apenas para exceções
Conceda acesso através de um grupo e deixe permissões como Não definidas para identidades que não deveriam receber a concessão. Em vez de conceder um acesso amplo e depois adicionar muitas entradas de Negação , crie um grupo com as permissões exatas necessárias.
Use Negar apenas quando tiver de anular uma Permitir herdada para uma exceção específica. Uma única entrada Negada não é inerentemente um problema de desempenho. No entanto, muitas exceções adicionam ACEs e frequentemente exigem mais atribuições de permissões ao nível do objeto.
Utilize grupos de identidades com a dimensão adequada
Use grupos que estejam alinhados com os requisitos de acesso, como uma unidade de negócio, projeto, produto ou função de trabalho. Nem os grupos Entra nem os grupos Azure DevOps oferecem melhor desempenho. Aplique o mesmo tamanho e as mesmas diretrizes de aninhamento a ambos os tipos de grupos.
- Evite adicionar um grupo de inquilinos ou de toda a empresa, como um grupo de Todos os Colaboradores .
- Evite estruturas de grupo profundamente aninhadas ou frequentemente mutáveis quando um grupo mais simples oferece o mesmo acesso.
- Dividir um grupo muito grande em coortes de acesso mais pequenos quando os seus membros não precisam todos do mesmo acesso.
- Se todos os membros precisarem do mesmo acesso, atribui um grupo num âmbito parental herdado em vez de usar atribuições individuais ou grupos duplicados.
Grupos com mais de 10.000 membros representam um risco de desempenho. O nesting, as frequentes alterações de membros e o acesso a muitos recursos autorizados podem aumentar o impacto. Reduzir a adesão desnecessária e dividir o grupo em coortes de acesso mais pequenos sempre que possível.
Equilibrar os recursos entre projetos e organizações
Evite concentrar milhares de repositórios e a maioria dos recursos protegidos por permissão num só projeto, enquanto outros contêm apenas alguns. Operações que descobrem recursos acessíveis podem precisar de avaliar permissões em todo o conjunto.
Distribua grandes conjuntos de repositórios e outros recursos entre projetos antes que demasiados recursos se acumulem num só projeto. Não cries um projeto por repositório; O número de projetos também tem limites práticos de desempenho.
Em escalas empresariais extremas, várias organizações mais pequenas podem ter um desempenho melhor do que uma organização que contém a maioria dos recursos e dados de permissões da empresa. Dividir as organizações ao longo de fronteiras estáveis de produto ou negócio para distribuir a carga de recursos e permissões. Utilize esta abordagem apenas quando o benefício de escala compensar a sobrecarga de gerir recursos em organizações separadas.
Reduzir a rotatividade da automatização de permissões
Se gerir permissões através de scripts, APIs REST ou fluxos de trabalho de configuração-como-código:
- Aplique apenas as alterações necessárias para atingir o estado pretendido. Não apague nem reconstrua, em cada execução, as atribuições de permissões que não foram alteradas.
- Defina permissões num âmbito pai em vez de gerar entradas equivalentes para cada recurso filho.
- Alterações em lote eram suportadas e seguiam as melhores práticas da API REST do Azure DevOps.
- Evite loops de reconciliação de permissões de alta frequência.
- Evite criar e eliminar rotineiramente grandes quantidades de projetos ou recursos autorizados.
- Remover atribuições explícitas obsoletas para reduzir a lista de controlo de acesso (ACL) e o volume ACE.