Proteja a sua cadeia de abastecimento de imagens de contentores
Como proteger a sua cadeia de abastecimento de software?
Proteger a sua cadeia de abastecimento de software significa controlar cada artefacto entre uma submissão de código e a produção. Em pipelines contentorizados, resume-se a quatro controlos: um registo privado com RBAC, verificação de CVE, assinatura criptográfica e uma política que bloqueia imagens não assinadas ou vulneráveis na implementação.
Porque é que os ataques à cadeia de abastecimento visam agora as suas imagens de contentores
SolarWinds, Log4Shell, xz-utils: o pipeline de compilação é o novo perímetro
Os incidentes de segurança de software mais graves dos últimos anos não começaram com uma quebra de firewall ou uma palavra-passe roubada. Começaram dentro da própria cadeia de abastecimento de software.
- SolarWinds: o sistema de compilação foi comprometido para injetar código malicioso em atualizações de software assinadas, chegando a agências governamentais dos Estados Unidos e a milhares de clientes empresariais a jusante.
- Log4Shell: um componente de código aberto vulnerável, enterrado numa árvore de dependências partilhada por inúmeros projetos, tornou-se uma vulnerabilidade grave que os atacantes exploraram em milhares de organizações não relacionadas ao mesmo tempo.
- xz-utils: o ambiente de compilação de um responsável pela manutenção de pacotes de confiança tornou-se um vetor de ataque, dado um atacante suficientemente paciente para explorar anos de confiança acumulada.
O padrão é o mesmo nos três casos. O processo de compilação, e não a aplicação em execução, foi o ponto de compromisso.
Uma imagem de contentor é o último artefacto antes de o resultado da compilação chegar à produção. É também o último local prático para detetar um componente comprometido e as suas dependências antes de um exploit causar danos.
Porque é que o Docker Hub e os registos públicos não são suficientes
Um registo público é público por predefinição, a menos que pague por repositórios privados. Não possui RBAC por equipa, não tem aplicação de política de CVE, nem verificação de assinatura no momento da extração (pull).
Isso não é uma lacuna de funcionalidade que se corrige. É um tipo de produto diferente.
Os registos públicos existem para distribuir software de código aberto a qualquer consumidor que o pretenda. O autor do pacote e o consumidor do pacote nunca se encontram, e nenhum dos dois consegue verificar muito sobre o outro.
Controlar exatamente que imagens de software os clusters Kubernetes da sua organização têm permissão para extrair é um problema completamente diferente.
Um registo privado genérico sem uma postura de segurança documentada também não reduz o risco da cadeia de abastecimento de software. O risco é concreto: um ataque que coloque um componente malicioso numa imagem infeta todos os clusters que a extraem.
Esse risco agrava-se com cada equipa que partilha o registo. Sem uma análise sistemática, sem uma camada de política e sem um rasto de auditoria de quem enviou o quê, quando, e se foi assinado, moveu imagens de um registo público sem reduzir o risco.
A perspetiva da conformidade: ISO 27001, SOC 2 e indústrias reguladas
As equipas de segurança raramente obtêm orçamento para este trabalho até que uma auditoria o force. As auditorias de conformidade tratam as imagens de contentores não analisadas como uma descoberta crítica, não como uma sugestão.
A segurança é uma postura que se mantém, não um produto que se compra, e um auditor testa a postura em vez da lista de ferramentas. A segurança da cadeia de abastecimento de software é avaliada como um conjunto de práticas, e cada prática necessita de provas.
A ISO 27001, a SOC 2 e a maioria das normas de segurança de indústrias reguladas, muitas desenvolvidas com agências governamentais e organismos de orientação da indústria, esperam uma análise de vulnerabilidades e um controlo de acesso documentados e sistemáticos em qualquer software que chegue à produção. As imagens de contentores são artefactos de produção como quaisquer outros.
As imagens de contentores também armazenam código de aplicação, configuração e, por vezes, variáveis de ambiente. As permissões de registo são, portanto, um controlo de acesso sobre propriedade intelectual de software sensível.
Estas são exatamente o tipo de melhores práticas de segurança que um auditor espera ver documentadas, e não assumidas.
A prática recomendada em todos os conjuntos de orientações publicados, desde a CISA até à CNCF, é a mesma, e vale a pena aprendê-la antes que uma auditoria o obrigue a tal:
• Faça de cada controlo uma prática documentada com um responsável nomeado.
• Proteja o ambiente de compilação com o mesmo cuidado que o ambiente de execução.
• Mantenha as dependências atualizadas para que vulnerabilidades conhecidas não se acumulem.
Os auditores querem provas para cada um destes pontos, e o hub Identity, Security & Operations da OVHcloud cobre os serviços que as geram.
Os quatro controlos de que cada pipeline contentorizado necessita
Uma estrutura como a SLSA (Supply-chain Levels for Software Artifacts) oferece às equipas uma forma estruturada de medir a maturidade destes controlos. Não precisa de adotar uma estrutura completa para obter o benefício prático.
Os níveis SLSA são principalmente úteis como uma linguagem comum com auditores e parceiros, e vale a pena aprender sobre a SLSA só por isso. Um parceiro externo declara o seu nível, compara-o com o seu e ninguém envia um longo questionário.
Os fornecedores publicam cada vez mais um, pelo que pedir o de um parceiro é uma questão de aquisição normal.
A análise estática, ou SAST, é executada no código-fonte antes de qualquer coisa ser compilada. Deteta uma classe diferente de vulnerabilidades do que a análise de imagens, e pertence a uma fase anterior da cadeia, juntamente com a análise de composição de software nas suas dependências.
O SAST e a análise de imagens são complementos, não substitutos. Nenhum deteta o que o outro foi concebido para encontrar. Três camadas cobrem toda a cadeia:
1. Execute o SAST no seu próprio código-fonte.
2. Execute a análise de composição de software em dependências externas.
3. Execute a análise de imagens no artefacto compilado.
Ignore um dos três e deixará uma classe inteira de vulnerabilidades por medir, independentemente do que as outras ferramentas reportem.
Os quatro controlos abaixo entram em ação no momento em que uma compilação produz uma imagem de contentor, o artefacto central na cadeia.
Armazene imagens num registo privado controlado por RBAC
O controlo fundamental de uma cadeia de abastecimento de software segura é um registo fechado por predefinição, com RBAC por projeto ou por equipa. Não um repositório partilhado onde todos podem publicar, nem um registo público com imagens visíveis por predefinição.
As contas de robô fazem o resto do trabalho:
• Limite cada conta de robô a um único projeto.
• Atribua às etapas de compilação permissões de envio apenas de escrita e às etapas de implementação permissões de leitura apenas de leitura.
• Execute um projeto por equipa, para que um projeto comprometido permaneça contido.
• Aplique uma política central em todos os projetos, auditada centralmente.
• Mantenha as credenciais pessoais e de administrador totalmente fora das compilações automatizadas.
Analise cada imagem em busca de CVEs no envio e na extração
A análise de vulnerabilidades tem de ocorrer em dois pontos:
• No envio, para que uma nova imagem seja analisada no momento em que é compilada.
• Na extração, para que uma verificação de política seja executada novamente antes de uma imagem mais antiga ser implementada contra uma base de dados de vulnerabilidades mais recente.
Uma imagem que estava limpa em março pode conter três vulnerabilidades conhecidas em junho, e apenas uma verificação no momento da extração as detetará.
A análise assíncrona no envio não atrasa a compilação. A análise é executada em paralelo enquanto o pipeline continua, e os resultados estão disponíveis antes de a imagem ser promovida para produção.
Assine artefactos com Cosign ou Notary v2
Assinar uma imagem regista criptograficamente quem a criou e confirma que não foi adulterada em trânsito. Estabelece uma cadeia de confiança desde o sistema de compilação até ao cluster.
A confiança é o que um atacante está realmente a visar. A porta dos fundos do xz-utils funcionou porque a confiança num responsável tinha-se acumulado durante anos, e os atacantes são suficientemente pacientes para explorar um responsável em vez de uma firewall.
O Cosign, parte do projeto Sigstore, e o Notary v2 são as duas abordagens de código aberto dominantes para a assinatura de imagens de contentores atualmente.
Sem uma assinatura e uma política que a verifique, não há forma de provar após um incidente que a imagem em execução na produção é o artefacto exato que o seu pipeline construiu. Uma imagem não assinada e uma imagem adulterada são indistinguíveis no momento da implementação.
Aplique uma política de implementação antes de as imagens chegarem ao Kubernetes
A análise e a assinatura só importam se algo as aplicar. Um controlador de admissão do Kubernetes, sendo o Kyverno ou o OPA Gatekeeper as duas escolhas comuns, verifica cada imagem no momento da implementação e rejeita qualquer coisa que não cumpra a política:
• CVE críticas não resolvidas.
• Uma assinatura Cosign em falta ou inválida.
• Uma imagem de um registo não aprovado.
Esse é o controlo que torna os outros aplicáveis, e aquele que um ataque tem de derrotar. Transforma a análise de imagens de uma métrica reportada numa barreira rígida, para que nenhuma imagem não analisada chegue à produção, o que é o requisito de conformidade real.
Os dois pontos de aplicação são complementares. O registo bloqueia o envio, o cluster bloqueia a implementação, e um ataque que ultrapasse um ainda encontra o outro. Ambos assentam sobre um cluster que não tem de gerir quando utiliza o Managed Kubernetes Service da OVHcloud.
Estes quatro controlos técnicos existem paralelamente, e não em substituição, às práticas organizacionais que reduzem o risco de forma mais abrangente. Práticas deste tipo são baratas comparadas com um incidente, e cada uma é uma prática que um auditor pode verificar.
Estas são as práticas que transformam um design seguro num sistema seguro, e cada uma é uma prática central, não um extra opcional:
• Atualize regularmente as dependências e os componentes de terceiros para se proteger contra exploits conhecidos.
• Limite o acesso a sistemas de compilação sensíveis e a chaves de assinatura.
• Eduque os colaboradores e realize formação de sensibilização para a segurança, para que os engenheiros reconheçam um pacote comprometido ou uma tentativa de phishing contra uma conta de responsável.
• Realize exercícios com base num plano de resposta a incidentes, para que uma equipa saiba como responder rapidamente quando um controlo falha.
• Verifique a integridade do software continuamente em vez de a assumir, para que cada artefacto permaneça protegido por uma verificação e não por hábito.
Qualquer lacuna de segurança potencial nesta lista é, normalmente, uma lacuna de processo e não uma lacuna de ferramentas.
Cada componente de software que importa, e cada componente transitivo abaixo dele, é uma decisão que alguém tomou uma vez e que raramente volta a analisar. Uma aplicação moderna inclui centenas desses componentes, a maioria de uma entidade externa que ninguém conhece.
O inventário de componentes é, portanto, a prática da qual tudo o resto depende. A gestão de dependências, saber que software e que componentes provêm de terceiros, é o que torna um SBOM (lista de materiais de software) útil depois de o ter.
Um SBOM lista todos os componentes e todas as versões, o que transforma um novo aviso de CVE numa consulta de cinco minutos em vez de uma semana de arqueologia. Sem um, a resposta honesta sobre se está exposto é que ninguém sabe.
Como o OVHcloud Managed Private Registry fecha a lacuna
O Harbor por dentro: Graduado pela CNCF, norma OCI, código aberto
Managed Private Registry é uma instância totalmente gerida do Harbor, uma tecnologia de código aberto graduada pela CNCF, criada para o armazenamento de contentores e gráficos Helm, com a segurança como uma funcionalidade de primeira classe e não como um complemento.
Autogerir o Harbor significa executar e aplicar patches ao PostgreSQL, Redis, serviços principais do Harbor e ao scanner, além de TLS e atualizações em cada um desses componentes.
A OVHcloud remove essa camada operacional. Cria um registo, envia imagens e configura a política, enquanto a infraestrutura do Harbor subjacente é da responsabilidade da OVHcloud. Isso liberta a sua equipa de cibersegurança para a modelação de ameaças e resiliência da cadeia de abastecimento, em vez de aplicar patches a uma base de dados.
Como o Harbor é de código aberto e baseado em normas, não existe dependência de fornecedor. As imagens residem no formato OCI padrão, pelo que a migração para um Harbor autogerido ou outro registo compatível com OCI não necessita de qualquer passo de conversão nem de qualquer formato de extração proprietário a reverter.
Essa transparência é, por si só, uma propriedade de segurança. Uma comunidade global de revisores, e não um único fornecedor, revê o código que executa o seu registo.
Um projeto central com muitos revisores deteta um compromisso malicioso mais rapidamente do que um fechado, e a inteligência de ameaças sobre vulnerabilidades do Harbor ou do Trivy chega até si através dos mesmos canais públicos em que todos os outros utilizadores confiam.
Análise de vulnerabilidades com Trivy: Deteção de CVE no envio e na extração
O OVHcloud Managed Private Registry inclui o Trivy, o scanner integrado do Harbor, ativado ao nível do projeto.
Configure a análise no envio (scan-on-push) para que cada imagem seja verificada assim que chega, e depois defina um limiar de gravidade de CVE. Avisar em ALTA, bloquear em CRÍTICA é uma política inicial recomendada.
Uma análise no momento da extração (pull) verifica novamente uma imagem mais antiga contra uma base de dados de vulnerabilidades mais recente.
Uma política de implementação do Harbor impede a extração de imagens com CVEs CRÍTICAS não resolvidas para espaços de nomes de produção, o que torna o resultado da análise acionável em vez de informativo.
Assinatura de imagens com Cosign e Notary v2
O serviço baseia-se no Harbor, pelo que suporta a análise de vulnerabilidades e o armazenamento de gráficos Helm documentados para o produto.
A assinatura de imagens é efetuada através de ferramentas de código aberto Cosign padrão no seu pipeline CI/CD, apontando para o registo da OVHcloud em vez de um serviço de assinatura proprietário.
Aplicação de políticas: bloquear imagens com CVEs críticos antes da implementação
A política do lado do registo, bloquear em caso de CVE CRÍTICO e exigir uma assinatura válida, é apenas metade da história da aplicação.
A outra metade é executada no próprio Kubernetes. Uma política de admissão Kyverno ou OPA Gatekeeper rejeita qualquer imagem sem uma assinatura Cosign válida, ou com uma vulnerabilidade grave não resolvida, independentemente de como foi implementada ou por que interveniente.
Juntos, proporcionam um bloqueio de CVE aplicado por política de ponta a ponta. É uma configuração que define deliberadamente, não uma garantia automática.
Armazenamento de Helm charts (compatível com OCI)
Os Helm charts são armazenados no mesmo formato compatível com OCI que as imagens de contentores, na mesma estrutura de projeto, com as mesmas contas RBAC e robot.
As equipas que empacotam implementações como Helm charts obtêm um único registo para ambos os tipos de artefactos, em vez de um repositório de charts separado para proteger e manter.
Ligar o seu pipeline CI/CD (GitHub Actions, GitLab CI, Tekton)
Contas de robô: envio apenas de escrita para compilações, extração apenas de leitura para implementações
Crie um projeto Harbor por equipa ou aplicação e, em seguida, emita contas de robô limitadas exatamente ao que cada fase necessita: push apenas de escrita para a fase de compilação, pull apenas de leitura para a fase de implementação.
Nunca incorpore credenciais de administrador ou pessoais, ou o ficheiro de chave de uma conta
de robô, numa definição de compilação. Uma conta de robô apenas de leitura comprometida é um incidente contido. Uma credencial de administrador divulgada nas mãos de um agente externo não o é.
Para chaves de assinatura Cosign especificamente, o OVHcloud Key Management Service suporta a utilização da sua própria chave (bring-your-own-key) com armazenamento baseado em HSM FIPS 140-2, o que mantém as suas chaves fora dos portáteis dos programadores e dos executores de CI.
Exemplo de GitHub Actions: compilar, analisar, assinar e enviar
Uma única fase cobre todo o controlo:
1. Crie a imagem.
2. Envie-a com uma conta de robô de escrita apenas.
3. Aguarde pelo resultado da análise do Trivy.
4. Assine com o Cosign apenas se a análise cumprir o limite de CVE configurado.
Esta sequência mantém uma barreira rígida entre a existência de uma imagem e uma imagem ser suficientemente fiável para ser assinada, em vez de assinar incondicionalmente no momento da compilação.
O mesmo padrão aplica-se quer a compilação seja executada no GitHub Actions, GitLab CI ou Tekton. Apenas a sintaxe para chamar o registo e o scanner muda, independentemente da linguagem de programação em que a sua aplicação está escrita.
Políticas de admissão Kyverno no Managed Kubernetes Service
No Managed Kubernetes Service da OVHcloud, uma política Kyverno, definida como um ficheiro de política Kubernetes padrão, verifica cada especificação de pod recebida quanto a uma assinatura Cosign válida e rejeita a implementação se a assinatura estiver em falta ou for inválida.
Combinado com a política de CVE do lado do registo, isto fecha o ciclo entre o que constrói e o que o cluster pode executar. Uma imagem não assinada ou não analisada nunca arranca, independentemente de quem solicitou a implementação.
Cadeia de abastecimento soberana: porque é que a jurisdição do seu registo importa
As imagens de contentor transportam PI, e com elas a exposição à CLOUD Act
Uma imagem de contentor agrupa código de aplicação, camadas de configuração e, por vezes, variáveis de ambiente: uma fatia significativa da propriedade intelectual da sua organização. Um registo central é onde essa propriedade intelectual se concentra, e é por isso que a sua jurisdição é importante. Armazenar essa imagem com um fornecedor sediado nos EUA, mesmo um com centros de dados na UE, coloca-a sob a jurisdição da CLOUD Act dos EUA, porque a exposição segue a empresa-mãe, não o local de armazenamento. A mesma lógica aplica-se a qualquer implementação de AWS ECR, Google Artifact Registry ou Docker Hub: A jurisdição da CLOUD Act dos EUA aplica-se independentemente da região.
Sede europeia, sem empresa-mãe nos EUA, RGPD por jurisdição
Uma imagem de contentor agrupa código de aplicação, camadas de configuração e, por vezes, variáveis de ambiente: uma fatia significativa da propriedade intelectual da sua organização.
Um registo central é onde essa propriedade intelectual se concentra, e é por isso que a sua jurisdição é importante.
Armazenar essa imagem com um fornecedor sediado nos EUA, mesmo um com centros de dados na UE, coloca-a sob a jurisdição da CLOUD Act dos EUA, porque a exposição segue a empresa-mãe e não a localização do armazenamento.
O mesmo se aplica a qualquer registo operado por um fornecedor com sede nos EUA: A jurisdição da CLOUD Act dos EUA aplica-se independentemente da região.
Sede europeia, sem empresa-mãe nos EUA, RGPD por jurisdição
A OVHcloud é um operador europeu sem empresa-mãe nos EUA, pelo que não existe exposição estrutural ao CLOUD Act em nada do que está armazenado no registo.
A infraestrutura do registo funciona ao abrigo do RGPD por jurisdição e não por compromisso político.
A proteção jurídica advém do local onde a empresa e a infraestrutura se encontram, e não de uma promessa contratual sobreposta a uma infraestrutura que uma autoridade estrangeira ainda poderia obrigar.
Caminho de ponta a ponta: Managed Private Registry para Managed Kubernetes Service
Crie um projeto de Registo Privado Gerido, envie uma imagem e ative a análise e a assinatura. O MKS Free cobre o desenvolvimento e a fase de testes sem custos, para que possa validar toda a cadeia de políticas antes de o tráfego de produção depender dela. Para múltiplos clusters de produção, setores regulados ou conjuntos de nós GPU, um Arquiteto de Soluções da OVHcloud ajudará a dimensioná-lo. O centro de orquestração de contentores é o local onde pode aprender o resto.
Disponibilidade 3-AZ em Paris e Milão, SLA de disponibilidade de 99,99% no MKS Standard
O registo funciona em 3-AZ em Paris com alta disponibilidade integrada. Uma falha numa única zona não interrompe as suas compilações nem as suas implementações, o que é importante porque uma interrupção do registo bloqueia ambas.
O Managed Kubernetes Service Standard funciona em 3-AZ em Paris e Milão com um SLA de disponibilidade de 99,99%, pelo que o registo e o cluster que dele retira dados partilham a mesma postura de disponibilidade, em vez de um ser o elo mais fraco.
MKS Free para começar, MKS Standard para produção
O Managed Kubernetes Service tem um nível gratuito para desenvolvimento e testes, suficiente para validar toda a cadeia de fornecimento de software: registo, análise, assinatura e política de admissão, antes de se comprometer com um cluster de produção.
A fixação de versões nos seus ficheiros de política mantém essa validação reproduzível.
Quando estiver pronto para o tráfego de produção, o MKS Standard adiciona o nível 3-AZ com um SLA de disponibilidade de 99,99%, e as mesmas políticas Kyverno ou OPA Gatekeeper transitam inalteradas entre ambos os níveis.
As equipas que executam vários clusters adicionam o Managed Rancher Service por cima para um plano de controlo único entre eles.
Comece agora: ative o seu registo e envie imagens seguras hoje mesmo
Crie um projeto de Registo Privado Gerido, envie uma imagem e ative a análise e a assinatura. O MKS Free cobre o desenvolvimento e a fase de testes sem custos, para que possa validar toda a cadeia de políticas antes de o tráfego de produção depender dela. Para múltiplos clusters de produção, setores regulados ou conjuntos de nós GPU, um Arquiteto de Soluções da OVHcloud ajudará a dimensioná-lo. O hub de orquestração de contentores é o local onde pode aprender o resto.