Sobre segurança, autenticação e autorização
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. A combinação de ambos determinam o acesso do usuário a 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. Cada plataforma aproveita 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 operações diferentes:
- 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:
OAuth para gerar tokens em nome dos usuários para acessar APIs REST.
- Há dois modelos de aplicativo OAuth disponíveis: OAuth do Azure DevOps está previsto para ser preterido em 2026. Use Microsoft Entra OAuth para criar aplicativos em nome de usuários.
- Você também pode gerar tokens do Microsoft Entra para operações pontuais por conta própria, para acessar recursos como builds ou itens de trabalho ou acessar APIs REST do Azure DevOps.
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.
Tokens de acesso pessoal (PATs) para gerar tokens em seu nome. PaTs podem ser úteis para clientes como Xcode e NuGet que não dão suporte a contas ou recursos da Microsoft, como a MFA (autenticação multifator).
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.
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
- URL da política de privacidade: especifica uma URL vinculada ao seu documento personalizado que descreve como você lida com a privacidade de dados de convidado interna e externa. Para obter mais informações, consulte Adicionar uma URL de política de privacidade para sua organização.
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:
- Acesso a aplicativos que não são da Microsoft por meio do OAuth.
- Acesso à autenticação SSH.
- Permitir projetos públicos: quando habilitados, os usuários podem criar projetos públicos que permitem que não membros de um projeto e usuários que não estejam conectados somente leitura, tenham acesso limitado aos artefatos e serviços do projeto. Para obter mais informações, consulte Tornar seu projeto público.
- Eventos de auditoria de log – ative a capacidade de acompanhar eventos e fluxos de auditoria para sua organização.
- Habilite a validação da CAP (Política de Acesso Condicional) do Microsoft Entra.
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 exibir 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 de habilitado, qualquer usuário ou grupo adicionado ao grupo Project-Scoped Usuários, será restringido das seguintes maneiras:
- Só pode acessar as páginas Visão geral e Projetos das configurações da organização.
- Só é possível conectar e exibir os projetos que são 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.
Políticas de repositório e branch do Git
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, outros recursos além dos recursos discutidos neste artigo são empregados. Para obter mais informações, consulte os artigos a seguir.
- Protegendo o Azure Pipelines
- Planejar como proteger seus pipelines YAML
- Proteção do repositório
- Recursos de pipeline
- Recomendações para estruturar projetos com segurança em seu pipeline
- Segurança por meio de modelos
- Como usar variáveis e parâmetros com segurança em seu pipeline
- Recomendações para proteger a infraestrutura compartilhada no Azure Pipelines
- Outras considerações de segurança