Conheça os principais conceitos do DevSecOps

As liberações rápidas, frequentes e iterativas são muito comuns para serviços em nuvem.

Normalmente direciona a necessidade de práticas de DevOps. Isso pode ser uma oportunidade e um desafio à segurança. O desafio é que um curto período de versões frequentes pode não incluir tempo suficiente para realizar um ciclo completo de testes de segurança.

A adoção de práticas de DevOps significa mais colaboração entre as equipes de desenvolvimento, controle de qualidade, TI e operação e adoção mais em andamento de ferramentas de integração contínua ou de entrega contínua. Isso fornece uma boa base para a migração para o DevSecOps. Dependendo do nível de maturidade do IC / CD existente, práticas ou ferramentas de segurança podem ser adicionadas sobre a estrutura de CI / CD existente através do DevSecOps.

Esta é uma maneira eficaz de introduzir segurança, com uma curva de aprendizado menor. Criar ferramentas de segurança em torno do CI / CD existente ainda é a melhor abordagem.

Um pipeline de construção é uma maneira automatizada, confiável e repetível de produzir artefatos implementáveis consistentes.

O principal recurso de um pipeline de construção é que, sempre que o código-fonte é alterado, é possível iniciar um processo de construção que seja consistente e repetidamente consistente.

O motivo disso ser importante é que ele confia à equipe que todas as alterações de código têm integridade.

Outro benefício dos pipelines de construção é que você pode voltar no tempo, verificar as versões mais antigas do produto e construí-las de maneira confiável, o que significa que você pode testar uma versão específica do sistema que possa exibirproblemas conhecidos e verificar as correções.

O teste é uma parte importante da maioria dos programas de qualidade de software. É também uma fonte alta de custos, atrasos e desperdícios em muitos programas tradicionais.

Quando o teste leva semanas de trabalho, é impossível liberar o código em teste mais rapidamente do que os testes levam para executar.

Os testes automatizados geralmente seguem a pirâmide de testes, onde a maioria dos testes é de baixo nível, barata e rápida de executar, simples de automatizar e fácil de alterar.

Isso reduz a dependência da equipe em testes de aceitação de ponta a ponta, que são caros de configurar, lentos para executar, difíceis de automatizar e ainda mais difíceis de manter.

Temos um artigo falando especificamente sobre teste automatizados! Clique aqui para vê-lo

Uma vez que temos um pipeline de construção, permitindo

• a criação de artefatos consistentes
• uma capacidade de teste automatizado que garanta verificações básicas de qualidade

Podemos combinar esses dois sistemas. A chave para a integração contínua é a palavra contínua. A ideia de um sistema de CI é que ele monitora constantemente o estado do repositório de código e se houve uma mudança ele aciona automaticamente a construção do artefato e, em seguida, aplica testes no artefato.

Em algumas organizações, a construção e teste de um artefato podem ser feitas em segundos, enquanto em sistemas maiores ou pipelines de teste de construção mais complexos pode levar vários minutos para ser realizado.

Onde os tempos ficam mais longos, as equipes tendem a começar a separar testes e etapas e executá-los em paralelo para manter loops de feedback rápido.

Se os testes e verificações passarem, a saída da integração contínua é um artefato que pode ser implantado em seus servidores após cada commit de código de um desenvolvedor, o que faz parte do DevSecOps.

Isso dá feedback quase instantâneo para o desenvolvedor que eles não cometeram um erro ou quebrou o trabalho de ninguém.

Isso também fornece a capacidade para a equipe manter um artefato saudável e pronto para implantar artefatos o tempo todo, o que significa que patches de emergência ou respostas de segurança podem ser aplicados de forma fácil e rápida.

No entanto, o advento da computação em nuvem e gerenciamento de configuração programável significa que é possível e até mesmo comum gerenciar sua infraestrutura em repositórios de código.

Existem muitas maneiras diferentes de fazer isso, mas os padrões comuns são aqueles que mantém um repositório de código que define o estado desejado para o sistema.

Isso incluirá informações sobre sistemas operacionais, nomes de host, definições de rede, regras de firewall, conjuntos de aplicativos instalados e assim por diante.

Este código é versionado, revisado e testado da mesma forma que o código de aplicativo. Isso dá os mesmos níveis de confiança nas mudanças de infraestrutura que você tem sobre as alterações de sua aplicação.

A maioria dos sistemas de gerenciamento de configuração inspeciona regularmente o sistema e a infraestrutura e, se notarem diferenças, poderão avisar ou definir proativamente o sistema ao estado desejado.

Usando essa abordagem, você pode auditar seu ambiente de tempo de execução analisando o repositório de código em vez de ter que digitalizar e avaliar manualmente sua infraestrutura. Ele também dá confiança de repetibilidade entre ambientes.

Ao compartilhar grande parte do código de infraestrutura entre produção e desenvolvimento, podemos rastrear e manter a menor lacuna possível entre os ambientes e garantir que isso não aconteça.

Embora o gerenciamento de configuração faça um excelente trabalho de manter o ambiente operacional em um estado consistente e desejado, ele não se destina a monitorar ou alertar sobre as mudanças no ambiente que podem estar associadas às ações de um adversário ou a um ataque contínuo.

As ferramentas de gerenciamento de configuração verificam o estado real do ambiente em relação ao estado desejado em uma base periódica (por exemplo, a cada 30 minutos). Isso deixa uma janela de exposição para um adversário operar, onde as configurações poderiam ser alteradas, capitalizadas e revertidas sem que o sistema de gerenciamento de configuração percebesse as mudanças.

A fim de tornar as liberações menos dolorosas e propensas a erros, equipes ágeis tentam liberar com mais frequência. Os procedimentos que são regularmente praticados e executados tendem a ser bem conservados e precisos.

Com automação, os processos de implantação e liberação se tornam ainda mais consistentes, confiáveis e eficientes. A liberação de pequenas mudanças reduz com mais frequência os riscos operacionais, bem como os riscos de segurança.

Pequenas mudanças são mais fáceis de entender, revisar e testar, reduzindo a chance de erros graves de segurança entrarem em produção.

Esses processos devem ser seguidos em todos os ambientes, para garantir que eles funcionem de forma confiável e, se automatizados, possam ser conectados ao sistema de integração contínua.

Se isso for feito, podemos avançar para uma abordagem de entrega contínua ou implantação contínua, onde uma alteração comprometida com o repositório de código pode passar pelo pipeline de construção e seus estágios de teste automatizados e ser implantada automaticamente, possivelmente até mesmo em Produção.

Garante que as alterações estejam sempre prontas para serem implantadas na produção, automatizando e auditando as etapas de construção, teste, empacotamento e implantação para que sejam executadas de forma consistente para cada alteração.

Na implantação contínua, as alterações são executadas automaticamente através das mesmas fases de compilação e teste e são automaticamente e imediatamente promovidas à produção se todas as etapas passarem.

Isso dá confiança na implantação de um novo lançamento de software não causará problemas na produção, porque a compilação é testada e o processo de liberação é testado e todas as etapas foram validadas.

Mesmo que você não vá até o fim para implantar continuamente cada alteração na produção, automatizando o processo de liberação, você elimina erros humanos e ganha repetibilidade, consistência, velocidade e audibilidade.

Além disso, a auditoria incorporada significa que você pode ver exatamente quem decidiu liberar algo e o que estava contido nessa mudança, o que significa que, se ocorrer um erro, é muito mais fácil identificar e corrigir.

Também é muito mais confiável em uma emergência. Se você precisa urgentemente corrigir um bug de segurança de software, que você se sentiria mais confiante com patch que teve que ignorar grande parte de seus testes manuais e ser implantado por alguém que não fez isso em vários meses.

Mas agora podemos liberar com bastante facilidade e com frequência, precisamos garantir que as equipes não interfiram umas com as outras.

Dado este pipeline automatizado ou no caminho para a produção, torna-se fundamental saber o que vai seguir esse caminho, e para as equipes não interferir com o trabalho uns dos outros.

Apesar de todos esses testes e automação, há sempre possíveis erros, muitas vezes causados por dependências em unidades de trabalho. Uma peça de trabalho pode ser dependente de outra peça de trabalho que está sendo feito por outra equipe.

Quase todas as metodologias ágeis priorizam a comunicação da equipe, e o mecanismo mais comum para isso é o grande rastreamento visível do trabalho. Isso pode ser notas post-it ou cartões em uma parede, ou uma placa Kanban, ou pode ser um rastreador de história eletrônica, mas o que quer que seja, os requisitos comuns são:

• Visível: Todos na equipe, e as equipes relacionadas devem ser capazes de ver rapidamente o que está sendo trabalhado e o que está no caminho para a produção.
• Atualizado e completo: Para que essas informações sejam úteis e confiáveis, elas devem ser completas e atuais. Tudo sobre o projeto – a lista de pendências da história, bugs e vulnerabilidades, trabalho em andamento, marcos de programação e velocidade e tempo de ciclo, riscos, o status atual do pipeline de construção – devem estar disponíveis em um só lugar e atualizados em tempo real.
• Simples: Este não é um sistema para rastrear todos os requisitos detalhados para cada peça de trabalho. Cada item deve ter um espaço reservado que representa a peça de trabalho, mostrando algumas coisas importantes, quem é o dono, e em que estado ele está.

Claro que ter a capacidade de ver em que trabalho as pessoas estão trabalhando não adianta se o trabalho em si não for valioso.

Finalmente, se você tem um pipeline eficiente para a produção, e é capaz de testar automaticamente que suas alterações não quebraram seu produto, você precisa de alguma maneira de monitorar a eficácia das mudanças que você faz.

Você precisa ser capaz de monitorar o sistema e, em particular, como ele está trabalhando para entender suas mudanças. Isso não é como monitoramento do sistema, onde você verifica se as máquinas estão funcionando, mas sim o monitoramento da Cadeia de Valor, seja verificando a taxa de conversão de navegadores para compradores, ou tempo de repouso, ou taxas de cliques – métricas que são importantes para a equipe, para os usuários do sistema, e para o negócio.

A razão para isso é que equipes ágeis altamente eficazes estão constantemente mudando seu produto em resposta ao feedback. No entanto, a fim de otimizar esse tempo de ciclo, a organização precisa saber o feedback para coletar, e mais especificamente saber se o trabalho realmente entregou algum valor.

Saber que uma equipe fez 10, 100 ou 1000 mudanças é inútil, a menos que você possa amarrar esse trabalho de volta ao trabalho significativo para a organização.

Os indicadores variam muito por contexto e serviço, mas exemplos comuns podem incluir valor para o dinheiro, receita por transação, taxas de conversão, tempo de permanência ou tempo médio para ativação. Esses valores devem ser monitorados e exibidos nos painéis visíveis que permitem que a equipe veja valores históricos e atuais.