Segurança

Os recursos deste guia descrevem os recursos de gerenciamento de segurança que você pode implementar no seu app controlador de política de dispositivo (DPC). Este documento contém exemplos de código. Também é possível usar o app Test DPC como uma fonte de exemplo de código para os recursos empresariais do Android.

Um app de DPC pode ser executado no modo "Proprietário do perfil" em dispositivos pessoais ou no proprietário do dispositivo em dispositivos totalmente gerenciados. Esta tabela indica quais recursos estão disponíveis quando o DPC é executado no modo de proprietário do perfil ou de proprietário do dispositivo:

Recurso	Proprietário do perfil	Proprietário do dispositivo
Desativar o acesso a apps	✓	✓
Bloquear apps de fontes desconhecidas	✓	✓
Restringir contas no Google Play	✓	✓
Ativar a proteção contra redefinição de fábrica para empresas		✓
Monitorar registros de processos corporativos e relatórios remotos de bugs		✓
Conceder e remover acesso a um certificado do cliente	✓	✓
Redefinição de senha segura	✓	✓
Desafio de segurança do perfil de trabalho	✓

Desativar o acesso a apps

Para organizações que querem impedir que os funcionários joguem ou assistam YouTube em um dispositivo Android durante determinados horários do dia, ou em certos dias da semana, um DPC pode desativar temporariamente o acesso aos aplicativos.

Para desativar o acesso a apps, um DPC em execução no modo "Proprietário do dispositivo" ou "Proprietário do perfil" configura setPackagesSuspended(), e o app selecionado age como se estiver desativado (o Acesso rápido do Google esmaece o aplicativo). Quando um usuário toca no app, ele vê uma caixa de diálogo do sistema informando que o app está suspenso.

Enquanto está suspenso, ele não pode iniciar atividades, e enviar notificações para o são suprimidos. Os pacotes suspensos não aparecem na visão geral , não podem mostrar caixas de diálogo (incluindo avisos e snackbars) e não pode reproduzir áudio ou vibrar o dispositivo.

A tela de início pode descobrir se um app está suspenso chamando o método isPackageSuspended(). Para detalhes sobre como configurar o app suspensão, consulte setPackagesSuspended.

Bloquear apps de fontes desconhecidas

Os apps que não são instalados do Google Play (ou de outras app stores confiáveis) não são chamados apps de fontes desconhecidas. Dispositivos e dados podem estar em maior risco quando as pessoas instalarem esses aplicativos.

Para impedir que alguém instale apps de fontes desconhecidas, os componentes do administrador do que os dispositivos totalmente gerenciados e os perfis de trabalho Restrição de usuário do DISALLOW_INSTALL_UNKNOWN_SOURCES.

Restrição em todo o dispositivo do perfil de trabalho

Quando o administrador de um perfil de trabalho adicionar DISALLOW_INSTALL_UNKNOWN_SOURCES, a restrição se aplica apenas ao perfil de trabalho. No entanto, o administrador de um projeto pode aplicar uma restrição em todo o dispositivo definindo uma configuração gerenciada do Google Play. A restrição que abrange todo o dispositivo é disponível no Android 8.0 (ou superior) quando o app Google Play instalado versão 80812500 ou mais recente.

Para restringir as instalações de apps ao Google Play, siga estas etapas:

1. Definir um pacote de configuração gerenciada para o pacote do Google Play com.android.vending:
2. No pacote, coloque um valor booleano para o valor Tecla verify_apps:device_wide_unknown_source_block.
3. Adicione a restrição de usuário ENSURE_VERIFY_APPS.

O exemplo a seguir mostra como verificar se o Google Play é compatível com esse e defina o valor como true:

Kotlin

internal val DEVICE_WIDE_UNKNOWN_SOURCES = "verify_apps:device_wide_unknown_source_block"
internal val GOOGLE_PLAY_APK = "com.android.vending"

// ...

// Add the setting to Google Play's existing managed config. Supported in
// Google Play version 80812500 or higher--older versions ignore unsupported
// settings.
val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
var existingConfig = dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK)
val newConfig = Bundle(existingConfig)
newConfig.putBoolean(DEVICE_WIDE_UNKNOWN_SOURCES, true)
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig)

// Make sure that Google Play Protect verifies apps.
dpm.addUserRestriction(adminName, UserManager.ENSURE_VERIFY_APPS)
dpm.addUserRestriction(adminName, UserManager.DISALLOW_INSTALL_UNKNOWN_SOURCES)

Java

static final String DEVICE_WIDE_UNKNOWN_SOURCES =
    "verify_apps:device_wide_unknown_source_block";
static final String GOOGLE_PLAY_APK = "com.android.vending";

// ...


// Add the setting to Google Play's existing managed config. Supported in
// Google Play version 80812500 or higher--older versions ignore unsupported
// settings.
DevicePolicyManager dpm =
    (DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE);
Bundle existingConfig =
    dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK);
Bundle newConfig = new Bundle(existingConfig);
newConfig.putBoolean(DEVICE_WIDE_UNKNOWN_SOURCES, true);
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig);

// Make sure that Google Play Protect verifies apps.
dpm.addUserRestriction(adminName, UserManager.ENSURE_VERIFY_APPS);
dpm.addUserRestriction(adminName, UserManager.DISALLOW_INSTALL_UNKNOWN_SOURCES);

A interface do usuário nas configurações do sistema permanece ativa, mas o sistema bloqueia instalação do app. Essa restrição afeta instalações futuras. e os apps instalados continuam no dispositivo. Os usuários do dispositivo podem continuar instalando apps no perfil pessoal usando o Android Debug Bridge (adb).

Para saber mais sobre fontes desconhecidas, leia Distribuição alternativa .

Restringir contas no Google Play

Às vezes, uma organização pode querer permitir que as pessoas adicionem informações pessoais do usuário (para ler e-mails no Gmail, por exemplo), mas não quer a conta pessoal para instalar apps. Seu DPC pode definir uma lista de contas que as pessoas podem usar Google Play

Os componentes do administrador de dispositivos totalmente gerenciados ou perfis de trabalho podem restringir o definindo uma configuração gerenciada para o Google Play. A conta a restrição está disponível quando a versão do app Google Play instalado é 80970100 ou superior.

Para limitar as contas no Google Play, faça o seguinte:

1. Definir um pacote de configuração gerenciada para o pacote do Google Play com.android.vending:
2. No pacote, coloque os endereços de e-mail separados por vírgula como um valor de string para a tecla allowed_accounts.

O exemplo a seguir mostra como limitar contas:

Kotlin

internal val ALLOWED_ACCOUNTS = "allowed_accounts"
internal val GOOGLE_PLAY_APK = "com.android.vending"

// ...

// Limit Google Play to one work and one personal account. Use
// a comma-separated list of account email addresses (usernames).
val googleAccounts = "[e-mail],[e-mail]"

// Supported in Google Play version 80970100 or higher.
val existingConfig = dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK)
val newConfig = Bundle(existingConfig)
newConfig.putString(ALLOWED_ACCOUNTS, googleAccounts)
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig)

Java

static final String ALLOWED_ACCOUNTS = "allowed_accounts";
static final String GOOGLE_PLAY_APK = "com.android.vending";

// ...


// Limit Google Play to one work and one personal account. Use
// a comma-separated list of account email addresses (usernames).
String googleAccounts = "[e-mail],[e-mail]";

// Supported in Google Play version 80970100 or higher.
Bundle existingConfig =
    dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK);
Bundle newConfig = new Bundle(existingConfig);
newConfig.putString(ALLOWED_ACCOUNTS, googleAccounts);
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig);

Para limitar o Google Play apenas à conta de trabalho, defina allowed_accounts como o conta gerenciada assim que o seu DPC souber o endereço de e-mail dessa conta. Um string vazia impede que as pessoas usem qualquer conta no Google Play.

Ativar a proteção contra redefinição de fábrica para empresas

Com a proteção contra redefinição de fábrica, as organizações podem especificar quais As Contas do Google podem provisionar um dispositivo redefinido para a configuração original.

A proteção contra redefinição de fábrica para o consumidor foi criada para impedir o roubo de dispositivos. Antes permitir que qualquer pessoa provisione o dispositivo após uma redefinição de fábrica não autorizada (como como usa um EMM), o assistente de configuração exige que o usuário faça a autenticação em qualquer Contas do Google que estavam no perfil pessoal do dispositivo.

Em um ambiente corporativo, a redefinição para a configuração original é uma ferramenta importante para gerenciar aos dispositivos de um funcionário quando ele sai da organização. No entanto, se o a organização não sabe as credenciais da conta de um funcionário, redefinir para a configuração original pode bloquear a capacidade de uma organização de emitir um dispositivo funcionário.

Observação: a proteção contra redefinição de fábrica vai ficar desativada se o desbloqueio de OEM estiver ativado no Opções do desenvolvedor.

Controlar o provisionamento após uma redefinição para a configuração original

No modo "Proprietário do dispositivo", o DPC pode usar setFactoryResetProtectionPolicy() para controlar quais contas são autorizado a provisionar um dispositivo após a redefinição para a configuração original. Se essa configuração for definido como null ou como uma lista vazia, as contas autorizadas a provisionar um dispositivo após a redefinição de fábrica são as contas no perfil pessoal do dispositivo.

Um DPC pode configurar essas contas durante todo o ciclo de vida dispositivo.

Observação: o DPC usa o valor userID para configurar quais contas podem provisionar. depois de uma redefinição para a configuração original.

1. O administrador de TI pode usar o método people.get da API People. com o valor especial me. Isso recupera o userId do está conectada. O userID é retornado na chave resourceName em o formato people/[userId] como uma string de números inteiros. Contas recém-criadas podem não estará disponível para redefinição de fábrica por 72 horas.
2. Você também pode permitir que um ou mais administradores de TI desbloqueiem o dispositivo após redefinir para a configuração original. Peça que cada um dos administradores de TI faça login na Conta do Google. siga a etapa 1 e compartilhe o userId com você para adicioná-las userIds à lista na próxima etapa.
3. O DPC define uma restrição de aplicativo apropriada usando setFactoryResetProtectionPolicy() para definir a lista de userId que pode provisionar um dispositivo redefinido para a configuração original.
4. O DPC ativa as contas que podem provisionar dispositivos depois da fábrica redefinido enviando a transmissão com.google.android.gms.auth.FRP_CONFIG_CHANGED como uma intent explícita para evitar queda devido a restrições em segundo plano.

Kotlin

const val ACTION_FRP_CONFIG_CHANGED =
    "com.google.android.gms.auth.FRP_CONFIG_CHANGED"
const val GMSCORE_PACKAGE = "com.google.android.gms"

// ...

// List of userId that can provision a factory reset device.
// You can use the value returned calling people/me endpoint.
val accountIds = listOf("000000000000000000000")

dpm.setFactoryResetProtectionPolicy(
    adminName,
    FactoryResetProtectionPolicy.Builder()
        .setFactoryResetProtectionAccounts(accountIds)
        .setFactoryResetProtectionEnabled(true)
        .build()
)

val frpChangedIntent = Intent(ACTION_FRP_CONFIG_CHANGED)

frpChangedIntent.setPackage(GMSCORE_PACKAGE)
context.sendBroadcast(frpChangedIntent)

Java

static final String ACTION_FRP_CONFIG_CHANGED =
    "com.google.android.gms.auth.FRP_CONFIG_CHANGED";
static final String GMSCORE_PACKAGE = "com.google.android.gms";

// ...

// List of userId that can provision a factory reset device.
// You can use the value returned calling people/me endpoint.
List<String> accountIds = new ArrayList<String>();
accountIds.add("000000000000000000000");

dpm.setFactoryResetProtectionPolicy(
    adminName,
    new FactoryResetProtectionPolicy.Builder()
        .setFactoryResetProtectionAccounts(accountIds)
        .setFactoryResetProtectionEnabled(true)
        .build());

Intent frpChangedIntent = new Intent(ACTION_FRP_CONFIG_CHANGED);

frpChangedIntent.setPackage(GMSCORE_PACKAGE);
context.sendBroadcast(frpChangedIntent);

Legado

Para dispositivos que não podem usar setFactoryResetProtectionPolicy(), introduzidos com API de nível 30, o DPC pode usar setApplicationRestrictions para adicionar as contas escolhidas para a configuração gerenciada factoryResetProtectionAdmin para o pacote com.google.android.gms.

Kotlin

const val GOOGLE_PLAY_APK = "com.android.vending"
const val FACTORY_RESET_PROTECTION_ADMIN = "factoryResetProtectionAdmin"
const val DISABLE_FACTORY_RESET_PROTECTION_ADMIN = "disableFactoryResetProtectionAdmin"
const val GMSCORE_PACKAGE = "com.google.android.gms"

// ...

val existingConfig = dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK)
val newConfig = Bundle(existingConfig)
newConfig.putBoolean(DISABLE_FACTORY_RESET_PROTECTION_ADMIN, false)
newConfig.putString(FACTORY_RESET_PROTECTION_ADMIN, googleAccounts)
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig)

val frpChangedIntent = Intent(ACTION_FRP_CONFIG_CHANGED)

frpChangedIntent.setPackage(GMSCORE_PACKAGE)
context.sendBroadcast(frpChangedIntent)

Java

static final String GOOGLE_PLAY_APK = "com.android.vending";
static final String FACTORY_RESET_PROTECTION_ADMIN = "factoryResetProtectionAdmin";
static final String DISABLE_FACTORY_RESET_PROTECTION_ADMIN = "disableFactoryResetProtectionAdmin";
static final String GMSCORE_PACKAGE = "com.google.android.gms";

// ...

Bundle existingConfig =
        dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK);
Bundle newConfig = new Bundle(existingConfig);
newConfig.putBoolean(DISABLE_FACTORY_RESET_PROTECTION_ADMIN, false);
newConfig.putStringArray(FACTORY_RESET_PROTECTION_ADMIN,
        accountIds.toArray(new String[accountIds.size()]));
dpm.setApplicationRestrictions(adminName, GOOGLE_PLAY_APK, newConfig);

Intent frpChangedIntent = new Intent(ACTION_FRP_CONFIG_CHANGED);

frpChangedIntent.setPackage(GMSCORE_PACKAGE);
context.sendBroadcast(frpChangedIntent);

Desativar a proteção contra redefinição de fábrica para empresas

Para desativar a proteção contra redefinição de fábrica, seu DPC pode usar setFactoryResetProtectionPolicy()Transmitindo o valor null.

Kotlin

const val ACTION_FRP_CONFIG_CHANGED =
    "com.google.android.gms.auth.FRP_CONFIG_CHANGED"
const val GMSCORE_PACKAGE = "com.google.android.gms"

// ...

dpm.setFactoryResetProtectionPolicy(adminName, null)

val frpChangedIntent = Intent(ACTION_FRP_CONFIG_CHANGED)

frpChangedIntent.setPackage(GMSCORE_PACKAGE)
context.sendBroadcast(frpChangedIntent)

Java

static final String ACTION_FRP_CONFIG_CHANGED =
    "com.google.android.gms.auth.FRP_CONFIG_CHANGED";
static final String GMSCORE_PACKAGE = "com.google.android.gms";

// ...

dpm.setFactoryResetProtectionPolicy(adminName, null);

Intent frpChangedIntent = new Intent(ACTION_FRP_CONFIG_CHANGED);

frpChangedIntent.setPackage(GMSCORE_PACKAGE);
context.sendBroadcast(frpChangedIntent);

Legado

Para dispositivos que não podem usar setFactoryResetProtectionPolicy(), introduzidos com API de nível 30, o DPC pode usar setApplicationRestrictions para definir uma chave de true no disableFactoryResetProtectionAdmin configuração para o pacote com.google.android.gms.

Observação: basta deixar a configuração gerenciada factoryResetProtectionAdmin sem definição. não desativa a proteção contra redefinição de fábrica.

Kotlin

const val GOOGLE_PLAY_APK = "com.android.vending"
const val FACTORY_RESET_PROTECTION_ADMIN = "factoryResetProtectionAdmin"
const val DISABLE_FACTORY_RESET_PROTECTION_ADMIN = "disableFactoryResetProtectionAdmin"
const val GMSCORE_PACKAGE = "com.google.android.gms"

// ...

val existingConfig = dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK)
val newConfig = Bundle(existingConfig)
newConfig.putBoolean(DISABLE_FACTORY_RESET_PROTECTION_ADMIN, true)

dpm.setApplicationRestrictions(
    adminName, GOOGLE_PLAY_SERVICES_PACKAGE, restrictions
)

val frpChangedIntent = Intent(ACTION_FRP_CONFIG_CHANGED)

frpChangedIntent.setPackage(GMSCORE_PACKAGE)
context.sendBroadcast(frpChangedIntent)

Java

static final String GOOGLE_PLAY_APK = "com.android.vending";
static final String FACTORY_RESET_PROTECTION_ADMIN = "factoryResetProtectionAdmin";
static final String DISABLE_FACTORY_RESET_PROTECTION_ADMIN = "disableFactoryResetProtectionAdmin";
static final String GMSCORE_PACKAGE = "com.google.android.gms";

// ...

Bundle existingConfig =
        dpm.getApplicationRestrictions(adminName, GOOGLE_PLAY_APK);
Bundle newConfig = new Bundle(existingConfig);
newConfig.putBoolean(DISABLE_FACTORY_RESET_PROTECTION_ADMIN, true);

dpm.setApplicationRestrictions(
    adminName, GOOGLE_PLAY_SERVICES_PACKAGE, restrictions);

Intent frpChangedIntent = new Intent(ACTION_FRP_CONFIG_CHANGED);

frpChangedIntent.setPackage(GMSCORE_PACKAGE);
context.sendBroadcast(frpChangedIntent);

Monitore registros de processos corporativos e relatórios remotos de bugs

No console de EMM, um administrador pode monitorar dispositivos totalmente gerenciados registros de processos e relatórios de bugs remotos.

Registrar atividade empresarial do dispositivo

Um DPC em execução no modo "Proprietário do dispositivo" pode identificar atividades suspeitas remotamente rastrear a atividade do dispositivo, incluindo inicializações de apps, Android Debug Bridge (adb); atividade física e desbloqueios de tela. Os registros do processo não exigem o consentimento do usuário.

Para ativar ou desativar a geração de registros, um DPC chama setSecurityLoggingEnabled().

Quando um novo lote de registros está disponível, um DeviceAdminReceiver recebe o Callback onSecurityLogsAvailable(). Para recuperar os registros (depois receber o callback), o DPC vai chamar retrieveSecurityLogs().

Os DPCs também podem chamar retrievePreRebootSecurityLogs() para buscar a segurança registros gerados no ciclo de reinicialização anterior. É o intervalo entre última reinicialização do dispositivo e a reinicialização anterior. Dispositivos sem suporte retrieveSecurityLogs() retorna null. Se o app recuperar registros usando retrievePreRebootSecurityLogs() e retrieveSecurityLogs(), será preciso para verificar se há entradas duplicadas.
Observação: esse recurso só registra a atividade em dispositivos totalmente gerenciados com um único ou usuários afiliados no dispositivo. Este recurso não funciona dispositivos pessoais, porque registra a atividade em todo o dispositivo.

Essa configuração pode ser útil na auditoria pós-segurança, porque registra seguintes tipos de ações:

• Sempre que o app for iniciado. Isso pode ajudar a identificar se há malware que começa com um app comprometido.
• Tentativas de desbloqueio malsucedidas em um dispositivo. Isso pode identificar se há várias tentativas de desbloqueio malsucedidas em um curto período de tempo.
• Comandos adb potencialmente nocivos quando um usuário se conecta. o dispositivo a um computador usando um cabo USB.

Para detalhes sobre como ler registros, consulte SecurityLog.

Enquanto você desenvolve e testa, é possível forçar o sistema a fazer registros de segurança existentes disponíveis para seu DPC. Você não precisa esperar em lote. No Android 9.0 (nível 28 da API) ou versões mais recentes, execute o seguinte: Comando do Android Debug Bridge (adb) no seu terminal:

adb shell dpm force-security-logs

O sistema limita a frequência com que você pode usar a ferramenta e informa qualquer desaceleração intencional na saída do terminal. Se houver registros disponíveis, O DPC recebe o callback onSecurityLogsAvailable().

Solicitar remotamente um relatório do bug

Um DPC executado no modo "Proprietário do dispositivo" pode solicitar remotamente relatórios de bugs para o usuário dispositivos com apenas um usuário ou usuários afiliados. O relatório do bug captura a atividade do dispositivo no momento exato em que o relatório do bug é solicitado, mas também pode incluem atividades das últimas horas, dependendo da frequência com que o logcat atualizações de buffer.

Para solicitar relatórios de bugs remotamente, o DPC chama requestBugreport():

• Se um usuário aceitar compartilhar o relatório do bug, o DPC receberá o bug gerar um relatório usando onBugreportShared()
• Se um usuário negar o compartilhamento do relatório do bug, o DPC receberá uma solicitação de solicitação de mensagem negada usando onBugreportSharingDeclined()
• Se o relatório falhar, o DPC verá onBugreportFailed() com BUGREPORT_FAILURE_FAILED_COMPLETING ou BUGREPORT_FAILURE_FILE_NO_LONGER_AVAILABLE.

Conceder e remover o acesso a um certificado do cliente

Se um DPC em execução no modo "Proprietário do perfil" ou "Proprietário do dispositivo" autorizar um app de terceiros capacidade de gerenciar certificados, o aplicativo pode conceder acesso certificados instalados sem a intervenção do usuário. Para instalar um certificado que todos os apps em um perfil podem acessar, use installKeyPair().

Para saber quais parâmetros configurar, consulte installKeyPair(). Este recurso funciona em conjunto com a API existente para gerenciar certificados.

Cenário de implantação

Sem o método installKeyPair():

• Os usuários precisam tocar no nome do certificado e em Permitir todas as vezes. se quer conceder acesso a um certificado.
• Os usuários recebem uma solicitação ao instalar um certificado e precisam nomear certificado.

Com o método installKeyPair():

• Os usuários não precisarão tocar em Permitir sempre que quiserem conceder acesso a um certificado.
• Os usuários não podem renomear certificados.
• Os administradores têm mais controle, pois podem bloquear certificados para aplicativos que não devem ter acesso a certificados específicos.

Remover um certificado do cliente

Depois de conceder acesso a um certificado do cliente, para remover remotamente o cliente certificados instalados pelo installKeyPair(), chame removeKeyPair()

Um DPC executado no modo "Proprietário do dispositivo" ou "Proprietário do perfil" ou delegado o instalador de certificado pode chamar removeKeyPair(). Com isso, certificado e par de chaves privadas instalados em um determinado alias de chave privada.

Cenário de implantação

Use este recurso se uma organização estiver migrando para uma forma mais segura de cliente certificado. Se um administrador lançar um novo certificado e a respectiva distribuição levar muito tempo, o administrador poderá revogar a certificados após a migração.

Redefinição de senha segura

Seu DPC pode redefinir a senha de um usuário autorizando a alteração com uma um token seguro e pré-registrado. Proprietários de dispositivos e de perfil podem ligar para o modo seguro APIs de redefinição de senha para mudar a senha de dispositivos e perfis de trabalho respectivamente. A redefinição de senha segura substitui resetPassword() pelo seguintes melhorias:

• Seu DPC pode redefinir a senha antes que o usuário desbloqueie o dispositivo ou perfil. após a reinicialização em dispositivos a criptografia baseada em arquivos.
• O Android Keystore retém chaves autenticadas pelo usuário após a redefinição da senha.

Use a redefinição de senha segura se o build do DPC for destinado ao Android 8.0 (API nível 26) ou superior. Chamar resetPassword() gera uma SecurityException em DPCs destinados ao Android 8.0 ou versões mais recentes, então você pode precisa atualizar seu DPC.

Definir e ativar um token

Seu DPC precisa definir e ativar um token antes de redefinir uma senha. Devido ao seu DPC pode não conseguir usar o token imediatamente, você define o token antes que um administrador de TI precise usá-la.

Um token de redefinição de senha é um valor aleatório com criptografia forte e precisa ter pelo menos 32 bytes. Crie um token para cada dispositivo e perfil. Não reutilizar ou compartilhar os tokens gerados.

Aviso :trate o token como você trataria as credenciais do usuário. Nunca armazene os token no dispositivo como texto simples, especialmente no armazenamento criptografado do dispositivo. Seu organização deve considerar cuidadosamente como armazenar tokens em um servidor e quem tem acesso aos tokens. Os tokens podem estar sujeitos a solicitações oficiais para acesso ao dispositivo.

Recomendamos armazenar tokens, ou os meios para descriptografar um token criptografado, em uma servidor. Se você armazenar tokens localmente no armazenamento criptografado por credenciais, seu DPC não pode redefinir a senha até que o usuário desbloqueie o dispositivo ou perfil. Se você armazenar os tokens localmente no armazenamento criptografado do dispositivo, que fica comprometido; um invasor pode usar o token para obter acesso a um perfil de trabalho ou a um usuário.

Você pode gerar um novo token no DPC ou buscar um token em um servidor. A exemplo abaixo mostra um DPC gerando o próprio token e relatando-o para um servidor:

Kotlin

val token = ByteArray(32)

// Generate a new token
val random = SecureRandom()
random.nextBytes(token)

// Set the token to use at a later date
val success: Boolean
success = dpm.setResetPasswordToken(DeviceAdminReceiver.getComponentName(context), token)

// Activate the token and update success variable...

// Store the token on a server
if (success) {
 sendTokenToServer(token)
}

Java

byte token[] = new byte[32]; // Minimum size token accepted

// Generate a new token
SecureRandom random = new SecureRandom();
random.nextBytes(token);

// Set the token to use at a later date
boolean success;
success = dpm.setResetPasswordToken(DeviceAdminReceiver.getComponentName(getContext()), token);

// Activate the token and update success variable ...

// Store the token on a server
if (success) {
 sendTokenToServer(token);
}

Na maioria dos casos, seu DPC precisa ativar um token depois de configurá-lo. Mas, quando o usuário não tem uma senha para a tela de bloqueio, o sistema ativa um token imediatamente. Para ativar um token, peça para o usuário confirmar as credenciais. Seu DPC pode chamar o método KeyguardManager createConfirmDeviceCredentialIntent() para ter um Intent que inicie o confirmação. Explique ao usuário do dispositivo na interface do usuário por que você está solicitando a autenticação. O snippet abaixo mostra como ativar no seu DPC:

Kotlin

// In your DPC, you'll need to localize the user prompt
val ACTIVATE_TOKEN_PROMPT = "Use your credentials to enable remote password reset"
val ACTIVATE_TOKEN_REQUEST = 1

// Create or fetch a token and set it in setResetPasswordToken() ...
val keyguardManager = context.getSystemService(Context.KEYGUARD_SERVICE) as KeyguardManager
val confirmIntent = keyguardManager.createConfirmDeviceCredentialIntent(null, ACTIVATE_TOKEN_PROMPT)

if (confirmIntent != null) {
 startActivityForResult(confirmIntent, ACTIVATE_TOKEN_REQUEST)
 // Check your onActivityResult() callback for RESULT_OK
} else {
 // Null means the user doesn't have a lock screen so the token is already active.
 // Call isResetPasswordTokenActive() if you need to confirm
}

Java

// In your DPC, you'll need to localize the user prompt
static final String ACTIVATE_TOKEN_PROMPT =
 "Use your credentials to enable remote password reset";
static final int ACTIVATE_TOKEN_REQUEST = 1;

// Create or fetch a token and set it in setResetPasswordToken() ...

KeyguardManager keyguardManager = (KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE);
Intent confirmIntent = keyguardManager.createConfirmDeviceCredentialIntent(
  null, ACTIVATE_TOKEN_PROMPT);

if (confirmIntent != null) {
 startActivityForResult(confirmIntent, ACTIVATE_TOKEN_REQUEST);
 // Check your onActivityResult() callback for RESULT_OK
} else {
 // Null means the user doesn't have a lock screen so the token is already active.
 // Call isResetPasswordTokenActive() if you need to confirm
}

É preciso ativar um token definido pelo DPC antes da reinicialização do dispositivo. Android armazena um token não ativado na memória e não mantém o token depois que um reiniciar o dispositivo. Se o usuário reinicializar o dispositivo antes de ativar um token, o DPC poderá definir o mesmo token novamente ou gerar um novo token.

Seu DPC pode confirmar se um token está ativo chamando isResetPasswordTokenActive() e verificando se o resultado é true.

Depois que o DPC define e ativa um token, ele é válido até que o DPC exclua ou substitui o token (ou o dispositivo é redefinido para a configuração original). O token é independente a senha e não seja afetada pela alteração ou limpeza da senha pelo usuário.

Excluir um token

É possível chamar clearResetPasswordToken() para excluir um token que seu DPC que você definiu antes. Talvez seja necessário revogar um token comprometido ou cancelar remover a capacidade de redefinição da senha. O exemplo abaixo mostra como fazer no seu DPC:

Kotlin

val dpm = getDpm()
val admin = DeviceAdminReceiver.getComponentName(requireActivity())

// Clear the token
if (!dpm.clearResetPasswordToken(admin)) {
 // Report the failure and possibly try later ...
}

Java

DevicePolicyManager dpm = getDpm();
ComponentName admin = DeviceAdminReceiver.getComponentName(getActivity());

// Clear the token
if (!dpm.clearResetPasswordToken(admin)) {
 // Report the failure and possibly try later ...
}

Redefinir a senha

Quando um administrador de TI precisar redefinir a senha, chame resetPasswordWithToken() e transmita o token que o DPC definiu e ativou com antecedência:

Kotlin

val token: ByteArray = getTokenFromServer()
val newPassword = "password"

try {
 val result: Boolean = dpm.resetPasswordWithToken(
 DeviceAdminReceiver.getComponentName(requireContext()),
 newPassword,
 token,
 0
 )

 if (result) {
 // The password is now 'password'
 } else {
 // Using 'password' doesn't meet password restrictions
 }
} catch (e: IllegalStateException) {
 // The token doesn't match the one set earlier.
}

Java

byte token[] = getTokenFromServer();
String newPassword = "password";

try {
 boolean result = dpm.resetPasswordWithToken(
  DeviceAdminReceiver.getComponentName(getContext()), newPassword, token, 0);

 if (result) {
 // The password is now 'password'
 } else {
 // Using `password` doesn't meet password restrictions
 }
} catch (IllegalStateException e) {
 // The token doesn't match the one set earlier.
}

Uma chamada para resetPasswordWithToken() retorna false, e a senha não mudar, quando a nova senha não atender às seguintes restrições:

• O número de caracteres atende a qualquer restrição de tamanho mínimo de senha. Ligação getPasswordMinimumLength() para saber se um departamento de TI o administrador definiu uma restrição de tamanho.
• O alcance e a complexidade dos caracteres da senha atendem a uma composição restrição. Chame getPasswordQuality() para saber se um departamento de TI administrador definiu uma restrição de composição.

Se as restrições de qualidade da senha não exigirem a definição de uma senha, você poderá Transmita null ou uma string vazia a resetPasswordWithToken() para remover o senha.

Desafio de segurança de perfil de trabalho

Um DPC executado no modo de proprietário do perfil pode exigir que os usuários especifiquem uma política para apps executados no perfil de trabalho. O sistema mostra a segurança um desafio quando o usuário tentar abrir qualquer aplicativo de trabalho. Se o usuário conseguir concluir o desafio de segurança, o sistema desbloqueia o perfil de trabalho e o descriptografa, se necessário.

Observação: o desafio de trabalho separado é um recurso que os usuários também podem definir. Se o usuário escolher a opção de bloqueio unificado, poderá acessar os apps de trabalho depois de desbloquear o bloqueio pessoal no dispositivo.

Como funciona o desafio de segurança do perfil de trabalho

1. Se um DPC enviar uma intent ACTION_SET_NEW_PASSWORD, o sistema solicitará para o usuário configurar um desafio de segurança.
2. O DPC também pode enviar um ACTION_SET_NEW_PARENT_PROFILE_PASSWORD para solicitar que o usuário defina um bloqueio de dispositivo.

Um DPC pode definir políticas de senha para o desafio de trabalho de forma diferente políticas para senhas de outros dispositivos. Por exemplo, o comprimento mínimo de resposta do desafio no dispositivo pode ser diferente do tamanho exigido para outros senhas. Um DPC define as políticas de desafio usando a Métodos DevicePolicyManager, como setPasswordQuality() e setPasswordMinimumLength().

Considerações

• O DPC pode redefinir a senha no perfil de trabalho, mas não pode redefinir do dispositivo (pessoal). Se um usuário escolher definir senhas de trabalho e pessoais forem iguais, resetPassword() no perfil de trabalho fará com que o que a senha seja redefinida apenas no perfil de trabalho, e a senha não será a mesma da tela de bloqueio do dispositivo.
• Um DPC pode personalizar a tela de credenciais para o desafio de trabalho usando setOrganizationColor() e setOrganizationName().
• Os administradores do dispositivo não podem usar o resetPassword() para limpar ou mudar senhas as que já foram definidas. Os administradores do dispositivo ainda podem definir uma senha, mas apenas quando o dispositivo não tem senha, PIN ou padrão.

Para mais informações, consulte getParentProfileInstance() e a referência documentação em DevicePolicyManager.