Segurança moderna para ambientes modernos

Antigamente, a arquitetura empresarial era física e singular, convenientemente localizada em um só lugar, que podia ser facilmente gerenciada e protegida.

Agora, a situação se inverteu. A pressa pela digitalização está forçando as organizações a se moverem em velocidades sem precedentes. Organizações que adotaram metodologias ágeis e práticas de DevOps conseguiram modernizar seus ambientes, pilhas de aplicativos e implantações, decompondo aplicativos anteriormente monolíticos em arquiteturas de microsserviços, automatizando tarefas de rotina, adotando o Kubernetes (k8s) para gerenciamento de contêineres e migrando para a nuvem pública para entrega ágil de serviços.

Embora isso tenha melhorado muito a conveniência para as organizações e seus usuários finais, também trouxe alguns problemas de segurança significativos.

Nesse ritmo de mudança, a segurança tem ficado, em grande parte, para trás. Em muitos casos, o DevOps foi implementado e distribuído sem intervenção de segurança, fazendo com que a TI tenha que corrigir problemas conforme eles ocorrem e, em alguns exemplos públicos significativos, depois que eles ocorrem.

Então, qual é a melhor maneira de aliviar a pressão sobre os técnicos de segurança e, ao mesmo tempo, evitar violações, sem criar atrito entre os usuários?

Afastando-se da segurança centralizada

De muitas maneiras, as necessidades de segurança ao descentralizar para ambientes virtualizados pegaram as organizações de surpresa.  À medida que nos afastamos de nossos controles de segurança centralizados tradicionais, os controles distribuídos que temos em mãos não são realmente suficientes.

Como os ambientes centralizados eram bem conhecidos e quantificados, era relativamente fácil alcançar uniformidade nos controles de segurança, operações, relatórios e alertas. Mudanças nas tecnologias adotadas ocorreram com pouca frequência devido ao alto investimento, à propriedade intelectual acumulada e ao alto custo da mudança.

Oferecer suporte a vários ambientes novos trouxe uma série de desafios e considerações, como falta de maturidade e capacidade, ambientes de nuvem díspares, uma mistura de tecnologias, operações pouco claras, baixa visibilidade, relatórios difíceis e, muitas vezes, baixa maturidade.

Em resposta a esses desafios, os fornecedores de nuvem pública nos deram gateways de trânsito, um ponto central de controle por onde passa todo o tráfego de e para os locatários.

Em ambientes modernos, com aplicativos distribuídos em nuvens, locatários e data centers, faz muito sentido ter a segurança dentro do aplicativo individual. Isso garante que a segurança seja inerente, ou seja: não pode ser esquecida, removida ou ignorada. Isso também significa que a segurança está em vigor quando e onde é necessária e é removida como parte do estágio de desativação do aplicativo.

Este modelo também apresenta a oportunidade para a segurança “mudar para a esquerda” em termos de estar em vigor em todos os estágios do ciclo de vida e em todos os ambientes. Isso significa que os controles de segurança não são encontrados pela primeira vez na implantação e execução, ou na pré-produção e produção.

Levando segurança para a organização

As equipes de segurança querem deixar de ser o "escritório do não" e levar a segurança para a organização, em vez de arrastar a organização para a segurança. Em nossa opinião, a melhor maneira de conseguir isso é permitir que as equipes de DevOps consumam a segurança da maneira que melhor atenda às suas necessidades. Isso significa implementar e usar a segurança desde o início de um aplicativo ou programa, e não depois.

Chamado de “mudança de segurança para a esquerda”, isso significa implementar controles de segurança em estágios iniciais do ciclo de vida do desenvolvimento, por exemplo: Modelagem de ameaças, testes de segurança de aplicativos estáticos, análise de composição de software; e disponibilização de controles de segurança de estágios posteriores em ambientes de estágios anteriores, por exemplo: Firewall de aplicativo da Web, testes de segurança de aplicativos dinâmicos, etc. em ambientes de desenvolvimento e teste.

É claro que a segurança distribuída tende a trazer uma série de desafios. Para alcançar segurança distribuída, tradicionalmente significa ter diferentes tecnologias, pilhas e controles para diferentes ambientes. Isso não gera economia de escala, pois a diversidade de ambientes aumenta e se torna exponencialmente mais difícil dar suporte a cada novo ambiente e conjunto de controles distintos.

Isso também significa que você obtém pouca consistência de segurança em diferentes ambientes, o que pode levar a problemas. Provavelmente o mais importante é que você também tem diferentes alertas, relatórios e registros de cada ambiente, o que torna muito difícil gerenciar ou prever seus ambientes.

Para onde então?

Em um mundo ideal, como a segurança funciona em um ambiente descentralizado com vários usuários, aplicativos e nuvens?

A resposta é uma pilha uniforme que pode ser implantada em qualquer lugar que seja necessária. A pilha teria um formato pequeno, seria adequada para ambientes modernos e suportaria implantação e desativação rápidas. Também incluiria controles de segurança abrangentes, maduros e de nível empresarial.

Haveria um ponto de controle central; um único ponto para definir a política uma vez e implantá-la globalmente. A definição de política seria flexível e definida por Rede, Identidade, Segurança e Aplicação. O ponto de controle central também forneceria visibilidade, registro e relatórios centralizados e uniformes.

E toda a solução seria 100% orientada por API para realmente permitir que as equipes de desenvolvimento, segurança e operações se movam de forma colaborativa no ritmo dos negócios.

A F5 pode ajudar você a concretizar essa visão. Saiba mais.