Uma das coisas interessantes — e mais frustrantes — que observei ao longo dos anos é a diferença entre a forma como engenheiros de rede e desenvolvedores de aplicações enxergam os aplicativos. Isso fica evidente na maneira como as aplicações são representadas em diagramas de rede e, inversamente, na forma como as redes são mostradas em diagramas de arquitetura de aplicações.
Nem é preciso dizer que cada um tem uma visão muito simplista do outro.
Isso também se aplica à segurança, cujo papel na proteção não apenas de redes e aplicações, mas do próprio negócio, tornou-se fundamental. É importante que as equipes de segurança olhem além dos blocos dos diagramas de arquitetura convencionais para realmente compreender as aplicações. Uma porcentagem significativa dos ataques bem-sucedidos ocorre na camada de aplicação. Quanto mais demorarmos para reconhecer as características específicas dos diversos tipos de aplicações, mais tempo elas permanecerão vulneráveis.
A discussão de hoje será focada em SPAs. Para quem está se perguntando o que essa sigla de três letras significa, trata-se de "aplicações de página única".
Uma introdução às SPAs
Um aplicativo de página única é exatamente isso: uma única página da web que serve como estrutura para todas as tarefas relacionadas ao aplicativo. Essa arquitetura remonta à época da Web 2.0 e ao surgimento do AJAX como um método para “atualizar” elementos individuais do DOM (Modelo de Objetos de Documento), em vez de recarregar a página inteira. Essa técnica melhorou significativamente o desempenho e foi a precursora dos modernos aplicativos de página única.
Esses aplicativos se assemelham mais ao comportamento de um aplicativo móvel, no qual a interface do usuário no cliente é carregada quando ele é aberto pela primeira vez, e a comunicação com o servidor envolve apenas dados. Isso significa que cada chamada ao servidor contém somente dados, e todas as alterações na interface do usuário ocorrem no cliente. Isso reduz drasticamente a quantidade de dados enviados e recebidos e, como você pode imaginar, melhora o desempenho. Esses tipos de aplicativos usam APIs para trocar dados.
Em geral, temos trabalhado com a premissa de que a maioria dessas APIs é implementada de acordo com os princípios REST. Isso significa que cada objeto (normalmente considerado como vinculado a um único elemento da interface do usuário) tem sua própria API, que pode ser chamada para executar operações CRUD (criar, ler, atualizar e excluir). Do ponto de vista da segurança, isso facilita um pouco as coisas, pois é possível esperar dados em formatos específicos para uma determinada chamada de API (URI). Os dados enviados para "/update/product/123" serão sempre o mesmo objeto serializado, enquanto os dados enviados para "/delete/order/4433" serão um objeto serializado diferente. Isso significa que as práticas tradicionais de associar políticas específicas a URIs específicas podem ser usadas para proteger essa API.
O padrão de URI única
Agora, as SPAs podem ou não seguir esse padrão. As práticas emergentes relacionadas a SPAs podem usar — e de fato usam — a mesma API para realizar transações, bem como um mapeamento mais tradicional de função para URI. Em uma SPA com padrão de URI único, o URI não muda, mas os objetos serializados enviados entre o servidor e o cliente mudam.
Isso remete às transações SOA/XML, nas quais um único endpoint (URI) era usado para invocar várias funções. A função (endpoint) de destino era especificada nos dados XML serializados ou, às vezes, inserida em um cabeçalho HTTP personalizado. Esse modelo levou à necessidade de gateways SOA/XML responsáveis por receber a solicitação e determinar qual função estava sendo invocada antes de encaminhá-la ao endpoint (servidor) correto.
Com SPAs, você pode estar lidando com várias chamadas de API ou apenas algumas. Em todos os casos, provavelmente será necessário proteger os dados em algum formato (talvez XML, mas provavelmente JSON). Isso significa que você precisa estar ciente de que o conteúdo representa um risco. Como alguns dados podem ser usados para gerar dinamicamente elementos da interface do usuário (ou manipular o DOM de alguma outra forma no cliente), é importante identificar e eliminar códigos potencialmente maliciosos em cada envio.
A desconexão na segurança
Infelizmente, se um único URI for usado para trocar dados entre diferentes funções, a prática tradicional de associar políticas a URIs não funcionará. Na verdade, isso pode comprometer a segurança, pois essas políticas geralmente são configuradas para esperar formatos específicos de carga útil. Os gateways de API também costumam vincular políticas (roteamento, medição e acesso) a um URI específico. Isso significa que a prática de usar apenas alguns URIs (chamadas de API) para lidar com um número muito maior de funções com diferentes formatos de dados pode comprometer a segurança existente.
Este é um exemplo de por que é cada vez mais importante que as equipes de segurança e desenvolvimento (não DevOps, mas desenvolvedores) trabalhem em maior colaboração, desde a primeira linha de código até a implantação. Há medidas que os desenvolvedores podem adotar logo no início para facilitar a implementação das proteções adequadas pela equipe de segurança, como inserir um cabeçalho HTTP com um indicador que permita executar a política correta. Algo tão simples quanto "X-Code: 'order'" enriqueceria as solicitações de modo que as soluções de segurança pudessem identificar — e posteriormente verificar — os dados em busca de possíveis explorações de vulnerabilidades.
Do ponto de vista arquitetural, isso pode exigir um proxy L7 inteligente capaz de extrair o código e reescrever o URI antes de encaminhar a solicitação para a solução de segurança adequada (WAF, API Gateway etc.). Essa abordagem também funciona se o proxy L7 inteligente for capaz de interpretar a linguagem do formato de dados, como JSON, e os desenvolvedores incluírem em cada troca algum código ou nome de endpoint que possa ser usado para reescrever e encaminhar a solicitação ao destino correto.
O ideal é incorporar a segurança da camada de aplicação ao próprio aplicativo, o que proporcionaria o melhor equilíbrio entre desempenho e segurança. No entanto, isso nem sempre é possível e, às vezes, são necessárias soluções arquitetônicas criativas para atingir o objetivo de segurança.
Segurança é um trabalho em equipe
De modo geral, as mudanças na forma como os desenvolvedores distribuem as diversas responsabilidades entre o cliente e o servidor têm um impacto significativo na maneira como a infraestrutura de serviços de aplicações interage com as solicitações e respostas subsequentes. É importante que as equipes de segurança, desenvolvimento e infraestrutura de serviços de aplicações participem de todo o ciclo de vida de desenvolvimento de software (SDLC). Uma solução arquitetônica também leva tempo para ser implementada. Se ela for deixada "para o final", isso acrescentará dias — ou semanas, talvez até meses — ao prazo de lançamento no mercado. Ou o produto será lançado sem serviços de segurança, o que traz seus próprios riscos (e consequências).
A colaboração desde o primeiro dia de desenvolvimento é a melhor — e mais rápida — maneira de garantir que os aplicativos estejam disponíveis, rápidos e seguros quando entrarem em produção.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicaçõ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...