Sophos Mobile: verificar certificados SCEP e ligações com segurança

O SCEP permite instalar e renovar certificados no Sophos Mobile (MDM). Este procedimento trata da ligação SCEP ao nível do tenant e dos diferentes percursos de comunicação envolvidos — não da configuração completa de uma CA Windows, de uma infraestrutura Wi-Fi/VPN ou de todos os payloads de políticas Android, Apple e Windows. A instalação e a renovação SCEP segundo este procedimento não suportam Chromebooks.

Antes de qualquer alteração em produção: as equipas responsáveis pela CA/PKI, pela rede e pelo MDM e, se aplicável, pelo serviço de autenticação Wi-Fi/VPN definem em conjunto os dispositivos e modos de inscrição envolvidos, se e como um determinado serviço pode utilizar o certificado SCEP e como manter o acesso aos dispositivos em caso de perda de ligação à rede. Nem Save nem a distribuição de uma política comprovam que um certificado de cliente foi emitido, renovado ou associado a um perfil Wi-Fi/VPN.

Três percursos de comunicação, não uma abertura indiscriminada de portas

O Sophos Fusion liga-se à CA própria com suporte para SCEP; o dispositivo gerido comunica separadamente com o Sophos Mobile. Uma autenticação posterior no serviço Wi-Fi/VPN com esse mesmo certificado SCEP não está automaticamente garantida e tem de ser comprovada para cada plataforma e perfil. Aqui, tenant designa o ambiente Sophos Mobile da organização e MDM a respetiva gestão de dispositivos.

Determinar a região do tenant: no Sophos Fusion, em My Products > Mobile, verificar o URL na barra de endereços do browser. A região encontra-se no primeiro componente do nome do host, ou seja, antes do primeiro ponto, imediatamente após smc-user-if-cloudstation-. No exemplo smc-user-if-cloudstation-eu-west-1, a região é eu-west-1. Para as permissões de acesso, utilizar a região do URL do próprio browser, não o valor de exemplo nem um texto idêntico no caminho do URL ou nos parâmetros de consulta. A região de alojamento é escolhida ao criar a conta Sophos Fusion; para contas existentes, é aqui determinada a partir do URL real no browser. Este host de administração não é um endpoint de dispositivos nem um servidor SCEP. A determinação da região também se aplica ao Mobile Threat Defense, mas não demonstra a existência de uma função SCEP própria do MTD.
Do Fusion para os servidores próprios (entrada): a lista regional atual de IPs de origem para definir a permissão de entrada concreta indica TCP 443 para SCEP e TCP 636 para a ligação LDAP/AD, que é distinta. Permitir exclusivamente os IPs de origem do Mobile atualmente publicados para a região real do tenant e apenas para o destino SCEP ou AD próprio a que se destinam. Não copiar a região de exemplo nem criar uma regra de entrada global ou sem restrições. A ligação LDAP/AD serve para a autenticação de utilizadores com credenciais do AD durante o registo de dispositivos através do Apple Business (anteriormente Apple Business Manager), Google Zero-touch ou Samsung KME. Esta autenticação não é a primeira emissão de um certificado de cliente SCEP para um dispositivo gerido nem a posterior renovação desse certificado.
Do dispositivo para o Sophos Mobile (saída): os dispositivos geridos precisam de HTTPS 443 para o host regional smc-device-if-cloudstation-. Os destinos completos dos dispositivos são smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com para eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com para eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com para us-west-2 e smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com para us-east-2, todos através de HTTPS 443. Utilizar apenas o destino da região real do tenant determinada anteriormente; estes destinos dos dispositivos não são o host de administração nem os destinos SCEP próprios. São também necessárias ligações para notificações push, inscrição e outras funções das plataformas. Os percursos de verificação separados e os guias internos das plataformas apresentados abaixo distinguem essas ligações por tipo de dispositivo e função efetivamente utilizada; os quatro hosts regionais de dispositivos não constituem uma lista completa de destinos de saída. Estes destinos adicionais não são IPs de origem de entrada para SCEP nem uma lista genérica de portas SCEP.

Manter separadas as outras dependências de tráfego de saída dos dispositivos:

Notificações push do Windows: para computadores Windows, estão documentados, para Windows Notification Service (WNS) e Microsoft Push Notification Service (MPNS), os destinos *.notify.windows.com, *.wns.windows.com e *.notify.live.net, todos através de HTTPS 443. Estas são ligações push do Windows, não portas de entrada para SCEP.
Inscrição e aprovisionamento Android: para Android, consultar o guia Android Enterprise e, para os pré-requisitos de QR/Zero-touch/KME, o guia de aprovisionamento; nesses guias, continua a ser necessário verificar as permissões de acesso para o dispositivo e o modo concretos.
Notificações push de gestão Apple: para a gestão de iPhones, iPads e Macs, verificar separadamente o percurso push da Apple; o guia APNs descreve a identidade do certificado, a renovação e a verificação de acessibilidade disponível no iPhone/iPad.
Informações sobre atualizações Apple e conformidade: separadamente, o Sophos Mobile necessita de informações sobre atualizações Apple disponíveis: se o serviço Apple destinado a esse fim não estiver acessível, essas informações ficam em falta e as regras de conformidade relativas a atualizações obrigatórias não têm efeito. Verificar o percurso na própria rede e os limites de plataforma, sistema operativo e inscrição no guia de conformidade. As notificações push de gestão Apple e as informações sobre atualizações são requisitos de tráfego de saída dos dispositivos, não endpoints de entrada SCEP nem de emissão de certificados.
Tráfego da aplicação IXM: para iPhone/iPad com Sophos Intercept X for Mobile (IXM), verificar as ligações separadas da aplicação no guia de rede do IXM; esse guia descreve a correspondência entre serviços e portas e os limites conforme a versão da aplicação, a edição, o tipo de gestão e a função efetivamente utilizada. Estas não são ligações de entrada para SCEP; o título da secção Apple numa lista de ligações de rede não implica que o IXM se aplique a Macs.

Um endereço de destino documentado ainda não comprova a acessibilidade na própria rede.

Em caso de falha, registar separadamente se (a) o Fusion chega ao endpoint SCEP próprio, (b) o dispositivo chega ao Sophos Mobile e recebe a sua política e (c) o serviço Wi-Fi/VPN aceita o certificado emitido. O êxito num destes percursos não dispensa as outras duas verificações.

Definir previamente a confiança e as responsabilidades

Conceitos necessários para a decisão: PKI é a infraestrutura de certificados e CA é a entidade que os emite. O SCEP solicita o certificado de cliente; o Subject e o SAN (Subject Alternative Name), incluindo, se aplicável, o UPN (identificador de utilizador), determinam a identidade a verificar. EAP é um método de autenticação de um serviço Wi-Fi. A importação PKCS-#12 (.pfx) é um método de disponibilização diferente do SCEP; o respetivo certificado não é renovado automaticamente pelo intervalo de renovação SCEP.

Decidir separadamente as três questões de confiança, mesmo que a mesma CA desempenhe várias funções na PKI da organização:

Ligação ao servidor SCEP: antes de SCEP, a equipa de MDM disponibiliza na política adequada uma configuração Root certificate com o certificado da CA do servidor SCEP. Nas políticas de dispositivo Android Enterprise, selecionar também o certificado no campo SCEP Root certificate entre os certificados da mesma política. Este não é o certificado de cliente emitido e não comprova a identidade do cliente.
Identidade de cliente emitida: no Android Enterprise e no iOS, o Subject tem de ser um nome X.500 válido da pessoa ou do dispositivo pretendido depois de substituídos todos os marcadores. Definir separadamente o tipo e o valor do SAN; AD user logon name designa, nos campos SCEP de dispositivo, o UPN do utilizador no AD, não um identificador arbitrário do dispositivo. O campo CA name do iOS é um nome interpretado pela CA, por exemplo para distinguir as suas instâncias — não comprova o emissor nem uma âncora de confiança. Por isso, a equipa de PKI/CA verifica no certificado efetivamente emitido a CA emissora e a cadeia, os valores permitidos de Subject/SAN/UPN, a utilização da chave e o acesso à chave privada. As equipas de MDM e do serviço acordam a correspondência efetiva da identidade com o serviço que utiliza o certificado; não devem copiar marcadores de exemplo.
Confiança do serviço: se o Wi-Fi/VPN utilizar o certificado de cliente, o serviço em questão tem de confiar na respetiva cadeia de CA. No caso de EAP, é ainda necessário verificar se o dispositivo confia no certificado do servidor Wi-Fi. Nenhuma destas verificações decorre apenas da confiança no servidor SCEP.

Responsabilidades antes da aprovação:

Equipa de PKI/CA: verificar a CA Windows com suporte para SCEP, a acessibilidade de /CertSrv/MSCEP_ADMIN e /CertSrv/MSCEP e as permissões para gerar challenges e inscrever certificados. Não guardar palavras-passe de challenge, credenciais de acesso ao serviço ou chaves privadas em tickets ou capturas de ecrã. A referência histórica ao Windows 2003 na documentação da Sophos não é uma garantia atual de suporte para esse servidor.
Equipa de rede: verificar o FQDN de destino, o percurso através de TLS/proxy HTTP e a permissão estritamente limitada dos IPs de origem regionais face à topologia real; verificar separadamente o tráfego de saída dos dispositivos, as notificações push e um percurso independente de gestão/rede para emergências. Não substituir estas verificações pela desativação generalizada dos filtros.
Equipa de MDM e do serviço: definir a plataforma, o tipo de política de dispositivo ou de utilizador e o modo de inscrição antes da configuração. Para o percurso de dispositivos Android Enterprise aqui descrito, utilizar uma Android Enterprise device policy; uma política Work Profile corresponde a um âmbito de gestão diferente. O guia Android Enterprise explica esta decisão sobre o modo. Tratar separadamente o payload SCEP de dispositivo iOS e não o utilizar como prova para políticas de utilizador iOS. Os campos SCEP comuns e específicos de cada plataforma são verificados separadamente no procedimento do piloto abaixo. Parar se o tipo de política não estiver confirmado ou o modo de inscrição não for suportado.

Parar se a identidade pretendida ou a cadeia de confiança da CA não estiver esclarecida, se o tipo de dispositivo ou modo não corresponder à política verificada ou se a gestão do dispositivo depender exclusivamente da rede Wi-Fi/VPN que será alterada e não existir um percurso alternativo independente.

A emissão do certificado não equivale à associação a Wi-Fi/VPN

A configuração SCEP solicita um certificado à CA. Antes de alterar o Wi-Fi/VPN, verificar separadamente:

Campo de seleção de Wi-Fi: nas políticas de dispositivo Android Enterprise e iOS, Identity certificate seleciona um certificado de uma configuração Client certificate da mesma política. Esta configuração importa um ficheiro PKCS-#12 (.pfx); é um método de disponibilização diferente do SCEP. Isto não comprova que seja possível selecionar no campo de Wi-Fi um certificado emitido por SCEP. Uma rede Wi-Fi EAP para Android Enterprise não pode estar oculta: o SSID tem de ser difundido.
Renovação e confiança no servidor: planear separadamente a importação, a validade e a substituição dos certificados PKCS-#12; SCEP renewal interval não os renova automaticamente. O certificado raiz para o servidor EAP na política Wi-Fi não deve ser considerado, por defeito, equivalente à confiança no servidor SCEP.

Também não há uma integração VPN/SCEP uniforme: no Android Enterprise, a política seleciona uma aplicação VPN gerida do Google Play previamente instalada; os parâmetros de ligação ficam na respetiva Managed Configuration. No iOS, a autenticação por certificado e a seleção do certificado dependem do tipo de ligação. Esta seleção, por si só, não comprova que seja possível utilizar um certificado SCEP. Antes de um piloto Wi-Fi/VPN, confirmar a associação suportada do certificado e o comportamento após a renovação para a plataforma, o tipo de política, o método de autenticação e, se aplicável, o cliente VPN, com base em documentação apropriada do fabricante ou num piloto delimitado. Na ausência dessa prova, limitar o piloto à emissão e renovação SCEP; não iniciar uma migração Wi-Fi/VPN nem retirar a cadeia de confiança atual.

Configurar o SCEP apenas num piloto delimitado

Em Setup > Sophos setup > SCEP, acordar com a equipa de PKI o URL do servidor SCEP https://<server>/CertSrv/MSCEP e o URL de challenge https://<server>/CertSrv/MSCEP_ADMIN. Utilizar um utilizador autorizado no formato username@domain e a respetiva palavra-passe; confirmar com a PKI os tipos de caracteres permitidos para o challenge e as permissões. Selecionar os tipos de caracteres acordados no campo Challenge characters para a palavra-passe de challenge antes de executar Save; manter o comprimento de challenge predefinido pela Sophos. Adotar um valor diferente exigido pela PKI apenas como exceção documentada, aprovada e testada em separado. Se estiver ativo um proxy HTTP, Use HTTP proxy aplica-se inicialmente a esta ligação; desativar a opção apenas se se pretender deliberadamente que o Sophos Mobile chegue ao servidor SCEP sem passar pelo proxy.
Executar Save e documentar o teste de ligação ao servidor SCEP. Em caso de erro, verificar o URL, a confiança no certificado, o proxy, as permissões e os IPs de origem permitidos com as equipas responsáveis — não alterar imediatamente políticas de forma generalizada.
Primeiro, criar uma política ou editar uma política existente adequada ao modo do piloto. Para criar a política, editar as configurações, guardar e depois atribuir a política ao piloto, consultar o guia de políticas; verificar previamente a plataforma e o tipo de política suportado. Nessa política, configurar primeiro Root certificate com o certificado da CA do servidor SCEP e depois SCEP e SCEP renewal interval. Para os campos SCEP URL e Challenge, a documentação das políticas de dispositivo Android Enterprise e iOS descreve, respetivamente, os marcadores %_SCEPPROXYURL_% e %_CACHALLENGE_% para os URLs de servidor SCEP e de challenge previamente configurados; acordar Subject, SAN/UPN, tamanho da chave e finalidade de utilização com a PKI e o serviço de destino para a plataforma concreta. Atribuir a política apenas ao grupo delimitado do piloto. A PKI e a equipa de MDM definem previamente, para essa plataforma e esse modo de política específicos, onde podem observar a entrega da política, o certificado no dispositivo e a emissão/renovação na PKI; se a associação a Wi-Fi/VPN também estiver comprovada, definir igualmente o log do serviço. Não pressupor os mesmos campos de estado nem os mesmos nomes de logs em todos os dispositivos. SCEP renewal interval determina quando o dispositivo faz o pedido, não se este tem êxito.
Campos SCEP específicos de cada plataforma: nas políticas de dispositivo Android Enterprise, definir um Alias name reconhecível para os diálogos de seleção e selecionar, no campo Root certificate, o certificado da CA do servidor SCEP da mesma política. Nas políticas de dispositivo iOS, acordar CA name com a CA; Retries conta as novas tentativas após uma resposta pending do servidor e Retry delay define o intervalo em segundos. Não apresentar estes campos iOS como campos Android. Key size tem de corresponder à configuração do servidor SCEP. Em Certificate usage, acordar separadamente com a PKI e o serviço a utilização pretendida como Use as digital signature ou Use for encryption; não inventar um tamanho ou uma seleção predefinidos.
Para Type of Subject Alternative Name e Value of Subject Alternative Name, verificar separadamente o tipo e o valor documentados: RFC 822 name para um endereço de e-mail válido, DNS name para o nome DNS do servidor da CA ou Uniform resource identifier para o respetivo URL completo. AD user logon name continua a ser o UPN do utilizador no AD. A descrição dos campos não substitui a verificação da identidade no certificado efetivamente emitido.
Primeira emissão após a entrega da política: no dispositivo piloto, comparar o emissor/cadeia, o Subject e o SAN/UPN, o número de série, as datas de início/fim da validade e a utilização da chave com as especificações aprovadas pela PKI. O registo de um dispositivo no AD não conta como emissão de um certificado de cliente SCEP. Sem emissão observada: parar e não aprovar a rotação.
Renovação posterior: a PKI e a equipa de MDM definem um período de observação a partir do intervalo e da validade do certificado. Nesse período, verificar no dispositivo um novo certificado válido, com novo número de série e valores de identidade/emissor adequados, bem como a operação confirmada na PKI. Se a renovação não for observável ou não ocorrer durante o piloto, não aprovar a rotação como validada.
Apenas se a associação a Wi-Fi/VPN estiver comprovada no piloto: no log do serviço utilizado, associar a autenticação bem-sucedida antes e depois da renovação àquele dispositivo piloto e certificado concretos. Sem log do serviço ou associação confirmada: não alterar o Wi-Fi/VPN.

Rotação e via de recuperação

Antes de alterar o URL SCEP, as credenciais de challenge ou a CA, ou de efetuar uma alteração de perfil Wi-Fi/VPN comprovada separadamente, registar no protocolo do piloto, para cada classe de dispositivos, as atribuições das políticas antiga e nova, as âncoras de confiança e os grupos afetados. As equipas de PKI, rede e MDM definem o percurso de gestão efetivamente acessível e independente da rede baseada no certificado que vai ser alterado, o responsável local pela recuperação e o critério de paragem. O método concreto de reatribuição ou remoção de uma política e o respetivo efeito nos dispositivos têm de ser validados no piloto para a plataforma e o modo de inscrição; não se presume aqui um procedimento de reposição universal. Segundo a Sophos, Uninstall policy só está disponível para políticas de dispositivo Android, de contentor Knox e de dispositivo iOS; para outros tipos, incluindo políticas de dispositivo Android Enterprise, deve atualizar-se a política ou atribuir-se outra. Isso não comprova que uma CA ou um certificado de cliente já instalado seja removido ou restaurado.

Decisão antes da implementação geral: disponibilizar primeiro a nova cadeia de confiança no piloto apenas se o modo concreto permitir a distribuição em paralelo. Verificar a nova emissão e uma renovação posterior efetiva. Caso esteja prevista uma alteração de Wi-Fi/VPN, verificar também a associação comprovada ao perfil e a autenticação no serviço antes e depois da renovação. Só após a aceitação controlada e o planeamento da implementação devem ser removidos os perfis/âncoras de confiança antigos. Não retirar prematuramente a CA antiga se ainda for necessária para as ligações existentes.

Em caso de falha, decidir consoante a acessibilidade do dispositivo:

Parar todas as novas atribuições e remoções de políticas, perfis e âncoras de confiança. Manter a CA, os perfis e as âncoras de confiança anteriores; envolver as equipas responsáveis pela PKI, rede e MDM com base no protocolo do piloto.
Dispositivo acessível pelo percurso independente verificado: a equipa de MDM repõe a associação documentada à política/rede/CA anterior pelo método de atribuição/remoção previamente validado para este modo; a PKI e a equipa de rede verificam a sua parte. Se o Wi-Fi/VPN tiver sido alterado, testar novamente a autenticação no log do serviço.
Dispositivo offline ou sem percurso independente: o responsável local pela recuperação, previamente designado, utiliza exclusivamente o procedimento local de recuperação anteriormente planeado e testado; em seguida, volta a testar a acessibilidade e, se aplicável, a autenticação no serviço. A simples reposição de uma definição na cloud não constitui um rollback comprovado para dispositivos que ficaram offline. Se o procedimento local não tiver sido comprovado, não afirmar que existe uma recuperação remota segura nem alargar a alteração.

Sem primeira emissão observada, renovação e via de recuperação verificada, a alteração SCEP em produção permanece bloqueada; uma alteração de Wi-Fi/VPN exige adicionalmente uma associação comprovada do certificado e a sua utilização bem-sucedida antes e depois da renovação.

Limite da validação: este é um rascunho baseado em fontes, não testado no tenant nem em dispositivos. As versões de SO/servidor suportadas, o comportamento do cliente na renovação offline e a correspondência concreta da identidade em EAP/VPN têm de ser confirmados separadamente no ambiente da organização.