---
title: "Evolução da arquitetura SASE"
url: "https://www.aryaka.com/pt-br/blog/evolution-of-sase-architecture/"
markdown_url: "https://www.aryaka.com/pt-br/blog/evolution-of-sase-architecture.md"
llm_canonical: "https://www.aryaka.com/pt-br/blog/evolution-of-sase-architecture.md"
canonical_for_llm: true
entity_type: "Article"
primary_entity: "Evolução da arquitetura SASE"
citation_value: "Published on Aryaka; canonical URL https://www.aryaka.com/pt-br/blog/evolution-of-sase-architecture/."
last_updated: "2024-08-20T05:35:53-07:00"
---
Evolução da arquitetura SASE
 O senhor já deve ter ouvido falar de vários princípios de arquitetura no contexto da segurança de rede em geral e da SASE em particular.
Alguns princípios de arquitetura de software usados pelo setor no contexto da SASE são:
- Arquitetura de passagem única
- Arquitetura de um proxy
- Arquitetura Run-to-Completion
- Arquitetura de expansão
- Arquitetura de processamento paralelo de passagem única
- Traga sua própria função de segurança Arquitetura
- Arquitetura nativa da nuvem
- Arquitetura de isolamento
- Primeira arquitetura de API
- Arquitetura de fatiamento (segmentação E2E)
Muitos dos princípios arquitetônicos acima não são novos.
Os princípios arquitetônicos Single-pass, One-proxy, Single-pass-parallel-processing e Run-to-completion são populares desde a época do UTM (Unified Threat Management), no início dos anos 2000, embora já tenham sido conhecidos por nomes diferentes.
O principal objetivo desses princípios arquitetônicos é alcançar
- Maior rendimento com uso eficiente de recursos.
- Menor latência de ponta a ponta
- Menor jitter
- Maior elasticidade (Scale-out) e resiliência, mesmo em caso de ataques DDoS aos serviços de segurança
- Introdução mais rápida de novas funções de segurança (agilidade)
- Integração de funções de segurança de vários fornecedores sem introduzir ineficiências (integração das melhores tecnologias)
- Capacidade de adoção (correr para qualquer lugar)
- Painel de vidro único
Evolução
Um aspecto positivo do setor de segurança de rede é que ele é dinâmico.
Ele adota novos princípios de arquitetura de software e implantação em cada nova geração de produtos.
Ele também mantém a proteção contra a sofisticação dos atacantes.
Dito isso, o mercado de segurança de rede é tradicionalmente fragmentado.
Há vários fornecedores de segurança que oferecem diferentes funções de segurança.
Isso é bom do ponto de vista da inovação, deve ser incentivado e deve continuar.
Deve-se observar que um fornecedor pode não ser bom em todas as funções de segurança.
Como o senhor verá mais adiante, se cada fornecedor fornecer uma pilha completa para suas funções de segurança, haverá enormes ineficiências e, portanto, enormes implicações de custo.
Além disso, isso pode introduzir mais latência, o que pode ser um desafio para alguns aplicativos.
Por isso, a aplicabilidade de princípios de arquitetura e práticas recomendadas mais recentes.
A arquitetura de software deve ser feita de modo a eliminar as ineficiências, mas permitir a integração de tecnologias de vários fornecedores para obter a melhor segurança cibernética.
Antes da convergência
A Figura 1 e a Figura 2 são dois exemplos representativos de segurança de rede antes da SASE.
A Figura 1 mostra o acesso seguro à Internet e a Figura 2 mostra um exemplo de acesso privado seguro.
Observe que a ordem das funções de segurança nessas figuras é arbitrária e a ordem de execução normalmente é específica da implantação.  O acesso seguro à Internet é tradicionalmente obtido por meio de várias soluções de segurança, conforme listado na Figura
1. É a empresa que compra essas funções de segurança e as coloca em uma cadeia de serviços. Como muitas funções de segurança exigem o proxy das conexões, esse encadeamento também é chamado de Proxy Chaining pelo setor.
Como cada solução de segurança discreta é autossuficiente e vem de vários fornecedores, a funcionalidade comum é repetida nessas soluções.
A funcionalidade comum inclui policiamento de tráfego na entrada, modelagem de tráfego na saída, filtragem de tráfego para garantir que somente o tráfego relevante vá para os proxies, encerramento de conexão TCP do cliente, nova conexão TCP para o destino, interceptação de SSL/TLS (que requer geração de certificado sob demanda emulando o certificado de destino) que inclui descriptografia e criptografia de TLS, autenticação de proxy (Kerberos, NTLM, OIDC), decodificação de HTTP 1.1/2.0.
Essa funcionalidade comum em cada caixa/aparelho virtual, em uma estimativa, ocupa 50% dos recursos totais de CPU da solução de segurança.
O acesso seguro aos aplicativos também é obtido de forma semelhante, encadeando a solução de segurança discreta, conforme mostrado na Figura
2. Aqui também, a funcionalidade comum é a mesma em várias soluções de segurança. É quase como a funcionalidade comum das soluções de segurança usadas no Secure Internet Access.
Algumas diferenças incluem a terminação SSL/TLS em vez de interceptação e autenticação de usuário por meio de métodos tradicionais em vez de autenticação por proxy.
A sobrecarga média da funcionalidade comum em uma solução de segurança pode chegar a 50% da solução total.
A latência decorrente dessa arquitetura pode aumentar em alguns milissegundos devido ao encadeamento de funções.  Outro grande desafio enfrentado pelas empresas com appliances físicos e virtuais é o dimensionamento.
Originalmente, o dimensionamento era feito com o uso de appliances maiores ou com a atribuição de mais recursos de CPU e memória às soluções de segurança baseadas em VM.
Isso é chamado de aumento de escala.
Se o tráfego for de volume constante, faz sentido que as empresas gastem dinheiro em appliances físicos/virtuais maiores.
Porém, se o tráfego for intenso, as empresas não gostam de ver dinheiro sendo desperdiçado.
Pense nos casos em que apenas alguns dias do ano o tráfego é maior.
Por que as empresas gostariam de gastar dinheiro com esses picos durante todo o ano?
Isso levou à próxima evolução, em que os fornecedores de segurança começaram a oferecer suporte à arquitetura de expansão por meio do serviço fornecido pela nuvem.
Isso é como o raciocínio para IaaS no mundo dos aplicativos em nuvem.
Na arquitetura scale-out, mais instâncias das soluções de segurança são ativadas automaticamente ao detectar o tráfego mais alto ou devido a um ataque DDoS e são desativadas quando a demanda diminui.
A Figura 3 mostra essa arquitetura scale-out.  Não há dúvida de que a funcionalidade de scale-out é necessária.
No entanto, ela precisa de um balanceador de carga em cada solução de segurança.
Esse balanceador de carga é necessário para equilibrar a carga das sessões em várias instâncias da solução de segurança.
As várias passagens do balanceador de carga exigem mais recursos e aumentam a latência de ponta a ponta das sessões de tráfego.
A próxima evolução da arquitetura de segurança de rede aborda os desafios de
- Necessidade de um número maior de recursos de computação
- Maior latência
Com
- Uma arquitetura de proxy
- Arquitetura de passagem única
Arquitetura single-pass e one-proxy (arquitetura convergente)
Conforme mostrado na figura 4 abaixo, todas as funções de segurança são agrupadas com proxy e outras funções comuns que entram em cena apenas uma vez.
Todas as funções de segurança são chamadas uma de cada vez, no modo run-to-completion.
Como resultado, essa arquitetura consome recursos de computação de forma eficiente.
Como todas as funções são chamadas no mesmo contexto de espaço do usuário, as cópias de memória são evitadas.
Além disso, a arquitetura de um processo no espaço do usuário reduz drasticamente as trocas de contexto do sistema operacional.
Uma única instância de proxy pode processar várias sessões ao mesmo tempo por meio de multi-threading, com cada thread processando um subconjunto de sessões, aproveitando assim as CPUs de vários núcleos de forma eficaz.
O recurso multi-threading também permite que algumas funções de segurança sejam executadas em paralelo, em vez de em série, para uma determinada sessão de tráfego, melhorando assim a latência.
Essa arquitetura é chamada de “Single Pass Parallel Processing”. Para lidar com cargas inesperadas e cenários de DDoS, é adotada uma arquitetura de escalonamento automático com uma instância de balanceador de carga que interfere no balanceamento de carga da sessão.  Nessa arquitetura, o proxy expõe a API da interface.
Todas as funções de segurança se conectam a essa API.
O proxy chama as funções de segurança relevantes durante o processamento da sessão de tráfego.
Nem todas as funções de segurança podem ser implementadas pelos desenvolvedores de soluções SASE.
Os desenvolvedores de soluções SASE trabalham com fornecedores de tecnologia integrando mecanismos e feeds de fornecedores de tecnologia aos proxies.
Dessa forma, os clientes dos provedores de SASE obtêm o melhor dos dois mundos: SASE de alto desempenho com as melhores implementações de segurança.
Dito isso, alguns fornecedores de tecnologia podem não fornecer o mecanismo na forma de SDK para o desenvolvimento de funções de segurança como parte do proxy.
É possível que eles o tenham como um serviço de nuvem.
O DLP é um exemplo em que muitos fornecedores de tecnologia o têm como um serviço de nuvem.
Além disso, em alguns casos, pode ser que o provedor de soluções SASE não queira integrar algumas funções de segurança no mesmo contexto de processo de espaço do usuário do proxy por motivos como restrições de memória, para evitar incompatibilidade de licenças, para evitar tornar o espaço do usuário frágil e outros.
Arquitetura unificada e funções de segurança “Bring Your Own
A próxima evolução na arquitetura SASE é mostrada abaixo.
Há três pontos importantes mostrados na Figura 6 abaixo. **Suporte a serviços de segurança via ICAP (Internet Content Adaptation Protocol):** As empresas podem estar acostumadas ou querer usar serviços de segurança de outros fornecedores de segurança. As especificações [ICAP](https://datatracker.ietf.org/doc/html/rfc3507) da IETF especificam como os proxies podem se comunicar com serviços externos de adaptação de conteúdo, inclusive serviços de segurança.
Ao permitir serviços de segurança externos, os provedores de soluções SASE permitem que as empresas escolham os serviços de segurança de sua preferência. **Traga suas próprias funções de segurança:** De acordo com o relatório de segurança da IBM “Cost of a Data Breach Report 2022”, as organizações estão levando, em média, 277 dias para detectar e conter uma violação de dados.
Embora a SASE forneça uma configuração de política muito boa, é possível que algumas violações de dados exijam regras programáticas.
As organizações que analisam a violação de dados estão em uma boa posição para desenvolver esses programas.
Dependendo dos provedores de SASE ou dos serviços de segurança, os fornecedores podem levar algum tempo, pois os lançamentos de produtos precisam passar por um ciclo de vida completo de desenvolvimento de software.
Para evitar esses atrasos, as novas arquiteturas SASE oferecem às equipes de segurança das empresas uma maneira de desenvolver regras programáticas por conta própria e implantá-las.
Como elas não devem causar instabilidade no proxy, as arquiteturas SASE fornecem tempos de execução WASM para permitir a criação de regras programáticas como módulos WASM.
Como o tempo de execução do WASM atua como sandbox, qualquer problema com os módulos WASM não faz com que o espaço de usuário de hospedagem e outros plug-ins de função de segurança travem/morram. **Proxy unificado:** Um proxy unificado para o Secure Internet Access e o Secure Application Access pode reduzir os requisitos de memória.
Os mecanismos e feeds de algumas funções de segurança, como o Anti-Malware e o DLP, consomem muita memória.
Portanto, criar duas instâncias diferentes de proxy para cada site da empresa pode ser caro.
Além disso, ter um proxy que ofereça suporte aos três modos (direto, reverso e transparente) também é uma boa prática de desenvolvimento do ponto de vista da produtividade do desenvolvedor. 
Outros princípios de arquitetura seguidos na geração mais recente da arquitetura SASE são
**Nativo da nuvem:** Conforme discutido na [postagem](https://www.aryaka.com/blog/unified-sase-and-universal-sase/) Universal SASE deste [blog](https://www.aryaka.com/blog/unified-sase-and-universal-sase/), os serviços SASE são necessários no local, nas nuvens e nas bordas.
Por isso, as arquiteturas SASE de nova geração estão seguindo os princípios “nativos da nuvem” para fazer com que a SASE funcione em qualquer lugar.
Embora nativo da nuvem e Kubernetes não sejam sinônimos, muitas vezes, as soluções que se dizem nativas da nuvem são baseadas em Kubernetes.
O motivo da escolha de fazer com que as soluções funcionem no Kubernetes é que todos os provedores de nuvem/edge oferecem o Kubernetes como serviço e, mais importante, a interface da API é mantida intacta pelos provedores de nuvem/edge.
Devido à interface de API consistente do Kubernetes em todos os provedores de nuvem/edge, as soluções SASE baseadas em K8s funcionam perfeitamente em todos os provedores de nuvem/edge. **Arquitetura de isolamento:** As arquiteturas SASE atuais, por motivos de eficiência, permitem que várias sessões de locatário passem por processos de espaço de usuário compartilhado.
Métodos inteligentes são usados para garantir que algum nível de isolamento seja mantido, mesmo que haja sobreposição de endereços IP entre os locatários.
Os processos de espaço de usuário compartilhado para vários locatários não são bons do ponto de vista do desempenho e do isolamento de segurança.
Com recursos compartilhados, é possível que qualquer comportamento inadequado, como um ataque DDOS a um locatário, possa causar problemas de desempenho no tráfego de outros locatários.
Além disso, qualquer exploração no processo de espaço de usuário compartilhado pode expor todos os segredos/senhas/chaves de todos os locatários.
Tendo em mente o acima exposto, as arquiteturas SASE de nova geração estão cada vez mais optando por instâncias de proxy dedicadas por meio de processos de espaço de usuário dedicados ou contêineres dedicados. **Arquitetura API first:** As soluções SASE atuais fornecem CLI e Portal para configuração e observação.
Algumas soluções SASE usam APIs entre CLI/Portal para sistemas de gerenciamento de back-end, mas elas não são anunciadas.
Em alguns casos, as APIs não são limpas.
As novas soluções SASE estão adotando a arquitetura API first, em que as APIs são definidas não apenas para implementações de CLI e Portal, mas também para que terceiros desenvolvam entidades programáticas externas.
As APIs permitem o SecOps-as-code via terraform e outros, desde o desenvolvimento de scripts simples até o desenvolvimento de fluxos de trabalho complexos.
É prática geral usar a API RESTful, cargas úteis JSON com documentação baseada em OpenAPI, mas alguns também expõem recursos personalizados do Kubernetes para configurar objetos e políticas de segurança e de rede.
Também se espera que a arquitetura API First separe a lógica de backend real da implementação do RBAC (Role Based Access Control, controle de acesso baseado em função).
A experiência do setor mostra que há um bom número de vulnerabilidades quando o RBAC e a lógica de negócios são combinados.
Como resultado, o setor está se movendo no sentido de separar a funcionalidade do RBAC para entidades externas e deixar os aplicativos concentrados na lógica comercial.
A mesma lógica está sendo aplicada aos sistemas de gerenciamento de SASE, em que os sistemas de gerenciamento de SASE se concentram na política/objetos SAE e na observabilidade e deixam a funcionalidade RBAC para entidades externas, como proxies de entrada e gateways de API.
Os proxies de entrada cuidam de toda a autenticação e autorização e do roteamento de API.
O bom é que um ingress proxy pode fazer o frontend de vários aplicativos.
Por isso, os usuários administradores só precisam se familiarizar com uma entidade RBAC em muitos aplicativos. Para essa separação da lógica comercial do RBAC, espera-se que as soluções de arquitetura API-first sigam algumas diretrizes.
Por exemplo, muitos proxies de entrada e gateways de API esperam que o URI seja usado para apontar para um recurso para RBAC.
No caso da automação baseada em fluxo de trabalho, espera-se que os sistemas de gerenciamento possam marcar a configuração e restaurar as marcas mais antigas para permitir padrões de saga.
Espera-se que qualquer arquitetura API-first siga as práticas recomendadas do setor.
Resumo
As arquiteturas de segurança de rede estão evoluindo de entidades físicas/monolíticas para appliances e contêineres virtuais.
Muitos princípios nativos da nuvem que se tornaram populares no mundo dos aplicativos estão sendo adotados nas soluções SASE para obter os benefícios semelhantes aos da nuvem, incluindo scale-out/in, agilidade, prontidão para várias nuvens/frente e uso eficiente de recursos em vários locatários.
Fique atento a este espaço para conhecer os novos princípios de arquitetura e como a Aryaka está aproveitando as tecnologias semelhantes à nuvem.
- Blog CTO Insights
A série de blogs Aryaka CTO Insights oferece liderança de pensamento para tópicos de rede, segurança e SASE. Para obter as especificações dos produtos Aryaka, consulte as fichas técnicas da Aryaka.