Arquitetura de Acesso Remoto Centrada em Confiança: Integrando Negócio, SASE/SSE e Modelos de Implantação

A rápida evolução dos modelos de trabalho distribuído e a adoção massiva de infraestruturas cloud-native demandaram uma reestruturação nas arquiteturas de acesso remoto. O paradigma tradicional, baseado na segurança de perímetro, demonstrou ser insuficiente para combater ameaças modernas, levando à consolidação do conceito de Zero Trust (Confiança Zero). Para arquitetos de rede, a construção de um acesso remoto resiliente e seguro exige uma compreensão dos objetivos de negócio, a fim de alinhar as capacidades técnicas dos modelos Secure Access Service Edge (SASE), SD-WAN e Security Service Edge (SSE) com as estratégias de implantação Greenfield e Brownfield.

Identificação de Fluxos de Trabalho Corporativos

A arquitetura Zero Trust permite definir a confiança necessária para que usuários e dispositivos acessem diferentes aplicações, utilizando os princípios de Zero Trust (que demanda uma estratégia bem definida no acesso aos recursos computacionais seja local ou em cloud). Em sua fase de implementação para o acesso remoto as aplicações, é necessário converter esses conceitos em fluxos de trabalho de negócios.

  • Colaborador local utilizando um dispositivo confiável para acessar uma aplicação privada no data center local.
  • Colaborador local utilizando um dispositivo confiável para acessar uma aplicação privada na nuvem ou SaaS.
  • Prestador de serviço local (terceiro) utilizando um dispositivo não confiável para acessar aplicações privadas.
  • Visitantes locais com acesso não confiável utilizando apenas a Internet.
  • Colaboradores remotos utilizando dispositivos confiáveis para acessar aplicações privadas no data center.
  • Colaboradores remotos utilizando dispositivos confiáveis para acessar aplicações em SaaS.

A Relação Causal entre Estratégia de Negócio e Arquitetura de Acesso

A formulação de uma arquitetura de acesso remoto eficaz transcende a mera seleção de produtos; ela deve ser holisticamente guiada pelos pilares de Pessoas, Processos e Tecnologia. O objetivo principal é garantir apenas o acesso necessário (least-privilege access) para um dado serviço.

Do ponto de vista estratégico, a arquitetura deve inicialmente estabelecer um nível dinâmico de confiança para os solicitantes de acesso. Isso requer:

  1. Definição de Confiança do Usuário: Envolve a autenticação contínua da identidade, que se apoia em técnicas robustas de verificação, como a autenticação multifator (MFA). A estratégia de Zero Trust exige a Verificação Explícita (Explicit Verification), onde nenhuma entidade é automaticamente confiada.
  2. Definição de Confiança do Dispositivo: Implica assegurar que um dispositivo esteja em um estado saudável (healthy state) e autorizado.

A partir da verificação bem-sucedida, as políticas de acesso são definidas com base no princípio de acesso de privilégio mínimo, frequentemente incorporando conceitos de Just-in-Time (JIT) e Just-Enough Access (JEA), limitando o acesso a recursos críticos apenas quando estritamente necessário.

SASE e SSE: A Convergência de Rede e Segurança

A complexidade crescente da rede, impulsionada pelo uso de multinuvem e trabalho remoto, estimulou o desenvolvimento de modelos unificados.

SASE (Secure Access Service Edge) é uma estrutura de segurança baseada em nuvem que integra serviços de rede, como Software-Defined Wide Area Network (SD-WAN), com serviços de segurança, incluindo firewalls e controle de acesso baseado em identidade e o SSE. O SASE visa simplificar a entrega de serviços de rede e segurança a todos os endpoints, independentemente de sua localização geográfica.

SSE (Security Service Edge) é um subconjunto fundamental do SASE, focando estritamente nos componentes de segurança, abstraindo a funcionalidade de conectividade da WAN. Os principais componentes do SSE incluem Secure Web Gateway (SWG), Cloud Access Security Broker (CASB) e o acesso remoto, que é tipicamente implementado via Zero Trust Network Access (ZTNA). O SSE tornou-se o método mais adotado pelo mercado para a implementação de arquiteturas Zero Trust  devido à sua simplicidade e flexibilidade nativas da nuvem, garantindo a verificação contínua da segurança, mesmo para acesso remoto a aplicações SaaS.

O SSE oferece suporte direto para diversos casos de uso de acesso remoto, incluindo:

  1. ZTNA Baseado em Cliente ( Client-Based ): Projetado para dispositivos corporativos gerenciados , requer a instalação de um módulo ZTA no endpoint . Este módulo intercepta e direciona o tráfego para a corretora SSE na nuvem, garantindo que a postura do dispositivo seja constantemente avaliada antes de conceder acesso a aplicações privadas.
  2. ZTNA Sem Cliente (Clientless): Utilizado para dispositivos não gerenciados (como parceiros ou convidados). O acesso é realizado via navegador (browser-based)ou dispositivo externo com função de gateway, onde o SSE atua como um reverse proxy após autenticação e autorização, eliminando a necessidade de clientes VPN tradicionais.
  3. ZTNA Baseado em VPN (VPN-Based): Permite a migração de concentradores VPN legados para a nuvem SSE, mantendo a conectividade VPN obrigatória, enquanto aplica cadeias de serviços de segurança e políticas de dados consistentes.

Em um modelo ZTNA, o acesso a aplicativos e recursos é fornecido com base na verificação rigorosa da postura do dispositivo e de outros fatores contextuais, independentemente da localização do usuário ou da conexão de rede.

Estratégias de Implementação ZTNA em Greenfield e Brownfield

A adoção do ZTNA através do SSE requer estratégias distintas, dependendo do estágio de maturidade da infraestrutura existente.

1. Implementação Greenfield (Início do Zero)

Em um ambiente Greenfield, a infraestrutura é construída do zero, permitindo uma implementação limpa e alinhada com o princípio Assume Breach. A estratégia se concentra em integrar a filosofia Zero Trust em todas as fases do ciclo de vida da rede.

A abordagem técnica envolve as seguintes etapas sequenciais:

  • Definição de Objetivos: Formular uma visão clara de ZT, garantindo o alinhamento com os objetivos de negócio (e.g., fortalecimento da segurança e conformidade) e obtendo o apoio executivo necessário.
  • Definição do Roteiro (Roadmap): Desenvolver um plano abrangente que delineie marcos, cronogramas e o orçamento essencial para tecnologia e treinamento.
  • Desenvolvimento da Arquitetura e Projeto: Criar uma arquitetura de alto nível que incorpore nativamente a segmentação e a gestão de identidade (IAM). Isso inclui o desenho do layout de rede, estabelecendo zonas para diferentes tipos de ativos e dados, sendo a macrosegmentação a separação inicial e a microsegmentação (baseada em identidades ou SGTs) a base para o controle granular entre segmentos.

2. Implementação Brownfield (Infraestrutura Existente)

Em um ambiente Brownfield, o desafio reside na integração do ZTNA em sistemas legados e operacionais que foram concebidos sem os princípios de Zero Trust. A estratégia aqui é mais adaptável e faseada (phased and adaptable strategies) para mitigar interrupções operacionais.

A transição deve ser executada metodologicamente:

  • Avaliação e Priorização: Realizar uma avaliação abrangente do ambiente de segurança atual, incluindo controles de acesso e privilégios de usuário.
  • Foco no Risco Elevado: Identificar as áreas de maior risco, como aplicações críticas ou dados sensíveis, para iniciar a implementação do ZTNA.
  • Transição Gradual e Adaptável: O objetivo é a transição gradual para o ZT, identificando vulnerabilidades e reforçando a segurança sem comprometer as operações em curso. Isso pode envolver o uso inicial de microsegmentação em modo de monitoramento antes da imposição total (enforcement) para entender os fluxos de tráfego e evitar a interrupção de sistemas legados.

Em ambos os cenários, a manutenção de políticas consistentes e a automação da resposta a ameaças (Automated Response and Orchestration) são importantes para o sucesso da arquitetura de acesso remoto. Ao assumir a premissa de violação presumida (Assume Breach), e ao aplicar continuamente políticas granulares por meio de SASE/SSE, as organizações podem evoluir de um modelo focado em perímetro para uma postura de segurança dinâmica e resiliente.

Concluindo…

A mudança para modelos de acesso baseados em SASE e SSE não é apenas uma tendência tecnológica, mas uma necessidade operacional ditada pela dispersão de usuários, dados e aplicações. A arquitetura de acesso remoto, embasada na tríade Explicit VerificationLeast-Privilege Access e Assume Breach, e implementada através de estratégias de microsegmentação (base de ZTNA), garante que o acesso, seja ele em uma implantação Greenfield ou uma transição Brownfield, seja sempre autenticado, autorizado e continuamente monitorado. A capacidade de aplicar políticas de forma uniforme, independentemente da localização do usuário ou do recurso, transforma a arquitetura de acesso remoto em um componente habilitador de segurança, e não apenas um mecanismo de conectividade.

Referência

Zero Trust in Resilient Cloud and Network Architectures – Josh Halley, Dhrumil Prajapati, Ariel Leza, Vinay Saini – Cisco Press 2025

https://arubanetworking.hpe.com/techdocs/VSG/docs/125-remote-worker-design/esp-rw-000-design/

Oversubscription para os uplinks em uma rede LAN de duas camadas (two-tier)

O oversubscription, no contexto de redes de computadores, especialmente em data centers, refere-se à prática de dimensionar a capacidade de um switch de forma que a porta de uplink (portas que conectam em outros Switches de camadas superiores) tenha uma capacidade menor do que a soma das portas de downlink (conexão utilizada em endpoint e servidores).

A rede pode tolerar o uso de oversubscritpion em razão de todos os servidores possuírem diferentes perfis de trafego e não utilizarão toda a banda disponível de suas portas ao mesmo tempo.

Imagine um switch com 48 portas de 10Gbps cada e 4 portas de 40Gbps. A porta de uplink desse switch, que conecta o switch a outro equipamento na rede, pode ter apenas 160Gbps, enquanto o total de portas em uso ao mesmo tempo demandaria 480Gbps. Neste caso, o oversubscription ratio seria de 3:1 (480/160).

O cliente pode especificar a proporção máxima de oversubscription permitida para o projeto. Caso contrário, você geralmente deve buscar fornecer entre 3:1 e 5:1 de oversubscription entre a camada de acesso e a camada core em uma topologia de duas camadas.

Para dimensionar a largura de banda do uplink, use a fórmula:

Largura de banda do uplink = (Soma das portas de acesso) / Oversubscription

Essa fórmula calcula a capacidade mínima necessária no uplink, considerando a razão de oversubscription desejada.”

Exemplo Prático

Imaginando um switch com 10 portas de 1Gbps cada. Você deseja configurar uma proporção de oversubscription de 4:1. Qual será a largura de banda mínima do uplink?

  • Soma da largura de banda das portas de acesso: 10 portas * 1Gbps/porta = 10Gbps
  • Proporção de oversubscription: 4
  • Largura de banda do uplink: 10Gbps / 4 = 2.5Gbps

10*1 / 4 = 2.5Gbps

Portanto, você precisará de um uplink de pelo menos 2.5Gbps para atender a essa configuração. Caso o Switch possui apenas portas de 1Gbps no uplink, seriam necessárias pelo menos 3 portas de 1Gbps.

Observe que, se um cliente exigir um oversubscription muito baixo, você deve projetar uma topologia leaf-spine.

Referências

HPE Aruba Certified Network Architect – Data Center – Official Certification Study Guide (Exam HPE7 -A04)

MPLS (Multi Protocol Label Switching)

Apesar de existirem inúmeros sites em português com ótimas referencias de Introdução ao Protocolo MPLS, escreveremos uma serie de artigos com a utilização de MPLS em diversos cenários. Esse post servirá como uma pequena introdução para a descrição e utilização do protocolo com o foco um pouco mais simples na arquitetura e serviços.

O protocolo MPLS (Multi Protocol Label Switching) foi criado para permitir o encapsulamento de diversos protocolos de rede para serem encaminhados por Roteadores baseando-se apenas no endereço do Label ao invés do endereço de rede. A tecnologia é largamente utilizada pelos Provedores de Internet com diversas topologias de serviços orientado a redes em apenas uma única rede convergida com o MPLS em seu Backbone, permitindo a utilização de Redes Privadas (VPNs MPLS), Qualidade de Serviço (QoS), Any Transport over MPLS (AToM) e Engenharia de tráfego (MPLS-TE).

Ele é chamado de Multiprotocolo pois é utilizado com qualquer protocolo da camada de Rede e em certos cenários permite até o transporte de protocolos da Camada de Enlace sobre MPLS, apesar de quase todo o foco estar voltado no uso do MPLS com o IP.

O objetivo de uma rede MPLS dentro dos Provedores de Serviço não é o de conectar diretamente a sistemas finais.  Ao invés disto ela é uma rede de trânsito, para transporte de pacotes.

Em sua função básica os Roteadores do Backbone chamados de Provider Routers (P) encaminham o tráfego baseando-se apenas nos Labels.  Já os roteadores que são responsáveis por receber os pacotes IP e encapsulá-los com labels em uma rede MPLS são chamados de Provider Edge Routers (PE).

A terminologia dada aos equipamentos em uma rede MPLS é muito importante para identificarmos a função de cada equipamento na topologia e a sua função na arquitetura.

De certa forma, um cliente ao comprar uma comunicação entre as filiais utilizando um link MPLS privado (MPLS VPN), não terá necessariamente em seus roteadores o encaminhamento de pacotes via labels e muito menos a troca deles. Os roteadores designados para clientes, chamados de Customer Edge Routers (CE) possuem a função de prover conectividade na rede MPLS situados na “borda do cliente” (saída para rede).

A conectividade entre PE e CE poderá ser tanto provida por roteamento estático ou via IGP.

Mas o que são os Labels?

Em uma tradução literal, poderíamos dizer que label teria a atribuição de um rótulo. Em sua função no modo frame o label é inserido na frente do cabeçalho da camada de rede. Um pacote pode ter um ou mais rótulos dependendo do serviço oferecido na rede MPLS.

O label é um identificador, de tamanho fixo e significado local. Todo pacote ao entrar numa rede MPLS recebe um label. Desta forma os roteadores só analisam os labels para encaminhar os pacotes. O cabeçalho MPLS deve ser posicionado depois de qualquer cabeçalho da camada de enlace e antes do cabeçalho da camada de rede, ele é conhecido como Shim Header pelo seu posicionamento entre os 2 cabeçalhos e é “carinhosamente” chamado de protocolo da camada 2,5.do Modelo OSI.

Nos próximos posts daremos foco no processo de encaminhamento e troca de labels, outros termos comuns em uma rede MPLS e a configuração de Roteadores para a troca de labels.

Um grande abraço

Referências:

http://www.gta.ufrj.br/grad/01_2/mpls/mpls.htm
http://pt.wikipedia.org/wiki/MPLS
Designing and Implementing, IP/MPLS-Based Ethernet Layer 2 VPN Services, An Advanced Guide for VPLS and VLL, Zhuo ( Frank) Xu – Wiley Publishing, INC – 2010
MPLS Fundamentals, Luc De Ghein. – Cisco Press – 2006
TCP sobre MPLS, ENNE, ANTONIO JOSE FIGUEIREDO – Ciência Moderna – 2009

COMO ESCOLHER UM SWITCH DE REDE?

O mercado de TI oferece uma grande variedade de modelos de switches para os mais diversos fins.

Nesse video montamos uma lista de itens que pode te ajudar a qualificar o equipamento adequado com alguns simples pontos.

– Perfil do equipamento;
– Definir os ativos que conectarão ao Switch;
– Infra;
– Funcionalidades;
– Throughput;
– Integração com os equipamentos de outros fabricantes da rede ;
– Profissionais capacitados na equipe para gerenciamento;
– Troubleshooting;
– Robustez/ Credibilidade do fabricante / Garantia;
– Custo $$$;

SD-WAN – QUAIS SÃO OS DESAFIOS DA WAN QUE A TECNOLOGIA VEM SOLUCIONAR?

SD-WAN é a sigla para se referir ao termo “Software-Defined Wide Area Network”. Trata-se de uma abordagem onde as definições de tráfego são controladas por software de forma a se criar uma rede overlay para permitir a conectividade no âmbito de redes WAN.

Podendo ser composta de links dedicados, Internet de banda larga e serviços sem fio, a tecnologia SD-WAN permite gerenciar aplicativos de maneira eficiente, em particular aqueles na nuvem.

O tráfego é encaminhado de maneira automática e dinâmica pelo caminho WAN mais adequado e eficiente com base nas condições de rede, demandas das aplicações, requisitos de QoS e custo de circuito.

REDES WIRELESS – COLETA DE INFORMAÇÕES PARA UM PROJETO WI-FI

Nesse vídeo listamos algumas perguntas a serem feitas para o levantamento de informações para desenvolvimento de um projeto de rede sem fio.

Eu utilizo esse questionário para desenvolvimento de projetos de Wi-Fi e auxiliam a encontrar os problemas as serem resolvidos, necessidades de negócio e a escolha dos equipamentos que ajudarão em todo o ecossistema da rede sem fio.

VLAN DESIGN – COMO PLANEJAR MELHOR A SEGMENTAÇÃO DE REDES

Nesse vídeo listamos alguns pontos para um melhor planejamento na segmentação de redes com a utilização de VLANs.

TOPOLOGIA DE REDE CAMPUS – NETWORK DESIGN – 2 E 3 CAMADAS

A integração da rede campus utilizando dados, voz e vídeo torna-se essencial para a alta disponibilidade e impulsionamento dos negócios. Logo, uma rede local (LAN) projetada corretamente é um requisito fundamental, pois uma rede construída de forma hierárquica torna mais fácil o seu gerenciamento, expansão e troubleshooting para detecção de problemas. O design de rede hierárquico envolve a divisão da rede em camadas discretas, facilitando escalabilidade e desempenho.

Ciclo de Vida de um Projeto de Redes – PPDIOO e PBM

O PPDIOO é um acrônimo para “Prepare, Plan, Design, Implement, Operate, and Optimize”, que se refere ao ciclo de vida de rede proposto pela Cisco para o projetos, implementações e operação de redes de computadores.

O ciclo de vida PPDIOO é dividido em seis fases, cada uma com um conjunto de atividades específicas:

Prepare (Preparar): Nesta fase, o objetivo é identificar as necessidades do negócio e as metas da rede, avaliar as restrições e limitações do projeto e desenvolver um plano de projeto preliminar. Algumas atividades incluem: definir objetivos e requisitos de negócios, analisar recursos disponíveis e restrições, e identificar as partes interessadas.

Plan (Planejar): Nesta fase, o objetivo é criar um plano de projeto detalhado, incluindo um cronograma, um orçamento e um plano de gerenciamento de riscos. Algumas atividades incluem: definir as especificações técnica. Aqui, os planos de alto nível são desenvolvidos, incluindo um plano de gerenciamento do projeto, um plano de gerenciamento de risco e um plano de comunicação. Os requisitos técnicos e de design são estabelecidos .

Design (Projetar): Nesta fase, o objetivo é desenvolver um design detalhado da rede, incluindo a seleção de tecnologias, equipamentos e protocolos. Algumas atividades incluem: criar um esquema de endereçamento IP, projetar a topologia de rede, selecionar equipamentos e tecnologias de rede e criar um plano de configuração.

Implement (Implementar): Nesta fase, o objetivo é implementar a rede de acordo com o plano de projeto e o design. Algumas atividades incluem: instalar equipamentos de rede, configurar a rede, testar a conectividade e verificar se o desempenho da rede atende às especificações.

Operate (Operar): Nesta fase, o objetivo é gerenciar e manter a rede em funcionamento, garantindo a sua disponibilidade, segurança e desempenho. Algumas atividades incluem: monitorar a rede, solucionar problemas, fazer backup e restaurar dados, gerenciar usuários e garantir a conformidade com políticas e regulamentos.

Optimize (Otimizar): Nesta fase, o objetivo é melhorar continuamente o desempenho da rede, identificando áreas para aprimoramentos e implementando melhorias. Algumas atividades incluem: avaliar o desempenho da rede, identificar gargalos, implementar mudanças e atualizações e garantir a evolução da rede para atender às necessidades futuras do negócio.

O ciclo de vida PPDIOO é um modelo iterativo, o que significa que as fases podem ser revisitadas e repetidas para melhorar o desempenho da rede ou atender a novas necessidades de negócios.