Integração BYOD: Como configurar o acesso de colaboradores e convidados
Published
Um novo colaborador chega com um telemóvel pessoal, um prestador de serviços surge com um portátil mais antigo e um convidado precisa de WiFi antes de a reunião começar. Se os três receberem a mesma palavra-passe partilhada, o acesso é fácil de conceder e difícil de controlar mais tarde. A integração de BYOD funciona melhor quando escolhe um caminho para cada tipo de dispositivo e, em seguida, planeia o que acontece quando alguém não pode ou não quer inscrevê-lo.
A chave é tratar a integração como um ciclo de vida. Uma página de início de sessão pode registar quem se ligou, mas não estabelece que um dispositivo está seguro, não decide ao que pode aceder nem garante que o seu acesso possa ser revogado.
Índice
- Escolher um método de integração BYOD
- Configurar o portal cativo e o início de sessão com SSO
- Emitir certificados EAP-TLS através do seu MDM
- Integração sem MDM e chaves por dispositivo para dispositivos partilhados
- Rotas de recurso para dispositivos não suportados e parcialmente geridos
- Regras de consentimento, privacidade e desassociação
- Confirmar a ordem da rota e realizar um piloto primeiro
Escolher um Método de Onboarding para BYOD
| Método | Gestão de dispositivos necessária | Credencial emitida | Ideal para | Principal limitação |
|---|---|---|---|---|
| Portal cativo com SSO, Google, Apple, Facebook ou SMS | Nenhuma | Sessão de navegador com consentimento registado | Convidados e visitantes ocasionais | O início de sessão no portal não comprova a postura do dispositivo |
| Certificado de EAP-TLS emitido por MDM através de SCEP | MDM inscrito, como Intune ou Jamf Pro | Certificado por dispositivo | Telemóveis e portáteis geridos de colaboradores | Dispositivos pessoais não inscritos não podem aceder |
| Passe de WiFi instalado por aplicação sem MDM | Aplicação de instalação, sem MDM | Passe por utilizador ou por dispositivo | Equipas de limpeza, pessoal de agência, telemóveis pessoais | Menor visibilidade sobre a postura do dispositivo |
| Chave de xPSK por dispositivo | Nenhuma no dispositivo | Chave pré-partilhada exclusiva por dispositivo | Caixas registadoras partilhadas, IoT, residentes | Requer gestão de chaves e um processo de revogação |
| Perfil Passpoint ou OpenRoaming | Perfil instalado no dispositivo | Identidade baseada em certificado | Visitantes recorrentes em diferentes locais | Apenas dispositivos que suportem Passpoint |
Estes caminhos adequam-se a diferentes níveis de confiança e a diferentes expetativas dos utilizadores. Um portal no navegador mantém o acesso de convidados simples, mas não consegue verificar a postura de segurança de um telemóvel. Um certificado atribui a um dispositivo gerido uma identidade mais forte no momento da ligação, mas exige a inscrição. Para dispositivos que não podem receber um perfil de MDM, um passe ou uma chave exclusiva oferece uma alternativa a uma palavra-passe partilhada em todo o local.
O BYOD tornou-se um requisito de controlo de acessos à medida que os dispositivos pessoais passaram a integrar o trabalho diário. Num inquérito do IBSG da Cisco de 2012 realizado a 600 líderes de TI e de negócios nos EUA, 95% afirmaram que as suas organizações permitiam, de alguma forma, o uso de dispositivos propriedade dos colaboradores, e 84% não só permitiam dispositivos pessoais como ofereciam, pelo menos, algum suporte (estudo de BYOD de 2012 da Cisco). Esta distinção é importante: permitir a entrada de um dispositivo no WiFi não é o mesmo que dar-lhe suporte, atribuir-lhe o acesso adequado ou preparar a remoção das suas credenciais.
Escolha a predefinição antes da exceção
Comece por atribuir uma rota predefinida a cada classe de dispositivo. Os dispositivos geridos dos funcionários devem utilizar certificados; os convidados devem utilizar um portal; os dispositivos sem MDM devem obter um passe instalado por aplicação ou uma chave única, e não uma palavra-passe partilhada. Os convidados habituais podem ser adequados para Passpoint ou OpenRoaming se os seus dispositivos suportarem o perfil.
Em seguida, verifique se a predefinição escolhida exige algo que o utilizador não irá fornecer, como a permissão para gerir um telemóvel pessoal. Envie apenas essas exceções para as rotas de recurso, em vez de enfraquecer a predefinição para todos. Uma WiFi visão geral do controlo de acesso pode ajudar as equipas a mapear a autenticação de acordo com a política de acesso, mas as suas classes de dispositivos e permissões de rede devem orientar a escolha final.
Configurar o portal cativo e o início de sessão SSO
Um portal cativo é uma opção padrão prática para convidados, porque estes podem iniciar sessão sem instalar um perfil de gestão. Também é útil quando precisa de registar o consentimento ou permitir que os visitantes se autentiquem utilizando uma conta que já possuem. A decisão de conceção importante é para onde o portal envia cada utilizador após o início de sessão: a autenticação deve encaminhar para a rede correta e não conceder um acesso amplo por predefinição.
Criar e testar o fluxo de início de sessão
Mapeie a rede e escolha um local piloto. Numa sessão de conceção, mapeie pontos de acesso, SSIDs, grupos de diretório e classes de dispositivos em redes abertas, seguras e de xPSK. Um engenheiro de rede deve deixar a equipa com um plano e um local piloto, para que a configuração reflita o património físico e não um diagrama idealizado.
Registe uma aplicação de identidade. Configure uma aplicação no Entra ID, Google Workspace ou Okta e conceda o acesso ao diretório necessário para o início de sessão. Utilize primeiro um registo piloto, para poder verificar as permissões e a experiência de início de sessão antes de expandir a implementação.
Adicione os detalhes do portal e de RADIUS ao controlador. Configure o servidor de RADIUS e o URL de splash. Assim que o registo da aplicação existir, a configuração do lado do cliente demora menos de 15 minutos, incluindo estas alterações no controlador.
Escolha os métodos de início de sessão para cada público. Utilize o SSO para os funcionários que necessitam de uma identidade organizacional, o Google ou a Apple para contas pessoais e o Facebook onde os visitantes o esperem. Os códigos de acesso único por SMS oferecem aos visitantes sem uma conta adequada outra via.
Personalize o portal com a sua marca e torne o consentimento claro. Escreva o texto de consentimento numa linguagem clara e registe uma entrada para cada início de sessão. Coloque o aviso num local onde o utilizador o possa ler antes de aceitar, e não abaixo do botão em que precisa de clicar.
Testar dispositivos reais na rede de convidados. Ligue um iPhone pessoal, um telefone Android e um portátil Windows. Confirme que cada utilizador vai ter à VLAN de convidados e que o isolamento de clientes impede que os dispositivos de convidados acedam entre si.
Os deslizes habituais no piloto são um URL de splash a apontar para o controlador errado, texto de consentimento oculto sob o botão de início de sessão e testes realizados apenas com dispositivos corporativos. Cada um destes pontos pode fazer com que um portal pareça bem-sucedido num teste restrito, mas falhar para as pessoas que dele necessitam. As equipas que utilizam o Okta também podem consultar este guia de autenticação do Okta no WiFi ao planearem a ligação de identidade.
Emitir certificados EAP-TLS através do seu MDM
Para dispositivos geridos de colaboradores, uma adesão baseada em certificados vincula o acesso à rede a um dispositivo registado, em vez de depender de uma palavra-passe partilhada WiFi. O dispositivo comprova a sua identidade durante a ligação, e a identidade do utilizador pode determinar quais as permissões de rede aplicáveis. O NIST descreve um certificado aprovisionado como uma forma de identificar e autenticar um dispositivo móvel no ponto de ligação, e assinala que a sua combinação com credenciais de utilizador pode fornecer uma autenticação de dois fatores (orientação de segurança para dispositivos móveis do NIST).
A escala raramente é o problema aqui. A disponibilização de certificados através de SCEP demora entre cinco a dez minutos uma única vez para toda a organização, pelo que, na noite da migração, os computadores portáteis e telemóveis geridos recebem o respetivo certificado do MDM e ligam-se automaticamente. O trabalho mais difícil é decidir que verificações um dispositivo tem de passar antes que esse certificado seja considerado de confiança.
Integrar a confiança no dispositivo no processo de adesão
Autenticar o utilizador. Comece com SSO ou outro fator aprovado, para que a rede possa associar um dispositivo a uma pessoa ou conta conhecida.
Verificar a inscrição e a postura. Confirme se o dispositivo está inscrito e cumpre os requisitos mínimos de SO e segurança da organização. Trate um dispositivo pessoal como potencialmente não confiável até que passe por essas verificações.
Emitir um certificado vinculado ao dispositivo. Utilize o MDM para entregar o certificado via SCEP. Uma credencial vinculada ao dispositivo é mais fácil de gerir do que um segredo partilhado, pois pode ser associada a um único ponto de extremidade inscrito e revogada sem alterar mais nada.
Ligar utilizando EAP-TLS. Configure o cliente e a rede para validar os certificados relevantes. As credenciais do utilizador e o certificado do dispositivo fornecem depois verificações de identidade distintas no momento da ligação.
Atribuir acessos por grupo. Mapeie grupos de diretório para VLANs de menor privilégio, para que a função de um colaborador determine o que a sessão pode alcançar. Uma autenticação bem-sucedida não deve significar automaticamente o acesso a todos os serviços internos.
Reverificar a conformidade continuamente. Não limite a avaliação de políticas à inscrição inicial. Reavalie a postura do dispositivo e remova o acesso quando um dispositivo já não cumprir os requisitos, ou quando a conta associada ao mesmo for desativada.
As causas comuns de assistência técnica incluem versões de SO não suportadas, certificados expirados, hora do sistema incorreta, falta de certificados na cadeia de confiança, aleatorização de endereços MAC privados e utilizadores que recusam permissões de gestão. Monitorize as falhas por modelo de dispositivo e versão de SO, pois uma taxa de integração global saudável pode ocultar quebras repetidas numa única plataforma.
- SO não suportado: Ofereça uma via de atualização aprovada ou encaminhe o dispositivo para um acesso restrito.
- Certificado expirado: Automatize a renovação com a antecedência necessária para evitar interrupções de serviço quando uma credencial expirar.
- Hora incorreta ou cadeia de confiança em falta: Verifique o relógio do dispositivo e a instalação do certificado antes de alterar a política de rede.
- Aleatorização de MAC privado: Confirme se a política da rede depende de um endereço de dispositivo estável e forneça instruções de configuração específicas para a plataforma.
- Permissões de gestão recusadas: Explique o que a gestão pode visualizar e ofereça uma via de recurso em vez de conceder um acesso amplo.
A linha de base de conformidade em si permanece simples. Os dispositivos devem receber atualizações de segurança prontamente e de acordo com um agendamento regular, utilizar bloqueio de ecrã, instalar aplicações apenas a partir de fontes autorizadas e ser impedidos de se ligar caso tenham root ou jailbreak. Um dispositivo que falhe essas verificações de postura pertence a uma rede segregada e com baixos privilégios, não à rede corporativa.
A sequência é mais fácil de compreender quando se visualiza o fluxo do certificado em contexto. O vídeo abaixo fornece um complemento visual aos passos de integração.
Integrar sem MDM e chaves por dispositivo para dispositivos partilhados
Alguns dispositivos não conseguem concluir o registo em MDM. Isso inclui um telemóvel pessoal cujo proprietário não permite a gestão, uma caixa registadora ou quiosque partilhado e um sensor IoT sem uma interface de registo adequada. A solução não passa por colocar todos esses dispositivos na rede de colaboradores. Utilize uma rota restrita que atribua a cada dispositivo uma credencial identificável e um proprietário claro.
Utilizar um passe ou chave com um proprietário definido
Confirme que o dispositivo não é gerido ou não é suportado. Verifique se este não pode utilizar a via do certificado e se o seu proprietário concorda com qualquer aplicação de instalação. Isto evita que uma exceção se torne a norma apenas porque a inscrição é inconveniente.
Forneça aos telemóveis pessoais um passe de WiFi instalado via aplicação. O utilizador inicia sessão e instala o passe sem inscrever todo o telemóvel no MDM. Para uma implementação gerida, os telemóveis pessoais podem instalar um passe de WiFi a partir da aplicação Purple em dois toques na noite de transição.
Atribua a cada terminal partilhado a sua própria chave de xPSK. Coloque a caixa registadora ou quiosque no seu próprio VLAN, com um limite de largura de banda adequado à sua função. Uma chave exclusiva impede que uma palavra-passe se espalhe por todas as caixas registadoras.
Ajuste a validade da chave ao tipo de utilização. Configure-a para se adequar à reserva, ao contrato ou ao padrão de turnos. Uma credencial temporária não deve permanecer útil após a pessoa ou o dispositivo já não precisarem de acesso.
Registe quem detém cada chave. Mantenha um proprietário de dispositivo ou utilizador associado à credencial, para que a equipa de suporte possa identificar que acesso revogar quando um dispositivo se perde ou um trabalhador sai.
Revogue a chave e teste o resultado. Remova o acesso no momento da saída e confirme que o dispositivo se desliga da rede. A revogação faz parte da conceção do acolhimento (onboarding), e não uma tarefa a inventar após um problema surgir.
Estas rotas oferecem menor visibilidade sobre a postura do dispositivo do que um certificado, pelo que deve mantê-las em redes restritas em vez de as colocar no WiFi de funcionários VLAN. O compromisso operacional é simples: uma chave por dispositivo exige mais cuidado na emissão e na monitorização, mas limita o alcance de uma credencial comprometida.
Rotas de recurso para dispositivos não suportados e parcialmente geridos
O suporte não é suficientemente consistente para fazer de “registar ou perder o acesso” uma política viável para todos os colaboradores. Um relatório de segurança móvel de 2025 da Verizon revelou que 15% das organizações inquiridas ofereciam suporte completo para todos os tipos de dispositivos móveis, enquanto 32% ofereciam suporte pontual, 27% suportavam apenas modelos designados e 23% não forneciam qualquer suporte. Esta lacuna afeta pessoas que utilizam dispositivos mais antigos, prestadores de serviços, equipas de linha da frente e colaboradores que não consentem a monitorização ampla de um telemóvel pessoal.
| Caso do dispositivo | Via de integração | Acesso à rede | Verificação antes de conceder |
|---|---|---|---|
| SO totalmente gerido e suportado | Certificado MDM sobre EAP-TLS | Rede segura por grupo de diretório | Estado de conformidade e expiração do certificado |
| Telefone pessoal, sem permissão de gestão | Portal cativo ou passe da aplicação WiFi | VLAN de convidados com isolamento de clientes | Consentimento registado, sem VLAN corporativo |
| Versão de SO não suportada | Acesso apenas por navegador a aplicações designadas | Rede segregada de baixos privilégios | Data de atualização e lista de aplicações aprovadas |
| TPA ou quiosque partilhado | Chave xPSK por dispositivo | VLAN próprio com limite de largura de banda | Proprietário da chave e caminho de revogação |
| Prestador de serviços ou trabalhador temporário | Início de sessão de convidado com tempo limitado ou dispositivo de empréstimo | VLAN de convidados, com expiração no fim do contrato | Data de fim do contrato e responsável designado |
| Acessibilidade ou pedido para dispositivo antigo | Análise manual com um dispositivo de empréstimo | Limitado a aplicações aprovadas | Data de revisão e proprietário designado |
Mantenha a exceção restrita e documentada
Conceda a cada dispositivo o acesso mínimo necessário para a função. Um telemóvel pessoal que apenas necessita de acesso via navegador a um serviço específico não precisa de uma rota para aplicações internas ou para o WiFi corporativo VLAN. Uma caixa registadora partilhada necessita dos serviços que lhe foram atribuídos, e a sua credencial necessita de um proprietário identificado e de um caminho de revogação.
Publique uma matriz de compatibilidade de dispositivos para que os colaboradores possam verificar se o seu SO e dispositivo se podem inscrever antes de chegarem a um local. Mantenha um inventário dos sistemas operativos e aplicações não suportados e registe o caminho de alternativa aplicável a cada um. Para prestadores de serviços e visitantes, um caminho de rede com limite de tempo ajuda a tornar a expiração e o patrocínio explícitos.
Uma regra rígida pode piorar a segurança se levar os colaboradores a utilizar hotspots pessoais, palavras-passe partilhadas ou outras soluções alternativas não geridas. Uma rota restrita e documentada é frequentemente mais segura do que negar o acesso sem disponibilizar uma alternativa.
Regras de Consentimento, Privacidade e Offboarding
“Posso recusar o BYOD e o que é que o meu empregador poderá ver ou apagar exatamente?” Coloque a resposta no aviso de integração, antes de ser solicitado ao trabalhador que aceite um perfil ou instale uma aplicação. A autenticação técnica não prova que alguém compreendeu os termos ou se sentiu livre para escolher.
Num estudo realizado no setor dos cuidados de saúde, 50% dos prestadores utilizavam BYOD, mas apenas metade destes tinha uma política de BYOD; apenas 40% dos colaboradores que utilizavam dispositivos pessoais se recordavam de ter assinado qualquer política ou orientação. Um outro estudo de 2025 revelou que 70% dos colaboradores preferiam dispositivos fornecidos pela organização (o relatório de BYOD para a assistência social a adultos de 2025). Estas conclusões desafiam a suposição de que o acesso a partir de dispositivos pessoais é automaticamente mais barato ou mais conveniente para os trabalhadores.
O aviso deve indicar, em linguagem clara:
- Que telemetria de segurança é recolhida e que conteúdo pessoal a organização não pode ver.
- O que pode ser removido, incluindo a confirmação de que a remoção de um perfil de trabalho não apagará o conteúdo pessoal.
- Quem paga os dados móveis de trabalho e o desgaste do dispositivo, com regras de reembolso para o país relevante.
- Qual é a alternativa se o trabalhador recusar a gestão do dispositivo pessoal.
Uma caixa de seleção não representa um consentimento significativo se a participação for efetivamente obrigatória. Ofereça um dispositivo de empréstimo ou outra rota de acesso e solicite novamente o consentimento se a monitorização ou a utilização de dados mudarem. Para os processos de check-in de visitantes, as equipas também podem utilizar orientações para verificar os documentos de identificação dos convidados antes do check-in como um incentivo para ponderar quais as informações de identidade necessárias e como estas devem ser tratadas.
O descredenciamento tem de remover o certificado, o perfil de gestão, os tokens em cache e qualquer chave xPSK associada ao dispositivo. Uma demonstração do Purple Access pode mostrar a um engenheiro como emitir e revogar uma chave numa rede em tempo real, utilizando os dispositivos de um apartamento: uma fechadura, um termóstato, o portátil de um convidado e o telemóvel de um funcionário de um cliente.
- Emita uma chave num dispositivo ativo.
- Revogue-a.
- Cronometre quanto tempo o acesso demora a ser interrompido.
- Registe o resultado como a nota de aprovação de revogação do piloto.
Confirme a ordem das rotas e realize um piloto primeiro
Implemente as rotas numa ordem que impeça que as exceções definam toda a rede. Cada classe de dispositivo recebe uma predefinição, enquanto o piloto confirma que a rota funciona com as identidades, controladores e dispositivos num local real.
Comece com os dispositivos geridos dos colaboradores no EAP-TLS. Utilize a via do certificado para computadores portáteis e telemóveis registados, com acesso associado aos grupos do diretório e um caminho de revogação testado.
Adicione o portal de visitantes. Torne a experiência de início de sessão clara e registe o consentimento em cada sessão de visitante.
Passe os telemóveis pessoais e não geridos dos colaboradores para um passe WiFi. Isto oferece aos utilizadores uma alternativa que não exige o registo completo do dispositivo.
Coloque caixas registadoras partilhadas, quiosques e dispositivos IoT em chaves xPSK exclusivas. Atribua cada dispositivo à sua própria política de acesso e registe quem é o proprietário das respetivas credenciais.
Aplique vias de recurso apenas a exceções. Utilize o acesso exclusivo por navegador, uma rede de visitantes ou prestadores de serviços, um dispositivo de empréstimo ou uma revisão manual onde a via predefinida não seja possível.
Definir métricas piloto antes do lançamento
Escolha um local de piloto e defina as metas de aprovação antes de qualquer pessoa iniciar a inscrição. Meça a conclusão da inscrição, a primeira autenticação com sucesso, os contactos com o suporte por cada 100 inscrições e o tempo para revogar o acesso. Se definir os limites após o piloto, é demasiado fácil considerar um resultado fraco como aceitável porque o local já se encontra em funcionamento.
Agende uma sessão de conceção e traga a sua lista do SSID, o fornecedor de pontos de acesso, o diretório e o MDM. Um engenheiro de rede pode mapear esses detalhes para as redes abertas, seguras e do xPSK, e validar o plano relativamente ao local do piloto antes da implementação. O pedido de demonstração recolhe os dados da organização e de contacto, juntamente com o que é executado atualmente no WiFi do cliente, incluindo SSIDs, fornecedor de pontos de acesso, diretório e MDM.
O Purple Access suporta o início de sessão e consentimento em portal cativo, certificados EAP-TLS através de MDM e chaves por dispositivo para equipamento não gerido. Visite o Purple Access para agendar uma demonstração e traga os detalhes do seu dispositivo e da sua rede para a sessão de conceção.
