Migração de múltiplos locais de RADIUS: sequenciamento de locais, pontos de acesso e política

Você pode migrar uma estrutura multi-site para o cloud RADIUS em quatro fases sem um dia de virada total, mantendo os servidores antigos e novos funcionando lado a lado. Cada SSID lista ambos, e cada dispositivo confia no novo certificado do servidor. A transição de cada site ocorre sob o IEEE 802.1X com um teste de saída por escrito. Na Purple, a virada em si geralmente é uma tarefa realizada no fim de semana.

O que muda em uma migração RADIUS multi-site e o que permanece igual?

O estado final é uma política única de cloud RADIUS atendendo a todos os sites, com a identidade definindo a VLAN. O RADIUS, definido na RFC 2865, é o protocolo que seus pontos de acesso usam para perguntar a um servidor se um dispositivo pode se conectar. O servidor aceita ou rejeita o dispositivo. Ele também pode retornar atributos como a VLAN, o segmento de rede onde o dispositivo é alocado.

Em uma rede segura, essa troca ocorre dentro do IEEE 802.1X, o padrão para controle de acesso à rede baseado em porta. O 802.1X transporta o EAP (Extensible Authentication Protocol) entre o dispositivo, o ponto de acesso e o servidor. O EAP-TLS, definido na RFC 5216, autentica ambos os lados com certificados. O PEAP envolve uma troca de senha dentro de um túnel TLS.

Quatro coisas mudam:

• Cada ponto de acesso ou controlador aponta para um novo endereço de servidor e segredo compartilhado. O RADIUS chama esse dispositivo de NAS (network access server).
• Os dispositivos veem um novo certificado de servidor durante o handshake EAP.
• A política lê grupos do Microsoft Entra ID, Okta ou Google Workspace em vez de um diretório local.
• Os logs são transferidos para um novo console.

As coisas que permanecem iguais são ainda mais importantes. Você mantém seus pontos de acesso, nomes de SSID, IDs de VLAN, trunks de switch e zonas de firewall. Ninguém precisa alterar uma senha ou se conectar a uma nova rede.

A mesma abordagem se aplica a todas as três redes no Purple Access. Em redes abertas, muitos Captive Portals autorizam dispositivos por meio do RADIUS. Redes seguras usam EAP-TLS ou PEAP. Em redes xPSK, o RADIUS fornece a cada dispositivo ou morador sua própria chave pré-compartilhada. Este guia foca na rede segura, pois é a que apresenta maior risco.

{"tone":"warning","title":"O risco que preocupa: confiança no certificado do servidor","text":"Dispositivos com EAP-TLS ou PEAP verificam o certificado do servidor RADIUS, e muitos confiam apenas na autoridade certificadora do servidor antigo. Envie a nova CA para todos os perfis de dispositivos antes que o primeiro site seja migrado, caso contrário, esses dispositivos não conseguirão se conectar e tentarão novamente continuamente."}

Depois de resolver a confiança no certificado, o restante da migração se resume a trabalho de configuração e períodos de espera.

O que precisa estar correto antes da fase 1?

Cinco condições devem estar atendidas antes que qualquer política seja criada. Se uma estiver ausente, causará problemas em uma fase posterior.

Um inventário completo de NAS

Liste todos os dispositivos que enviam solicitações para o servidor antigo. Isso inclui pontos de acesso, controladores sem fio, switches que realizam 802.1X cabeado e gateways de VPN. Monte a lista a partir da lista de clientes RADIUS do servidor antigo, e não a partir do diagrama de rede. Se um NAS estiver ausente do inventário, você não poderá desligar o servidor antigo na fase 4.

Um mapa de políticas, linha por linha

Escreva cada regra que o servidor antigo aplica, com sua condição, seu resultado e os atributos que ele retorna. As linhas típicas se parecem com isto: grupo de funcionários para a VLAN de funcionários, prestadores de serviços para uma VLAN restrita, laptops corporativos por certificado para a VLAN corporativa. Observe quais atributos transportam a VLAN. A RFC 3580 define o conjunto padrão: Tunnel-Type, Tunnel-Medium-Type e Tunnel-Private-Group-ID. Algumas infraestruturas usam atributos específicos do fornecedor em vez disso, e você deve espelhá-los exatamente.

Um plano de certificados

Decida qual autoridade certificadora (CA) emite o novo certificado do servidor. Em dispositivos gerenciados, envie essa CA por meio do Microsoft Intune, Jamf ou sua plataforma de gerenciamento de dispositivos móveis (MDM) antes que qualquer local seja migrado. Para EAP-TLS, o novo servidor também deve confiar na CA que emitiu os certificados do seu dispositivo.

Uma fonte de identidade que o novo servidor possa ler

Conecte seu provedor de identidade e confirme se todos os grupos no mapa de políticas existem lá. Se um grupo existir apenas no servidor antigo, recrie-o primeiro no provedor de identidade.

Alcance, responsáveis e janelas de mudança

Cada local precisa de um caminho de rede para o servidor em nuvem, usando os endereços e portas na documentação de integração do Purple. Nomeie um responsável para cada local e combine janelas de mudança com os gerentes dos locais. Escreva o gatilho de reversão (rollback) antes que qualquer coisa seja migrada.

{"title":"Checklist de migração RADIUS multi-site","groups":[{"heading":"Antes da fase 1","items":[{"text":"Exporte a lista de clientes RADIUS do servidor antigo e concilie com o inventário NAS","why":"Um NAS esquecido bloqueia a desativação"},{"text":"Mapeie cada regra de política: condição, resultado e atributos retornados"},{"text":"Confirme se cada grupo de políticas existe no Microsoft Entra ID, Okta ou Google Workspace"},{"text":"Envie a CA do novo servidor para os dispositivos gerenciados por meio do seu MDM"},{"text":"Abra os caminhos na documentação de integração da Purple em cada site"},{"text":"Defina um responsável e uma janela de mudança por site e acorde o gatilho de rollback por escrito"}]},{"heading":"Fase 1: construção","items":[{"text":"Congele as alterações de política no servidor antigo"},{"text":"Recrie cada linha de política no novo servidor"},{"text":"Teste uma identidade por linha em ambos os servidores e compare as respostas"}]},{"heading":"Fases 2 e 3: piloto e ondas","items":[{"text":"Registre uma taxa de rejeição de referência por site antes da migração"},{"text":"Adicione o novo servidor ao lado do antigo em cada SSID"},{"text":"Confirme se cada classe de dispositivo se autentica no novo servidor"},{"text":"Mantenha cada onda por um ciclo de negócios completo antes da próxima"}]},{"heading":"Fase 4: desativação","items":[{"text":"Remova o servidor antigo de todos os SSIDs e NAS"},{"text":"Confirme zero solicitações no servidor antigo pelo período de inatividade acordado"},{"text":"Exporte e retenha os logs do servidor antigo de acordo com sua política de retenção"},{"text":"Aposente os segredos compartilhados usados com o servidor antigo"},{"text":"Atualize o runbook e arquive o registro de teste de saída de cada site"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

Quais são as 4 fases, em ordem?

O plano possui quatro fases. Cada uma termina com um teste de saída no qual você pode ser aprovado ou reprovado. Nada avança para a próxima fase até que o teste seja aprovado, evitando assim uma migração abrupta e arriscada.

{"kind":"timeline","direction":"lr","caption":"Uma propriedade ilustrativa de 40 locais: quatro fases, cada uma concluída por um teste de saída","alt":"Cronograma mostrando a preparação, depois a fase 1 de construção, a fase 2 de piloto, a fase 3 de ondas e a fase 4 de desativação ao longo de aproximadamente 12 semanas.","nodes":[{"id":"p0","label":"Antes da fase 1","sub":"Inventário, mapa de políticas, push de CA, fonte de identidade","tone":"neutral","when":"Semanas 1-2"},{"id":"p1","label":"Fase 1: construção e espelhamento","sub":"Política recriada no RADIUS em nuvem, respostas de laboratório idênticas","tone":"brand","when":"Semana 3"},{"id":"p2","label":"Fase 2: local piloto","sub":"Um local, servidor antigo mantido como secundário","tone":"brand","when":"Semanas 4-5"},{"id":"p3","label":"Fase 3: ondas","sub":"Cinco, depois 10, depois os 24 locais restantes","tone":"brand","when":"Semanas 6-10"},{"id":"p4","label":"Fase 4: desativação","sub":"Zero solicitações no servidor antigo, depois desligamento","tone":"success","when":"Semanas 11-12"}],"edges":[{"from":"p0","to":"p1","label":"pré-requisitos atendidos"},{"from":"p1","to":"p2","label":"respostas de laboratório idênticas"},{"from":"p2","to":"p3","label":"teste de saída do piloto"},{"from":"p3","to":"p4","label":"transição de todos os locais efetuada"}]}

{"caption":"Plano de fases para uma migração RADIUS de múltiplos locais","asOf":"2026-06-10","columns":[{"key":"phase","label":"Fase"},{"key":"scope","label":"Escopo"},{"key":"owner","label":"Responsável"},{"key":"exit","label":"Teste de saída"}],"rows":[["Antes da fase 1","Inventário de NAS, mapa de políticas, push de CA, fonte de identidade, caminhos de locais","Gerente de TI com líder de identidade e acesso","Cada NAS listado, cada grupo de políticas no provedor de identidade, nova CA em dispositivos gerenciados"],["Fase 1: construção","Política recriada no RADIUS em nuvem, sem tráfego em tempo real","Líder de identidade e acesso","Uma identidade de teste por linha recebe a mesma resposta e VLAN no servidor antigo e no novo"],["Fase 2: piloto","Um local representativo, novo servidor primário, antigo secundário","Arquiteto de rede","Um ciclo de negócios sem rejeições não explicadas e cada classe de dispositivo vista no novo servidor"],["Fase 3: ondas","Locais restantes em ondas crescentes, agrupados por modelo de console","Arquiteto de rede com responsáveis pelos locais","Cada onda passa pelo teste de saída do piloto antes do início da próxima"],["Fase 4: desativação","Servidor antigo removido de cada SSID e NAS","Gerente de TI","Zero solicitações no servidor antigo durante o período de inatividade, logs mantidos, credenciais desativadas"]],"footnote":"Os responsáveis são funções, não pessoas específicas. Defina o período de inatividade para pelo menos um ciclo de reautenticação mais uma semana útil.","download":{"filename":"radius-migration-phase-plan.csv"}}

O que acontece dentro de cada fase?

Fase 1: construção e espelhamento da política

Recrie o mapa de políticas no novo servidor antes que qualquer solicitação em tempo real chegue a ele. Conecte o provedor de identidade e, em seguida, recrie cada linha com sua condição, resultado e atributos retornados. Mantenha os IDs de VLAN idênticos, para que a configuração do switch e do firewall nunca mude.

Teste cada linha a partir de um laboratório. Use o eapol_test, uma ferramenta do projeto wpa_supplicant. Ele envia uma troca EAP real para um servidor RADIUS e exibe a resposta. Execute uma identidade por linha em ambos os servidores e compare as respostas. O teste de conclusão é uma correspondência em todas as linhas, com a mesma aceitação ou rejeição e o mesmo VLAN.

Fase 2: projeto piloto em um local

Escolha um local que represente toda a rede, e não o mais fácil. Ele deve ter todas as classes de dispositivos que você utiliza, incluindo as mais difíceis. Pense em scanners portáteis, terminais de pagamento em WiFi e notebooks mais antigos. Você também precisa de alguém no local que possa testar um dispositivo quando solicitado.

Adicione o novo servidor ao lado do antigo, teste-o e torne o novo servidor o principal. Deixe-o funcionando por um ciclo de negócios completo. Para um hotel, isso significa uma semana de turnos. Para um escritório, significa uma semana de logins na manhã de segunda-feira. O piloto é aprovado quando duas condições são verdadeiras: primeiro, cada classe de dispositivo se autenticou no novo servidor; segundo, a taxa de rejeição não é pior do que a sua linha de base.

Fase 3: migrar a rede em ondas

Faça com que cada onda seja maior que a anterior conforme as primeiras forem aprovadas. Uma rede de 40 locais pode migrar um local piloto, depois cinco, depois 10 e, em seguida, os 24 restantes. Agrupe cada onda por modelo de console ou grupo, para que uma única alteração alcance todos os locais contidos nela. Modelos de configuração do Meraki, modelos de WLAN do Juniper Mist e grupos do HPE Aruba Central são ideais para essa abordagem.

Faça a transição enquanto a equipe do local estiver presente, e não às 3h da manhã. Uma alteração que ninguém testa até a manhã seguinte é uma alteração que você não testou. Evite agrupar outras alterações de rede na mesma janela.

Fase 4: desativar o servidor antigo

Remova o servidor antigo de cada SSID e de cada NAS no inventário e, em seguida, monitore seus logs. As solicitações devem cair para zero. Qualquer coisa que ainda chegar virá de um NAS que você esqueceu. Mantenha o período de inatividade por pelo menos um ciclo de reautenticação mais uma semana útil. Em seguida, exporte os logs de acordo com sua política de retenção, desligue o servidor e aposente seus segredos compartilhados.

Cenário prático: um grupo de 40 hotéis usando Cisco Meraki

Considere um grupo de 40 hotéis executando WiFi para colaboradores em WiFi no Cisco Meraki. Ele usa PEAP em um servidor RADIUS local na matriz. Cada solicitação cruza a WAN até um único edifício, portanto, uma interrupção na matriz desativa o WiFi para colaboradores em WiFi em todos os hotéis.

O grupo envia a nova CA por meio de seu MDM na primeira semana. Ele recria cinco linhas de política no RADIUS em nuvem em comparação ao Microsoft Entra ID e, em seguida, realiza um piloto em um hotel urbano de 120 quartos. Seguem-se ondas de cinco, 10 e 24 hotéis, cada uma correspondendo a um modelo de configuração do Meraki. Um hotel faz rollback por uma tarde porque um tablet do serviço de governança confia apenas na CA antiga. Ele é migrado novamente uma semana depois.

O resultado:

• Todos os 40 hotéis migram em seis janelas de alteração.
• Um local faz rollback uma única vez.
• A matriz não está mais no caminho de autenticação.

Como os servidores RADIUS antigo e novo executam lado a lado?

A execução em paralelo depende de como os pontos de acesso fazem o failover. Um NAS envia cada solicitação para o primeiro servidor da sua lista. Ele tenta o próximo servidor apenas quando o primeiro não responde dentro do tempo limite (timeout).

Um Access-Reject conta como uma resposta, não como uma falha, portanto o NAS não tentará a solicitação novamente em outro lugar. Isso tem duas consequências:

• Ambos os servidores devem fornecer a mesma resposta. Se eles diferirem, a experiência do dispositivo dependerá de qual servidor respondeu.
• A execução em paralelo é uma rede de segurança, não um teste. Teste a política na fase 1 e no piloto. Não a teste esperando para ver o que o failover faz.

Verifique os tempos limite antes que o primeiro local seja migrado. Um servidor em nuvem está mais distante do que um servidor na sua sala de comunicações. Compare as configurações de tempo limite e de nova tentativa do NAS de cada local com o tempo de ida e volta (RTT). Se as configurações forem muito rígidas, as solicitações farão o failover para o servidor antigo sem nenhum motivo real, o que oculta problemas. Migre a contabilidade RADIUS para o novo servidor no mesmo momento da autenticação, para que os registros de sessão fiquem em um só lugar.

A transição em cada local é simplesmente inverter a ordem dos dois servidores. Estas etapas se aplicam a todos os locais, com as diferenças de fornecedores mostradas na etapa 2.

{"title":"Migre um local sem a necessidade de uma data de corte global","steps":[{"title":"Confirme se o local está pronto","body":"Verifique o local em relação à lista de verificação de migração: NAS listado, nova CA nos dispositivos gerenciados, caminho para a Purple aberto, responsável no local.","check":"Todos os pré-requisitos para o local estão marcados."},{"title":"Adicione o novo servidor ao lado do antigo","body":"Adicione o RADIUS em nuvem da Purple à lista de servidores RADIUS do SSID, usando o segredo compartilhado fornecido pela Purple para o local. Deixe o servidor antigo em primeiro lugar por enquanto.","check":"O console mostra ambos os servidores para o SSID.","variants":[{"label":"Meraki","body":"No Meraki Dashboard, adicione o servidor nas configurações de controle de acesso do SSID, de preferência no modelo de configuração."},{"label":"Aruba","body":"No HPE Aruba Central, adicione o servidor ao grupo de servidores de autenticação utilizado pela WLAN."},{"label":"Ruckus","body":"Adicione o servidor ao perfil de servidor AAA utilizado pela WLAN, como servidor secundário."},{"label":"Mist","body":"No portal Juniper Mist, adicione o servidor aos servidores de autenticação RADIUS da WLAN, de preferência no modelo de WLAN."},{"label":"UniFi","body":"No aplicativo UniFi Network, adicione o servidor ao perfil RADIUS atribuído à rede WiFi."}]},{"title":"Teste antes de alternar","body":"A partir de um host de teste registrado como cliente RADIUS, envie uma identidade por linha de política para o novo servidor.","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"Cada identidade recebe Access-Accept ou Access-Reject conforme indicado no mapa de políticas, com a VLAN esperada."},{"title":"Alterne a ordem","body":"Torne o novo servidor o principal e mantenha o servidor antigo como secundário. Esta é a migração efetiva.","check":"Os logs do novo servidor mostram solicitações de todos os pontos de acesso no local."},{"title":"Aguarde por um ciclo operacional","body":"Compare a taxa de rejeição com a sua linha de base e confirme que todas as classes de dispositivos foram autenticadas.","check":"Nenhuma rejeição não explicada e o local passa em seu teste de saída."}]}

Como reverter um local ou uma onda?

A reversão é o processo inverso da migração efetiva: você coloca o servidor antigo em primeiro lugar novamente. Em cada console mencionado acima, isso representa uma única alteração de configuração. Isso só funciona se o servidor antigo ainda estiver em execução, inalterado e com seus segredos compartilhados intactos. É por isso que a desativação vem por último. Também é por isso que você congela as políticas no servidor antigo no início da fase 1.

Combine os gatilhos antes de começar. Os gatilhos típicos são:

• Uma classe de dispositivos que não consegue se conectar e não possui uma solução no mesmo dia.
• Atribuições de VLAN que diferem do mapa de políticas.
• Uma taxa de rejeição acima da linha de base que você não consegue explicar dentro da janela de alteração.

{"title":"Avançar, pausar ou reverter uma onda","start":"q1","nodes":[{"id":"q1","question":"Alguma classe de dispositivo está falhando no novo servidor que passava no antigo?","help":"Compare as rejeições por tipo de dispositivo com a linha de base gravada antes da migração.","options":[{"label":"Sim","to":"q2"},{"label":"Não","to":"q3"}]},{"id":"q2","question":"A falha está restrita a uma classe de dispositivo com uma correção conhecida?","help":"Uma CA ausente em um perfil é uma correção conhecida. Rejeições em várias classes não são.","options":[{"label":"Sim","to":"o2"},{"label":"Não","to":"o3"}]},{"id":"q3","question":"Cada identidade de teste entra na VLAN esperada em cada local da onda?","options":[{"label":"Sim","to":"q4"},{"label":"Não","to":"o3"}]},{"id":"q4","question":"A onda executou um ciclo de negócios completo sem rejeições não explicadas?","options":[{"label":"Sim","to":"o1"},{"label":"Não","to":"o2"}]},{"id":"o1","outcome":"Avançar: iniciar a próxima onda","detail":"Registre o resultado do teste de saída por local e agende a próxima onda.","link":"[Uma política em todos os locais](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"Pausar: corrigir e testar novamente","detail":"Coloque o servidor antigo em primeiro lugar apenas no SSID afetado, corrija o perfil ou regra e execute novamente o teste de saída."},{"id":"o3","outcome":"Reverter a onda","detail":"Coloque o servidor antigo em primeiro lugar em todos os SSIDs da onda, capture logs de ambos os servidores e encontre a causa antes de tentar novamente.","link":"[Quando o RADIUS está inacessível](guide:radius-server-down-wifi)"}]}

Após qualquer reversão, exporte os logs de ambos os servidores para a janela com falha. Encontre a causa e corrija-a na nova política. Em seguida, execute novamente o teste de laboratório da fase 1 para a linha afetada antes que o local seja movido novamente.

Como você sabe que a migração foi concluída?

A migração é concluída quando as evidências confirmarem, não quando o último local for movido. Cinco testes a encerram:

1. O servidor antigo registrou zero solicitações durante o período de inatividade acordado.
2. Cada NAS no inventário aparece nos logs do novo servidor.
3. Um dispositivo real testou cada linha de política e entrou na VLAN esperada.
4. A taxa de rejeição está igual ou abaixo da linha de base registrada antes da fase 2.
5. O servidor antigo está desligado, seus logs são retidos, seus segredos são desativados e o runbook é atualizado.

Mantenha um registro de uma página para cada local, com a data, o resultado do teste de saída e qualquer reversão. Juntos aos novos logs de autenticação, esses registros são suas evidências para os controles de registro do PCI-DSS e controle de acesso da ISO 27001. Eles também servem como evidência de controle de alterações para o próximo ciclo de auditoria.

Modos de falha vistos em campo

Dispositivos que confiam apenas no certificado antigo

Esta é a falha mais comum. Dispositivos PEAP não gerenciados podem solicitar o novo certificado ou recusá-lo sumariamente. Alguns perfis gerenciados fixam o nome do servidor, bem como a CA. Verifique ambos antes do piloto.

Um NAS que ninguém listou

Controladores esquecidos, switches 802.1X cabeados e gateways VPN mantêm o servidor antigo ocupado muito tempo depois que o WiFi foi migrado. O período de silêncio na fase 4 é como você os identifica.

Políticas que residiam no servidor antigo

Grupos locais, listas de MACs codificadas no código e regras de horário do dia muitas vezes existem apenas no servidor antigo. Se eles não estiverem no mapa de políticas, desaparecerão no momento da transição.

Incompatibilidades de segredo compartilhado e atributos

Um segredo digitado incorretamente falha silenciosamente em alguns consoles. Uma VLAN retornada pelo nome em vez do ID pode colocar os dispositivos na VLAN padrão. Ambos devem aparecer nos testes da fase 1, e você deve verificar novamente durante o piloto.

Timeouts ajustados para um servidor local

Timeouts curtos em um NAS causam failover falso para o servidor antigo. Tudo parece funcionar até que o servidor antigo seja removido.

Cenário prático: um varejista de 120 lojas em dois consoles

Considere um varejista de 120 lojas com lojas mais antigas em HPE Aruba e mais novas em Juniper Mist. Dispositivos portáteis e laptops das lojas usam EAP-TLS contra um par de servidores RADIUS locais. O piloto e as ondas ocorrem sem problemas, agrupados por grupo do Aruba Central e modelo WLAN do Mist.

Na fase 4, os servidores antigos continuam registrando solicitações de três endereços após a migração de todos os SSIDs. Dois são controladores de centro de distribuição fora do parque de lojas. O terceiro é um gateway VPN para laptops da sede. A equipe adiciona todos os três ao inventário, transfere-os em uma janela adicional e reinicia o período de silêncio. A desativação é concluída com dois meses de atraso, sem qualquer interrupção em nenhuma loja.

Onde a Purple se encaixa

O Purple Access executa redes abertas, seguras e xPSK em uma única plataforma, usando os pontos de acesso que você já possui. A rede segura conduz essa migração. Ela oferece RADIUS na nuvem, EAP-TLS e identidade a partir do Microsoft Entra ID, Okta ou Google Workspace. Ela também suporta Passpoint, também chamado de Hotspot 2.0, que permite que os dispositivos entrem em uma rede segura automaticamente com uma credencial. A Purple é independente de hardware, portanto uma única política atende a locais nestas plataformas:

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme
• Fortinet

Isso significa que um parque misto pode ser migrado com um único plano.

A Purple opera o maior RADIUS na nuvem do mundo. Ela vem com um SLA de tempo de atividade do RADIUS de 99,9%, em uma plataforma que opera com 99,999% de tempo de atividade. Como o lado da Purple é construído antes do início da fase 2, a transição de cada local costuma ser um trabalho de fim de semana. O faturamento em fases existe para gerenciar o risco no seu parque de dispositivos, não na nossa plataforma.

{"items":[{"value":"80,000+","label":"locais ativos","note":"Dados da própria Purple"},{"value":"90","label":"países"},{"value":"99.9%","label":"SLA de tempo de atividade do RADIUS","note":"Em uma plataforma que opera a 99,999%"}]}

{"tone":"proof","title":"WiFi para funcionários em escala de filiais","text":"O JPMorgan opera o WiFi para funcionários na Purple em 5.000 filiais."}

Consulte RADIUS em nuvem no Purple Access para obter detalhes do produto e o guia de segurança do WiFi empresarial para o conjunto mais amplo de controles. O marketing de visitantes está no Engage e a filtragem de DNS está no Shield. Nenhum dos dois muda durante uma migração de RADIUS.

Perguntas frequentes

Quanto tempo leva uma migração de RADIUS em vários locais?

Planeje algumas semanas para toda a infraestrutura e um fim de semana por local. No Purple, a transição de cada local é geralmente um trabalho de fim de semana. A infraestrutura completa leva mais tempo porque cada etapa aguarda um ciclo de negócios antes que a próxima comece. Uma infraestrutura ilustrativa de 40 locais leva cerca de 12 semanas, do inventário ao desissionamento. A maior parte desse tempo é gasta em preparação e períodos de espera, não no trabalho de alteração.

Preciso de novos pontos de acesso para mudar para o RADIUS em nuvem?

Não. O RADIUS em nuvem altera o servidor que seus pontos de acesso consultam, não os pontos de acesso em si. O Purple funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Você adiciona o novo servidor à lista de servidores RADIUS de cada SSID no console que você já usa. Seus SSIDs, IDs de VLAN e configuração de switch permanecem como estão.

Como devo modelar o custo do RADIUS em nuvem em vários locais?

Modele com base em dois números: locais e identidades. Conte cada local que autentica e cada identidade que se conecta, incluindo dispositivos no EAP-TLS. Em seguida, compare isso com o custo total do servidor antigo: hardware, licenças, aplicação de patches, alta disponibilidade e o caminho WAN para a matriz. Nosso guia para modelar o custo de RADIUS em nuvem por local detalha o cálculo.

Posso manter o servidor RADIUS antigo como substituto após a mudança?

Mantenha-o durante a execução em paralelo e, em seguida, desative-o. Enquanto estiver listado como secundário, ele cobre tempos limite em locais que ainda estão nas etapas de migração. Após a fase 4, um servidor mantendo uma cópia congelada da política antiga torna-se um risco, pois qualquer resposta fornecida usará regras desatualizadas. A partir de então, a resiliência vem do SLA de 99,9% de tempo de atividade do RADIUS e de um plano de recuperação contra interrupções.

Os funcionários terão que cadastrar novamente seus dispositivos?

Não se o novo certificado do servidor for confiável antes da transição. Envie a nova AC para dispositivos gerenciados por meio do seu MDM durante a fase de compilação. Os dispositivos EAP-TLS mantêm seus certificados de cliente existentes, desde que o novo servidor confie na AC que os emitiu. Os dispositivos PEAP não gerenciados são a exceção, pois alguns solicitam uma confirmação para aceitar o novo certificado. Envie a esses funcionários um aviso curto antes que o local deles seja migrado.

A migração afeta nossas evidências de ISO 27001 ou PCI DSS?

Isso altera de onde vêm suas evidências, portanto, planeje isso desde o início. Logs de autenticação, definições de políticas e registros de alterações passam para a nova plataforma. Retenha os logs do servidor antigo sob sua política de retenção e arquive o registro de teste de saída de cada site. A Purple possui certificação ISO 27001, o que fornece aos seus auditores evidências do lado da plataforma. Seus próprios controles ainda precisam de suas próprias evidências.

Como isso difere para um MSP que gerencia vários ambientes?

As fases são as mesmas. O que difere é o isolamento entre os ambientes. Um MSP executa as mesmas quatro fases para cada ambiente, mas cada um precisa de sua própria política, fonte de identidade e logs em uma plataforma compartilhada. As ondas geralmente seguem limites contratuais em vez de modelos de console. Nosso guia sobre RADIUS multi-tenant para MSPs aborda como manter cada ambiente separado durante e após a mudança.