Fundamentos de segurança na nuvem, parte 3: capacite seus desenvolvedores

No post anterior da nossa série sobre os 5 fundamentos de segurança na nuvem, analisamos o valor da prevenção e do design seguro. Mapear as relações entre recursos e aplicar barreiras de segurança durante todo o desenvolvimento ajuda a reduzir significativamente a superfície de ataque disponível. Mas quem vai aplicar essas barreiras quando sua equipe de segurança estiver ocupada com outras tarefas? É aí que os desenvolvedores podem entrar em ação. Vamos conhecer outro elemento essencial da segurança na nuvem: capacitar os desenvolvedores. 

Em 2013, Gene Kim, Kevin Behr e George Spafford escreveram o livro sobre DevOps: O Projeto Fênix. O objetivo do livro era promover o DevOps, mas o trabalho dos autores foi mais profético do que eles imaginavam — especialmente no que diz respeito à segurança na nuvem. 

O DevOps buscava integrar melhor as equipes de operações de TI ao ciclo de vida de desenvolvimento de software, ou SDLC, e permitir que as equipes criassem e implantassem uma infraestrutura melhor em menos tempo. As equipes de operações de TI aprenderam a entender as pressões do desenvolvimento, mas, talvez ainda mais importante, os desenvolvedores aprenderam a planejar e desenvolver aplicações e infraestrutura de forma mais integrada.

Você provavelmente já ouviu falar de um novo termo: DevSecOps. Esse termo surgiu por vários motivos, e um deles se destaca. Gene Kim explica:

A proporção entre engenheiros de Desenvolvimento, Operações e Segurança da Informação em uma organização de tecnologia típica é de 100:10:1. Quando a equipe de Segurança da Informação está em tamanha desvantagem numérica, sem automação e sem integrar a segurança da informação ao trabalho diário de Desenvolvimento e Operações, ela só consegue fazer verificações de conformidade — o oposto da engenharia de segurança.

Em essência, essa proporção revela a principal prioridade de muitas empresas: desenvolver software — não protegê-lo. A solução é capacitar os desenvolvedores para incorporar a engenharia de segurança aos seus fluxos de trabalho de desenvolvimento.

Neste artigo, apresentamos três princípios que líderes de tecnologia em nuvem podem usar para capacitar seus desenvolvedores e criar uma postura de segurança mais robusta e econômica.

1. Use infraestrutura como código sempre que possível

O software não apenas dominou o mundo: também dominou a nuvem.

Hoje, a infraestrutura na nuvem pode ser 100% software; na prática, para os clientes de nuvem, ela é 100% software. Com ferramentas de infraestrutura como código, como Terraform e AWS CloudFormation, os desenvolvedores podem criar e gerenciar ambientes na nuvem de forma programática.

No passado, a segurança na nuvem era uma atividade isolada, como a maioria das funções de segurança. As equipes de segurança dependiam de ferramentas de Cloud Security Posture Management, usadas para analisar ambientes em execução provisionados pelas equipes de engenharia. Em seguida, identificavam configurações incorretas, priorizavam-nas por gravidade e atribuíam tarefas de correção às equipes de DevOps.

Mas um grande problema veio à tona: configurações incorretas e outros problemas de segurança só podem ser detectados depois que acontecem. Um estudo da IBM de 2017 mostrou um dos motivos pelos quais isso é problemático: “Corrigir um bug de software encontrado durante a fase de testes pode custar até 15 vezes mais do que corrigir o mesmo bug encontrado na fase de design”.

A infraestrutura como código muda essa conversa. Ao permitir que as equipes de desenvolvimento definam por meio de código a configuração dos ambientes na nuvem, as empresas podem antecipar a segurança — ou seja, levar o trabalho de segurança para etapas anteriores do SDLC da infraestrutura na nuvem.

Assim, as verificações de segurança podem acontecer antes da implantação. O resultado é menos configurações incorretas em tempo de execução, menos bugs em produção e uma postura de segurança muito mais robusta, muito mais cedo.

2. Priorize integrações com ferramentas de desenvolvimento

Às vezes, a segurança tem má reputação entre os desenvolvedores porque costuma ser uma série de etapas que as empresas acrescentam ao final do SDLC. Com isso, os desenvolvedores acabam fazendo muito trabalho manual. Além de serem mais difíceis de detectar nas etapas finais, bugs e outras falhas também são mais difíceis de identificar e corrigir, e muitas vezes exigem retrabalho demorado e caro.

O segredo é encontrar ferramentas que ofereçam integrações abrangentes e relevantes e usá-las para incluir recursos de segurança no fluxo de trabalho de desenvolvimento. O objetivo não é mudar a forma como os desenvolvedores trabalham, mas incorporar a segurança à maneira como eles já trabalham.

Priorize a integração das verificações de segurança às ferramentas de desenvolvimento, aos repositórios de código-fonte e às cadeias de ferramentas de CI/CD. Além disso, ao escolher ferramentas de segurança, avalie tanto a variedade de integrações disponíveis quanto a qualidade delas. Ambas são necessárias para tornar a segurança parte integrante do fluxo de trabalho de desenvolvimento. As ferramentas de segurança para desenvolvedores só são eficazes se eles as usarem.

3. Ofereça orientações úteis aos desenvolvedores

O DevSecOps não é apenas um benefício adicional. Quando os desenvolvedores têm à disposição infraestrutura como código e integrações estreitas com ferramentas de segurança, eles podem aprimorar cada vez mais suas habilidades em engenharia de segurança. Ao capacitar os desenvolvedores e fornecer ferramentas para que usem esse potencial, suas habilidades podem se expandir.

Com infraestrutura como código, os desenvolvedores podem aprender a criar ambientes seguros desde a arquitetura. E quando as empresas incorporam abordagens de DevSecOps aos programas de segurança na nuvem, os engenheiros recebem automaticamente feedback e orientações de segurança enquanto programam.

Com o tempo, os desenvolvedores podem aprimorar suas habilidades em engenharia de segurança e, assim, introduzir menos problemas durante o desenvolvimento. Mesmo quando surgem problemas em tempo de execução, eles conseguem identificar melhor em que ponto da infraestrutura aplicar as correções.

O segredo é as equipes de segurança atuarem como fornecedoras internas de ferramentas para os desenvolvedores. Essa prática funciona melhor quando as equipes de segurança trabalham em estreita colaboração com as equipes de desenvolvimento e engenharia de nuvem para entender seus casos de uso e fluxos de trabalho. A partir daí, podem desenvolver, adquirir e integrar ferramentas que ofereçam feedback útil e oportuno, além de orientações específicas para a correção.

Mais cedo, mais rápido, melhor, mais forte

Quanto mais cedo você corrigir configurações incorretas, bugs e vulnerabilidades, melhor.

A FormHero, que contava com uma única pessoa dedicada à segurança em tempo integral e uma equipe de desenvolvimento de 10 pessoas, comprovou esse princípio ao buscar ferramentas para reduzir o tempo de correção.

Ryan Kimber, fundador e CEO, afirma: “Se você não resolver os problemas durante o fluxo de trabalho dos desenvolvedores e só os encontrar e tratar na etapa de QA, levará 10 vezes mais tempo para corrigi-los”.

Com infraestrutura como código, ferramentas de segurança bem integradas e orientações automáticas para os desenvolvedores, os líderes de segurança na nuvem podem alcançar essa melhoria de 10 vezes e ampliá-la em todos os ambientes na nuvem — criando uma segurança mais robusta e econômica.