Vue d’ensemble des stratégies de protection des applications

Les stratégies de protection des applications Intune sont des règles qui garantissent que les données d’un organization restent sécurisées ou contenues dans une application managé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 des stratégies de protection des applications Intune 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 consultées 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 la gestion des applications mobiles Intune. 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 conteneurs sécurisés.

• 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. Il est également possible d’appliquer une stratégie de gestion MAM en fonction de l’état géré. Si vous créez une stratégie de protection d’applications, sélectionnez Non à côté de Cibler tous les types d’application. Ensuite, choisissez entre les deux solutions 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 le SDK Intune à d'autres plateformes telles que React Native et NativeScript, nous ne fournissons pas de conseils explicites ni de plugins pour les développeurs d'applications utilisant d'autres plateformes que celles que nous prenons 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).

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

  L’application mobile Outlook prend actuellement en charge uniquement Intune App Protection pour Microsoft Exchange Online et Exchange Server avec authentification moderne hybride et ne prend pas en charge Exchange dédié à Office 365.

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 Office sur des 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 Office, Intune considère les sites d’entreprise suivants : e-mail (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 », pensez à un utilisateur qui démarre un nouveau document dans Word, ceci est considéré comme un contexte personnel, donc les stratégies Intune App Protection ne sont pas appliquées. Une fois que le document est enregistré sur le compte OneDrive « d’entreprise », il est considéré comme étant de contexte « d’entreprise » et les stratégies Intune App Protection 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 sensibles, puis configurez 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 PIN ne demandera pas à l'utilisateur de le saisir car la minuterie a été réinitialisée. 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 PIN est partagé entre les applications de différents éditeurs, l’invite s’affiche à nouveau quand la valeur de Revérifier les spécifications requises pour l’accès après (minutes) est à nouveau atteinte pour l’application qui n’a pas le focus d’entrée principal. 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

Afin de vérifier plus souvent les exigences d’accès de l’utilisateur (p. ex., en demandant un code PIN), en particulier pour les applications fréquemment utilisées, 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 PIN de l’application, mais constitue 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 PIN qu’Outlook, car il utilise le même trousseau partagé. 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 ce trousseau, car OneDrive utilise peut-être toujours ce code PIN. Pour cette raison, les réinitialisations sélectives n’effacent pas ce trousseau partagé, notamment le code PIN. 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 PIN est partagé entre les applications d’un même éditeur, si la réinitialisation aboutit à une application unique, le kit de développement logiciel (SDK) Intune ne sait pas s’il y a d’autres applications du même éditeur sur l’appareil. Par conséquent, le kit de développement logiciel (SDK) Intune n’efface pas le code PIN, qui 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 NIP est effacé sur certains appareils, il est probable que la situation suivante se produise : Puisque le NIP est lié à une identité, si l'utilisateur s'est connecté avec un compte différent après un effacement, il sera invité à entrer un nouveau NIP. 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 pin 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 du code d'accès ne sont pas correctement appliqués pour les applications ciblées. Il s’agit d’une fonctionnalité publiée dans le Kit de développement logiciel (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 possède des applications avec Intune SDK pour iOS versions avant 7.1.12 ET après 7.1.12 du même éditeur (ou versions avant 14.6.0 ET après 14.6.0), il devra configurer deux PIN. Les deux PIN (pour chaque application) ne sont liés en aucune façon (c'est-à-dire qu'ils doivent respecter la stratégie) de protection des applications qui est 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 Office, Intune considère les éléments suivants comme des emplacements d’entreprise :

• 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 sur site, 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. Le comportement suivant est implémenté: si un changement est apporté à la base de données biométrique de l’appareil, Intune invite l’utilisateur à entrer un code PIN la prochaine fois que le délai d’attente d’inactivité est atteint. 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 d'Intune n'a pas de code PIN défini, il est invité à en créer un.

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.. La stratégie de protection des applications Intune 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 une fonctionnalité permettant d’ouvrir du contenu ou des applications spécifiques avec des 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 les appareils Android Entreprise gérés par Intune 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 les appareils Android Entreprise dédiés gérés par Intune avec le mode 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 Microsoft Teams Android ne prend pas en charge l'APP (elle ne reçoit pas de stratégie via l'application Company Portal). Cela signifie que les paramètres de stratégie de protection des applications ne seront pas appliqués aux 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 d’appareil n’est pas obligatoire, même si l’application Portail d’entreprise est toujours nécessaire. 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.

Stratégies de protection des applications Intune et case activée d’intégrité des appareils Google Play pour les appareils Android

Les stratégies de protection des applications Intune 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 effectué est limitée en raison de la charge. Ainsi, cette valeur est tenue à jour 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. En l’absence de données, l’accès sera autorisé à condition qu’aucun autre contrôle de lancement conditionnel n’échoue, et un « aller-retour » de Google Play Services pour déterminer les résultats d’attestation commencera dans le back-end et invitera l’utilisateur de façon asynchrone si l’attestation de l’appareil a échoué. Si les données sont périmées, l'accès sera 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 commencera et invitera l'utilisateur de manière 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 développe et gère cet ensemble d’API pour les applications Android, à adopter s’il ne souhaite pas que ses 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 contrôles de détection du rootage effectués, nous estimons que ces API sont capables de détecter les appareils qui ont été rootés par l’utilisateur. 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. Comme il s'agit de paramètres relevant du domaine de la sécurité, l'utilisateur final sera bloqué s'il a été ciblé par ces paramètres et s'il ne dispose pas de la version appropriée de Google Play Services 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

Paramètres de la stratégie de protection des applications iOS/iPadOS disponibles avec Microsoft Intune