O que você faz quando precisa de duas coisas, mas "todo mundo sabe" que as duas são mutuamente exclusivas?
Há um mito antigo nas comunidades de rede e segurança: arquiteturas de software seguras são inflexíveis e software entregue de forma ágil é menos seguro. Mas espere um pouco – há alguma evidência que sustente que o software desenvolvido usando um modelo iterativo é inerentemente menos seguro? Se houver, minha ‘pesquisa’ (leia-se: (Pesquisando no Google) não encontrei realmente.
Na verdade, você pode argumentar de forma confiável que um ciclo de entrega mais rápido e um processo de liberação automatizado e simplificado reduzem o risco ao reduzir o tempo geral de exposição à vulnerabilidade.
Então, existe realmente uma divisão entre flexibilidade e segurança? Infelizmente, eu ainda diria que sim, existe.
No entanto, não estou convencido de que um ciclo de vida de software ágil introduza mais vulnerabilidades de código inerentes (embora algumas das novas plataformas – como sistemas de gerenciamento de contêineres certamente introduzam novas superfícies para ataque), pois o código do aplicativo é apenas parte da postura geral de segurança de uma organização.
Reconhecendo que todo software contém defeitos, as pilhas de tecnologia de TI também contêm controles de segurança externos ao código do aplicativo, como firewalls de rede, sistemas de detecção de intrusão e firewalls de aplicativos da web. Muitos desses sistemas precisam rastrear o comportamento dos aplicativos e responder a ameaças recém-descobertas em estruturas ou sistemas operacionais. O ideal é que esses sistemas sejam tão ágeis quanto o ciclo de vida da entrega do software. Porque se não forem, uma de duas coisas acontecerá: ou os controles de segurança serão vistos como impactantes na velocidade de entrega e no tempo de valorização, ou eles não fornecerão a proteção para a qual foram colocados. Nenhuma dessas coisas é exatamente ótima.
A solução óbvia é mover o modelo de controle de segurança para um mais próximo do modelo de ciclo de vida de entrega de software e, de fato, o movimento DevSecOps está começando a aplicar práticas de engenharia de software e DevOps para entregar controles de segurança e compartilhar a responsabilidade pela segurança com todos em uma equipe, mesmo que a experiência profunda permaneça com uma equipe altamente experiente e especializada de profissionais.
Acompanhando essa transformação cultural está uma evolução tecnológica, onde a implementação de controles de segurança se integra ao pipeline de entrega de software. Onde os controles de segurança acompanham cada nova iteração de software durante os testes, preparação e implantação, e não apenas são adicionados no final. Onde elementos de telemetria e rastreabilidade são injetados e rastreados em vários pontos da pilha. Onde novas métricas que ajudam a identificar, rastrear e relatar adversários podem ser rapidamente coletadas e analisadas.
Para tornar isso possível, sua pilha de tecnologia precisa colaborar tanto quanto suas equipes. Essa é uma das possibilidades mais interessantes em uma futura organização F5 + NGINX. Com um portfólio que vai do firewall de rede ao servidor de aplicativos, e em todas as camadas intermediárias, as possibilidades para um conjunto de controles de segurança mais ágil, mais integrado e mais informativo são enormes. A promessa de segurança e visibilidade de nível empresarial aliada à agilidade leve tem o potencial de dar a todos na equipe as ferramentas, informações e (relativa) paz de espírito que eles procuram.
Para saber mais sobre as vantagens de unir o F5 e o NGINX, confira uma postagem do CEO do F5 apresentando a série de blogs "Bridging the Divide".