Proteger repositórios e pipelines

8 minutos

Quando você automação para implantar a infraestrutura, o pipeline e o repositório se tornam poderosos e importantes. Porque agora eles representam a única maneira de aplicar alterações aos seus ambientes controlados.

Várias partes da organização do Azure DevOps, do repositório do GitHub e dos pipelines precisam ser protegidas. A tabela a seguir mostra alguns dos elementos mais importantes a serem protegidos, juntamente com exemplos de vulnerabilidades que podem ocorrer quando eles não são protegidos corretamente.

Elemento a ser protegido	Vulnerabilidade de exemplo
A organização do Azure DevOps ou o repositório do GitHub, incluindo quem tem acesso a eles e o que eles tem permissão para fazer.	Um ex-funcionário descontente exclui o repositório de código.
Branches importantes no repositório e o que precisa acontecer para alterar o código que eles contêm.	Alguém confirma acidentalmente algum código Bicep não seguro no branch principal do repositório.
O código dentro do repositório, incluindo as definições de infraestrutura, os testes e o código do aplicativo.	Alguém esquece de testar um código que escreveu e ele não funciona corretamente quando é liberado para produção.
A definição do pipeline.	Alguém adiciona acidentalmente uma etapa de pipeline que grava uma cadeia de conexão de banco de dados no log do pipeline.
Os agentes ou executores que executam o pipeline.	Um pipeline em execução em uma solicitação de pull de rascunho instala uma vulnerabilidade de segurança no agente, que mais tarde será usado para uma implantação de produção.
Tarefas ou componentes de terceiros que possam ser executados no pipeline.	Uma tarefa de pipeline de terceiros envia as credenciais da entidade de serviço a um site mal-intencionado.
As entidades de serviço que o pipeline usa para acessar o Azure.	Uma entidade de serviço que não é de produção faz uma alteração acidental no ambiente de produção.
Os segredos que o pipeline usa para acessar sistemas externos.	Um membro da equipe grava um novo arquivo de definição de pipeline para um protótipo e conecta-o acidentalmente ao ambiente de produção.

Agora, vamos aprender sobre algumas das abordagens que podem ser usadas para aplicar controles e governança relacionados ao repositório de código e aos pipelines de implantação, no Azure DevOps e no GitHub.

Gerenciar usuários e permissões

Considere como você concede acesso à organização do Azure DevOps ou ao repositório do GitHub. Pense em quem tem acesso e no que eles podem fazer.

Uma prática recomendada é usar a instância do Microsoft Entra da organização como o provedor de identidade do pipeline. Assim, você poderá garantir que sempre que alguém ingressar na organização ou sair dela, o acesso ao pipeline será concedido ou revogado automaticamente. Ao usar o Microsoft Entra ID, você também pode implementar proteções como acesso condicional e autenticação multifator facilmente.

Observação

Para usar a integração do Microsoft Entra ID ao GitHub, a organização precisa de uma licença do GitHub Enterprise.

Você também pode criar equipes (no GitHub) ou grupos (no Azure DevOps), que representam conjuntos de usuários que podem receber permissões juntos. Dessa forma, você não precisa atribuir permissões individualmente. É fácil alterar as permissões dos usuários adicionando-as e removendo-as de uma equipe ou de um grupo.

Dica

O Azure DevOps usa um modelo de permissão de privilégios mínimos, que é diferente do modelo que o Azure usa. No Azure DevOps, as permissões negar substituem as permissões permitir. Isso significa que se você estiver atribuído a vários grupos com diferentes conjuntos de permissões, apenas poderá executar as ações permitidas para todos os grupos.

Entenda como as permissões são atribuídas, principalmente para grupos.

Proteger branches de código importantes

Os pipelines e a automação devem ser baseados na identificação de branches de código específicos, como principal. O código nesses branches designados normalmente é confiável e tem permissão para ser implantado em ambientes de produção. Aplique controles para garantir que o código nos branches importantes seja verificado e revisado.

Considere o uso de regras de proteção de branch (no GitHub) ou políticas de branch (no Azure Repos) para evitar commits diretos em branches de código importantes. Depois, você poderá exigir que a equipe use solicitações de pull para mesclar as alterações. Você pode aplicar verificações automatizadas e processos de revisão manuais para verificar se as alterações são válidas antes de serem mescladas.

Testar e revisar o código

Faça com que a equipe entenda suas expectativas de revisão e teste de todos os códigos, incluindo as definições de infraestrutura.

As definições de pipeline são arquivos YAML, portanto, são uma forma de código. As alterações nas definições de pipeline precisam ser revisadas e avaliadas. Caso contrário, alguém poderá criar acidentalmente ou maliciosamente uma etapa de pipeline que vaze as credenciais da entidade de serviço ou faça uma alteração perigosa no seu patrimônio do Azure.

Todas as alterações nos arquivos de definição de pipeline precisam ser revisadas minuciosamente. Faça com que todos na equipe entendam que os pipelines são altamente privilegiados e precisam de atenção especial.

Proteger os agentes e os executores de pipeline

O pipeline é executado com agentes (para o Azure Pipelines) ou executores (para o GitHub Actions). Entenda os agentes e os executores como se fossem máquinas virtuais. Sua definição de pipeline controla essas máquinas virtuais executando as tarefas e os scripts que você fornece.

Tanto o Azure Pipelines quanto o GitHub Actions fornecem agentes e executores hospedados, que a Microsoft ou o GitHub configura e mantém. O proprietário da plataforma configura os computadores para serem compatíveis com as práticas de segurança recomendadas. As responsabilidades do proprietário da plataforma incluem a aplicação de patch de vulnerabilidades no sistema operacional.

Você pode decidir usar as suas máquinas físicas ou virtuais para os agentes e os executores. Computadores desse tipo são chamados de agentes e executores auto-hospedados. Se você usar executores e agentes auto-hospedados, será responsável por garantir que os computadores estejam configurados corretamente e protegidos contra ameaças.

Os agentes hospedados pela Microsoft e os executores hospedados pelo GitHub são efêmeros. Todas os arquivos ou as alterações de configuração de um agente ou executor são destruídos quando a execução de um pipeline termina. Se você auto-hospedar o agente ou o executor, o mesmo computador provavelmente será usado para vários pipelines ou ambientes separados, incluindo ambientes de produção e que não são de produção. Suponha que alguém crie uma definição de pipeline que modifique alguns arquivos importantes no sistema operacional do agente e execute o pipeline com uma solicitação de pull. Na próxima vez que uma implantação for executada no ambiente de produção, ela poderá reutilizar o agente. E você não terá como prever o impacto causado pelo arquivo corrompido no ambiente de produção.

Por esses motivos, a prática recomendada é usar agentes hospedados pela Microsoft e executores hospedados pelo GitHub sempre que possível. Se você precisar usar executores auto-hospedados, avalie cuidadosamente os riscos envolvidos na configuração e no uso.

Avaliar componentes de terceiros que são executados no pipeline

Se você usa extensões do GitHub Actions ou do Azure DevOps fornecidas pela comunidade, entenda quem as criou e o que elas fazem. Componentes de pipeline de terceiros podem ter acesso às credenciais da entidade de serviço e, portanto, a todo o ambiente no Azure.

No Azure DevOps, o administrador da organização normalmente aprova todas as extensões para que ela possa ser usada. Se você é o administrador da organização, considere o risco de segurança envolvido em cada componente usado. Você é responsável por verificar se eles são confiáveis e seguros.

Sempre que você usar uma ação ou uma tarefa de terceiros, especifique a versão. Considere especificar a versão exata que você revisou. Se você permitir que o pipeline use automaticamente uma versão posterior, um risco que não foi revisado poderá ser introduzido.

Proteger as entidades de serviço do pipeline

Os pipelines usam entidades de serviço para acessar o Azure e outros serviços. É importante proteger as entidades de serviço e garantir que as respectivas credenciais não sejam usadas inadequadamente. Considere aplicar várias camadas de proteção.

Primeiro, você pode considerar a proteção das credenciais das entidades de serviço:

Sempre que possível, use identidades gerenciadas ou identidades de carga de trabalho para evitar o armazenamento total de credenciais. Embora não seja possível usar identidades gerenciadas ou identidades de carga de trabalho com todos os pipelines, recomenda-se que isso seja feito sempre que possível.
Planeje como você vai alterar ou fazer a rotação das credenciais da entidade de serviço periodicamente. Por exemplo, sua organização pode ter uma política para fazer a rotação das credenciais a cada 90 ou 120 dias. Considere quem será responsável pela rotação e como você atualizará todos os locais em que a credencial é usada.
Considere designar um detentor secreto cuja função é gerenciar segredos, chaves e certificados para que eles não sejam expostos a outras partes da organização.

Depois, pense nas permissões concedidas às entidades de serviço:

Aplique políticas de acesso condicional do Microsoft Entra ID às entidades de serviço do pipeline. Essas políticas ajudam a identificar entradas e comportamentos suspeitos. Por exemplo, se as entidades de serviço de pipeline sempre entrarem de uma determinada região geográfica, o acesso condicional poderá detectar e impedir entradas de locais inesperados, o que poderia indicar o comprometimento das credenciais.
Considere cuidadosamente as permissões que você concede a cada entidade de serviço. Por exemplo, suponha que você tenha uma entidade de serviço usada para ler a configuração de um recurso compartilhado. Considere se você pode permitir somente acesso de Leitor a essa entidade de serviço, pois ela não precisa fazer nada que exija mais privilégios.
Use o escopo mínimo para cada permissão atribuída a uma entidade de serviço. Por exemplo, se a entidade de serviço precisar ser implantada apenas em um só grupo de recursos, defina o escopo da atribuição de função para esse grupo de recursos, não para toda a assinatura.
Use entidades de serviço separadas para cada um dos ambientes. Dessa forma, mesmo se as credenciais de uma entidade de segurança forem comprometidas ou se alguém obtiver acesso a um ambiente, outros ambientes não poderão ser acessados.

Proteger as conexões de serviço e os segredos

Uma conexão de serviço (no Azure Pipelines) ou um segredo (no GitHub) contém as credenciais da entidade de serviço que o pipeline usa para acessar o ambiente do Azure. É importante que você proteja as conexões de serviço e os segredos e controle quais pipelines usam cada conexão de serviço e segredo. Caso contrário, você poderá habilitar acidentalmente um ambiente que não seja de produção para usar uma entidade de serviço com acesso aos recursos de produção.

No Azure DevOps, ao criar uma conexão de serviço, você pode configurá-la a fim de exigir a aprovação para que um novo pipeline ou ambiente possa usá-la.

O Azure DevOps também permite associar verificações a conexões de serviço específicas. As verificações adicionam uma camada adicional de proteção. Por exemplo, você pode configurar uma verificação em uma conexão de serviço de produção para verificar se ela é usada somente no código do branch principal do repositório. Essa verificação ajuda a impedir que um código não autorizado seja implantado no ambiente de produção.

No GitHub, você pode configurar segredos específicos do ambiente para que, quando o fluxo de trabalho do GitHub Actions estiver trabalhando com esse ambiente, ele forneça apenas o valor do segredo. Usando segredos específicos do ambiente e controles de ambiente, como aprovações, você pode reduzir o risco de que uma implantação que não seja de produção ocorra no ambiente de produção. Você também pode usar identidades de carga de trabalho para evitar o uso de credenciais nos fluxos de trabalho do GitHub Actions e eliminar a possibilidade de que as credenciais sejam expostas.

Usar recursos de segurança do GitHub

O GitHub oferece recursos de segurança que você deve avaliar e usar. Esses recursos incluem:

Dependabot, que verifica as dependências do código-fonte em busca de vulnerabilidades conhecidas.
Verificação de segredo, que identifica textos no repositório que se parecem com chaves ou credenciais. Não se recomenda armazenar segredos em um repositório. Se você for alertado sobre um segredo no repositório, considere o valor do segredo como comprometido e revogue-o ou altere-o.
Auditoria, para entender quem fez alterações na configuração do GitHub.
Visão geral de segurança, que consolida todos os alertas de segurança nos repositórios da organização.

Usar logs de auditoria do Azure DevOps

O Azure DevOps fornece logs de auditoria que ajudam você a entender quem fez alterações nos pipelines, nas políticas de branch, nos repositórios e em outros recursos. Uma prática recomendada é habilitar a auditoria e examinar os logs de auditoria regularmente.

Proteger o repositório e o pipeline

Discutimos os controles importantes que você pode aplicar ao repositório e ao pipeline. Agora, vamos considerar quais controles você pode usar para proteger cada um dos elementos importantes listados nesta unidade:

Elemento a ser protegido	Controles a serem aplicados
A organização do Azure DevOps ou o repositório do GitHub, incluindo quem tem acesso a eles e o que eles tem permissão para fazer.	Use a autenticação do Microsoft Entra ID. Use equipes e grupos para atribuir permissões. Habilite o log de auditoria e examine os logs de auditoria regularmente.
Branches importantes no repositório e o que precisa acontecer para alterar o código que eles contêm.	Aplique regras de proteção de branch ou políticas de branch.
O código dentro do repositório, incluindo as definições de infraestrutura, os testes e o código do aplicativo.	Imponha requisitos de revisão de código. Adicione testes automatizados ou manuais. No GitHub, use o Dependabot e a verificação de segredo.
A definição do pipeline.	Imponha requisitos de revisão de código.
Os agentes ou executores que executam o pipeline.	No Azure Pipelines, use agentes hospedados pela Microsoft. No GitHub Actions, use executores hospedados no GitHub.
Tarefas ou componentes de terceiros que possam ser executados no pipeline.	Examine o risco de segurança associado a todas as extensões e tarefas de terceiros.
As entidades de serviço que o pipeline usa para acessar o Azure.	Use identidades de carga de trabalho no GitHub Actions. Para o Azure Pipelines, use entidades de serviço e faça a rotação regular das credenciais. Use entidades de serviço separadas para cada ambiente. Aplique políticas de acesso condicional.
Os segredos que o pipeline usa para acessar sistemas externos.	No Azure DevOps, use aprovações e verificações em conexões de serviço. No GitHub, use segredos específicos do ambiente e identidades de carga de trabalho.