Muitos diretores de TI herdam a mesma história de rede. Um hotel tem um circuito de fibra sólido e regras de firewall sensatas. A propriedade seguinte funciona com um fornecedor diferente, um padrão de router diferente e uma VPN em que ninguém quer mexer antes de um fim de semana prolongado. No retalho, é frequentemente pior. Novas lojas abrem rapidamente, as aplicações na nuvem multiplicam-se e a rede acaba por ser cosida a partir de MPLS, banda larga, soluções locais improvisadas e demasiadas exceções.
Esse modelo falha quando o WiFi para convidados, o acesso dos funcionários, as aplicações na nuvem e as políticas de segurança precisam de funcionar de forma consistente em todos os locais. O WAN as a service é a transição de gerir cada filial como um pequeno projeto de rede para passar a consumir a conectividade de área alargada como um serviço gerido e fornecido na nuvem. Para organizações distribuídas, isto trata-se menos de publicidade e mais de sanidade operacional.
Ir Mais Além da Dor das Redes Legadas
Um grupo hoteleiro em crescimento normalmente não falha por falta de acesso à internet. Tem dificuldades porque cada local se comporta de forma diferente.
Uma propriedade tem conectividade fiável, mas uma segmentação fraca entre o tráfego de convidados e o de funcionários. Outra tem um WiFi para convidados aceitável, mas um acesso lento ao PMS na nuvem ou a ferramentas de colaboração. Um terceiro local precisa de alterações urgentes para apoiar uma renovação ou um evento pop-up, mas a rede depende de equipamento local, tempos de entrega dos operadores e de alguém se lembrar de como o último empreiteiro configurou a VPN.
Esse é o principal ponto de dor. Não a largura de banda isoladamente. A inconsistência.
Para as cadeias de retalho, o padrão é semelhante. O ponto de venda, inventário, sinalização digital, dispositivos dos funcionários e o acesso de convidados competem todos numa rede de filial que nunca foi desenhada para ser governada centralmente à escala. As equipas de TI passam demasiado tempo a apagar fogos em problemas locais e pouco tempo a melhorar o parque tecnológico.
Por que razão o modelo está a mudar
O mercado evoluiu porque as empresas querem que as redes se comportem de forma mais semelhante à infraestrutura na nuvem. O mercado global de NaaS foi avaliado em 11,5 mil milhões de USD em 2022, cresceu para 14,6 mil milhões de USD in 2023 e projeta-se que atinja os 115,5 mil milhões de USD até 2032, de acordo com as estatísticas de mercado de network as a service da Market.us .
Este crescimento é importante porque reflete uma decisão mais ampla que está a ser tomada pelas equipas de TI das empresas. Não querem gerir cada filial como uma coleção de caixas, circuitos e exceções. Querem uma política central, uma implementação mais limpa e uma prestação de serviços previsível.
Regra prática: Se adicionar um novo local ainda significa reconstruir a segurança, o encaminhamento e a política de acesso local por local, o seu modelo de WAN está a atrasar o negócio.
O que melhora primeiro
Quando as organizações se afastam das redes de filiais legadas, os primeiros ganhos são normalmente operacionais:
- Padronização de locais mais rápida porque a política reside numa plataforma central, não nas peculiaridades dos dispositivos locais.
- Resolução de problemas mais limpa visto que as equipas podem ver os caminhos de tráfego e a integridade do serviço em todos os locais.
- Melhor experiência do utilizador tanto para o pessoal como para os convidados, porque a conectividade deixa de depender do quão bem cada local foi construído há anos.
O ponto principal não é que a WANaaS faça a rede desaparecer. Não faz. Altera o local onde reside a complexidade e quem a tem de gerir.
Desconstruir a WAN as a Service
Se procura a explicação mais simples, a wan as a service aplica o modelo de consumo da nuvem à WAN. É a mesma mudança de mentalidade que muitas equipas já aceitaram com o e-mail, a identidade e a infraestrutura. Deixa de possuir cada peça móvel em cada local e passa a consumir um serviço que lida com o transporte, lógica de encaminhamento, visibilidade e, frequentemente, segurança a partir de um plano de controlo central.
A mudança arquitetónica central
O design tradicional da WAN vincula estreitamente o desempenho e a política ao hardware da filial. A WANaaS altera isso utilizando um modelo definido por software. As plataformas WANaaS utilizam redes definidas por software para separar os planos de controlo e de dados, permitindo o encaminhamento dinâmico de tráfego através de MPLS, banda larga e 5G com base nas condições da rede em tempo real, conforme descrito pela visão geral da WAN as a service da Red River .
Em termos práticos, isso significa que a filial já não tem de tomar todas as decisões de forma isolada. A política é definida centralmente e depois aplicada de forma consistente. O serviço pode direcionar o tráfego com base na necessidade da aplicação, qualidade do caminho, requisitos de resiliência ou regras de negócio.
Para um diretor de TI, a questão útil não é se a arquitetura é elegante. É se o tráfego certo recebe o tratamento correto sem necessidade de ajuste manual em cada local.
O que as peças móveis realmente fazem
Três componentes são os que mais importam:
O underlay de acesso
Esta é a conectividade física que já conhece. Fibra, banda larga, backup móvel ou uma mistura. A WANaaS não elimina a necessidade de circuitos. Torna-os mais fáceis de utilizar em conjunto.O overlay definido por software
É aqui que residem a seleção de caminhos, direcionamento de tráfego, segmentação e lógica de resiliência. É o que permite que um local utilize mais do que um tipo de ligação sem se tornar confuso.A camada de gestão em nuvem
Esta é a parte que muitas equipas mais valorizam. Obtém visibilidade central, política central e um modelo de serviço que escala de forma mais limpa do que a administração filial a filial.
Uma perspetiva externa útil sobre esse modelo operacional é Optimising business networks with WaaS , que enquadra a mudança de um design de WAN rígido e centrado no local para uma gestão baseada em serviços. Para uma perspetiva mais ampla sobre o modelo de rede fornecido na nuvem, o próprio guia da Purple sobre networking as a service também merece uma leitura.
Trate o WANaaS como um modelo operacional, não como uma substituição de circuitos. Se apenas trocar o transporte e mantiver os mesmos processos manuais, não obterá o principal benefício.
O que funciona e o que não funciona
O que funciona é utilizar o WANaaS para simplificar o controlo em vários locais. Um grupo hoteleiro pode priorizar centralmente o tráfego de PMS, pagamentos, voz e colaboração da equipa, mantendo o acesso de convidados isolado. Um retalhista pode implementar a mesma política de filial em todos os locais, sem ter de reconstruir o design da rede loja a loja.
O que não funciona é esperar que o WANaaS resolva, por si só, um design de aplicação deficiente, controlos de identidade fracos ou normas de LAN inconsistentes. Melhora a WAN. Não apaga todos os problemas a montante e a jusante.
Como o WANaaS se Compara ao MPLS e ao SD-WAN
Um grupo hoteleiro que abre três propriedades remodeladas num trimestre não precisa de outro projeto de design de filiais. Precisa de cada local online rapidamente, com pagamentos, PMS, aplicações da equipa e WiFi para convidados a comportarem-se da mesma forma no primeiro dia. Esse é o contexto para comparar o WANaaS com o MPLS e o SD-WAN.
A maioria das equipas de TI não está a escolher a partir de uma folha em branco. Normalmente, estão a gerir uma mistura de MPLS, SD-WAN gerida pelo próprio, ligações de internet comuns e dispositivos de segurança de filiais adicionados ao longo de vários anos.
Os padrões de tráfego também mudaram. As empresas enviam agora muito mais tráfego diretamente para plataformas de nuvem e SaaS do que enviavam quando o design de WAN hub-and-spoke era a norma. Como observado no relatório on the state of the enterprise WAN , essa mudança tem decorrido em paralelo com uma adoção mais ampla de SASE. Assim que o tráfego das filiais se direciona diretamente para o Microsoft 365, plataformas de PMS na nuvem, ferramentas de colaboração e serviços de identidade, torna-se mais difícil justificar o retorno de todo o tráfego através de um ponto central.
Comparação de Arquiteturas de Rede
| Critério | MPLS | DIY SD-WAN | WAN as a Service |
|---|---|---|---|
| Alinhamento com a nuvem | Frequentemente construído em torno de retorno central de tráfego | Melhor adequação à nuvem se bem concebido | Concebido em torno de políticas fornecidas na nuvem e consumo de serviços |
| Propriedade operacional | Forte dependência de fornecedores e contratos, além de complexidade nas filiais locais | Elevada responsabilidade interna pelo design, hardware e ciclo de vida | Maior responsabilidade recai sobre o prestador de serviços e o painel de gestão na cloud |
| Agilidade para novos locais | Geralmente mais lento e menos flexível | Mais flexível do que o MPLS, mas a qualidade da implementação depende da sua equipa e ferramentas | Excelente adequação para implementação padronizada de filiais em locais distribuídos |
| Modelo de segurança | Historicamente separado do transporte | Pode ser forte, mas frequentemente requer múltiplas integrações | Comumente construído com controlos de segurança integrados e política centralizada |
| Sobrecarga de hardware | Dependência significativa de filiais e da periferia (edge) | Ainda substancial em muitas implementações | Menor complexidade local em modelos cloud-native |
| Melhor adequação | Instalações estáveis com tráfego previsível e longos ciclos de planeamento | Equipas que pretendem controlo e podem assumir a sobrecarga operacional | Organizações que pretendem agilidade gerida, política centralizada e uma escala mais simplificada |
Onde o MPLS ainda tem o seu lugar
O MPLS ainda se adequa a alguns ambientes. Se uma empresa tem locais altamente estáveis, ciclos de planeamento longos, relações estritas com operadoras e um pequeno conjunto de aplicações previsíveis, ele pode continuar a ser útil.
O problema não é que o MPLS tenha deixado de funcionar. O problema é que muitas instalações de hotelaria e retalho mudaram à sua volta. Novos locais abrem mais rapidamente. Mais serviços são alojados na cloud. As expectativas dos clientes relativamente à qualidade do WiFi são mais elevadas. Os funcionários autenticam-se cada vez mais através de plataformas de identidade na cloud, e essas decisões de identidade necessitam que a rede da filial responda de forma rápida e consistente.
Onde o SD-WAN em modo "faça você mesmo" (DIY) ajuda, e onde complica
O SD-WAN DIY abordou uma lacuna real. Deu às equipas de rede seleção de caminhos, flexibilidade de transporte e melhor utilização de circuitos de banda larga e internet. Para organizações com forte engenharia interna, esse controlo ainda pode valer a pena.
Mas a contrapartida é o peso operacional. A sua equipa ainda tem de escolher fornecedores, manter o hardware de periferia, atualizar software, integrar firewalls e gateways web seguras, resolver exceções nas filiais e manter os padrões consistentes em todos os locais. Numa cadeia de retalho ou rede de hotéis, o número de filiais cresce geralmente mais rápido do que a equipa de rede.
Se está a avaliar se esse controlo extra compensa a sobrecarga de suporte, o guia da Purple sobre os benefícios do SD-WAN para empresas distribuídas é um ponto de referência útil.
O MPLS troca flexibilidade por previsibilidade. O SD-WAN feito por si (DIY) troca flexibilidade por esforço de engenharia. O WANaaS foi desenhado para organizações que pretendem uma política central e uma implementação mais rápida sem terem de possuir todas as partes da infraestrutura.
Escolher o modelo que a sua equipa consegue operar bem
A decisão principal prende-se menos com listas de funcionalidades e mais com o modelo operacional.
Uma equipa de engenharia de rede capaz pode preferir desenhar o seu próprio SD-WAN, a sua infraestrutura de segurança e as suas integrações na cloud. Isso pode funcionar bem se a empresa aceitar o fardo do ciclo de vida. Muitos grupos hoteleiros, retalhistas e operadores de recintos de uso misto pretendem um resultado diferente. Querem uma segmentação consistente, uma ativação de locais mais rápida e menos exceções específicas de filiais.
Isto assume ainda maior importância assim que o acesso WiFi é associado à identidade. Se o acesso de convidados utiliza OpenRoaming e o acesso do pessoal depende de credenciais emitidas pelo Entra ID ou Okta, a WAN não pode ser tratada como uma camada de tubagem isolada. A política tem de ser transportada da WAN para a periferia do recinto, para que o tráfego de convidados permaneça isolado, os dispositivos do pessoal herdem o acesso correto e os controlos de segurança na cloud vejam o contexto de utilizador e dispositivo de que necessitam. O WANaaS adequa-se melhor a esse modelo do que uma manta de retalhos de circuitos e equipamentos de filial, porque oferece uma forma mais limpa de aplicar políticas entre locais e, depois, estendê-las à experiência WiFi que os convidados e o pessoal utilizam.
Integrar a Segurança na Estrutura da Sua WAN
O antigo modelo de filial tratava a segurança como uma camada adicionada após a conectividade estar estabelecida. Essa abordagem cria desvios. Um local recebe uma política de firewall ligeiramente diferente. Outro atrasa a atualização de hardware. Um terceiro tem exceções que ninguém documenta devidamente. Com o tempo, a WAN torna-se ligada, mas não protegida de forma consistente.
O WANaaS moderno muda isso ao tornar a segurança parte da própria estrutura do serviço.
De acordo com o whitepaper sobre WAN as a Service da Cloudflare, o WANaaS moderno funciona como uma solução cloud-native que integra firewalls, mitigação de DDoS e protocolos zero-trust em todas as camadas, eliminando grande parte do fardo do ciclo de vida do hardware e proporcionando uma postura de segurança unificada a partir de um único painel de controlo.
Porque é que isto importa em ambientes multi-site
Um hotel, centro comercial ou complexo de saúde não precisa apenas de "internet segura". Precisa que diferentes tipos de tráfego sejam tratados de forma diferente.
O tráfego de convidados deve permanecer isolado dos sistemas operacionais. Os dispositivos do pessoal devem herdar políticas com base na identidade e na função. Os sistemas de pagamento, ferramentas de administração, IoT e serviços de inquilinos externos necessitam frequentemente das suas próprias vias. Se essa segmentação depender do trabalho artesanal de firewalls locais nas filiais, a consistência não irá durar.
O WANaaS melhora isto de duas formas:
- A política é centralizada para que cada espaço não se torne na sua própria ilha de segurança.
- Os serviços de segurança são integrados em vez de serem adicionados através de uma cadeia de produtos separados e transferências manuais.
Como é uma boa arquitetura de segurança
Na prática, uma segurança WANaaS forte inclui geralmente:
- Decisões de acesso baseadas na identidade para que os utilizadores e dispositivos não obtenham acesso amplo apenas por estarem na sub-rede correta.
- Segmentação de tráfego que mantém visitantes, funcionários, sistemas operacionais e inquilinos separados.
- Inspeção e monitorização centrais para que as equipas possam aplicar a política de forma uniforme e investigar problemas sem terem de iniciar sessão em cada filial individualmente.
Esta arquitetura é particularmente útil em espaços com uma mistura de utilizadores fidedignos e não fidedignos. Hotéis e centros comerciais são exemplos óbvios, mas residências de estudantes, clínicas e edifícios residenciais enfrentam o mesmo problema. Um único local físico pode conter várias zonas de confiança.
A filial não deve decidir a segurança apenas pela localização. Deve aplicar a política por identidade, função e tipo de tráfego.
O compromisso a ter em conta
Existe um compromisso. Quando move mais controlo para a plataforma cloud de um fornecedor, o seu modelo de visibilidade e resolução de problemas muda. A sua equipa precisa de compreender as ferramentas, registos e fluxo de trabalho de políticas do fornecedor. É uma troca justa se o plano de gestão for maduro e os seus processos se adaptarem a ele. É uma má troca se adquirir WANaaS e ainda insistir em gerir cada local como se fosse um antigo parque de firewalls de filial.
Ligar o WANaaS ao Acesso WiFi Baseado em Identidade
Um hóspede entra num hotel, liga-se ao WiFi através do OpenRoaming, abre uma aplicação de fidelização e espera que funcione imediatamente. Ao mesmo tempo, um funcionário da receção inicia sessão num dispositivo de trabalho utilizando um certificado associado ao Entra ID ou Okta. Se ambas as sessões terminarem na mesma rede local apenas com uma etiqueta VLAN a separá-las, a WAN tem muito pouco contexto. Vê tráfego. Não vê intenção.
Esta lacuna é importante em espaços distribuídos. Hotéis, superfícies comerciais, clínicas e propriedades de uso misto investem frequentemente em melhores políticas de WAN, mas depois deixam as decisões de acesso WiFi isoladas na filial. O resultado é familiar. Os visitantes obtêm um fluxo de integração decente, os funcionários obtêm um método de autenticação separado, e a equipa de TI central ainda tem de manter zonas de rede amplas porque a identidade se perde antes de o tráfego chegar ao motor de políticas de WAN.
O melhor design consiste em transportar a identidade desde o momento em que um dispositivo se junta ao WiFi para o modelo de políticas utilizado em toda a WAN e pilha de segurança na cloud. A Purple enquadra-se bem neste padrão porque suporta acesso de convidados sem palavra-passe através de OpenRoaming e Passpoint , além de acesso de funcionários baseado em certificados associado ao Entra ID, Okta e Google Workspace. A plataforma WiFi classifica o utilizador primeiro. O WANaaS utiliza depois essa classificação para aplicar o caminho, a inspeção e os controlos de acesso corretos.
Como estender a identidade à borda da WAN
Na prática, o fluxo de trabalho deve ser o seguinte:
Autenticar o utilizador no WiFi
- Os utilizadores convidados juntam-se através de OpenRoaming ou Passpoint.
- Os funcionários autenticam-se com um certificado ou método baseado em diretório associado ao Entra ID ou Okta.
Atribuir uma função na camada de acesso
- Convidado
- Funcionário
- Prestador de serviços
- Dispositivo IoT ou partilhado
Passar essa função para a política de rede
- Mapeie a função autenticada para uma VLAN, SGT, segmento VXLAN ou etiqueta de política equivalente, dependendo da sua pilha de WLAN e WANaaS.
- Mantenha o mapeamento consistente em todos os locais.
Aplicar a política de WANaaS por identidade, não apenas por SSID
- O tráfego de convidados vai para um breakout de internet local com filtragem web e política de largura de banda.
- O tráfego de funcionários vai para aplicações privadas, controlos de SaaS e pontos de inspeção definidos para acesso de colaboradores.
- Os dispositivos operacionais seguem uma rota separada com restrições este-oeste mais rigorosas.
Registar decisões de identidade e política centralmente
- O service desk deve ser capaz de responder a três perguntas rapidamente: Quem se ligou? Que função lhe foi atribuída? Que política de WAN é que isso ativou?
Este é o elo em falta em muitos projetos de WANaaS.
Um exemplo prático de política
Um convidado OpenRoaming não deve apenas aterrar em "WiFi de convidados." Essa etiqueta é demasiado vaga para as operações modernas. A sessão deve mapear para um objeto de política definido na estrutura da WAN, como:
- Origem de identidade: Autenticação Purple OpenRoaming
- Função: Convidado
- Segmento de rede: Apenas internet de convidados
- Política de WAN: Breakout local, filtragem de DNS, limite de largura de banda, bloqueio de acesso a gamas privadas RFC1918, sem movimento lateral para sistemas do local
- Registo: Início de sessão, local, classe de dispositivo, política aplicada
Um funcionário num tablet gerido deve seguir um caminho diferente:
- Origem de identidade: Autenticação baseada em certificados Entra ID ou Okta via Purple
- Função: Funcionários
- Segmento de rede: Acesso seguro de colaboradores
- Política de WAN: Encaminhar para aplicações de negócios, permitir SaaS aprovado, inspecionar tráfego de acordo com a política da empresa, bloquear o acesso a segmentos de convidados e IoT
- Registo: Identidade do utilizador, postura do dispositivo se disponível, eventos de acesso a aplicações, alterações de políticas
É assim que a segmentação ao nível da WAN chega ao limite do WiFi de uma forma utilizável. A WLAN decide quem é o utilizador. A plataforma WANaaS decide o que essa identidade tem permissão para fazer em vários locais, serviços cloud e saídas de internet.
O que as equipas de TI precisam de padronizar
A parte difícil raramente é a autenticação em si. A parte difícil é a consistência da política.
Se um hotel mapeia os funcionários para a VLAN 20, outro mapeia-os para a VLAN 40, e um terceiro depende de um objeto de firewall local que ninguém documentou, o fornecedor de WANaaS não consegue impor um modelo limpo baseado em identidade em toda a propriedade. As definições de funções padrão importam mais do que a uniformidade perfeita de circuitos. Uma cadeia de retalho com 300 lojas é geralmente mais bem servida por quatro ou cinco classes de identidade bem geridas do que por dezenas de exceções específicas do local.
As equipas que avaliam a arquitetura de filiais chegam frequentemente a este ponto ao comparar a política de SD-WAN local com controlos de WAN geridos na cloud. Estes casos de uso de SD-WAN para locais distribuídos são uma referência útil para a forma como a política de aplicações e acessos se comporta ao nível do local.
O trade-off a planear
A imposição baseada em identidade melhora o controlo, mas também eleva a fasquia de qualidade para a integração. A WLAN, o fornecedor de identidade, o NAC ou motor de políticas, e a WANaaS devem concordar com os nomes das funções, etiquetas de políticas e gestão de falhas. Se o Entra ID estiver indisponível, o que acontece à integração de funcionários? Se o OpenRoaming for bem-sucedido mas a etiqueta de política falhar na sincronização, o utilizador cai numa política de retenção restrita ou ganha acesso amplo à internet por engano?
Bons designs respondem a essas perguntas desde o início. Definem uma política de contingência, mantêm o mapeamento de funções simples e testam a integração sob a perspetiva do utilizador, e não apenas a partir da consola de administração.
Se a Purple identificar o utilizador e a plataforma WANaaS não conseguir consumir essa identidade de forma consistente, terá uma melhor integração de WiFi, mas não um melhor controlo de rede.
É por isso que o acesso WiFi baseado em identidade deve ser concebido como parte da arquitetura WAN, e não anexado mais tarde como uma funcionalidade de filial.
WANaaS em Ação nos seus Locais
A arquitetura importa devido ao que corrige no terreno. Setores diferentes deparam-se com problemas diferentes, mas o padrão é consistente. Os locais distribuídos precisam de controlo central sem uniformizar todos os requisitos locais.
Hotelaria
Um grupo hoteleiro procura frequentemente três coisas ao mesmo tempo. Um registo simples para os hóspedes, acesso seguro para os funcionários e um desempenho consistente das aplicações em todas as propriedades.
Com a WANaaS, o grupo pode aplicar um modelo único de encaminhamento e segmentação em todos os hotéis, adaptando-se simultaneamente à disponibilidade de circuitos locais. O tráfego dos hóspedes é distribuído de forma limpa, o tráfego dos funcionários acede aos sistemas empresariais em segurança e a equipa central de TI não precisa de ajustar cada local separadamente. Se está a avaliar onde os padrões de SD-WAN e de WAN gerida na nuvem se enquadram operacionalmente, estes casos de uso de SD-WAN para locais distribuídos fornecem um contexto útil.
Retalho
As lojas de retalho penalizam rapidamente as redes fracas. O tráfego de pagamentos não pode esperar que a navegação dos hóspedes abrande. A sinalética digital, as aplicações de fidelização, os dispositivos portáteis e as ferramentas de inventário na nuvem precisam todos de um tratamento previsível.
O que funciona aqui é uma política sensível às aplicações combinada com uma segmentação rigorosa. A WANaaS pode dar prioridade ao tráfego crítico para o negócio, mantendo ao mesmo tempo uma experiência de utilizador utilizável para os hóspedes. O que não funciona é dar a cada loja um acesso geral à Internet e esperar que os equipamentos locais mantenham tudo em ordem.
Cuidados de Saúde
As clínicas e os centros de consulta externa precisam de mais do que simples acesso à Internet. Precisam de um acesso fiável às aplicações principais, de uma separação clara para o tráfego clínico e não clínico, e de uma supervisão operacional mais simples.
Um modelo WANaaS ajuda quando as instalações de saúde estão dispersas por muitos locais mais pequenos com presença local de TI limitada. As equipas centrais podem padronizar políticas, reduzir a complexidade das filiais e evitar transformar cada clínica num projeto isolado.
Residencial e multi-inquilino
O arrendamento habitacional, as residências de estudantes e as propriedades de uso misto são complexos para o pensamento tradicional de filial, porque um único edifício pode comportar-se como muitas redes separadas. Os residentes querem uma experiência semelhante à de casa. Os funcionários precisam de acesso gerido. Os sistemas partilhados e os dispositivos antigos ainda precisam de controlo.
Um bom design de WANaaS suporta o isolamento por inquilino, limites de acesso claros e administração centralizada. A lição importante é que estes ambientes não são "apenas projetos de WiFi". Eles precisam que a WAN, a identidade e a segmentação funcionem em conjunto.
As redes de locais mais fortes não se limitam a ligar espaços. Elas mantêm um modelo de confiança consistente de propriedade para propriedade.
Planear a sua Migração para WANaaS
As melhores migrações para WANaaS começam com os pontos de fricção do negócio, não com demonstrações de produtos. Se começar com a lista de funcionalidades do fornecedor, perderá as questões operacionais que realmente importam para o seu património.
Comece com a infraestrutura que já possui
Audite os locais por criticidade de negócio, tipo de utilizador, método de acesso e carga de suporte. Um hotel de referência, uma pequena filial de retalho e uma clínica de saúde podem estar todos na mesma WAN hoje em dia, mas não terão a mesma tolerância a falhas, latência ou erros de política.
Mapeie o que realmente está a acontecer em cada local:
- Comportamento de tráfego em acessos de convidados, funcionários, operacionais e de terceiros
- Caminhos de autenticação para utilizadores, dispositivos e equipamentos legados
- Dependências de sucursais, tais como firewalls locais, VPNs ou interfaces geridas por fornecedores
Defina o sucesso em termos operacionais
Mantenha o objetivo prático. Os melhores planos de migração geralmente definem o sucesso como menos exceções locais, integração mais simples para novos locais, segmentação mais forte e isolamento de falhas mais rápido.
Faça perguntas diretas. Pode uma nova propriedade herdar o design de rede padrão sem um projeto personalizado? Podem as alterações de identidade dos funcionários refletir-se de forma limpa na política de acesso? Podem os tráfegos de convidados e operacional permanecer isolados sem a proliferação de regras locais?
Escolha o modelo de serviço com cuidado
Os fornecedores de WANaaS variam muito. Alguns são fortes na flexibilidade de transporte, mas fracos na integração de identidade. Outros possuem estruturas de segurança sólidas, mas ferramentas operacionais complexas.
Antes de se comprometer, verifique:
- Modelo de política. Consegue expressar as zonas de confiança e os tipos de utilizadores que gere?
- Visibilidade. A sua equipa terá acesso a dados úteis de monitorização e resolução de problemas?
- Integração. Consegue alinhar-se perfeitamente com a sua WLAN, fornecedores de identidade e aplicações na nuvem?
- Método de implementação. O fornecedor suporta uma adoção faseada sem forçar uma transição de alto risco?
Um pequeno projeto-piloto em alguns locais representativos costuma revelar mais do que um workshop de vendas bem preparado. Escolha locais com diferentes tipos de circuitos, diferentes perfis de utilizadores e pelo menos uma dependência de legado complexa. Se o modelo funcionar aí, terá boas hipóteses de escalar com sucesso.
Se está a analisar como o WiFi de convidados, a identidade dos funcionários e as políticas de WAN devem articular-se em hotéis, lojas de retalho, unidades de saúde ou propriedades multi-inquilino, a Purple é um bom ponto de partida. Foca-se no acesso sem palavra-passe para convidados, conectividade baseada na identidade para funcionários e controlo de políticas centralizado, o que a torna relevante quando tenta ligar decisões de acesso WiFi a um design mais amplo de WANaaS e de zero-trust.
