Sécurité

Les fonctionnalités présentées dans ce guide décrivent les fonctionnalités de gestion de la sécurité que vous pouvez mettre en œuvre dans votre application d'outil de contrôle des règles relatives aux appareils (DPC). Ce document contient des exemples de code. Vous pouvez également utiliser l'application Test DPC en tant que une source d'exemple de code pour les fonctionnalités d'entreprise d'Android.

Une application DPC peut s'exécuter en mode propriétaire de profil sur des appareils personnels ou en mode propriétaire de l'appareil sur les appareils entièrement gérés. Ce tableau présente les fonctionnalités disponibles Lorsque l'outil DPC s'exécute en mode propriétaire du profil ou en mode propriétaire de l'appareil:

Fonctionnalité	Propriétaire de la fiche	Propriétaire de l'appareil
Désactiver l'accès aux applications	✓	✓
Bloquer les applications provenant de sources inconnues	✓	✓
Limiter les comptes dans Google Play	✓	✓
Activer la protection après rétablissement de la configuration d'usine de l'entreprise		✓
Surveiller les journaux de processus d'entreprise et les rapports de bug à distance		✓
Accorder et supprimer l'accès à un certificat client	✓	✓
Réinitialisation du code secret sécurisé	✓	✓
Question d'authentification à la sécurité du profil professionnel	✓

Désactiver l'accès aux applications

Pour les organisations qui souhaitent empêcher les employés de jouer ou de regarder à utiliser YouTube sur leur appareil Android à certaines heures de la journée ; certains jours de la semaine, un DPC peut désactiver temporairement l'accès aux applications.

Pour désactiver l'accès aux applications, un DPC s'exécutant en mode propriétaire de l'appareil ou propriétaire du profil configure setPackagesSuspended(), puis l'application sélectionnée se comporte comme si elle est désactivée (le lanceur d'applications Google fait apparaître l'application en grisé). Lorsqu'un utilisateur appuie sur l'application, une boîte de dialogue système indique que l'application est suspendue.

Lorsqu'une application est suspendue, elle ne peut pas démarrer d'activités et l'envoi de notifications à packages sont supprimés. Les packages suspendus n'apparaissent pas dans la vue d'ensemble. écran, ils ne peuvent pas afficher de boîtes de dialogue (y compris les toasts et les snackbars) et l'appareil ne peut pas lire de contenu audio ni le faire vibrer.

Les lanceurs d'applications peuvent savoir si une application est suspendue en appelant la méthode isPackageSuspended(). Pour savoir comment configurer une application suspension, consultez setPackagesSuspended.

Bloquer les applications provenant de sources inconnues

Les applications qui ne sont pas installées depuis Google Play (ou d'autres plates-formes de téléchargement d'applications de confiance) appelés applications provenant de sources inconnues. Risque accru sur les appareils et les données lorsqu'ils installent ces applications.

Pour empêcher quiconque d'installer des applications provenant de sources inconnues, les composants d'administration de les appareils entièrement gérés et les profils professionnels peuvent ajouter Restriction utilisateur DISALLOW_INSTALL_UNKNOWN_SOURCES.

Restriction à l'échelle de l'appareil associée au profil professionnel

Lorsque l'administrateur d'un profil professionnel ajoute DISALLOW_INSTALL_UNKNOWN_SOURCES : la restriction ne s'applique qu'au profil professionnel. Toutefois, l'administrateur d'une profil peut appliquer une restriction à l'échelle de l'appareil en définissant configuration gérée pour Google Play. La restriction au niveau de l'appareil disponible sur Android 8.0 (ou version ultérieure) lorsque l'application Google Play installée est version 80812500 ou ultérieure.

Pour limiter les installations d'applications à Google Play, procédez comme suit:

1. Définir un bundle de configuration gérée pour le package Google Play com.android.vending
2. Dans le groupe, indiquez une valeur booléenne pour le paramètre Clé verify_apps:device_wide_unknown_source_block.
3. Ajoutez la restriction utilisateur ENSURE_VERIFY_APPS.

L'exemple suivant montre comment vérifier que Google Play prend en charge ce et définissez sa valeur sur 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'interface utilisateur dans les paramètres système reste active, mais le système se bloque l'installation d'applications. Cette restriction affecte les futures installations les applications installées restent sur l'appareil. Les utilisateurs d'appareils peuvent continuer à installer des applis au profil personnel à l'aide d'Android Debug Bridge (adb).

Pour en savoir plus sur les sources inconnues, consultez Autres distributions options.

Limiter les comptes dans Google Play

Parfois, une organisation peut souhaiter autoriser des utilisateurs à ajouter des comptes Google Comptes (pour lire les e-mails dans Gmail, par exemple), mais qui ne veulent pas pour installer des applications. Votre DPC peut définir une liste de comptes que les personnes peuvent utiliser dans Google Play.

Les composants d'administration d'appareils entièrement gérés ou de profils professionnels peuvent limiter en définissant une configuration gérée pour Google Play. Le compte est disponible lorsque l'application Google Play installée est à la version 80970100 ou supérieur.

Pour limiter les comptes dans Google Play, procédez comme suit:

1. Définir un bundle de configuration gérée pour le package Google Play com.android.vending
2. Dans le groupe, saisissez les adresses e-mail séparées par une virgule en tant que valeur de chaîne pour la clé allowed_accounts.

L'exemple suivant montre comment limiter des comptes:

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

Pour limiter Google Play au seul compte professionnel, définissez allowed_accounts sur compte géré unique dès que votre DPC connaît l'adresse e-mail du compte. Une Une chaîne vide empêche les utilisateurs d'utiliser un compte sur Google Play.

Activer la protection après rétablissement de la configuration d'usine de l'entreprise

Grâce à la protection après rétablissement de la configuration d'usine, les entreprises peuvent spécifier Les comptes Google peuvent provisionner un appareil dont la configuration d'usine a été rétablie.

La protection après rétablissement de la configuration d'usine du client est conçue pour dissuader le vol de l'appareil. Avant permettant à quiconque de provisionner l'appareil après une réinitialisation non autorisée que l'utilisation d'un fournisseur EMM), l'assistant de configuration demande à l'utilisateur de s'authentifier auprès de Comptes Google qui figuraient auparavant sur le profil personnel de l'appareil

Dans un environnement d'entreprise, le rétablissement de la configuration d'usine est un outil important pour gérer les appareils des employés lorsqu'ils quittent l'organisation. Toutefois, si le ne connaît pas les identifiants du compte d'un employé, peut empêcher l'organisation de transmettre un appareil un employé.

Remarque :La protection contre le rétablissement de la configuration d'usine est désactivée si le déverrouillage OEM est activé dans Options pour les développeurs.

Contrôler le provisionnement après une réinitialisation

Lorsqu'il s'exécute en mode propriétaire de l'appareil, votre DPC peut utiliser setFactoryResetProtectionPolicy() pour contrôler les comptes autorisé à provisionner un appareil après une réinitialisation. Si cette configuration est définie sur null ou définie sur une liste vide, les comptes autorisés à provisionner un appareil après une réinitialisation selon les paramètres d'usine, sont les comptes figurant dans le profil personnel appareil.

Un DPC peut configurer ces comptes tout au long de la durée de vie d'un compte appareil.

Remarque :Le DPC utilise la valeur userID pour configurer les comptes pouvant provisionner un appareil après une réinitialisation.

1. L'administrateur informatique peut utiliser la méthode people.get de l'API People avec la valeur spéciale me. Cette opération récupère les userId pour connecté à un compte. Le userID est renvoyé dans la clé resourceName dans au format people/[userId], sous la forme d'une chaîne entière. Les comptes nouvellement créés ne sera pas disponible pour rétablir la configuration d'usine pendant 72 heures.
2. Vous pouvez également autoriser un ou plusieurs administrateurs informatiques à déverrouiller l'appareil après rétablir la configuration d'usine. Demandez à chacun de ces administrateurs informatiques de se connecter à leur compte Google et Suivez également l'étape 1 et partagez leurs userId avec vous, afin que vous puissiez ajouter ces éléments userIds à la liste à l'étape suivante.
3. Le DPC définit une restriction d'application appropriée en utilisant setFactoryResetProtectionPolicy() pour définir la liste des userId pouvant de provisionner un appareil rétabli à la configuration d'usine.
4. Le DPC permet aux comptes autorisés à provisionner des appareils après une usine réinitialisé en envoyant la diffusion com.google.android.gms.auth.FRP_CONFIG_CHANGED comme intent explicite empêcher l'abandon en raison de restrictions d'arrière-plan.

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

Legacy

Pour les appareils qui ne peuvent pas utiliser setFactoryResetProtectionPolicy(), introduit avec Niveau d'API 30, votre DPC peut utiliser setApplicationRestrictions pour ajouter les comptes sélectionnés vers la configuration gérée factoryResetProtectionAdmin pour le package 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);

Désactiver la protection après rétablissement de la configuration d'usine de l'entreprise

Pour désactiver la protection après rétablissement de la configuration d'usine, votre DPC peut utiliser setFactoryResetProtectionPolicy()en transmettant la valeur 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);

Legacy

Pour les appareils qui ne peuvent pas utiliser setFactoryResetProtectionPolicy(), introduit avec Niveau d'API 30, votre DPC peut utiliser setApplicationRestrictions pour définir une clé de true dans l'environnement disableFactoryResetProtectionAdmin géré pour le package com.google.android.gms.

Remarque :Laisser simplement la configuration gérée factoryResetProtectionAdmin non définie ne désactive pas la protection après rétablissement de la configuration d'usine.

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

Surveiller les journaux des processus d'entreprise et les rapports de bugs à distance

Dans votre console EMM, un administrateur peut surveiller les appareils entièrement gérés via des de traiter les journaux et les rapports de bogues distants.

Enregistrer l'activité des appareils de l'entreprise

Un DPC exécuté en mode propriétaire de l'appareil peut identifier une activité suspecte à distance Suivre l'activité de l'appareil, y compris les lancements d'applis, Android Debug Bridge (adb) l'activité et les déverrouillages de l'écran. Les journaux de processus ne nécessitent pas le consentement de l'utilisateur.

Pour activer ou désactiver la journalisation, un DPC appelle setSecurityLoggingEnabled().

Lorsqu'un nouveau lot de journaux est disponible, un DeviceAdminReceiver reçoit le Rappel onSecurityLogsAvailable(). Pour récupérer les journaux (après réception du rappel), un DPC appelle retrieveSecurityLogs().

Les DPC peuvent également appeler retrievePreRebootSecurityLogs() pour récupérer la sécurité les journaux générés lors du précédent cycle de redémarrage. Il s'agit de l'intervalle entre le dernier redémarrage de l'appareil et le précédent. Appareils non compatibles retrieveSecurityLogs() renvoie null. Si votre application récupère les journaux à l'aide des deux retrievePreRebootSecurityLogs() et retrieveSecurityLogs(), vous devez : rechercher les entrées en double.
Remarque: Cette fonctionnalité enregistre uniquement l'activité sur les appareils entièrement gérés disposant d'un seul ou des utilisateurs affiliés sur l'appareil. Cette fonctionnalité n'est pas disponible sur les appareils personnels, car elle enregistre l'activité au niveau de l'appareil.

Ce paramètre peut être utile pour l'audit post-événement de sécurité, car il consigne types d'actions suivants:

• Chaque fois que l'application est lancée récemment. Cela pourrait aider à identifier s'il y a les logiciels malveillants commençant par une application compromise.
• Tentatives de déverrouillage infructueuses sur un appareil. Cela pourrait permettre d'identifier s'il y a plusieurs tentatives de déverrouillage infructueuses en peu de temps.
• Commandes adb potentiellement dangereuses lorsqu'un utilisateur se connecte l'appareil à un ordinateur à l'aide d'un câble USB.

Pour en savoir plus sur la lecture des journaux, consultez SecurityLog.

Pendant le développement et le test, vous pouvez forcer le système les journaux de sécurité existants disponibles pour votre DPC, vous n'avez pas à attendre par lot. Sous Android 9.0 (niveau d'API 28) ou version ultérieure, exécutez la commande suivante : Android Debug Bridge (adb) dans votre terminal:

adb shell dpm force-security-logs

Le système limite la fréquence d'utilisation de l'outil et signale les un ralentissement intentionnel de la sortie du terminal. Si des journaux sont disponibles, Le DPC reçoit le rappel onSecurityLogsAvailable().

Demander un rapport de bug à distance

Un DPC exécuté en mode propriétaire de l'appareil peut demander à distance des rapports de bug à l'utilisateur appareils avec un seul utilisateur ou des utilisateurs affiliés. Le rapport de bug capture l'activité de l'appareil au moment exact où le rapport de bug est demandé, mais il peut aussi incluent l'activité des dernières heures, en fonction de la fréquence à laquelle le tampon est actualisé.

Pour demander à distance des rapports de bug, l'outil DPC appelle requestBugreport():

• Si un utilisateur accepte de partager le rapport de bug, le DPC reçoit le bug créer un rapport à l'aide de onBugreportShared()
• Si un utilisateur refuse le partage du rapport de bug, le DPC reçoit une notification de requête refusée avec onBugreportSharingDeclined()
• Si le rapport de bug échoue, le DPC voit onBugreportFailed() avec BUGREPORT_FAILURE_FAILED_COMPLETING ou BUGREPORT_FAILURE_FILE_NO_LONGER_AVAILABLE

Accorder et supprimer l'accès à un certificat client

Si un DPC exécuté en mode propriétaire du profil ou propriétaire de l'appareil accorde une application tierce gérer les certificats, l'application peut s'accorder l'accès et les certificats qu'il installe sans l'intervention d'un utilisateur. Pour installer un un certificat auquel toutes les applications d'un profil peuvent accéder, utilisez installKeyPair().

Pour connaître les paramètres à configurer, consultez installKeyPair(). Cette fonctionnalité fonctionne avec l'API existante pour gérer les certificats.

Scénario de déploiement

Sans la méthode installKeyPair():

• Les utilisateurs doivent appuyer sur le nom du certificat, puis sur Autoriser à chaque fois. il veut accorder l’accès à un certificat.
• Les utilisateurs voient une invite lorsqu'ils installent un certificat et doivent nommer le certificat.

Avec la méthode installKeyPair():

• Les utilisateurs n'ont pas besoin d'appuyer sur Autoriser chaque fois qu'ils souhaitent accorder l'accès à certificat.
• Les utilisateurs ne peuvent pas renommer les certificats.
• Les administrateurs ont plus de contrôle, car ils peuvent bloquer les certificats pour des applications qui ne devraient pas avoir accès à des certificats spécifiques.

Supprimer un certificat client

Après avoir accordé l'accès à un certificat client, pour supprimer à distance le client certificats installés via installKeyPair(), appelez removeKeyPair()

Un DPC s'exécutant en mode propriétaire de l'appareil ou en mode propriétaire du profil, ou délégué Le programme d'installation du certificat peut appeler removeKeyPair(). Cela supprime de clé privée et de certificat installée sous un alias de clé privée donné.

Scénario de déploiement

Utilisez cette fonctionnalité si une entreprise migre vers un type de client plus sécurisé certificat. Si un administrateur déploie un nouveau certificat et sa distribution prend beaucoup de temps, l'administrateur peut révoquer le certificat certificats après la migration.

Réinitialisation du code secret sécurisé

Votre DPC peut réinitialiser le mot de passe d'un utilisateur en autorisant la modification avec un préenregistré et sécurisé. Les propriétaires d'appareils et de profils peuvent appeler des numéros sécurisés API de réinitialisation de code secret pour modifier le mot de passe des appareils et des profils professionnels respectivement. La réinitialisation d'un code secret sécurisé remplace resetPassword() par le améliorations suivantes:

• Votre DPC peut réinitialiser le code secret avant que l'utilisateur déverrouille l'appareil ou le profil. après un redémarrage sur les appareils chiffrement basé sur les fichiers.
• Android Keystore conserve les clés authentifiées par l'utilisateur. après la réinitialisation d'un code secret.

Vous devez utiliser la réinitialisation du code secret sécurisé si le build de votre DPC cible Android 8.0 (API niveau 26) ou supérieur. L'appel de resetPassword() génère une SecurityException dans les DPC ciblant Android 8.0 ou version ultérieure. Vous pourriez donc mettre à jour votre DPC.

Définir et activer un jeton

Votre DPC doit définir et activer un jeton avant de réinitialiser un mot de passe. En effet, votre DPC pourrait ne pas être en mesure d'utiliser le jeton tout de suite, vous définissez le jeton avant qu'un administrateur informatique ait besoin de l'utiliser.

Un jeton de réinitialisation de mot de passe est une valeur aléatoire cryptographiquement forte et doit comporter au moins 32 octets. Créez un jeton pour chaque appareil et profil ; ne le faites pas réutiliser ou partager vos jetons générés.

Avertissement :Traitez le jeton de la même manière que les identifiants de l'utilisateur. Ne stockez jamais la sur l'appareil en texte brut, en particulier dans le stockage chiffré de l'appareil. Votre l'organisation doit bien réfléchir à la façon dont vous stockez les jetons sur un serveur et qui a accès aux jetons. Les jetons peuvent faire l'objet de réquisitions judiciaires pour l'accès à l'appareil.

Nous vous recommandons de stocker les jetons, c'est-à-dire les moyens de déchiffrer les jetons chiffrés, sur un Google Cloud. Si vous stockez des jetons localement dans un espace de stockage chiffré par identifiants, votre DPC ne peut pas réinitialiser le mot de passe tant que l'utilisateur n'a pas déverrouillé l'appareil ou le profil. Si vous stocker les jetons localement dans le stockage chiffré de l’appareil, qui est compromis, un pirate informatique peut utiliser le jeton pour accéder à un profil professionnel ou à une adresse utilisateur.

Vous pouvez générer un nouveau jeton dans votre DPC ou récupérer un jeton sur un serveur. La l'exemple ci-dessous montre un DPC qui génère lui-même un jeton et le signale à un serveur:

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

Dans la plupart des cas, votre DPC doit activer un jeton après l'avoir défini. Mais, quand l'utilisateur n'a pas de mot de passe d'écran de verrouillage, le système active un jeton tout de suite. Pour activer un jeton, demandez à l'utilisateur de confirmer ses identifiants. Votre DPC peut appeler la méthode KeyguardManager createConfirmDeviceCredentialIntent() pour obtenir un Intent qui lance le confirmation. Expliquez à l'utilisateur de l'appareil dans l'interface utilisateur pourquoi vous de s'authentifier. L'extrait ci-dessous montre comment activer dans votre 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
}

Vous devez activer un jeton défini par votre DPC avant que l'appareil redémarre. Android stocke en mémoire un jeton non activé et ne le conserve pas après une redémarrer. Si l'utilisateur redémarre l'appareil avant d'activer un jeton, votre DPC peut définissez à nouveau le même jeton ou générez-en un nouveau.

Votre DPC peut confirmer qu'un jeton est actif en appelant isResetPasswordTokenActive() et la vérification du résultat est true.

Une fois que votre DPC définit et active un jeton, il est valide jusqu'à ce que votre DPC soit supprimé ou remplace le jeton (ou la configuration d'usine de l'appareil est rétablie). Le jeton est indépendant le mot de passe et n’est pas affecté par le changement ou l’effacement du mot de passe par l’utilisateur.

Supprimer un jeton

Vous pouvez appeler clearResetPasswordToken() pour supprimer un jeton que votre DPC défini précédemment. Vous devrez peut-être révoquer un jeton compromis ou supprimer la possibilité de réinitialiser le mot de passe. L'exemple ci-dessous montre comment ceci dans votre 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 ...
}

Réinitialiser le mot de passe

Lorsqu'un administrateur informatique doit réinitialiser le mot de passe, appelez resetPasswordWithToken() et transmettez le jeton que votre DPC a défini et activé à l'avance:

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

Un appel à resetPasswordWithToken() renvoie false, mais le mot de passe ne renvoie pas lorsque le nouveau mot de passe ne répond pas aux contraintes suivantes:

• Le nombre de caractères doit respecter les contraintes de longueur minimale du mot de passe. Appeler getPasswordMinimumLength() pour savoir si un service informatique l'administrateur a défini une contrainte de longueur.
• La gamme et la complexité des caractères du mot de passe répondent à une composition d'une contrainte. Appelez getPasswordQuality() pour savoir si un informaticien a défini une contrainte de composition.

Si les contraintes de qualité des mots de passe ne nécessitent pas la définition d’un mot de passe, vous pouvez transmettez null ou une chaîne vide à resetPasswordWithToken() pour supprimer mot de passe.

Question d'authentification via le profil professionnel

Un DPC exécuté en mode propriétaire de profil peut obliger les utilisateurs à spécifier un niveau de sécurité pour les applications exécutées dans le profil professionnel. Le système affiche le niveau de sécurité lorsque l'utilisateur tente d'ouvrir des applications professionnelles. Si l'utilisateur réussit achève le défi de sécurité, le système déverrouille le profil professionnel et le déchiffre, si nécessaire.

Remarque :Le défi professionnel distinct est une fonctionnalité qu'un utilisateur peut également définir. l'utilisateur choisit l'option de verrouillage unifiée, il peut accéder aux applications professionnelles déverrouiller son verrouillage personnel sur l'appareil.

Fonctionnement de la question d'authentification à la sécurité du profil professionnel

1. Si un DPC envoie un intent ACTION_SET_NEW_PASSWORD, le système vous invite à l'utilisateur de configurer une question d'authentification.
2. Le DPC peut également envoyer un ACTION_SET_NEW_PARENT_PROFILE_PASSWORD pour inviter l'utilisateur à définir un verrouillage de l'appareil.

Un DPC peut définir les règles de mot de passe pour la question d'authentification professionnelle différemment de la des règles applicables aux autres mots de passe des appareils. Par exemple, la longueur minimale du paramètre la réponse d'authentification via un appareil peut être différente de la longueur requise pour d'autres mots de passe. Un DPC définit les règles de défi en utilisant le Méthodes DevicePolicyManager, telles que setPasswordQuality() et setPasswordMinimumLength()

Points à prendre en compte

• Le DPC peut réinitialiser le mot de passe du profil professionnel, mais pas le mot de passe (personnel) de l'appareil. Si un utilisateur choisit de définir des mots de passe professionnels et personnels est identique, alors resetPassword() sur le profil professionnel entraîne le mot de passe ne pourra être réinitialisé que sur le profil professionnel, et le mot de passe sera différent que celle de l'écran de verrouillage de l'appareil.
• Un DPC peut personnaliser l'écran des identifiants pour le défi professionnel en utilisant setOrganizationColor() et setOrganizationName().
• Les administrateurs des appareils ne peuvent pas utiliser resetPassword() pour effacer les mots de passe ni les modifier celles qui sont déjà définies. Les administrateurs d'appareils peuvent toujours définir un mot de passe, mais seulement si l'appareil ne dispose d'aucun mot de passe, code ou schéma.

Pour en savoir plus, consultez getParentProfileInstance() et la documentation de référence documentation sous DevicePolicyManager.