Gestão de dispositivos móveis: configuração e prova

A gestão de dispositivos só apoia a segurança nos dispositivos e nas definições que efetivamente abrange. Um painel de MDM que mostra dispositivos conformes exige uma segunda pergunta: que dispositivos estão em falta? Segue-se uma terceira: «conforme» descreve uma configuração eficaz ou apenas uma política atribuída a um equipamento terminal?

Para um CTO, a tarefa consiste em tornar estas respostas reproduzíveis. A gestão de dispositivos móveis deve ligar a propriedade dos dispositivos, a configuração, o acesso às aplicações, a resposta a incidentes e as evidências. O objetivo não é um painel verde. É uma explicação defensável de que equipamentos terminais podem aceder a informação de negócio, como estão protegidos e o que acontece quando a proteção falha.

O que o MDM controla, e o que não controla

A gestão de dispositivos móveis (MDM) é a administração de equipamentos terminais através de um serviço central e de mecanismos de gestão suportados pela plataforma. Consoante o produto, o sistema operativo e o modo de inscrição, pode implementar perfis de configuração, distribuir aplicações, reportar o estado dos dispositivos, restringir determinadas funções e emitir comandos remotos. Os produtos mais amplos de gestão de equipamentos terminais podem incluir portáteis e computadores de secretária a par de telemóveis e tablets.

Estas capacidades não são uniformes. Um telemóvel empresarial totalmente gerido e um telemóvel pessoal com um perfil de trabalho gerido expõem controlos e telemetria diferentes. Algumas plataformas utilizam serviços de gestão integrados; outras exigem agentes adicionais. Não se deve presumir nem conectividade contínua nem execução imediata.

O MDM também não substitui a gestão de identidades, a deteção em equipamentos terminais, a gestão de vulnerabilidades nem a classificação da informação. Pode configurar esses controlos ou fornecer-lhes sinais, mas o seu funcionamento exige uma verificação separada. Um dispositivo gerido pode, ainda assim, ter permissões de aplicações excessivas, uma sessão não revogada ou uma aplicação vulnerável.

Antes de selecionar definições, defina a afirmação de controlo. Por exemplo: «Os portáteis da empresa que acedem ao ambiente de administração de produção têm de estar inscritos, cifrados, ser suportados e ter sido avaliados recentemente.» Esta afirmação identifica uma população, um recurso e condições observáveis. «Todos os dispositivos são seguros» não o faz.

Ligar a gestão de equipamentos terminais ao SGSI

A ISO/IEC 27001 diz respeito a um sistema de gestão da segurança da informação com âmbito definido e não à aquisição de uma determinada ferramenta para equipamentos terminais. As suas cláusulas 4 a 10 estabelecem os requisitos do sistema de gestão. O Anexo A fornece um conjunto de referência de 93 controlos cuja aplicabilidade é ponderada através da avaliação e do tratamento de riscos; não é uma lista de verificação universal de configuração de MDM.

A Declaração de Aplicabilidade regista os controlos necessários, a justificação da sua inclusão, o estado de implementação e a justificação para a exclusão de controlos do Anexo A. Uma implementação de MDM fornece parte da implementação e das evidências dos controlos relevantes, em vez de provar todo o SGSI.

As ligações úteis incluem:

Estes mapeamentos descrevem contributos e não equivalências. Por exemplo, implementar uma configuração de início de sessão não demonstra que o acesso privilegiado foi devidamente aprovado. Utilize o nosso guia do Anexo A para ligar as medidas para equipamentos terminais ao SGSI mais amplo, em vez de tratar a conformidade dos dispositivos como uma pontuação isolada.

Definir a população antes de medir a conformidade

Comece pelos dispositivos que armazenam, processam ou acedem a informação dentro do âmbito do SGSI. Inclua, quando relevante, equipamento da empresa e equipamento pessoal, equipamentos terminais de prestadores de serviços, dispositivos partilhados e dispositivos de empréstimo temporário. Acorde os sistemas operativos suportados, as regras de inscrição e os limites de privacidade.

Construa o inventário em torno de identificadores estáveis e não apenas de nomes de apresentação. Os campos úteis incluem o identificador do ativo, o identificador de gestão, o utilizador atribuído, a propriedade, a plataforma, o modo de inscrição, a finalidade de negócio, a data de inscrição, o último contacto e o estado de abate. Registe explicitamente os responsáveis pela guarda dos dispositivos partilhados.

Concilie o inventário do MDM com fontes independentes. Os registos de aquisição de ativos revelam equipamentos que nunca foram inscritos. Os registos de início de sessão do fornecedor de identidades e os registos de acesso às aplicações podem revelar equipamentos terminais ausentes da gestão. Os registos de proteção de equipamentos terminais podem expor agentes duplicados ou dispositivos geridos noutro sistema. Verifique que identificadores cada fonte fornece efetivamente antes de tentar cruzá-las.

Classifique as discrepâncias em vez de as excluir silenciosamente:

• No âmbito e inscrito: avaliar a configuração e a atualidade da informação.
• No âmbito mas não gerido: inscrever, restringir o acesso ou aprovar uma exceção delimitada.
• Abatido mas ainda ativo: investigar e revogar os acessos residuais.
• Duplicado ou reinstalado: conciliar os registos sem perder evidência histórica.
• Fora do âmbito: documentar o motivo e a fronteira que impede o acesso relevante.

O denominador importa. «98 % conformes» entre os dispositivos inscritos pode ocultar uma população substancial de dispositivos não geridos. Reporte a cobertura separadamente da conformidade da configuração e conserve a data da conciliação e os registos por resolver.

Construir uma linha de base que possa ser testada

Uma linha de base para equipamentos terminais deve traduzir as decisões de risco em definições e critérios de verificação. Deve distinguir plataformas e modelos de propriedade, em vez de fingir que todas as definições funcionam em todo o lado.

O que se segue é um ponto de partida prático e não uma lista de verificação universal imposta por lei ou pela ISO:

Defina o que significa «desconhecido». Um equipamento terminal que não reportou o estado da cifragem não está comprovadamente cifrado. Trate a telemetria em falta ou desatualizada como um estado separado com uma resposta clara, em vez de a converter num resultado positivo.

As janelas de atualização devem refletir a gravidade das vulnerabilidades, a exposição, as mitigações disponíveis e as restrições operacionais. Documente o tratamento de emergência de vulnerabilidades ativamente exploradas e um processo para atualizações que danifiquem aplicações essenciais. Os relatórios de implementação do MDM ajudam a determinar o estado da instalação; não explicam, por si só, se o risco de vulnerabilidades por resolver é aceitável.

Nas aplicações, distinga a distribuição do controlo. Instalar uma aplicação aprovada não impede os utilizadores de instalar alternativas, a menos que a plataforma e a configuração suportem essa restrição. Defina quem pode aprovar software, o que exige avaliação e como são removidas as aplicações obsoletas ou proibidas.

Cada exceção à linha de base precisa de um responsável, dos dispositivos afetados, de um motivo de negócio, de uma avaliação de risco, de medidas compensatórias, de aprovação e de uma data de expiração. Um sistema operativo não suportado com acesso irrestrito a dados sensíveis não deve permanecer indefinidamente ao abrigo de uma nota genérica de «requisito de negócio».

Implementar a configuração sem confundir atribuição com sucesso

Utilize um grupo piloto que represente cada plataforma, modo de propriedade e caso de utilização de negócio importantes. Teste o trabalho normal, as viagens, o comportamento sem ligação e a recuperação, e não apenas uma inscrição bem-sucedida na secretária de um administrador.

Antes de uma implementação alargada, estabeleça os pré-requisitos de gestão: funções de administrador, permissões de inscrição, certificados ou credenciais de serviço necessários e a responsabilidade pela sua renovação. Um serviço de gestão pode perder eficácia quando um certificado expira, mesmo que os documentos de política permaneçam inalterados.

Acompanhe a configuração através de estados distintos: direcionada, entregue, aplicada, avaliada e eficaz. Quando a plataforma expõe menos fases, documente essa limitação e acrescente um método de verificação seguro. Analise perfis em conflito, agentes desatualizados, definições não suportadas e ações dos utilizadores que impedem a conclusão.

Utilize uma implementação faseada com um percurso aprovado de reversão ou recuperação. Registe a versão da linha de base, os grupos visados, os resultados do piloto, a aprovação e as falhas de implementação. Uma captura de ecrã de um editor de políticas prova as definições pretendidas; os relatórios dos dispositivos e os testes determinam se essas definições funcionaram.

Proteja o próprio plano de gestão. Utilize contas de administrador nominativas, autenticação forte adequada, funções de privilégio mínimo e registo de eventos. Limite os privilégios de apagamento em massa e de alteração de configurações. Reveja os administradores e as credenciais de serviço, porque o comprometimento do serviço de gestão pode afetar muitos equipamentos terminais em simultâneo.

Verificar a cifragem e a recuperação separadamente

Nos portáteis, verifique a proteção de armazenamento implementada e não apenas uma política de «ativar a cifragem». Nos telemóveis e tablets, compreenda o modelo de cifragem do sistema operativo, o comportamento no estado bloqueado e a visibilidade da gestão. A cifragem em repouso e o transporte cifrado na rede são afirmações distintas.

Decida que armazenamento local está abrangido, se os suportes amovíveis são permitidos e como pode a informação de negócio sair das aplicações geridas. Um disco de sistema protegido não protege automaticamente um ficheiro exportado para uma unidade externa não cifrada.

Os mecanismos de recuperação precisam da sua própria conceção de controlo. Determine onde é guardado o material de recuperação, quem o pode obter, como é autorizada e registada essa obtenção e quando é necessária a rotação ou substituição. Não coloque segredos de recuperação em evidências de auditoria gerais nem em pedidos ao helpdesk.

Teste a recuperação num equipamento terminal de teste designado, utilizando um procedimento aprovado. Preserve a autorização e o resultado, não o segredo. Um campo na consola que mostra que uma chave existe não prova que o pessoal autorizado consegue recuperar o dispositivo quando necessário.

A proteção da rede depende também da configuração das aplicações e dos serviços. O MDM pode distribuir certificados ou definições de rede, mas não consegue demonstrar que todas as aplicações utilizam ligações cifradas configuradas de forma adequada. Para o ciclo de vida mais amplo, consulte cifragem e gestão de chaves.

Ligar o estado do dispositivo às decisões de acesso

Um sinal de conformidade tem valor limitado se os equipamentos terminais não conformes mantiverem acesso irrestrito. Quando suportado, ligue a informação de confiança ou de conformidade do dispositivo aos controlos de acesso de identidades e de aplicações. Determine com precisão que recursos aplicam a condição e que percursos de acesso a contornam.

Teste, quando aplicável, o acesso pelo browser, as aplicações nativas, a administração remota, a autenticação legada e as sessões existentes. Um browser não gerido pode ser bloqueado enquanto um cliente previamente autorizado continua a funcionar. O comportamento da revogação de sessões e a atualidade dos sinais exigem testes explícitos.

Utilize restrições baseadas no risco. Os sistemas administrativos sensíveis podem exigir condições mais rigorosas para os equipamentos terminais do que os recursos de colaboração de baixo risco. Defina procedimentos de acesso de emergência e de recuperação para que uma falha do serviço de conformidade não produza vias de contorno permanentes e não documentadas.

A autenticação para desbloquear o dispositivo não é o mesmo que a autenticação nas aplicações. O bloqueio de ecrã protege um equipamento terminal sem vigilância; a autenticação multifator e a autorização protegem o acesso aos recursos. O MDM pode apoiar a configuração, mas a evidência do fornecedor de identidades e das aplicações tem de sustentar essas afirmações distintas.

Tratar deliberadamente os dispositivos pessoais, as perdas e as saídas

Para os dispositivos pessoais, decida se a gestão abrange o dispositivo completo, um perfil de trabalho, apenas as aplicações ou se não está disponível. Explique o que os administradores podem ver, o que podem alterar, que informação de negócio é recolhida e o que pode ser removido. Não presuma que o rastreio da localização ou a visibilidade das aplicações pessoais são necessários ou estão disponíveis.

Quando a telemetria dos dispositivos dos trabalhadores envolva dados pessoais, avalie as obrigações de privacidade aplicáveis. O RGPD exige um fundamento de licitude e o respeito pelos princípios de tratamento relevantes; o artigo 32.º adota uma abordagem à segurança baseada no risco, em vez de impor a cifragem generalizada em todas as circunstâncias. Não se deve presumir que o consentimento dos trabalhadores é suficiente. Obtenha uma revisão adequada em matéria de privacidade e de direito do trabalho para os procedimentos de monitorização e de remoção.

Separe a remoção seletiva dos dados de negócio do apagamento completo do dispositivo. Confirme o comportamento suportado para cada modo de inscrição e comunique-o antes da inscrição. A remoção de um perfil de trabalho pode deixar os dados pessoais intactos, ao passo que um apagamento completo tem consequências materialmente diferentes.

Perante um dispositivo perdido, a resposta deve identificar o equipamento terminal e o utilizador, avaliar a exposição, restringir o acesso, revogar as sessões ou credenciais relevantes, emitir os comandos suportados de bloqueio ou apagamento e registar os resultados. O apagamento remoto depende da conectividade e das capacidades da plataforma. «Comando em fila» não é «dados removidos».

Os procedimentos de saída devem abordar tanto a devolução do dispositivo como o acesso à informação. Revogue o acesso independentemente de o dispositivo ser recuperado. Remova os perfis de negócio quando adequado, preserve a informação sujeita a requisitos de conservação e só abata os registos do inventário após as verificações necessárias. Teste estes processos num âmbito seguro, com contas e dispositivos de teste.

Preservar evidência que sustente uma afirmação delimitada

Um conjunto de evidências deve permitir a um revisor reconstruir o que esteve protegido durante um período declarado. Preserve exportações datadas, contagens da população, decisões sobre exceções e registos de remediação. Inclua contexto suficiente para distinguir uma avaliação pontual de evidência de funcionamento contínuo.

Os resultados úteis incluem:

• Âmbito e conciliação do inventário, incluindo os dispositivos não geridos por resolver.
• Versões aprovadas da linha de base e definições específicas de cada plataforma.
• Exportações do estado dos dispositivos com identificadores, inscrição, último contacto e configuração efetiva.
• Aprovações de exceções com datas de expiração e medidas compensatórias.
• Falhas de implementação, pedidos de remediação e verificação do seu encerramento.
• Registos de testes de recuperação, de recusa de acesso, de dispositivos perdidos e de saídas.
• Decisões de revisão periódica e ações de seguimento atribuídas.

Documente os filtros de exportação, o momento da recolha e a interpretação dos campos de estado. Proteja as exportações de forma adequada, porque podem conter identificadores pessoais ou pormenores sensíveis da infraestrutura. As capturas de ecrã podem explicar a configuração, mas as exportações pesquisáveis são normalmente mais úteis para a análise da população.

Recolha amostras ao longo dos riscos e dos modos de falha, e não apenas de dispositivos saudáveis. Inclua diferentes plataformas, inscrições recentes, utilizadores privilegiados, equipamentos terminais desatualizados e exceções aprovadas. Um relatório atual não consegue reconstruir um período de revisão anterior, a menos que os registos históricos tenham sido conservados.

As revisões periódicas da cobertura devem incluir os dispositivos recém-integrados e a evolução dos padrões de acesso. As métricas operacionais úteis incluem a cobertura de inscrição, a conformidade com a linha de base avaliada, os reportes desatualizados, as exceções expiradas e a antiguidade das remediações. Defina cada denominador e cada limiar. A monitorização contínua de controlos fornece contexto adicional para distinguir sinais de conclusões revistas.

Exemplo prático: revisão de um parque misto

Os números e limiares seguintes são pressupostos ilustrativos e não referências do setor.

Uma empresa identifica 120 portáteis empresariais e 30 telemóveis pessoais autorizados para o correio eletrónico profissional. A sua linha de base para portáteis exige inscrição, cifragem, um sistema operativo suportado, bloqueio de ecrã e uma avaliação bem-sucedida nos últimos sete dias. Os telemóveis pessoais exigem um perfil de trabalho gerido e software suportado; a gestão completa do dispositivo está fora do limite de privacidade aprovado.

A consola do MDM contém 116 portáteis. Destes, 108 cumprem a linha de base, quatro reportam atualizações em atraso, dois têm avaliações desatualizadas e dois mostram falhas de cifragem. Os restantes quatro portáteis estão ausentes da gestão.

Reportar apenas o resultado da consola dá 108 em 116, aproximadamente 93 % de conformidade com a linha de base. Face à população de portáteis estabelecida, 108 em 120, ou seja 90 %, cumprem comprovadamente a linha de base. A cobertura de inscrição é de aproximadamente 97 %. São métricas diferentes, e nenhuma prova os controlos dos telemóveis pessoais.

Os registos de identidade mostram que dois portáteis não geridos acederam a uma aplicação sensível. A equipa restringe esse acesso, investiga a propriedade e inscreve os dispositivos. Confirma-se que os outros dois foram abatidos; a evidência da revogação e da eliminação sustenta a sua remoção da população ativa.

Quanto aos telemóveis, três utilizadores têm acesso ao correio eletrónico sem o perfil de trabalho exigido. O seu acesso é restringido até à inscrição ou à conclusão de uma alternativa aprovada. Um telemóvel de teste confirma que a remoção seletiva elimina o perfil de trabalho sem apagar o conteúdo pessoal.

O registo da revisão conserva a população original, as alterações da conciliação, as falhas, as restrições de acesso e a remediação verificada. Não substitui a avaliação inicial falhada por uma captura de ecrã limpa posterior.

Facilitar a próxima revisão

Os erros comuns são operacionais: contar apenas os equipamentos terminais inscritos, confiar na atribuição de políticas, aceitar telemetria desatualizada, deixar exceções em aberto e tratar comandos remotos como ações concluídas. Cada um pode ser resolvido através de uma população definida, de um tratamento explícito dos estados e de verificações datadas.

A Secani pode organizar este trabalho em torno dos sistemas, requisitos, responsáveis e evidências relevantes. Carregue documentos da linha de base, exportações datadas do MDM e registos de testes; ligue-os aos controlos ou decisões que sustentam; e transforme a evidência em falta ou as falhas por resolver em tarefas atribuídas. Preserve a revisão humana, a aprovação e o contexto das fontes para as conclusões materiais. O MDM continua a ser a ferramenta operacional de gestão de equipamentos terminais; o espaço de trabalho de conformidade preserva o contexto de implementação e as decisões de revisão.

Um próximo passo prático é selecionar uma aplicação sensível e conciliar todos os equipamentos terminais que lhe acedem com os registos de gestão. Teste um equipamento terminal saudável, um não gerido e um desatualizado. Registe os resultados de acesso e a evidência de configuração e, depois, atribua cada discrepância por explicar a um responsável. Este pequeno exercício testa em conjunto a cobertura, a aplicação e a prova.