Renforcer la sécurité avec les règles de gestion des appareils

Abandon de l'administration des appareils. Certaines règles d'administration ont été marquées comme obsolètes lorsqu'elles ont été appelées par un administrateur de l'appareil. Pour en savoir plus et découvrir les options de migration, consultez Abandon de l'administration des appareils.

Depuis Android 2.2 (niveau d'API 8), la plate-forme Android offre des fonctionnalités de gestion des appareils au niveau du système via les API d'administration des appareils.

Dans cette leçon, vous allez apprendre à créer une application sensible à la sécurité qui gère l'accès à son contenu en appliquant des règles de gestion des appareils. Plus précisément, l'application peut être configurée de manière à s'assurer qu'un mot de passe de verrouillage de l'écran d'un niveau de sécurité suffisant est défini avant d'afficher un contenu restreint à l'utilisateur.

Définir et déclarer votre stratégie

Tout d'abord, vous devez définir les types de règles à prendre en charge au niveau fonctionnel. Ces règles peuvent porter sur le niveau de sécurité des mots de passe de verrouillage de l'écran, le délai d'expiration, le chiffrement, etc.

Vous devez déclarer l'ensemble de règles sélectionné, qui sera appliqué par l'application, dans le fichier res/xml/device_admin.xml. Le fichier manifeste Android doit également référencer l'ensemble de règles déclaré.

Chaque règle déclarée correspond à un certain nombre de méthodes de règles relatives aux appareils associées dans DevicePolicyManager (par exemple, la longueur minimale du mot de passe et le nombre minimal de caractères en majuscules). Si une application tente d'appeler des méthodes dont la stratégie correspondante n'est pas déclarée dans le fichier XML, une SecurityException est générée au moment de l'exécution. D'autres autorisations, telles que force-lock, sont disponibles si l'application a l'intention de gérer d'autres types de règles. Comme vous le verrez plus tard, dans le cadre du processus d'activation de l'administrateur de l'appareil, la liste des règles déclarées sera présentée à l'utilisateur sur un écran système.

L'extrait de code suivant déclare la règle de limite des mots de passe dans res/xml/device_admin.xml:

<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-policies>
        <limit-password />
    </uses-policies>
</device-admin>

Fichier XML de déclaration de règle référencé dans le fichier manifeste Android:

<receiver android:name=".Policy$PolicyAdmin"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <meta-data android:name="android.app.device_admin"
        android:resource="@xml/device_admin" />
    <intent-filter>
        <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
    </intent-filter>
</receiver>

Créer un récepteur de l'administration des appareils

Créez un broadcast receiver de l'administration des appareils qui recevra des notifications en cas d'événements liés aux règles que vous avez déclarées compatibles. Une application peut ignorer les méthodes de rappel de manière sélective.

Dans l'exemple d'application "Administration des appareils", lorsque l'administrateur de l'appareil est désactivé par l'utilisateur, la règle configurée est supprimée de la préférence partagée. Vous devez envisager d'implémenter une logique métier pertinente pour votre cas d'utilisation. Par exemple, l'application peut prendre certaines mesures pour atténuer les risques de sécurité en mettant en œuvre une combinaison de ces actions : suppression des données sensibles sur l'appareil, désactivation de la synchronisation à distance, alerte d'un administrateur, etc.

Pour que le broadcast receiver fonctionne, veillez à l'enregistrer dans le fichier manifeste Android, comme illustré dans l'extrait ci-dessus.

Kotlin

class PolicyAdmin : DeviceAdminReceiver() {

    override fun onDisabled(context: Context, intent: Intent) {
        // Called when the app is about to be deactivated as a device administrator.
        // Deletes previously stored password policy.
        super.onDisabled(context, intent)
        context.getSharedPreferences(APP_PREF, Activity.MODE_PRIVATE).edit().apply {
            clear()
            apply()
        }
    }
}

Java

public static class PolicyAdmin extends DeviceAdminReceiver {

    @Override
    public void onDisabled(Context context, Intent intent) {
        // Called when the app is about to be deactivated as a device administrator.
        // Deletes previously stored password policy.
        super.onDisabled(context, intent);
        SharedPreferences prefs = context.getSharedPreferences(APP_PREF, Activity.MODE_PRIVATE);
        prefs.edit().clear().commit();
    }
}

Activer l'administrateur de l'appareil

Avant d'appliquer des règles, l'utilisateur doit activer manuellement l'application en tant qu'administrateur de l'appareil. L'extrait ci-dessous montre comment déclencher l'activité de paramétrage dans laquelle l'utilisateur peut activer votre application. Il est recommandé d'inclure le texte explicatif pour expliquer aux utilisateurs pourquoi l'application demande le rôle d'administrateur d'appareil, en spécifiant l'extra EXTRA_ADD_EXPLANATION dans l'intent.

Figure 1 : Écran d'activation des utilisateurs dans lequel vous pouvez fournir une description des règles relatives à vos appareils.

Kotlin

if (!policy.isAdminActive()) {

    val activateDeviceAdminIntent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN)

    activateDeviceAdminIntent.putExtra(
            DevicePolicyManager.EXTRA_DEVICE_ADMIN,
            policy.getPolicyAdmin()
    )

    // It is good practice to include the optional explanation text to
    // explain to user why the application is requesting to be a device
    // administrator. The system will display this message on the activation
    // screen.
    activateDeviceAdminIntent.putExtra(
            DevicePolicyManager.EXTRA_ADD_EXPLANATION,
            resources.getString(R.string.device_admin_activation_message)
    )

    startActivityForResult(activateDeviceAdminIntent, REQ_ACTIVATE_DEVICE_ADMIN)
}

Java

if (!policy.isAdminActive()) {

    Intent activateDeviceAdminIntent =
        new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);

    activateDeviceAdminIntent.putExtra(
        DevicePolicyManager.EXTRA_DEVICE_ADMIN,
        policy.getPolicyAdmin());

    // It is good practice to include the optional explanation text to
    // explain to user why the application is requesting to be a device
    // administrator. The system will display this message on the activation
    // screen.
    activateDeviceAdminIntent.putExtra(
        DevicePolicyManager.EXTRA_ADD_EXPLANATION,
        getResources().getString(R.string.device_admin_activation_message));

    startActivityForResult(activateDeviceAdminIntent,
        REQ_ACTIVATE_DEVICE_ADMIN);
}

Si l'utilisateur choisit "Activer", l'application devient administrateur de l'appareil et peut commencer à configurer et à appliquer la règle.

L'application doit également être préparée à gérer les situations d'annulation où l'utilisateur abandonne le processus d'activation en appuyant sur le bouton "Annuler", la touche Retour ou la touche Accueil. Par conséquent, onResume() dans l'activité de configuration des règles doit avoir une logique pour réévaluer la condition et présenter l'option d'activation de l'administrateur de l'appareil à l'utilisateur si nécessaire.

Implémenter l'outil de contrôle des règles relatives aux appareils

Une fois l'administrateur de l'appareil activé, l'application configure le gestionnaire de règles relatives aux appareils avec la règle demandée. N'oubliez pas que de nouvelles règles sont ajoutées à Android à chaque version. Il est approprié d'effectuer des vérifications de version dans votre application si vous utilisez de nouvelles règles tout en prenant en charge les anciennes versions de la plate-forme. Par exemple, la règle du mot de passe minimal en majuscules n'est disponible qu'à partir du niveau d'API 11 (Honeycomb). Le code suivant montre comment vérifier la version au moment de l'exécution.

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var policyAdmin: ComponentName

dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
policyAdmin = ComponentName(context, PolicyAdmin::class.java)

dpm.apply {
    setPasswordQuality(policyAdmin, PASSWORD_QUALITY_VALUES[passwordQuality])
    setPasswordMinimumLength(policyAdmin, passwordLength)
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
        setPasswordMinimumUpperCase(policyAdmin, passwordMinUpperCase)
    }
}

Java

DevicePolicyManager dpm = (DevicePolicyManager)
        context.getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName policyAdmin = new ComponentName(context, PolicyAdmin.class);

dpm.setPasswordQuality(policyAdmin, PASSWORD_QUALITY_VALUES[passwordQuality]);
dpm.setPasswordMinimumLength(policyAdmin, passwordLength);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
    dpm.setPasswordMinimumUpperCase(policyAdmin, passwordMinUpperCase);
}

À ce stade, l'application est en mesure d'appliquer la règle. Bien que l'application n'ait pas accès au mot de passe de verrouillage de l'écran réellement utilisé, l'API Device Policy Manager peut déterminer si le mot de passe existant respecte la stratégie requise. S'il s'avère que le mot de passe de verrouillage de l'écran existant n'est pas suffisant, l'API d'administration des appareils ne prend pas automatiquement de mesures correctives. Il incombe à l'application de lancer explicitement l'écran de modification du mot de passe du système dans l'application Paramètres. Par exemple:

Kotlin

if (!dpm.isActivePasswordSufficient) {
    // Triggers password change screen in Settings.
    Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
        startActivity(intent)
    }
}

Java

if (!dpm.isActivePasswordSufficient()) {
    ...
    // Triggers password change screen in Settings.
    Intent intent =
        new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
    startActivity(intent);
}

Normalement, l'utilisateur peut sélectionner l'un des mécanismes de verrouillage disponibles, tels que Aucun, Schéma, Code PIN (numérique) ou Mot de passe (alphanumérique). Lorsqu'une stratégie de mots de passe est configurée, les types de mots de passe moins sécurisés que ceux définis dans la règle sont désactivés. Par exemple, si la qualité du mot de passe "numérique" est configurée, l'utilisateur peut choisir le mot de passe PIN (numérique) ou le mot de passe (alphanumérique).

Une fois que l'appareil est correctement sécurisé en configurant un mot de passe de verrouillage d'écran approprié, l'application autorise l'accès au contenu sécurisé.

Kotlin

when {
    !dpm.isAdminActive(policyAdmin) -> {
        // Activates device administrator.
        ...
    }
    !dpm.isActivePasswordSufficient -> {
        // Launches password set-up screen in Settings.
        ...
    }
    else -> {
        // Grants access to secure content.
        ...
        startActivity(Intent(context, SecureActivity::class.java))
    }
}

Java

if (!dpm.isAdminActive(..)) {
    // Activates device administrator.
    ...
} else if (!dpm.isActivePasswordSufficient()) {
    // Launches password set-up screen in Settings.
    ...
} else {
    // Grants access to secure content.
    ...
    startActivity(new Intent(context, SecureActivity.class));
}