Governança de ponta a ponta no Azure ao usar CI/CD

Ao desenvolver um modelo de governança para sua organização, é importante lembrar que o Azure Resource Manager é apenas uma das formas de gerenciar recursos. O Azure DevOps e a automação de integração contínua e entrega contínua (CI/CD) podem ser uma brecha de segurança não intencional se não estiverem devidamente protegidos. Esses recursos devem ser protegidos espelhando o modelo RBAC (controle de acesso baseado em função) usado para o Resource Manager.

O conceito de governança de ponta a ponta é independente do fornecedor. A implementação descrita aqui usa do Azure DevOps, mas alternativas também são mencionadas brevemente.

Possíveis casos de uso

Essa implementação e demonstração de referência são de software livre e devem ser usadas como uma ferramenta de ensino para organizações que são novas no DevOps e precisam criar um modelo de governança para implantação no Azure. Leia este cenário cuidadosamente para entender as decisões por trás do modelo usado neste repositório de exemplo.

Qualquer modelo de governança deve estar vinculado às regras de negócios da organização, que são refletidas em qualquer implementação técnica de controles de acesso. Este modelo de exemplo usa uma empresa fictícia com o seguinte cenário comum (com requisitos de negócios):

• Grupos do Microsoft Entra que se alinham com domínios de negócios e modelos de permissões
  A organização tem muitos domínios comerciais verticais, como "frutas" e "vegetais", que operam em grande parte de forma independente. Em cada domínio empresarial, há dois níveis ou privilégios, que são mapeados para grupos do Microsoft Entra *-admins ou *-devs diferentes. Isso permite que os desenvolvedores sejam direcionados ao configurar permissões na nuvem.

• ambientes de implantação
  Cada equipe tem dois ambientes:

  • Produção. Somente os administradores têm privilégios elevados.
  • Não produção. Todos os desenvolvedores têm privilégios elevados (para incentivar a experimentação e a inovação).

• Metas de Automação
  Cada aplicativo deve implementar o Azure DevOps não apenas para CI (integração contínua), mas também para CD (implantação contínua). Por exemplo, as implantações podem ser disparadas automaticamente por alterações no repositório Git.

• Jornada na nuvem até agora
  A organização começou com um modelo de projeto isolado para acelerar o percurso para a nuvem. Mas agora eles estão explorando opções para quebrar silos e incentivar a colaboração criando os projetos de "colaboração" e "supermercado".

Este diagrama simplificado mostra como as ramificações em um repositório Git são mapeadas para ambientes de desenvolvimento, preparo e produção:

Baixar um SVG deste diagrama.

Arquitetura

Este diagrama mostra como a vinculação do Resource Manager e da CI/CD à ID do Microsoft Entra é a chave para ter um modelo de governança de ponta a ponta.

Baixar um SVG desta arquitetura.

Nota

Para facilitar a compreensão do conceito, o diagrama ilustra apenas o domínio "vegetais". O domínio "frutas" seria semelhante e usaria as mesmas convenções de nomenclatura.

Fluxo de trabalho

A numeração reflete a ordem na qual os administradores de TI e arquitetos corporativos pensam e configuram seus recursos de nuvem.

1. Microsoft Entra ID

   Integramos o Azure DevOps com o Microsoft Entra ID para ter um único plano de identidade. Isso significa que um desenvolvedor usa a mesma conta do Microsoft Entra para o Azure DevOps e o Resource Manager. Os usuários não são adicionados individualmente. Em vez disso, a associação é atribuída por grupos do Microsoft Entra para que possamos remover o acesso de um desenvolvedor aos recursos em uma única etapa, removendo suas associações de grupo do Microsoft Entra. Para cada domínio, criamos:

   • Grupos do Microsoft Entra. Dois grupos por domínio (descritos mais adiante nas etapas 4 e 5 posteriores neste artigo).
   • Entidades de serviço. Uma entidade de serviço explícita por ambiente.

2. Ambiente de produção

   Para simplificar a implantação, essa implementação de referência usa um grupo de recursos para representar o ambiente de produção. Na prática, você deve usar uma assinatura diferente.

   O acesso privilegiado a esse ambiente é limitado apenas aos administradores.

3. Ambiente de desenvolvimento

   Para simplificar a implantação, essa implementação de referência usa um grupo de recursos para representar o ambiente de desenvolvimento. Na prática, você deve usar uma assinatura diferente.

4. Atribuições de função no Resource Manager

   Embora nossos nomes de grupo do Microsoft Entra impliquem uma função, os controles de acesso não são aplicados até que uma atribuição de função seja configurada. Isso atribui uma função a um principal do Microsoft Entra para um escopo específico. Por exemplo, os desenvolvedores têm a função de colaborador no ambiente de produção.

   Entidade de segurança do Microsoft Entra	Ambiente de desenvolvimento (Resource Manager)	Ambiente de produção (Resource Manager)
   veggies-devs-group	Proprietário	Leitor
   veggies-admins-group	Proprietário	Proprietário
   veggies-ci-dev-sp	Função personalizada *	–
   veggies-ci-prod-sp	–	Função personalizada *

   * Para simplificar a implantação, essa implementação de referência atribui a função Owner às entidades de serviço. No entanto, na produção, você deve criar uma função personalizada que impeça um principal de serviço de remover quaisquer bloqueios de gerenciamento que você colocou em seus recursos. Isso ajuda a proteger os recursos contra danos acidentais, como exclusão de banco de dados.

   Para entender o raciocínio por trás das atribuições de função individuais, consulte a seção de considerações posteriormente neste artigo.

5. Atribuições de grupo de segurança no Azure DevOps

   Os grupos de segurança funcionam como funções no Resource Manager. Aproveite as funções internas e o padrão de colaborador para os desenvolvedores. Os administradores são atribuídos ao grupo de segurança Administrador do Projeto para permissões elevadas, o que lhes permite configurar as permissões de segurança.

   Observe que o Azure DevOps e o Resource Manager têm modelos de permissões diferentes:

   • O Azure Resource Manager usa um modelo de permissões aditivas.
   • O Azure DevOps usa um modelo de permissões mínimas.

   Por esse motivo, a associação aos grupos -admins e -devs deve ser mutuamente exclusiva. Caso contrário, as pessoas afetadas teriam menos acesso do que o esperado no Azure DevOps.

   Nome do grupo	Função do Resource Manager	Função do Azure DevOps
   fruits-all	–	–
   fruits-devs	Colaborador	Colaborador
   fruits-admins	Proprietário	Administradores de projeto
   veggies-all	–	–
   veggies-devs	Colaborador	Colaborador
   veggies-admins	Proprietário	Administradores de projeto
   infra-all	–	–
   infra-devs	Colaborador	Colaborador
   infra-admins	Proprietário	Administradores de projeto

   Em um cenário de colaboração limitada - por exemplo, a equipe “frutas” convida a equipe “verduras” a colaborar em um único repositório - eles usariam o grupo veggies-all.

   Para entender o raciocínio por trás das atribuições de função individuais, consulte posteriormente a seção de considerações neste artigo.

6. Conexões de serviço

   No Azure DevOps, um Service Connection é um wrapper genérico em torno de uma credencial. Criamos uma conexão de serviço que contém o ID do cliente da entidade de serviço e o segredo do cliente. Os Administradores de Projetos podem configurar o acesso a este recurso protegido quando necessário, como, por exemplo, exigindo aprovação humana antes da implantação. Essa arquitetura de referência tem duas proteções mínimas na conexão de serviço:

   • Os administradores devem configurar permissões de pipeline para controlar quais pipelines podem acessar as credenciais.
   • Os administradores também devem configurar uma verificação de controle de ramificação para que somente os pipelines em execução no contexto da ramificação production possam usar o prod-connection.

7. Repositórios Git

   Como nossas conexões de serviço estão vinculadas a ramificações por meio de controles de ramificação, é essencial configurar permissões para os repositórios Git e aplicar políticas de ramificação. Além de exigir que os builds de CI sejam aprovados, também exigimos que as solicitações de pull tenham pelo menos dois aprovadores.

Componentes

• Azure DevOps
• Microsoft Entra ID
• Azure Resource Manager
• Azure Repos
• Azure Pipelines

Alternativas

O conceito de governança de ponta a ponta é independente do fornecedor. Embora este artigo se concentre Azure DevOps, o Azure DevOps Server pode ser usado como um substituto local. Como alternativa, você também pode usar um conjunto de tecnologias para um pipeline de desenvolvimento de CI/CD de software livre usando opções como jenkins e gitLab.

O Azure Repos e o GitHub são plataformas criadas para usar o sistema de controle de versão git de software livre. Embora seus conjuntos de recursos sejam um pouco diferentes, ambos podem ser integrados a modelos de governança global para CI/CD. O GitLab é outra plataforma baseada em Git que fornece recursos robustos de CI/CD.

Esse cenário usa o Terraform como sua ferramenta IaC (infraestrutura como código). As alternativas incluem Jenkins, Ansiblee Chef.

Considerações

Para obter governança de ponta a ponta no Azure, é importante entender o perfil de segurança e permissões do caminho do computador do desenvolvedor para a produção. O diagrama a seguir ilustra um fluxo de trabalho de CI/CD de linha de base com o Azure DevOps. O ícone de bloqueio vermelho indica permissões de segurança que devem ser configuradas pelo usuário. Não configurar ou configurar incorretamente as permissões deixará suas cargas de trabalho vulneráveis.

Baixar um SVG deste fluxo de trabalho.

Para proteger suas cargas de trabalho com êxito, você deve usar uma combinação de configurações de permissão de segurança e verificações humanas em seu fluxo de trabalho. É importante que qualquer modelo RBAC também se estenda para pipelines e código. Eles geralmente são executados com identidades privilegiadas e destruirão suas cargas de trabalho se forem instruídos a fazê-lo. Para evitar que isso aconteça, você deve configurar políticas de ramificação em seu repositório para exigir aprovação humana antes de aceitar alterações que disparam pipelines de automação.

Estágios de implantação	Responsabilidade	Descrição
Solicitações pull	Utilizador	Os engenheiros devem realizar uma revisão por pares de seus trabalhos, incluindo o próprio código do pipeline.
Proteção de ramificações	Compartilhado	Configure Azure DevOps para rejeitar alterações que não atendam a determinados padrões, como verificações de CI e revisões por pares (via pull requests).
Pipeline como código	Utilizador	Um servidor de build excluirá todo o ambiente de produção se o código do pipeline o instruir a fazer isso. Ajude a evitar isso usando uma combinação de solicitações de pull e regras de proteção de ramificação, como aprovação humana.
conexões de serviço	Compartilhado	Configure o Azure DevOps para restringir o acesso a essas credenciais.
Recursos do Azure	Compartilhado	Configure o RBAC no Resource Manager.

Os conceitos e perguntas a seguir são importantes a serem considerados ao criar um modelo de governança. Tenha em mente os possíveis casos de uso desta organização de exemplo.

1. Proteja seus ambientes com políticas de ramificação

Como o código-fonte define e dispara implantações, sua primeira linha de defesa é proteger o repositório SCM (gerenciamento de código-fonte). Na prática, isso é alcançado utilizando o fluxo de trabalho de Pull Request em combinação com as políticas de ramificação , que definem verificações e requisitos antes que o código possa ser aceito.

Ao planejar seu modelo de governança de ponta a ponta, os usuários privilegiados (veggies-admins) serão responsáveis por configurar a proteção de ramificação. As verificações comuns de proteção de ramificação usadas para proteger suas implantações incluem:

• Exigir que o build de CI seja aprovado. Útil para estabelecer a qualidade do código de linha de base, como lint de código, testes de unidade e até mesmo verificações de segurança, como verificações de vírus e credenciais.

• Exigir revisão por pares Ter outra pessoa verificando se o código funciona conforme o esperado. Tenha cuidado extra quando forem feitas alterações no código do pipeline. Combine com builds de CI para tornar as revisões em pares menos entediantes.

O que acontece se um desenvolvedor tentar fazer push diretamente para a produção?

Lembre-se de que o Git é um sistema SCM distribuído. Um desenvolvedor pode se comprometer diretamente com seu branch production local. Mas quando o Git estiver configurado corretamente, esse push será rejeitado automaticamente pelo servidor Git. Por exemplo:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Observe que o fluxo de trabalho no exemplo é independente do fornecedor. Os recursos de solicitação de pull e proteção de ramificação estão disponíveis em vários provedores SCM, incluindo Azure Repos, GitHub e GitLab.

Depois que o código tiver sido aceito em uma ramificação protegida, a próxima camada de controles de acesso será aplicada pelo servidor de build (como Azure Pipelines).

2. De que acesso as entidades de segurança precisam?

No Azure, uma entidade de segurança pode ser uma entidade de usuário ou uma entidade headless, como uma entidade de serviço ou uma identidade gerenciada. Em todos os ambientes, as entidades de segurança devem seguir a entidade de segurança com privilégios mínimos. Embora as entidades de segurança possam ter expandido o acesso em ambientes de pré-produção, os ambientes do Azure de produção devem minimizar as permissões permanentes, favorecendo o acesso just-in-time (JIT) e o Acesso Condicional do Microsoft Entra. Crie suas atribuições de função do RBAC do Azure para entidades de usuário alinharem-se a essas entidades de privilégios mínimos.

Também é importante modelar o RBAC do Azure de forma distinta do RBAC do Azure DevOps. A finalidade do pipeline é minimizar o acesso direto ao Azure. Com exceção de casos especiais como inovação, aprendizado e resolução de problemas, a maioria das interações com o Azure deve ser realizada por meio de pipelines fechados e criados com finalidade.

Para entidades de serviço do Pipeline do Azure, considere usar uma função personalizada que a impeça de remover bloqueios de recursos e executar outras ações destrutivas fora do escopo para sua finalidade.

3. Criar uma função personalizada para a entidade de serviço usada para acessar a produção

É um erro comum dar aos agentes de build de CI/CD funções e permissões de proprietário. As permissões de colaborador não serão suficientes se o pipeline também precisar executar atribuições de função de identidade ou outras operações privilegiadas, como gerenciamento de política do Key Vault.

No entanto, um agente de build de CI/CD excluirá todo o ambiente de produção se for informado para fazer isso. Para evitar alterações destrutivas irreversíveis, criamos uma função personalizada que:

• Remove políticas de acesso do Key Vault
• Remove bloqueios de gerenciamento que, por padrão, devem impedir a exclusão de recursos (um requisito comum em setores regulamentados)

Para fazer isso, criamos uma função personalizada e removemos as ações Microsoft.Authorization/*/Delete.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Se isso remover muitas permissões para suas finalidades, consulte a lista completa na documentação oficial para operações do provedor de recursos do Azure e ajuste sua definição de função conforme necessário.

Implantar esse cenário

Esse cenário vai além do Resource Manager. É por isso que usamos o Terraform, que nos permite também criar entidades de segurança no Microsoft Entra ID e inicializar o Azure DevOps usando uma única infraestrutura como ferramenta de código.

Para obter código-fonte e instruções detalhadas, visite o repositório GitHub Governança no Azure Demo - do DevOps ao ARM.

Precificação

Os custos do Azure DevOps dependem do número de usuários em sua organização que exigem acesso, juntamente com outros fatores, como o número de build/versões simultâneas necessárias e o número de usuários. O Azure Repos e o Azure Pipelines são recursos do serviço Azure DevOps. Para saber mais, confira Preços de Azure DevOps.

Na ID do Microsoft Entra, o tipo de gerenciamento de acesso de grupo necessário para esse cenário é fornecido nas edições Premium P1 e Premium P2. Os preços dessas camadas são calculados por usuário. Para obter mais informações, confira Preços do Microsoft Entra.

Colaboradores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Julie Ng | Engenheiro de Serviços Sênior

Próximas etapas

• Acesse o repositório de código para este cenário em Governança na demonstração do Azure – de DevOps para ARM.
• Revise os guias de governança de nuvem do Cloud Adoption Framework .
• O que é o RBAC (controle de acesso baseado em função) do Azure?
• Cloud Adoption Framework: Gerenciamento de acesso a recursos no Azure
• funções do Azure Resource Manager
  • Proprietário (integrado)
  • Colaborador (integrado)
  • Leitor (integrado)
  • Função Personalizada
• Grupos de segurança do Azure DevOps
  • administradores de projeto
  • Colaborador
  • Leitor