Controle de acesso baseado em função para ferramentas de DevOps
Quando você implanta soluções baseadas em nuvem para suas implantações de infraestrutura, a segurança sempre deve ser sua preocupação mais importante. A Microsoft mantém a infraestrutura de nuvem subjacente segura. Você configura a segurança no Azure DevOps ou no GitHub.
Pré-requisitos
Depois de decidir quais modelos da zona de destino do Azure serão implantados, clone-os no seu próprio repositório. Configure os pipelines de CI/CD. Para o GitHub e o Azure DevOps, há vários métodos de autenticação disponíveis, como tokens de acesso pessoal (PAT) e integração com um provedor de identidade, como o Microsoft Entra ID. Para obter mais informações, confira Usar tokens de acesso pessoal.
Recomendamos que você se integre ao Microsoft Entra ID para usar todos os seus recursos. A integração ajuda a simplificar o processo de atribuição de função e o gerenciamento do ciclo de vida de identidades. Para obter mais informações, consulte Conectar sua organização ao Microsoft Entra ID. Se você estiver usando o GitHub, considere integrar o GitHub Enterprise com o Microsoft Entra ID.
Considerações gerais sobre design
Recomendamos que você mantenha um controle rígido de administradores e grupos de contas de serviço no Microsoft Entra ID e na sua ferramenta DevOps. Considere a implementação do princípio de privilégios mínimos em todas as suas atribuições de função.
Por exemplo, sua organização pode ter uma equipe de Plataforma ou de Excelência na Nuvem que mantém os modelos do Azure Resource Manager para suas zonas de destino do Azure. Atribua usuários dessa equipe a um Grupo de Segurança no Microsoft Entra ID, supondo que você o esteja usando como seu provedor de identidade. Atribua funções a esse grupo de segurança na sua ferramenta de DevOps para que esses usuários possam realizar os respectivos trabalhos.
Para qualquer administrador ou contas altamente privilegiadas no Active Directory, recomendamos que as credenciais não sejam sincronizadas com a ID do Microsoft Entra e vice-versa. Essa abordagem reduz a ameaça de movimento lateral. Se um administrador no Microsoft Entra ID for comprometido, o invasor não poderá acessar facilmente nenhum ativo de nuvem, como o Azure DevOps. Essa conta não pode potencialmente injetar tarefas mal-intencionadas nos pipelines de CI/CD. Essa etapa é particularmente importante para todos os usuários que receberam permissões elevadas no seu ambiente de DevOps, como administradores de build ou de projeto/coleção. Para obter mais informações, consulte Práticas recomendadas de segurança no Microsoft Entra ID.
Considerações sobre o acesso baseado em função do Azure DevOps
Gerencie a segurança no Azure DevOps com grupos de segurança, políticas e configurações no nível de organização/coleção, projeto ou objeto. Para integrar com um provedor de identidade, como o Microsoft Entra ID, considere a criação de políticas de acesso condicional para impor a autenticação multifator para todos os usuários. As políticas permitem acesso à sua organização do Azure DevOps e a restrições mais granulares em relação ao endereço IP, ao tipo de dispositivo usado para acesso e à conformidade do dispositivo.
Para a maioria dos membros da equipe de Plataforma que gerencia suas zonas de destino do Azure, o nível de acesso Básico e o grupo de segurança padrão Colaborador devem fornecer acesso suficiente. O grupo de segurança Colaborador permite que eles editem os modelos da zona de destino do Azure no seu repositório e os pipelines de CI/CD que os validam e implantam.
Recomendamos que você atribua sua equipe de Plataforma ao grupo de segurança Colaborador no nível do projeto do Azure DevOps. Essa abordagem segue o princípio de privilégios mínimos. Essas atribuições podem ser feitas por meio da página Configurações do Projeto mostrada abaixo.
Outra melhor prática para seus projetos e organizações do Azure DevOps é desabilitar a herança sempre que possível. Os usuários herdam as permissões concedidas pelas respectivas atribuições de grupo de segurança. Devido à natureza da herança de permissão por padrão, usuários inesperados podem obter acesso ou permissões.
Por exemplo, se você atribuir a associação ao grupo de segurança Colaborador da equipe de Plataforma, verifique as permissões dela no repositório de zonas de destino do Azure. Você deve ter políticas de branch em vigor para verificar se o grupo de segurança não tem permissão para ignorar essas políticas durante as solicitações de pull. Verifique essa configuração em Configurações do Projeto>Repositórios.
Depois de atribuir permissões aos usuários, revise periodicamente os eventos de auditoria para monitorar e responder aos padrões de uso inesperados por administradores e outros usuários. Comece criando um fluxo de auditoria para um workspace do Log Analytics. Se o workspace usar o Microsoft Sentinel, crie regras de análise para receber alertas sobre eventos notáveis, como o uso inadequado de permissões.
Para saber mais, consulte os recursos a seguir:
- Melhores práticas de segurança do Azure DevOps
- Grupos e permissões do Azure DevOps
- Níveis de acesso do Azure DevOps
Considerações sobre o acesso baseado em função do GitHub
Se a sua ferramenta principal de DevOps for o GitHub, você poderá atribuir aos usuários o acesso aos recursos concedendo-lhes funções no nível do repositório, da equipe ou da organização. Depois de bifurcar o repositório de Zonas de Aterrissagem do Azure e integrar com um provedor de identidade, como o Microsoft Entra ID, considere a criação de uma equipe no GitHub. Atribua a essa equipe o acesso de gravação no seu novo repositório de zonas de destino do Azure. Para a maioria dos membros da equipe de Plataforma que modifica e implanta as zonas de destino, o acesso de gravação deve ser suficiente. Para os gerentes de projeto ou os gerentes do Scrum na equipe, talvez seja necessário atribuir a eles a função de manutenção nesse repositório.
Recomendamos que você gerencie todas essas atribuições de função por meio do provedor de identidade integrado. Por exemplo, você pode sincronizar a equipe da Plataforma para o repositório da Zona de Aterrissagem do Azure que você criou no GitHub com o Grupo de Segurança da equipe da Plataforma correspondente na ID do Microsoft Entra. Em seguida, à medida que você adiciona ou remove membros do Microsoft Entra Security Group, essas alterações são refletidas em suas atribuições de função do GitHub Enterprise Cloud.
Observação
Depois de conectar uma equipe específica do GitHub a um provedor de identidade integrado, você ficará restrito a gerenciar a associação de equipe por meio dele.
Próximas etapas
Para obter mais informações sobre como gerenciar funções e equipes no GitHub, confira estes recursos: