Compartilhar via

Sobre segurança, autenticação e autorização

  • Artigo

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

O Azure DevOps emprega vários conceitos de segurança para garantir que somente usuários autorizados possam acessar recursos, funções e dados. Os usuários obtêm acesso ao Azure DevOps por meio da autenticação de suas credenciais de segurança e da autorização de seus direitos de conta para acessar recursos ou funções específicas.

Este artigo baseia-se nas informações fornecidas em Introdução a permissões, acesso e grupos de segurança. Os administradores podem se beneficiar da compreensão dos tipos de conta, métodos de autenticação, métodos de autorização e políticas usadas para proteger o Azure DevOps.

Tipos de conta

  • Usuários
  • Proprietário da organização
  • Contas de serviço
  • Entidades de serviço ou identidades gerenciadas
  • Agentes de trabalho

Autenticação

  • Credenciais de usuário
  • Autenticação do Windows
  • 2FA (Autenticação de Dois Fatores)
  • Autenticação de chave SSH
  • Tokens de acesso pessoal
  • Configuração do Oauth
  • Biblioteca de autenticação do Active Directory

Autorização

  • Associação a um grupo de segurança
  • Controle de acesso baseado em função
  • Níveis de acesso
  • Sinalizadores de recurso
  • Namespaces e permissões de segurança

Políticas

  • URL da política de privacidade
  • Conexão de aplicativo e políticas de segurança
  • Políticas de usuário
  • Políticas de repositório e branch do Git

Tipos de conta

  • Usuários
  • Contas de serviço
  • Entidades de serviço ou identidades gerenciadas
  • Agentes de trabalho

Autenticação

  • Credenciais de usuário
  • Autenticação do Windows
  • 2FA (Autenticação de Dois Fatores)
  • Autenticação de chave SSH
  • Tokens de acesso pessoal
  • Configuração do Oauth
  • Biblioteca de autenticação do Active Directory

Autorização

  • Associação a um grupo de segurança
  • Permissões baseadas em função
  • Níveis de acesso
  • Sinalizadores de recurso
  • Namespaces e permissões de segurança

Políticas

  • Políticas de repositório e branch do Git

Importante

O Azure DevOps não dá suporte à autenticação de credenciais alternativas. Se você ainda estiver usando credenciais alternativas, recomendamos que você mude para um método de autenticação mais seguro.

Azure DevOps Services (nuvem) e Azure DevOps Server (local) dão suporte ao desenvolvimento de software desde o planejamento até a implantação. Eles aproveitam a infraestrutura e os serviços de plataforma como serviço do Microsoft Azure, incluindo bancos de dados SQL do Azure, para fornecer um serviço confiável e disponível globalmente para seus projetos.

Para obter mais informações sobre como a Microsoft garante que seus projetos Azure DevOps Services sejam seguros, disponíveis, protegidos e privados, consulte a visão geral da proteção de dados do Azure DevOps Services.

Contas

Embora as contas de usuário humano sejam o foco principal, o Azure DevOps também dá suporte a vários outros tipos de conta para diferentes operações. Isso inclui os seguintes tipos de conta:

  • Proprietário da organização: o criador de uma organização Azure DevOps Services ou proprietário atribuído. Para localizar o proprietário da sua organização, consulte Pesquisar o proprietário da organização.
  • Contas de serviço: organização interna do Azure DevOps usada para dar suporte a um serviço específico, como o Serviço de Pool de Agentes, PipelinesSDK. Para obter descrições de contas de serviço, consulte Grupos de segurança, contas de serviço e permissões.
  • Entidades de serviço ou identidades gerenciadas: aplicativos do Microsoft Entra ou identidades gerenciadas adicionadas à sua organização para executar ações em nome de um aplicativo de terceiros. Algumas entidades de serviço referem-se à organização interna do Azure DevOps para dar suporte a operações internas.
  • Agentes de trabalho: contas internas usadas para executar trabalhos específicos em um agendamento regular.
  • Contas de terceiros: contas que exigem acesso para dar suporte a ganchos da Web, conexões de serviço ou outros aplicativos de terceiros.

Em nossos artigos relacionados à segurança, "usuários" refere-se a todas as identidades adicionadas ao Hub de Usuários, que podem incluir usuários humanos e entidades de serviço.

  • Contas de serviço: organização interna do Azure DevOps usada para dar suporte a um serviço específico, como o Serviço de Pool de Agentes, PipelinesSDK. Para obter descrições de contas de serviço, consulte Grupos de segurança, contas de serviço e permissões.
  • Entidades de serviço ou identidades gerenciadas: aplicativos do Microsoft Entra ou identidades gerenciadas adicionadas à sua organização para executar ações em nome de um aplicativo de terceiros. Algumas entidades de serviço referem-se à organização interna do Azure DevOps para dar suporte a operações internas.
  • Agentes de trabalho: contas internas usadas para executar trabalhos específicos em um agendamento regular.
  • Contas de terceiros: contas que exigem acesso para dar suporte a ganchos da Web, conexões de serviço ou outros aplicativos de terceiros.

A maneira mais eficaz de gerenciar contas é adicionando-as a grupos de segurança.

Observação

O proprietário da organização e os membros do grupo Administradores de Coleção de Projetos recebem acesso total a quase todos os recursos e funções.

Autenticação

A autenticação verifica a identidade de uma conta com base nas credenciais fornecidas durante a entrada no Azure DevOps. Esses sistemas se integram e contam com os recursos de segurança dos seguintes outros sistemas:

  • ID do Microsoft Entra
  • MSA (conta Microsoft)
  • AD (Active Directory)

A ID do Microsoft Entra e a MSA dão suporte à autenticação de nuvem. Recomendamos usar a ID do Microsoft Entra para gerenciar um grande grupo de usuários. Para uma pequena base de usuários que acessa sua organização do Azure DevOps, as contas da Microsoft são suficientes. Para obter mais informações, consulte Sobre como acessar o Azure DevOps com a ID do Microsoft Entra.

Para implantações locais, o AD é recomendado para gerenciar um grande grupo de usuários. Para obter mais informações, consulte Configurar grupos para uso em implantações locais.

Métodos de autenticação, integração com outros serviços e aplicativos

Outros aplicativos e serviços podem se integrar ao Azure DevOps. Para acessar sua conta sem solicitar repetidamente as credenciais do usuário, os aplicativos podem usar os seguintes métodos de autenticação:

  • Tokens de acesso pessoal (PATs) para gerar tokens em seu nome para:

    • Acessar recursos ou atividades específicas, como builds ou itens de trabalho
    • Clientes como Xcode e NuGet que exigem nomes de usuário e senhas como credenciais básicas e não são compatíveis com a conta Microsoft e os recursos do Microsoft Entra, como autenticação multifator
    • Acessando APIs REST do Azure DevOps

  • Azure DevOps OAuth para gerar tokens em nome dos usuários para acessar APIs REST. As APIs Contas e Perfis suportam apenas OAuth.

  • Autenticação SSH para gerar chaves de criptografia para si mesmo quando você usa Linux, macOS ou Windows executando o Git para Windows e não pode usar gerenciadores de credenciais do Git ou PATs para autenticação HTTPS.

  • Entidades de serviço ou identidades gerenciadas para gerar tokens do Microsoft Entra em nome de um aplicativo ou serviço, normalmente automatizando fluxos de trabalho que precisam acessar recursos do Azure DevOps. A maioria das ações tradicionalmente executadas por uma conta de serviço e um PAT pode ser feita usando uma entidade de serviço ou identidade gerenciada.

Por padrão, sua conta ou coleção permite o acesso para todos os métodos de autenticação. Você pode limitar o acesso restringindo especificamente cada método. Quando você nega o acesso a um método de autenticação, nenhum aplicativo pode usar esse método para acessar sua conta. Qualquer aplicativo que tinha acesso anteriormente recebe um erro de autenticação e não pode acessar sua conta.

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

Autorização

A autorização verifica se a identidade que está tentando se conectar tem as permissões necessárias para acessar um serviço, um recurso, uma função, um objeto ou um método. A autorização sempre ocorre após a autenticação bem-sucedida. Se uma conexão não for autenticada, ela falhará antes que qualquer verificação de autorização seja executada. Mesmo que a autenticação seja bem-sucedida, uma ação específica ainda poderá não ser permitida se o usuário ou grupo não tiver autorização.

A autorização depende das permissões atribuídas ao usuário, diretamente ou por meio da associação a um grupo de segurança ou direito de acesso. Os níveis de acesso e os sinalizadores de recursos também podem gerenciar o acesso a recursos específicos. Para obter mais informações sobre esses métodos de autorização, consulte Introdução a permissões, acesso e grupos de segurança.

Namespaces e permissões de segurança

Os namespaces de segurança determinam os níveis de acesso do usuário para ações específicas em recursos.

  • Cada família de recursos, como itens de trabalho ou repositórios Git, tem um namespace exclusivo.
  • Cada namespace contém zero ou mais listas de controle de acesso (ACLs).
    • Cada ACL inclui um token, um sinalizador de herança e entradas de controle de acesso (ACEs).
    • Cada ACE tem um descritor de identidade, uma máscara de bits de permissões permitidas e uma máscara de bits de permissões negadas.

Para obter mais informações, consulte Namespaces de segurança e referência de permissão.

Políticas de segurança

Para proteger sua organização e código, você pode definir várias políticas. Especificamente, você pode habilitar ou desabilitar as seguintes políticas:

Geral

Conexão de aplicativo e políticas de segurança

Use a política de locatário do Microsoft Entra para restringir a criação de novas organizações somente aos usuários desejados. Essa política é desativada por padrão e válida apenas quando a organização está conectada à ID do Microsoft Entra. Para obter mais informações, consulte Restringir a criação da organização.

As seguintes políticas determinam o acesso concedido a usuários e aplicativos em suas organizações:

Políticas de usuário

  • Acesso de convidado externo (válido somente quando a organização está conectada à ID do Microsoft Entra.): Quando habilitado, os convites podem ser enviados para contas de email de usuários que não são membros da ID do Microsoft Entra do locatário por meio da página Usuários . Para obter mais informações, consulte Adicionar usuários externos à sua organização.
  • Permitir que os administradores de equipe e projeto convidem novos usuários: válido somente quando a organização está conectada à ID do Microsoft Entra. Quando ativado, os administradores de equipe e projeto podem adicionar usuários por meio da página Usuários . Para obter mais informações, consulte Restringir novos convites de usuários do Project e administradores de equipe.
  • Solicitar acesso: válido somente quando a organização está conectada à ID do Microsoft Entra. Quando habilitado, os usuários podem solicitar acesso a um recurso. Uma solicitação resulta em uma notificação por email para os administradores solicitando revisão e acesso, conforme necessário. Para obter mais informações, consulte Adicionar usuários externos à sua organização.
  • Convidar usuários do GitHub: válido somente quando a organização não está conectada à ID do Microsoft Entra. Quando habilitado, os administradores podem adicionar usuários com base em suas contas de usuário do GitHub na página Usuários . Para obter mais informações, consulte Conectar-se ao GitHub/FAQs.

grupo Usuários do Project-Scoped

Por padrão, os usuários adicionados a uma organização podem visualizar todas as informações e configurações da organização e do projeto, incluindo listas de usuários, listas de projetos, detalhes de cobrança, dados de uso e muito mais.

Importante

  • Os recursos de visibilidade limitados descritos nesta seção se aplicam apenas a interações por meio do portal da Web. Com as APIs REST ou azure devops comandos da CLI, os membros do projeto podem acessar os dados restritos.
  • Os usuários convidados que são membros do grupo limitado com acesso padrão na ID do Microsoft Entra não podem pesquisar usuários com o seletor de pessoas. Quando o recurso de visualização está desativado para a organização ou quando os usuários convidados não são membros do grupo limitado, os usuários convidados podem pesquisar todos os usuários do Microsoft Entra, conforme esperado.

Para restringir determinados usuários, como Stakeholders, usuários convidados do Microsoft Entra ou membros de um grupo de segurança específico, você pode habilitar o recurso Limitar a visibilidade e a colaboração do usuário a projetos específicos para a organização. Depois que isso estiver habilitado, qualquer usuário ou grupo adicionado ao grupo Usuários com Escopo do Projeto será restrito das seguintes maneiras:

  • Só pode acessar as páginas Visão geral e Projetos das configurações da organização.
  • Só pode se conectar e exibir os projetos aos quais eles foram adicionados explicitamente.
  • Só pode selecionar identidades de usuário e grupo adicionadas explicitamente ao projeto ao qual estão conectados.

Para obter mais informações, consulte Gerenciar sua organização, Limitar a visibilidade do usuário para projetos e muito mais e Gerenciar recursos de visualização.

Aviso

Habilitar o recurso Limitar a visibilidade e a colaboração do usuário a projetos específicos impede que os usuários com escopo de projeto pesquisem usuários adicionados à organização por meio da associação de grupo do Microsoft Entra, em vez de por meio de um convite de usuário explícito. Esse é um comportamento inesperado e uma resolução está em andamento. Para resolver esse problema, desative o recurso de visualização Limitar a visibilidade e a colaboração do usuário a projetos específicos para a organização.

Repositório Git e políticas de branch

Para proteger seu código, você pode definir várias políticas de branch e repositório Git. Para obter mais informações, consulte os artigos a seguir.

segurança do Azure Repos e do Azure Pipelines

Como repositórios e pipelines de build e lançamento apresentam desafios de segurança exclusivos, recursos adicionais além dos recursos discutidos neste artigo são empregados. Para obter mais informações, consulte os artigos a seguir.

Próximas etapas

Referência de permissões e grupos