O que você faz quando precisa de duas coisas, mas “todo mundo sabe” que elas são mutuamente excludentes?
Há muito tempo existe um mito nas comunidades de redes e segurança: arquiteturas de software seguras são inflexíveis, e softwares desenvolvidos com metodologias ágeis são menos seguros. Mas espere — há alguma evidência de que um software desenvolvido com um modelo iterativo seja inerentemente menos seguro? Se houver, minha “pesquisa” (leia-se: buscas no Google) não conseguiu encontrá-la.
De fato, é possível argumentar de forma convincente que um ciclo de entrega mais rápido e um processo de lançamento automatizado e simplificado reduzem os riscos ao diminuir o tempo total de exposição a vulnerabilidades.
Então, existe realmente uma divisão entre flexibilidade e segurança? Infelizmente, eu ainda diria que sim.
No entanto, não estou convencido de que um ciclo de vida ágil de software introduza mais vulnerabilidades inerentes no código (embora algumas das novas plataformas — como os sistemas de gerenciamento de contêineres — certamente criem novas superfícies de ataque), pois o código da aplicação é apenas parte da postura geral de segurança de uma organização.
Reconhecendo que todo software contém falhas, as pilhas de tecnologia de TI também incluem controles de segurança externos ao código da aplicação, como firewalls de rede, sistemas de detecção de intrusões e firewalls de aplicações web. Muitos desses sistemas precisam monitorar o comportamento da aplicação e responder a ameaças recém-descobertas em frameworks ou sistemas operacionais. O ideal é que esses sistemas sejam tão ágeis quanto o ciclo de vida de entrega de software. Caso contrário, uma de duas coisas acontecerá: ou os controles de segurança serão vistos como um obstáculo à velocidade de entrega e ao tempo para geração de valor, ou não fornecerão a proteção para a qual foram implementados. Nenhuma dessas situações é exatamente ideal.
A solução óbvia é adotar um modelo de controles de segurança mais próximo do modelo de ciclo de vida de entrega de software. De fato, o movimento DevSecOps está começando a aplicar práticas de engenharia de software e DevOps à implementação de controles de segurança e a compartilhar a responsabilidade pela segurança com todos os integrantes da equipe, mesmo que o conhecimento especializado continue concentrado em uma equipe altamente experiente de profissionais especializados.
Acompanhando essa transformação cultural, ocorre uma evolução tecnológica, na qual a implementação de controles de segurança passa a ser integrada ao pipeline de entrega de software. Os controles de segurança acompanham cada nova iteração do software durante os testes, o staging e a implantação, em vez de serem simplesmente adicionados ao final. Elementos de telemetria e rastreabilidade são inseridos e monitorados em vários pontos da stack. Novas métricas que ajudam a identificar, rastrear e gerar relatórios sobre agentes mal-intencionados 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 abrange desde o firewall de rede até o servidor de aplicações, passando por todas as camadas intermediárias, são enormes as possibilidades de criar um conjunto de controles de segurança mais ágil, integrado e informativo. A promessa de segurança e visibilidade de nível empresarial aliadas a uma agilidade leve tem o potencial de oferecer a todos da equipe as ferramentas, as informações e a (relativa) tranquilidade que procuram.
Para saber mais sobre as vantagens de unir a F5 e a NGINX, confira uma publicação do CEO da F5 que apresenta a série de posts do blog ‘Bridging the Divide’.
Sobre o autor
Publicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...