Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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. Configure a segurança no Azure DevOps ou no GitHub.
Pré-requisitos
Depois de decidir quais modelos da Zona de Destino do Azure implantar, clone-os em 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 PAT (tokens de acesso pessoal) 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 à ID do Microsoft Entra 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 identidade. Para obter mais informações, consulte Conecte sua organização ao Microsoft Entra ID. Se você estiver usando o GitHub, considere a integração do GitHub Enterprise à ID do Microsoft Entra.
Considerações gerais sobre design
Recomendamos que você mantenha um controle rigoroso sobre administradores e grupos de contas de serviço no Microsoft Entra ID e na sua ferramenta DevOps. Considere implementar o princípio de privilégio mínimo em todas as suas atribuições de função.
Por exemplo, sua organização pode ter uma equipe de Plataforma ou Excelência em Nuvem que mantém 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ê esteja usando-o como seu provedor de identidade. Atribua funções a esse grupo de segurança em sua ferramenta DevOps para que esses usuários possam fazer seus 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 na ID do Microsoft Entra estiver comprometido, o invasor não poderá obter facilmente acesso a 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 atribuídos permissões elevadas em seu ambiente DevOps, como Administradores de Build ou Project/Collection. Para obter mais informações, consulte as práticas recomendadas de segurança na ID do Microsoft Entra.
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 se integrar a 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 o acesso à sua organização do Azure DevOps e restrições mais granulares em torno de endereço IP, tipo de dispositivo usado para acesso e conformidade do dispositivo.
Para a maioria dos membros da equipe da plataforma que gerenciam 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 do privilégio mínimo. Essas atribuições podem ser feitas por meio da página Configurações do Projeto mostrada abaixo.
Outra prática recomendada 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 esta configuração em Configurações do Projeto>Repositórios.
Depois de atribuir permissões aos usuários, examine periodicamente os eventos de auditoria para monitorar e reagir a 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 alertá-lo sobre eventos notáveis, como o uso inadequado de permissões.
Para obter mais informações, consulte os seguintes recursos:
- Práticas recomendadas de segurança do Azure DevOps
- Permissões e grupos do Azure DevOps
- Níveis de acesso do Azure DevOps
Considerações sobre acesso baseado em funções do GitHub
Se sua principal ferramenta DevOps for o GitHub, você poderá atribuir aos usuários acesso aos recursos concedendo-lhes funções no nível do repositório, nível de equipe ou organização. Depois de bifurcar o repositório de zonas de destino do Azure e fazer a integração com um provedor de identidade, como o Microsoft Entra ID, considere criar 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 gerentes de projeto ou gerentes do Scrum na equipe, talvez seja necessário atribuir a eles a função de manutenção a esse repositório.
Recomendamos que você gerencie todas essas atribuições de função por meio do provedor de identidade integrado. Por exemplo, é possível sincronizar a equipe da Plataforma para o repositório da zona de destino do Azure que você criou no GitHub com o grupo de segurança da equipe de plataforma correspondente no Microsoft Entra ID. Em seguida, à medida que você adiciona ou remove membros ao Grupo de Segurança do Microsoft Entra, 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ê fica 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, consulte estes recursos: