Governança de ponta a ponta do DevOps para Azure

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

Não é suficiente planejar e implementar um modelo de RBAC (controle de acesso baseado em função) para modelos do ARM (Azure Resource Manager), o 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 do ARM, mas ainda tem permissões suficientes para alterar o código do aplicativo ou a infraestrutura como código e disparar um fluxo de trabalho de automação. O desenvolvedor, indiretamente via DevOps, pode acessar e fazer alterações destrutivas nos modelos do 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 seus modelos ARM modelo RBAC. É 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 essa etapa para modelos do ARM e DevOps.

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

Observação

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á ser mantido se a associação de grupo do Microsoft Entra não estiver sincronizada.

O diagrama a seguir ilustra como o Microsoft Entra ID é usado como o plano de gerenciamento de identidade único. Em 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 na ID do Microsoft Entra. Observe que os nomes dos recursos seguem as convenções de nomenclatura e as abreviações 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 a ID do Microsoft Entra como seu plano de gerenciamento de identidade único, poderá remover o acesso de um desenvolvedor aos seus 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.

Espelhar o modelo de RBAC com atribuições de função

Quando bem planejado, o modelo de RBAC em suas ferramentas de CI espelhará de perto seu modelo de 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 segurança. Lembre-se de que o RBAC é uma combinação de entidades de segurança, definições e escopos que não entram 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.
• A esse grupo do Microsoft Entra é atribuída a função Proprietário para modelos do Azure ARM em vários escopos de assinatura:
  • contoso-dev-sub assinatura
  • contoso-prod-sub assinatura
• O contoso-admins-group é adicionado ao grupo Administradores de Projeto para Azure DevOps em um único escopo do 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 Colaborador para modelos do ARM, não esperamos que eles pertençam ao grupo Administradores de Projeto para DevOps.

Agora que você sabe sobre a necessidade de proteger os modelos do ARM e os fluxos de trabalho do DevOps, é necessário:

• Examinar seu modelo de RBAC e pensar em como as funções e as responsabilidades que você definiu para os modelos do 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 de grupo do Microsoft Entra.
• Examinar as funções e os níveis de acesso oferecidos pelas ferramentas de CI e compare-as com o modelo de RBAC do Azure. As funções e os níveis de acesso não mapearão um para um. Verifique a configuração. Se um desenvolvedor não tiver acesso para modelos do 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 os recursos de produção não deve ter acesso direto para disparar execuções de pipeline de produção.

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

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

Próximas etapas

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

Arquitetura de segurança de desenvolvimento