Melhores práticas de segurança do sistema

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

Autenticação biométrica

Adquira, armazene e processe dados biométricos para autenticação do usuário com cuidado. Você deve:

  • Exija o método de autenticação principal antes de usar qualquer outra forma de autenticação (incluindo 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 envolvam 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 manuseio.
  • Nunca envie dados biométricos (incluindo medições brutas de sensores e recursos derivados) para fora do dispositivo. Se possível, mantenha esses dados em um ambiente seguro e isolado, como o Trusted Execution Environment (TEE) ou o Secure Element.

Dispositivos com biometria devem suportar a API BiometricPrompt , que oferece uma interface comum e consistente para desenvolvedores de aplicativos aproveitarem a autenticação baseada em biometria em seus aplicativos. Somente biometria forte pode ser integrada ao BiometricPrompt e as integrações devem seguir as diretrizes do Documento de definição de compatibilidade do Android (CDD).

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

SELinux

SELinux fornece a definição e aplicação de grande parte do modelo de segurança do Android. O uso correto do SELinux é fundamental para a segurança dos dispositivos Android e pode ajudar a mitigar o impacto das vulnerabilidades de segurança. Todos os dispositivos Android devem implementar uma política SELinux robusta por esse motivo.

  • Implemente uma política de privilégio mínimo.
  • Evite conceder 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 SELinux.
    • Certifique-se de que rótulos padrão não sejam usados ​​e que o acesso não seja concedido a eles.
  • A política específica do dispositivo deve representar de 5 a 10% da política geral executada 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 inativas. Políticas desnecessariamente grandes desperdiçam memória, desperdiçam espaço em disco ao exigir uma imagem de inicialização maior e afetam negativamente os tempos de pesquisa de políticas em tempo de execução.

Carregamento dinâmico da política SELinux

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

  • Impedir a aceitação de patches de segurança críticos.
  • Expondo a capacidade de fazer root em um dispositivo por meio do recarregamento de políticas.
  • Expondo um vetor para ataques man-in-the-middle contra o atualizador de políticas.
  • Resultando em dispositivos bloqueados devido a erros nas atualizações de políticas.

Portas dos fundos

Os aplicativos Android não devem ter backdoors ou formas de acessar o sistema ou dados que contornem os mecanismos normais de segurança. Isso inclui diagnóstico, depuração, desenvolvimento ou reparo em garantia, acesso especial protegido por segredos conhecidos pelo desenvolvedor. Para evitar backdoors:

  • Verifique todos os aplicativos de terceiros usando uma ferramenta de verificação de vulnerabilidades de aplicativos reconhecida pelo setor.
  • Execute revisões de código de todos os códigos com acesso confidencial, incluindo bibliotecas de terceiros.
  • Utilize o Google Play Protect fazendo upload de aplicativos para o Google Play para verificação. Você pode fazer upload de aplicativos para digitalização sem publicar no Google Play.
  • Não pré-carregue ferramentas focadas em diagnóstico ou reparo em compilações de lançamento. Instale essas ferramentas somente sob demanda para resolver problemas específicos. Além disso, essas ferramentas não devem operar ou fazer upload de dados específicos da conta.

Ferramentas de desenvolvimento

Ferramentas de desenvolvimento, como ferramentas de depuração, teste e diagnóstico, muitas vezes podem criar lacunas de segurança não intencionais em seu dispositivo, revelando como elas operam e os dados que coletam. Para garantir que as ferramentas de desenvolvimento não cheguem às compilações de produção:

  • Desenvolva uma lista negra de hashes de ferramentas internas de depuração e teste e verifique compilações para esses APKs antes de usar a imagem do sistema.
  • Verifique todos os aplicativos originais usando uma ferramenta de verificação de vulnerabilidades de aplicativos reconhecida pelo setor.
  • Contrate uma empresa terceirizada de testes de segurança de aplicativos para avaliar todos os aplicativos críticos de diagnóstico no dispositivo antes de qualquer atualização importante, especialmente se o aplicativo for desenvolvido por terceiros.
  • Certifique-se de que apenas o usuário possa ativar a ferramenta, verbalmente ou por chat, durante uma sessão de suporte. Armazene artefatos de consentimento e desative a ferramenta após coletar as informações de diagnóstico necessárias.
  • Armazene o registro de utilização desta ferramenta em um log acessível pelo usuário em sua conta operadora.
  • Certifique-se de que quaisquer informações de identificação pessoal (PII) ou dados de telemetria de dispositivos coletados pela ferramenta estejam sujeitos a práticas de anonimato, retenção e exclusão relevantes para o país. Somente dados relevantes para a chamada de suporte deverão ser coletados. Esses dados devem ser excluídos após cada chamada.
  • Certifique-se de que as técnicas que podem ser usadas para spyware, como registro de teclas digitadas, uso de microfone ou uso de câmera, não sejam usadas sem o consentimento explícito do usuário. Os aplicativos que utilizam esses métodos potencialmente invasivos à privacidade devem ser divulgados de forma muito clara, juntamente com uma política de privacidade com a qual o usuário deve consentir. Aplicativos como este não devem ser ativados sem o consentimento explícito do usuário.

Aqui estão algumas sugestões adicionais a serem consultadas ao implementar a divulgação e o consentimento:

Divulgação no aplicativo

  • Exiba o uso normal do aplicativo diretamente no aplicativo. Não exige que o usuário navegue em um menu ou configurações.
  • Descreva o tipo de dados que estão sendo coletados e explique como os dados serão usados.
  • O ideal é não incorporar essas informações em uma política de privacidade ou termos de serviço. Não inclua-o com outras divulgações não relacionadas à coleta de dados pessoais ou confidenciais.
  • O consentimento deve ser afirmativo. Não considere a navegação fora da divulgação, incluindo tocar ou pressionar o botão Voltar ou Início, como consentimento.
  • Apresente a caixa de diálogo de consentimento de forma 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 confidenciais antes de obter consentimento afirmativo.
  • Não use mensagens descartadas automaticamente ou expiradas.

Funcionalidade incorporada no AOSP

A incorporação de funcionalidades adicionais no AOSP muitas vezes pode ter comportamentos e consequências inesperados; prossiga com cuidado.

  • Certifique-se de que o usuário seja questionado se deseja usar diferentes aplicativos padrão (por exemplo, mecanismo de pesquisa, navegador da web, iniciador) e divulgar o envio de dados para fora do dispositivo.
  • Certifique-se de que os APKs AOSP estejam assinados com o certificado AOSP.
  • Execute testes de regressão e mantenha um log de alterações para determinar se os APKs AOSP tiveram código adicionado.

Atualizações de segurança

Os dispositivos Android devem receber suporte de segurança contínuo por pelo menos dois anos a partir do lançamento. Isso inclui o recebimento de atualizações regulares que abordam vulnerabilidades de segurança conhecidas.

  • Trabalhe com parceiros de hardware, como seus fornecedores de SoC, para estabelecer acordos de suporte apropriados para todos os componentes do seu dispositivo Android.
  • Certifique-se de 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 em seus dispositivos Android. É altamente recomendável implementar atualizações contínuas do sistema ou um recurso de segurança equivalente.
  • Certifique-se de compreender o requisito cumulativo do Android Security Patch Level (SPL), conforme declarado no Android Security Bulletin . Por exemplo, os dispositivos que usam o nível de patch de segurança 01/02/2018 devem incluir todos os problemas associados a esse nível de patch de segurança, bem como correções para todos os problemas relatados 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 robusto de atualização OTA 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 terceiros.
  • Se uma chave de assinatura estiver comprometida, gere uma nova chave e assine novamente todos os aplicativos daqui para frente.
  • Armazene todas as chaves em hardware de módulo de alta segurança ou serviços que exigem vários fatores de acesso.

Assinatura de imagem do sistema

A assinatura da imagem do sistema é crítica para determinar a integridade do dispositivo.

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

Bootloaders desbloqueáveis

Muitos dispositivos Android suportam 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 execução de desenvolvimento em nível de sistema no dispositivo. Por exemplo, para desbloquear a imagem do sistema em um Google Nexus ou Pixel, um usuário pode executar fastboot oem unlock , que exibe esta mensagem:

Como prática recomendada, os dispositivos Android desbloqueáveis ​​devem apagar com segurança todos os dados do usuário antes de serem desbloqueados. A falha em excluir adequadamente todos os dados no desbloqueio pode permitir que um invasor fisicamente próximo obtenha 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 suporte o desbloqueio deve implementá-lo adequadamente.

  • Depois que o usuário confirmar o comando de desbloqueio, o dispositivo deverá iniciar uma limpeza imediata de dados. O sinalizador unlocked não deve ser definido até que a exclusão segura seja concluída.
  • Se uma exclusão segura não puder ser concluída, o dispositivo deverá permanecer bloqueado.
  • Se for suportado pelo dispositivo de bloco subjacente, deve ser usado ioctl(BLKSECDISCARD) ou equivalente. Para dispositivos MultiMediaCard (eMMC) incorporados, isso significa usar um comando Secure Erase ou Secure Trim. Para o eMMC 4.5 e posterior, isso significa usar um Erase ou Trim normal seguido por uma operação Sanitize.
  • Se BLKSECDISCARD não for suportado pelo dispositivo de bloco subjacente, ioctl(BLKDISCARD) deverá ser usado. Em dispositivos eMMC, esta é uma operação normal de Trim.
  • Se BLKDISCARD não for suportado, a substituição dos dispositivos de bloco com zeros é aceitável.
  • Um usuário deve ter a opção de exigir que os dados do usuário 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 rebloqueado. No entanto, recomendamos fortemente que travar novamente o bootloader com posterior redefinição de fábrica deve restaurar 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 posteriormente bloqueado novamente usando o comando fastboot oem lock . Bloquear o bootloader fornece a mesma proteção dos dados do usuário com o novo sistema operacional personalizado que estava disponível com o sistema operacional original do fabricante do dispositivo (por exemplo, os dados do usuário serão apagados se o dispositivo for desbloqueado novamente).

Teste de invasão de dispositivos

Os dispositivos devem ser revisados ​​por um pentester competente antes do envio. O teste de pentes deve estabelecer que o dispositivo seguiu as orientações de segurança fornecidas aqui, bem como as orientações de segurança internas do OEM.

Teste de segurança

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

  • Use ferramentas de segurança de memória durante o desenvolvimento: use MTE onde houver suporte (ARMv9 e superior) e HWASan onde não houver. Execute tantos testes quanto possível com essas ferramentas habilitadas.
  • Use GWP-ASan e KFENCE em produção para detecção probabilística de problemas de segurança de memória.