Um pipeline de implementação é um processo automatizado que usa código ou artefactos pré-criados e os implementa num ambiente de teste ou num ambiente de produção. Os pipelines de implementação são usados frequentemente para implementar aplicações, configurações ou infraestrutura na nuvem (infraestrutura como código) e podem desempenhar um papel importante na postura de segurança geral de uma implementação na nuvem.
Este guia destina-se a engenheiros de segurança e DevOps, e descreve as práticas recomendadas para conceber pipelines de implementação seguros com base nos seus requisitos de confidencialidade, integridade e disponibilidade.
Arquitetura
O diagrama seguinte mostra o fluxo de dados num pipeline de implementação. Ilustra como pode transformar os seus artefactos em recursos.
As pipelines de implementação fazem frequentemente parte de um fluxo de trabalho de integração contínua/implementação contínua (CI/CD) maior e são normalmente implementadas através de um dos seguintes modelos:
Modelo de envio: neste modelo, implementa o pipeline de implementação usando um sistema de CI/CD central, como o Jenkins ou o GitLab. Este sistema de CI/CD pode ser executado no Google Cloudlocalmente ou num ambiente de nuvem diferente. Muitas vezes, o mesmo sistema de CI/CD é usado para gerir vários pipelines de implementação.
O modelo de envio gera uma arquitetura centralizada com alguns sistemas de CI/CD que são usados para gerir um número potencialmente grande de recursos ou aplicações. Por exemplo, pode usar uma única instância do Jenkins ou GitLab para gerir todo o seu ambiente de produção, incluindo todos os respetivos projetos e aplicações.
Modelo de obtenção: neste modelo, o processo de implementação é implementado por um agente que é implementado juntamente com o recurso, por exemplo, no mesmo cluster do Kubernetes. O agente extrai artefactos ou código fonte de uma localização centralizada e implementa-os localmente. Cada agente gere um ou dois recursos.
O modelo de obtenção leva a uma arquitetura mais descentralizada com um número potencialmente grande de agentes de objetivo único.
Em comparação com as implementações manuais, a utilização consistente de pipelines de implementação pode ter as seguintes vantagens:
- Maior eficiência, porque não é necessário trabalho manual.
- Maior fiabilidade, uma vez que o processo é totalmente automático e repetível.
- Maior rastreabilidade, porque pode rastrear todas as implementações até às alterações no código ou aos artefactos de entrada.
Para ser executado, um pipeline de implementação requer acesso aos recursos que gere:
- Um pipeline que implementa infraestrutura através de ferramentas como o Terraform pode ter de criar, modificar ou até eliminar recursos como instâncias de VM, sub-redes ou contentores do Cloud Storage.
- Um pipeline que implementa aplicações pode ter de carregar novas imagens de contentores para o Artifact Registry e implementar novas versões de aplicações no App Engine, no Cloud Run ou no Google Kubernetes Engine (GKE).
- Um pipeline que gere definições ou implemente ficheiros de configuração pode ter de modificar os metadados da instância da VM, as configurações do Kubernetes ou modificar os dados no Cloud Storage.
Se os seus pipelines de implementação não estiverem devidamente protegidos, o respetivo acesso aos Google Cloud recursos pode tornar-se um ponto fraco na sua postura de segurança. A segurança enfraquecida pode levar a vários tipos de ataques, incluindo os seguintes:
Ataques de envenenamento de pipeline: em vez de atacar um recurso diretamente, um interveniente malicioso pode tentar comprometer o pipeline de implementação, a respetiva configuração ou a infraestrutura subjacente. Tirando partido do acesso do pipeline a Google Cloud, o interveniente mal-intencionado pode fazer com que o pipeline execute ações maliciosas em recursos da nuvem, conforme mostrado no diagrama seguinte:
Ataques à cadeia de fornecimento: em vez de atacar o pipeline de implementação, um ator malicioso pode tentar comprometer ou substituir a entrada do pipeline, incluindo código fonte, bibliotecas ou imagens de contentores, conforme mostrado no seguinte diagrama:
Para determinar se os seus pipelines de implementação estão devidamente protegidos, não basta analisar apenas as políticas de permissão e as políticas de recusa de Google Cloud recursos isoladamente. Em alternativa, tem de considerar todo o gráfico de sistemas que concedem acesso direta ou indiretamente a um recurso. Este gráfico inclui as seguintes informações:
- A pipeline de implementação, o respetivo sistema de CI/CD subjacente e a respetiva infraestrutura subjacente
- O repositório de código-fonte, os respetivos servidores subjacentes e a respetiva infraestrutura subjacente
- Introduzir artefactos, as respetivas localizações de armazenamento e a infraestrutura subjacente
- Sistemas que produzem os artefactos de entrada e a respetiva infraestrutura subjacente
Os gráficos de entrada complexos dificultam a identificação do acesso dos utilizadores aos recursos e das fraquezas sistémicas.
As secções seguintes descrevem as práticas recomendadas para conceber pipelines de implementação de forma a ajudar a gerir o tamanho do gráfico e reduzir o risco de movimento lateral e ataques à cadeia de fornecimento.
Avalie os objetivos de segurança
É provável que os seus recursos no Google Cloud variem em termos de sensibilidade. Alguns recursos podem ser altamente sensíveis porque são essenciais para a empresa ou confidenciais. Outros recursos podem ser menos sensíveis porque são efémeros ou destinam-se apenas a fins de teste.
Para criar um pipeline de implementação seguro, tem de compreender primeiro os recursos aos quais o pipeline precisa de aceder e a sensibilidade desses recursos. Quanto mais sensíveis forem os seus recursos, mais deve focar-se na proteção do pipeline.
Os recursos acedidos pelos pipelines de implementação podem incluir:
- Aplicações, como o Cloud Run ou o App Engine
- Recursos da nuvem, como instâncias de VM ou contentores do Cloud Storage
- Dados, como objetos do Cloud Storage, registos do BigQuery ou ficheiros
Alguns destes recursos podem ter dependências de outros recursos, por exemplo:
- As aplicações podem aceder a dados, recursos na nuvem e outras aplicações.
Os recursos da nuvem, como instâncias de VM ou contentores do Cloud Storage, podem conter aplicações ou dados.
Conforme mostrado no diagrama anterior, as dependências afetam a sensibilidade de um recurso. Por exemplo, se usar uma aplicação que aceda a dados altamente confidenciais, normalmente, deve tratar essa aplicação como altamente confidencial. Da mesma forma, se um recurso de nuvem, como um contentor do Cloud Storage, contiver dados confidenciais, normalmente deve tratar o contentor como confidencial.
Devido a estas dependências, é melhor avaliar primeiro a sensibilidade dos seus dados. Depois de avaliar os seus dados, pode examinar a cadeia de dependências e avaliar a sensibilidade dos seus recursos e aplicações na nuvem.
Categorize a sensibilidade dos seus dados
Para compreender a sensibilidade dos dados no seu pipeline de implementação, considere os três objetivos seguintes:
- Confidencialidade: tem de proteger os dados contra o acesso não autorizado.
- Integridade: tem de proteger os dados contra modificação ou eliminação não autorizada.
- Disponibilidade: tem de garantir que as pessoas e os sistemas autorizados podem aceder aos dados no seu pipeline de implementação.
Para cada um destes objetivos, pergunte-se o que aconteceria se a sua conduta fosse violada:
- Confidencialidade: qual seria o impacto se os dados fossem divulgados a um agente malicioso ou fossem divulgados publicamente?
- Integridade: qual seria o impacto se os dados fossem modificados ou eliminados por um interveniente mal intencionado?
- Disponibilidade: qual seria o impacto se um interveniente prejudicial interrompesse o seu acesso aos dados?
Para tornar os resultados comparáveis entre recursos, é útil introduzir categorias de segurança. As Normas para a categorização de segurança (FIPS-199) sugerem a utilização das seguintes quatro categorias:
- Elevado: os danos seriam graves ou catastróficos
- Moderado: os danos seriam graves
- Baixo: os danos seriam limitados
- Não aplicável: a norma não se aplica
Consoante o seu ambiente e contexto, um conjunto diferente de categorias pode ser mais adequado.
A confidencialidade e a integridade dos dados do pipeline existem num espectro, com base nas categorias de segurança que acabámos de abordar. As subsecções seguintes contêm exemplos de recursos com diferentes medições de confidencialidade e integridade:
Recursos com confidencialidade baixa, mas integridade baixa, moderada e alta
Os seguintes exemplos de recursos têm todos uma confidencialidade baixa:
- Baixa integridade: dados de teste
- Integridade moderada: conteúdo do servidor Web público, restrições de políticas para a sua organização
- Integridade elevada: imagens de contentores, imagens de disco, configurações de aplicações, políticas de acesso (listas de autorizações e recusas), ónus, dados ao nível de acesso
Recursos com confidencialidade média, mas integridade baixa, moderada e alta
Os seguintes exemplos de recursos têm todos confidencialidade média:
- Baixa integridade: conteúdo do servidor Web interno
- Integridade moderada: registos de auditoria
- Alta integridade: ficheiros de configuração da aplicação
Recursos com confidencialidade elevada, mas integridade baixa, moderada e elevada
Os seguintes exemplos de recursos têm todos uma confidencialidade elevada:
- Baixa integridade: dados de utilização e informações de identificação pessoal
- Integridade moderada: segredos
- Integridade elevada: dados financeiros, chaves do KMS
Categorize as aplicações com base nos dados aos quais acedem
Quando uma aplicação acede a dados confidenciais, a aplicação e o pipeline de implementação que gere a aplicação também podem tornar-se confidenciais. Para determinar essa sensibilidade, analise os dados aos quais a aplicação e o pipeline precisam de aceder.
Depois de identificar e categorizar todos os dados acedidos por uma aplicação, pode usar as seguintes categorias para categorizar inicialmente a aplicação antes de criar um pipeline de implementação seguro:
- Confidencialidade: categoria mais elevada de quaisquer dados acedidos
- Integridade: categoria mais elevada de quaisquer dados acedidos
- Disponibilidade: categoria mais elevada de quaisquer dados acedidos
Esta avaliação inicial fornece orientações, mas podem existir fatores adicionais a ter em conta, por exemplo:
- Dois conjuntos de dados podem ter baixa confidencialidade isoladamente. No entanto, quando combinados, podem revelar novas estatísticas. Se uma aplicação tiver acesso a ambos os conjuntos de dados, pode ter de a categorizar como de confidencialidade média ou alta.
- Se uma aplicação tiver acesso a dados de alta integridade, deve categorizá-la como de alta integridade. No entanto, se esse acesso for apenas de leitura, uma categorização de alta integridade pode ser demasiado rigorosa.
Para ver detalhes sobre uma abordagem formalizada para categorizar aplicações, consulte o Guia para mapear tipos de informações e sistemas de informações para categorias de segurança (NIST SP 800-60 Vol. 2 Rev1).
Categorize os recursos da nuvem com base nos dados e nas aplicações que alojam
Todos os dados ou aplicações que implementar no Google Cloud são alojados por um recurso doGoogle Cloud :
- Uma aplicação pode ser alojada por um serviço do App Engine, uma instância de VM ou um cluster do GKE.
- Os seus dados podem ser alojados por um disco persistente, um contentor do Cloud Storage ou um conjunto de dados do BigQuery.
Quando um recurso da nuvem aloja dados ou aplicações sensíveis, o recurso e o pipeline de implementação que gere o recurso também podem tornar-se sensíveis. Por exemplo, deve considerar um serviço do Cloud Run e a respetiva pipeline de implementação tão sensíveis quanto a aplicação que está a alojar.
Depois de categorizar os seus dados e as suas aplicações, crie uma categoria de segurança inicial para a aplicação. Para o fazer, determine um nível a partir das seguintes categorias:
- Confidencialidade: categoria mais elevada de quaisquer dados ou aplicações alojados
- Integridade: categoria mais elevada de quaisquer dados ou aplicações alojados
- Disponibilidade: categoria mais elevada de quaisquer dados ou aplicações alojados
Ao fazer a avaliação inicial, não seja demasiado rigoroso. Por exemplo:
- Se encriptar dados altamente confidenciais, trate a chave de encriptação como altamente confidencial. No entanto, pode usar uma categoria de segurança inferior para o recurso que contém os dados.
- Se armazenar cópias redundantes de dados ou executar instâncias redundantes das mesmas aplicações em vários recursos, pode tornar a categoria do recurso inferior à categoria dos dados ou da aplicação que aloja.
Restrinja a utilização de pipelines de implementação
Se o pipeline de implementação precisar de aceder a recursos Google Cloud confidenciais, tem de considerar a respetiva postura de segurança. Quanto mais sensíveis forem os recursos, mais deve tentar proteger o pipeline. No entanto, pode deparar-se com as seguintes limitações práticas:
- Quando usa uma infraestrutura ou um sistema de CI/CD existente, essa infraestrutura pode restringir o nível de segurança que pode alcançar de forma realista. Por exemplo, o seu sistema de CI/CD pode suportar apenas um conjunto limitado de controlos de segurança ou pode estar a ser executado numa infraestrutura que considera menos segura do que alguns dos seus ambientes de produção.
- Quando configura uma nova infraestrutura e sistemas para executar o pipeline de implementação, proteger todos os componentes de uma forma que cumpra os seus requisitos de segurança mais rigorosos pode não ser rentável.
Para lidar com estas limitações, pode ser útil definir restrições sobre os cenários que devem e não devem usar pipelines de implementação e um sistema de CI/CD específico. Por exemplo, as implementações mais sensíveis são, muitas vezes, melhor processadas fora de um pipeline de implementação. Estas implementações podem ser manuais, através de um sistema de gestão de sessões privilegiadas ou um sistema de gestão de acesso privilegiado, ou algo mais, como proxies de ferramentas.
Para definir as restrições, defina os controlos de acesso que quer aplicar com base nas categorias de recursos. Considere as orientações apresentadas na tabela seguinte:
| Categoria do recurso | Controlos de acesso |
|---|---|
| Baixo | Não requer aprovação |
| Moderada | O responsável de equipa tem de aprovar |
| Alto | Vários leads têm de aprovar e as ações têm de ser registadas |
Contraste estes requisitos com as capacidades dos seus sistemas de gestão de código fonte (SCM) e CI/CD fazendo as seguintes perguntas e outras:
- Os seus sistemas SCM ou CI/CD suportam os controlos de acesso e os mecanismos de aprovação necessários?
- Os controlos estão protegidos contra subversão se os intervenientes prejudiciais atacarem a infraestrutura subjacente?
- A configuração que define os controlos está devidamente protegida?
Em função das capacidades e das limitações impostas pelos seus sistemas SCM ou CI/CD, pode definir as restrições de dados e aplicações para os seus pipelines de implementação. Considere as orientações apresentadas na seguinte tabela:
| Categoria do recurso | Restrições |
|---|---|
| Baixo | É possível usar pipelines de implementação e os programadores podem autoaprovar implementações. |
| Moderada | É possível usar pipelines de implementação, mas um líder de equipa tem de aprovar todas as confirmações e implementações. |
| Alto | Não use pipelines de implementação. Em alternativa, os administradores têm de usar um sistema de gestão de acesso privilegiado e a gravação de sessões. |
Mantenha a disponibilidade dos recursos
A utilização de um pipeline de implementação para gerir recursos pode afetar a disponibilidade desses recursos e introduzir novos riscos:
- Causar interrupções: um pipeline de implementação pode enviar código com falhas ou ficheiros de configuração, o que faz com que um sistema que funcionava anteriormente deixe de funcionar ou que os dados se tornem inutilizáveis.
- Prolongar interrupções: para corrigir uma interrupção, pode ter de executar novamente um pipeline de implementação. Se o pipeline de implementação estiver danificado ou indisponível por outros motivos, isso pode prolongar a indisponibilidade.
Um pipeline que pode causar ou prolongar interrupções representa um risco de negação de serviço: um ator malicioso pode usar o pipeline de implementação para causar intencionalmente uma interrupção.
Crie procedimentos de acesso de emergência
Quando um pipeline de implementação é a única forma de implementar ou configurar uma aplicação ou um recurso, a disponibilidade do pipeline pode tornar-se crítica. Em casos extremos, quando um pipeline de implementação é a única forma de gerir uma aplicação essencial para a empresa, também pode ter de considerar o pipeline de implementação essencial para a empresa.
Uma vez que os pipelines de implementação são frequentemente criados a partir de vários sistemas e ferramentas, a manutenção de um elevado nível de disponibilidade pode ser difícil ou antieconómica.
Pode reduzir a influência dos pipelines de implementação na disponibilidade através da criação de procedimentos de acesso de emergência. Por exemplo, crie um caminho de acesso alternativo que possa ser usado se o pipeline de implementação não estiver operacional.
Normalmente, a criação de um procedimento de acesso de emergência requer a maioria dos seguintes processos:
- Manter uma ou mais contas de utilizador com acesso privilegiado aos Google Cloud recursos relevantes.
- Armazene as credenciais das contas de utilizador de acesso de emergência num local seguro ou use um sistema de gestão de acesso privilegiado para intermediar o acesso.
- Estabeleça um procedimento que os funcionários autorizados possam seguir para aceder às credenciais.
- Audite e reveja a utilização de contas de utilizador de acesso de emergência.
Certifique-se de que os artefactos de entrada satisfazem as suas exigências de disponibilidade
Normalmente, os pipelines de implementação têm de transferir o código fonte de um repositório de código fonte central antes de poderem fazer uma implementação. Se o repositório de código-fonte não estiver disponível, é provável que a execução do pipeline de implementação falhe.
Muitos pipelines de implementação também dependem de artefactos de terceiros. Estes artefactos podem incluir bibliotecas de origens como npm, Maven Central ou a galeria NuGet, bem como imagens base de contentores e pacotes .deb e .rpm. Se uma das origens de terceiros não estiver disponível, a execução do pipeline de implementação pode falhar.
Para manter um determinado nível de disponibilidade, tem de garantir que os artefactos de entrada do pipeline de implementação cumprem todos os requisitos de disponibilidade iguais ou superiores. A seguinte lista pode ajudar a garantir a disponibilidade de artefactos de entrada:
- Limite o número de origens para artefactos de entrada, em particular, origens de terceiros
- Manter uma cache de artefactos de entrada que os pipelines de implementação podem usar se os sistemas de origem estiverem indisponíveis
Trate os pipelines de implementação e a respetiva infraestrutura como sistemas de produção
Os pipelines de implementação servem frequentemente como elo de ligação entre os ambientes de desenvolvimento, de preparação e de produção. Consoante o ambiente, podem ser implementadas várias fases:
- Na primeira fase, o pipeline de implementação atualiza um ambiente de desenvolvimento.
- Na fase seguinte, o pipeline de implementação atualiza um ambiente de preparação.
- Na fase final, o pipeline de implementação atualiza o ambiente de produção.
Quando usar um pipeline de implementação em vários ambientes, certifique-se de que o pipeline cumpre as exigências de disponibilidade de cada ambiente. Uma vez que os ambientes de produção têm normalmente as exigências de disponibilidade mais elevadas, deve tratar o pipeline de implementação e a respetiva infraestrutura subjacente como um sistema de produção. Por outras palavras, aplique os mesmos padrões de controlo de acesso, segurança e qualidade à infraestrutura que executa os seus pipelines de implementação, tal como faz para os seus sistemas de produção.
Limite o âmbito dos pipelines de implementação
Quanto mais recursos um pipeline de implementação puder aceder, mais danos pode causar se for comprometido. Um pipeline de implementação comprometido que tenha acesso a vários projetos ou até a toda a sua organização pode, no pior dos casos, causar danos duradouros a todos os seus dados e aplicações noGoogle Cloud.
Para ajudar a evitar este pior cenário, limite o âmbito dos seus pipelines de implementação. Defina o âmbito de cada pipeline de implementação para que apenas precise de acesso a um número relativamente pequeno de recursos no Google Cloud:
- Em vez de conceder acesso ao nível do projeto, conceda apenas acesso aos pipelines de implementação a recursos individuais.
- Evite conceder acesso a recursos em vários Google Cloud projetos.
- Divida os pipelines de implementação em várias fases se precisarem de acesso a vários projetos ou ambientes. Em seguida, proteja as fases individualmente.
Manter a confidencialidade
Um pipeline de implementação tem de manter a confidencialidade dos dados que gere. Um dos principais riscos relacionados com a confidencialidade é a exfiltração de dados.
Existem várias formas como um interveniente malicioso pode tentar usar um pipeline de implementação para filtrar dados dos seus recursos Google Cloud . Estas formas incluem:
- Direta: um autor malicioso pode modificar o pipeline de implementação ou a respetiva configuração para extrair dados dos seus recursos Google Cloude, em seguida, copiá-los para outro local.
- Indireto: um interveniente malicioso pode usar o pipeline de implementação para implementar código comprometido, que rouba dados do seu ambiente. Google Cloud
Pode reduzir os riscos de confidencialidade minimizando o acesso a recursos confidenciais. No entanto, pode não ser prático remover todo o acesso a recursos confidenciais. Por conseguinte, tem de conceber o pipeline de implementação de forma a cumprir as exigências de confidencialidade dos recursos que gere. Para determinar estas exigências, pode usar a seguinte abordagem:
- Determine os dados, as aplicações e os recursos aos quais o pipeline de implementação precisa de aceder e categorize-os.
- Encontre o recurso com a categoria de confidencialidade mais elevada e use-o como categoria inicial para o pipeline de implementação.
Semelhante ao processo de categorização de aplicações e recursos na nuvem, esta avaliação inicial nem sempre é adequada. Por exemplo, pode usar um pipeline de implementação para criar recursos que, eventualmente, vão conter informações altamente confidenciais. Se restringir o pipeline de implementação para que possa criar, mas não ler, estes recursos, uma categoria de confidencialidade inferior pode ser suficiente.
Para manter a confidencialidade, o modelo Bell-LaPadula sugere que um pipeline de implementação não deve:
- Consumir artefactos de entrada de maior confidencialidade
- Escrever dados num recurso de confidencialidade inferior
De acordo com o modelo Bell-LaPadula, o diagrama anterior mostra como os dados devem fluir no pipeline para ajudar a garantir a confidencialidade dos dados.
Não permita que os pipelines de implementação leiam dados de que não precisam
Normalmente, os pipelines de implementação não precisam de acesso aos dados, mas podem continuar a tê-lo. Esta concessão excessiva de acesso pode resultar do seguinte:
- Conceder autorizações de acesso incorretas. Por exemplo, pode ser concedido acesso a um pipeline de implementação ao Cloud Storage ao nível do projeto. Como resultado, o pipeline de implementação pode aceder a todos os contentores do Cloud Storage no projeto, embora o acesso a um único contentor possa ser suficiente.
- Usar uma função demasiado permissiva. Por exemplo, pode ser concedida a um pipeline de implementação uma função que forneça acesso total ao Cloud Storage. No entanto, a autorização para criar novos contentores seria suficiente.
Quanto mais dados um pipeline conseguir aceder, maior é o risco de alguém ou algo roubar os seus dados. Para ajudar a minimizar este risco, evite conceder às pipelines de implementação acesso a dados de que não precisam. Muitos pipelines de implementação não precisam de acesso a dados, porque o seu único objetivo é gerir implementações de software ou de configuração.
Não permita que os pipelines de implementação escrevam em localizações de que não precisam
Para remover dados, um interveniente malicioso precisa de acesso e de uma forma de transferir os dados para fora do seu ambiente. Quanto mais locais de armazenamento e de rede um pipeline de implementação puder enviar dados, maior é a probabilidade de um agente malicioso poder usar um desses locais para exfiltração.
Pode ajudar a reduzir o risco limitando o número de localizações de rede e armazenamento onde um pipeline pode enviar dados:
- Revogue o acesso de escrita a recursos que o pipeline não necessita, mesmo que os recursos não contenham dados confidenciais.
- Bloquear o acesso à Internet ou restringir as ligações a um conjunto de localizações de rede na lista de autorizações.
Restringir o acesso de saída é particularmente importante para pipelines que categorizou como moderadamente confidenciais ou altamente confidenciais, porque têm acesso a dados confidenciais ou material de chaves criptográficas.
Use os VPC Service Controls para ajudar a impedir que implementações comprometidas roubem dados
Em vez de permitir que o pipeline de implementação realize a exfiltração de dados, um ator malicioso pode tentar usar o pipeline de implementação para implementar código comprometido. Em seguida, esse código comprometido pode roubar dados do seu ambiente Google Cloud.
Pode ajudar a reduzir o risco de tais ameaças de roubo de dados através dos VPC Service Controls. Os VPC Service Controls permitem-lhe restringir o conjunto de recursos e APIs que podem ser acedidos a partir de determinadosGoogle Cloud projetos.
Mantenha a integridade
Para manter o seu Google Cloud ambiente seguro, tem de proteger a sua integridade. Isto inclui:
- Impedir a modificação ou a eliminação não autorizada de dados ou da configuração
- Impedir a implementação de código ou configuração não fidedignos
- Garantir que todas as alterações deixam um registo de auditoria claro
Os pipelines de implementação podem ajudar a manter a integridade do seu ambiente, permitindo-lhe:
- Implemente processos de aprovação, por exemplo, sob a forma de revisões de código
- Aplique um processo consistente para todas as alterações de configuração ou código
- Executar testes automatizados ou verificações rápidas antes de cada implementação
Para serem eficazes, tem de tentar garantir que os intervenientes mal-intencionados não conseguem prejudicar nem contornar estas medidas. Para impedir esta atividade, tem de proteger a integridade do seguinte:
- A pipeline de implementação e a respetiva configuração
- A infraestrutura subjacente
- Todas as entradas consumidas pelo pipeline de implementação
Para evitar que o pipeline de implementação fique vulnerável, tente garantir que os padrões de integridade do pipeline de implementação correspondem ou excedem as exigências de integridade dos recursos que gere. Para determinar estas exigências, pode usar a seguinte abordagem:
- Determine os dados, as aplicações e os recursos aos quais o pipeline de implementação precisa de aceder e categorize-os.
- Encontre o recurso com a categoria de integridade mais elevada e use-o como a categoria para o pipeline de implementação.
Para manter a integridade do pipeline de implementação, o modelo Biba sugere que:
- O pipeline de implementação não pode consumir artefactos de entrada com integridade inferior.
- O pipeline de implementação não pode escrever dados num recurso de integridade superior.
De acordo com o modelo Biba, o diagrama anterior mostra como os dados devem fluir no pipeline para ajudar a garantir a integridade dos dados.
Valide a autenticidade dos artefactos de entrada
Muitos pipelines de implementação consomem artefactos de origens de terceiros. Estes artefactos podem incluir:
- Imagens base do Docker
.rpmou.deb- Bibliotecas Maven,
.npmou NuGet
Um interveniente malicioso pode tentar modificar o seu pipeline de implementação para que use versões comprometidas de artefactos de terceiros das seguintes formas:
- Comprometer o repositório que armazena os artefactos
- Modificar a configuração do pipeline de implementação para usar um repositório de origem diferente
- Carregar pacotes maliciosos com nomes semelhantes ou nomes que contenham gralhas
Muitos gestores de pacotes permitem-lhe validar a autenticidade de um pacote através do suporte de assinatura de código. Por exemplo, pode usar o PGP para assinar pacotes RPM e Maven. Pode usar o Authenticode para assinar pacotes NuGet.
Pode usar a assinatura de código para reduzir o risco de ser vítima de pacotes de terceiros comprometidos das seguintes formas:
- Exigir que todos os artefactos de terceiros estejam assinados
- Manter uma lista organizada de certificados ou chaves públicas de publicadores fidedignos
- Permitir que o pipeline de implementação valide a assinatura de artefactos de terceiros com base na lista de publicadores fidedignos
Em alternativa, pode validar os hashes dos artefactos. Pode usar esta abordagem para artefactos que não suportam a assinatura de código e que mudam com pouca frequência.
Certifique-se de que a infraestrutura subjacente cumpre as suas exigências de integridade
Em vez de comprometer o próprio pipeline de implementação, os intervenientes maliciosos podem tentar comprometer a respetiva infraestrutura, incluindo:
- O software de CI/CD que executa o pipeline de implementação
- As ferramentas usadas pelo pipeline, por exemplo, Terraform, kubectl ou Docker
- O sistema operativo e todos os respetivos componentes
Uma vez que a infraestrutura subjacente aos pipelines de implementação é frequentemente complexa e pode conter componentes de vários fornecedores ou fontes, este tipo de violação de segurança pode ser difícil de detetar.
Pode ajudar a reduzir o risco de infraestrutura comprometida:
- Manter a infraestrutura e todos os respetivos componentes nos mesmos padrões de integridade que o pipeline de implementação e os Google Cloud recursos que gere
- Certificar-se de que as ferramentas são provenientes de uma fonte fidedigna e verificar a respetiva autenticidade
- Reconstruir regularmente a infraestrutura do zero
- Executar o pipeline de implementação em VMs protegidas
Aplique controlos de integridade no pipeline
Embora os autores de ataques sejam uma ameaça, não são a única fonte possível de software ou alterações de configuração que podem prejudicar a integridade do seu ambienteGoogle Cloud . Estas alterações também podem ter origem nos programadores e ser simplesmente acidentais, devido a desconhecimento ou ao resultado de erros ortográficos e outros erros.
Pode ajudar a reduzir o risco de aplicar inadvertidamente alterações arriscadas configurando pipelines de implementação para aplicar controlos de integridade adicionais. Estes controlos podem incluir:
- Realizar a análise estática do código e da configuração
- Exigir que todas as alterações passem por um conjunto de regras (política como código)
- Limitar o número de alterações que podem ser feitas em simultâneo
O que se segue?
- Saiba mais sobre as nossas práticas recomendadas para usar contas de serviço em pipelines de implementação.
- Reveja as nossas práticas recomendadas para proteger contas de serviço.
- Saiba mais sobre como Investigar e responder a ameaças.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.