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:
Funzionalità | Proprietario del profilo | Proprietario del dispositivo |
Disattivare l'accesso alle app | ✓ | ✓ |
Bloccare app provenienti da origini sconosciute | ✓ | ✓ |
Limitare gli account in Google Play | ✓ | ✓ |
Abilita la protezione ripristino dati di fabbrica aziendale | ✓ | |
Monitora i log dei processi aziendali e le segnalazioni di bug da remoto | ✓ | |
Concedere l'accesso a un certificato client e rimuovere l'accesso | ✓ | ✓ |
Reimpostazione sicura del passcode | ✓ | ✓ |
Verifica di sicurezza del profilo di lavoro | ✓ |
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:
- Imposta un bundle di configurazione gestita per il pacchetto Google Play
com.android.vending
. - Nel bundle, inserisci un valore booleano per la chiave
verify_apps:device_wide_unknown_source_block
. - 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
:
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);
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:
- Imposta un bundle di configurazione gestita per il pacchetto Google Play
com.android.vending
. - 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:
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 = "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)
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 = "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.
- 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.
- 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. - Il DPC imposta una limitazione app appropriata utilizzando
DevicePolicyManager.setApplicationRestrictions()
per impostare i valori della coppia chiave-valore nel bundlesettings
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
. - 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.
- Il DPC imposta una limitazione app appropriata utilizzando
DevicePolicyManager.setApplicationRestrictions()
per impostare i valori della coppia chiave-valore nel bundlesettings
e per indicare il pacchetto per cui sono soggette le limitazioni:
Nome chiave:disableFactoryResetProtectionAdmin
.
Valore chiave: un valore booleano ditrue
ofalse
(impostazione predefinita).
Nome del pacchetto:com.google.android.gms
. - 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()
conBUGREPORT_FAILURE_FAILED_COMPLETING
oBUGREPORT_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:
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); }
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:
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 }
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:
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 ... }
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:
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. }
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
- Se un DPC invia un intent
ACTION_SET_NEW_PASSWORD
, il sistema chiede all'utente di impostare una verifica di sicurezza. - 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()
esetOrganizationName()
. - 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
.