Windows, iPad et Android – Gestion et utilisation de vos ressources Office dans le monde des tablettes (partie 4) – Gestion d'accès basée sur l'appareil

Article original publié le jeudi 20 octobre 2011

Bienvenue dans la quatrième partie de la série de billets sur la gestion de vos ressources Office dans le monde de l'informatique sur tablettes. Dans la première partie , j'ai présenté les principales façons d'utiliser Office avec des clients riches, des clients riches distants, Office pour Mac et Office Web Apps sur un téléphone. Dans la deuxième partie , j'ai parlé de l'usage de la messagerie sur les tablettes à l'aide d'Exchange ActiveSync, comparé les contrôles obtenus avec d'autres plateformes sur les stratégies de groupe et décrit les options de configuration d'Office. Dans la troisième partie , j'ai traité des applications Web Office dans le cadre du service SharePoint 2010 ou Office 365. Cela me conduit au sujet d'aujourd'hui qui est peut-être le plus épineux de cette série de billets de blog : comment différencier l'accès aux ressources en fonction des appareils utilisés.

Confiance basée sur l'appareil et modèles d'accès différencié

En ce qui concerne la sécurisation des données Office, je pense à trois principaux types de contrôles :

1. Sécurisation des informations trouvées localement sur le disque dur de l'appareil
2. Sécurisation des informations auxquelles vous accédez à distance à partir de l'appareil
3. Sécurisation du transfert des données des sources distances aux appareils

La protection du stockage local sur l'appareil tend à reposer sur des méthodes de cryptage et sur la manière de verrouiller quelqu'un hors du stockage local jusqu'à ce qu'il puisse fournir tous les facteurs d'authentification nécessaires pour prouver qu'il est bien qui il prétend.

Chiffrement de lecteur

Windows utilise le chiffrement de lecteur BitLocker™ et il existe des scores des solutions tierces disponibles pour chiffrer les volumes d'un disque dur complet. L'iPad utilise également le chiffrement du disque dur pour protéger les données locales et Android Honeycomb et les systèmes d'exploitation de tablette plus récents prennent aussi en charge le chiffrement du disque dur. Par conception, Biloquer ne stocke pas les données utilisateur dans les partitions non chiffrées du disque dur tandis que les autres conceptions ne sont pas aussi sécurisées et peuvent stocker des données d'authentification sensibles dans des zones accessibles et non chiffrées du disque dur. Les plateformes courantes Android versions 1.6, 2.1 et 2.2 n'incluent pas le chiffrement natif du disque dur et seraient vulnérables si l'appareil tombait en mauvaises mains. Pour être clair, avec Windows, vous devez vous assurer que les utilisateurs utilisent le chiffrement et qu'ils l'appliquent en tant que stratégie informatique. Dans le cas contraire, il existe de nombreuses façons d'accéder aux informations sur les disques durs (en les retirant ou en démarrant dans des environnements d'autres systèmes d'exploitation), de modifier les mots de passe des comptes locaux (en utilisant la réinitialisation du mot de passe d'ERD Commander), etc. Une fois que vous avez requis et appliqué le chiffrement de lecteur, il est extrêmement difficile d'accéder aux informations stockées localement en ne disposant pas des facteurs d'authentification spécifiques à l'ordinateur (module de plateforme sécurisée, code PIN, carte à puce, dongle USB ou mot de passe).

Protection réseau

Si vous décidez d'autoriser des appareils non gérés à se connecter à l'intérieur de votre pare-feu, vous disposez de quelques options outre les paramètres de certificat et de proxy habituels. Certaines organisations, pour des raisons de sécurité, bâtissent une infrastructure réseau parallèle spécifiquement pour l'accès des appareils non gérés et limitent l'accès des informations aux ressources contrôlables via Exchange ActiveSync et l'infrastructure associée. Cela a pu être une option acceptable pour de nombreux environnements, mais les informaticiens sont souvent sous une pression accrue qui les pousse à autoriser ces appareils à se connecter à l'intérieur des pare-feu de l'entreprise. Si vous êtes confronté à ce problème, il y a plusieurs choses que vous pouvez faire pour favoriser la différenciation de l'accès en fonction de l'appareil ou du navigateur qui se connecte à vos données SharePoint.

Il existe déjà des méthodes courantes pour déterminer l'intégrité d'un objet ordinateur entrant en contact avec des ressources réseau. Nous connaissons le réseau privé virtuel de mise en quarantaine et la protection d'accès réseau (NAP) depuis plusieurs années déjà. Dans la solution NAP, un appareil est en fait interrogé lorsqu'il essaie d'accéder à un réseau et s'il ne répond pas aux exigences (état du correctif, antivirus à jour, etc.), des droits d'accès au réseau réduits à zéro lui sont accordés. Vous trouverez des descriptions du fonctionnement de la protection NAP avec IPsec, VPN, 802.11x et DHCP dans TechNet , et l'illustration ci-dessous représente le flux de processus mis en œuvre pour détecter et mettre à jour un appareil non conforme avec IPsec.

Le problème concernant la protection NAP est qu'elle requiert un ordinateur prenant en charge NAP, tel que Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows Vista ou Windows XP avec SP3. Par conséquent, pour imposer l'intégrité à l'aide de la protection NAP, il convient de déployer des appareils dotés d'un système d'exploitation Windows.

Supposons qu'il est impossible d'utiliser la protection NAP parce que l'appareil qui se connecte est un périphérique Mac, iPad ou Android. Que faire dans ce cas ? Certaines options existent, qui utilisent Microsoft Forefront Unified Access Gateway (UAG) pour faire appliquer les normes sur des appareils non-Windows (Mac et Linux), par exemple en exigeant la présence d'un antivirus sur ces appareils. L'image ci-dessous montre l'éditeur de stratégie dans Forefront UAG et les plateformes non-Windows qu'il prend en charge.

Le texte ci-dessus est affiché aux utilisateurs lorsqu'un appareil ne répond pas aux spécifications d’intégrité définies par UAG. Des informations sur les exigences du client UAG sont disponibles dans TechNet. Il est important pour ce blog que Forefront UAG SP1 Update 1 intègre additionnellement la prise en charge des navigateurs sur les plateformes iOS 4 et Android 2.3 et 3.0.

Une autre manière d'aider à prévenir le téléchargement de fichiers vers des appareils consiste à utiliser les Services Internet (IIS) pour interroger les appareils qui se connectent avec des informations transmises à un serveur IIS et, en fonction de ces informations, autoriser ou interdire le téléchargement des fichiers. Grâce à IIS, il est possible de définir des règles qui redirigeront les appareils qui essaient de télécharger des fichiers. Dans ce cas, il est possible d'inspecter le journal IIS et de déterminer les identifiants de ces appareils.

Dans le journal ci-dessus, vous pouvez voir le type d'appareil « iPad » et le navigateur qui se connecte au document. Vous pouvez alors configurer dans IIS une règle pour rediriger les appels provenant des périphériques dotés de ces attributs vers une page qui leur indiquera qu'ils sont en train de faire quelque chose d'interdit par l'administrateur réseau.

Comme vous pouvez le voir ci-dessus, j'ai créé dans le Gestionnaire des services Internet une règle qui s'applique à tous les fichiers d'extension DOCX. Lorsqu'un appareil correspond au modèle et possède un descripteur contenant iPad, son utilisateur est redirigé vers le site Intranet download%20denied.aspx. Il n'est pas nécessaire de procéder ainsi pour tous les fichiers individuels et il est possible de définir une règle unique qui couvre tous les fichiers dotés de l'extension DOCX (ou d'autres extensions). L'intérêt de cette approche est d'autoriser l'appareil à afficher le document à l'aide d'Office Web Apps, auquel cas le document est rendu sur le serveur SharePoint et seul un fichier PNG est renvoyé à l'appareil.

Lorsque l'utilisateur tente de télécharger une copie vers un appareil que nous ne gérons pas, l'utilisateur voit s'afficher l'écran suivant :

Cela peut fondamentalement aider à prévenir le téléchargement du fichier sur le disque dur local des utilisateurs, ainsi que l'utilisation d'un autre service pour le télécharger ou l'envoyer par messagerie vers un emplacement non souhaité. Dans le cas d'un disque dur non chiffré ou d'un appareil doté d'un dispositif de stockage amovible, cela aiderait à prévenir le stockage du fichier dans un système de fichiers non protégé, sur une carte SD, etc. Bien que cette solution ne soit pas idéale, elle peut aider à réduire les activités illicites des utilisateurs tout en autorisant l'affichage à l'aide d'Office Web Apps.

Transmission sécurisée des données

La transmission des données est un autre élément que j'avais répertorié au tout début de ce blog, mais les piles de mise en réseau des appareils iOS et Android les plus récents prennent en charge les standards WEP (Wired Equivalent Privacy) et WPA (Wi-Fi Protected Access) les plus courants pour favoriser le maintien de la sécurité des transmissions en direction et en provenance des appareils. La clé ici est d'utiliser ces méthodes par opposition aux réseaux non sécurisés.

Conclusions de cette quatrième partie

Les appareils mobiles ont fait beaucoup de chemin et continuent à s'améliorer ; néanmoins, ils ne sont pas aussi maniables que les plateformes plus mûres, équipées pour une défense en profondeur des données sur l'appareil et de la connexion aux données distantes. Il est compréhensible, toutefois, en raison du climat actuel, que certaines concessions soient faites pour accorder l'accès à des appareils qui ne répondraient pas par ailleurs aux critères de sécurité. Certaines des méthodes que j'ai décrites dans ce blog, je l'espère, vous aideront à déterminer des façons d'accorder un accès limité, mais suffisant, aux appareils non gérés pour vous permettre d'avoir l'esprit tranquille tout en satisfaisant vos utilisateurs. Bien entendu, il existe d'autres mécanismes, tels que la Gestion des droits relatifs à l’information (IRM), qui permettent de fournir à des appareils Windows non gérés l'accès à des fichiers sensibles via la prise en charge d'Exchange ActiveSync dans Windows Phone 7.5 et Windows Mobile, et via Outlook Web Access. Toutefois, ils ne sont pas d'une grande aide en ce qui concerne iPad et Android et n'apportent pas une base de comparaison, par exemple de la protection NAP par rapport aux stratégies IIS et UAG. C'est la raison pour laquelle je n'ai pas abordé ici les détails concernant IRM.

Je voulais lancer un débat sur la mise en place d'un accès à distance à l'aide de Citrix XenApp et des services Bureau à distance dans Windows Server, sur la manière de personnaliser l'interface utilisateur d'Office et le shell Windows pour un accès à partir d'un appareil iPad ou Android, mais je réserve cela pour mon prochain et probablement dernier billet de blog de cette série.

Merci d’avoir lu ce billet.

Jeremy Chapman

Chef de projet senior

Équipe Office IT Pro

Ce billet de blog a été traduit de l’anglais. Vous pouvez consulter la version originale de cet article Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 4) – Device-based Access Management