F5 Sexta-feira: Como a padronização permite uma abordagem personalizável por aplicativo (microsserviços) para segurança de aplicativos
Falei , falei e falei mais um pouco sobre a necessidade crescente de serviços afins a aplicativos para proteger, dimensionar e otimizar os aplicativos que eles protegem. Assim como os desenvolvedores de aplicativos estão descobrindo que é mais eficiente e ágil em escala dividir monólitos em microsserviços mais focados e granulares, a infraestrutura também precisa espelhar essa mudança para continuar fornecendo o mesmo nível e qualidade de serviço em escala.
Mas essa abordagem não é apenas para arquiteturas de microsserviços. Também é para organizações que precisam entregar políticas por aplicativo em escala e fazer isso rapidamente. Considere uma pesquisa que descobriu que “85% das empresas têm um backlog móvel de um a 20 aplicativos, com a maioria (50%) tendo um backlog de 10 a 20 aplicativos”. Isso se soma à infinidade de aplicativos existentes (nossa pesquisa mostrou que quase metade das organizações tem entre 1 e 200 aplicativos, a outra metade, bem mais de 200, incluindo os surpreendentes 10% com mais de 3.000 aplicativos para lidar) que precisam de atualizações para serem lançados.
A maioria delas exige políticas muito específicas para garantir sua escala, segurança e desempenho. Você precisa escalar, mas precisa escalar rápido para gerenciar tudo.
Uma das desvantagens de uma abordagem de serviço por aplicativo, é claro, é que cada um deve ser adaptado para atender aos requisitos exclusivos do aplicativo que está sendo entregue. Esse é o ponto, é claro, mas sem uma abordagem estratégica para dimensionar as operações por trás da criação e implementação de políticas para atender a essa demanda, tal abordagem poderia levar a tempos de implementação mais lentos, e não mais rápidos.
É por isso que o DevOps e sua infraestrutura como filosofia de código, combinados com a atenção à automação, devem ser considerados não apenas apropriados, mas desejáveis, para as operações de segurança. Porque somente mudando a segurança da web para a esquerda uma abordagem holística de microsserviços em aplicativos e serviços de aplicativos pode ser bem-sucedida. Na verdade, é fundamental que a segurança consiga corresponder à velocidade com que a TI hoje espera entregar seus serviços aos clientes que atende.
Foi isso que levou a Catholic Education South Australia (CESA), que fornece serviços de TI para mais de 98 escolas distribuídas pela Austrália do Sul, a adotar a plataforma F5. A CESA estava enfrentando desafios decorrentes dos métodos tradicionais de provisionamento e implantação que simplesmente não forneciam o dimensionamento horizontal necessário para acompanhar a demanda. O que eles precisavam era de uma estrutura personalizável para implantar aplicativos e automatizar tarefas associadas. E isso eventualmente incluiu segurança na web.
Simon Sigre, engenheiro de rede sênior da CESA, explica por que eles precisavam fazer uma mudança: “ Fomos obrigados a começar a construir políticas de segurança de Camada 7 (L7) que envolvessem como uma luva cada aplicativo da web .”
A CESA precisava entregar políticas por aplicativo, mas precisava fazer isso rápido e em escala. O que significa que eles precisavam de automação para realizar esse feito. Mas isso não era tudo o que eles precisavam. A adaptação de políticas – especialmente políticas tão intimamente ligadas ao aplicativo que elas protegem – leva tempo. Mas nem tudo em um aplicativo é único. Há elementos comuns, particularmente aqueles relacionados a protocolos (como TCP e HTTP) e plataformas (como o software de servidor web ou de aplicativos) que permanecem os mesmos em muitos aplicativos. Configurar políticas para proteger esses aspectos também leva tempo; tempo que é duplicado em vários aplicativos.
É aqui que a padronização vem ao resgate. Uma das características da padronização é a capacidade de aproveitar pontos em comum em APIs, modelos, sistemas de comando e controle e scripts para melhorar a eficiência, o que se traduz em custos operacionais reduzidos e tempo de colocação no mercado mais rápido. Foi exatamente isso que a CESA fez quando aproveitou a programabilidade do F5 não apenas para automatizar a escalabilidade, mas para padronizar políticas de segurança criando modelos de alto nível para tecnologias comuns em uso e, então, personalizá-los para acomodar diferenças em cada novo serviço. Eles conseguiram criar as políticas de segurança por aplicativo necessárias sem incorrer nos custos normalmente associados à personalização, tratando a infraestrutura (segurança da web) como código (modelos), eliminando efetivamente os custos associados à recriação da política base toda vez que precisavam implantar um novo serviço.
Você pode ler mais sobre a experiência da CESA com a F5 e suas tecnologias aqui nesta história de cliente.