Compartilhar via

Melhores práticas de segurança

  • Artigo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Quando você está lidando com informações e dados, especialmente em uma solução baseada em nuvem como Azure DevOps Services, a segurança deve ser sua principal prioridade. Embora a Microsoft garanta a segurança da infraestrutura de nuvem subjacente, configurar a segurança no Azure DevOps é sua responsabilidade.

Embora não seja obrigatório, a incorporação de práticas recomendadas pode melhorar significativamente sua experiência e reforçar a segurança. As recomendações a seguir foram projetadas para ajudá-lo a manter um ambiente seguro do Azure DevOps.

Proteger seu ambiente do Azure DevOps

Empregue as seguintes práticas recomendadas para remover usuários, revisar eventos de auditoria e integrar com a ID do Microsoft Entra.

Remover usuários

  • Remover usuários inativos das contas MSA:
  • Desabilite ou exclua contas de usuário do Microsoft Entra:
    • Se sua organização estiver conectada à ID do Microsoft Entra, você poderá desabilitar ou excluir a conta de usuário do Microsoft Entra enquanto mantém a conta de usuário do Azure DevOps ativa.
    • Essa abordagem permite que você continue consultando o histórico do item de trabalho usando sua ID de usuário do Azure DevOps.
  • Revogar PATs do usuário:
    • Revise e revogue regularmente todos os PATs de usuário existentes.
    • Os PATs são tokens de autenticação críticos e gerenciá-los com segurança é essencial.
  • Revogue permissões especiais concedidas a usuários individuais:
    • Audite e revogue todas as permissões especiais concedidas a contas de usuário individuais.
    • Certifique-se de que as permissões estejam alinhadas com o princípio do privilégio mínimo.
  • Reatribuir trabalho de usuários removidos:
    • Antes de remover usuários, reatribua todos os itens de trabalho que eles estavam manipulando.
    • Distribua a carga de trabalho entre os membros atuais da equipe.

Usar a ID do Microsoft Entra

  • Plano único para identidade:
    • Ao conectar o Azure DevOps à ID do Microsoft Entra, você estabelece um sistema de identidade unificado.
    • A consistência entre os serviços reduz a confusão e minimiza os riscos de segurança decorrentes de erros de configuração manual.
  • Governança de ponta a ponta:
    • Aproveitar a ID do Microsoft Entra permite que você implemente uma governança refinada.
    • Atribua diferentes funções e permissões a grupos específicos do Microsoft Entra em vários escopos de recursos.
    • Essa abordagem garante acesso controlado e se alinha às melhores práticas de segurança.
  • Características de segurança:
    • O Microsoft Entra ID habilita recursos de segurança adicionais, como:
      • Autenticação multifator (MFA): aprimore a autenticação do usuário exigindo vários fatores (por exemplo, verificação de senha e telefone).
      • Políticas de acesso condicional: defina regras de acesso com base em condições (por exemplo, local, dispositivo ou nível de risco).

Para obter mais informações, consulte os seguintes artigos:

Examinar eventos de auditoria

Depois que sua organização tiver o suporte do Microsoft Entra, execute as seguintes tarefas para aprimorar a segurança e monitorar os padrões de uso:

  • Habilitar auditoria:
    • Em suas políticas de segurança, habilite a auditoria.
    • A auditoria ajuda a rastrear e registrar eventos relacionados a ações, permissões e alterações do usuário.
  • Revise regularmente os eventos de auditoria:
    • Revise o log de auditoria periodicamente.
    • Procure padrões de uso inesperados, especialmente por administradores e outros usuários.

Proteger suas redes

As funções a seguir são maneiras eficazes de aprimorar a segurança da rede quando você está trabalhando com o Azure DevOps.

  • Lista de permissões de IP:
    • Configure uma lista de permissões para restringir o acesso a endereços IP específicos.
    • Permita apenas o tráfego de fontes confiáveis, reduzindo a superfície de ataque.
  • Criptografia:
    • Sempre use criptografia para dados em trânsito e em repouso.
    • Proteja os canais de comunicação usando protocolos como HTTPS.
  • Validação do certificado:
    • Valide certificados ao estabelecer conexões.
    • Certifique-se de que os certificados sejam válidos e emitidos por autoridades confiáveis.
  • Firewalls de aplicativos Web (WAFs):
    • Implemente WAFs para filtrar, monitorar e bloquear tráfego malicioso baseado na Web.
    • Os WAFs fornecem uma camada adicional de proteção contra ataques comuns.

Para obter mais informações, consulte Práticas recomendadas de gerenciamento de aplicativos.

Permissões com escopo

O sistema lida com permissões em vários níveis — individual, coleção, projeto e objeto — e as atribui a um ou mais grupos internos por padrão. Para aumentar a segurança, execute as seguintes ações:

  • Forneça acesso mínimo: Dê aos usuários e serviços o acesso mínimo necessário para executar suas funções de negócios.
  • Desativar herança:
    • Sempre que possível, desative a herança.
    • A herança pode conceder inadvertidamente acesso ou permissões a usuários inesperados devido à sua natureza de permissão por padrão.
    • Para obter mais informações, consulte a seção sobre herança de permissão

Para obter mais informações sobre permissões, consulte os seguintes artigos:

Permissões no nível de projeto

  • Limitar o acesso a projetos e repositórios:
    • Para reduzir o risco de vazamento de informações confidenciais e implantação de código inseguro na produção, limite o acesso a projetos e repositórios.
    • Use os grupos de segurança internos ou grupos de segurança personalizados para gerenciar permissões. Para obter mais informações, consulte Conceder ou restringir permissões a tarefas específicas.
  • Desative "Permitir projetos públicos":
    • Nas configurações de política da sua organização, desabilite a opção de criar projetos públicos.
    • Azure DevOps Services permite que você alterne a visibilidade do projeto de pública para privada (e vice-versa).
    • Os usuários que não entraram em sua organização têm acesso somente leitura a projetos públicos.
    • Os usuários conectados podem ter acesso a projetos privados e fazer alterações permitidas.
  • Restringir a criação de projetos:
    • Impedir que os usuários criem novos projetos para manter o controle sobre seu ambiente.

Acesso de convidado externo

  • Bloquear o acesso de convidados externos:
  • Use um email ou UPN diferente para suas contas pessoais e comerciais:
    • Mesmo que seja permitido, use endereços de email distintos ou UPNs (nomes UPNs) para contas pessoais e comerciais.
    • Essa prática elimina a ambiguidade ao desambiguar entre suas contas pessoais e relacionadas ao trabalho.
  • Agrupar usuários convidados externos:
    • Coloque todos os usuários convidados externos em um único grupo do Microsoft Entra.
    • Gerencie as permissões para esse grupo adequadamente.
    • Remova as atribuições diretas para garantir que as regras do grupo se apliquem a esses usuários. Para obter mais informações, consulte Adicionar uma regra de grupo para atribuir níveis de acesso.
    • Reavalie regularmente as regras na guia Regras de grupo da página Usuários. Considere quaisquer alterações de associação de grupo na ID do Microsoft Entra que possam afetar sua organização. A ID do Microsoft Entra pode levar até 24 horas para atualizar a associação de grupo dinâmico. As regras são reavaliadas automaticamente a cada 24 horas e sempre que uma regra de grupo é alterada.

Para obter mais informações, consulte Convidados B2B na ID do Microsoft Entra.

Gerenciar grupos de segurança

Segurança e grupos de usuários

A tabela a seguir mostra recomendações para atribuir permissões a grupos de segurança e grupos de usuários.

Fazer Não
Use a ID do Microsoft Entra, o Active Directory ou os grupos de segurança do Windows ao gerenciar muitos usuários. Não altere as permissões padrão para o grupo Usuários Válidos do Projeto . Esse grupo pode acessar e exibir informações do projeto.
Ao adicionar equipes, considere quais permissões você deseja atribuir aos membros da equipe que precisam criar e modificar caminhos de área, caminhos de iteração e consultas. Não adicione usuários a vários grupos de segurança que contenham níveis de permissão diferentes. Em determinados casos, um nível de permissão Negar pode substituir um nível de permissão Permitir .
Ao adicionar muitas equipes, considere criar um grupo personalizado administradores de equipe em que você aloca um subconjunto das permissões disponíveis para administradores de projeto. Não altere as atribuições padrão feitas para os grupos Usuários Válidos do Projeto . Se você remover ou definir Exibir informações no nível da instância como Negar para um dos grupos Usuários Válidos do Projeto , nenhum usuário no grupo poderá acessar qualquer projeto, coleção ou implantação em que você defina a permissão.
Considere conceder às pastas de consulta do item de trabalho permissão contribuir para usuários ou grupos que exigem a capacidade de criar e compartilhar consultas de item de trabalho para o projeto. Não atribua permissões que são indicadas como Atribuir somente a contas de serviço a contas de usuário.
Mantenha os grupos o menor possível. O acesso deve ser restrito e os grupos devem ser auditados com frequência.
Aproveite as funções internas e o padrão de colaborador para os desenvolvedores. Os administradores são atribuídos ao grupo de segurança administrador de projeto para permissões elevadas, permitindo que eles configurem permissões de segurança.

Para obter mais informações, consulte Grupos de usuários válidos.

Acesso just-in-time para grupos de administradores

Se você tiver acesso de Administrador de Coleção de Projetos e Administrador de Projeto , poderá modificar a configuração de sua organização ou projeto. Para aprimorar a segurança desses grupos de administradores internos, considere implementar o acesso just-in-time usando um grupo do Microsoft Entra Privileged Identity Management (PIM). Essa abordagem permite que você conceda permissões elevadas somente quando necessário, reduzindo o risco associado ao acesso permanente.

Configurar o acesso

  1. Crie um grupo atribuível à função na ID do Microsoft Entra.
  2. Adicione seu grupo do Microsoft Entra ao grupo do Azure DevOps.

Observação

Ao configurar o acesso just-in-time usando um grupo do Microsoft Entra Privileged Identity Management (PIM), certifique-se de que qualquer usuário com acesso elevado também mantenha o acesso padrão à organização. Dessa forma, eles podem visualizar as páginas necessárias e atualizar suas permissões conforme necessário.

Usar acesso

  1. Ative seu acesso.
  2. Atualize suas permissões no Azure DevOps.
  3. Execute a ação que requer acesso de administrador.

Observação

Os usuários têm acesso elevado no Azure DevOps por até 1 hora após a desativação do acesso ao grupo PIM.

Contas de serviço de escopo

  • Entender as contas de serviço
  • Crie contas de serviço de finalidade única:
    • Cada serviço deve ter sua conta dedicada para minimizar o risco.
    • Evite usar contas de usuário regulares como contas de serviço.
  • Siga as convenções de nomenclatura e documentação:
    • Use nomes claros e descritivos para contas de serviço.
    • Documente sua finalidade e serviços associados.
  • Identifique e desabilite contas de serviço não utilizadas:
    • Revise e identifique regularmente as contas que não estão mais em uso.
    • Desative as contas não utilizadas antes de considerar a exclusão.
  • Restringir privilégios:
    • Limite os privilégios da conta de serviço ao mínimo necessário.
    • Evite direitos de entrada interativos para contas de serviço.
  • Use identidades separadas para leitores de relatório:
    • Se você estiver usando contas de domínio para contas de serviço, use uma identidade diferente para leitores de relatório.
    • Isole as permissões para evitar acesso desnecessário. Para obter mais informações, consulte Contas de serviço e dependências.
  • Use contas locais para instalações de grupos de trabalho:
    • Ao instalar componentes em um grupo de trabalho, use contas locais para contas de usuário.
    • Evite contas de domínio neste cenário. Para obter mais informações, consulte Requisitos da conta de serviço.
  • Aproveite as conexões de serviço:
    • Use conexões de serviço sempre que possível.
    • Eles fornecem uma maneira segura de se conectar a serviços sem passar variáveis secretas diretamente para compilações.
    • Restrinja as conexões a casos de uso específicos.
  • Monitore a atividade da conta de serviço:
    • Implemente a auditoria e crie fluxos de auditoria.

Para obter mais informações, consulte Tipos comuns de conexão de serviço.

Conexões de serviço de escopo

  • Escopo das conexões de serviço do Azure Resource Manager :
    • Para limitar o acesso, defina o escopo de suas conexões de serviço para recursos e grupos específicos. Evite conceder amplos direitos de colaborador em toda a assinatura do Azure.
    • Use a federação de identidade de carga de trabalho para autenticação. Isso permite conexões de serviço sem segredo no Azure Pipelines.
  • Use a federação de identidade de carga de trabalho:
    • A federação de identidade de carga de trabalho usa o OIDC (OpenID Connect) para autenticar com recursos do Azure sem usar segredos.
    • Você pode criar a federação de identidade de carga de trabalho automática ou manualmente. Considere essa abordagem se:
      • Você tem a função Proprietário para sua assinatura do Azure.
      • Você não está se conectando a ambientes do Azure Stack ou do Azure US Government.
      • Todas as tarefas de extensões do Marketplace que você usa dão suporte à federação de identidades de carga de trabalho1.
  • Escopo do grupo de recursos:
    • Verifique se o grupo de recursos contém apenas as VMs (Máquinas Virtuais) ou os recursos necessários para o processo de compilação.
  • Evite conexões de serviço clássico do Azure:
    • As conexões de serviço clássicas não têm opções de escopo. Em vez disso, opte por conexões de serviço modernas do Azure Resource Manager.
  • Use contas de serviço de equipe específicas para a finalidade:
    • Autentique conexões de serviço usando contas de serviço de equipe específicas para manter a segurança e o controle.

Para obter mais informações, consulte Tipos comuns de conexão de serviço.

Escolher o método de autenticação correto

Selecione seus métodos de autenticação nas seguintes fontes:

Considerar entidades de serviço

Explore alternativas como entidades de serviço e identidades gerenciadas:

  • Entidades de serviço:
    • Representar objetos de segurança em um aplicativo do Microsoft Entra.
    • Defina o que um aplicativo pode fazer em um determinado locatário.
    • Configure durante o registro do aplicativo no portal do Azure.
    • Configurado para acessar recursos do Azure, incluindo o Azure DevOps.
    • Útil para aplicativos que precisam de acesso e controle específicos.
  • Identidades gerenciadas:
    • Semelhante à entidade de serviço de um aplicativo.
    • Forneça identidades para recursos do Azure.
    • Permitir que os serviços que dão suporte à autenticação do Microsoft Entra compartilhem credenciais.
    • O Azure lida com o gerenciamento e a rotação de credenciais automaticamente.
    • Ideal quando você deseja um gerenciamento contínuo de detalhes de login.

Usar PATs com moderação

  • Defina o escopo dos PATs para funções específicas:
    • Atribua aos PATs apenas as permissões necessárias para tarefas específicas. Evite conceder acesso global a várias organizações ou repositórios.
    • O escopo dos PATs garante que eles tenham os privilégios mínimos necessários, reduzindo o risco de uso indevido acidental.
  • Evite permissões de gravação ou gerenciamento em builds e versões:
    • Os PATs não devem ter permissões de gravação ou gerenciamento em builds, versões ou outros recursos críticos.
    • Restringir essas permissões ajuda a evitar ações não intencionais que podem afetar seus pipelines ou implantações.
  • Defina datas de validade e mantenha os PATs em segredo:
    • Sempre defina uma data de expiração para PATs. Revise-os e renove-os regularmente conforme necessário.
    • Trate os PATs tão críticos quanto as senhas. Mantenha-os confidenciais e evite compartilhá-los publicamente ou codificá-los no código do aplicativo.
  • Evite codificar PATs no código do aplicativo:
    • Embora possa parecer conveniente, evite incorporar PATs diretamente em seu código.
    • Em vez disso, use arquivos de configuração seguros ou variáveis de ambiente para armazenar e recuperar PATs dinamicamente.
  • Audite e revogue regularmente PATs não utilizados:
    • Os administradores devem revisar periodicamente todos os PATs usando as APIs REST.
    • Revogue todos os PATs que não são mais necessários ou não atendem aos critérios recomendados.

Para obter mais informações, marcar os seguintes artigos:

Proteger o Azure Artifacts

Proteger Azure Boards

Proteger o Azure Pipelines

Políticas

  • Exigir revisores fora do solicitante original:
    • Ter pelo menos um revisor fora do solicitante original garante um processo de revisão mais completo.
    • O aprovador compartilha a copropriedade das alterações e deve ser igualmente responsabilizado por qualquer impacto potencial.
  • Exigir que a compilação de CI seja aprovada:
    • Exigir que o build de CI (Integração Contínua) seja aprovado antes de mesclar uma PR estabelece uma linha de base para a qualidade do código.
    • As verificações de CI incluem linting de código, testes de unidade e verificações de segurança (por exemplo, verificações de vírus e credenciais).
  • Não permitir a autoaprovação do solicitante original:
    • Impedir que o solicitante de PR original aprove suas próprias alterações.
    • Essa ação garante um processo de revisão imparcial e evita possíveis conflitos de interesse.
  • Não permitir a conclusão de PR mesmo com votos de "esperar" ou "rejeitar":
    • Mesmo que alguns revisores votem para esperar ou rejeitar, impeça a conclusão do PR.
    • Esta ação incentiva a abordagem de todos os comentários antes da fusão.
  • Redefinir os votos do revisor de código nas alterações enviadas:
    • Quando as alterações recentes forem enviadas para o PR, redefina os votos dos revisores.
    • Essa ação garante que os revisores reavaliem o código atualizado.
  • Bloqueie pipelines de lançamento para ramificações de produção específicas:
    • Limite os pipelines de lançamento a ramificações específicas (geralmente produção ou principal).
    • Evite implantações acidentais de outras ramificações.
  • Impor variáveis configuráveis no momento da fila:
    • Ative a opção "Impor configurável no tempo da fila" para variáveis de pipeline.
    • Essa ação impede que os usuários substituam valores de variáveis durante a execução do pipeline.
  • Não permitir substituições de variáveis no editor:
    • Para variáveis definidas no editor de pipeline, não permita substituições de usuário.
    • Essa ação mantém a consistência e evita alterações não intencionais.

Agentes

  • Conceda permissões com moderação:
    • Limite as permissões ao menor conjunto necessário de contas.
    • Evite acessos excessivamente permissivos, reduzindo a superfície de ataque.
  • Firewalls restritivos para agentes utilizáveis:
    • Configure os firewalls para serem o mais restritivos possível e, ao mesmo tempo, permitir que os agentes funcionem.
    • Encontre um equilíbrio entre segurança e usabilidade.
  • Atualize regularmente os pools de agentes:
    • Mantenha sua frota de agentes atualizada atualizando regularmente os agentes.
    • Essa ação garante que o código vulnerável não esteja em execução, reduzindo o risco de exploração.
  • Pool de agentes separado para artefatos de produção:
    • Use um pool de agentes distinto para criar artefatos destinados à produção.
    • Isolar artefatos de produção ajuda a evitar implantações acidentais de ramificações que não são de produção.
  • Pools sensíveis a segmentos:
    • Crie pools separados para cargas de trabalho confidenciais e não confidenciais.
    • Permitir apenas credenciais em definições de compilação associadas ao pool apropriado.

Definições

  • Use YAML para definições de pipeline:
    • YAML (Yet Another Markup Language) é a abordagem recomendada para definir pipelines.
    • Ele oferece rastreabilidade para alterações, facilitando o rastreamento de modificações ao longo do tempo.
    • Além disso, os pipelines YAML podem aderir às diretrizes de aprovação e às práticas de controle de versão.
  • Restrinja o acesso de edição às definições de pipeline:
    • Limite o acesso à edição de definições de pipeline às contas mínimas necessárias.
    • Ao fazer isso, você reduz o risco de alterações acidentais ou não autorizadas.

Entrada

  • Inclua verificações de sanidade para variáveis em scripts de compilação:
    • Implemente verificações de integridade em seus scripts de compilação para mitigar possíveis ataques de injeção de comando por meio de variáveis configuráveis.
    • Essas verificações podem validar valores de entrada e evitar comandos não intencionais ou mal-intencionados.
  • Limite o número de variáveis de compilação "configuráveis no momento do lançamento":
    • Defina o menor número possível de variáveis de compilação para serem "configuráveis no momento do lançamento".
    • Minimizar o número dessas variáveis reduz a superfície de ataque e simplifica o gerenciamento de configuração.

Tarefas

  • Evite recursos buscados remotamente:
    • Sempre que possível, evite buscar recursos de URLs externas durante o processo de compilação.
    • Se recursos remotos forem necessários, use controle de versão e verificação de hash para garantir a integridade.
  • Evite registrar segredos:
    • Nunca registre informações confidenciais, como segredos ou credenciais, em seus logs de compilação.
    • Os segredos de registro podem expô-los involuntariamente e comprometer a segurança.
  • Use o Azure Key Vault para segredos:
    • Em vez de armazenar segredos diretamente em variáveis de pipeline, use o Azure Key Vault.
    • O Key Vault fornece uma maneira segura de gerenciar e recuperar segredos centralmente.
  • Restrinja as compilações em execução em relação a ramificações ou tags arbitrárias:
    • Para pipelines críticos de segurança, limite os usuários de executar builds em qualquer branch ou marca.
    • Defina ramificações ou tags autorizadas específicas para evitar execuções acidentais ou não autorizadas.
  • Desative a herança para permissões de pipeline:
    • As permissões herdadas podem ser excessivamente amplas e podem não refletir com precisão suas necessidades.
    • Desative a herança e defina permissões explicitamente para se alinhar aos seus requisitos de segurança.
  • Limitar escopos de autorização de trabalho:
    • Sempre restrinja os escopos de autorização de trabalho ao mínimo necessário.
    • Ajuste as permissões com base nas tarefas específicas executadas por cada trabalho.

Repositórios e branches

  • Exigir um número mínimo de revisores:
    • Habilite a política "Exigir um número mínimo de revisores" para garantir que cada solicitação de pull receba revisões de pelo menos dois aprovadores.
    • Isso promove a revisão completa do código e a responsabilidade.
  • Configure políticas de segurança específicas do repositório:
    • Em vez de políticas para todo o projeto, adapte as políticas de segurança a cada repositório ou ramificação.
    • Políticas personalizadas reduzem riscos, impõem padrões de gerenciamento de mudanças e melhoram a qualidade do código.
  • Isole os segredos de produção em um cofre de chaves separado:
    • Armazene segredos de produção separadamente em um Azure Key Vault.
    • Limite o acesso a uma base de necessidade de conhecimento para manter a separação de compilações que não são de produção.
  • Separe os ambientes de teste da produção:
    • Evite misturar ambientes de teste com produção.
    • Certifique-se de que as credenciais e os segredos não sejam usados em contextos de não produção.
  • Desativar bifurcação:
    • Desabilitar a bifurcação ajuda a gerenciar a segurança.
    • Os forks podem proliferar, dificultando o rastreamento da segurança em todas as cópias.
  • Evite fornecer segredos para compilações de bifurcação:
    • Evite compartilhar segredos com compilações bifurcadas.
    • Os segredos devem permanecer confidenciais e não devem ser expostos a bifurcações.
  • Considere acionar manualmente builds de bifurcação:
    • Acione manualmente builds para bifurcações em vez de permitir gatilhos automáticos.
    • Isso fornece melhor controle sobre as verificações de segurança.
  • Use agentes hospedados pela Microsoft para builds de bifurcação:
    • Aproveite os agentes hospedados pela Microsoft para builds bifurcados.
    • Esses agentes são mantidos e seguros.
  • Verificar definições de compilação de produção em repositórios Git:
    • Verifique regularmente as definições de compilação de produção armazenadas no repositório Git do seu projeto.
    • Procure credenciais ou informações confidenciais.
  • Configure verificações de controle de ramificação para o contexto de produção:
    • Configure verificações de controle de ramificação para restringir o uso de conexões confidenciais (por exemplo, prod-connection) a pipelines em execução no contexto da ramificação de produção.
    • Isso garante a autorização adequada e evita o uso indevido acidental.

Para obter mais informações, consulte Outras considerações de segurança.

Proteger Azure Repos

Proteger Azure Test Plans

Proteger integrações do GitHub

  • Use o fluxo OAuth em vez de PATs:
    • Desabilite a autenticação baseada em PAT para conexões de serviço do GitHub.
    • Opte pelo fluxo OAuth, que oferece melhor segurança e integração.
  • Evite identidades de administrador ou proprietário:
    • Nunca autentique conexões de serviço do GitHub usando uma identidade que seja um administrador ou proprietário de qualquer repositório.
    • Limite as permissões ao nível necessário.
  • Evite PATs GitHub de escopo completo:
    • Evite usar um GitHub PAT de escopo completo para autenticar conexões de serviço.
    • Use tokens com as permissões mínimas necessárias.
  • Evite contas pessoais do GitHub como conexões de serviço:
    • Não use contas pessoais do GitHub como conexões de serviço no Azure DevOps.
    • Em vez disso, crie contas de serviço dedicadas ou use contas no nível da organização.