Todo blueprint Netskope - certificação e accreditation - abre com "features and architectural benefits", e a arquitetura é genuinamente a chave que torna o resto da plataforma legível. Este artigo desenha a imagem única da qual os outros artigos Netskope deste site pendem.
A plataforma: um motor vestindo cinco siglas
O Netskope One é uma plataforma /: a metade de segurança do Secure Access Service Edge, entregue como serviço de nuvem. O vocabulário da indústria faz parecer cinco produtos - (Cloud Access Security Broker: visibilidade e controle sobre SaaS), SWG (Secure Web Gateway: filtragem web e proteção contra ameaças), (Zero Trust Network Access: acesso a aplicações privadas), Cloud Firewall (controle de saída para tudo que não é web) e (prevenção de perda de dados) - mas arquiteturalmente são superfícies de política sobre um motor de inspeção. Um único fluxo de tráfego, decifrado e decodificado, é avaliado uma vez, em passagem única, contra todas elas. Esse é o significado prático da alegação de "single-pass": não compressão de marketing, e sim a razão de uma decisão de steering e uma interceptação TLS comprarem todos os controles de uma vez, em vez de encadear cinco appliances que cada um decifra, inspeciona e recifra.
NewEdge: a rede em que o motor roda
Um proxy de nuvem é tão bom quanto sua distância do usuário, então a Netskope opera a - sua rede global de data centers operada privadamente, onde a inspeção de fato acontece. A intenção de projeto que vale entender para qualquer cenário de exame: todo data center é full-compute (qualquer ponto de presença executa qualquer inspeção, então usuários são atendidos na porta mais próxima em vez de arrastados até onde um recurso mora), e o peering com as grandes plataformas SaaS e web acontece diretamente nessas bordas. A consequência operacional é a que importa em campo: o orçamento de latência de "mande tudo por uma nuvem para inspeção" é pago na distância até o nó NewEdge mais próximo - e é por isso que projeto de steering e proximidade de data center são temas recorrentes de troubleshooting, não trivia.
Microsserviços: por que a plataforma entrega recursos do jeito que entrega
O blueprint do NSK300 nomeia "the various microservices of the Netskope Security Cloud platform" como tópico de nível arquiteto, e o conceito importa mais que qualquer lista de componentes: o pipeline de inspeção é composto de serviços independentes - decifração, decodificação de protocolo, identificação de aplicação, análise de ameaças, DLP - costurados naquela passagem única. O benefício arquitetural é do lado da implantação: serviços escalam e atualizam de forma independente pela NewEdge sem janelas de manutenção visíveis ao cliente, o contraste invisível com o mundo de appliances, em que um recurso de inspeção é uma imagem de software numa caixa cuja atualização exige downtime agendado.
Dois caminhos de dados, um cérebro de política
A peça final da imagem é a divisão sobre a qual a plataforma inteira repousa, e ela ganha artigo próprio: a proteção inline em tempo real faz proxy do tráfego enquanto ele acontece (os métodos de steering existem para entregar tráfego a ela, e a interceptação TLS existe para que ela enxergue), enquanto a proteção via API conecta-se fora de banda a tenants SaaS gerenciados e inspeciona o que já está em repouso. Mesmo vocabulário de política, mesmo motor de DLP, pontos de observação diferentes - e saber qual caminho vê o quê é, confiavelmente, onde começam tanto as questões de exame quanto os incidentes de produção com Netskope.