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

Pode migrar uma propriedade multi-site para cloud RADIUS em quatro fases, sem a necessidade de um dia de transição abrupta quando os servidores antigos e novos funcionam lado a lado. Cada SSID lista ambos, e todos os dispositivos confiam no novo certificado do servidor. Cada site faz a transição sob 802.1X com um teste de saída por escrito. No Purple, a transição em si é geralmente um exercício de fim de semana.

O que muda numa migração RADIUS multi-site e o que se mantém?

O estado final é uma política de cloud RADIUS a servir todos os sites, com a identidade a definir a VLAN. O RADIUS, definido na RFC 2865, é o protocolo que os seus pontos de acesso utilizam para perguntar a um servidor se um dispositivo pode aderir. O servidor aceita ou rejeita o dispositivo. Também pode retornar atributos como a VLAN, o segmento de rede onde o dispositivo é colocado.

Numa rede segura, essa troca ocorre dentro do 802.1X, o padrão para controlo de acesso à rede baseado em portas. 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 palavra-passe 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 partilhado. O RADIUS chama a esse dispositivo de NAS (network access server).
• Os dispositivos veem um novo certificado de servidor durante o handshake EAP.
• A política lê grupos a partir do Microsoft Entra ID, Okta ou Google Workspace em vez de um diretório local.
• Os registos (logs) passam para uma nova consola.

As coisas que permanecem iguais são as mais importantes. Mantém os seus pontos de acesso, nomes de SSID, IDs de VLAN, trunks de switch e zonas de firewall. Ninguém altera uma palavra-passe ou adere a uma nova rede.

A mesma abordagem aplica-se a todas as três redes no Purple Access. Em redes abertas, muitos portais cativos (Captive Portal) autorizam dispositivos através de RADIUS. As redes seguras utilizam EAP-TLS ou PEAP. Em redes xPSK, o RADIUS dá a cada dispositivo ou residente a sua própria chave pré-partilhada. Este guia segue a rede segura, porque é a que envolve mais riscos.

{"tone":"warning","title":"O risco que preocupa: confiança no certificado do servidor","text":"Os dispositivos em EAP-TLS ou PEAP verificam o certificado do servidor RADIUS e muitos confiam apenas na autoridade de certificação do servidor antigo. Envie a nova CA para todos os perfis de dispositivo antes que o primeiro site seja migrado, ou esses dispositivos falharão a ligação e continuarão a tentar."}

Assim que tiver tratado da confiança no certificado, o resto da migração é trabalho de configuração e períodos de espera.

O que tem de estar garantido antes da fase 1?

Devem estar reunidas cinco condições antes de ser criada qualquer política. Se faltar uma, causará problemas numa fase posterior.

Um inventário completo de NAS

Liste todos os dispositivos que enviam pedidos para o servidor antigo. Isso inclui pontos de acesso, controladores sem fios, switches que fazem 802.1X por cabo e gateways VPN. Elabore a lista a partir da lista de clientes RADIUS do servidor antigo, e não a partir do diagrama de rede. Se um NAS faltar no inventário, não poderá desligar o servidor antigo na fase 4.

Um mapa de políticas, linha por linha

Anote cada regra que o servidor antigo aplica, com a sua condição, o seu resultado e os atributos que devolve. As linhas típicas têm este aspeto: grupo de funcionários para a VLAN de funcionários, prestadores de serviços para uma VLAN restrita, portáteis corporativos por certificado para a VLAN corporativa. Note quais os atributos que transportam a VLAN. A RFC 3580 define o conjunto padrão: Tunnel-Type, Tunnel-Medium-Type e Tunnel-Private-Group-ID. Algumas infraestruturas utilizam atributos específicos do fornecedor e deve espelhá-los exatamente.

Um plano de certificados

Decida qual a autoridade de certificação (CA) que emite o novo certificado do servidor. Em dispositivos geridos, envie essa CA através do Microsoft Intune, Jamf ou da sua plataforma de gestão de dispositivos móveis (MDM) antes de qualquer migração de local. Para EAP-TLS, o novo servidor também deve confiar na CA que emitiu os certificados dos seus dispositivos.

Uma fonte de identidade que o novo servidor consiga ler

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

Acessibilidade, responsáveis e janelas de alteração

Cada local precisa de um caminho de rede para o servidor na nuvem, utilizando os endereços e portas na documentação de integração da Purple. Nomeie um responsável para cada local e acorde janelas de alteração com os gestores dos locais. Anote o acionador de reversão (rollback) antes de mover qualquer elemento.

{"title":"Multi-site RADIUS migration checklist","groups":[{"heading":"Before phase 1","items":[{"text":"Export the old server's RADIUS client list and reconcile it with the NAS inventory","why":"A forgotten NAS blocks decommission"},{"text":"Map every policy rule: condition, result and returned attributes"},{"text":"Confirm every policy group exists in Microsoft Entra ID, Okta or Google Workspace"},{"text":"Push the new server CA to managed devices through your MDM"},{"text":"Open the paths in Purple's onboarding documentation at each site"},{"text":"Name an owner and a change window per site, and agree the rollback trigger in writing"}]},{"heading":"Phase 1: build","items":[{"text":"Freeze policy changes on the old server"},{"text":"Recreate each policy row on the new server"},{"text":"Test one identity per row against both servers and match the replies"}]},{"heading":"Phases 2 and 3: pilot and waves","items":[{"text":"Record a baseline reject rate per site before cutover"},{"text":"Add the new server alongside the old on each SSID"},{"text":"Confirm every device class authenticates on the new server"},{"text":"Hold each wave for one full business cycle before the next"}]},{"heading":"Phase 4: decommission","items":[{"text":"Remove the old server from every SSID and NAS"},{"text":"Confirm zero requests on the old server for the agreed quiet period"},{"text":"Export and retain old server logs under your retention policy"},{"text":"Retire the shared secrets used with the old server"},{"text":"Update the runbook and file each site's exit-test record"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

Quais são as 4 fases, por ordem?

O plano tem quatro fases. Cada uma termina com um teste de saída no qual pode ser aprovado ou reprovado. Nada avança para a fase seguinte até que o teste seja aprovado, evitando assim uma transição abrupta.

{"kind":"timeline","direction":"lr","caption":"Uma propriedade ilustrativa de 40 locais: quatro fases, cada uma terminada com um teste de saída","alt":"Linha temporal mostrando a preparação, depois a fase 1 de construção, fase 2 de piloto, fase 3 de vagas e 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, envio de CA, fonte de identidade","tone":"neutral","when":"Semanas 1-2"},{"id":"p1","label":"Fase 1: construção e espelhamento","sub":"Política reconstruída no RADIUS em nuvem, respostas de laboratório coincidem","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: vagas","sub":"Cinco, depois 10, depois os 24 locais restantes","tone":"brand","when":"Semanas 6-10"},{"id":"p4","label":"Fase 4: desativação","sub":"Zero pedidos no servidor antigo, depois encerrar","tone":"success","when":"Semanas 11-12"}],"edges":[{"from":"p0","to":"p1","label":"pré-requisitos preenchidos"},{"from":"p1","to":"p2","label":"respostas de laboratório coincidem"},{"from":"p2","to":"p3","label":"teste de saída do piloto"},{"from":"p3","to":"p4","label":"todos os locais migrados"}]}

{"caption":"Plano de fases para uma migração RADIUS multilocal","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 NAS, mapa de políticas, envio de CA, fonte de identidade, caminhos de locais","Gestor de TI com responsável de identidade e acesso","Cada NAS listado, cada grupo de políticas no fornecedor de identidade, nova CA em dispositivos geridos"],["Fase 1: construção","Política reconstruída no RADIUS em nuvem, sem tráfego em tempo real","Responsável de identidade e acesso","Uma identidade de teste por linha recebe a mesma resposta e VLAN do antigo e do novo"],["Fase 2: piloto","Um local representativo, novo servidor primário, antigo secundário","Arquiteto de rede","Um ciclo de negócio sem rejeições não explicadas e cada classe de dispositivo vista no novo servidor"],["Fase 3: vagas","Locais restantes em vagas crescentes, agrupados por modelo de consola","Arquiteto de rede com responsáveis dos locais","Cada vaga passa o teste de saída do piloto antes de a seguinte começar"],["Fase 4: desativação","Servidor antigo removido de cada SSID e NAS","Gestor de TI","Zero pedidos no servidor antigo durante o período de inatividade, registos mantidos, segredos retirados"]],"footnote":"Os responsáveis são funções, não pessoas nomeadas. Defina o período de inatividade para pelo menos um ciclo de reautenticação mais uma semana de trabalho.","download":{"filename":"radius-migration-phase-plan.csv"}}

O que acontece dentro de cada fase?

Fase 1: construir e espelhar a política

Reconstrua o mapa de políticas no novo servidor antes que qualquer pedido em tempo real o alcance. Ligue o fornecedor de identidade e, em seguida, recrie cada linha com a sua condição, resultado e atributos devolvidos. 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. Utilize o eapol_test, uma ferramenta do projeto wpa_supplicant. Envia uma troca de EAP real para um servidor RADIUS e imprime a resposta. Execute uma identidade por linha contra ambos os servidores e compare as respostas. O teste de saída é uma correspondência em todas as linhas, com a mesma aceitação ou rejeição e o mesmo VLAN.

Fase 2: piloto num local

Escolha um local que represente a totalidade dos seus edifícios e não o mais fácil. Deve ter todas as classes de dispositivos com que trabalha, incluindo as mais difíceis. Pense em scanners portáteis, terminais de pagamento em WiFi e computadores portáteis mais antigos. 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, em seguida, torne o novo servidor o principal. Mantenha-o assim durante um ciclo de atividade completo. Para um hotel, isso significa uma semana de turnos de trabalho. Para um escritório, significa uma semana de acessos à segunda-feira de manhã. O piloto é aprovado quando duas condições se confirmam. Primeiro, todas as classes de dispositivos se autenticaram no novo servidor. Segundo, a taxa de rejeição não é pior do que a sua linha de base.

Fase 3: migrar os edifícios em vagas

Faça com que cada vaga seja maior do que a anterior à medida que as primeiras vão sendo aprovadas. Um conjunto de 40 edifícios pode migrar um local piloto, depois cinco, depois 10 e, por fim, os 24 restantes. Agrupe cada vaga por modelo ou grupo de consola, para que uma alteração alcance todos os locais nessa vaga. Os modelos de configuração Meraki, os modelos de WLAN Juniper Mist e os grupos do HPE Aruba Central adequam-se todos a esta abordagem.

Efetue a transição enquanto os colaboradores do local estiverem presentes, não às 3:00. Uma alteração que ninguém testa até de manhã é uma alteração que não testou. Evite associar outras alterações de rede à mesma janela de intervenção.

Fase 4: desativar o servidor antigo

Remova o servidor antigo de todos os SSID e de todos os NAS no inventário e, em seguida, monitorize os respetivos registos. Os pedidos devem cair para zero. Qualquer pedido que ainda chegue provém de um NAS que tenha esquecido. Mantenha o período de inatividade durante pelo menos um ciclo de reautenticação acrescido de uma semana de atividade. Em seguida, exporte os registos ao abrigo da sua política de retenção, encerre o servidor e desative os seus segredos partilhados.

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

Considere um grupo de 40 hotéis a operar com WiFi para colaboradores em Cisco Meraki. Utiliza o PEAP num servidor RADIUS local na sede. Cada pedido cruza a WAN para um edifício, pelo que uma falha na sede desativa o WiFi para colaboradores em todos os hotéis.

O grupo distribui a nova CA através do seu MDM na primeira semana. Reconstrói cinco linhas de política no RADIUS na nuvem em comparação com o Microsoft Entra ID e, em seguida, realiza um piloto num hotel de cidade com 120 quartos. Seguem-se vagas de cinco, 10 e 24 hotéis, sendo cada uma delas um modelo de configuração Meraki. Um hotel reverte a alteração durante uma tarde porque um tablet do serviço de limpeza confia apenas na CA antiga. Voltou a migrar uma semana mais tarde.

O resultado:

• Todos os 40 hotéis migraram em seis janelas de alteração.
• Um local reverteu a alteração uma vez.
• A sede já não se encontra no caminho de autenticação.

Como é que os servidores RADIUS antigo e novo funcionam em simultâneo?

A execução em paralelo depende da forma como os pontos de acesso fazem a migração em falha (failover). Um NAS envia cada pedido para o primeiro servidor da sua lista. Apenas tenta o servidor seguinte quando o primeiro não responde dentro do tempo limite (timeout).

Um Access-Reject conta como uma resposta, não como uma falha, pelo que o NAS não voltará a tentar o pedido noutro local. Isto tem duas consequências:

• Ambos os servidores devem dar a mesma resposta. Se diferirem, a experiência do dispositivo dependerá do servidor que por acaso responder.
• 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 limites antes da migração do primeiro local. Um servidor na nuvem está mais distante do que um servidor na sua sala de comunicações. Compare as definições de timeout e de nova tentativa de cada NAS do local com o seu tempo de viagem de ida e volta (round-trip time). Se as definições forem demasiado apertadas, os pedidos farão failover para o servidor antigo sem motivo real, o que esconde problemas. Mova a contabilidade RADIUS para o novo servidor no mesmo momento da autenticação, para que os registos de sessão fiquem num único local.

A transição em cada local consiste simplesmente em inverter a ordem dos dois servidores. Estes passos aplicam-se a todos os locais, com as diferenças de fornecedores apresentadas no passo 2.

{"title":"Efetuar o cutover de um local sem um dia de transição global","steps":[{"title":"Confirmar que o local está pronto","body":"Verifique o local em relação à lista de verificação de migração: NAS listado, nova CA nos dispositivos geridos, caminho para a Purple aberto, responsável no local.","check":"Todos os pré-requisitos para o local foram assinalados."},{"title":"Adicionar o novo servidor ao lado do antigo","body":"Adicione o RADIUS em nuvem da Purple à lista de servidores RADIUS do SSID, utilizando o segredo partilhado emitido pela Purple para o local. Mantenha o servidor antigo em primeiro lugar por agora.","check":"A consola mostra ambos os servidores associados ao SSID.","variants":[{"label":"Meraki","body":"No Meraki Dashboard, adicione o servidor nas definições de controlo de acesso do SSID, idealmente no modelo de configuração."},{"label":"Aruba","body":"No HPE Aruba Central, adicione o servidor ao grupo de servidores de autenticação que a WLAN utiliza."},{"label":"Ruckus","body":"Adicione o servidor ao perfil de servidor AAA que a WLAN utiliza, como servidor secundário."},{"label":"Mist","body":"No portal Juniper Mist, adicione o servidor aos servidores de autenticação RADIUS da WLAN, idealmente no modelo da WLAN."},{"label":"UniFi","body":"Na aplicação UniFi Network, adicione o servidor ao perfil RADIUS atribuído à rede WiFi."}]},{"title":"Testar antes de alternar","body":"A partir de um anfitrião de teste registado 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 pelo mapa de políticas, com a VLAN esperada."},{"title":"Alternar a ordem","body":"Torne o novo servidor primário e mantenha o servidor antigo como secundário. Este é o cutover.","check":"Os registos do novo servidor mostram pedidos de todos os pontos de acesso no local."},{"title":"Aguardar durante um ciclo de negócio","body":"Compare a taxa de rejeição com a sua referência e confirme que todas as classes de dispositivos foram autenticadas.","check":"Sem rejeições não explicadas e o local passa o seu teste de saída."}]}

Como reverter um local ou uma vaga?

A reversão é o cutover no sentido inverso: volta a colocar o servidor antigo em primeiro lugar. Em cada consola referida acima, trata-se de uma única alteração de configuração. Só funciona se o servidor antigo ainda estiver em execução, inalterado e com os seus segredos partilhados intactos. É por isso que a desativação é efetuada em último lugar. É também por isso que deve congelar a política no servidor antigo no início da fase 1.

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

• Uma classe de dispositivos que não consegue ligar-se e não tem correção no próprio dia.
• Atribuições de VLAN que diferem do mapa de políticas.
• Uma taxa de rejeição acima da referência que não consegue explicar dentro da janela de alteração.

{"title":"Avançar, pausar ou reverter uma vaga","start":"q1","nodes":[{"id":"q1","question":"Alguma classe de dispositivos está a falhar no novo servidor que tenha passado no antigo?","help":"Compare as rejeições por tipo de dispositivo com a linha de base registada antes da transição.","options":[{"label":"Sim","to":"q2"},{"label":"Não","to":"q3"}]},{"id":"q2","question":"A falha está limitada a uma classe de dispositivos com uma correção conhecida?","help":"Uma CA em falta num 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 termina na VLAN esperada em todos os locais da vaga?","options":[{"label":"Sim","to":"q4"},{"label":"Não","to":"o3"}]},{"id":"q4","question":"A vaga 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 vaga","detail":"Registe o resultado do teste de saída por local e agende a próxima vaga.","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 a regra e execute novamente o teste de saída."},{"id":"o3","outcome":"Reverter a vaga","detail":"Coloque o servidor antigo em primeiro lugar em todos os SSID da vaga, capture os registos de ambos os servidores e identifique 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 registos de ambos os servidores para a janela de tempo da falha. Identifique 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 de o local ser movido novamente.

Como saber se a migração terminou?

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

1. O servidor antigo registou zero pedidos durante o período de inatividade acordado.
2. Todos os NAS do inventário aparecem nos registos do novo servidor.
3. Um dispositivo real testou cada linha de política e terminou na VLAN esperada.
4. A taxa de rejeição está igual ou abaixo da linha de base registada antes da fase 2.
5. O servidor antigo está desligado, os seus registos foram mantidos, os seus segredos foram desativados e o manual de operações (runbook) foi atualizado.

Mantenha um registo de uma página para cada local, com a data, o resultado do teste de saída e qualquer reversão. Juntamente com os novos registos de autenticação, esses registos constituem a sua evidência para o controlo de acessos da ISO 27001 e para os controlos de registo do PCI-DSS. Também servem como evidência de controlo de alterações para o próximo ciclo de auditoria.

Modos de falha observados no terreno

Dispositivos que confiam apenas no certificado antigo

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

Um NAS que ninguém listou

Controladores esquecidos, switches 802.1X cablados e gateways VPN mantêm o servidor antigo ocupado muito depois de o WiFi ter sido migrado. O período de inatividade na fase 4 é a forma de os detetar.

Políticas que residiam no servidor antigo

Grupos locais, listas de MAC hard-coded e regras por hora do dia existem muitas vezes apenas no servidor antigo. Se não estiverem no mapa de políticas, desaparecem no momento da transição.

Incompatibilidades de segredo partilhado e atributos

Um segredo introduzido incorretamente falha silenciosamente em algumas consolas. Um VLAN devolvido por nome em vez de ID pode colocar dispositivos no VLAN predefinido. Ambos devem ser detetados nos testes da fase 1 e deve voltar a verificar no piloto.

Timeouts ajustados para um servidor no edifício

Timeouts reduzidos num NAS causam um failover espúrio para o servidor antigo. Tudo parece funcionar até que o servidor antigo seja removido.

Cenário prático: um retalhista de 120 lojas em duas consolas

Considere um retalhista de 120 lojas com lojas mais antigas em HPE Aruba e mais recentes em Juniper Mist. Os terminais portáteis e portáteis das lojas usam EAP-TLS em relação a um par de servidores RADIUS locais. O piloto e as fases decorrem sem problemas, agrupados por grupo do Aruba Central e modelo WLAN do Mist.

Na fase 4, os servidores antigos continuam a registar pedidos de três endereços após a migração de todos os SSID. Dois são controladores de centros de distribuição fora do parque de lojas. O terceiro é um gateway VPN para portáteis da sede. A equipa adiciona os três ao inventário, migra-os numa janela adicional e reinicia o período de inatividade. O encerramento definitivo termina com duas semanas de atraso, sem qualquer interrupção em nenhuma loja.

Onde a Purple se enquadra

O Purple Access executa redes abertas, seguras e xPSK numa única plataforma, utilizando os pontos de acesso que já possui. A rede segura suporta esta migração. Fornece RADIUS na nuvem, EAP-TLS e identidade a partir do Microsoft Entra ID, Okta ou Google Workspace. Também suporta Passpoint, também chamado Hotspot 2.0, que permite aos dispositivos juntarem-se a uma rede segura automaticamente com uma credencial. A Purple é agnóstica em relação ao hardware, pelo que uma única política serve locais nestas plataformas:

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

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

A Purple opera o maior RADIUS na nuvem do mundo. Inclui um SLA de disponibilidade do RADIUS de 99,9%, numa plataforma que funciona com 99,999% de disponibilidade. Como o lado da Purple é configurado antes do início da fase 2, a transição de cada local é normalmente um exercício de fim de semana. O faseamento existe para gerir o risco no seu parque de equipamentos, não na nossa plataforma.

{"items":[{"value":"80,000+","label":"locais ativos","note":"Dados próprios da Purple"},{"value":"90","label":"países"},{"value":"99.9%","label":"SLA de disponibilidade do RADIUS","note":"Numa plataforma com 99,999% de disponibilidade"}]}

{"tone":"proof","title":"WiFi para funcionários à escala de sucursais","text":"A JPMorgan executa o WiFi para funcionários na Purple em 5 000 sucursais."}

Consulte RADIUS na nuvem no Purple Access para obter os detalhes do produto e o guias de segurança de WiFi empresarial para o conjunto de controlos mais amplo. O marketing de visitantes está no Engage e a filtragem de DNS está no Shield. Nenhum deles sofre alterações durante uma migração de RADIUS.

Perguntas frequentes

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

Planeie para várias semanas em todo o parque de equipamentos e um fim de semana por local. No Purple, a transição de cada local é normalmente um exercício de fim de semana. O parque de equipamentos demora mais tempo porque cada vaga aguarda por um ciclo de negócio antes de a seguinte começar. Um parque exemplificativo de 40 locais demora cerca de 12 semanas desde o inventário até ao desmantelamento. 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 na nuvem?

Não. O RADIUS na nuvem altera o servidor que os 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. Adiciona o novo servidor à lista de servidores RADIUS de cada SSID na consola que já utiliza. Os seus SSIDs, IDs de VLAN e a configuração do switch permanecem como estão.

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

Modele-o com base em dois números: locais e identidades. Conte cada local que se autentica e cada identidade que se junta, incluindo dispositivos em 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 sede. O nosso guia para modelar o custo do RADIUS na nuvem por local explica o cálculo passo a passo.

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

Mantenha-o durante a execução em paralelo e, em seguida, deslique-o. Enquanto estiver listado como secundário, cobre os tempos limite nos locais que ainda estão nas vagas. Após a fase 4, um servidor que contenha uma cópia congelada da política antiga torna-se um risco, porque qualquer resposta que dê utiliza regras desatualizadas. A partir daí, a resiliência provém do SLA de 99,9% de tempo de atividade do RADIUS e de um plano de recuperação de falhas.

Os colaboradores terão de voltar a registar os seus dispositivos?

Não, se o certificado do novo servidor for fidedigno antes da transição. Envie a nova AC para os dispositivos geridos através do seu MDM durante a fase de compilação. Os dispositivos em EAP-TLS mantêm os seus certificados de cliente existentes, desde que o novo servidor confie na AC que os emitiu. Os dispositivos PEAP não geridos são a exceção, porque alguns solicitam uma vez a aceitação do novo certificado. Envie a esses colaboradores um aviso curto antes da mudança do seu local.

A migração afeta a nossa evidência de ISO 27001 ou PCI DSS?

Isso altera a origem das suas evidências, pelo que deve planeá-lo desde o início. Os registos de autenticação, definições de políticas e registos de alterações mudam para a nova plataforma. Conserve os registos do servidor antigo ao abrigo da sua política de retenção e arquive o registo de teste de saída de cada local. A Purple possui a certificação ISO 27001, o que fornece aos seus auditores evidências do lado da plataforma. Os seus próprios controlos ainda precisam de recolher as suas próprias evidências.

Como é que isto difere para um MSP que gere vários ambientes?

As fases são as mesmas. O que difere é o isolamento entre ambientes. Um MSP executa as mesmas quatro fases para cada ambiente, mas cada um precisa da sua própria política, fonte de identidade e registos numa plataforma partilhada. As vagas geralmente seguem os limites contratuais em vez dos modelos de consola. O nosso guia sobre RADIUS multi-tenant para MSPs aborda como manter cada ambiente separado durante e após a migração.