Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Android 6.0 : les améliorations pour conquérir l'entreprise

Marshmallow de Troie
Mobilité 6 min
Android 6.0 : les améliorations pour conquérir l'entreprise
Crédits : MartenBG/iStock

Si les nouveautés d'Android 6.0 sont nombreuses pour le grand public, celles dédiées à la sécurité et au monde professionnel ont de quoi conquérir le cœur des entreprises. Du chiffrement intégral aux multiples améliorations de la gestion de flotte, tour d'horizon des ajouts cachés de Marshmallow.

En dehors des nouveautés visibles par le grand public, Android 6.0 apporte tout un lot d'améliorations pour la sécurité et les professionnels. Si certaines d'entre elles ont été largement mises en avant par Google, comme la lecture d'empreintes digitales sur les derniers Nexus, d'autres moins connues méritent que nous nous y penchions.

Parmi elles figurent de nombreuses améliorations pour la gestion des smartphones et tablettes en entreprise, comme un meilleur contrôle des applications et des simplifications pour les utilisateurs. Nous avons décidé de leur consacrer la dernière partie de notre dossier sur Android 6.0. Vous retrouverez les autres  parties de ce dossier par ici : 

Le chiffrement intégral par défaut sur les nouveaux appareils, s’ils sont assez rapides

Il s’agit d’un changement qui devait initialement faire partie des nouveautés d’Android 5.0. Google était finalement revenu sur sa décision à cause de problèmes de performances : l’activation du chiffrement intégral des données réclamait trop de puissance au processeur, et de nombreux terminaux affichaient une nette chute de réactivité.

Dans le document adressé aux constructeurs (PDF), Google indique désormais que ce chiffrement intégral est bien actif par défaut avec Android 6.0 dès que le nouveau terminal, qu’il s’agisse d’un smartphone ou d’une tablette, permet un chiffrement AES d’au moins 128 bits sur un flot de données au rythme minimal de 50 Mio/s (mébioctets par seconde). Il s’agit clairement d’une obligation pour le constructeur, et non d’un conseil.

Ce chiffrement concerne les dossiers /data et /sdcard et permet donc de couvrir toutes les données personnelles de l’utilisateur, même quand elles se trouvent sur une carte mémoire. Rien n’empêche cependant les possesseurs de smartphones actuels d’activer ce chiffrement, comme cela était déjà le cas depuis avec Android 5.0. Attention cependant aux éventuelles chutes de performances, même si la fonctionnalité peut être stoppée. Notez par ailleurs qu’en cas d’activation, il sera impossible de récupérer les données sur le terminal si la séquence de déverrouillage est perdue.

Les empreintes digitales gérées de manière centralisée

La reconnaissance digitale n’est pas une nouveauté en soi. Plusieurs constructeurs, notamment Samsung, la proposant depuis quelques années. Mais chacun y est allé de sa propre technologie, interfacée avec d’autres services maison, en particulier ceux liés au paiement.

Android 6.0 apporte une gestion centralisée des empreintes. Comme on peut s’y attendre, et comme c’est le cas d’ailleurs sur d’autres plateformes comme iOS avec TouchID, elle est directement reliée à la solution de paiement Android Pay. Pour l’utilisateur, cela ne changera pas forcément grand-chose dans la pratique, il s’agira simplement d’une autre manière de faire.

Évidemment, pour ceux qui utiliseront Android Pay, la situation sera différente. Ce système de paiement ne sera cependant disponible qu’aux États-Unis dans un premier temps, où il a été lancé il y a quelques semaines seulement. Sachez dans tous les cas qu’une fois cette solution en place un peu partout, les possesseurs de smartphones « rootés » ne pourront pas l’utiliser. L’infrastructure ne fonctionne que sur des droits limités pour des questions évidentes de sécurité, et Google ne souhaite pas créer un contexte propice au piratage, surtout pour une infrastructure impliquant des banques.

BoringSSL remplace officiellement OpenSSL

OpenSSL est l’implémentation libre des protocoles SSL et TLS que l’on trouvait pratiquement partout jusqu’à récemment. La faille HeartBleed a cependant créé une onde de choc et des « forks » sont apparus. BoringSSL est l’un d’eux et correspond aux efforts de Google pour proposer une alternative viable et surtout plus sécurisée. Le groupe de Mountain View a donc décidé de remplacer OpenSSL par sa solution dans Android 6.0.

Heartbleed OpenSSL

Simplifier la vie des administrateurs dans les entreprises

Le modèle BYOD (Bring Your Own Device, « Apportez votre propre appareil ») est devenu courant en entreprise, mais certaines préfèrent toujours passer par une gestion centralisée des appareils. Dans les structures qui adoptent cette solution, certains outils manquent toujours à l’appel, et Google était conscient que les administrateurs avaient besoin de certaines fonctionnalités supplémentaires pour gérer un parc mobile plus efficacement. L’éditeur a donc renforcé certaines API, en a apporté de nouvelles et a enrichi son offre Android for Work, lancée en février.

Plusieurs nouvelles capacités ont donc été ajoutées pour les appareils ayant un profil spécifique pour le travail (Work Profile). Via une API dédiée, les administrateurs vont pouvoir par exemple surveiller de près la quantité de données consommée par tout ou partie des applications professionnelles. Il y a une séparation nette de ces dernières avec les applications classiques, considérées comme personnelles donc, que l’utilisateur installe depuis la boutique Google Play.

Cet ajout peut avoir de multiples intérêts. Il peut bien entendu aider à observer les surconsommations de données dans le cadre d’une optimisation éventuelle. Mais pour les employés en déplacement, la consommation des données peut entrainer une facturation spécifique sur son forfait. L’entreprise peut alors vérifier précisément la part qu’elle représente et rembourser l’utilisateur sur cette base. 

Automatiser des tâches potentiellement rébarbatives

L’API DevicePolicyManager évolue de son côté pour prendre en charge une éventuelle application tierce ou interne dont la mission sera de configurer un accès VPN ou de simplifier l’installation des certificats de sécurité. Un ajout réclamé par les entreprises qui souhaitaient y consacrer moins de temps. L’idée est de pouvoir envoyer directement sur les terminaux des profils de configuration ou des certificats, supprimant l’étape de paramétrage par l’utilisateur ou le service informatique et les avertissements parfois « anxiogènes ».

Dans un autre domaine, Android 6.0 permet aux entreprises tout un ensemble de règles qui devraient nettement faciliter la vie de tout le monde. Par exemple, un administrateur peut définir sur un appareil une certaine configuration Wi-Fi que l’utilisateur ne pourra pas supprimer par erreur (ou volontairement d’ailleurs). Même chose pour une réinitialisation de l’appareil, qui peut être bloquée (Factory Reset Protection). Quant aux applications maison, elles peuvent recevoir automatiquement les mises à jour sans que l’utilisateur n’ait à vérifier quoi que ce soit. Notez d’ailleurs que les applications « pro » seront désormais signalées par une icône de petite valise dans la barre de statut.

Des appareils « kiosques » beaucoup plus figés

Android 6.0 ajoute également de nouvelles capacités à des appareils dont la configuration est particulière et qu’on surnomme souvent les « kiosques ». Google appelle ces appareils « COSU » de son côté, pour « corporate-owned, single-use », autrement dit des appareils appartenant à l’entreprise et dédiés à une utilisation unique. Il s’agit tout simplement de terminaux « figés » et qui ne servent la plupart du temps qu’un seul objectif : lancer une application ou un service unique, par exemple pour la gestion des stocks ou une démonstration quelconque.

Dans la pratique, les configurations n’étaient pas aussi figées qu’elles auraient dû l’être, et les utilisateurs avaient encore la capacité de « dérégler » (par accident ou non) les paramètres mis en place. Désormais, Android 6.0 permet de bloquer de nombreux éléments, dont le clavier virtuel et la barre de statut. Le safe boot peut lui aussi être activé ou non, au choix de l’entreprise.

7 commentaires
Avatar de Lyaume Abonné
Avatar de LyaumeLyaume- 04/11/15 à 09:44:46

OpenSSL n'a-t-il pas été revu et corrigé suite à la découverte de la faille?
Du coup, pourquoi Google propose son BoringSSL? Est-il aussi libre de sorte à ce qu'on puisse voir ce qu'il s'y passe?

Parce qu'il me semble qu'OpenSSL est toujours viable alors je me demande l'intérêt pour Google de développer et d'utiliser encore un autre fork... Si quelqu'un à la réponse, je le remercie d'avance.

Avatar de WereWindle INpactien
Avatar de WereWindleWereWindle- 04/11/15 à 09:52:12

Parce que leur propre implémentation était déjà largement forkée et que gérer le delta entre la version "officielle" d'OpenSSL et leurs besoins devenait lourdingue

Avatar de Valeryan_24 Abonné
Avatar de Valeryan_24Valeryan_24- 04/11/15 à 09:52:39

L'explication du fork BoringSSL par Google est la suivante :

http://www.developpez.com/actu/73591/Chrome-Google-remplace-OpenSSL-par-BoringSS...
"BoringSSL est donc un fork d’OpenSSL, qui n’a cependant pas pour ambition de remplacer OpenSSL. La vision des développeurs de Google est de disposer d’un socle sur lequel ils importeront les modifications qui ont été apportées à OpenSSL, plutôt que d’appliquer leurs changements au-dessus de l’outil. Il faut noter que Google dispose actuellement de plus de 70 correctifs développés en interne pour OpenSSL. Les maintenir pour l’ensemble de ses produits utilisant la solution (Android, Chrome, etc.), demande beaucoup trop d’efforts. De plus, avec BoringSSL, Google pourra également profiter des évolutions de LibreSSL, le fork d’OpenSSL maintenu par la fondation OpenBSD."

http://www.zdnet.fr/actualites/google-forke-openssl-au-sein-du-projet-boringssl-...
"Nous avons appliqué un certain nombre de patchs à OpenSSL au fil des années. Certains ont été accepté dans le dépôt principal d'OpenSSL, mais beaucoup ne cadrent pas avec la garantie de stabilité de l'API et de l'ABI d'OpenSSL, et beaucoup sont un peu trop expérimentaux, explique Adam Langley, ingénieur chez Google."

Personnellement, vu que sur mon Z1c, aussi bien la version Sony (Android 5.0) que la dernière Cyanogenmod (5.1), on est toujours sur OpenSSL (respectivement 1.0.1h et 1.0.1j) vulnérable entre autres à la faille Freak (c'est le cas aussi de nombreuses applications bancaires, ou VPN...), ce changement me réjouit.

Édité par Valeryan_24 le 04/11/2015 à 09:53
Avatar de Valeryan_24 Abonné
Avatar de Valeryan_24Valeryan_24- 04/11/15 à 11:56:59

Pour compléter, oui BoringSSL est également open-source, même si Google ne recommande pas un usage externe : il est tellement lié à leurs produits qu'ils ne garantissent pas la compatibilité de l'API.

Par contre, tout comme LibreSSL, ils permettent aussi de remonter des bugs et apporter des corrections à OpenSSL (ou inversement).

En espérant, avec l'amélioration du code de ce dernier également et la participation financière de compagnies l'utilisant, que cela permettra une meilleure sécurité globale :auto:

Avatar de Crazy Diver Abonné
Avatar de Crazy DiverCrazy Diver- 04/11/15 à 12:28:42

Logique OpenSSL y'a des bug alors on fait 3 fork pour optimiser la puissance de développement ... et après on passe sont temps à porté les correctifs ...

Avatar de Valeryan_24 Abonné
Avatar de Valeryan_24Valeryan_24- 04/11/15 à 13:02:06

Il faut voir les raisons aussi : la qualité du code d'OpenSSL a été fortement critiquée, l'équipe d'OpenBSD qui a forké LibreSSL a voulu radicalement le simplifier et supprimer une grande partie de rétro-compatibilité.

L'avantage c'est qu'il y a ainsi plusieurs équipes dédiées qui développent, et donc auditent régulièrement le code, cela a déjà permis de trouver et combler de nombreuses failles récemment.

Après le problème est aussi (de la même manière que la fragmentation Android) le manque global de coordination, homogénéisation des mises à jours de tous les composants utilisant les librairies sensibles d'OpenSSL (OS serveurs, mobiles, matériels, applications...) !

Avatar de Lyaume Abonné
Avatar de LyaumeLyaume- 04/11/15 à 16:09:16

WereWindle a écrit :

Valeryan_24 a écrit :

Ok, je comprend mieux pourquoi Google fait sa petite popote dans son coin. Je croyais que c'était encore pour faire une de leur entourloupe, mais finalement, ça à l'air de se tenir.

Merci bien. :yes:

Il n'est plus possible de commenter cette actualité.