A segurança nativa da nuvem estava no ar na KubeCon/CloudNativeCon 2022

Como um cinéfilo que se identifica, algumas falas de filmes de alguma forma ficaram comigo ao longo dos anos. Um deles é do Ridley Scott Gladiador (2000), quando um senador romano diz: “O coração pulsante de Roma não é o mármore do Senado, é a areia do Coliseu”.

Essa frase surgiu na minha cabeça enquanto eu andava pelos corredores da KubeCon/CloudNativeCon (“KubeCon”), o principal evento do Fundação de Computação Nativa em Nuvem (CNCF). Para mim, o coração da segurança nativa da nuvem é definitivamente o KubeCon.

A edição norte-americana deste ano do evento aconteceu na semana passada em Detroit, reunindo milhares de participantes no local e muitos outros remotamente. Além do evento principal de três dias, o crescente interesse em projetos específicos levou a Cloud Native Computing Foundation a organizar vários “eventos co-localizados” antes da conferência principal.

Para o evento de 2022, não houve apenas um evento específico de dois dias CloudNativeSecurityCon, mas também muito conteúdo de segurança em outros eventos, incluindo Application Networking Day, EnvoyCon, Policy Day with OPA, ServiceMeshCon e muito mais, refletindo o amplo interesse na nuvem. tópicos de segurança nativos. Curiosamente, o evento CloudNativeSecurityCon agora “passou” para um evento independente a ser realizado separadamente em fevereiro.

Segurança nativa da nuvem: desenvolvimento versus operações

Então, onde está o estado atual das conversas sobre segurança nativa da nuvem? Para Omdia, existe uma forte bifurcação: preocupações centradas no desenvolvimento e preocupações centradas nas operações. Não é tão útil chamá-los de “Desenvolvimento” e “Ops” porque a estrutura da equipe está mudando em muitas organizações: algumas podem ter equipes de engenharia de confiabilidade de site (SRE), outras podem chamá-las de operações, equipes de plataforma e muito mais.

No lado do desenvolvimento do livro-razão, três tópicos de interesse são proveniência, ruído e exposição.

A proveniência faz a pergunta fundamental: podemos confiar na integridade do componente externo que incorporamos em nosso pipeline de software? Embora existam muitos exemplos, o ataque à SolarWinds em 2020 foi um ponto de viragem no interesse na integridade da cadeia de fornecimento de software. Na KubeCon, houve um impulso palpável por trás da ideia de assinar imagens de software: loja de assinatura O projeto foi anunciado como disponibilidade geral e está sendo usado pelo Kubernetes e outros projetos importantes.

Ruído refere-se à redução do número de vulnerabilidades existentes no ambiente, começando pela redução das imagens base do contêiner que estão sendo usadas. Isso pode incluir o uso de bases de imagens como Alpine ou Debian Slim ou considerar alternativas “sem distribuição” ainda menores. A vantagem é que essas imagens menores ocupam um espaço mínimo e, portanto, reduzem a chance de surgimento de vulnerabilidades.

Exposição: Para qualquer vulnerabilidade, quão expostos estamos como organização? Não há melhor exemplo disso na história recente da indústria do que o Log4j, é claro. Este é o campo das discussões sobre listas de materiais de software (SBOMs), no que se refere a saber onde os componentes podem ser usados, seja como imagens armazenadas em um registro em algum lugar ou em execução na produção. Curiosamente, enquanto este ensaio está sendo escrito, há aviso prévio de que informações sobre vulnerabilidades críticas no OpenSSL 3.x serão divulgadas em breve, o que provavelmente será outro bom caso de uso para SBOMs — exatamente onde o OpenSSL 3.x é usado em nossa organização? Dado que a cobertura do SBOM ainda não está generalizada, a Omdia espera uma utilização mínima do SBOM desta vez, infelizmente.

As equipes de operações estão naturalmente focadas em fornecer e operar uma plataforma subjacente cada vez mais complexa e fazê-lo com segurança. A palavra “plataforma” é particularmente relevante aqui: houve um interesse notável em organizar o Kubernetes e muitos da lista crescente de projetos CNCF (140 no momento da redação deste artigo, entre os vários estágios de incubação do projeto: sandbox, incubação, graduado) em mais fáceis. plataformas para consumo. De interesse específico para públicos de segurança, projetos como Cilium (usando a funcionalidade subjacente eBPF) para redes e observabilidade, SPIFFE/SPIRE (para estabelecer identidades), Falco (para segurança em tempo de execução), Open Policy Agent (para política como código) , Cloud Custodian (para governança) e outros, vale a pena examinar. A expectativa é que esses projetos colaborem cada vez mais com aspectos de “observabilidade” do cloud-native e também sejam implantados utilizando práticas como GitOps.

Razões para otimismo em relação à segurança nativa da nuvem

Para onde vamos daqui? Ficou bastante claro que a comunidade nativa da nuvem se preocupa profundamente com a segurança e está avançando a todo vapor no tratamento dos vários tópicos em torno dela. A orientação para as equipes de segurança é saber rapidamente como esses diferentes projetos e iniciativas estão sendo implementados. É importante observar que, para muitas organizações, isso não ocorrerá na forma de uso explícito do projeto comunitário (embora algumas o façam), mas sim como parte de um pacote de plataforma de fornecedores como Red Hat, SUSE, Canonical e outros. ou diretamente de provedores de nuvem como AWS, Google Cloud, Azure, Oracle e outros.

Esteja ciente de que, no contexto do uso de código aberto, não existe algo realmente “gratuito” — mesmo que alguém opte por usar a versão original dos projetos, há custos inerentes à manutenção desses pacotes e à participação no desenvolvimento da comunidade.