Sicurezza

Le funzionalità di questa guida descrivono le funzionalità di gestione della sicurezza che puoi implementare nell'app controller dei criteri dei dispositivi (DPC). Questo documento contiene esempi di codice e puoi anche utilizzare l'app DPC di test come origine di codice campione per le funzionalità aziendali di Android.

Un'app DPC può essere eseguita in modalità proprietario del profilo su dispositivi personali o in modalità proprietario del dispositivo su dispositivi completamente gestiti. Questa tabella indica le funzionalità disponibili quando il DPC viene eseguito in modalità proprietario profilo o proprietario dispositivo:

Disattivare l'accesso alle app

Per le organizzazioni che vogliono impedire ai dipendenti di giocare o guardare YouTube sul proprio dispositivo Android in determinati momenti della giornata o in determinati giorni della settimana, un DPC può disattivare temporaneamente l'accesso alle app.

Per disattivare l'accesso alle app, un DPC in esecuzione in modalità Proprietario del dispositivo o Proprietario del profilo configura setPackagesSuspended() e l'app selezionata si comporta come se fosse disabilitata (l'Avvio app di Google disattiva l'app). Quando un utente tocca l'app, viene visualizzata una finestra di dialogo di sistema che informa che l'app è sospesa.

Mentre un'app è sospesa non può avviare attività e le notifiche al pacchetto vengono soppresse. I pacchetti sospesi non vengono visualizzati nella schermata panoramica, non possono mostrare le finestre di dialogo (inclusi toast e snackbar) e non possono riprodurre audio o vibrare il dispositivo.

Gli Avvio app possono sapere se un'app è sospesa chiamando il metodo isPackageSuspended(). Per maggiori dettagli su come configurare la sospensione delle app, consulta setPackagesSuspended.

Blocca app provenienti da origini sconosciute

Le app che non vengono installate da Google Play (o da altri store attendibili) sono chiamate app di origini sconosciute. Dispositivi e dati possono essere più a rischio quando le persone installano queste app.

Per impedire a qualcuno di installare app da origini sconosciute, i componenti di amministrazione dei dispositivi completamente gestiti e dei profili di lavoro possono aggiungere la limitazione relativa agli utenti di DISALLOW_INSTALL_UNKNOWN_SOURCES.

Limitazione a livello di dispositivo del profilo di lavoro

Quando l'amministratore di un profilo di lavoro aggiunge DISALLOW_INSTALL_UNKNOWN_SOURCES, la limitazione si applica solo al profilo di lavoro. Tuttavia, l'amministratore di un profilo di lavoro può applicare una limitazione a livello di dispositivo impostando una configurazione gestita per Google Play. La limitazione a livello di dispositivo è disponibile su Android 8.0 (o versioni successive) se l'app Google Play installata è la versione 80812500 o successive.

Per limitare le installazioni di app a Google Play, procedi nel seguente modo:

1. Imposta un bundle di configurazione gestita per il pacchetto Google Play com.android.vending.
2. Nel bundle, inserisci un valore booleano per la chiave verify_apps:device_wide_unknown_source_block.
3. Aggiungi la limitazione relativa agli utenti per ENSURE_VERIFY_APPS.

L'esempio seguente mostra come verificare che Google Play supporti questa impostazione e impostare il valore su true:

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)

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);

L'interfaccia utente nelle impostazioni di sistema rimane attiva, ma il sistema blocca l'installazione dell'app. Questa limitazione interessa le installazioni future: le app precedentemente installate rimangono sul dispositivo. Gli utenti dei dispositivi possono continuare a installare app nel profilo personale utilizzando il Bridge di debug di Android (adb).

Per scoprire di più sulle origini sconosciute, consulta Opzioni di distribuzione alternativa.

Limitare gli account in Google Play

A volte un'organizzazione potrebbe voler consentire agli utenti di aggiungere Account Google personali (per leggere la posta in Gmail, ad esempio), ma non vuole che l'account personale installi app. Il DPC può impostare un elenco di account che gli utenti possono utilizzare in Google Play.

I componenti amministrativi di dispositivi completamente gestiti o di profili di lavoro possono limitare gli account impostando una configurazione gestita per Google Play. La limitazione relativa all'account è disponibile se l'app Google Play installata è 80970100 o versioni successive.

Per limitare gli account in Google Play:

1. Imposta un bundle di configurazione gestita per il pacchetto Google Play com.android.vending.
2. Nel pacchetto, inserisci gli indirizzi email separati da virgole come valore stringa per la chiave allowed_accounts.

L'esempio seguente mostra come limitare gli account:

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 = "ali@gmail.com,ali.connors@example.com"

// 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)

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 = "ali@gmail.com,ali.connors@example.com";

// 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);

Per limitare Google Play solo all'account di lavoro, imposta allowed_accounts sul singolo account gestito non appena il tuo DPC conosce l'indirizzo email dell'account. Una stringa vuota impedisce agli utenti di utilizzare qualsiasi account in Google Play.

Attiva la protezione ripristino dati di fabbrica aziendali

Utilizzando la protezione ripristino dati di fabbrica aziendale, le organizzazioni possono specificare quali Account Google possono eseguire il provisioning di un dispositivo di cui sono stati ripristinati i dati di fabbrica.

La protezione ripristino dati di fabbrica per gli utenti è concepita per scoraggiare il furto del dispositivo. Prima di consentire a chiunque di eseguire il provisioning del dispositivo dopo un ripristino dei dati di fabbrica non autorizzato (ad esempio tramite un EMM), la configurazione guidata richiede all'utente di eseguire l'autenticazione con qualsiasi Account Google precedentemente associato al profilo personale del dispositivo.

In un ambiente aziendale, il ripristino dei dati di fabbrica è uno strumento importante per la gestione dei dispositivi dei dipendenti quando un dipendente lascia l'organizzazione. Tuttavia, se l'organizzazione non conosce le credenziali dell'account di un dipendente, il ripristino dei dati di fabbrica può impedire all'organizzazione di fornire un dispositivo a un altro dipendente.

Controllare il provisioning dopo un ripristino dei dati di fabbrica

Quando viene eseguito in modalità Proprietario del dispositivo, il DPC può utilizzare factoryResetProtectionAdmin per controllare quali account sono autorizzati a eseguire il provisioning di un dispositivo dopo un ripristino dei dati di fabbrica. Se questa configurazione gestita non è presente, viene impostata su null o viene impostata su un elenco vuoto, gli account autorizzati a eseguire il provisioning di un dispositivo dopo il ripristino dei dati di fabbrica sono quelli attualmente sul profilo personale del dispositivo.

Un DPC può configurare questi account per tutta la durata di un dispositivo completamente gestito.

1. Il DPC ottiene gli ID degli account (manualmente o in modo programmatico) che possono eseguire il provisioning di un dispositivo dopo un ripristino dei dati di fabbrica.
2. Il DPC utilizza il valore speciale "me" come userId per indicare l'utente autenticato. L'ID viene restituito come stringa intera. I nuovi account creati potrebbero non essere disponibili per il ripristino dei dati di fabbrica per 72 ore.
3. Il DPC imposta una limitazione app appropriata utilizzando DevicePolicyManager.setApplicationRestrictions() per impostare i valori della coppia chiave-valore nel bundle settings e per indicare il pacchetto per cui sono applicate limitazioni:
   Nome chiave: factoryResetProtectionAdmin.
   Valore chiave: una stringa contenente un ID account che può eseguire il provisioning di un dispositivo di ripristino dei dati di fabbrica o di un array di stringhe contenente più ID account.
   Nome del pacchetto: com.google.android.gms.
   
4. Il DPC abilita gli account che possono eseguire il provisioning dei dispositivi dopo un ripristino dei dati di fabbrica inviando l'annuncio com.google.android.gms.auth.FRP_CONFIG_CHANGED.

Disattiva la protezione ripristino dati di fabbrica

Per disattivare la protezione dal ripristino dei dati di fabbrica, il DPC deve impostare disableFactoryResetProtectionAdmin con un valore chiave pari a true. Se non imposti questa configurazione gestita, non viene disattivata la protezione ripristino dati di fabbrica.

1. Il DPC imposta una limitazione app appropriata utilizzando DevicePolicyManager.setApplicationRestrictions() per impostare i valori della coppia chiave-valore nel bundle settings e per indicare il pacchetto per cui sono soggette le limitazioni:
   Nome chiave: disableFactoryResetProtectionAdmin.
   Valore chiave: un valore booleano di true o false (impostazione predefinita).
   Nome del pacchetto: com.google.android.gms.
   
2. Il DPC informa Google Play Services della modifica inviando la trasmissione com.google.android.gms.auth.FRP_CONFIG_CHANGED.

Monitora i log dei processi aziendali e le segnalazioni di bug da remoto

Nella console EMM, un amministratore può monitorare i dispositivi completamente gestiti utilizzando i log di processi aziendali e le segnalazioni di bug da remoto.

Registra attività del dispositivo aziendale

Un DPC eseguito in modalità Proprietario del dispositivo può identificare le attività sospette monitorando da remoto l'attività del dispositivo, inclusi lanci di app, attività di Android Debug Bridge (adb) e sblocchi schermo. I log dei processi non richiedono il consenso dell'utente.

Per attivare o disattivare il logging, un DPC chiama setSecurityLoggingEnabled().

Quando è disponibile un nuovo batch di log, un elemento DeviceAdminReceiver riceve il callback onSecurityLogsAvailable(). Per recuperare i log (dopo aver ricevuto il callback), un DPC chiama retrieveSecurityLogs().

I DPC possono anche chiamare retrievePreRebootSecurityLogs() per recuperare i log di sicurezza generati nel ciclo di riavvio precedente. Si tratta dell'intervallo di tempo tra l'ultimo riavvio del dispositivo e quello precedente. I dispositivi che non supportano fetchSecurityLogs() restituiscono null. Se la tua app recupera i log utilizzando sia retrievePreRebootSecurityLogs() sia retrieveSecurityLogs(), devi verificare la presenza di voci duplicate.

Questa impostazione può essere utile nel controllo post-evento di sicurezza perché registra i seguenti tipi di azioni:

• Ogni volta che l'app è stata appena avviata. Questo potrebbe essere utile per identificare la presenza di malware che inizia con un'app compromessa.
• Tentativi di sblocco non riusciti su un dispositivo. Ciò potrebbe identificare l'eventuale presenza di diversi tentativi di sblocco non riusciti in un breve periodo di tempo.
• Comandi ab potenzialmente dannosi quando un utente collega il dispositivo a un computer tramite un cavo USB.

Per maggiori dettagli su come leggere i log, consulta SecurityLog.

Durante lo sviluppo e il test, puoi forzare il sistema a rendere disponibili i log di sicurezza esistenti per il tuo DPC, senza dover attendere un batch completo. In Android 9.0 (livello API 28) o versioni successive, esegui il seguente comando Android Debug Bridge (adb) nel terminale:

adb shell dpm force-security-logs

Il sistema limita la frequenza con cui puoi utilizzare lo strumento e segnala eventuali rallentamenti involontari nell'output del terminale. Se sono disponibili log, il DPC riceve il callback onSecurityLogsAvailable().

Richiedere una segnalazione di bug da remoto

Un DPC eseguito in modalità Proprietario del dispositivo può richiedere da remoto segnalazioni di bug per i dispositivi degli utenti con un solo utente o utenti affiliati. La segnalazione di bug acquisisce l'attività del dispositivo nel momento esatto in cui viene richiesta la segnalazione di bug, ma può anche includere attività delle ultime ore, a seconda della frequenza di aggiornamento del buffer logcat.

Per richiedere da remoto le segnalazioni di bug, il DPC chiama requestBugreport():

• Se un utente accetta di condividere la segnalazione di bug, il DPC riceve la segnalazione tramite onBugreportShared().
• Se un utente nega la condivisione della segnalazione di bug, il DPC riceve un messaggio di richiesta di condivisione rifiutata tramite onBugreportSharingDeclined().
• Se la segnalazione di bug non va a buon fine, il DPC vede onBugreportFailed() con BUGREPORT_FAILURE_FAILED_COMPLETING o BUGREPORT_FAILURE_FILE_NO_LONGER_AVAILABLE.

Concedere l'accesso e rimuovere l'accesso a un certificato client

Se un DPC in esecuzione in modalità proprietario del profilo o proprietario del dispositivo concede a un'app di terze parti la possibilità di gestire i certificati, l'app può concedersi l'accesso ai certificati che installa senza l'intervento di un utente. Per installare un certificato a cui tutte le app di un profilo possono accedere, utilizza installKeyPair().

Per conoscere i parametri da configurare, consulta installKeyPair(). Questa funzionalità funziona in combinazione con l'API esistente per la gestione dei certificati.

Scenario di implementazione

Senza il metodo installKeyPair():

• Gli utenti devono toccare il nome del certificato e Consenti ogni volta che vogliono concedere l'accesso a un certificato.
• Durante l'installazione di un certificato, gli utenti visualizzano un messaggio che richiede un nome per il certificato.

Con il metodo installKeyPair():

• Gli utenti non devono toccare Consenti ogni volta che vogliono concedere l'accesso a un certificato.
• Gli utenti non possono rinominare i certificati.
• Gli amministratori hanno un maggiore controllo in quanto possono bloccare i certificati per le app che non dovrebbero avere accesso a certificati specifici.

Rimuovere un certificato client

Dopo aver concesso l'accesso a un certificato client, per rimuovere da remoto i certificati client installati tramite installKeyPair(), chiama removeKeyPair().

Un DPC in esecuzione in modalità proprietario del dispositivo o proprietario del profilo oppure l'utente che ha eseguito l'installazione dei certificati delegato può chiamare removeKeyPair(). Questa operazione rimuove un certificato e una coppia di chiavi private installati sotto un determinato alias di chiave privata.

Scenario di implementazione

Utilizza questa funzionalità se un'organizzazione sta eseguendo la migrazione a una forma di certificato client più sicura. Se un amministratore implementa un nuovo certificato e se l'implementazione richiede un periodo di tempo significativo, l'amministratore può revocare i certificati ritirati al termine della migrazione.

Reimpostazione del passcode di sicurezza

Il DPC può reimpostare la password di un utente autorizzando la modifica con un token sicuro preregistrato. I proprietari di dispositivi e profili possono chiamare le API di reimpostazione del passcode sicura per modificare rispettivamente la password dei dispositivi e dei profili di lavoro. La reimpostazione del passcode di sicurezza sostituisce resetPassword() con i seguenti miglioramenti:

• Il DPC può reimpostare il passcode prima che l'utente sblocchi il dispositivo o il profilo dopo un riavvio sui dispositivi utilizzando la crittografia basata su file.
• L'archivio chiavi di Android conserva le chiavi autenticate dall'utente dopo la reimpostazione del passcode.

Devi utilizzare la reimpostazione del passcode sicuro se la build DPC ha come target Android 8.0 (livello API 26) o versioni successive. La chiamata di resetPassword() genera un codice SecurityException negli DPC che hanno come target Android 8.0 o versioni successive, pertanto potrebbe essere necessario aggiornare il DPC.

Impostare e attivare un token

Il DPC deve impostare e attivare un token prima di reimpostare una password. Poiché il tuo DPC potrebbe non essere in grado di utilizzare subito il token, devi impostarlo in anticipo rispetto a quando un amministratore IT potrebbe averne bisogno.

Un token di reimpostazione della password è un valore casuale crittograficamente efficace e deve avere una lunghezza di almeno 32 byte. Crea un token per ogni dispositivo e profilo. Non riutilizzare o condividere i token generati.

Consigliamo di archiviare i token o i metodi per decriptarli, su un server. Se archivi i token localmente in un archivio con credenziali criptate, il DPC non può reimpostare la password finché l'utente non sblocca il dispositivo o il profilo. Se archivi i token localmente nello spazio di archiviazione criptato del dispositivo, che diventa compromesso, un utente malintenzionato potrebbe utilizzare il token per ottenere l'accesso a un profilo di lavoro o a un utente principale.

Puoi generare un nuovo token nel tuo DPC o recuperare un token da un server. L'esempio seguente mostra un DPC che genera un token e lo segnala a un server:

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)
}

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);
}

Nella maggior parte dei casi, il DPC deve attivare un token dopo averlo impostato. Tuttavia, se l'utente non ha una password per la schermata di blocco, il sistema attiva subito un token. Per attivare un token, chiedi all'utente di confermare le sue credenziali. Il tuo DPC può chiamare il metodo KeyguardManager createConfirmDeviceCredentialIntent() per ottenere un Intent che avvia la conferma. Spiega all'utente del dispositivo nell'interfaccia utente perché gli chiedi di eseguire l'autenticazione. Lo snippet seguente mostra come potresti attivare un token nel tuo DPC:

// 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
}

// 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
}

Devi attivare un token impostato dal tuo DPC prima che il dispositivo si riavvii. Android archivia un token non attivato in memoria e non lo memorizza in modo permanente dopo un riavvio. Se l'utente riavvia il dispositivo prima di attivare un token, il DPC può impostare di nuovo lo stesso token o generarne uno nuovo.

Il DPC può confermare che un token è attivo chiamando isResetPasswordTokenActive() e controllando il risultato true.

Una volta impostato e attivato dal DPC, un token è valido finché quest'ultimo non lo elimina o sostituisce il token (o non vengono ripristinati i dati di fabbrica del dispositivo). Il token è indipendente dalla password e non viene influenzato dalla modifica o dalla cancellazione della password da parte dell'utente.

Elimina un token

Puoi chiamare clearResetPasswordToken() per eliminare un token impostato in precedenza dal DPC. Potrebbe essere necessario revocare un token compromesso o rimuovere la possibilità di reimpostare la password. L'esempio riportato di seguito mostra come eseguire questa operazione nel DPC:

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

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

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

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

Reimpostare la password

Quando un amministratore IT deve reimpostare la password, chiama il numero resetPasswordWithToken() e passa il token impostato e attivato in anticipo dal tuo DPC:

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.
}

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.
}

Una chiamata a resetPasswordWithToken() restituisce false e la password non cambia quando la nuova password non soddisfa i seguenti vincoli:

• Il numero di caratteri soddisfa qualsiasi vincolo di lunghezza minima della password. Chiama il numero getPasswordMinimumLength() per sapere se un amministratore IT ha impostato un vincolo di lunghezza.
• L'intervallo e la complessità dei caratteri nella password incontra un vincolo di composizione. Chiama getPasswordQuality() per sapere se un amministratore IT ha impostato un vincolo di composizione.

Se i vincoli di qualità delle password non richiedono l'impostazione di una password, puoi passare null o una stringa vuota a resetPasswordWithToken() per rimuovere la password.

Verifica della sicurezza del profilo di lavoro

Un DPC eseguito in modalità proprietario del profilo può richiedere agli utenti di specificare una verifica di sicurezza per le app in esecuzione nel profilo di lavoro. Il sistema mostra la verifica della sicurezza quando l'utente tenta di aprire un'app di lavoro. Se l'utente completa correttamente la verifica di sicurezza, il sistema sblocca il profilo di lavoro e lo decripta, se necessario.

Come funziona la verifica della sicurezza del profilo di lavoro

1. Se un DPC invia un intent ACTION_SET_NEW_PASSWORD, il sistema chiede all'utente di impostare una verifica di sicurezza.
2. Il DPC può anche inviare un intent ACTION_SET_NEW_PARENT_PROFILE_PASSWORD per richiedere all'utente di impostare un blocco dispositivo.

Un DPC può impostare i criteri relativi alle password per la verifica di lavoro in modo diverso rispetto ai criteri per le altre password del dispositivo. Ad esempio, la lunghezza minima per la risposta alla richiesta di verifica del dispositivo può essere diversa da quella richiesta per altre password. Un DPC definisce i criteri della verifica utilizzando i metodi DevicePolicyManager consueti, ad esempio setPasswordQuality() e setPasswordMinimumLength().

Considerazioni

• Il DPC può reimpostare la password sul profilo di lavoro, ma non può reimpostare la password del dispositivo (personale). Se un utente sceglie la stessa password di lavoro e quella personale, resetPassword() sul profilo di lavoro la password viene reimpostata solo nel profilo di lavoro e la password sarà diversa da quella per la schermata di blocco del dispositivo.
• Un DPC può personalizzare la schermata delle credenziali per la sfida lavorativa utilizzando setOrganizationColor() e setOrganizationName().
• Gli amministratori dei dispositivi non possono utilizzare resetPassword() per cancellare le password o modificare quelle già impostate. Gli amministratori dei dispositivi possono comunque impostare una password, ma solo se il dispositivo non ha password, PIN o sequenza.

Per ulteriori informazioni, consulta getParentProfileInstance() e la documentazione di riferimento nella sezione DevicePolicyManager.