Práticas recomendadas de segurança de aplicações para seu pipeline de DevOps
Práticas recomendadas de segurança de aplicativos em um ambiente de microsserviços nativo da nuvem
Uma arquitetura de microsserviços nativa da nuvem adiciona complexidade ao pipeline de DevOps devido ao desacoplamento. Com os microsserviços, você tem centenas de atualizações independentes se movendo pelo seu pipeline, o que significa que você tem muitos aplicativos “lógicos” sendo atualizados durante todo o dia. Rastrear o que está sendo enviado aos usuários finais se torna mais difícil.
Rastreie os insights de segurança para o aplicativo lógico completo
As práticas recomendadas de segurança de aplicativos em um ambiente de microsserviço nativo da nuvem são muito mais complexas em comparação com o desenvolvimento monolítico tradicional. Uma arquitetura desacoplada requer o rastreamento de um aplicativo lógico e a agregação de todos os insights de segurança.
No desenvolvimento tradicional, executamos nossa compilação que monta estaticamente fontes e bibliotecas. Geramos nosso aplicativo Software Bill of Material (SBOM) e atribuímos um número de versão à compilação. A SBOM mostra uma lista abrangente de todos os artefatos usados. Os CVEs são rastreados com base na compilação do aplicativo. Podemos comparar duas versões de aplicativos e entender o que mudou.
Em uma arquitetura desacoplada, as compilações são dispersas em todos os microsserviços. O aplicativo agora se torna uma composição lógica dos microsserviços necessários. Uma atualização de microsserviço é igual à execução de uma compilação tradicional, mas passa despercebida. De repente, o aplicativo lógico é diferente, mas não há número de versão, SBOM, CVE ou relatório de diferença para mostrar o que mudou ou por que os usuários finais agora estão enfrentando problemas.
O desafio de segurança de aplicativos mais difícil para o pipeline de DevOps é a capacidade de capturar automaticamente quando o aplicativo lógico foi afetado por um microsserviço atualizado. Uma atualização de microsserviço deve ser propagada para o nível de aplicativo lógico criando um novo número de versão, SBOM e CVE para refletir a alteração.
Para atender ao pedido de SBOM de 2022 do governo Biden, as equipes precisarão entregar um SBOM que agregue todos os SBOMs de microsserviço ao nível de aplicativo lógico quando uma alteração for entregue. Para atingir esse nível de relatórios de SBOM, o pipeline de DevOps precisará rastrear automaticamente o aplicativo lógico e criar uma versão de lançamento do aplicativo, SBOM e CVE para cada alteração. E lembre-se, uma única atualização de microsserviço pode afetar vários aplicativos lógicos. Não só isso, os microsserviços são entregues durante todo o dia. A automação do microsserviço para atualizações de aplicativos será um componente essencial das práticas recomendadas de segurança do aplicativo em uma arquitetura de microsserviços.
Consolide insights abrangentes e completos
A criação de software à prova de violação requer a geração de vários tipos de insights de segurança. A maioria desses insights, como o SBOMS, é gerada como parte do pipeline de DevOps, mas deixada sob o capô em um log ou exibida em vários painéis em todo o ambiente. Em um ambiente nativo da nuvem, há centenas desses logs e relatórios, gerados para cada nova compilação de um microsserviço. Os dados são importantes.
A geração de logs de segurança, como SBOMs e resultados CVE, é a primeira etapa, mas consumir os dados e criar insights acionáveis é a base para a criação de políticas de segurança fortes, incluindo confiança zero. O que é necessário é uma consolidação das informações. O consumo dessas informações fornece uma compreensão abrangente e completa do perfil de segurança da organização. Por exemplo, você precisa de um lugar para ir para encontrar onde ‘log4j’ está sendo consumido e está em execução. Você precisa de um local para exibir dados históricos para determinar os níveis de exposição. Você precisa de um local para entender quem possui um microsserviço, qual é o impacto do microsserviço e quais versões estão sendo executadas em todos os clusters. A segurança começa e termina com o conhecimento de qual software você está executando em toda a sua empresa. A consolidação dos dados permite que você crie políticas de segurança sólidas com insights imediatos para tomar ações rápidas e precisas de forma abrangente em todos os seus ambientes.
A coleta de dados se torna cada vez mais relevante à medida que criamos nosso perfil de segurança de aplicativos. Novas ferramentas e projetos de código aberto estão sendo desenvolvidos para melhorar a segurança de artefatos individuais, pacotes de código aberto e a auditoria do fluxo de trabalho de DevOps. Projetos interessantes para assistir:
Ortelius.io – Um armazenamento central de evidências de todos os resultados de segurança, com agregação de dados em nível de aplicativo para insights e histórico abrangentes de ponta a ponta. Incubação na Continuous Delivery Foundation (CDF).
Pyrsia.io – A Pyrsia cria uma rede de pacotes descentralizada com um consenso de construção. Ao construir em vários nós, o Pyrsia pode comparar os resultados e notificá-lo imediatamente quando uma compilação foi comprometida. Incubação na Continuous Delivery Foundation (CDF).
Tekton.dev – Um mecanismo de CI/CD baseado em eventos criado para o Kubernetes. Também inclui Tekton Chains para auditar o próprio pipeline. Incubação na Continuous Delivery Foundation (CDF).
CD.Events – Uma peça crítica no quebra-cabeça geral do pipeline. O CDEvents é um esforço da comunidade da Continuous Delivery Foundation (CDF) para definir padrões para a criação de uma estrutura de eventos de CD. O CDEvents simplificará e padronizará os fluxos de trabalho de CI/CD, eliminando grande parte do script único e criando uma auditoria do que está ocorrendo no pipeline. Um pipeline de CI/CD baseado em eventos facilitará a adição e a atualização de atividades de pipeline sem tocar em centenas de fluxos de trabalho de pipeline.
Keptn – Um mecanismo de CI/CD nativo da nuvem baseado em eventos para orquestrar o ciclo de vida do aplicativo. Projetado para incluir observabilidade e correção com uma abordagem GitOps. Incubação na Cloud Native Computing Foundation.
Alpha-Omega – Seu objetivo é primeiro (Alpha), trabalhar com os projetos de código aberto mais populares para encontrar e corrigir vulnerabilidades, e segundo (Omega) fornecer mais de 10.000 projetos de sistema operacional com análise de segurança automatizada. Um projeto comunitário Open Source Security Foundation (OpenSSF).
SigStore.dev – Assinatura, verificação e armazenamento de contêiner em um registro OCI. Fornece um registro histórico de alterações e permite a pesquisa do registro. Um projeto comunitário Open Source Security Foundation (OpenSSF).
Syft – Uma ferramenta CLI e biblioteca Go para gerar uma Lista de Materiais de Software (SBOM) a partir de imagens de contêiner e sistemas de arquivos. Gerenciado pela Anchore.
Apko – Compile e publique imagens de contêiner OCI construídas a partir de pacotes do Alpine Package Keeper. Uma maneira mais segura de criar contêineres. Gerenciado pela ChainGuard.
Conclusão
Se você trabalhou duro para definir práticas recomendadas sólidas de segurança de aplicativos para suas equipes de desenvolvimento, então é hora de voltar sua atenção para o seu pipeline de DevOps. À medida que você se afasta das práticas monolíticas para uma arquitetura de microsserviços nativa da nuvem desacoplada, haverá novos problemas a serem resolvidos. Primeiro, mais dados de segurança precisarão ser coletados, consumidos e acionados para cada objeto gerenciado em seus pipelines. No mínimo, cada versão de seus microsserviços deve ter uma verificação SBOM e CVE associada. Em segundo lugar, a capacidade de rastrear seus microsserviços, com seu perfil de segurança agregado até o nível do aplicativo, será essencial. Você não pode produzir o perfil de segurança de um aplicativo lógico sem conhecer todos os dados de dependência de nível inferior e gerar relatórios sobre todos eles como uma solução completa. Em terceiro lugar, continue a adicionar maneiras novas e mais seguras de gerenciar a criação de seus contêineres. Verificar o conteúdo é a etapa mais importante em todo o processo.
Estamos apenas começando a definir e implementar as práticas recomendadas de segurança de aplicativos. Há uma enorme quantidade de trabalho ainda a ser feito, e a comunidade de código aberto quer ter certeza de que eles estão prontos e capazes de resolver essas tarefas difíceis.
Onde o DeployHub se encaixa?
O DeployHub consome e agrega segurança e inteligência de DevOps, fornecendo insights abrangentes e completos, incluindo relacionamentos de microsserviços e aplicativos lógicos, relatórios consolidados de segurança de aplicativos e microsserviços, desvio de versão de serviço entre clusters e uso geral da cadeia de suprimentos de aplicativos. O DeployHub é adicionado ao pipeline de CI/CD para automatizar a coleta e a agregação desses dados usando uma interface de linha de comando simples que também pode adicionar a geração de SBOM ao processo, se você ainda não tiver feito isso.