O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
This page was translated by the Cloud Translation API.
Switch to English

Segurança de aplicativos

Elementos de Aplicações

O Android fornece uma plataforma de código aberto e um ambiente de aplicativos para dispositivos móveis. O sistema operacional principal é baseado no kernel do Linux. Os aplicativos Android costumam ser escritos na linguagem de programação Java e executados na máquina virtual Dalvik. No entanto, os aplicativos também podem ser gravados em código nativo. Os aplicativos são instalados a partir de um único arquivo com a extensão .apk.

Os principais blocos de construção de aplicativos Android são:

  • AndroidManifest.xml : o arquivo AndroidManifest.xml é o arquivo de controle que informa ao sistema o que fazer com todos os componentes de nível superior (especificamente atividades, serviços, receptores de transmissão e provedores de conteúdo descritos abaixo) em um aplicativo. Isso também especifica quais permissões são necessárias.

  • Atividades : Uma Atividade é, geralmente, o código para uma única tarefa focada no usuário. Geralmente inclui a exibição de uma interface do usuário para o usuário, mas não é necessário - algumas atividades nunca exibem interfaces de usuário. Normalmente, uma das atividades do aplicativo é o ponto de entrada para um aplicativo.

  • Serviços : Um Serviço é um corpo de código executado em segundo plano. Ele pode ser executado em seu próprio processo ou no contexto do processo de outro aplicativo. Outros componentes "ligam" a um Serviço e invocam métodos nele por meio de chamadas de procedimento remoto. Um exemplo de serviço é um media player: mesmo quando o usuário sai da interface do usuário de seleção de mídia, o usuário provavelmente ainda pretende que a música continue tocando. Um serviço mantém a música funcionando mesmo quando a interface do usuário foi concluída.

  • Receptor de Broadcast : Um BroadcastReceiver é um objeto que é instanciado quando um mecanismo IPC conhecido como Intent é emitido pelo sistema operacional ou outro aplicativo. Um aplicativo pode registrar um receptor para a mensagem de bateria fraca, por exemplo, e alterar seu comportamento com base nessas informações.

O modelo de permissão do Android: acessando APIs protegidas

Todos os aplicativos no Android são executados em uma caixa de proteção de aplicativos . Por padrão, um aplicativo Android pode acessar apenas um intervalo limitado de recursos do sistema. O sistema gerencia o acesso do aplicativo Android a recursos que, se usados ​​incorretamente ou maliciosamente, podem afetar adversamente a experiência do usuário, a rede ou os dados no dispositivo.

Essas restrições são implementadas de várias formas diferentes. Alguns recursos são restritos por uma falta intencional de APIs à funcionalidade sensível (por exemplo, não há API Android para manipular diretamente o cartão SIM). Em alguns casos, a separação de funções fornece uma medida de segurança, como no isolamento de armazenamento por aplicativo. Em outros casos, as APIs confidenciais destinam-se ao uso por aplicativos confiáveis ​​e protegidas por um mecanismo de segurança conhecido como Permissões.

Essas APIs protegidas incluem:

  • Funções da câmera
  • Dados de localização (GPS)
  • Funções Bluetooth
  • Funções de telefonia
  • Funções SMS / MMS
  • Conexões de rede / dados

Esses recursos são acessíveis apenas através do sistema operacional. Para usar as APIs protegidas no dispositivo, um aplicativo deve definir os recursos necessários em seu manifesto. Todas as versões do Android 6.0 e superior usam um modelo de permissões de tempo de execução . Se um usuário solicitar um recurso de um aplicativo que exija uma API protegida, o sistema exibirá uma caixa de diálogo, solicitando que o usuário negue ou permita a permissão.

Uma vez concedidas, as permissões são aplicadas ao aplicativo enquanto ele estiver instalado. Para evitar confusão do usuário, o sistema não notifica o usuário novamente das permissões concedidas ao aplicativo, e os aplicativos incluídos no sistema operacional principal ou agrupados por um OEM não solicitam permissões do usuário. As permissões são removidas se um aplicativo for desinstalado; portanto, uma reinstalação subsequente resultará novamente na exibição de permissões.

Nas configurações do dispositivo, os usuários podem visualizar as permissões dos aplicativos que eles instalaram anteriormente. Os usuários também podem desativar algumas funcionalidades globalmente quando quiserem, como desativar GPS, rádio ou wi-fi.

No caso de um aplicativo tentar usar um recurso protegido que não foi declarado no manifesto do aplicativo, a falha na permissão normalmente resultará em uma exceção de segurança lançada de volta para o aplicativo. As verificações de permissão da API protegida são aplicadas no nível mais baixo possível para evitar a evasão. Um exemplo das mensagens do usuário quando um aplicativo é instalado enquanto solicita acesso às APIs protegidas é mostrado na Figura 2 .

As permissões padrão do sistema estão descritas em https://developer.android.com/reference/android/Manifest.permission.html . Os aplicativos podem declarar suas próprias permissões para uso de outros aplicativos. Essas permissões não estão listadas no local acima.

Ao definir uma permissão, um atributo protectionLevel informa ao sistema como o usuário deve ser informado sobre os aplicativos que exigem a permissão ou quem tem permissão para ter uma permissão. Detalhes sobre a criação e o uso de permissões específicas do aplicativo estão descritos em https://developer.android.com/guide/topics/security/security.html .

Existem alguns recursos do dispositivo, como a capacidade de enviar intenções de transmissão por SMS, que não estão disponíveis para aplicativos de terceiros, mas que podem ser usados ​​por aplicativos pré-instalados pelo OEM. Essas permissões usam a permissão signatureOrSystem.

Como os usuários entendem aplicativos de terceiros

O Android se esforça para esclarecer aos usuários quando eles estão interagindo com aplicativos de terceiros e informar o usuário sobre os recursos que esses aplicativos possuem. Antes da instalação de qualquer aplicativo, o usuário recebe uma mensagem clara sobre as diferentes permissões que o aplicativo está solicitando. Após a instalação, o usuário não é solicitado novamente a confirmar as permissões.

Há muitos motivos para mostrar permissões imediatamente antes da hora da instalação. É quando o usuário está revisando ativamente as informações sobre o aplicativo, o desenvolvedor e a funcionalidade para determinar se elas correspondem às suas necessidades e expectativas. Também é importante que eles ainda não tenham estabelecido um compromisso mental ou financeiro com o aplicativo e possam comparar facilmente o aplicativo com outros aplicativos alternativos.

Algumas outras plataformas usam uma abordagem diferente para a notificação do usuário, solicitando permissão no início de cada sessão ou enquanto os aplicativos estão em uso. A visão do Android é fazer com que os usuários alternem perfeitamente entre aplicativos à vontade. O fornecimento de confirmações a cada vez atrasaria o usuário e impediria o Android de proporcionar uma ótima experiência ao usuário. A permissão de revisão do usuário no momento da instalação oferece ao usuário a opção de não instalar o aplicativo se sentir desconforto.

Além disso, muitos estudos de interface do usuário mostraram que o excesso de solicitação faz com que o usuário comece a dizer "OK" em qualquer caixa de diálogo exibida. Um dos objetivos de segurança do Android é transmitir efetivamente importantes informações de segurança ao usuário, o que não pode ser feito usando diálogos que o usuário será treinado para ignorar. Ao apresentar as informações importantes uma vez, e somente quando importantes, é mais provável que o usuário pense no que está concordando.

Algumas plataformas optam por não mostrar nenhuma informação sobre a funcionalidade do aplicativo. Essa abordagem impede que os usuários compreendam e discutam facilmente os recursos do aplicativo. Embora não seja possível para todos os usuários sempre tomar decisões totalmente informadas, o modelo de permissões do Android torna as informações sobre aplicativos facilmente acessíveis a uma ampla variedade de usuários. Por exemplo, solicitações de permissões inesperadas podem solicitar que usuários mais sofisticados façam perguntas críticas sobre a funcionalidade do aplicativo e compartilhem suas preocupações em locais como o Google Play, onde são visíveis para todos os usuários.

Permissões na instalação de aplicativos - Google Maps Permissões de um aplicativo instalado - Gmail
Permissões na instalação de aplicativos - Google MapsPermissões de um aplicativo instalado - Gmail

Figura 1. Exibição de permissões para aplicativos

Comunicação entre processos

Os processos podem se comunicar usando qualquer um dos mecanismos tradicionais do tipo UNIX. Exemplos incluem o sistema de arquivos, soquetes locais ou sinais. No entanto, as permissões do Linux ainda se aplicam.

O Android também fornece novos mecanismos de IPC:

  • Fichário : Um mecanismo leve de chamada de procedimento remoto baseado em capacidade, projetado para alto desempenho ao executar chamadas em processo e entre processos. O Binder é implementado usando um driver Linux personalizado. Consulte https://developer.android.com/reference/android/os/Binder.html .

  • Serviços : Os serviços (discutidos acima) podem fornecer interfaces diretamente acessíveis usando o fichário.

  • Intents : Intent é um objeto de mensagem simples que representa uma "intenção" de fazer alguma coisa. Por exemplo, se seu aplicativo deseja exibir uma página da web, ele expressa seu "Intent" para exibir a URL criando uma instância de Intent e entregando-a ao sistema. O sistema localiza outro trecho de código (nesse caso, o Navegador) que sabe como lidar com essa Intenção e a executa. As intenções também podem ser usadas para transmitir eventos interessantes (como uma notificação) em todo o sistema. Consulte https://developer.android.com/reference/android/content/Intent.html .

  • ContentProviders : um ContentProvider é um armazém de dados que fornece acesso aos dados no dispositivo; o exemplo clássico é o ContentProvider usado para acessar a lista de contatos do usuário. Um aplicativo pode acessar dados que outros aplicativos expuseram por meio de um ContentProvider e também pode definir seus próprios ContentProviders para expor seus próprios dados. Consulte https://developer.android.com/reference/android/content/ContentProvider.html .

Embora seja possível implementar o IPC usando outros mecanismos, como soquetes de rede ou arquivos graváveis ​​pelo mundo, essas são as estruturas recomendadas do Android IPC. Os desenvolvedores do Android serão incentivados a usar as melhores práticas para proteger os dados dos usuários e evitar a introdução de vulnerabilidades de segurança.

APIs sensíveis a custos

Uma API sensível ao custo é qualquer função que possa gerar um custo para o usuário ou a rede. A plataforma Android colocou APIs sensíveis ao custo na lista de APIs protegidas controladas pelo sistema operacional. O usuário terá que conceder permissão explícita para aplicativos de terceiros que solicitem o uso de APIs sensíveis ao custo. Essas APIs incluem:

  • Telefonia
  • SMS / MMS
  • Rede / Dados
  • Faturamento no aplicativo
  • Acesso NFC

O Android 4.2 adiciona mais controle sobre o uso de SMS. O Android fornecerá uma notificação se um aplicativo tentar enviar SMS para um código curto que usa serviços premium que podem causar cobranças adicionais. O usuário pode optar por permitir que o aplicativo envie ou bloqueie a mensagem.

Acesso ao cartão SIM

O acesso de baixo nível ao cartão SIM não está disponível para aplicativos de terceiros. O sistema operacional lida com todas as comunicações com o cartão SIM, incluindo o acesso a informações pessoais (contatos) na memória do cartão SIM. Os aplicativos também não podem acessar os comandos AT, pois são gerenciados exclusivamente pelo RIL (Radio Interface Layer). O RIL não fornece APIs de alto nível para esses comandos.

Informação pessoal

O Android colocou APIs que fornecem acesso aos dados do usuário no conjunto de APIs protegidas. Com o uso normal, os dispositivos Android também acumulam dados do usuário em aplicativos de terceiros instalados pelos usuários. Os aplicativos que optarem por compartilhar essas informações podem usar as verificações de permissão do sistema operacional Android para proteger os dados de aplicativos de terceiros.

Acesso a dados confidenciais do usuário disponíveis apenas através de APIs protegidas

Figura 2. O acesso a dados confidenciais do usuário está disponível apenas através de APIs protegidas

Os provedores de conteúdo do sistema que provavelmente contêm informações pessoais ou de identificação pessoal, como contatos e calendário, foram criados com permissões claramente identificadas. Essa granularidade fornece ao usuário uma indicação clara dos tipos de informações que podem ser fornecidas ao aplicativo. Durante a instalação, um aplicativo de terceiros pode solicitar permissão para acessar esses recursos. Se a permissão for concedida, o aplicativo poderá ser instalado e terá acesso aos dados solicitados a qualquer momento quando estiver instalado.

Quaisquer aplicativos que coletem informações pessoais, por padrão, terão esses dados restritos apenas ao aplicativo específico. Se um aplicativo optar por disponibilizar os dados para outros aplicativos pelo IPC, o aplicativo que concede acesso pode aplicar permissões ao mecanismo IPC imposto pelo sistema operacional.

Dispositivos de entrada de dados sensíveis

Os dispositivos Android freqüentemente fornecem dispositivos de entrada de dados confidenciais que permitem que os aplicativos interajam com o ambiente ao redor, como câmera, microfone ou GPS. Para que um aplicativo de terceiros acesse esses dispositivos, primeiro ele deve receber explicitamente o acesso do usuário através do uso de Permissões do SO Android. Após a instalação, o instalador solicitará o usuário solicitando permissão ao sensor por nome.

Se um aplicativo quiser saber a localização do usuário, ele precisará de uma permissão para acessar a localização do usuário. Após a instalação, o instalador solicitará ao usuário que pergunte se o aplicativo pode acessar o local do usuário. A qualquer momento, se o usuário não desejar que nenhum aplicativo acesse sua localização, ele poderá executar o aplicativo "Configurações", ir para "Localização e segurança" e desmarcar as opções "Usar redes sem fio" e "Ativar satélites GPS" . Isso desativará os serviços baseados em localização para todos os aplicativos no dispositivo do usuário.

Metadados do dispositivo

O Android também se esforça para restringir o acesso a dados que não são intrinsecamente sensíveis, mas podem revelar indiretamente características sobre o usuário, preferências do usuário e a maneira como eles usam um dispositivo.

Por padrão, os aplicativos não têm acesso aos logs do sistema operacional, histórico do navegador, número de telefone ou informações de identificação de hardware / rede. Se um aplicativo solicitar acesso a essas informações no momento da instalação, o instalador solicitará ao usuário que pergunte se o aplicativo pode acessar as informações. Se o usuário não conceder acesso, o aplicativo não será instalado.

Autoridades de certificação

O Android inclui um conjunto de autoridades de certificação do sistema instaladas, que são confiáveis ​​em todo o sistema. Antes do Android 7.0, os fabricantes de dispositivos podiam modificar o conjunto de CAs enviadas em seus dispositivos. No entanto, os dispositivos executando 7.0 e acima terão um conjunto uniforme de CAs do sistema, pois a modificação pelos fabricantes de dispositivos não será mais permitida.

Para ser adicionada como uma nova CA pública ao conjunto de ações do Android, a CA deve concluir o Processo de Inclusão de CA da Mozilla e, em seguida, registrar uma solicitação de recurso no Android ( https://code.google.com/p/android/issues/entry ) para que a CA seja adicionada à CA Android do estoque definida no Android Open Source Project (AOSP).

Ainda existem CAs específicas do dispositivo e não devem ser incluídas no conjunto principal de CAs AOSP, como as CAs privadas das operadoras, que podem ser necessárias para acessar com segurança componentes da infraestrutura da operadora, como gateways SMS / MMS. Os fabricantes de dispositivos são incentivados a incluir as CAs privadas apenas nos componentes / aplicativos que precisam confiar nessas CAs. Para mais detalhes, consulte Configuração de segurança de rede .

Assinatura do aplicativo

A assinatura de código permite que os desenvolvedores identifiquem o autor do aplicativo e atualizem seu aplicativo sem criar interfaces e permissões complicadas. Todo aplicativo executado na plataforma Android deve ser assinado pelo desenvolvedor. Os aplicativos que tentam instalar sem serem assinados são rejeitados pelo Google Play ou pelo instalador do pacote no dispositivo Android.

No Google Play, a assinatura do aplicativo supera a confiança que o Google tem com o desenvolvedor e a confiança que o desenvolvedor tem com o aplicativo. Os desenvolvedores sabem que seu aplicativo é fornecido, sem modificação para o dispositivo Android; e os desenvolvedores podem ser responsabilizados pelo comportamento de seus aplicativos.

No Android, a assinatura do aplicativo é a primeira etapa para colocar um aplicativo em sua caixa de proteção de aplicativos. O certificado do aplicativo assinado define qual ID do usuário está associado a qual aplicativo; aplicativos diferentes são executados sob diferentes IDs de usuário. A assinatura do aplicativo garante que um aplicativo não possa acessar nenhum outro aplicativo, exceto por meio do IPC bem definido.

Quando um aplicativo (arquivo APK) é instalado em um dispositivo Android, o Gerenciador de Pacotes verifica se o APK foi assinado corretamente com o certificado incluído nesse APK. Se o certificado (ou, mais precisamente, a chave pública no certificado) corresponder à chave usada para assinar qualquer outro APK no dispositivo, o novo APK terá a opção de especificar no manifesto que compartilhará um UID com o outro da mesma forma APKs assinados.

Os aplicativos podem ser assinados por terceiros (OEM, operadora, mercado alternativo) ou autoassinados. O Android fornece assinatura de código usando certificados autoassinados que os desenvolvedores podem gerar sem assistência ou permissão externa. Os pedidos não precisam ser assinados por uma autoridade central. O Android atualmente não executa a verificação da CA para certificados de aplicativo.

Os aplicativos também podem declarar permissões de segurança no nível de proteção de assinatura, restringindo o acesso apenas aos aplicativos assinados com a mesma chave, mantendo UIDs e caixas de proteção de aplicativos distintas. Um relacionamento mais próximo com uma Sandbox de Aplicativo compartilhada é permitido por meio do recurso UID compartilhado, no qual dois ou mais aplicativos assinados com a mesma chave de desenvolvedor podem declarar um UID compartilhado em seu manifesto.

Verificação de aplicativo

O Android 4.2 e posterior suportam a verificação de aplicativos. Os usuários podem optar por ativar "Verificar aplicativos" e ter os aplicativos avaliados por um verificador de aplicativo antes da instalação. A verificação do aplicativo pode alertar o usuário se eles tentarem instalar um aplicativo que possa ser prejudicial; se um aplicativo for especialmente ruim, ele pode bloquear a instalação .

Gerenciamento de direitos digitais

A plataforma Android fornece uma estrutura DRM extensível que permite que os aplicativos gerenciem conteúdo protegido por direitos de acordo com as restrições de licença associadas ao conteúdo. A estrutura DRM suporta muitos esquemas DRM; quais esquemas de DRM que um dispositivo suporta é deixado para o fabricante do dispositivo.

A estrutura do DRM do Android é implementada em duas camadas arquiteturais (veja a figura abaixo):

  • Uma API de estrutura DRM, que é exposta a aplicativos por meio da estrutura de aplicativos Android e é executada na Dalvik VM para aplicativos padrão.

  • Um gerenciador de DRM de código nativo, que implementa a estrutura DRM e expõe uma interface para plug-ins (agentes) de DRM para lidar com o gerenciamento de direitos e descriptografia para vários esquemas de DRM

Arquitetura de gerenciamento de direitos digitais na plataforma Android

Figura 3. Arquitetura do gerenciamento de direitos digitais na plataforma Android