Proteja seus repositórios e pipelines

8 minutos

Quando você usa a automação para implantar sua infraestrutura, seu pipeline e repositório se tornam poderosos e importantes. Porque eles agora representam a única maneira pela qual as alterações são aplicadas aos seus ambientes controlados.

Muitas partes da sua organização do Azure DevOps, repositório GitHub e pipelines precisam ser protegidas. A tabela a seguir fornece alguns dos elementos mais importantes a serem protegidos, juntamente com exemplos de vulnerabilidades que podem ocorrer se você não proteger esses elementos adequadamente.

Elemento a proteger	Exemplo de vulnerabilidade
Sua organização do Azure DevOps ou repositório GitHub, incluindo quem tem acesso a ele e o que eles têm permissão para fazer.	Um ex-funcionário descontente exclui seu repositório de código.
Ramificações importantes em seu repositório e o que precisa acontecer para alterar o código nessas ramificações.	Alguém acidentalmente comete algum código Bicep não seguro na ramificação principal do seu repositório.
O código dentro do repositório, incluindo definições de infraestrutura, testes e código do aplicativo.	Alguém se esquece de testar o código que escreveu e ele não funciona corretamente quando é liberado para produção.
A definição de pipeline.	Alguém adiciona inadvertidamente uma etapa de pipeline que grava uma cadeia de conexão de banco de dados no log do pipeline.
Os agentes ou corredores que executam seu pipeline.	Um pipeline executado contra uma solicitação pull de rascunho instala uma vulnerabilidade de segurança no agente, que é usada posteriormente para uma implantação de produção.
Quaisquer tarefas ou componentes de terceiros que possam ser executados dentro do seu pipeline.	Uma tarefa de pipeline de terceiros envia as credenciais da entidade de serviço para um site mal-intencionado.
As entidades de serviço que seu pipeline usa para acessar o Azure.	Uma entidade de serviço que não é de produção acidentalmente faz uma alteração no seu ambiente de produção.
Os segredos que seu pipeline usa para acessar sistemas externos.	Um membro da equipe escreve um novo arquivo de definição de pipeline para um protótipo e o conecta acidentalmente ao seu ambiente de produção.

Agora vamos aprender sobre algumas das abordagens que você pode usar para aplicar governança e controles em torno de seu repositório de código e pipelines de implantação, no Azure DevOps e GitHub.

Gerenciar usuários e permissões

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

É uma boa prática usar a instância do Microsoft Entra da sua organização como provedor de identidade do pipeline. Dessa forma, você pode garantir que, sempre que alguém entrar ou sair da sua organização, o acesso ao seu pipeline seja automaticamente concedido ou revogado. Usando o Microsoft Entra ID, você também pode implementar facilmente proteções como acesso condicional e autenticação multifator.

Nota

Para usar a integração do Microsoft Entra com o GitHub, sua 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 aos quais podem ser concedidas permissões juntas. Dessa forma, você não precisa atribuir permissões individualmente. É fácil alterar as permissões dos usuários adicionando-os e removendo-os de uma equipe ou grupo.

Gorjeta

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

Certifique-se de entender como as permissões são atribuídas, especialmente a grupos.

Proteja ramificações de código importantes

Seus pipelines e automação devem ser baseados na identificação de ramificações de código específicas, como principal. O código nessas ramificações designadas normalmente é confiável e pode ser implantado em seus ambientes de produção. Aplique controles para garantir que o código que está em suas ramificações importantes tenha sido verificado e revisado.

Considere o uso de regras de proteção de ramificação (no GitHub) ou políticas de ramificação (no Azure Repos) para evitar confirmações diretas em ramificações de código importantes. Em seguida, você pode exigir que sua equipe use solicitações pull para mesclar quaisquer alterações. Você pode aplicar verificações automatizadas e processos de revisão manual para verificar se as alterações são válidas antes de serem mescladas.

Teste e reveja o seu código

Certifique-se de que sua equipe entenda suas expectativas para revisar e testar todo o código, incluindo suas definições de infraestrutura.

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

Quaisquer alterações nos arquivos de definição de pipeline precisam ser cuidadosamente revisadas. Certifique-se de que todos na sua equipe entendam que os pipelines são altamente privilegiados e precisam de atenção especial.

Proteja seus agentes de tubulação e corredores

Seu pipeline é executado em agentes (para Pipelines do Azure) ou corredores (para Ações do GitHub). Você pode pensar em agentes e corredores como máquinas virtuais. Sua definição de pipeline controla essas máquinas virtuais executando as tarefas e scripts fornecidos.

Tanto o Azure Pipelines quanto o GitHub Actions fornecem agentes hospedados e runners, que a Microsoft ou o GitHub configuram e mantêm. O proprietário da plataforma configura as máquinas para serem compatíveis com as práticas de segurança recomendadas. As responsabilidades do proprietário da plataforma incluem a correção de vulnerabilidades do sistema operacional.

Em vez disso, você pode optar por usar suas próprias máquinas físicas ou virtuais para seus agentes e corredores. Máquinas desse tipo são chamadas de agentes e corredores auto-hospedados . Se você usa agentes e corredores auto-hospedados, é responsável por garantir que as máquinas estejam configuradas corretamente e protegidas contra ameaças.

Os agentes hospedados pela Microsoft e os corredores hospedados no GitHub são efêmeros. Quaisquer arquivos ou alterações de configuração em um agente ou corredor são destruídos quando a execução de um pipeline termina. Se você hospedar automaticamente seu agente ou corredor, é provável que a mesma máquina seja usada para vários pipelines ou ambientes separados, incluindo ambientes de produção e não 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 a partir de uma solicitação pull. Na próxima vez que uma implantação for executada em seu ambiente de produção, ela poderá reutilizar o agente. Agora você não tem como prever qual pode ser o impacto do arquivo corrompido em seu ambiente de produção.

Por esses motivos, é uma boa prática usar agentes hospedados pela Microsoft e corredores hospedados pelo GitHub sempre que puder. Se você precisar usar corredores auto-hospedados, avalie cuidadosamente os riscos envolvidos em sua configuração e uso.

Avalie componentes de terceiros que são executados dentro do seu pipeline

Se você usa Ações do GitHub fornecidas pela comunidade ou extensões do Azure DevOps, entenda quem as criou e o que elas fazem. Os 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 cada extensão antes que ela possa ser usada. Se você for o administrador da sua organização, considere o risco de segurança envolvido em cada componente que você usa. Você é responsável por verificar se eles são confiáveis e seguros.

Sempre que você usar uma ação ou tarefa de terceiros, especifique a versão. Considere especificar a versão exata que você analisou. Permitir que o pipeline use automaticamente uma versão posterior pode introduzir um risco que você não analisou.

Proteja as entidades de serviço do seu pipeline

Os pipelines usam entidades de serviço para acessar o Azure e outros serviços. É importante proteger suas entidades de serviço e garantir que suas credenciais não possam ser usadas de forma inadequada. Considere a aplicação de várias camadas de proteção.

Primeiro, você pode considerar a proteção das credenciais para suas 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 você não possa usar identidades gerenciadas ou identidades de carga de trabalho com todos os pipelines, é uma boa prática fazê-lo quando puder.
Planeje como você alterará ou girará as credenciais da entidade de serviço regularmente. Por exemplo, sua organização pode ter uma política para alternar credenciais a cada 90 ou 120 dias. Considere quem será responsável pela rotação e como você atualizará todos os locais onde a credencial é usada.
Considere designar um custodiante secreto cuja função é gerenciar segredos, chaves e certificados para que eles não sejam expostos a outras partes da organização.

Em seguida, pense nas permissões que você concede às entidades de serviço:

Aplique as políticas de Acesso Condicional do Microsoft Entra às entidades de serviço do seu pipeline. Essas políticas ajudam a identificar entradas e comportamentos de risco. Por exemplo, se as entidades de serviço de pipeline sempre entrarem de uma região geográfica, o Acesso Condicional poderá detetar e impedir entradas de locais inesperados, o que pode indicar que as credenciais foram comprometidas.
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 que você usa para ler a configuração de um recurso compartilhado. Considere se você pode conceder apenas acesso de Leitor a essa entidade de serviço, porque a entidade de serviço 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 implantar em apenas um único grupo de recursos, defina o escopo da atribuição de função para esse grupo de recursos em vez de para toda a assinatura.
Use entidades de serviço separadas para cada um dos seus ambientes. Dessa forma, mesmo que as credenciais de uma entidade de segurança sejam comprometidas ou se alguém tiver acesso a um ambiente, ele não poderá acessar outros ambientes.

Proteja suas conexões de serviço e segredos

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

No Azure DevOps, quando você cria uma conexão de serviço, pode configurá-la para exigir sua aprovação antes 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 apenas no código da ramificação principal do repositório. Essa verificação ajuda a impedir que códigos não autorizados sejam implantados em seu ambiente de produção.

No GitHub, você pode configurar segredos específicos do ambiente, de modo que, quando o fluxo de trabalho de Ações do GitHub estiver trabalhando com esse ambiente, ele forneça apenas o valor secreto. 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 seja usada para implantar em seu ambiente de produção. Você também pode usar identidades de carga de trabalho para evitar o uso de credenciais em seus fluxos de trabalho de Ações do GitHub e eliminar a possibilidade de que as credenciais possam ser expostas.

Usar recursos de segurança do GitHub

O GitHub fornece recursos de segurança que você deve avaliar e usar. Estas funcionalidades incluem:

Dependabot, que verifica as dependências do código-fonte em busca de vulnerabilidades conhecidas.
Verificação secreta, que identifica texto no repositório que se parece com chaves ou credenciais. É uma má prática armazenar segredos em um repositório. Se você for alertado sobre um segredo em seu repositório, considere que o valor do segredo está comprometido e, em seguida, 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 seus alertas de segurança nos repositórios da sua organização.

Usar logs de auditoria do Azure DevOps

O Azure DevOps fornece logs de auditoria para ajudá-lo a entender quem fez alterações em seus pipelines, políticas de ramificação, repositórios e outros recursos. É uma boa prática habilitar a auditoria e revisar os logs de auditoria regularmente.

Proteja seu repositório e pipeline

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

Elemento a proteger	Controlos a aplicar
Sua organização do Azure DevOps ou repositório GitHub, incluindo quem tem acesso a ele e o que eles têm permissão para fazer.	Use o Microsoft Entra ID para autenticação. Use equipes e grupos para atribuir permissões. Habilite o registro de auditoria e revise os logs de auditoria regularmente.
Ramificações importantes em seu repositório e o que precisa acontecer para alterar o código nessas ramificações.	Aplique regras de proteção de ramificação ou políticas de filial.
O código dentro do repositório, incluindo definições de infraestrutura, testes e código do aplicativo.	Impor requisitos de revisão de código. Adicione testes automatizados ou manuais. No GitHub, use o Dependabot e a verificação secreta.
A definição de pipeline.	Impor requisitos de revisão de código.
Os agentes ou corredores que executam seu pipeline.	No Azure Pipelines, use agentes hospedados pela Microsoft. Em Ações do GitHub, use corredores hospedados no GitHub.
Quaisquer tarefas ou componentes de terceiros que possam ser executados dentro do seu pipeline.	Analise o risco de segurança associado a todas as extensões e tarefas de terceiros.
As entidades de serviço que seu pipeline usa para acessar o Azure.	Use identidades de carga de trabalho em Ações do GitHub. Para Pipelines do Azure, use entidades de serviço e alterne regularmente suas credenciais. Use entidades de serviço separadas para cada ambiente. Aplique políticas de acesso condicional.
Os segredos que seu 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.