O programa Android Enterprise Recomendado pode ter requisitos de atualização de segurança relaxados, de acordo com um documento vazado revisado pelo XDA.
Embora o Android seja o sistema operacional dominante para smartphones, de acordo com dados de CDI, o iOS da Apple é o sistema operacional preferido da maioria das empresas. É fácil entender por quê: a Apple atualiza seus dispositivos iOS geralmente por muito mais tempo e de forma mais consistente do que a maioria dos fabricantes de dispositivos Android. atualizar seus smartphones, os iPhones são simples de configurar e gerenciar e há muito menos SKUs para oferecer suporte se uma empresa escolher Maçã. Mas também há razões para as empresas escolherem um dispositivo Android, incluindo custo reduzido e maior flexibilidade em hardware. Para tornar o Android ainda mais atraente para o local de trabalho, o Google lançou o "Android for Work" no início de 2015 (mais tarde rebatizado como "Android Enterprise" no final de 2016). Então, no início de 2018, o Google lançou o
No entanto, documentos descobertos pelo desenvolvedor Android @deletarscape que foram revisados por Desenvolvedores XDA revelam que o Google está planejando afrouxar os requisitos de atualização de segurança para dispositivos Android Enterprise recomendados. Em vez disso, o Google está pressionando para que os fornecedores sejam mais transparentes sobre como lidam com as atualizações de segurança. Segundo @deletescape, esses documentos foram compartilhados com fornecedores nos últimos 15 dias. Assim, embora não possamos garantir que essas alterações propostas no Android Enterprise Recomendado serão implementadas na lista final de requisitos, podemos pelo menos confirmar que o Google considerou muito recentemente estes mudanças.
Há atualmente 170 dispositivos Android diferentes que são recomendados para Android Enterprise. HMD Global, Sony, Motorola, OPPO, e claro, Google, oferecem dispositivos que são AER. Até OnePlus está considerando ter seus dispositivos certificados no programa. No entanto, marcas conhecidas de smartphones de consumo não são as únicas empresas que vendem dispositivos Android Enterprise Recomendados. Smartphones robustos de empresas como Zebra, Honeywell, Sonim e outras estão incluídas no programa, e agora até mesmo operadoras podem vender dispositivos AER diretamente para empresas, desde que aprovem rapidamente as versões de manutenção de segurança.
O fluxo de provisionamento de dispositivos no Android 10. Fonte: Jason Bayton
O lista de requisitos necessário para entrar no AER não é tão extenso – muitos mais dispositivos Android poderiam ter entrado na lista devido aos baixos requisitos básicos de hardware. Mesmo os requisitos de software da AER não exigem muitas mudanças dos fornecedores, conforme descrito em vários documentos internos do Google. Um dos documentos descreve como os fornecedores precisam criar emblemas de ícones para aplicativos no perfil de trabalho, adicionar uma guia dedicada para aplicativos de perfil de trabalho no inicializador, separar alvos de compartilhamento para aplicativos no perfil pessoal e de trabalho, pré-carregar determinados aplicativos do Google e gerenciar dados de perfis cruzados comunicação. Outro documento descreve os requisitos de UX para a guia do iniciador do perfil de trabalho, Configuração rápida do perfil de trabalho bloco, caixas de diálogo de perfil de trabalho, mensagens educacionais do iniciador, alternância de contexto e outros designs de sistema elementos. Esses requisitos têm como objetivo promover um padrão mínimo de hardware aceitável, bem como consistência de UX de software entre dispositivos Android Enterprise Recomendados.
No entanto, parece que o requisito para que os dispositivos obtenham rapidamente atualizações de patches de segurança após cada mês Boletim de segurança do Android (ASB) provou ser uma barreira muito alta para muitos fornecedores.
Google pressiona por transparência de atualização para Android Enterprise recomendado
Desenvolvedor Android @deletarscape, que recentemente compartilhou um rascunho vazado de Documento de definição de compatibilidade do Google para Android 11, obteve um rascunho vazado dos novos requisitos recomendados pelo Android Enterprise para dispositivos que executam o Android 11. Debaixo de "Segurança do dispositivo", que reproduzimos abaixo, o Google está propondo a remoção de uma série de requisitos para o programa AER. De acordo com essas novas regras propostas, os dispositivos AER não terão mais garantia de receber atualizações de patches de segurança dentro de 90 dias após um ASB. Curiosamente, uma das linhas do gráfico sugere que o Google realmente reforçou esse requisito de 90 para 30 dias com a mudança para o Android 10, mas o Google ainda não atualizou o lista pública de requisitos para refletir essa mudança. No entanto, de acordo com as alterações propostas, este requisito não se aplicará mais a dispositivos Android Enterprise Recomendados que executam Android 11. Além disso, os fornecedores também não serão mais obrigados a fornecer três anos de atualizações regulares de segurança para dispositivos AER. No entanto, eles ainda serão obrigados a fornecer atualizações de "Lançamento de Manutenção de Segurança Emergencial" (ESMR), o que presumivelmente significa que eles só precisam lançar atualizações contendo correções para segurança crítica vulnerabilidades.
Android 10 versus Android 11 – Requisitos de segurança do dispositivo para Android Enterprise recomendados
Categoria |
Número de série |
DEVE/MAIO |
Atributo e Implementação |
Comentários |
Q (andróide 10) |
R (andróide 11) |
|||
Segurança do dispositivo |
1 |
PODERIA |
Operar um Programa de Recompensas de Vulnerabilidade OEM (VRP) |
Operar um Programa de Recompensas de Vulnerabilidade OEM (VRP) |
2 |
PODERIA |
Suporte para StrongBox |
Suporte para StrongBox |
|
3 |
PODERIA |
Suporte a Keystore apoiado por hardware |
Suporte a Keystore apoiado por hardware |
|
4 |
PODERIA |
Suporte para atestado de ID de dispositivo |
Suporte para atestado de ID de dispositivo |
|
5 |
PODERIA |
Suporte de atestado principal |
Suporte de atestado principal |
|
6 |
Atualizações de segurança de 30 dias |
Requisito removido |
Substituído pelo requisito de transparência de segurança |
|
7 |
DEVE |
Suporte de 3 anos para versão de manutenção de segurança de emergência (ESMR) |
Suporte de 3 anos para versão de manutenção de segurança de emergência (ESMR) |
Substituído pelo requisito de transparência de segurança |
8 |
Criptografia baseada em arquivo – ativada por padrão. Usa implementação AOSP. |
Requisito removido |
Este é um requisito do GMS aplicado a todos os dispositivos |
|
9 |
Atualizações de segurança de 90 dias |
Requisito removido |
Substituído pelo requisito de transparência de segurança |
|
10 |
Suporte para atualização de segurança de 3 anos (pode ser ESMR inferior ao 3º ano) |
Requisito removido |
Substituído pelo requisito de transparência de segurança |
|
11 |
Publicar o nível de patch de segurança mais recente |
Requisito removido |
Substituído pelo requisito de transparência de segurança |
consulte Mais informação
Conforme mencionado no gráfico, o Google propõe substituir muitos desses requisitos por novos requisitos de “transparência”. Na verdade, o Google está propondo a adição de uma nova seção intitulada "Transparência de atualizações de segurança/sistema operacional." Os novos requisitos detalham como os fornecedores serão obrigados a publicar informações como a data de fim da vida útil das versões de manutenção de segurança, o patch de segurança mais recente disponível, com que frequência o dispositivo receberá atualizações, quais correções estão contidas em cada atualização, o envio e as atualizações de software planejadas do dispositivo e muito mais. Curiosamente, o Google também exige que os dispositivos Android 11 sejam submetidos a testes de certificação pelo Aliança ioXt antes que eles possam se tornar recomendados para Android Enterprise. A ioXt Alliance é uma aliança de empresas cujo objetivo é melhorar a segurança dos produtos IoT. Seus membros incluem Amazon, Facebook, Google, NXP e muito mais. O Google diz que ter esta certificação aumentará a transparência, provavelmente porque dará empresas uma métrica independente de quão seguro é um determinado dispositivo, em vez de apenas o Google garantia.
Requisitos de transparência de atualizações de segurança/sistema operacional (novos) para Android Enterprise recomendados
Categoria |
Número de série |
DEVE/MAIO |
Atributo e Implementação |
Comentários |
Q (andróide 10) |
R (andróide 11) |
|||
Transparência de atualizações de segurança/sistema operacional |
1 |
DEVE |
DEVE publicar as seguintes informações de atualizações no site do OEM - Data de término do suporte SMR (última data em que o dispositivo receberá SMR) - Mais recente patch de segurança disponível - Frequência de atualizações que o dispositivo receberá - Correções contidas no patch de segurança, incluindo qualquer específico do OEM Conserta |
Alteração do requisito de suporte SMR para transparência de SMR/patches/atualizações |
2 |
DEVE |
DEVE publicar as seguintes informações do sistema operacional no site do OEM - SO com o qual o dispositivo é enviado - Versão principal atual do sistema operacional - Todas as principais atualizações de versão do sistema operacional que o dispositivo receberá |
Alteração do requisito de suporte para transparência, por exemplo: Pixel 3- Versão enviada - Android 9- Versão atual - Android 10- Versão principal esperada - Android 11 |
|
3 |
DEVE |
Envie o dispositivo para certificação IoXT |
A pontuação IoXT aumenta a transparência |
consulte Mais informação
Não é nenhum segredo que os fornecedores têm dificuldade em acompanhar o lançamento de atualizações mensais de patches de segurança. Há muitas, muitas razões pelas quais isso acontece: atrasos na certificação da operadora, espera por patches do chipset e outros fornecedores, a dificuldade de aplicar patches a compilações de estruturas Android fortemente modificadas e kernels Linux fora da árvore, e mais. Alguns usuários do Android perceberam como alguns fornecedores não atende aos requisitos AER. Embora os esforços de desenvolvimento e os contratos de licença do Google tenham ajudou a melhorar a rapidez com que as atualizações de segurança são implementadas para muitos dispositivos, elas claramente não foram capazes de sustentar os requisitos atuais de patch de segurança para o programa Android Enterprise Recommendation. Afrouxar estes requisitos em favor de mais transparência ajudará a tornar o programa mais acessível aos fornecedores e também dá às empresas mais confiança no dispositivo específico que escolhem para seus trabalhadores.
O relaxamento proposto nas atualizações de patches de segurança não é a única mudança que pode ocorrer no programa Android Enterprise Recomendado para Android 11, é claro. O Google também planeja aumentar os requisitos mínimos de hardware de 2 GB de RAM para 3 GB de RAM, restringir os requisitos de treinamento e implementar um novo conjunto de requisitos para o perfil de trabalho UX. No entanto, a maioria dessas mudanças não afetará os trabalhadores do conhecimento. O Android nas empresas cresceu muito desde seus primeiros dias. Se você estiver interessado em aprender mais sobre sua história, recomendo a leitura este excelente artigo de Jason Bayton.