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:

  • Obrigar 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 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 manuseio.
  • Nunca envie dados biométricos (incluindo medições brutas do sensor e recursos derivados) 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.

Os dispositivos com biometria devem ser compatíveis com a API BiometricPrompt , que oferece uma interface comum e consistente para que os desenvolvedores de aplicativos aproveitem a autenticação baseada em biometria em seus aplicativos. Somente biometria forte pode se integrar 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étrica .

SELinux

O 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égios mínimos.
  • Evite conceder 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 os 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 mais de 20% quase certamente contêm domínios com privilégios excessivos e política inativa. 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 de tempo de execução.

Carregamento dinâmico da política SELinux

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

  • Impedindo 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ítica.
  • Resultando em dispositivos emparedados devido a erros com atualizações de política.

Portas dos fundos

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

  • Analise todos os aplicativos de terceiros usando uma ferramenta de verificação de vulnerabilidades de aplicativos reconhecida pelo setor.
  • Realize revisões de código de todo o código 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 apenas sob demanda para resolver problemas específicos. Além disso, essas ferramentas não devem operar ou carregar dados específicos da conta.

Ferramentas de desenvolvimento

Ferramentas de desenvolvimento, como ferramentas de depuração, teste e diagnóstico, muitas vezes podem criar falhas 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 internos de ferramentas de depuração e teste e verifique as compilações desses APKs antes de usar a imagem do sistema.
  • Analise todos os aplicativos primários 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 uso desta ferramenta em um log acessível pelo usuário em sua conta de operadora.
  • Certifique-se de que quaisquer 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. Somente dados relevantes para a chamada de suporte devem 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 pressionamento de tecla, 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 esse não devem ser ativados sem o consentimento explícito do usuário.

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

Divulgação no aplicativo

  • Exiba o uso normal do aplicativo diretamente no aplicativo. Não exija que o usuário navegue em um menu ou configurações.
  • Descreva o tipo de dados que está sendo coletado 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 o inclua 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 o diálogo de consentimento de forma clara e inequívoca.
  • Exigir 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 o consentimento afirmativo.
  • Não use mensagens com dispensa automática ou expiração.

Funcionalidade incorporada no AOSP

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

  • Certifique-se de que o usuário seja avisado se deseja usar aplicativos padrão diferentes (por exemplo, mecanismo de pesquisa, navegador da Web, iniciador) e divulgue o envio de dados do dispositivo.
  • Certifique-se de que os APKs AOSP sejam assinados com o certificado AOSP.
  • Execute testes de regressão e mantenha um log de alterações para determinar se os AOSPs APKs 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 implementar os contratos 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. A implementação de atualizações contínuas do sistema ou um recurso de segurança equivalente é altamente recomendável.
  • Certifique-se de entender 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 2018-02-01 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 haja algumas pesquisas sugerindo 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 as 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 duas vezes todos os aplicativos daqui para frente.
  • Armazene todas as chaves em hardware de módulo de alta segurança ou serviços que exijam acesso a vários fatores.

Assinatura da imagem do sistema

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

  • Não assine dispositivos com uma chave conhecida publicamente.
  • Gerencie chaves de assinatura de dispositivo 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 o 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 corretamente todos os dados no desbloqueio pode permitir que um invasor fisicamente próximo obtenha acesso não autorizado a dados confidenciais de usuários do Android. Para evitar a divulgação de dados do usuário, um dispositivo que suporte o desbloqueio deve implementá-lo corretamente.

  • Após o usuário confirmar o comando de desbloqueio, o dispositivo deve iniciar uma limpeza de dados imediata. 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 em um estado bloqueado.
  • Se suportado pelo dispositivo de bloco subjacente, ioctl(BLKSECDISCARD) ou equivalente deve ser usado. Para dispositivos MultiMediaCard (eMMC) incorporados, isso significa usar um comando Secure Erase ou Secure Trim. Para eMMC 4.5 e posterior, isso significa usar uma operação normal de Erase ou Trim seguido por uma operação de 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 todos os 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, é altamente recomendável que o rebloqueio do carregador de inicialização com a redefinição de fábrica subsequente deve restaurar a funcionalidade total 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 . 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).

Pentest de dispositivos

Os dispositivos devem ser revisados ​​por um pentester competente antes do envio. O teste de teste 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 pelo 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 o maior número possível de testes 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.