Parece que foi ontem que ouvimos falar em SASE pela primeira vez. A proposta de integrar rede e serviços de segurança da nuvem pareceu atraente e repercutiu no mercado. E desde então, não é surpresa que os Provedores de Serviços de Internet (ISPs) começaram a explorar como eles poderiam oferecer um conjunto de serviços SASE. Agora no que diz respeito aos dias atuais, todos nós estamos observando como Security Service Edge (SSE), como uma nova categoria de produtos, está sendo recebida pelas empresas. Recentemente, o Gartner anunciou o primeiro Quadrante Mágico para SSE, e desde então, as equipes de gerenciamento de ISPs estão discutindo o que SSE significa para os negócios. Afinal, é outra ameaça competitiva que está sendo entregue pelos provedores de nuvem? Ou é uma oportunidade de introduzir um novo serviço no mercado? Ou espere, indo mais a fundo: o que isso significa para o serviço gerenciado de SASE que acabei de lançar?
Como você provavelmente já sabe, SSE é parte da arquitetura SASE. É a stack de segurança que integra um conjunto específico de serviços de segurança como Access Security Broker (CASB), Secure Web Gateway (SWG), Zero Trust Network Access (ZTNA), Remote Browser Isolation (RBI), e Cloud Firewall (CFW). A outra parte de SASE é composta por WAN Edge Services—SD-WAN, otimização de aplicações, conectividade e todas as outras coisas relacionadas à rede. Simplesmente falando, SSE + WAN Edge Services = SASE.
Por que os Provedores de Serviços estão bem-posicionados para arquitetura SASE
A lógica nos leva à conclusão de que se um provedor oferece serviços gerenciados de SASE, ele deve também ter capacidades SSE como parte deles. Mas o diabo, como sempre, mora nos detalhes. O Gartner, que definiu os termos SASE e SSE, descreve para o futuro as seguintes propriedades da estratégia SASE baseada em SSE:
- Aplicação consistente de políticas, independentemente da localização;
- Plano de controle de políticas consolidado;
- Visibilidade e controle de dados confidenciais.
Portanto, se você já oferece um serviço gerenciado de SASE, agora é um bom momento para comparar suas capacidades com esses requisitos a fim de garantir que seu serviço vá além da simples oferta de produtos separados e atenda às demandas de segurança mais recentes.
Mas e se você não tiver uma oferta SASE, ainda vê a demanda do mercado? Seu departamento de vendas fala sobre as consultas dos clientes a respeito de SASE. Seu departamento de marketing compartilha previsões empolgantes sobre como o mercado SASE crescerá durante os próximos cinco anos. E como uma autoridade em design de serviços, você para e se pergunta: como posso oferecer um serviço atraente? Como uso os pontos fortes da minha empresa—serviços de conectividade amplos e maduros—para me manter à frente do jogo?
A boa notícia é que os provedores de serviços estão muito bem-posicionados para fornecer a arquitetura SASE, oferecendo um serviço abrangente. Em vez de oferecer várias soluções abordando casos de uso de nicho, você pode usar o amplo alcance de sua rede e sua experiência no atendimento de grandes mercados para introduzir um serviço consistente que seja compatível com SASE—conecte QUALQUER usuário com QUALQUER serviço de nuvem e garanta a proteção de dados. Você pode cobrir todos os tipos de tecnologias de acesso e fornecer o mesmo nível de visibilidade e gerenciamento de políticas com um SLA aplicado contratualmente. Usando SD-WAN, ao controlar tanto o "underlay" quanto o "overlay" da conectividade do cliente, você é capaz de oferecer um SLA melhor e resolver qualquer problema mais rapidamente.
Como os provedores de serviços podem integrar recursos de SSE à SASE
Para tentar reduzir o tempo de lançamento no mercado, você pode considerar posicionar suas capacidades atuais de WAN Edge Services como SSE. Sua atual oferta SD-WAN provavelmente terá alguns recursos de segurança, como Firewall (Next Generation) ou UTM, entretanto, não se engane—essas capacidades por si só não se qualificariam como SSE
SSE vai muito além dos recursos de firewall pontuais, oferecendo mais controles de segurança para um conjunto mais amplo de casos de uso. A combinação de CASB e SWG permite criar uma política singular para controlar o tráfego na nuvem e na web para qualquer aplicação e qualquer usuário. O isolamento remoto do navegador e o acesso à rede Zero Trust tornam-se parte desta política, aproveitando o contexto de dados coletados pela CASB/SWG. Todos estes serviços são fortemente integrados dentro de SSE em torno do conceito de proteção de dados.
Então, como você implementa um serviço de SSE? Que segmentos de clientes você planeja abordar? Você vai usar soluções diferentes para diferentes tipos de clientes? Que stack de tecnologia deve ser usado? SSE pode ser implementado usando os princípios da NFV como uma cadeia de serviços de rede e segurança VNFs ou CNFs? Deve ser executado em uma nuvem pública, nuvem privada ou em um modelo híbrido, contando com algo como AWS Outpost, Azure Stack ou Google Anthos? Ou talvez valha a pena pesquisar as soluções SSE existentes e pensar em integrá-las à sua linha de produtos?
Para ajudá-lo a responder estas perguntas, vamos rever as expectativas dos usuários finais da SSE que influenciarão seu processo de decisão:
- Console único, conjunto único de políticas, data lake único para logs. A ideia de SSE surgiu de uma consolidação de mercado dos componentes SWG, CASB e ZTNA. A última coisa que seus usuários querem é gerenciar vários produtos usando vários consoles e APIs. Além disso, como provedor de serviços, você provavelmente não quer que suas operações repliquem as mesmas políticas entre várias ferramentas, o que aumenta os custos operacionais internos.
- Visibilidade de atividades na nuvem que é fácil de entender.Seus clientes gostariam de dashboards intuitivos que ajudassem a entender as áreas de risco e onde deveriam concentrar sua atenção. Quais aplicações são utilizadas? Os funcionários compartilham dados da empresa usando instâncias pessoais SaaS (como Gmail ou Office365)? Onde estão meus dados confidenciais? Há algum sinal de comportamento de risco nos meus usuários? Ser capaz de responder a estas perguntas demonstra como você pode fornecer capacidades muito complexas de modo user-friendly.
- Nenhum impacto no desempenho com todos os controles de segurança habilitados. Ao consumir serviços de segurança de um provedor de nuvem, seus clientes esperam um desempenho consistente, não importa onde estejam. Para garantir isso, um provedor de serviços precisa considerar de quais pontos de presença (PoP) os serviços de segurança serão entregues e como a localização do PoP impactará o mercado. Ao mesmo tempo, dentro de cada PoP, o desempenho não deve depender do tipo de controle de segurança que você habilita. Arquiteturas "single-pass" devem ser preferidas em vez de "service chains" onde o tráfego do usuário passa por múltiplas funções de segurança de forma serial.
- Custo. De acordo com várias previsões (1,2,3), o mercado SASE atingirá entre 5 e 8 bilhões de dólares nos próximos cinco anos e é provável que atraia muitos players. Para permanecer competitivo, é fundamental que um provedor encontre o preço certo para o serviço e mantenha os custos internos sob controle. Talvez a decisão mais importante aqui seja se você vai construir a infraestrutura para fornecer serviços SSE ou se vai fazer parceria com um provedor de segurança em nuvem já existente. Embora a construção de suas próprias capacidades SSE faça todo sentido a longo prazo (especialmente se você já investiu em infraestrutura NFV), considere as seguintes "incógnitas conhecidas" que podem elevar seus custos:
- Os custos das licenças VNF e CNF (funções de rede) são geralmente subestimados. Casos comuns são as funções de rede de locatário único e cadeias de serviços de backup provisionadas para cada cliente, o que requer a implantação de mais funções de rede do que você poderia ter pensado inicialmente.
- Os custos associados ao desenvolvimento da orquestração NFV (VNFM e NFVO) também são subestimados. A manutenção de várias funções de rede de diferentes fornecedores requer diversos protocolos e estruturas e normalmente resulta em uma mistura de APIs, registro, SNMP, telemetria de fluxo e assim por diante. Fica ainda mais complicado se você planeja implementar procedimentos de auto escalonamento e autorregeneração.
E depois há "incógnitas desconhecidas", como possíveis limitações de escalabilidade e desempenho instável, tudo levando seus custos cada vez mais altos. Nesse caso, oferecer SASE usando seus recursos de rede existentes e fazer parceria com um provedor de SSE ajuda você a ter custos fixos e a construir um modelo de negócios mais previsível.
Parece complexo, não? Bem, esta é apenas a ponta do iceberg. No entanto, nós da Netskope estamos fortemente convencidos de que SSE como parte da SASE não é uma ameaça, mas sim uma oportunidade para os provedores de serviços de Internet. À medida que as organizações embarcam em uma jornada de transformação da rede e da segurança, elas procuram um fornecedor conhecido e maduro capaz de lhes ajudar, e os provedores de serviços de Internet estão muito bem-posicionados para oferecer um serviço SASE de alta qualidade.
Se SASE é SSE + WAN Edge Services, então os prestadores de serviços são o sinal "mais", integrando as duas metades e oferecendo um serviço bem completo. A Netskope tem experiência em capacitar ISPs a oferecer capacidades de segurança de ponta e está pronta para ajudar. Se você estiver interessado em saber mais, por favor, acesse [email protected] e nós compartilharemos nossa experiência.
