Trois étapes pour mieux protéger les données en mobilité

Tout part du système d’exploitation mobile

La plupart des postes de travail fonctionnent sous Windows, voire sous OS X. Ce qui donne aux DSI un environnement à gérer relativement cohérent et maîtrisé. Mais les terminaux mobiles exécutent des systèmes d’exploitation plus variés, qui évoluent plus rapidement, avec des versions susceptibles de changer d’un constructeur à l’autre, si ce n'est d’un modèle à l’autre.

Lorsque les utilisateurs amènent leurs propres appareils et leurs propres applications mobiles, ils accroissent encore la diversité de l’environnement. Dès lors, la DSI ne peut pas compter sur la standardisation et le verrouillage des appareils pour sécuriser les données.

Cette tâche nécessite de comprendre ce que chaque OS mobile peut - ou ne peut pas faire. C'est à ce prix que les administrateurs peuvent pleinement tirer parti des technologies, des applications et des réglages. Par exemple, la plupart des systèmes d’exploitation mobiles supportent l’isolation des applications – ou sandboxing –ennatif, et intègrent des capacités avancées de sécurisation du noyau.

En revanche, le support du chiffrement à l’échelle du terminal et de l’effacement à distance varie. Pour cela, il est fréquent que les DSI choisissent une approche de sécurisation en deux temps : elles commencent par établir et faire respecter des critères d’acceptation minimum, puis comblent les limitations des plateformes avec des outils tiers.

Déterminer quels terminaux accepter 

Pour établir les critères d’acceptation des terminaux, il convient d’examiner l’architecture de sécurité de chaque plateforme et voir à quel point les applications de l'utilisateur, de l'opérateur et du constructeur sont isolées les unes des autres, et isolées du noyau de l'OS. 

Il convient également de savoir si les applications peuvent lire ou modifier les données en dehors du bac à sable – des fichiers partagés ou des messages, par exemple. L’examen doit également couvrir les permissions qui sont accordées – par défaut ou explicitement – aux applications, ainsi que le degré de contrôle que la DSI peut exercer pour détecter et bloquer celles potentiellement dangereuses.

Comme leurs homologues pour le poste de travail, les systèmes d’exploitation mobiles souffrent de vulnérabilités susceptibles de mettre en danger les données. La question des mises à jour - des apps et de l'OS - et de leurs délais de mise à disposition s’avère particulièrement problématique dans un écosystème fragmenté.

La même considération s’applique à la provenance des applications mobiles. Le contrôle exercé par Apple s’avère efficace pour limiter la diffusion de logiciels malveillants pour iOS – sans toutefois l’empêcher complètement. C’est un facteur à prendre en compte dans l’établissement des critères d’acceptabilité. Par exemple, certaines entreprises interdisent les terminaux Android, ou n’en autorisent que certaines versions.

Pour beaucoup, les critères non négociables touchent à une version d’OS mobile minimum, ausupport matériel du chiffrement complet du terminal, à des interfaces d’administration OTA, à la possibilité d’imposer l’utilisation d’un mot de passe robuste, à celle d’effacer le terminal à distance, d’enregistrer les activités, de détecter les opérations de jailbreak ou de rootage, voire de gérer les installations d'applications.

Les terminaux qui ne répondent pas à ces critères de base sont susceptibles d’être interdits d’accès aux réseaux et aux services de l’entreprise, ou bien autorisés d'une manière limitée qui ne mette pas en danger les données.

Protection native des données : une base

Les smartphones et les tablettes se perdent. Avec les données métiers qu’ils transportent.

Le chiffrement complet du terminal peut souvent empêcher une telle perte d’être à l’origine d’une fuite de données.

Mais un tel chiffrement peut s’avérer d’une portée limitée sur certaines plateformes. Par exemple, l’efficacité de l'effacement à distance varie. Sur les appareils Apple et BlackBerry, les clés de chiffrement sont supprimées, ce qui rend les données chiffrées irrécupérables. Sur les anciens appareils Android - sans chiffrement matériel - l’effacement n’est qu’une réinitialisation en conditions de sortie d’usine. Ce qui est susceptible de laisser les données exposées en cas de perte, de vol ou de revente du terminal.

De la même manière, un système de fichiers chiffré ne peut pas pleinement sécuriser les données sur un terminal compromis. Il ne peut pas non plus empêcher les utilisateurs de déplacer des données vers d'autres emplacements non chiffrés.

Lorsque des applications professionnelles et personnelles coexistent sur un même appareil, il y a plus de chances pour qu’une application malicieuse - ou trop curieuse - compromette des données présente sur le même système de fichiers. A moins que la DSI ne prenne des mesures préventives, un employé qui a acces à un terminal chiffré peut aisément laisser fuiter des données par e-mail ou les transférer vers un service de stockage Cloud.

La protection native des données en mobilité apparaît en fait comme un point de départ essentiel. Mais pas suffisant. Pour profiter pleinement de ce que peuvent offrir les OS mobiles modernes, il faut utiliser un EMM pour enrôler les appareils et provisionner leurs réglages, en commençant par des points tels que la robustesse du mot de passe, le recours au lecteur d’empreintes digitales, ou encore le nombre de tentatives autorisées.

Une authentification robuste est critique du fait que des codes PIN, faciles à deviner, peuvent neutraliser un chiffrement fort. Il convient aussi d’activer l’effacement à distance et de recueillir le consentement explicite de l’utilisateur - durant l’enrôlement - pour que la DSI puisse utiliser cette fonctionnalité en dernier recours, et dans des conditions très précises, sur son appareil.

Adapté de l'anglais