Governança de ponta a ponta do DevOps para o Azure

Este artigo descreve como gerenciar e implementar cuidadosamente práticas de governança sólidas para sua equipe, como permissões de controle de acesso baseadas em função.

Não é suficiente planejar e implementar um modelo de controle de acesso baseado em função (RBAC) do Azure para modelos do Azure Resource Manager (modelos ARM), que restringe o acesso por meio do portal do Azure e da CLI do Azure.

Se esse modelo não for espelhado para automação de DevOps, sua organização poderá deixar um backdoor de segurança aberto. Considere um exemplo em que um desenvolvedor não tem acesso por meio de modelos ARM, mas ainda tem permissões suficientes para alterar o código do aplicativo ou a infraestrutura como código e acionar um fluxo de trabalho de automação. O desenvolvedor, indiretamente via DevOps, pode acessar e fazer alterações destrutivas em seus modelos ARM.

Plano de gerenciamento de identidade único com grupos do Microsoft Entra

A primeira etapa é integrar o Microsoft Entra ID para usar o logon único por prática recomendada de gerenciamento de identidade.

Se você não estiver usando um produto de CI primário do Azure como o Azure DevOps, verifique se seu fornecedor oferece integração com o Microsoft Entra.

A segunda etapa é usar os grupos do Microsoft Entra, os mesmos grupos que você já está usando para seu modelo RBAC de modelos ARM. É uma prática recomendada atribuir funções a grupos do Microsoft Entra, não a indivíduos. Para criar um modelo de governança de ponta a ponta, você precisará executar esta etapa para modelos ARM e DevOps.

O Azure DevOps tem uma integração total com o Microsoft Entra ID, incluindo a associação a grupos do Microsoft Entra, facilitando a aplicação de atribuições de função ao mesmo grupo do Microsoft Entra.

Nota

Se você estiver usando outro fornecedor de CI, talvez tenha um contêiner lógico intermediário para gerenciar associações de grupo, que também precisará manter se a associação ao grupo do Microsoft Entra não estiver sincronizada.

O diagrama a seguir ilustra como o Microsoft Entra ID é usado como o único plano de gerenciamento de identidade. Nos modelos ARM e em nossas ferramentas de DevOps (Azure DevOps neste exemplo), só precisamos gerenciar atribuições de função, não associações, que devem ser gerenciadas no Microsoft Entra ID. Observe que os nomes de recursos seguem as convenções de nomenclatura e abreviaturas recomendadas para recursos do Azure.

Cenário de exemplo: Remover o acesso do contratante com uma única etapa, associação ao Microsoft Entra

Para tornar a governança de ponta a ponta concreta, vamos examinar os benefícios com um cenário de exemplo.

Se você usar o Microsoft Entra ID como seu único plano de gerenciamento de identidade, poderá remover o acesso de um desenvolvedor aos recursos do Azure em uma ação, ajustando suas associações de grupo do Microsoft Entra. Por exemplo, se o acesso de um contratante deve ser revogado após a conclusão do projeto, quando você remove a associação do contratante dos grupos relevantes do Microsoft Entra, o acesso aos modelos ARM e ao Azure DevOps é removido.

Modelo RBAC espelhado com atribuições de função

Quando bem planejado, o modelo RBAC em suas ferramentas de CI espelhará de perto seu modelo RBAC do Azure. Embora os exemplos de nome de grupo do Microsoft Entra no diagrama acima impliquem regras de segurança, a associação por si só não impõe a segurança. Lembre-se de que o RBAC é uma combinação de princípios, definições e escopos, que não entra em vigor até que a atribuição de função seja criada.

• O diagrama ilustra a atribuição de função para um único grupo do Microsoft Entra, contoso-admins-group.
• Este grupo do Microsoft Entra recebe a função de Proprietário para modelos ARM do Azure em vários escopos de assinatura:
  • contoso-dev-sub subscrição
  • contoso-prod-sub subscrição
• O contoso-admins-group é adicionado ao grupo Administradores de Projeto para DevOps do Azure em um único escopo de projeto.

O grupo Microsoft Entra tem funções igualmente privilegiadas para modelos ARM e DevOps. Seguindo essa lógica, se tivermos um grupo de desenvolvedores atribuído à função de Colaborador para modelos ARM, não esperaríamos que eles pertencessem ao grupo Administradores de Projeto para DevOps.

Agora que você entende a necessidade de proteger modelos ARM e fluxos de trabalho de DevOps, deve:

• Analise seu modelo RBAC e pense em como as funções e responsabilidades que você definiu para modelos ARM correspondem ao seu fluxo de trabalho de CI/CD.
• Analise as soluções de gerenciamento de identidade da sua plataforma de CI e integre o Microsoft Entra ID. Idealmente, você deseja incluir a associação ao grupo Microsoft Entra.
• Analise as funções e os níveis de acesso oferecidos pelas suas ferramentas de CI e compare-os com o seu modelo RBAC do Azure. As funções e os níveis de acesso não mapearão um para um. Verifique a sua configuração. Se um desenvolvedor não tiver acesso para modelos ARM, ele não deverá ter acesso para DevOps. No exemplo mais simples, um desenvolvedor que não tem permissões de gravação para recursos de produção não deve ter acesso direto para disparar execuções de pipeline de produção.

Para saber mais sobre design e permissões de governança, consulte:

• Método recomendado para conceder e restringir permissões
• Permissões predefinidas e acesso ao Azure DevOps
• Gerir o acesso das pessoas à sua organização com funções

Próximos passos

Agora que você entende a necessidade de proteger modelos ARM e fluxos de trabalho de DevOps, saiba como gerenciar segredos de forma segura.

Arquitetura de segurança de desenvolvimento