Glossaire
App wrapping
L'app wrapping consiste à réencapsuler une application existante pour y injecter des contrôles de sécurité sans toucher à son code source : chiffrement du stockage local, blocage du copier-coller, code d'accès à l'ouverture, effacement des données à distance. C'est une technique de transition, utile quand une application ne peut pas être modifiée, et largement dépassée par les mécanismes natifs d'iOS et d'Android.
Comment ça marche
L'outil de wrapping prend un APK ou un IPA, le décompresse, intercepte les appels systèmes sensibles en les redirigeant vers une bibliothèque de gestion, puis resigne le paquet. Les appels concernés sont ceux qui touchent au stockage, au presse-papiers, au réseau, au partage de fichiers et à l'impression. Une variante plus propre, le SDK, demande au développeur d'intégrer la bibliothèque lui-même au moment du build : c'est l'approche qu'a retenue Microsoft avec son Intune App SDK.
Les problèmes se trouvent tous au même endroit. Resigner une application casse sa signature d'origine, ce qui est interdit pour toute application venant de l'App Store ou du Play Store : le wrapping ne s'applique donc qu'à vos propres builds. Chaque mise à jour de l'application exige un nouveau passage de wrapping, donc un délai supplémentaire à chaque livraison. Et une application qui utilise des bibliothèques natives, du code obfusqué, des vérifications d'intégrité ou des notifications push se comporte souvent mal après l'opération, avec des bugs difficiles à diagnostiquer puisque le binaire a été modifié.
Apple et Google ont d'ailleurs rendu la plupart des usages inutiles. Le chiffrement du stockage est natif et systématique, la séparation des données passe par le profil professionnel Android ou par le volume séparé de l'enrôlement utilisateur iOS, et les règles de partage entre applications gérées et non gérées sont exposées directement par le système.
Pourquoi c'est important pour une flotte
Le cas où le wrapping garde du sens est étroit : une application métier ancienne, dont l'éditeur a disparu ou dont le code n'est plus maintenu, qui doit manipuler des données sensibles sur des appareils que vous ne pouvez pas enrôler complètement. Dans cette situation, réencapsuler est parfois la seule option.
Partout ailleurs, le calcul penche de l'autre côté. Si vous contrôlez le code, intégrez un SDK ou utilisez la configuration d'application : vous obtenez les mêmes contrôles sans modifier le binaire après coup. Si vous ne contrôlez pas le code mais que l'appareil est enrôlé, les contrôles natifs du profil professionnel ou du mode géré couvrent les cas réels.
Un point souvent oublié côté juridique : réencapsuler l'application d'un éditeur tiers viole généralement sa licence, et vous prenez la responsabilité d'un binaire modifié qu'il ne supportera pas. Posez la question avant le projet, pas après le premier incident en production.
Comment Appaloosa le gère
Appaloosa s'appuie sur les mécanismes natifs plutôt que sur la réencapsulation : applications gérées installées dans le profil professionnel Android ou en mode géré sur iOS, configuration d'application poussée à l'installation, règles de partage de données entre applications gérées et non gérées, VPN par application, et effacement sélectif qui retire les applications professionnelles et leurs données. Vos APK et IPA internes se distribuent tels que vos développeurs les produisent, sans passe de wrapping intermédiaire. Voir la page gestion des applications mobiles.
Explorer
Découvrez toute la plateforme
Enrôlement, apps, sécurité, support à distance : tout au même endroit.
Explorer Appaloosa →Envie d'essayer Appaloosa ? Démarrer gratuitement