Práticas recomendadas de segurança do sistema

Esta seção contém recomendações para garantir a segurança do sistema operacional e dos dispositivos principais do Android.

Autenticação biométrica

Adquira, armazene e processe dados biométricos para autenticação do usuário com cuidado. O que você terá aprendido:

  • Obriga o método de autenticação principal antes de usar qualquer outra forma de autenticação (incluindo a biometria).
  • Exija uma confirmação explícita para indicar a intenção ao usar modalidades biométricas passivas, como reconhecimento facial, para transações (por exemplo, pagamentos) que envolvem chaves vinculadas à autenticação.
  • Exija o método de autenticação principal a cada 72 horas.
  • Use um pipeline totalmente seguro para todos os dados biométricos e processamento.
  • Nunca envie dados biométricos (incluindo medições brutas do sensor e recursos derivados) para fora do dispositivo. Se possível, mantenha esses dados em um ambiente seguro e isolado, como o ambiente de execução confiável (TEE) ou o Elemento de segurança.

Os dispositivos com biometria precisam oferecer suporte à API BiometricPrompt, que oferece uma interface comum e consistente para que os desenvolvedores de apps aproveitem a autenticação baseada em biometria. Somente biometrias fortes podem ser integradas ao BiometricPrompt, e as integrações precisam seguir as diretrizes do Documento de definição de compatibilidade do Android (CDD, na sigla em inglês).

Para mais diretrizes biométricas, consulte Diretrizes de implementação de HAL biométrica.

SELinux

O SELinux fornece a definição e a aplicação de grande parte do modelo de segurança do Android. O uso correto do SELinux é essencial para a segurança de dispositivos Android e pode ajudar a reduzir o impacto das vulnerabilidades de segurança. Por esse motivo, todos os dispositivos Android precisam implementar uma política robusta do SELinux.

  • Implemente uma política de privilégio mínimo.
  • Evite conceder as permissões CAP_DAC_OVERRIDE, CAP_SYS_ADMIN e CAP_NET_ADMIN.
  • Não registre dados do sistema no cartão SD.
  • Use os tipos fornecidos para acesso ao driver, como gpu_device, audio_device etc.
  • Use nomes significativos para processos, arquivos e tipos do SELinux.
    • Não use marcadores padrão nem conceda acesso a eles.
  • A política específica do dispositivo precisa representar de 5% a 10% da política geral em execução em um dispositivo. As personalizações na faixa de 20%ou mais quase certamente contêm domínios com privilégios excessivos e políticas inválidas. Uma política grande demais desperdiça memória, desperdiça espaço em disco ao exigir uma imagem de inicialização maior e afeta negativamente os tempos de pesquisa de políticas de execução.

Carregamento dinâmico da política do SELinux

Não carregue dinamicamente a política do SELinux em dispositivos Android. Isso pode resultar em problemas, como:

  • Impedir a aceitação de patches de segurança críticos.
  • Exposição da capacidade de fazer o root de um dispositivo com a recarregação de políticas.
  • Exposição de um vetor para ataques man-in-the-middle contra o atualizador de políticas.
  • O que resulta em dispositivos inúteis devido a erros nas atualizações de políticas.

Acesso "backdoor"

Os apps Android não podem ter backdoors ou formas de acessar o sistema ou dados que contornem mecanismos de segurança normais. Isso inclui acessos especiais de diagnóstico, depuração, desenvolvimento ou reparo de garantia, bloqueados por secrets conhecidos pelo desenvolvedor. Para evitar backdoors:

  • Verifique todos os apps de terceiros usando uma ferramenta de verificação de vulnerabilidades reconhecida pelo setor.
  • Realize análises de código de todo o código com acesso sensível, incluindo bibliotecas de terceiros.
  • Use o Google Play Protect fazendo o upload de apps para o Google Play para verificação. É possível fazer upload de apps para verificação sem publicar no Google Play.
  • Não pré-carregue ferramentas de diagnóstico ou reparo em builds de lançamento. Instale essas ferramentas apenas quando necessário para resolver problemas específicos. Além disso, essas ferramentas não podem operar ou fazer upload de dados específicos da conta.

Ferramentas de desenvolvimento

Ferramentas de desenvolvimento, como depuração, teste e diagnóstico, podem criar lacunas de segurança indesejadas no dispositivo, revelando como elas operam e os dados que coletam. Para garantir que as ferramentas de desenvolvimento não cheguem aos builds de produção:

  • Desenvolva uma lista de bloqueio de hashes de ferramentas internas de depuração e teste e faça a verificação de builds desses APKs antes de usar a imagem do sistema.
  • Verifique todos os apps próprios usando uma ferramenta de verificação de vulnerabilidade reconhecida pelo setor.
  • Contrate uma empresa terceirizada de testes de segurança de apps para avaliar todos os apps de diagnóstico críticos no dispositivo antes de qualquer atualização importante, especialmente se o app for desenvolvido por terceiros.
  • Verifique se apenas o usuário pode ativar a ferramenta, verbalmente ou por chat, durante uma sessão de suporte. Armazene artefatos de consentimento e desative a ferramenta depois de coletar as informações de diagnóstico necessárias.
  • Armazenar o registro de uso dessa ferramenta em um registro acessível pelo usuário na conta da operadora.
  • Garanta que todas as informações de identificação pessoal (PII) ou dados de telemetria do dispositivo coletados pela ferramenta estejam sujeitos a práticas de anonimização, retenção e exclusão relevantes para o país. Apenas os dados relevantes para a chamada de suporte devem ser coletados. Esses dados precisam ser excluídos após cada chamada.
  • Verifique se as técnicas que podem ser usadas para spyware, como o registro de teclas, o uso do microfone ou da câmera, não são usadas sem o consentimento explícito do usuário. Os apps que usam esses métodos potencialmente invasivos à privacidade precisam ser divulgados de forma muito clara, junto com uma Política de Privacidade que o usuário precisa aceitar. Apps como esse não podem ser ativados sem o consentimento explícito do usuário.

Confira outras sugestões para consultar ao implementar a divulgação e o consentimento:

Divulgação no app

  • Mostre o uso normal do app diretamente no app. Não exija que o usuário navegue até um menu ou até as configurações.
  • Descreva o tipo de dados coletados e explique como eles são usados.
  • O ideal é não incorporar essas informações em uma Política de Privacidade ou nos Termos de Serviço. Não a inclua em outras divulgações não relacionadas à coleta de dados pessoais ou sensíveis.
  • O consentimento precisa ser afirmativo. Não considerar a navegação para outra tela a partir da declaração, incluindo tocar na tela para sair ou pressionar os botões home ou "Voltar", como consentimento.
  • Apresente a caixa de diálogo de consentimento de uma maneira clara e inequívoca.
  • Exija uma ação afirmativa do usuário, como tocar para aceitar ou falar um comando, para aceitar.
  • Não colete dados pessoais ou sensíveis sem o consentimento expresso.
  • Não use mensagens que expiram ou são dispensadas automaticamente.

Funcionalidade integrada no AOSP

A incorporação de mais funcionalidades no AOSP pode ter consequências e comportamentos inesperados. Portanto, tenha cuidado.

  • Garanta que o usuário seja solicitado se quiser usar apps padrão diferentes (por exemplo, mecanismo de pesquisa, navegador da Web, iniciador) e informe o envio de dados para fora do dispositivo.
  • Verifique se os APKs do AOSP estão assinados com o certificado do AOSP.
  • Execute testes de regressão e mantenha um registro de mudanças para determinar se o código foi adicionado aos APKs do AOSP.

Atualizações de segurança

Os dispositivos Android precisam receber suporte de segurança contínuo por pelo menos dois anos após o lançamento. Isso inclui receber atualizações regulares que abordam vulnerabilidades de segurança conhecidas.

  • Trabalhe com parceiros de hardware, como fornecedores de SoC, para implementar acordos de suporte adequados para todos os componentes do dispositivo Android.
  • Garanta que as atualizações de segurança possam ser instaladas com o mínimo de interação do usuário para aumentar a probabilidade de os usuários aceitarem e instalarem atualizações no dispositivo Android. É altamente recomendável implementar atualizações contínuas do sistema ou um recurso de segurança equivalente.
  • Entenda o requisito cumulativo do nível de patch de segurança (SPL) do Android, conforme declarado no boletim de segurança do Android. Por exemplo, dispositivos que usam o nível do patch de segurança 2018-02-01 precisam incluir todos os problemas associados a esse nível, além de correções para todos os problemas informados em todos os boletins de segurança anteriores.

Atualizações dinâmicas do kernel

Não modifique dinamicamente componentes críticos do sistema. Embora existam algumas pesquisas que sugerem que as atualizações dinâmicas do kernel ajudam a proteger contra ameaças de emergência, o custo avaliado atualmente supera os benefícios. Em vez disso, crie um método de atualização OTA robusto para distribuir rapidamente proteções contra vulnerabilidades.

Gerenciamento de chaves

Mantenha boas políticas e práticas de gerenciamento de chaves para garantir a segurança das chaves de assinatura.

  • Não compartilhe chaves de assinatura com partes externas.
  • Se uma chave de assinatura for comprometida, gere uma nova chave e faça a dupla assinatura de todos os apps daqui para frente.
  • Armazene todas as chaves em hardware ou serviços de módulo de alta segurança que exigem vários fatores de acesso.

Assinatura de imagem do sistema

A assinatura da imagem do sistema é essencial para determinar a integridade do dispositivo.

  • Não assine dispositivos com uma chave conhecida publicamente.
  • Gerenciar chaves de assinatura de dispositivo de maneira consistente com as práticas padrão do setor para lidar com chaves sensíveis, incluindo um módulo de segurança de hardware (HSM) que oferece acesso limitado e auditável.

Carregadores de inicialização desbloqueáveis

Muitos dispositivos Android oferecem suporte ao desbloqueio, permitindo que o proprietário do dispositivo modifique a partição do sistema ou instale um sistema operacional personalizado. Os casos de uso comuns incluem a instalação de uma imagem de sistema de terceiros e a realização de desenvolvimento no nível do sistema no dispositivo. Por exemplo, para desbloquear a imagem do sistema em um Google Nexus ou Pixel, o usuário pode executar fastboot oem unlock, que exibe esta mensagem:

Como prática recomendada, os dispositivos Android desbloqueáveis precisam apagar com segurança todos os dados do usuário antes de serem desbloqueados. A falha na exclusão adequada de todos os dados ao desbloquear pode permitir que um invasor fisicamente próximo tenha acesso não autorizado a dados confidenciais do usuário do Android. Para evitar a divulgação de dados do usuário, um dispositivo que ofereça suporte ao desbloqueio precisa implementá-lo corretamente.

  • Depois que o usuário confirmar o comando de desbloqueio, o dispositivo precisará iniciar um apagamento imediato de dados. A flag unlocked não pode ser definida até que a exclusão segura seja concluída.
  • Se não for possível concluir uma exclusão segura, o dispositivo precisa permanecer em um estado bloqueado.
  • Se o dispositivo de bloco de destino oferecer suporte, ioctl(BLKSECDISCARD) ou equivalente precisa ser usado. Para dispositivos de cartão multimídia (eMMC) incorporados, isso significa usar um comando de Limpeza segura ou de Recorte seguro. Para eMMC 4.5 e versões mais recentes, isso significa usar um apagamento normal ou o corte seguido por uma operação de limpeza.
  • Se o dispositivo de bloco de dados de BLKSECDISCARD não tiver suporte, ioctl(BLKDISCARD) precisará ser usado. Em dispositivos eMMC, essa é uma operação de corte normal.
  • Se não houver suporte para BLKDISCARD, a substituição dos dispositivos de bloco por zeros será aceitável.
  • O usuário precisa ter a opção de exigir que os dados sejam apagados antes de atualizar uma partição. Por exemplo, os dispositivos Nexus usam o comando fastboot oem lock para limpar os dados do usuário.
  • Um dispositivo pode registrar, por meio de eFuses ou mecanismo semelhante, se um dispositivo foi desbloqueado e/ou bloqueado novamente. No entanto, recomendamos que o rebloqueio do carregador de inicialização com a redefinição para a configuração original restaure a funcionalidade completa do dispositivo.

Esses requisitos garantem que todos os dados sejam destruídos após a conclusão de uma operação de desbloqueio. A falha na implementação dessas proteções é considerada uma vulnerabilidade de segurança de nível moderado.

Um dispositivo desbloqueado pode ser bloqueado novamente usando o comando fastboot oem lock. O bloqueio do carregador oferece a mesma proteção de dados do usuário com o novo SO personalizado que estava disponível com o SO original do fabricante do dispositivo. Por exemplo, os dados do usuário são excluídos se o dispositivo for desbloqueado novamente.

Teste de penetração de dispositivos

Os dispositivos precisam ser analisados por um pentester competente antes do envio. O teste de penetração precisa estabelecer que o dispositivo seguiu as orientações de segurança fornecidas aqui, bem como as orientações de segurança internas do OEM.

Testes de segurança

Use as ferramentas de teste de segurança fornecidas pelo AOSP. Em particular

  • Use ferramentas de segurança de memória durante o desenvolvimento: use o MTE onde houver suporte (ARMv9 e versões mais recentes) e HWASan onde não houver. Realize o maior número possível de testes com essas ferramentas ativadas.
  • Use GWP-ASan e KFENCE na produção para a detecção probabilística de problemas de segurança de memória.