Planear Wi-Fi, certificados, VPN e proxy Apple com o Sophos Mobile

Âmbito: Sophos Mobile no Sophos Fusion (anteriormente Sophos Central), iPhone e iPad com iOS/iPadOS. Esta orientação distingue as políticas de dispositivo iOS (Device Policy) das políticas de utilizador iOS (User Policy). Não é uma configuração passo a passo testada para um tenant concreto, nem um guia para macOS, nem uma autorização para distribuição em massa em produção. Verifique primeiro no dispositivo de destino a versão do sistema operativo, o modo de inscrição, a supervisão (Supervision), o tipo de política e as funções disponíveis no próprio tenant.

⚠️ Não cortar a ligação: Um certificado Wi-Fi/EAP incorreto, uma CA SCEP inacessível, um PAC/WPAD defeituoso ou um túnel VPN podem também interromper o canal de retorno das tarefas MDM. Antes de qualquer alteração, confirme uma ligação independente do perfil alterado e uma via local de resolução de problemas. Uma reversão guardada na consola não chega automaticamente a um dispositivo bloqueado e offline.

Distinguir primeiro o modo de gestão

Device Enrollment não implica automaticamente supervisão: Automated Device Enrollment supervisiona o dispositivo, mas outros métodos não o fazem necessariamente. Apple User Enrollment nunca o supervisiona e abrange os dados geridos, não todo o dispositivo pessoal. Para BYOD, a conta Apple gerida (Managed Apple Account) e o consentimento fazem parte dos requisitos prévios. Nesse modo não há proxy HTTP global, VPN normal para todo o dispositivo nem definições de proxy na configuração Wi-Fi gerida; a Sophos não consegue consultar MAC/UDID/IMEI para identificação NAC.

A Sophos limita o User Enrollment baseado em perfis ao iOS/iPadOS 17 ou anterior; isto não significa a descontinuação geral do User Enrollment baseado em contas (account-driven). Ao cancelar a inscrição, o volume APFS gerido e a conta Apple gerida são removidos do dispositivo; isto não equivale a uma reversão geral do Wi-Fi ou da VPN. A Apple descreve a VPN por aplicação como uma função possível no User Enrollment, não como prova de que existe um método funcional de associação de aplicações na Sophos.

Planear o Wi-Fi e a cadeia de certificados em conjunto

Isolar o piloto BYOD antes de cada alteração: Para as políticas de utilizador iOS/iPadOS, a Sophos sincroniza automaticamente as alterações sempre que o dispositivo volta a ligar-se ao Sophos Mobile; não é necessário executar manualmente Update devices. Por isso, utilize uma política de utilizador separada, atribuída apenas ao dispositivo de teste BYOD autorizado, e verifique as suas atribuições atuais e o número de dispositivos de destino antes de editar e antes de Save. Não altere no piloto uma política já partilhada com dispositivos BYOD em produção. Uma atribuição posterior a dispositivos de teste selecionados não limita a sincronização da alteração nos outros dispositivos aos quais a mesma política já está atribuída. Esta regra de âmbito também se aplica a alterações de certificados e a correções durante a reversão; a sincronização, por si só, não confirma o funcionamento da rede nem a via de retorno MDM.

Quem verifica quem? Em Wi-Fi empresarial com EAP (autenticação entre dispositivo e rede), o dispositivo verifica o nome e a cadeia de certificados do servidor RADIUS. Na autenticação baseada em certificados, o RADIUS verifica, por sua vez, a identidade de cliente emitida. A CA do servidor e a identidade de cliente têm, portanto, funções diferentes. A opção Identity certificate da configuração Wi-Fi exige uma configuração Client certificate na mesma política; o certificado do servidor em Trusted certificates exige aí uma configuração Root certificate.

Apenas exemplos fictícios: não reutilizar: radius.test.invalid como nome do servidor, Test-CA como CA de confiança do servidor e CN=Testperson,OU=Pilot,O=Beispiel como subject X.500 (campos da identidade de cliente). Substitua todos os valores pelos nomes, pela CA e pelos campos de identidade confirmados pela própria equipa de PKI/RADIUS. No dispositivo de teste, verifique se a identidade de servidor configurada corresponde à cadeia real e se o RADIUS aceita o certificado de cliente emitido. O certificado raiz é um certificado X.509 em PEM/DER; um certificado de cliente importado está em PKCS#12 (.pfx). O carregamento de um .pfx não o torna automaticamente reutilizável em várias políticas: se precisar do certificado de cliente noutra política, tem de o carregar novamente nessa política. Verifique a origem da CA, a posse da chave, a validade e a finalidade prevista. Carregar uma CA raiz não prova que todas as aplicações confiem nela universalmente.

Para Root certificate numa política de dispositivo iOS, abra a configuração em Edit policy através de Add configuration > Root certificate. Selecione o ficheiro X.509 em PEM/DER com Upload a file e abra-o com Open. Após o carregamento, Certificate name apresenta o Distinguished Name (DN) do emissor, não a identidade de cliente. Guarde a configuração com Apply e, depois, guarde a política em Edit policy com Save. Segundo a Sophos, a atribuição da política instala no dispositivo o certificado raiz carregado. A indicação e a gravação, por si só, não comprovam a confiança, a validade nem uma instalação bem-sucedida. Cada certificado raiz adicional exige uma configuração Root certificate própria na mesma política.

Para Root certificate numa política de utilizador iOS, a Sophos descreve a importação em Edit policy através de Add configuration > Root certificate. Selecione o ficheiro X.509 em PEM/DER com Upload a file e abra-o com Open. Após o carregamento, Certificate name apresenta o Distinguished Name do emissor. Guarde a configuração com Apply e, depois, guarde a política em Edit policy com Save. Adicione uma configuração Root certificate própria para cada certificado raiz adicional. Segundo a Sophos, a atribuição da política de utilizador instala o certificado no dispositivo; dentro da mesma política, pode utilizá-lo, por exemplo, como certificado do servidor EAP no Wi-Fi. A indicação após o carregamento e a política guardada não comprovam uma instalação bem-sucedida, a confiança no certificado nem uma autenticação Wi-Fi funcional.

Na configuração Client certificate da política de dispositivo iOS, selecione primeiro Upload a file em File e depois o ficheiro de certificado PKCS#12 (.pfx). Em Certificate name, o Sophos Mobile apresenta o nome lido do ficheiro de certificado. Esse nome, por si só, não comprova a confiança, a validade nem uma instalação bem-sucedida.

Antes da configuração SCEP: Se utilizar a ligação SCEP configurada em Sophos setup com as variáveis indicadas abaixo, verifique primeiro o procedimento de requisitos SCEP e certificados: acessibilidade do Sophos Fusion à CA, autorizações de firewall limitadas à região e, para este percurso documentado com uma CA Windows, um acesso autorizado para criar desafios e inscrever certificados. Antes de SCEP, disponibilize o certificado da CA do servidor SCEP como Root certificate na mesma política. Esta confiança no servidor é distinta da confiança no servidor RADIUS e da identidade de cliente emitida; isto não afirma que o Windows seja um requisito de todas as implementações SCEP diretas.

O SCEP (Simple Certificate Enrollment Protocol) permite ao dispositivo solicitar um certificado à CA. Para isso, é necessário um URL de CA acessível ou a variável do proxy SCEP da Sophos corretamente configurada. Peça à equipa de PKI que adapte à CA utilizada os campos X.500 do subject e SAN/UPN (nomes de identidade adicionais), o desafio (challenge), os parâmetros de repetição de pedidos pendentes, o comprimento da chave e os bits de utilização. Para a configuração SCEP de uma política de dispositivo iOS, são importantes as seguintes decisões:

• Ponto terminal e nome da CA: URL é o endereço Web do servidor CA. %_SCEPPROXYURL_% remete para o URL do servidor no separador SCEP da página Sophos setup. CA name é um nome que a CA reconhece; pode servir, por exemplo, para distinguir instâncias de CA. Confirme com a equipa de PKI o nome esperado pela própria CA. Este campo não é a indicação Certificate name de um certificado importado nem o nome exemplificativo da CA de confiança do servidor RADIUS.
• Identidade de utilizador ou de dispositivo: Subject pode conter marcadores para dados do utilizador ou propriedades do dispositivo. A Sophos indica CN=%_USERNAME_% para um utilizador e CN=%_DEVPROP(SerialNumber)_% para um iPhone ou iPad. São exemplos de sintaxe documentados, não valores verificados para o seu tenant. Valide a identidade pretendida com a equipa de PKI e verifique se os dados estão disponíveis e se o subject, após a substituição, é um nome X.500 válido. BYOD: A existência de um marcador documentado para o número de série não prova que seja possível resolver uma identidade baseada nesse número no User Enrollment; a Sophos não consegue consultar aí os identificadores do dispositivo. Verifique o subject e a emissão com uma pessoa de teste.
• Tipo e valor de SAN: Em Type of Subject Alternative Name, selecione o tipo aprovado pela equipa de PKI e introduza o valor correspondente em Value of Subject Alternative Name. RFC 822 name designa um endereço de correio eletrónico válido. Para esta configuração SCEP de iOS, a Sophos descreve DNS name como o nome DNS do servidor CA e Uniform resource identifier como o respetivo URL totalmente qualificado — não como o nome do servidor RADIUS nem o endereço do desafio. AD user logon name é distinto e designa o UPN definido no Active Directory. Challenge é o endereço Web onde o dispositivo obtém uma palavra-passe de desafio do servidor SCEP. %_CACHALLENGE_% remete para o URL do desafio configurado no separador SCEP da página Sophos setup, não para a palavra-passe em si. Não inclua segredos reais em exemplos públicos ou tickets.
• Pedidos pendentes: Retries define o número de novas tentativas quando o servidor responde com pending; não é um contador geral de tentativas para todos os erros de rede. Retry delay é o intervalo entre essas tentativas, em segundos. Acorde o número e o intervalo com a equipa de PKI; não os confunda com a renovação do certificado.
• Chave e finalidade: Key size designa o tamanho da chave pública no certificado emitido e tem de coincidir com o tamanho configurado no servidor SCEP. Certificate usage define a finalidade permitida: Use as digital signature para assinaturas digitais e Use for encryption para encriptação de dados. A seleção tem de corresponder aos requisitos de PKI e ao serviço de destino; não comprova uma autenticação Wi-Fi/VPN bem-sucedida nem a encriptação de todo o tráfego do dispositivo.

Na criação da política existe o campo SCEP renewal interval. Verifique o intervalo, a expiração, a revogação e a substituição com a equipa de PKI; definir um intervalo não garante nem a renovação bem-sucedida nem a recuperação de um dispositivo que permaneceu offline.

Substituição de identidade em políticas de dispositivo e de utilizador: No exemplo acima CN=%_USERNAME_%, %_USERNAME_% é substituído por Exchange Login do utilizador atribuído ao dispositivo, não necessariamente pelo seu nome a apresentar nem automaticamente pelo UPN do AD. Verifique a atribuição correta do utilizador e o valor desta propriedade antes da atribuição da política; o subject resultante tem de continuar a ser um nome X.500 válido e aprovado pela equipa de PKI. AD user logon name continua a ser o campo UPN separado.

Para SCEP numa política de utilizador iOS, defina os pontos terminais separadamente. URL é o endereço Web do servidor CA. A variável %_SCEPPROXYURL_% remete para o URL do servidor no separador SCEP da página Sophos setup. Challenge é o URL para obter uma palavra-passe de desafio do servidor SCEP, não a palavra-passe em si. %_CACHALLENGE_% remete para o URL do desafio configurado nesse separador SCEP. Tal como nos parâmetros de pedidos descritos acima, Retries conta apenas as novas tentativas após uma resposta pending; Retry delay indica o intervalo entre elas em segundos. Key size tem de corresponder ao tamanho da chave pública configurado no servidor SCEP. Confirme estes parâmetros com a equipa de PKI; não são intervalos de renovação nem comprovam uma emissão bem-sucedida.

Wi-Fi empresarial e endereço Wi-Fi privado

Para um piloto Wi-Fi de dispositivo isolado, o procedimento seguinte liga os dados da rede à atribuição da política. Garanta previamente a via de rede e de retorno independente descrita na secção do piloto; não edite uma política atribuída em produção.

1. Em Policies, abra a plataforma Apple adequada ao dispositivo de destino, crie uma política de dispositivo com Create e introduza o nome, a descrição e o nome da organização. Em Edit policy, adicione a configuração Wi-Fi com Add configuration e abra o seu nome para a editar. Para Wi-Fi empresarial, disponibilize primeiro os certificados de cliente e raiz necessários na mesma política, como descrito acima; Apply nas configurações de certificado raiz não substitui Save para toda a política.
2. Em SSID, introduza o nome Wi-Fi confirmado pela equipa de rede e ajuste Security type ao método real, incluindo a variante Personal/Enterprise. Personal exige a palavra-passe Wi-Fi; para Enterprise, utilize as definições EAP, de autenticação e de confiança descritas abaixo. Connect automatically estabelece automaticamente a ligação quando a rede está disponível; Hidden network designa uma rede que não difunde o SSID. Escolha ambas as opções apenas de acordo com a rede prevista, não como prova de segurança.
3. Verifique todas as configurações e guarde a política em Edit policy com Save. Para a atribuição posterior, utilize o procedimento «Criar e atribuir uma política»: selecione a política do piloto guardada, marque apenas os dispositivos de teste individuais autorizados e confira a lista e o número antes de Finish. Respeite as ressalvas sobre agendamento e iPadOS aí indicadas. Depois, observe separadamente o estado da tarefa/atribuição, a autenticação Wi-Fi efetiva e o check-in MDM segundo os critérios de verificação abaixo; guardar e atribuir não são resultados de ligação confirmados.

Para a configuração Wi-Fi de uma política de dispositivo iOS, selecione primeiro Security type de acordo com a rede. Uma variante Personal disponibiliza a palavra-passe Wi-Fi. Só uma variante Enterprise disponibiliza Protocols, Authentication e Trusted certificates. Em Accepted EAP types, alinhe os métodos aceites pelo dispositivo com a autenticação da rede, em conjunto com a equipa de RADIUS. Os certificados de cliente e raiz descritos acima continuam vinculados à mesma política.

Em Authentication da política de dispositivo iOS, User é o nome de utilizador Wi-Fi e Password a palavra-passe Wi-Fi para autenticação com credenciais. Segundo a Sophos, Require password on each connect envia a palavra-passe em cada autenticação; a opção não promete um pedido interativo de palavra-passe. Acorde o percurso de credenciais e esta seleção com a equipa de RADIUS. Para autenticação baseada em certificados, selecione antes o Identity certificate adequado de uma configuração Client certificate da mesma política de dispositivo. No dispositivo de teste, verifique a aceitação das credenciais ou do certificado de cliente pelo RADIUS, consoante o método escolhido; a identidade do servidor e a cadeia de confiança continuam a exigir verificação separada em ambos os casos.

No TTLS, Internal identity designa o protocolo de autenticação do utilizador dentro do túnel. Não é a identidade externa. Para EAP-FAST, pode configurar-se uma Protected Access Credential (PAC); este PAC não é um script de configuração automática de proxy. Esclareça com a equipa de RADIUS o protocolo TTLS e, se aplicável, a credencial EAP-FAST, e verifique a autenticação no dispositivo de destino. Sem esse esclarecimento, exclua do piloto o ramo EAP em questão.

Para EAP, defina ambos os limites TLS ou deixe ambos por definir. A Sophos descreve Outer identity para TTLS, PEAP e EAP-FAST e exige uma identidade externa para TLS 1.3. Não utilize aí nomes de utilizador nem segredos, pois a identidade externa é transmitida em texto simples. Se necessário, a equipa de PKI/RADIUS deve verificar uma identidade externa anónima com o realm adequado para o encaminhamento. Observe a autenticação e a versão TLS negociadas no dispositivo de teste; a seleção, por si só, não comprova uma ligação bem-sucedida.

Turn off private address faz com que o dispositivo utilize, nesta rede Wi-Fi, o seu endereço MAC de hardware em vez de um endereço específico da rede gerado pelo iOS. Isto reduz a privacidade. Utilize a opção apenas se for indispensável identificar o dispositivo com o mesmo endereço MAC nas várias redes da organização. Segundo a Sophos, Synchronized Security não funciona com endereços MAC privados: o Sophos Fusion Wireless conhece apenas o endereço privado e o Sophos Mobile apenas o endereço de hardware. No entanto, desativar o endereço privado, por si só, não garante que Synchronized Security funcione; verifique a correspondência e o comportamento pretendido na rede prevista. Não trate esta opção como solução de contorno NAC para BYOD. No User Enrollment, a Sophos não dispõe do endereço MAC para NAC.

Também para Wi-Fi numa política de utilizador iOS, a Sophos distingue Personal e Enterprise em Security type. Personal utiliza a palavra-passe Wi-Fi. Protocols, Authentication e Trusted certificates só estão disponíveis em Enterprise. Para autenticação com credenciais, User é o nome de utilizador Wi-Fi e Password a palavra-passe Wi-Fi. Segundo a Sophos, Require password on each connect envia a palavra-passe em cada autenticação. Acorde esta seleção com a equipa de RADIUS; não a interprete como uma promessa de pedido de palavra-passe ao utilizador. Para autenticação baseada em certificados, selecione antes o Identity certificate adequado de uma configuração Client certificate da mesma política de utilizador. O certificado do servidor em Trusted certificates também exige uma configuração Root certificate nessa política. Utilize o certificado de cliente e a sua aceitação pelo RADIUS como critérios de verificação apenas para o método de autenticação baseado em certificados.

Segundo a descrição de Wi-Fi, as decisões EAP acima também se aplicam a esta política de utilizador. Alinhe Accepted EAP types com a autenticação da rede; para TTLS, esclareça o protocolo em Internal identity e, para EAP-FAST, se aplicável, a Protected Access Credential (PAC). Esta credencial não é um script PAC de proxy. Defina ambos os limites TLS ou deixe ambos por definir. Outer identity está descrita para TTLS, PEAP e EAP-FAST e é obrigatória para TLS 1.3. Respeite as indicações acima sobre texto simples e realm. Não deduza daí que todas as opções estejam disponíveis no seu tenant nem que a autenticação seja bem-sucedida; mantêm-se a exclusão de um proxy Wi-Fi gerido e a ressalva MAC/NAC no User Enrollment.

Proxy e VPN são intervenções diferentes

• Proxy Wi-Fi: Configurável manualmente ou através de PAC (ficheiro com regras de proxy) na política de dispositivo iOS. Com Apple User Enrollment, a configuração Wi-Fi não suporta proxy. A Sophos menciona como alternativa possível o WPAD (descoberta automática de proxy) no ponto de acesso e a seleção, pelo utilizador, da configuração automática do proxy HTTP nas definições de Wi-Fi — não uma configuração de proxy BYOD gerida remotamente. Teste PAC/WPAD, DNS e acessibilidade separadamente.
• Proxy HTTP global: A Sophos só permite esta configuração de dispositivo iOS em dispositivos supervisionados; pode ser manual, com servidor/porta/eventuais credenciais, ou automática, com URL PAC. No modo manual, Server é o nome ou o endereço IP do proxy HTTP e Port é o respetivo número de porta. Authentication é o nome de utilizador para a ligação ao servidor proxy e Password é a palavra-passe correspondente. Não constitui uma promessa de funcionamento em BYOD nem de tolerância a falhas.
• VPN para todo o dispositivo: A política de dispositivo iOS inclui tipo de ligação, servidor e autenticação; para Custom SSL/TLS, a aplicação do fornecedor tem de estar instalada. Não transfira esta configuração para Apple User Enrollment: a Apple não permite nesse modo uma VPN normal para todo o dispositivo.
• VPN por aplicação: Configuração própria para aplicações selecionadas, não equivalente a uma VPN de dispositivo. Verifique separadamente a aplicação do fornecedor, o servidor, a autenticação, eventuais certificados/proxy, On-Demand e as regras de domínio para Safari/outros navegadores, calendário, contactos e correio. Verifique também o âmbito real de Send all traffic through VPN; não deduza do nome isolamento universal das aplicações nem efeito em todo o dispositivo. A documentação da Sophos é inconsistente neste ponto: A descrição da User Policy inclui VPN por aplicação, mas a associação de aplicações refere apenas Device Policies como requisito e opção de seleção. Por isso, não afirme que existe um percurso funcional de associação BYOD na interface: confirme-o primeiro no tenant atual com uma aplicação e um dispositivo de teste.

VPN do dispositivo: fornecedor, autenticação e percurso do tráfego

As indicações seguintes pertencem à configuração VPN de uma política de dispositivo iOS, não à configuração de VPN por aplicação nem a Apple User Enrollment. Verifique a disponibilidade e o suporte do fornecedor no seu tenant. Connection name é o nome da ligação apresentado no dispositivo. Em Server, introduza o nome de host ou o endereço IP do servidor VPN; confirme o ponto terminal adequado com o responsável pela VPN.

• Em Connection type, selecione o fornecedor ou o tipo de ligação adequado. Para uma aplicação de fornecedor VPN da App Store, a Sophos descreve Custom SSL/TLS. A aplicação tem de estar instalada; introduza o seu identificador no formato DNS inverso em Identifier (reverse DNS format). Se o fornecedor definir parâmetros de ligação próprios, registe as chaves e os valores confirmados em Third-party settings, como propriedades da ligação. Não reutilize chaves ou valores de configurações de outros fornecedores.
• User authentication refere-se à autenticação do utilizador. Account é a conta de utilizador da ligação VPN; Group pode indicar um grupo de autenticação necessário para essa ligação. Em Password, indique a palavra-passe VPN; em Certificate, o certificado de autenticação VPN. Esclareça com o responsável pela VPN se é necessário um grupo e que identidade será utilizada. Estas credenciais não são credenciais de proxy.
• Device authentication é distinta. Para Keys (Shared Secret)/Group name, indique o grupo necessário em Group name e a chave partilhada em Keys (Shared Secret). A Sophos menciona ainda Use hybrid authentication e Request password, mas nesta página limita-se a indicar que a seleção depende das necessidades. O efeito e a seleção necessária destas duas opções não estão esclarecidos aqui; só as inclua no piloto após confirmação pelo fornecedor. Em Certificate, selecione o certificado de autenticação do dispositivo necessário. Segundo a Sophos, Including user PIN inclui opcionalmente o PIN do utilizador na autenticação do dispositivo. Não aplique nenhum destes ramos a todos os fornecedores sem verificação nem registe chaves ou PINs reais em tickets.
• Send all traffic through VPN é a definição para encaminhar todo o tráfego através desta ligação VPN. A Sophos descreve que todo o tráfego é enviado pela VPN. No dispositivo de teste, verifique o percurso real do tráfego no modo de fornecedor/túnel escolhido e controle separadamente o canal de retorno MDM. Isto não comprova a captura integral de tráfego nem o isolamento de aplicações.
• Em Proxy, defina o proxy desta ligação VPN. No proxy significa sem proxy de ligação. Para Manually, introduza o endereço e a porta do proxy em Server and port; Authentication é o nome de utilizador do proxy e Password a respetiva palavra-passe. Para Automatic, indique em Proxy server URL o URL do servidor com as definições de proxy. Esta seleção não é o proxy Wi-Fi nem a configuração de proxy HTTP global; não deduza daí um requisito de supervisão nem tolerância a falhas.
• Provider type distingue a camada de transporte, não o fornecedor de Connection type. App proxy transporta tráfego no túnel VPN à camada de aplicação; Packet tunnel, à camada de rede. Assim, App proxy não equivale a VPN por aplicação. É necessário verificar no dispositivo de destino que opção o fornecedor suporta e que tráfego é efetivamente abrangido.

VPN por aplicação: dados de entrada e início da ligação

Para Per app VPN numa política de dispositivo iOS, a Sophos descreve os seguintes dados de entrada e comportamentos; o efeito continua sujeito a verificação no piloto. Estas indicações não resolvem a contradição acima sobre a associação de aplicações em User Policy.

Para Per app VPN, tanto em políticas de dispositivo iOS como em políticas de utilizador iOS, Connection name é o nome da ligação apresentado no dispositivo. Trata-se da designação visível da ligação, não do identificador DNS inverso da aplicação do fornecedor, do endereço do servidor ou da conta de utilizador.

• Aplicação do fornecedor: Se o fornecedor VPN tiver uma aplicação na App Store que disponibilize a ligação VPN, selecione Custom SSL/TLS. Esta aplicação VPN tem de estar instalada no dispositivo; introduza o seu identificador em formato DNS inverso em Identifier (reverse DNS format), não o da aplicação de trabalho cujo tráfego passará pelo túnel.
• Autenticação VPN: Server é o nome de host ou endereço IP do servidor VPN; Account é a conta de utilizador para autenticar a ligação. Em User authentication, selecione Password ou Certificate e indique a palavra-passe VPN em Password ou o certificado de autenticação VPN em Certificate, conforme a escolha. Estes dados são distintos das credenciais de um proxy de ligação.
• Início da ligação: Quando Connect automatically on demand está ativada, segundo a Sophos, o dispositivo ativa a VPN quando a aplicação estabelece uma ligação de rede. Se a opção estiver desativada, os utilizadores têm de ativar a VPN manualmente. Verifique ambos os percursos no dispositivo de teste previsto.
• Proxy de ligação: Proxy disponibiliza No proxy, Manually e Automatic. Na configuração manual, indique o endereço válido e a porta do proxy em Server and port, o nome de utilizador do proxy em Authentication e a respetiva palavra-passe em Password. Na configuração automática, introduza em Proxy server URL o URL do servidor com as definições de proxy. Este é o proxy desta ligação VPN, não a configuração de proxy HTTP global.

Para Domains in Safari, Domains in Calendar, Domains in Contacts e Domains in Mail, aplica-se a mesma sintaxe: um domínio, domínio parcial ou nome de host por linha. Um domínio parcial corresponde quando todos os componentes separados por pontos coincidem a partir da direita; os pontos iniciais e finais são ignorados. Uma cadeia sem pontos corresponde apenas ao host com esse nome, não a quaisquer domínios com essa terminação. Aplica-se ainda a regra adicional de domínio de segundo nível para Calendário, Contactos e Mail; a secção do piloto descreve o teste positivo adequado.

VPN por aplicação na política de utilizador e associação de aplicações

A descrição da Sophos de Per app VPN numa política de utilizador iOS também documenta os dados de entrada explicados acima para a aplicação instalada do fornecedor VPN e o seu identificador DNS inverso, a autenticação com Password ou Certificate, o início da ligação On-Demand, o proxy de ligação e a sintaxe dos domínios. Estas semelhanças documentadas não comprovam um percurso funcional de associação no Apple User Enrollment.

A Sophos documenta os seguintes campos condicionais de Per app VPN tanto em políticas de dispositivo iOS como em políticas de utilizador iOS. As condições aplicam-se a ambos os tipos de política; verifique a disponibilidade e o suporte do fornecedor no próprio tenant:

• Em Third-party settings, podem registar-se as propriedades de ligação definidas pelo fornecedor VPN. O campo só está disponível para Custom SSL/TLS. Utilize Add para introduzir os valores confirmados de Key e Value. Estas propriedades de ligação não são a Managed configuration da aplicação de trabalho cujo tráfego passará pelo túnel.
• Group designa o grupo necessário para a autenticação. O campo só está disponível para Cisco AnyConnect e Cisco Legacy AnyConnect. Não aplique esta condição a outros tipos de ligação.
• Em Provider type, App proxy transporta tráfego no túnel VPN à camada de aplicação; Packet tunnel, à camada de rede. Esta definição não está disponível para Cisco AnyConnect. Verifique no dispositivo de teste previsto que opção o fornecedor suporta e que tráfego é efetivamente abrangido. A camada de transporte, por si só, não comprova o isolamento de aplicações nem um efeito VPN em todo o dispositivo.

A associação de uma ligação existente à aplicação de trabalho faz parte do processo de distribuição de aplicações na secção «Verificar a configuração gerida e o comportamento da aplicação». Aí, atribuir VPN por aplicação está expressamente limitado a políticas de dispositivo existentes. Os responsáveis pelas políticas disponibilizam a ligação adequada; os responsáveis pelas aplicações selecionam-na em VPN connection used by the app. Esta referência não resolve a incerteza acima sobre políticas de utilizador nem autoriza um percurso de associação BYOD não verificado.

Verificar previamente, observar o piloto e delimitar falhas

1. Inventário e via de retorno: Registe propriedade, modo de inscrição, supervisão, versão de iOS/iPadOS, política afetada e associação. Para um dispositivo empresarial supervisionado e um dispositivo BYOD voluntário de teste, identifique em cada caso uma via de rede independente (por exemplo, dados móveis ou outra rede Wi-Fi) e uma pessoa de contacto responsável. Sem essa via, não distribua alterações que possam bloquear o acesso. Para alterações a políticas de dispositivo iOS, use uma política de teste atribuída apenas ao dispositivo empresarial do piloto e, antes de a atualizar, confirme as atribuições atuais e o número de dispositivos abrangidos; não altere uma política já atribuída em produção para realizar o piloto.
2. Dependências: Teste a acessibilidade de DNS, APNs/MDM, CA/SCEP/RA, servidores RADIUS/EAP, PAC/WPAD e ponto terminal VPN antes e depois da alteração. Verifique a cadeia de certificados, os nomes de servidor, a data de expiração e a substituição prevista; não copie chaves privadas, desafios nem credenciais para tickets. Uma atribuição de política válida não prova, por si só, que o Wi-Fi ou a VPN funcionem.
3. Piloto direcionado: Comece por dispositivos de teste separados e uma atribuição mínima. Registe como critérios de verificação, não como resultados confirmados: o dispositivo aceita a identidade verificada do servidor RADIUS e liga-se ao Wi-Fi empresarial. Na autenticação baseada em certificados, verifique também a obtenção do certificado de cliente e a sua aceitação pelo RADIUS; na autenticação com nome de utilizador e palavra-passe, verifique o percurso de credenciais previsto. Para VPN por aplicação, verifique o tráfego do túnel da aplicação de teste gerida e associada; use acessos de outras aplicações como teste negativo apenas se não estiverem sujeitos a outra associação VPN nem corresponderem a uma regra de domínio configurada. Se existirem domínios definidos para Safari/outros navegadores, calendário, contactos ou correio, verifique também os acessos previstos aos domínios correspondentes e não pressuponha genericamente «outros acessos sem túnel». Verifique os domínios de Safari/navegadores à parte: Nos testes positivos com Calendário, Contactos e Mail, a Sophos exige ainda que o domínio de segundo nível do domínio indicado coincida com o do servidor VPN; um domínio diferente não constitui um teste positivo válido do túnel, e a ausência de tráfego por esse domínio, por si só, não prova que a distribuição da VPN falhou. Confirme as regras de domínio no próprio tenant, em vez de as transformar numa receita de configuração não verificada. Verifique separadamente no dispositivo de teste o efeito de Send all traffic through VPN no modo de fornecedor/túnel escolhido; não infira daí efeitos não verificados em todo o dispositivo nem isolamento das aplicações. Com VPN por aplicação numa User Policy, comprove a associação de aplicações efetivamente disponível ou exclua por enquanto essa função. Para PAC/WPAD, observe a via definida para uma falha de Web/proxy; após cada alteração, confirme separadamente um novo check-in MDM e a funcionalidade real da rede. Se não houver check-in ou faltar a via de rede independente, pare o piloto e não associe mais dispositivos.
4. Delimitar falhas: Se o Wi-Fi falhar, verifique primeiro o SSID e o tipo de segurança, o nome do servidor EAP e a CA de confiança; na autenticação com credenciais, verifique o nome de utilizador, a palavra-passe e o percurso de autenticação RADIUS previsto; na autenticação baseada em certificados, verifique a identidade de cliente emitida e a acessibilidade da CA; se a Web falhar, verifique PAC/WPAD/DNS e o acesso ao proxy; se uma aplicação falhar, verifique a aplicação do fornecedor, o túnel, o certificado e a associação. Observe separadamente a tarefa/o check-in e a ligação efetiva. Não provoque uma segunda falha ao remover certificados ou perfis sem controlo.

Reverter sem repor o dispositivo

Antes do piloto, prepare uma política de substituição e uma cadeia de confiança de substituição funcionais com uma rede acessível. Só remova a CA antiga e os certificados de identidade depois de confirmar a substituição no dispositivo de destino e o check-in MDM.

Segundo a Sophos, as alterações a políticas de dispositivo iOS requerem Update devices: esta ação cria uma tarefa de atualização para todos os dispositivos a que a política alterada está atribuída, não apenas para o dispositivo do piloto. Por isso, atualize apenas a política isolada do piloto, depois de verificar os dispositivos atualmente abrangidos; uma tarefa Assign policy direcionada a dispositivos selecionados não é o mesmo que atualizar uma política atribuída a vários dispositivos. A tarefa direcionada Uninstall policy destina-se a Device Enrollment, mas pode ela própria eliminar a via de rede. Para políticas de utilizador iOS em dispositivos com User Enrollment, não existe essa tarefa Uninstall policy: a Sophos disponibiliza em alternativa a tarefa direcionada Unassign iOS user policy. Atualizar ou atribuir outra política também pode ser adequado conforme o tipo de falha. Não confunda a tarefa direcionada com Unassign para todos os dispositivos.

iPadOS: distinguir ações diretas e tipos de tarefa. O guia de políticas explica a nomenclatura inconsistente dos percursos diretos de atualização e desinstalação: a visão geral dos tipos refere iOS/iPadOS, mas os guias diretos referem apenas iOS device policies. Por isso, não transponha a sua sequência de cliques para iPadOS sem verificação; esclareça o percurso direto disponível no tenant e no dispositivo do piloto. Isto não significa que a reversão em iPadOS seja, em geral, indocumentada ou impossível: os tipos de tarefa iOS/iPadOS documentam Uninstall policy para Device Enrollment e Unassign iOS user policy para User Enrollment. O procedimento de pacotes de tarefas conforme o modo descreve esta seleção; continue a verificar separadamente a transmissão da tarefa e o efeito real da reversão.

Teste a reversão separadamente num dispositivo empresarial de teste com Device Enrollment e num dispositivo BYOD de teste com User Enrollment, ambos ainda acessíveis: no dispositivo empresarial, experimente a tarefa direcionada Uninstall policy apenas para esse dispositivo; no BYOD, experimente a tarefa direcionada Unassign iOS user policy. Em cada dispositivo, confirme o estado da tarefa/do check-in e o estado da política efetivamente sincronizado; depois, volte a testar de forma independente o funcionamento de Wi-Fi/VPN e o contacto MDM. Limite quaisquer atribuições ou reversões adicionais aos dispositivos de teste efetivamente verificados até demonstrar as duas vias de retorno. Uma tarefa guardada ou enviada não chega automaticamente a um dispositivo bloqueado e offline. Para esse caso, são necessárias a via de rede independente e a via local de resolução de problemas previamente planeadas; Unassign para todos os dispositivos não é uma medida imediata de baixo risco. Nem a eliminação completa (Wipe) nem o cancelamento do User Enrollment constituem uma reversão geral da política.