Você sabia que o Android disponibiliza suporte para gerenciamento de dispositivos móveis desde a versão 2.2, lançada em 2010? Desde então, as empresas evoluíram e novas necessidades surgiram.

Atualmente, a utilização de dispositivos móveis é uma ferramenta estratégica para as empresas, possibilitando cada vez mais acesso a informações confidenciais.

No material abaixo você encontrará orientações sobre as melhores formas de implementação deste recurso, além de entender porque o Android Enterprise oferece os recursos mais seguros e adequados para o gerenciamento de aparelhos corporativos.

Evoluindo do Device Admin para o Device Owner

O Device Admin possibilitou a implementação de diversas configurações corporativas, permitindo que as empresas fizessem uma gestão avançada sobre os dispositivos.

Com a evolução da mobilidade empresarial, a exigência por recursos mais seguros foi além dos já disponibilizados, como: redefinição segura de senhas, separação de dados em implantações BYOD, distribuição de aplicativos de negócios, gerenciamento de dados através do Google Play e remoção do administrador do dispositivo.

Para evoluir e seguir as novas demandas do mercado, através de um comunicado oficial, a Google anunciou que a partir do Android 5.0, o Device Admin não será mais adequado para dar suporte aos requisitos empresariais atuais. A recomendação é para que as implantações sejam feitas já com o Device Owner.

“O uso do Device Admin foi suspenso a partir da versão do Android 9.0 e todas as funcionalidades assinaladas pela Google foram removidas definitivamente na versão Android 10.0.”

Fonte: https://developers.google.com/android/work/device-admin-deprecation

Mudanças de permissões de recursos do Device Admin para Device Owner

Quando a Google fez o movimento para “aposentar” o Device Admin, a cada versão de Android mais recursos do DA são marcados como obsoletos e migrados para o Device Owner.

Um exemplo é a função “Políticas de Senha”, que atualmente está disponível no Device Admin, somente para os aparelhos com versões mais antigas do Android.

Quando uma nova versão do Android, que ainda utiliza o Device Admin, tenta acessar a mesma funcionalidade, a permissão de acesso é negada em função das atualizações da Google, pois o recurso já foi atribuído ao Device Owner.

Já os aparelhos que utilizam versões mais recentes do Android e o Device Owner, conseguem acessar todos os recursos do Device Admin e também todas as novas funcionalidades oferecidas pelo Device Owner.

O que o AE nos entrega na prática?

O AE possibilita o gerenciamento de mobilidade empresarial (EMM), através de recursos integrados aos dispositivos Android e ao Google Play, oferecendo flexibilidade e suporte a uma variedade de cenários de negócios. Confira alguns recursos de gerenciamento:

Definir requisitos mínimos de senha para o desbloqueio de dispositivos
Bloquear e excluir dispositivos remotamente
Bloquear dispositivos que não estejam em conformidade de maneira automática
Distribuir e gerenciar apps remotos
Definir respostas para permissões de tempo de execução
Bloquear o dispositivo para apps e impedir que os usuários acessem a tela inicial, as configurações etc.
Programar atualizações do sistema over the air (OTA)

É possível ativar o Device Owner sem o AE?

Por ser um processo mais demorado e arriscado, exigir um conhecimento técnico maior e interromper as operações da empresa, já que os aparelhos precisam ser recolhidos para que TI execute a ativação manualmente, não é o mais indicado.

Os dispositivos não podem ter contas Gmail vinculadas e o modo de desenvolvedor precisa ser habilitado, o que pode expor a segurança do dispositivo.

Como é um processo via cabo, é necessário que seja feito através de um computador com ADB, recurso do Android que permite a execução de diversos comandos em um dispositivo, como configurar ou instalar alguma coisa no aparelho.

Mas e o AE? Não era obrigatório depois que a Google removeu o Device Admin?

O AE é o único modo atualizado para gerenciamento de dispositivos móveis corporativos amplamente aceito, independente do fabricante do aparelho.

Este é o recurso que a Google mais tem investido, e a cada atualização lança mais funcionalidades estratégicas, melhorando a segurança para os usuários, além de migrar os recursos já existentes no Device Admin para o Device Owner.

Se o Android é atualizado no aparelho, mas o mesmo ainda utiliza o Device Admin, ele perderá permissões de funcionalidades a cada upgrade da Google.

Por isso, é fundamental que os aparelhos passem a ser configurados como Device Owner, seja por AFW, NFC ou via cabo. Explicaremos melhor as formas de implementação mais a frente.

Os recursos que estão habilitados nos dispositivos configurados como Device Admin, poderão não funcionar após a próxima atualização da versão do Android, e isso causará grandes problemas na gestão de dispositivos móveis das empresas, já que deixariam de ter acesso a funcionalidades importantes como:

• Desabilitar recursos na tela de bloqueio nativa
• Atribuir configurações/políticas de senha
• Bloquear o dispositivo
• Realizar o reset de fábrica remotamente

Confira alguns recursos exclusivos disponíveis no Device Owner:

FRP (Proteção por conta para redefinição de fábrica, exigindo que uma senha seja inserida em caso de hard reset)
Desabilitar o reset de fábrica
Desabilitar ancoragem/tethering
Desabilitar captura de tela
Impedir que o usuário adicione/remova contas pessoais no dispositivo
Configurar firewall
Definir política de senha
Desabilitar gestão de certificados pelo usuário (na keystore)
Cadastrar/remover certificados no dispositivo
Bloquear a barra de notificações
Wifi manager

Vale destacar que dispositivos com API da fabricante, como é o caso da Samsung, ainda permitem alguma gerência sem o Device Owner, mas à medida que o Android Enterprise evolui, o acesso aos recursos também estão sendo removidos.

Como funciona na Pulsus?

Utilizando um dispositivo compatível (GMS – Google Mobile Service), os especialistas da Pulsus indicam a formatação através dos recursos Zero Touch, QRCode e AFW#pulsus.mobi, que são mais rápidos e seguros.

Implementações que recomendamos:

Zero touch Enrollment – Registro do agente Pulsus sem toque, ou seja, o dispositivo pode ser entregue na caixa para o usuário final; método recomendado de implementação.
Ativação AFW#pulsus.mobi – Método disponível para quando o dispositivo não possuir câmera ou leitor de QR Code, compatibilidade com NFC ou versão de Android não compatível com os demais métodos de provisionamento. O enroll via identifier tem uma cobertura maior de versão de Android.
Ativação por NFC e QR Code – Diferente dos demais métodos de provisionamento, esse possibilita configurar parâmetros reduzindo a interação com o dispositivo no registro. Exemplo: É possível passar uma rede Wifi via QR Code tornando a conexão da rede automatizada.
Instalação de Apps da Google Play Store – Único método disponível para distribuir aplicativos para os dispositivos no AE, sendo a forma mais segura atualmente de gerenciar apps corporativos.

Em todos os cenários de implantação acima, o usuário não precisa fazer login com uma conta de e-mail. Esta conta será gerada automaticamente pela solução Pulsus.

Exceções – Instalação de forma assistida

Para clientes que possuem muitos dados e não podem fazer a limpeza do sistema operacional, a melhor orientação é que alguns dados sejam salvos antes de o processo manual ser feito.

Quando o dispositivo não tem a suite da Google, que é o caso da fabricante Huawei e máquinas de cartão de crédito, que por questões de segurança não podem ter esse ecossistema, a solução é a configuração do Device Owner via cabo.

Ao finalizar o processo via cabo é importante que o modo desenvolvedor seja desativado, pois ele pode representar uma vulnerabilidade para o dispositivo.

Como os fabricantes podem ter acesso ao AE e outros recursos do Google?

Existem algumas etapas que os fabricantes precisam seguir para que os dispositivos tenham acesso aos serviços do Google:

1 – Baixar o código fonte do Android para customização com drivers.
2 – Adequação a um documento de definição de compatibilidade da Google (CDD – Compatibility Definition Document).
3 – Teste de compatibilidade, onde a Google adiciona os serviços desenvolvidos por ela (CTS – Compatibility Test Suite).

Em alguns casos, o fabricante que desenvolve e customiza o código fonte do Android pode ser aprovado no teste de compatibilidade e começa a fazer parte do ecossistema da Google, enquanto outros, como por exemplo a Huawei, pode não desenvolver e não customizar e acabar não recebendo a aprovação, mesmo tendo acessado o site da Google e baixado o código fonte.