Vue d’ensemble des stratégies de protection des applications
Intune stratégies de protection des applications (APP) sont des règles qui garantissent que les données d’un organization restent sécurisées ou contenues dans une application gérée. Ces stratégies vous permettent de contrôler la façon dont les données sont consultées et partagées par les applications sur les appareils mobiles. Une stratégie peut être une règle qui est appliquée lorsque l’utilisateur tente d’accéder à des données « d’entreprise » ou de les déplacer, ou s’il tente un ensemble d’actions interdites ou surveillées lorsqu’il se trouve dans l’application. Une application gérée dans Intune est une application protégée qui a Intune stratégies de protection des applications qui lui sont appliquées et qui est gérée par Intune.
L’utilisation de stratégies de protection des applications Intune présente plusieurs avantages, notamment la protection des données d’entreprise sur les appareils mobiles sans nécessiter l’inscription des appareils et le contrôle de la façon dont les données sont accessibles et partagées par les applications sur les appareils mobiles.
Voici quelques exemples d’utilisation de stratégies de protection des applications avec Microsoft Intune :
- Exiger un code confidentiel ou une empreinte digitale pour accéder à la messagerie d’entreprise sur un appareil mobile
- Empêcher les utilisateurs de copier et coller des données d’entreprise dans des applications personnelles
- Restriction de l’accès aux données d’entreprise uniquement aux applications approuvées
De nombreuses applications de productivité, telles que les applications Microsoft 365 (Office), peuvent être gérées à l’aide de Intune MAM. Consultez la liste officielle des applications protégées par Microsoft Intune accessibles au public.
Comment protéger les données d’application
Vos employés utilisent des appareils mobiles pour des tâches à la fois personnelles et professionnelles. Tout en veillant à ce que vos employés continuent à être productifs, vous souhaitez éviter toute perte de données, qu’elle soit intentionnelle ou non. Vous souhaiterez également protéger les données d’entreprise accessibles à partir d’appareils qui ne sont pas gérés par vous.
Vous pouvez utiliser des stratégies de protection des applications Intune indépendamment de toute solution de gestion des appareils mobiles (GAM). Cette indépendance vous aide à protéger les données de votre entreprise avec ou sans inscription des appareils auprès d’une solution de gestion. En implémentant des stratégies au niveau de l’application, vous pouvez restreindre l’accès aux ressources d’entreprise et conserver les données au sein de votre département informatique.
Stratégies de protection des applications sur les appareils
Les stratégies de protection des applications peuvent être configurées pour les applications qui s'exécutent sur des appareils qui sont :
inscrits dans Microsoft Intune : ces appareils sont généralement possédés par une entreprise ;
Inscrit dans une solution tierce de gestion des appareils mobiles (GPM) : Ces appareils appartiennent généralement à l’entreprise.
Remarque
Les stratégies de gestion des applications mobiles ne doivent pas être utilisées avec des solutions tierces de gestion des applications mobiles ou de conteneur sécurisé.
Non inscrits dans une solution de gestion des appareils mobiles : Ces appareils sont généralement des appareils appartenant aux employés qui ne sont pas gérés ou inscrits dans Intune ou d'autres solutions MDM.
Importante
Vous pouvez créer des stratégies de gestion des applications mobiles pour les applications mobiles Office qui se connectent aux services Microsoft 365. Vous pouvez aussi protéger l’accès aux boîtes aux lettres locales Exchange en créant des stratégies de protection d’application Intune pour Outlook sous iOS/iPadOS et Android avec authentification moderne hybride. Avant d’utiliser cette fonctionnalité, vérifiez que vous répondez aux exigences relatives à Outlook pour iOS/iPadOS et Android. Les stratégies de protection d’applications ne sont pas prises en charge pour les autres applications qui se connectent à des services Exchange ou SharePoint sur site.
Avantages de l’utilisation de stratégies de protection des applications
Les principaux avantages de l’utilisation de stratégies de protection des applications sont les suivants :
Protection des données de votre entreprise au niveau des applications. Étant donné que la gestion des applications mobiles ne nécessite pas de gestion des appareils, vous pouvez protéger les données d’entreprise à la fois sur les appareils gérés et non gérés. La gestion est centrée autour de l’identité de l’utilisateur, ce qui supprime la nécessité de gérer les appareils.
La productivité des utilisateurs finaux n’est pas affectée et les stratégies ne s’appliquent pas en cas d’utilisation de l’application dans un contexte personnel. Les stratégies sont appliquées uniquement dans un contexte professionnel, ce qui vous donne la possibilité de protéger les données d’entreprise sans toucher aux données personnelles.
Les stratégies de protection des applications permettent de s'assurer que les protections de la couche des applications sont en place. Par exemple, vous pouvez :
- Exiger un code PIN pour ouvrir une application dans un contexte professionnel
- Contrôler le partage de données entre applications
- Empêcher l'enregistrement des données des applications de l'entreprise sur un emplacement de stockage personnel
La gestion des appareils mobiles, en plus de celle des applications mobiles, permet de s’assurer que l’appareil est protégé. Par exemple, vous pouvez demander un code confidentiel pour accéder à l’appareil ou déployer des applications gérées sur l’appareil. Vous pouvez également déployer des applications sur des appareils via votre solution MDM, pour mieux contrôler la gestion des applications.
Il existe d’autres avantages à utiliser la gestion des appareils mobiles (MDM) avec des stratégies de protection des applications, et les entreprises peuvent, ou non, les utiliser simultanément. Considérons, par exemple, un employé qui utilise à la fois un téléphone fourni par l’entreprise et sa propre tablette personnelle. Le téléphone de l’entreprise est inscrit dans la gestion des appareils mobiles (MAM) et protégé par des stratégies de protection des applications, tandis que l’appareil personnel est protégé uniquement par des stratégies de protection des applications.
Si vous appliquez une stratégie de gestion MAM à l’utilisateur sans définir l’état de l’appareil, l’utilisateur reçoit la stratégie à la fois sur l’appareil BYOD et sur l’appareil géré par Intune. Vous pouvez également appliquer des stratégies GAM en fonction de l’état de gestion des appareils. Pour plus d’informations, consultez Stratégies de protection des applications cibles basées sur l’état de gestion des appareils. Lorsque vous créez une stratégie de protection des applications, sélectionnez Non en regard de Cibler tous les types d’applications. Ensuite, effectuez l’une des opérations suivantes :
- Appliquer une stratégie de gestion MAM moins stricte aux appareils gérés par Intune et une autre plus stricte aux appareils non inscrits à la gestion MDM.
- Appliquer une stratégie de gestion MAM aux appareils non inscrits exclusivement.
Plateformes prises en charge pour les stratégies de protection des applications
Intune propose une palette de fonctionnalités permettant d’obtenir les applications souhaitées sur les appareils sur lesquels vous voulez les exécuter. Pour plus d’informations, consultez Fonctionnalités de gestion d’application par plateforme.
La prise en charge de la plateforme des stratégies de protection des applications Intune s’aligne sur la prise en charge de la plateforme des applications mobiles Office pour les appareils Android et iOS/iPadOS. Pour plus d’informations, consultez la section Applications mobiles de la Configuration requise pour Office.
Préversion : en outre, vous pouvez créer des stratégies de protection des applications pour les appareils Windows. Pour plus d’informations, consultez Protection d'applications’expérience pour les appareils Windows.
Importante
Le Portail d’entreprise Intune est requis sur l’appareil pour recevoir des stratégies de protection des applications sur Android.
Framework de protection des données des stratégies de protection des applications
Les choix disponibles dans les stratégies de protection des applications (APP) permettent aux organisations de personnaliser la protection en fonction de leurs besoins spécifiques. Pour certaines, il peut être difficile d’identifier les paramètres de stratégie nécessaires pour implémenter un scénario complet. Pour aider les organisations à hiérarchiser le renforcement de la sécurité des points de terminaison des clients mobiles, Microsoft a introduit une taxonomie pour son framework de protection des données des stratégies de protection des applications pour la gestion des applications mobiles iOS et Android.
Le framework de protection des données des stratégies de protection des applications est organisé en trois niveaux de configuration distincts, chaque niveau s’appuyant sur le niveau précédent :
- La protection de base des données d’entreprise (niveau 1) garantit que les applications sont protégées par un code PIN et chiffrées, et effectue des opérations de réinitialisation sélective. Pour les appareils Android, ce niveau valide l’attestation des appareils Android. Il s’agit d’une configuration de niveau d’entrée qui fournit un contrôle de protection des données similaire dans les stratégies de boîte aux lettres Exchange Online et présente l’informatique ainsi que le nombre des utilisateurs aux stratégies de protection des applications.
- La protection améliorée des données d’entreprise (niveau 2) présente les mécanismes de prévention des fuites de données des stratégies de protection des applications et les exigences minimales du système d’exploitation. Il s’agit de la configuration qui s’applique à la plupart des utilisateurs mobiles accédant à des données professionnelles ou scolaires.
- La protection élevée des données d’entreprise (niveau 3) présente les mécanismes avancés de protection des données, une configuration de code PIN améliorée et une protection contre les menaces mobiles pour les stratégies de protection des applications. Cette configuration est souhaitable pour les utilisateurs qui accèdent à des données à risque élevé.
Pour afficher les recommandations spécifiques pour chaque niveau de configuration et les applications minimales à protéger, consultez Framework de protection des données à l’aide de stratégies de protection des applications.
Comment les stratégies de protection d’application protègent les données d’application
Applications sans stratégies de protection des applications
Lorsque les applications sont utilisées sans aucune restriction, les données d’entreprise et personnelles peuvent se mélanger. Les données de l'entreprise peuvent se retrouver dans des endroits comme le stockage personnel ou être transférées vers des applications qui ne sont pas de votre ressort et entraîner une perte de données. Dans le diagramme suivant, les flèches indiquent un déplacement des données sans restriction entre des applications aussi bien professionnelles que personnelles, et vers des emplacements de stockage.
Protection des données avec stratégies de protection des applications (APP)
Vous pouvez utiliser des stratégies de protection des applications pour empêcher l’enregistrement des données de l’entreprise sur le stockage local de l’appareil (voir l’image ci-dessous). Vous pouvez également limiter le déplacement de données vers d’autres applications qui ne sont pas protégées par des stratégies de protection des applications. Les paramètres de stratégie de protection d’application comprennent :
- Stratégies de réadressage des données telles que Enregistrer des copies des données de l’organisation et Restreindre couper, copier et coller.
- Des paramètres de stratégie d’accès comme Demander un code confidentiel simple pour l’accès et Bloquer l’exécution des applications gérées sur les appareils jailbreakés ou rootés.
Protection des données avec application sur des appareils gérés par une solution de gestion des appareils mobiles
L’illustration ci-dessous montre les couches de protection offertes par les stratégies combinées de gestion des appareils mobiles et de protection des applications.
La solution de gestion des appareils mobiles ajoute de la valeur en fournissant les éléments suivants :
- Inscrit l’appareil
- Déploie les applications sur l’appareil.
- Assure la gestion et la conformité de l’appareil en continu
Les stratégies de protection des applications ajoutent de la valeur en fournissant les éléments suivants :
- Empêcher la fuite des données d’entreprise vers des applications et des services de particuliers
- Appliquer des restrictions comme enregistrement sous, Presse-papiers ou code PIN aux applications clientes
- Elles permettent d’effacer les données d’entreprise des applications lorsque cela est nécessaire sans supprimer ces applications de l’appareil
Protection des données avec des stratégies de protection des données d’application pour les appareils sans inscription
Le schéma suivant illustre le fonctionnement des stratégies de protection des données au niveau de l’application sans gestion des appareils mobiles.
Pour les appareils BYOD non inscrits dans une solution MDM, les politiques de protection des applications peuvent aider à protéger les données de l'entreprise au niveau des applications. Cependant, il existe certaines limites à connaître, dont les suivantes :
- Vous ne pouvez pas déployer d'applications sur l'appareil. L’utilisateur final doit obtenir les applications depuis le Store.
- Vous ne pouvez pas configurer des profils de certificat sur ces appareils.
- Vous ne pouvez pas provisionner les paramètres Wi-Fi et VPN de l'entreprise sur ces appareils.
Les applications que vous pouvez gérer grâce aux stratégies de protection des applications
Toute application intégrée avec le Kit de développement logiciel (SDK) Intune ou packagée par l’outil de création de packages d’applications Intune peut être managée à l’aide de stratégies de protection des applications Intune. Voir la liste officielle des applications protégées Microsoft Intune qui ont été construites à l'aide de ces outils et sont disponibles pour un usage public.
L’équipe de développement du SDK Intune teste et maintient activement la prise en charge des applications générées avec les plateformes Android, iOS/iPadOS (Obj-C, Swift), Xamarin et Xamarin.Forms natives. Bien que certains clients aient réussi à intégrer Intune SDK à d’autres plateformes telles que React Native et NativeScript, nous ne fournissons pas de conseils ou de plug-ins explicites pour les développeurs d’applications utilisant autre chose que nos plateformes prises en charge.
Exigences de l'utilisateur final pour utiliser les stratégies de protection des applications
La liste suivante fournit les exigences de l'utilisateur final pour utiliser les stratégies de protection des applications sur une application gérée par Intune :
L’utilisateur final doit disposer d’un compte Microsoft Entra. Consultez Ajouter des utilisateurs et accorder des autorisations d’administration à Intune pour savoir comment créer des utilisateurs Intune dans Microsoft Entra ID.
L’utilisateur final doit disposer d’une licence pour Microsoft Intune attribuée à son compte Microsoft Entra. Consultez la section Gérer les licences Intune pour apprendre à attribuer des licences Intune à des utilisateurs finaux.
L’utilisateur final doit appartenir à un groupe de sécurité ciblé par une stratégie de protection d’application. La même stratégie de protection d’application doit cibler l’application spécifique utilisée. Protection d'applications stratégies peuvent être créées et déployées dans le centre d’administration Microsoft Intune. Des groupes de sécurité peuvent actuellement être créés dans le centre d’administration Microsoft 365.
L’utilisateur final doit se connecter à l’application à l’aide de son compte Microsoft Entra.
Protection d'applications stratégies pour les applications Microsoft 365 (Office)
Il existe quelques exigences supplémentaires que vous souhaitez connaître lorsque vous utilisez des stratégies Protection d'applications avec des applications Microsoft 365 (Office).
Importante
Intune gestion des applications mobiles (GAM) sur Android nécessite Microsoft Entra ID’inscription des appareils pour les applications Microsoft 365. Pour améliorer la sécurité, les appareils Android doivent être inscrits auprès de Microsoft Entra ID pour continuer à recevoir la stratégie GAM pour les applications Microsoft 365.
Lors de l’accès aux applications Microsoft 365 ciblées avec une stratégie GAM, les utilisateurs peuvent être invités à s’authentifier si l’appareil n’est pas déjà inscrit avec l’ID Entra. Les utilisateurs doivent terminer le processus d’authentification et d’inscription pour accéder à leurs applications compatibles gam Microsoft 365.
Si les stratégies d’accès conditionnel ou l’authentification multifacteur sont activées, les appareils doivent déjà être inscrits et les utilisateurs ne remarqueront aucune modification.
Pour afficher les appareils inscrits, accédez au rapport centre d’administration Microsoft Entra>Appareils>Tous les appareils, filtrez par système d’exploitation et triez par Inscrit. Pour plus d’informations, consultez Gérer les identités des appareils à l’aide du centre d’administration Microsoft Entra.
Application mobile Outlook
Les exigences supplémentaires pour utiliser l’application mobile Outlook comprennent les suivantes :
L’utilisateur final doit avoir installé l’application mobile Outlook sur son appareil.
L’utilisateur final doit disposer d’une boîte aux lettres et d’une licence Microsoft 365 Exchange Online liées à son compte Microsoft Entra.
Remarque
Actuellement, l’application mobile Outlook prend uniquement en charge Intune App Protection pour Microsoft Exchange Online et Exchange Server avec l’authentification moderne hybride et ne prend pas en charge Exchange dans Office 365 Dedicated.
Word, Excel et PowerPoint
Les exigences supplémentaires pour utiliser les applications mobiles Word, Excel et PowerPoint comprennent les suivantes :
L’utilisateur final doit disposer d’une licence pour Applications Microsoft 365 pour les PME ou entreprise liée à son compte Microsoft Entra. L’abonnement doit inclure les applications Microsoft 365 sur les appareils mobiles et peut inclure un compte de stockage cloud avec OneDrive Entreprise. Les licences Microsoft 365 peuvent être attribuées via le Centre d’administration Microsoft 365 en suivant ces instructions.
L’utilisateur final doit avoir configuré un emplacement géré à l’aide de la fonctionnalité granulaire Enregistrer sous, qui se trouve sous le paramètre de stratégie de protection des applications « Enregistrer des copies des données de l’organisation ». Si, par exemple, l’emplacement géré est OneDrive, l’application OneDrive doit être configurée dans l’application Word, Excel ou PowerPoint de l’utilisateur final.
Si l'emplacement géré est OneDrive, l'application doit être ciblée par la politique de protection des applications déployée pour l'utilisateur final.
Remarque
Les applications mobiles Office ne prennent actuellement en charge que SharePoint Online et non SharePoint sur site.
Emplacement géré requis pour Office
Un emplacement géré (p. ex., OneDrive) est nécessaire pour Office. Intune marque toutes les données de l’application en tant que données « d’entreprise » ou « personnelles ». Les données sont considérées comme « d’entreprise » lorsqu’elles proviennent d’un emplacement de l’entreprise. Pour les applications Microsoft 365, Intune considère les éléments suivants comme des emplacements professionnels : courrier électronique (Exchange) ou stockage cloud (application OneDrive avec un compte OneDrive Entreprise).
Skype Entreprise
Il existe des exigences supplémentaires pour utiliser Skype Entreprise. Voir les conditions requises pour les licences de Skype Entreprise. Pour Skype Entreprise (SfB) hybrides et locales, consultez Authentification moderne hybride pour SfB et Exchange en disponibilité générale et Authentification moderne pour SfB OnPrem avec Microsoft Entra ID, respectivement.
Stratégie globale de protection des applications
Si un administrateur OneDrive accède à admin.onedrive.com et sélectionne Accès à l’appareil, il peut définir des contrôles de Gestion des applications mobiles sur les applications clientes OneDrive et SharePoint.
Les paramètres, disponibles dans la console d’administration de OneDrive, configurent une stratégie de protection des applications Intune spéciale appelée stratégie Globale. Applicable à tous les utilisateurs dans votre locataire, cette stratégie globale n’offre aucun moyen de contrôler le ciblage de stratégie.
Une fois cette stratégie activée, les applications OneDrive et SharePoint pour iOS/iPadOS et Android sont protégées avec les paramètres sélectionnés par défaut. Un professionnel de l’informatique peut modifier cette stratégie dans le centre d’administration Microsoft Intune pour ajouter des applications plus ciblées et modifier n’importe quel paramètre de stratégie.
Par défaut, il ne peut y avoir qu’une seule stratégie Globale par locataire. Toutefois, vous pouvez utiliser les API Graph Intune pour créer des stratégies globales supplémentaires par locataire, mais nous vous le déconseillons. En effet, la résolution des problèmes liés à l’implémentation d’une telle stratégie peut s’avérer complexe.
Si la stratégie globale s'applique à tous les utilisateurs de votre locataire, toute stratégie de protection des applications Intune standard remplacera ces paramètres.
Remarque
Les paramètres de stratégie dans le Centre d’administration OneDrive ne sont plus mis à jour. Microsoft Intune peut être utilisé à la place. Pour plus d’informations, consultez Contrôler l’accès aux fonctionnalités dans les applications mobile OneDrive et SharePoint.
Fonctionnalités de protection des applications
Prise en charge de plusieurs identités
La prise en charge de plusieurs identités permet à une application de prendre en charge plusieurs publics. Ces publics sont à la fois des utilisateurs « d’entreprise » et des utilisateurs « personnels ». Les comptes professionnels et scolaires sont utilisés par les publics « d’entreprise », tandis que les comptes personnels sont utilisés pour les audiences grand public, comme les utilisateurs de Microsoft 365 (Office). Une application qui prend en charge la multi-identité peut être publiée publiquement ; les stratégies de protection des applications s’appliquent alors uniquement lorsque l’application est utilisée dans le contexte professionnel et scolaire (« entreprise »). La prise en charge de la multi-identité utilise le Kit de développement logiciel (SDK) Intune d’appliquer des stratégies de protection des applications uniquement au compte professionnel ou scolaire connecté à l’application. Si un compte personnel est connecté à l'application, les données ne sont pas modifiées. Les stratégies de protection des applications peuvent être utilisées pour empêcher le transfert des données d’un compte professionnel ou scolaire vers des comptes personnels au sein de l’application multi-identité, des comptes personnels au sein d’autres applications ou des applications personnelles.
Importante
Même si une application prend en charge plusieurs identités, seule une identité « d’entreprise » peut appliquer une stratégie Intune App Protection.
Pour un exemple de contexte « personnel », prenons l’exemple d’un utilisateur qui démarre un nouveau document dans Word, ce contexte étant considéré comme personnel, Intune stratégies App Protection ne sont pas appliquées. Une fois le document enregistré sur le compte OneDrive « d’entreprise », il est considéré comme un contexte « d’entreprise » et Intune stratégies De protection des applications sont appliquées.
Prenons les exemples suivants pour un contexte professionnel ou d’entreprise :
- Un utilisateur démarre l’application OneDrive à l’aide de son compte professionnel. Dans le contexte professionnel, ils ne peuvent pas déplacer des fichiers vers un emplacement de stockage personnel. Plus tard, quand il utilise OneDrive avec son compte personnel, il peut copier et déplacer des données à partir de son compte personnel OneDrive sans restrictions.
- Un utilisateur commence à rédiger un e-mail dans l’application Outlook. Une fois que l’objet ou le corps du message est rempli, l’utilisateur ne peut pas changer l’adresse de l’expéditeur du contexte professionnel vers le contexte personnel, car l’objet et le corps du message sont protégés par la stratégie App Protection.
Remarque
Outlook dispose d’une vue de messagerie combinée des e-mails « personnels » et « d’entreprise ». Dans ce cas, l’application Outlook vous invite à entrer le code confidentiel Intune au lancement.
Importante
Bien qu’Edge se place dans un contexte « d’entreprise », l’utilisateur peut déplacer intentionnellement les fichiers de contexte « d’entreprise » OneDrive vers un emplacement de stockage cloud personnel inconnu. Pour éviter cela, consultez Gérer les sites web pour autoriser le chargement de fichiers et configurer la liste des sites autorisés/bloqués pour Edge.
Code PIN d’application Intune
Le numéro d'identification personnel (PIN) est un code de passe utilisé pour vérifier que le bon utilisateur accède aux données de l'organisation dans une application.
Invite à entrer le code PIN
Intune n’invite l’utilisateur à saisir le code PIN de l’application que s’il est sur le point d’accéder à des données « d’entreprise ». Dans les applications multi-identité telles que Word, Excel ou PowerPoint, l’utilisateur est invité à entrer son code PIN lorsqu’il tente d’ouvrir un fichier ou un document « d’entreprise ». Dans les applications à identité unique, par exemple, les applications métier managées avec l’outil de création de packages d’applications Intune, le code PIN est demandé au lancement, car le Kit de développement logiciel (SDK) Intune sait que l’expérience utilisateur dans l’application est toujours de type « entreprise ».
Fréquence des invites à entrer le code confidentiel ou les informations d’identification d’entreprise
L’administrateur informatique peut définir le paramètre de stratégie de protection des applications Intune Revérifier les conditions d’accès après (minutes) dans le centre d’administration Microsoft Intune. Ce paramètre spécifie le délai avant que les conditions d’accès ne soient vérifiées sur l’appareil et que l’écran du code PIN de l’application ou l’invite de demande d’informations d’identification d’entreprise ne réapparaisse. Cependant, les détails importants concernant le PIN qui affectent la fréquence à laquelle l'utilisateur sera sollicité sont :
-
Le code PIN est partagé entre les applications du même éditeur pour améliorer la convivialité :
Sur iOS/iPadOS, un code PIN d’application est partagé entre toutes les applications du même éditeur d’application. Par exemple, toutes les applications Microsoft partagent le même code PIN. Sur Android, un même code PIN d’application est partagé entre toutes les applications. -
Le comportement Revérifier les exigences d’accès après (minutes), après un redémarrage de l’appareil :
Un minuteur suit le nombre de minutes d’inactivité déterminant quand afficher à nouveau l’invite du code PIN d’application Intune ou l’invite de demande d’informations d’identification d’entreprise. Sur iOS/iPadOS, ce minuteur n’est pas affecté par le redémarrage de l’appareil. Ainsi, le redémarrage de l’appareil n’a pas d’effet sur le nombre de minutes d’inactivité de l’utilisateur pour une application iOS/iPadOS avec la stratégie de code PIN Intune (ou d’informations d’identification d’entreprise) ciblée. Sur Android, la minuterie est réinitialisée au redémarrage de l'appareil. Ainsi, les applications Android avec la stratégie de code PIN Intune (ou d’informations d’identification d’entreprise) vont probablement demander le code PIN d’une application ou les informations d’identification d’entreprise, quelle que soit la valeur du paramètre « Revérifier les exigences d’accès après (minutes) » après un redémarrage de l’appareil. -
La nature roulante de la minuterie associée au PIN :
Une fois qu’un code PIN est entré pour accéder à une application (l’application A) et que l’application quitte le premier plan (le focus d’entrée principal) sur l’appareil, le minuteur est réinitialisé pour ce code PIN. Toute application (application B) qui partage ce code confidentiel n’invite pas l’utilisateur à entrer le code confidentiel, car le minuteur a été réinitialisé. L’invite réapparaît une fois que la valeur de « Revérifier les exigences d’accès après (minutes) » est à nouveau atteinte.
Pour les appareils iOS/iPadOS, même si le code confidentiel est partagé entre des applications de différents éditeurs, l’invite s’affiche à nouveau lorsque la valeur Revérifier les exigences d’accès après (minutes) est à nouveau remplie pour l’application qui n’est pas le main focus d’entrée. Par exemple, un utilisateur a application A de l’éditeur X et l’application B de l’éditeur Y, et ces deux applications partagent le même code PIN. L’utilisateur travaille avec l’application A (au premier plan) et l’application B est réduite. Une fois que la valeur de Revérifier les spécifications requises pour l’accès après (minutes) est atteinte et que l’utilisateur passe à l’application B, celui-ci doit entrer le code PIN.
Remarque
Pour vérifier les exigences d’accès de l’utilisateur plus souvent (par exemple, invite de code confidentiel), en particulier pour une application fréquemment utilisée, il est recommandé de réduire la valeur du paramètre « Revérifier les exigences d’accès après (minutes) ».
Codes PIN d’application intégrés pour Outlook et OneDrive
Le code PIN Intune fonctionne sur la base d’un minuteur d’inactivité (la valeur de Revérifier les exigences d’accès après (minutes)). Ainsi, les invites PIN d'Intune s'affichent indépendamment des invites PIN des applications intégrées pour Outlook et OneDrive, qui sont souvent liées au lancement de l'application par défaut. Si l’utilisateur reçoit en même temps les deux demandes de code PIN, le comportement attendu doit être que le code PIN Intune est prioritaire.
Sécurité du code PIN Intune
Le code PIN sert à autoriser uniquement les utilisateurs adéquats à accéder aux données de leur organisation dans l’application. Par conséquent, un utilisateur final doit se connecter avec son compte professionnel ou scolaire pour pouvoir définir ou réinitialiser son code PIN d’application Intune. Cette authentification est gérée par Microsoft Entra ID via l’échange de jetons sécurisé et n’est pas transparente pour le SDK Intune. Du point de vue de la sécurité, la meilleure manière de protéger les données professionnelles ou scolaires consiste à les chiffrer. Le chiffrement n’est pas lié au code confidentiel de l’application, mais il s’agit de sa propre stratégie de protection des applications.
Protection contre les attaques par force brute et code PIN Intune
Dans le cadre de la stratégie de code PIN d’application, l’administrateur peut définir un nombre maximal de tentatives d’authentification de son code PIN avant le verrouillage de l’application. Une fois que le nombre de tentatives atteint, le Kit de développement logiciel (SDK) Intune peut réinitialiser les données « d’entreprise » dans l’application.
Code PIN Intune et réinitialisation sélective
Sur iOS/iPadOS, les informations de code PIN au niveau de l’application sont stockées dans la chaîne de clés partagée entre les applications du même éditeur, par exemple toutes les applications Microsoft principales. Ces informations PIN sont également liées à un compte d'utilisateur final. La réinitialisation sélective d’une application ne doit pas affecter une autre application.
Par exemple, un code PIN défini pour Outlook pour l’utilisateur connecté est stocké dans un trousseau partagé. Lorsque l’utilisateur se connecte à OneDrive (également publié par Microsoft), il voit le même code confidentiel qu’Outlook, car il utilise la même keychain partagée. Lors de la déconnexion d’Outlook ou de la réinitialisation des données utilisateur dans Outlook, le Kit de développement logiciel (SDK) Intune n’efface pas cette keychain, car OneDrive utilise peut-être toujours ce code confidentiel. Pour cette raison, les réinitialisations sélectives n’effacent pas les keychain partagées, y compris le code confidentiel. Ce comportement reste le même dans le cas où il n’y a qu’une seule application d’un éditeur sur l’appareil.
Étant donné que le code confidentiel est partagé entre les applications du même éditeur, si la réinitialisation est effectuée sur une seule application, le sdk Intune ne sait pas s’il existe d’autres applications sur l’appareil avec le même éditeur. Par conséquent, le KIT de développement logiciel (SDK) Intune n’efface pas le code confidentiel, car il peut toujours être utilisé pour d’autres applications. Le PIN de l'application devrait être effacé lorsque la dernière application de cet éditeur sera supprimée dans le cadre d'un nettoyage du système d'exploitation.
Si vous observez que le code confidentiel est réinitialisé sur certains appareils, les événements suivants se produisent probablement : étant donné que le code confidentiel est lié à une identité, si l’utilisateur s’est connecté avec un autre compte après une réinitialisation, il est invité à entrer un nouveau code confidentiel. Toutefois, s'ils se connectent avec un compte existant, un code PIN stocké dans le trousseau peut déjà être utilisé pour se connecter.
Configurer un code PIN deux fois sur des applications du même éditeur ?
Mam (sur iOS/iPadOS) autorise actuellement le code confidentiel au niveau de l’application avec des caractères alphanumériques et spéciaux (appelés « code secret ») qui nécessite la participation d’applications (par exemple, WXP, Outlook, Managed Browser Viva Engage) pour intégrer le SDK Intune pour iOS. Sans cela, les paramètres de code secret ne sont pas correctement appliqués pour les applications ciblées. Il s’agit d’une fonctionnalité publiée dans le SDK Intune pour iOS v. 7.1.12.
Afin de prendre en charge cette fonctionnalité et d'assurer la rétrocompatibilité avec les versions précédentes du kit SDK Intune pour iOS/iPadOS, tous les codes PIN (qu'il s'agisse de codes numériques ou de codes de passe) dans la version 7.1.12+ sont traités séparément du code PIN numérique dans les versions précédentes du kit SDK. Un autre changement a été introduit dans le SDK Intune pour iOS v 14.6.0 qui fait que tous les PIN dans 14.6.0+ sont traités séparément de tous les PIN dans les versions précédentes du SDK.
Par conséquent, si un appareil a des applications avec Intune SDK pour les versions iOS antérieures à 7.1.12 ET après la version 7.1.12 du même éditeur (ou les versions antérieures à 14.6.0 et postérieures à 14.6.0), ils doivent configurer deux codes confidentiels. Les deux codes confidentiels (pour chaque application) ne sont liés d’aucune façon (c’est-à-dire qu’ils doivent respecter la stratégie de protection des applications appliquée à l’application). Ainsi, uniquement si les applications A et B ont les mêmes stratégies appliquées (en ce qui concerne le PIN), l'utilisateur peut configurer le même PIN deux fois.
Ce comportement est spécifique au code PIN sur les applications iOS/iPadOS activées avec la gestion des applications mobiles Intune. Au fil du temps, à mesure que les applications adoptent les versions ultérieures du SDK Intune pour iOS/iPadOS, devoir définir deux fois un code PIN sur les applications d’un même éditeur pose moins de problèmes. Veuillez consulter la note ci-dessous pour un exemple.
Remarque
Par exemple, si l'application A est construite avec une version antérieure à 7.1.12 (ou 14.6.0) et que l'application B est construite avec une version supérieure ou égale à 7.1.12 (ou 14.6.0) du même éditeur, l'utilisateur final devra configurer des codes PIN séparément pour A et B si les deux sont installés sur un appareil iOS/iPadOS.
Si une application C avec la version 7.1.9 (ou 14.5.0) du KIT de développement logiciel (SDK) est installée sur l’appareil, elle partage le même code confidentiel que l’application A.
Une application D générée avec 7.1.14 (ou 14.6.2) partage le même code confidentiel que l’application B.
Si seules les applications A et C sont installées sur un appareil, un seul code PIN devra être défini. Il en va de même si seules les applications B et D sont installées sur un appareil.
Chiffrement des données d’application
Les administrateurs informatiques peuvent déployer une stratégie de protection des applications qui exige que les données des applications soient cryptées. Dans le cadre de la stratégie, l'administrateur informatique peut également préciser quand le contenu est crypté.
Comment se déroule le processus de cryptage des données d'Intune
Pour plus d’informations sur le paramètre de chiffrement de stratégie de protection des applications, consultez Paramètres de stratégie de protection des applications Android et Paramètres de stratégie de protection des applications iOS/iPadOS.
Les données chiffrées
Seules les données marquées comme « d’entreprise » sont chiffrées en fonction de la stratégie de protection des applications de l’administrateur. Les données sont considérées comme « d’entreprise » lorsqu’elles proviennent d’un emplacement de l’entreprise. Pour les applications Microsoft 365, Intune considère les éléments suivants comme des emplacements professionnels :
- E-mail (Exchange)
- Stockage cloud (application OneDrive avec un compte OneDrive Entreprise)
Dans le cas des applications métier gérées par l’outil de création de packages d’applications Intune, toutes les données sont considérées comme étant de type « entreprise ».
Réinitialisation sélective
Effacement à distance des données
Intune peut réinitialiser les données d’application de trois façons différentes :
- Réinitialisation complète de l’appareil
- Réinitialisation sélective pour la gestion des appareils mobiles
- Réinitialisation sélective pour gestion des applications mobiles
Pour plus d'informations sur l'effacement à distance pour MDM, reportez-vous à la section Supprimer des appareils en utilisant l'effacement ou le retrait. Pour plus d'informations sur l'effacement sélectif à l'aide de MAM, voir l'action Retirer et Comment effacer uniquement les données d'entreprise des applications.
La réinitialisation complète de l’appareil supprime toutes les données et paramètres utilisateur de l’appareil en restaurant les paramètres d’usine par défaut de l’appareil. L'appareil est supprimé d'Intune.
Remarque
La réinitialisation d’un appareil et une réinitialisation sélective pour la gestion des appareils mobiles sont possibles uniquement sur les appareils inscrits à la gestion des appareils mobiles (MDM) Intune.
Effacement sélectif pour MDM
Voir Supprimer les appareils – retraite pour en savoir plus sur la suppression des données de l'entreprise.
Réinitialisation sélective pour la gestion des applications mobiles
L'effacement sélectif pour MAM supprime simplement les données d'une application de l'entreprise. La demande est lancée en utilisant Intune. Pour savoir comment effectuer une demande de réinitialisation, consultez la section Guide pratique pour effacer uniquement les données d’entreprise des applications.
Si l’utilisateur utilise l’application lorsque la réinitialisation sélective est lancée, le Kit de développement logiciel (SDK) Intune contrôle toutes les 30 minutes la présence d’une requête de réinitialisation sélective du service MAM Intune. Il vérifie également l'effacement sélectif lorsque l'utilisateur lance l'application pour la première fois et se connecte avec son compte professionnel ou scolaire.
Lorsque les services sur site (on-premises) ne fonctionnent pas avec les applications protégées par Intune
La protection d’applications Intune dépend de la cohérence de l’identité de l’utilisateur entre l’application et le Kit de développement logiciel (SDK) Intune. La seule façon de le garantir est de recourir à une authentification moderne. Il existe des scénarios dans lesquels les applications peuvent fonctionner avec une configuration locale, mais ils ne sont ni cohérents ni garantis.
Un moyen sûr d'ouvrir des liens web à partir d'applications gérées
L’administrateur informatique peut déployer et définir une stratégie de protection pour Microsoft Edge, un navigateur web facile à gérer avec Intune. L’administrateur informatique peut exiger que tous les liens web dans les applications gérées par Intune soient ouverts à l’aide d’un navigateur géré.
Expérience de la protection des applications pour les appareils iOS
Empreinte digitale de l’appareil ou ID de visage
Les stratégies de protection des applications Intune permettent de contrôler l'accès aux applications uniquement pour l'utilisateur titulaire d'une licence Intune. L’un des moyens de contrôler l’accès à une application est d’exiger un Touch ID ou un Face ID Apple sur les appareils pris en charge. Intune implémente un comportement dans lequel, en cas de modification de la base de données biométrique de l’appareil, Intune invite l’utilisateur à entrer un code confidentiel lorsque la valeur de délai d’inactivité suivante est atteinte. Les changements apportés aux données biométriques incluent l’ajout et la suppression d’une empreinte digitale ou d’un visage. Si l’utilisateur Intune n’a pas de code confidentiel défini, il est amené à configurer un code confidentiel Intune.
L'objectif de ce processus est de continuer à assurer la sécurité et la protection des données de votre organisation au niveau de l'application. Cette fonctionnalité est disponible seulement pour iOS/iPadOS et nécessite la participation d’applications qui intègrent le SDK Intune pour iOS/iPadOS 9.0.1 ou ultérieur. L'intégration du SDK est nécessaire pour que le comportement puisse être appliqué aux applications ciblées. Cette intégration se produit en continu et repose sur les équipes d’application spécifiques. Parmi les applications qui participent, citons WXP, Outlook, Managed Browser et Viva Engage.
Extension de partage iOS
Vous pouvez utiliser l’extension de partage iOS/iPadOS pour ouvrir les données professionnelles ou scolaires dans des applications non gérées, même si la stratégie de transfert de données est définie sur les Applications gérées uniquement ou sur Aucune application.. Intune stratégie de protection des applications ne peut pas contrôler l’extension de partage iOS/iPadOS sans gérer l’appareil. Par conséquent, Intune chiffre les données « d’entreprise » avant de les partager à l’extérieur de l’application. Vous pouvez valider ce comportement de chiffrement en essayant d’ouvrir un fichier « d’entreprise » en dehors de l’application gérée. Le fichier doit être crypté et ne peut être ouvert en dehors de l'application gérée.
Prise en charge des liens universels
Par défaut, les stratégies de protection des applications Intune empêchent l’accès au contenu non autorisé des applications. Dans iOS/iPadOS, il existe des fonctionnalités permettant d’ouvrir du contenu ou des applications spécifiques à l’aide de liens universels.
Les utilisateurs peuvent désactiver les liens universels d’une application en les visitant dans Safari et en sélectionnant Ouvrir dans un nouvel onglet ou Ouvrir. Pour utiliser des liens universels avec des stratégies de protection des applications Intune, il est important de réactiver les liens universels. L’utilisateur final doit effectuer une opération Ouvrir dans< le nom > del’application dans Safari après avoir appuyé longuement sur un lien correspondant. Cette opération doit inviter toute application protégée supplémentaire à router tous les liens universels vers l’application protégée sur l’appareil.
Plusieurs paramètres d’accès à la protection des applications Intune pour le même ensemble d’applications et d’utilisateurs
Les stratégies de protection des applications Intune pour l’accès sont appliquées dans un ordre spécifique sur les appareils des utilisateurs finaux quand ceux-ci tentent d’accéder à une application cible à partir de leur compte d’entreprise. En général, un essuyage est prioritaire, suivi d'un blocage, puis d'un avertissement inadmissible. Par exemple, si cela s’applique à l’utilisateur/application spécifique, un paramètre de système d’exploitation iOS/iPadOS minimal qui signale à un utilisateur qu’il doit mettre à niveau sa version d’iOS/iPadOS est appliqué après le paramètre de système d’exploitation iOS/iPadOS minimal qui bloque l’accès de l’utilisateur. Ainsi, dans le scénario où l’administrateur informatique configure le système d’exploitation iOS minimal sur 11.0.0.0 et le système d’exploitation iOS minimal (Avertissement uniquement) sur 11.1.0.0, alors que l’appareil qui tente d’accéder à l’application utilise iOS 10, l’utilisateur final est bloqué sur la base du paramètre le plus restrictif pour la version de système d’exploitation iOS minimal qui provoque un blocage de l’accès.
Lors du traitement de différents types de paramètres, l’exigence d’une version du SDK Intune est prioritaire, suivie de l’exigence d’une version de l’application, puis de l’exigence d’une version du système d’exploitation iOS/iPadOS. Ensuite, les avertissements éventuels pour tous les types de paramètres dans le même ordre sont vérifiés. Nous vous recommandons de configurer l’exigence de version de kit de développement logiciel (SDK) Intune uniquement sur recommandation de l’équipe de produit Intune pour les principaux scénarios de blocage.
Expérience de protection des applications pour les appareils Android
Remarque
Les stratégies Protection d'applications (APP) ne sont pas prises en charge sur Intune appareils Android Enterprise dédiés gérés sans mode d’appareil partagé. Sur ces appareils, Portail d'entreprise’installation est nécessaire pour qu’une stratégie de blocage d’application prenne effet sans impact sur l’utilisateur. les stratégies Protection d'applications sont prises en charge sur Intune appareils Android Entreprise dédiés gérés en mode d’appareil partagé, ainsi que sur les appareils AOSP sans utilisateur qui tirent parti du mode Appareil partagé.
Appareils Android Microsoft Teams
L’application Teams sur les appareils Android Microsoft Teams ne prend pas en charge l’APPLICATION (ne reçoit pas de stratégie via l’application Portail d'entreprise). Cela signifie que les paramètres de stratégie de protection des applications ne seront pas appliqués à Teams sur les appareils Android Microsoft Teams. Si vous avez configuré des stratégies de protection des applications pour ces appareils, envisagez de créer un groupe d’utilisateurs d’appareils Teams et d’exclure ce groupe des stratégies de protection des applications associées. En outre, envisagez de modifier votre stratégie d’inscription Intune, les stratégies d’accès conditionnel et les stratégies de conformité Intune afin qu’elles aient des paramètres pris en charge. Si vous ne pouvez pas modifier vos stratégies existantes, vous devez configurer (exclusion) Les filtres d’appareil. Vérifiez chaque paramètre par rapport à la configuration de l’accès conditionnel existante et la stratégie de conformité Intune pour savoir si vous avez des paramètres non pris en charge. Pour plus d’informations, consultez les stratégies de Stratégies de conformité des appareils Intune et d’accès conditionnel prises en charge pour les appareils Salles Microsoft Teams et Teams Android. Pour plus d’informations sur Salles Microsoft Teams, consultez L’accès conditionnel et la conformité Intune pour les Salles Microsoft Teams.
Authentification biométrique des appareils
Pour les appareils Android qui prennent en charge l’authentification biométrique, vous pouvez autoriser les utilisateurs finaux à utiliser l’empreinte digitale ou le déverrouillage par reconnaissance faciale, selon ce que prend en charge leur appareil Android. Vous pouvez configurer les types biométriques autorisés pour l’authentification, au-delà de l’empreinte digitale. Notez que l’empreinte digitale et le déverrouillage par reconnaissance faciale ne sont disponibles que pour les appareils conçus pour prendre en charge ces types biométriques et qui exécutent la version appropriée d’Android. L’authentification par empreinte digitale nécessite Android 6 et supérieur, et l’authentification par reconnaissance faciale nécessite Android 10 et supérieur.
Protection des applications du portail de l'entreprise et des applications Intune
La plupart des fonctionnalités de protection des applications sont intégrées à l’application Portail d’entreprise. L’inscription de l’appareil n’est pas obligatoire*, même si l’application Portail d'entreprise est toujours requise. Pour la gestion des applications mobiles (MAM), il suffit à l'utilisateur final d'installer l'application Company Portal sur son appareil.
Plusieurs paramètres d’accès à la protection des applications Intune pour le même ensemble d’applications et d’utilisateurs
Les stratégies de protection des applications Intune pour l’accès sont appliquées dans un ordre spécifique sur les appareils des utilisateurs finaux quand ceux-ci tentent d’accéder à une application cible à partir de leur compte d’entreprise. En général, un bloc est prioritaire, puis un avertissement ignoré. Par exemple, si cela s’applique à l’utilisateur/application en question, un paramètre de version de correctif Android minimale qui signale à un utilisateur qu’il doit effectuer une mise à niveau de correctif sera appliqué après le paramètre de version de correctif Android minimale qui bloque l’accès à l’utilisateur. Ainsi, dans le scénario où l’administrateur informatique configure la version de correctif Android minimale sur 2018-03-01 et la version de correctif Android minimale (Avertissement uniquement) sur 2018-02-01, alors que l’appareil qui tente d’accéder à l’application utilise une version de correctif 2018-01-01, l’utilisateur final est bloqué sur la base du paramètre le plus restrictif pour la version de correctif Android minimale qui provoque un blocage de l’accès.
Lorsque vous traitez différents types de paramètres, une exigence de version d’application est prioritaire, suivie d’une exigence de version du système d’exploitation Android et d’une exigence de version de correctif Android. Ensuite, tous les avertissements sont vérifiés pour tous les types de paramètres dans le même ordre.
Intune stratégies de protection des applications et case activée d’intégrité des appareils Google Play pour les appareils Android
Intune stratégies de protection des applications permettent aux administrateurs d’exiger que les appareils des utilisateurs finaux passent les case activée d’intégrité des appareils Google Play pour les appareils Android. Une nouvelle détermination de service Google Play est signalée à l’administrateur informatique à un intervalle déterminé par le service Intune. La fréquence à laquelle l’appel de service est limité en raison de la charge. Par conséquent, cette valeur est conservée en interne et n’est pas configurable. Toute action configurée par l’administrateur informatique pour le paramètre d’intégrité de l’appareil Google est effectuée en fonction du dernier résultat signalé au service Intune au moment du lancement conditionnel. S’il n’y a pas de données, l’accès est autorisé en fonction de l’échec des autres vérifications de lancement conditionnel, et le service Google Play « aller-retour » pour déterminer les résultats de l’attestation commence dans le back-end et invite l’utilisateur de façon asynchrone si l’appareil a échoué. S’il existe des données obsolètes, l’accès est bloqué ou autorisé en fonction du dernier résultat signalé. De même, un « aller-retour » du service Google Play pour déterminer les résultats de l’attestation commence et invite l’utilisateur de façon asynchrone si l’appareil a échoué.
Stratégies de protection des applications Intune et API de vérification des applications de Google pour les appareils Android
Les stratégies Intune App Protection permettent aux administrateurs d’exiger que les appareils des utilisateurs finaux envoient des signaux par le biais de l’API de vérification des applications de Google pour les appareils Android. Les instructions sur la manière de procéder varient légèrement selon les appareils. Le processus général implique d’aller sur Google Play Store, puis de cliquer sur Mes applications & jeux, de cliquer sur le résultat de la dernière analyse de l’application qui vous amènera au menu Play Protect. Assurez-vous que la case à cocher Scanner un appareil pour les menaces de sécurité est activée.
API d’intégrité play de Google
Intune s’appuie sur les API Play Integrity de Google pour ajouter à nos vérifications de détection racine existantes pour les appareils non inscrits. Google a développé et géré cet ensemble d’API pour les applications Android à adopter si elles ne veulent pas que leurs applications s’exécutent sur des appareils rootés. L’application Android Pay a par exemple incorporé cette fonctionnalité. Bien que Google ne partage pas publiquement l’intégralité des vérifications de détection racine qui se produisent, nous nous attendons à ce que ces API détectent les utilisateurs qui ont rooté leurs appareils. L’accès de ces utilisateurs peut alors être bloqué, ou leurs comptes professionnels supprimés des applications pour lesquelles une stratégie est activée. Vérifier l’intégrité de base vous informe quant à l’intégrité générale de l’appareil. Les appareils enracinés, les émulateurs, les appareils virtuels et les appareils présentant des signes d'altération manquent l'intégrité de base. Vérifier l’intégrité de base et les appareils certifiés vous informe quant à la compatibilité de l’appareil avec les services de Google. Seuls les appareils non modifiés qui ont été certifiés par Google peuvent passer ce contrôle. Les appareils suivants échoueront :
- Appareils qui échouent aux tests d’intégrité de base
- Appareils ayant un chargeur de démarrage déverrouillé
- Appareils ayant une image système/ROM personnalisée
- Appareils pour lesquels le fabricant n’a pas demandé ou obtenu la certification Google
- Appareils dotés d'une image système construite directement à partir des fichiers sources du programme Android Open Source
- Appareils ayant une image système en préversion bêta/développeur
Pour plus d’informations techniques, consultez la documentation de Google sur l’API Play Integrity de Google .
Paramètre de verdict d’intégrité de la lecture et paramètre « appareils jailbreakés/rootés »
Le verdict d’intégrité du jeu exige que l’utilisateur final soit en ligne, au moins pendant la durée de l’exécution du « aller-retour » pour déterminer les résultats de l’attestation. Si l’utilisateur final est hors connexion, l’administrateur informatique peut quand même s’attendre à ce qu’un résultat soit appliqué à cause du paramètre Appareils jailbreakés/rootés. Ceci étant dit, si l’utilisateur final est hors connexion depuis trop longtemps, la valeur Période de grâce hors connexion entre en jeu et tout accès aux données professionnelles ou scolaires est bloqué une fois cette valeur de minuteur atteinte, jusqu’à ce que l’accès réseau soit disponible. L’activation des deux paramètres permet d’adopter une approche multiniveau concernant l’intégrité des appareils des utilisateurs finaux, ce qui est important quand ceux-ci accèdent à des données professionnelles ou scolaires sur mobile.
API Google Play Protect et Google Play Services
Les paramètres de stratégie de protection des applications qui tirent parti des API Google Play Protect nécessitent Google Play Services. Les paramètres Verdict d’intégrité de la lecture et Analyse des menaces sur les applications nécessitent que la version google des services Google Play fonctionne correctement. Étant donné qu’il s’agit de paramètres qui relèvent de la sécurité, l’utilisateur final est bloqué s’il a été ciblé avec ces paramètres et ne répond pas à la version appropriée des services Google Play ou n’a pas accès à Google Play Services.
Préversion : expérience Protection d'applications pour les appareils Windows
Il existe deux catégories de paramètres de stratégie : la protection des données et les contrôles d’intégrité. Le terme application gérée par une stratégie fait référence aux applications configurées avec des stratégies de protection des applications.
Protection des données
Les paramètres de protection des données ont un impact sur les données et le contexte de l’organisation. En tant qu’administrateur, vous pouvez contrôler le déplacement des données vers et hors du contexte de la protection de l’organisation. Le contexte de l’organisation est défini par les documents, services et sites accessibles par le compte d’organisation spécifié. Les paramètres de stratégie suivants permettent de contrôler les données externes reçues dans le contexte de l’organisation et les données d’organisation envoyées à partir du contexte de l’organisation.
Contrôles d’intégrité
Les contrôles d’intégrité vous permettent de configurer les fonctionnalités de lancement conditionnel. Pour ce faire, vous devez définir les conditions de case activée d’intégrité de votre stratégie de protection des applications. Sélectionnez un paramètre et entrez la valeur que les utilisateurs doivent respecter pour accéder aux données de votre organisation. Sélectionnez ensuite l’action que vous souhaitez effectuer si les utilisateurs ne respectent pas vos conditions. Dans certains cas, plusieurs actions peuvent être configurées pour un seul paramètre.
Prochaines étapes
Comment créer et déployer des stratégies de protection des applications avec Microsoft Intune
Paramètres de stratégie de protection des applications Android disponibles avec Microsoft Intune