Par défaut sous-estimées par les équipes techniques internes et de défense, souvent sur-privilégiées, les App registrations peuvent permettre des pivots puissants suite à la compromission de l’environnement cloud.

Parmi les services les plus exposés, Microsoft SharePoint se distingue. Présent sur la majorité des tenants M365, souvent configuré de manière permissive, il offre un accès aux fichiers de l’entreprise via SharePoint et des collaborateurs au travers de OneDrive.

Cet article revient sur plusieurs constats observés en opération Red Team : comment une simple App Registration, liée de près ou de loin à SharePoint, peut offrir un accès élargi à votre SI on-premise, et comment l’exploitation de ce maillon faible permet parfois de faire de votre segmentation en Tiers une simple formalité pour l’attaquant.

Introduction aux App Registrations

Dans Microsoft Azure, l’enregistrement d’une application (App Registration) dans Entra ID permet de créer une identité pour cette application, ainsi qu’une Enterprise Application associée. L’App Registration définit l’application (identifiants, clés, permissions), tandis que l’Enterprise Application représente son instance dans le tenant, sur laquelle sont appliquées les politiques d’accès (comme l’authentification conditionnelle portée par les politiques d’accès conditionnels ou les rôles attribués).

Une App Registration contient les informations requises pour s’authentifier auprès d’Entra ID et obtenir des jetons d’accès pour interagir avec des services Microsoft 365 via des API comme Microsoft Graph. Selon les permissions qui lui sont accordées (déléguées (scopes) ou applicatives (rôles)) elle peut lire ou modifier des ressources telles que des mails, des fichiers, des utilisateurs ou des groupes tant que l’Enterprise Application est instanciée dans le tenant.

Généralement utilisées pour enregistrer une application visant à automatiser des processus métiers (gestion des utilisateurs, nettoyage de fichiers SharePoint, supervision de l’activité O365…), elles constituent une surface peu surveillée, mais à fort impact.

En effet, les secrets des App Registrations (certificats, client secrets) sont souvent stockés de manière non sécurisée (dans des dépôts de code, postes de travails, serveurs). Ces secrets permettent de personnifier une application avec des privilèges potentiellement élevés (listés dans l’App Registration) entraînant une persistance discrète sur les ressources de l’entreprise.

Pour un attaquant, compromettre une App Registration revient à s’approprier une identité applicative EntraID disposant d’un accès direct à certaines données de l’entreprise, sans nécessiter de rebond par des comptes utilisateurs interactifs ni MFA. Alors que les sécurités se multiplient autour des comptes utilisateurs (MFA obligatoire, accès conditionnel imposant une adresse IP ou un appareil de confiance), il est souvent constaté que celles-ci ne sont pas encore appliquées aux applications.

Se connecter en tant qu’une App Registration

Les applications Azure peuvent s’authentifier auprès d’Entra ID à l’aide de secrets d’application générés dans l’App registration associée :

• AppId + App Secret: Ce moyen d’authentification, équivalent à l’usage d’un nom d’utilisateur et d’un mot de passe est soumis aux mêmes limitations : il est compliqué d’assurer leur protection car ils peuvent facilement se retrouver stockés de manière non sécurisée, exposés dans les historiques de commandes, etc…

• AppId + Certificat: Cette méthode de connexion est davantage sécurisée, puisque les solutions de sécurité installées sur les machines protègent de manière efficace les certificats installés. Néanmoins, celle-ci est généralement moins utilisée en raison des contraintes d’utilisation qu’elle implique, telle que l’installation du certificat sur chaque machine nécessitant l’utilisation du compte.

Les identifiants et secrets d’une application lui permettent de récupérer un jeton d’accès OAuth2, afin de s’authentifier et d’appeler des API Microsoft (Graph, SharePoint, Exchange, etc.) qu’elle est autorisée à contacter. Ce mode de connexion est généralement difficile à détecter si les journaux d’accès ne sont pas activés ni supervisés.

Les droits d’une App Registration

Chaque App Registration définit les permissions API associées à l’application enregistrée. Elles sont décrites sous forme de rôles ou de scopes, sur différents services Microsoft. A titre d’exemples, ces autorisations d’application peuvent permettre de :

• Lire ou modifier des profils utilisateurs (User.ReadWrite.All) ;
• Gérer des objets dans l’annuaire Entra ID (Directory.ReadWrite.All) ;
• Lire, écrire ou supprimer des fichiers SharePoint ou OneDrive (Files.ReadWrite.All) ;
• Lire ou écrire des mails dans toutes les boîtes mails (Mail.ReadWrite) ;
• Etc.

Lors des audits, il est constaté que ces droits sont souvent surdimensionnés par rapport aux besoins réels des applications. Ils peuvent ainsi offrir à un attaquant un levier d’élévation de privilèges majeur s’ils sont récupérés.

D’autre part, un attaquant peut identifier les droits d’une application au travers de l’App Registration associée et compromise en s’authentifiant via l’URL https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token :

Le jeton d’accès obtenu est au format base64, et les droits définis par l’App Registration y sont présents :

Compromission d’App Registrations en opération Red Team

Dans le cadre d’une attaque, il est très fréquent que la compromission s’opère de manière progressive.

Généralement, un premier serveur est compromis, puis un second, etc. jusqu’à atteindre des composants plus critiques de l’infrastructure ou des utilisateurs davantage privilégiés : accès initial, élévation de privilèges, latéralisation, et ainsi de suite.

Ces dernières années, l’implémentation du modèle en Tiers (Tier-0, Tier-1 et Tier-2) au sein des infrastructures Active Directory s’est généralisée, avec par la même occasion une augmentation du niveau de sécurité des SI on-premise. Un nouveau facteur s’est également ajouté avec le développement des agents EDR : la détection !

Dorénavant au sein d’environnements matures, il est plus difficile de compromettre le Tier-0 (contrôleur de domaine, PKI, etc.) par la simple compromission d’un serveur Tier-1, le tout sans se faire détecter par la Blue Team, l’équipe de défense.

Toutefois, au cours de plusieurs opérations au sein d’environnement très variés, SharePoint s’est présenté comme un vecteur d’élévation de privilèges redoutable, et où aucune détection n’a été remontée côté Blue Team.

Plusieurs retours d’expériences d’opérations Red Team illustrant ce propos sont partagés ci-dessous.

Cas n°1 : Administrateur Tier-2 d’un sous-domaine vers la compromission de la forêt Active Directory

Ce cas illustre une opération pour un client international dont le SI se compose de plusieurs milliers de serveurs, qu’il s’agisse de serveurs applicatifs et métiers, industriels, d’infrastructure, etc. La compromission d’un premier serveur a engendré la compromission de comptes administrateurs Tier-1 puis Tier-2.

Dès l’obtention de privilèges d’administration acquis sur des postes de travail (Tier-2), une phase de collecte ciblée s’est amorcée dans le but d’identifier des secrets applicatifs.

Sur plusieurs postes d’utilisateurs à profil technique (équipes DevOps, Cloud, etc.), des scripts PowerShell sont découverts. Certains contiennent des identifiants liés à des App Registrations, avec un AppId, un AppSecret, ainsi que l’identifiant du tenant Azure auquel ils sont associés :

L’exploitation de ces secrets permet à l’attaquant de se connecter directement à la Microsoft Graph API, avec les autorisations déjà consenties définies dans l’App Registration compromise.

L’App Registration identifiée dans ce contexte contient des droits d’application étendus sur O365, notamment :

• User.ReadWrite.All: Lire et modifier tous les profils utilisateurs.
• Directory.Read.All: Lire les données du répertoire.
• Directory.ReadWrite.All: Lire et écrire les données du répertoire.
• Group.ReadWrite.All: Lire et écrire toutes les informations des groupes.
• Files.ReadWrite.All: Lire et écrire tous les fichiers.
• Mail.ReadWrite: Lire, créer, supprimer des mails en toutes les boîtes mails.
• Calendars.ReadWrite: Lire et écrire tous les calendriers.
• Contacts.ReadWrite: Lire et écrire tous les contacts.
• Tasks.ReadWrite: Lire et écrire toutes les tâches.

Parmi cet ensemble de permissions d’application, le droit Files.ReadWrite.All s’avère particulièrement critique et intéressant pour un attaquant, autorisant un accès complet à tous les fichiers stockés sur SharePoint et OneDrive.

Note : Ces permissions peuvent être « déléguées » et dans ce cas ne s’appliquent que dans le contexte de ce que peut faire l’utilisateur.

Un script PowerShell a été développé par l’équipe Red Team Wavestone (SharePwned) afin d’effectuer des recherches sur SharePoint et OneDrive basées sur des mots-clefs, et télécharger les fichiers souhaités.

Par le biais de ce script et via une recherche sur le nom de domaine de la forêt d’administration Active Directory (admin.xx.xxxx.net), plusieurs fichiers ont été identifiés au sein d’espaces OneDrive d’utilisateurs, puis téléchargés :

Ces fichiers, stockés sur l’espace OneDrive d’utilisateurs à privilèges, permettent d’identifier les serveurs de rebond utilisés pour accéder à la forêt Active Directory d’administration du SI.

Le stockage non sécurisé des secrets sur les postes de travail et espaces Cloud représente une faille de sécurité majeure. Pour autant, l’absence de sécurité et de supervision autour de cette App Registration liée à d’importants privilèges représente une vulnérabilité critique dès lors qu’une Enterprise Application associée est instanciée dans le tenant.

Dans le cas présent, la compromission du Tier-2, puis l’accès en lecture aux fichiers stockés sur les espaces OneDrive des collaborateurs a permis d’identifier rapidement les secrets et rebonds réseaux nécessaires à la compromission du Tier-0 de l’entreprise.

Cas n°2 : Accès distant au réseau d’entreprise du Groupe à partir de la compromission d’une filiale

Ce second cas présente une opération Red Team ciblant une entreprise disposant de nombreuses filiales et dont les réseaux ne communiquent pas entre eux.

Tout d’abord, le SI d’une première filiale a été compromis, ainsi que son tenant Azure.

A des fins de persistances et de recherches, une App Registration a alors été créée par la Red Team, tout en ajoutant l’autorisation d’application Files.Read.All.

En téléchargeant les secrets de l’application lors de sa création, il est une nouvelle fois possible d’utiliser l’outil développé par la RT Wavestone pour effectuer des recherches SharePoint et OneDrive :

En effectuant des recherches de mots de passe, des comptes associés à des solutions d’accès distants à l’entreprise cible du Red Team sont identifiés. En effet, certains membres des équipes Finance de la filiale compromise disposent d’accès à la solution de bureau distant du groupe, et stockent leur mot de passe en clair sur leur espace OneDrive.

Bien qu’un MFA soit configuré pour l’ensemble des utilisateurs de cette solution, seule une approbation de la notification est requise, et aucun code n’est demandé. En noyant les utilisateurs de notifications MFA, l’un d’eux a finalement validé l’authentification, permettant aux opérateurs Red Team d’accéder temporairement à la solution de bureau distant.

Finalement, en accédant à l’application de Finance hébergée sur une machine virtuelle Windows, un accès au réseau interne du groupe est récupéré.

Ainsi, à partir d’une compromission de filiale sans interconnexion directe avec le réseau groupe, l’usage d’App Registrations a permis une fois encore de découvrir des secrets et rebondir sur le SI groupe.

Cas n°3 : Compromission de l’EDR déployé sur les contrôleurs de domaine à partir de la chaîne CICD

La compromission de l’environnement CICD du client (hébergé sur AWS) a mené à la compromission de son serveur GitLab. Avec les droits root sur le serveur GitLab, il est possible d’accéder à sa base de données, et aux secrets qui y sont stockés. Bien que ceux-ci soient chiffrés, il est possible de les déchiffrer via la console GitLab Rails.

Parmi ces secrets, des clientID et clientSecrets Azure d’une App Registration sont récupérés. Ces identifiants d’accès permettent de se connecter à Azure sous l’identité de l’application associée, dans le cas présent sous l’identité de l’application GitLab.

Sur le tenant client, l’application GitLab dispose d’un rôle de contributeur sur les ressources d’une souscription Azure. Cela signifie qu’elle peut gérer les accès aux ressources, et en lire le contenu.

Parmi les ressources accessibles, des secrets sont stockés (et accessibles en lecture) dans un coffre-fort Azure Vault. En particulier, des clientId et clientSecret y sont présents :

Une nouvelle application Azure, nommée xxxxx-NettoyageSharePoint, est ainsi obtenue. Celle-ci possède les permissions nécessaires pour lire l’intégralité de SharePoint et OneDrive.

En utilisant une première version de l’outil SharePwned, une recherche de secrets est effectuée au sein des espaces OneDrive des collaborateurs. Des secrets stockés de manière non sécurisée sont découverts dans des fichiers de configuration d’outils d’administration, tels que mRemoteNg. Ces fichiers de configuration contiennent généralement des mots de passe chiffrés avec une clé publique connue. Ainsi, il est possible de les déchiffrer et obtenir les mots de passe en clair des utilisateurs :

Le compte récupéré ici dispose de privilèges d’administration sur l’application IAM de l’entreprise.

Après de multiples recherches de documentations sur SharePoint, toujours en utilisant l’outil SharePwned afin de cibler les recherches, l’équipe Red Team a pu comprendre les moyens d’intervention de l’équipe SOC sur le Système d’Information, les coffres-forts où sont stockés leurs secrets, et les droits nécessaires pour y accéder.

Alors, en utilisant le compte administrateur de l’IAM récupéré dans OneDrive, une attaque se basant sur les procédures d’intervention du SOC a été réalisée pour compromettre intégralement le Système d’Information on-premise du client.

Dans ce cas de figure également, des recherches ciblées sur SharePoint et OneDrive ont permis de récupérer de l’information technique très intéressante pour un attaquant, notamment l’agent EDR déployé sur les DC, les secrets nécessaires à son utilisation, les droits à s’attribuer pour y accéder.

Au-delà des mots de passe récupérés (chiffrés ou non) dans l’ensemble des scénarios précédemment décrits, SharePoint et OneDrive représentent un accès à la connaissance du SI pour l’attaquant. Lorsque l’attaquant se veut discret, il doit reproduire au mieux les flux métiers et d’administrations légitimes de l’entreprise. Le prérequis à cela est tout d’abord de les connaître, pour ensuite les comprendre et les appliquer.

Protéger et détecter les usages malveillants des App Registrations

Comme énoncé précédemment, SharePoint et OneDrive ont permis l’obtention de secrets relativement sensibles et compromettants pour les SI clients. Il reste donc primordial de sensibiliser les collaborateurs au stockage sécurisé des secrets et de les outiller à ces mêmes fins.

Malgré cela, il convient d’appliquer des processus et des mesures de sécurité à ces applications afin de leur faire respecter les principes de moindre privilège et de défense en profondeur. Ci-dessous sont listées des recommandations à appliquer à ces App Registrations.

Revue régulière et principe de moindre privilège

Il convient d’inventorier les applications disposant des permissions sur SharePoint et restreindre ces applications au strict minimum. Les permissions en question sont les suivantes :

• Sites.Read.All;
• Sites.ReadWrite.All;
• Sites.FullControl;
• Files.Read.All;
• Files.ReadWrite.All.

Au même titre que pour les utilisateurs et groupes à privilèges, une revue régulière de ces App Registrations est nécessaire.

Gestion et supervision des secrets

Afin d’éviter que des App Secret ne se retrouvent stockés de manière non sécurisée (au sein de scripts, documentations, mails, etc.), il est recommandé de préférer l’usage de certificats de connexion.

De manière générale, les secrets de connexion doivent faire l’objet d’un renouvellement régulier et automatisé.

La création d’une App Registration génère automatiquement la création d’une Enterprise Application. Lorsque celle-ci se voit attribuer des permissions de lecture sur SharePoint, un consentement de la part d’un Global Administrator est nécessaire. Il n’est ainsi pas trivial pour un attaquant de créer ce type d’applications privilégiées et l’ajout d’un secret à une application existante à privilèges sera souvent préférée par l’attaquant.

Il convient donc de superviser la création de nouveaux secrets de connexion sur les applications à privilèges.

Réduire la surface d’exposition

Enfin, il est recommandé de limiter les capacités d’utilisation de ces applications. Il peut s’agir de restrictions sur l’adresse IP source ou encore sur les plages horaires d’utilisation de l’application.

Note : Il n’est pas toujours nécessaire d’appliquer ces mesures en mode « bloquant ». En effet, une détection sans blocage peut déjà permettre à la Blue Team de prendre connaissance de l’attaque et amorcer sa réponse.

Cet article SharePoint & App Registrations : Vecteur de compromission du SI et RETEX Red Team est apparu en premier sur RiskInsight.

Pour celles qui n’ont pas encore franchi le pas (principalement les ETI et le secteur public), il est essentiel de démarrer au plus vite une réflexion autour des plateformes de collaboration et de communication Cloud. Ceci, afin de pouvoir assurer une continuité du service en cas de force majeure (cyberattaque, catastrophe naturelle ou même pandémie), voire même d’envisager une migration plus conséquente.

Pour cette plateforme de Digital Workplace, une étroite collaboration entre équipe sécurité et workplace sera un prérequis !

Dans cet article, je souhaiterais vous faire part de quelques retours d’expérience concernant le déploiement d’Office 365, la solution de Microsoft qui tend à s’imposer chez les entreprises que nous accompagnons.

Il existe de nombreuses documentations intéressantes sur le sujet sur Internet (« Top 10 des bonnes pratiques » ou « 3 bonnes raisons de raccorder l’application xxx pour assurer votre sécurité… »). Microsoft résume une partie de ces bonnes pratiques dans ces deux articles :

• Feuille de route sécurité Microsoft : 30, 90 jours et au-delà
• 10 principales façons de sécuriser les données Office 365

Aujourd’hui, je ne veux pas refaire ici une liste non-exhaustive de ces bonnes pratiques mais plutôt vous rappeler six points d’attention lors d’une ouverture d’un tel service.

1/ Construire le standard de sécurité, pilier de la future relation entre les équipes sécurité et workplace

Comme pour tout projet de ce type, il faut commencer par évaluer le potentiel du service et voir comment il pourra répondre au besoin initial, via l’élaboration d’un business case. Les possibilités offertes par Office 365 sont multiples : bureautique, messagerie instantanée ou email, visualisation de données développement d’applications sans code, etc.

Côté équipes sécurité, deux choix se présentent : s’opposer à cette migration en raison des risques liés au Cloud américain ou accompagner la réflexion pour créer des nouveaux usages sécurisés.

Dans une grande majorité des cas, le second choix est préféré. Il débute alors une relation tripartite, entre les équipes workplace, la sécurité, les architectes, dont l’objectif sera de construire un service pour les utilisateurs. Un résultat de cette étape pourra être l’élaboration d’un standard de sécurité, issue d’une analyse de risques, définissant les services utilisés et avec la configuration associée.

Parmi les questions à traiter, on retrouve généralement les trois thématiques suivantes :

• Quels usages offrir à en situation de mobilité ? Moyennant quelle authentification ?
• Quels nouveaux services proposer avec les possibilités d’intégration avec les API ?
• Comment partager des documents avec des utilisateurs externes ?

La tendance actuelle consiste à apporter des réponses avec une approche « Zéro trust ». Tout écart au standard de sécurité défini devra être détecté, grâce à la mise en place de tableaux de bord et de la supervision. L’adage « La confiance n’exclut pas le contrôle » n’aura jamais eu autant de sens.

Cette réflexion pourra même être l’occasion de se reposer des questions fondamentales afin de poser des bases cohérentes pour l’environnement de travail. Par exemple, pourquoi laisser l’email, un système vieux de 30 ans, ouvert à tout va et bloquer à l’externe ma messagerie Teams et mes partages SharePoint ? L’amélioration de l’expérience utilisateur ne pourra se faire qu’avec l’uniformisation des pratiques de sécurité.

2/ La protection des données, un sujet avec le vent en poupe

En parallèle de la construction du service, vient le sujet des données qui seront utilisées dans le tenant. Pour le coup, deux questions simples doivent trouver des réponses (souvent complexes).

 Comment protéger mes données ?

Aujourd’hui, les stratégies de protection des données non structurées reposent sur une base commune : le rattachement d’une donnée à un niveau de sensibilité. Cette correspondance entraine des mesures de protection à mettre en place :

• Chiffrement avec des clés maîtrisées par le CSP ou l’organisation ;
• Restriction des droits (ou DRM) ;
• Accès conditionnel avec authentification multi-facteurs ;
• Data Leakage Protection (ou DLP).

Afin de ne pas surprotéger les données et ainsi, éviter de d’amoindrir l’expérience utilisateur, le chiffrement et la restriction des droits peuvent être réservées aux données les plus critiques. Les autres données resteront tout de même maîtrisées grâce à des mesures plus classiques, comme le chiffrement bout en bout et le contrôle du niveau d’exposition.

Un facteur clé pour un tel projet, sera d’en faire un véritable projet d’entreprise, avec un programme de sensibilisation complet dédié à la classification.

Le chiffrement et la restriction des droits peuvent être réservées aux données les plus critiques.

Comment rester conforme avec la réglementation ?

Une organisation peut être soumise à des réglementations locales, liées à ses implémentations, et sectorielles, en fonction de ses activités.

Ces réglementations et directives imposent dans certains cas de véritables obstacles qu’il convient de lever dès le début du projet : rétention des données, archivage légal, géolocalisation, enquête judiciaire, demandes liées à des données à caractère personnel.

Prenons un exemple concret : la Russie. Avec la loi sur les données à caractère personnel de 2015, l’autorité de régulation nationale impose de conserver la source (appelée base primaire) des données de ses citoyens sur le sol russe. En pratique, cela revient à dire que l’Active Directory (base primaire des identités de l’entreprise) de l’entité russe doit rester Russie. De là, les informations pourront être synchronisées avec la GAL (Global Access List) et Azure Active Directory.

Le Trust Center de Microsoft sera très utile pour cette étape.

 L’épineuse question de la gestion du stock

Que faire des données déjà existantes ? Il s’agit d’une problématique complexe, en particulier si l’ouverture d’une solution de collaboration Cloud est liée au décommissionnement des serveurs de fichiers existants.

Tout d’abord, il y a une question technique. Est-ce que le réseau de l’entreprise sera capable de supporter des migrations massives de .pst et de documents ? En particulier, il ne sera pas nécessairement utile de migrer des données qui ne seront pas conforme avec la politique de rétention.

Ensuite, les données historiques peuvent avoir une sensibilité hétérogène et être soumises à diverses réglementation. Un arbitrage sera nécessaire, afin d’arbitrer entre un maintien des données en local, une acceptation du risque et un projet large de classification avant ou après migration.

3/ Le Target Operating Model, garant du maintien de la sécurité dans le temps

Le modèle opérationnel d’un service comme Office 365 définit les responsabilités des acteurs (administrateurs, supports, etc.) et les principes de gestion des objets. Il est complémentaire au standard de sécurité évoqué précédemment, en apportant une vision plus opérationnelle.

Le TOM doit être rédigé préalablement à l’ouverture du service, et mis à jour régulièrement. Il doit inclure à minima les sujets suivants.

 Un modèle d’administration

Microsoft propose par défaut une cinquantaine de rôles d’administration, sans compter les rôles RBAC des services (ex : Exchange et Intune). Une utilisation pertinente de ces rôles et de rôles personnalisés permettra d’éviter d’avoir trop d’Administrateurs Généraux et de suivre le principe du moindre privilège. L’implémentation d’accès Just-in-Time permettra de plus de suivre l’usage réel des rôles, tout en renforçant la sécurité.

Une communauté mi-architecture / mi-sécurité

Comme toute plateforme SaaS, Microsoft fait évoluer régulièrement les fonctionnalités de sa suite collaborative. La mission de cette communauté sera de faire de la veille sur les tendances, afin de maîtriser les nouveaux usages et de garder le contrôle sur le tenant en tenant compte des évolutions.

Le cycle de vie des identités et des espaces partagés

Une gestion laissée libre des espaces partagés (Teams, SharePoint) peut entrainer une explosion du nombre d’espaces ne respectant pas le standard de sécurité. Les rapports des éditeurs de solution de Data Discovery sont assez frappants. Pour éviter cela, il est nécessaire de fixer un cycle de vie des espaces partagés. Ces règles peuvent inclure une convention de nommage, des politiques de rétention, une durée de vie, des principes quant à la gestion des droits.

La mise en place d’un portail unique pour la création de ces espaces permettra d’implémenter ces bonnes pratiques, tout en favorisant l’expérience utilisateur.

Les rapports des éditeurs de solution de Data Discovery sont assez frappants en ce qui concerne l’exposition des données en raison du manque de gouvernance.

De même, un cycle de vie pour les objets Azure AD (incluant utilisateurs invités, groupes de sécurité, groupes Office 365 et applications) doit être défini et outillé. Voici deux exemples qui méritent d’être traités : la délégation des API est laissé ouverte et laisse la porte à des fuites de données massives ; les utilisateurs invités à collaborer ne sont jamais supprimés. Pour cela, deux stratégies sont possibles :

1. Création d’un Custom Automation Engine décorrélé de l’IAM, via une application maison développée en PowerShell ;
2. Intégration d’un connecteur Powershell / Graph API à la solution IAM en place afin de présenter une gestion complète des objets en faisant abstraction de leur hébergement direct.

4/ Abordez le sujet de l’identité des utilisateurs avec un regard neuf

Pilier fondateur du SaaS, le sujet de l’identité doit être abordé avec un œil neuf afin de considérer toutes les possibilités et les risques des fournisseurs d’identités (ou IdP) SaaS. En particulier, il est impensable en 2020 de considérer Azure Active Directory comme un simple Contrôleur de domaine dans le Cloud.

Trois approches sont possibles pour la source des identités accédant à Office 365.

La dissociation des identités, un quick-win mais compliqué d’un point de vue utilisateur

Il est possible de dissocier les identités local et Cloud si l’AD local n’est plus disponible ou pour décorréler l’espace de travail Cloud du SI historique. Ce scénario n’est évidemment pas en faveur d’une expérience optimale, mais peut-être un atout précieux en cas de crise ou de compromission avérée du SI.

L’utilisation de l’identité locale dans le Cloud, une stratégie classique

Afin de concilier sécurité et expérience utilisateur, il est nécessaire d’utiliser la même identité entre les applications historiques et ce nouveau service. Pour cela, trois scénarios techniques sont disponibles :

• Fédération des identités : Cette solution historique est très largement utilisée par les grandes entreprises françaises frileuses à l’idée d’héberger les mots de passe dans le Cloud et souhaitant avoir du SSO ;
• Synchronisation des Hash des mots de passe (Password Hash Sync en anglais ou PHS) : Cette solution, recommandée par Microsoft et par l’équivalent britannique de l’ANSSI, est implémentée une grande majorité des clients de Microsoft. Cette solution peut également être utilisée en tant que dispositif de secours lorsque le service de fédération n’est plus disponible ;
• Authentification directe (Password Through Authentication ou PTA) : Cette solution apporte la meilleure expérience utilisateur mais a l’inconvénient de faire transiter le mot de passe par Azure AD.

Migrer son référentiel d’identité dans le Cloud, une vision à plus long terme

Avant ou après migration, il pourra être opportun d’envisager de migrer complètement la source des identités dans le Cloud (qu’il s’agisse d’Azure AD ou d’une solution tierce), afin de profiter des nouvelles possibilités. Il reste aujourd’hui plusieurs prérequis devant être levés, comme la gestion des imprimantes, des GPO et des terminaux.

5/ Ouvrir progressivement les services, pour favoriser une adoption maîtrisée

Il est toujours plus facile d’ouvrir un nouveau service que de revenir en arrière pour des raisons de sécurité. Ouvrir massivement les différents services de la suite collaborative a l’avantage d‘offrir un maximum de cas d’usages, mais peut provoquer plusieurs effets de bords.

Tout d’abord, les services non officiellement supportés et laissés à la main des utilisateurs à des fins de tests représentent un risque certain. Ils doivent être configurés et durcis. Dans certains cas, il peut même être préférable de désactiver les licences correspondantes.

Ensuite, un lancement maîtrisé des outils permettra de maîtriser les coûts pendant les premiers mois ou années de la transition. En effet, les licences Microsoft représentant une certaine charge, il est possible d’optimiser les licences non utilisées.

La conduite du changement est également un aspect clé à considérer ; pour favoriser l’expérience utilisateur certes, mais également pour favoriser sécurité des données. Il est essentiel d’avoir une feuille de route et un parcours utilisateur clairement définis. Une adoption accompagnée permettra de poser les bases d’une gouvernance propre des espaces partagés et des données (tant en termes d’exposition que de protection).

Il sera utile d’envisager de créer une communauté d’évangélistes et d’utilisateurs afin de conserver une dynamique dans l’adoption des nouvelles fonctionnalités apportées par Microsoft. Un système de uservoice pourrait être un atout ; l’idéal étant d’être à l’écoute des besoins des utilisateurs et prioriser en fonction les prochaines ouvertures.

6/ Les licences, nerf de la guerre d’Office 365 et de la sécurité

Les solutions SaaS sont généralement soumises à un modèle de licences facturées mensuellement. Le choix des licences Microsoft 365 doit être le fruit une réflexion globale. Il ne peut rester l’apanage des équipes workplace, et être déterminé par le seul besoin de collaboration et de communication.

En effet, le choix du niveau de licensing conditionnera la stratégie de sécurisation du tenant. Ce choix aura plus largement des impacts sur la stratégie de sécurisation de l’environnement de travail.

Microsoft se positionne de plus en plus comme challenger des fournisseurs de solutions sécurité, étant le seul à proposer une suite aussi complète.

Le licensing des options sécurité est à traiter dès le début du projet, et à chaque renouvellement. Il sera moins onéreux d’inclure un paquet de licences dès le départ que de commander en urgence des licences AAD P1 pour en urgence du MFA.

Dans cette stratégie à définir, il pourra être opportun de cibler des personae pour adapter les exigences de sécurité à leur profil (VIP, admin, population médicale, etc.), via une approche par les risques.

Cette démarche, présentée ici pour Office 365, peut être généralisée à tout service SaaS (Solution as a Service), voire service IaaS (Infrastructure as a Service) ou PaaS (Platform as a Service).

Cet article Comment migrer son environnement de travail sereinement vers Office 365 est apparu en premier sur RiskInsight.

La sécurisation d’Office 365 passe par de nombreuses thématiques à adresser, dont la nécessité d’être en capacité de tracer les actions, afin de détecter des comportements illicites ou de remonter à la cause d’un incident.

En France, de nombreuses entreprises ont cependant des difficultés pour consolider les logs et définir des cas d’usages de supervision. La maîtrise de la journalisation doit être au cœur de cette démarche.

La supervision des actions d’administration, une nécessité

Pour ce décryptage sur la journalisation, prenons le cas des administrateurs de la plateforme.

Comme pour les autres solutions SaaS (Google Cloud Platform, Salesforce, etc.), l’atteinte à l’intégrité ou à la confidentialité des données à la suite d’une erreur ou d’une action malveillante d’un administrateur de l’entreprise se retrouve parmi les risques majeurs identifiés par nos clients

Par définition, les administrateurs Office 365 possèdent des privilèges élevés :

• Configuration des différents services – ou workloads – et des API ;
• Gestion des permissions sur les OneDrive et les boîtes mails des utilisateurs ;
• Gestion du cycle de vie des espaces de collaboration.

Il est facile d’imaginer les conséquences désastreuses qui pourraient résulter d’une utilisation malveillante ou non maîtrisée de ces privilèges. En effet, des paramètres tels que le partage à l’externe de SharePoint Online, les autorisations des API ou la configuration de la messagerie pourraient introduire des vecteurs de fuite de données significatifs.

Les bonnes pratiques du SI on-premise (cycle de vie, principe de moindre privilège, segmentation des droits, authentification forte, just-in-time access etc.) doivent aussi être appliquées sur le Cloud. Le Cloud aussi doit être maîtrisé et contrôlé.

Cependant, l’implémentation des bonnes pratiques  bien que nécessaire, ne suffisent pas. En effet, elles ne permettent pas de s’assurer qu’un administrateur ne réalise pas des actions diminuant le niveau de sécurité ou des actions illicites. On peut donc naturellement se demander comment il serait possible d’auditer les actions effectuées et de lever des alertes le cas échéant.

Quels sont les moyens fournis par Microsoft ? Comment prévenir qu’une personne malveillante n’efface ses traces (ce qui rendrait une attaque plus difficile à détecter et à reconstituer) ?

Afin d’illustrer les différentes possibilités, nous allons suivre les quatres exemples ci-dessous :

Figure 1 – Exemple d’actes d’administration suspects

Quels journaux sont disponibles ?

Unified Audit Logs : journalisation unifiée des différents services

Pour des raisons historiques et techniques, Office 365 possède nativement plusieurs sources de journaux : Unified Audit Logs, Exchange Logs et Azure Logs. Ces sources sont complémentaires et doivent être analysées conjointement afin d’avoir une vision exhaustive des actions d’administration réalisées.

La source de logs la plus couramment citée et utilisée sont les « Unified Audit Logs ». Ces logs centralisent les traces des utilisateurs et celles des administrateurs, pour l’ensemble des services de la plateforme : SharePoint Online, Azure AD, Exchange Online, Teams, Power Platforms. Microsoft intègre progressivement les différentes sources et continue à rajouter des nouveaux logs.

Pour revenir à nos exemples concrets, les logs intéressants sont :

• Modification de la Politique de partage à l’externe de SharePoint Online : SharingPolicyChanged
• Attribution de droits à un OneDrive : SiteCollectionAdminAdded
• Attribution de droits à une boîte mail : AddMailboxPermission
• Modification d’un rôle d’administration : AddMembertoRole

Ces logs sont accessibles et exportables via les Centres de Conformité et de Sécurité, les API Office 365 Management et PowerShell (via la cmdlet Search-UnifiedAuditLog). Notons que la journalisation doit être activée via le Centre de Conformité ou via PowerShell afin de pouvoir enregistrer des logs et permettre la recherche.

Il est possible de configurer directement des alertes liées à l’occurrence de certains logs dans les Centres de Sécurité et de Conformité.

Exchange Logs : journalisation de l’infrastructure de messagerie

La deuxième source de logs intéressante sont les « Exchange Logs ». Ces logs fournissent des informations quant aux actions d’utilisation et d’administration réalisées sur le service Exchange Online ainsi que sur les boîtes aux lettres personnelles ou partagées. Deux typologies de journaux peuvent être distinguées :

• Administrator Audit Logs: Logs d’administration du service ou d’une boîte aux lettres (ex : modification des permissions d’un utilisateur, modification de la durée de rétention de conservation des journaux d’une boîte aux lettres etc.)
• Mailbox Audit Logs : Logs d’utilisation d’une boîte aux lettres par l’utilisateur principal, un utilisateur délégué ou un administrateur de service (ex : accès à la boîte aux lettres, envoi d’un mail à la place de l’utilisateur principal, déplacement d’un élément dans un dossier, suppression définitive, etc.)

Pour revenir à nos exemples concrets, les logs qui vont nous intéresser ici sont :

• Attribution de droits à une boîte aux lettres : AddMailboxPermission
• Accès à un dossier ou à une boîte aux lettres : FolderBind (non activé par défaut):
• Accès à un mail : MailItemAccessed (uniquement pour les utilisateurs ayant une licence E5)

Pour aller plus loin avec les Administrator Audit Logs

Les Administrator Audit Logs sont générés pour toute action d’administration Exchange pouvant être reliée à une cmdlet PowerShell autre que Get, Search ou Test. Ces logs sont liés aux Unified Logs et peuvent être exploités dans le Centre d’Administration Exchange, les Centres de Sécurité et de Conformité, les API Office 365 Management et PowerShell.

Pour aller plus loin avec les Mailbox Audit Logs

Les Mailbox Audit Logs sont la seule catégorie de logs à être configurable (périmètre et granularité). Ces logs permettent de tracer les actions réalisées par un owner (propriétaire), un delegate (utilisateur ayant des permissions) et d’un admin (accès via les outils eDiscovery).

Depuis Janvier 2019, la journalisation des Mailbox Audit Logs est activée par défaut pour l’ensemble des locataires Office 365. A date, si la journalisation est activée par défaut, l’ensemble des boîtes aux lettres sont auditées (même si le paramètre « -AuditDisabled » est à « True »). La seule façon de ne pas journaliser les actions d’une boîte mail est d’implémenter une règle de by-pass avec « Set-MailboxAuditBypassAssociation ».

Il faut toutefois noter que certaines actions ne sont pas auditées par défaut, comme par exemple l’accès d’un delegate ou d’un admin à une boite mail d’un utilisateur. Il est par conséquence primordial d’analyser les journaux à activer, lors de la configuration initiale du service.

Selon le niveau de licences et la configuration, ces logs peuvent être liés aux Unified Logs et être exploités dans le Centre d’Administration Exchange, les API Office 365 Management et PowerShell ou les Centres de Sécurité et de Conformité.

Azure Logs et Rapports : journalisation d’Azure Active Directory

La dernière source de logs, mais pas la moins importante, sont les « Azure AD logs ». Ces logs permettent de fournir des traces complètes pour la brique d’identité d’Office 365 ainsi que sur les actions d’administration associées. Plusieurs catégories de journaux et de rapports sont disponibles :

• Azure Audit Logs: Logs d’administration de la brique d’identification ou de modification des éléments (ex : attribution du rôle « SharePoint Administrator », création d’un utilisateur ou d’un groupe de sécurité, autorisation d’une API, configuration des utilisateurs invités, etc.)
• Azure Sign-in Logs: Logs de connexion à un service Office 365 (ou à des applications / ) avec des informations sur la chaîne de connexion (ex : protocole, adresse IP, terminal, etc.)
• Risky Sign-in: Rapports de connexion avec des indicateurs liés à des connexions suspectes.

Ces logs et rapports sont accessibles et exportables via le portal Azure, les API Graph ou Azure Management et PowerShell. Certains des logs directement liés à Office 365 se retrouvent aussi dans les Unified Audit Logs.

Pour revenir à nos exemples concrets, les logs intéressants sont :

• Modification d’un rôle d’administration : AddMembertoRole
• Ajout d’une application : CoreDirectory – ApplicationManagement – Add service principal / Add application
• Consentement à une application : Core Directory – ApplicationManagement / Add delegated permission grant / Consent to application (ConsentContext.IsAdminConsent)

Figure 2 – Récapitulatif des caractéristiques des logs d’Office 365

En résumé, les Unified Audit Logs apportent une vision consolidée des différents services d’Office 365, mais certaines informations peuvent être manquantes. Il sera nécessaire de s’assurer que les journaux requis soient bien présents, et ensuite d’approfondir une investigation dans les logs et les rapports d’Exchange ou Azure.

Quelle rétention pour les différents journaux d’Office 365 ?

Une fois les logs adéquats identifiés, se pose le défi de la rétention. Comment être sûr que les journaux sont bien conservés sans être altérés, pendant toute la durée requise par la politique de sécurité de l’entreprise et les différentes réglementations, comme la loi anti-terroriste ou le RGPD ?

Par construction, et contrairement aux solutions Exchange and SharePoint on-premise, tous les logs cités précédemment sont inaltérables – c’est-à-dire non modifiables ni supprimables par les administrateurs de l’entreprise. Par ailleurs, les durées de conservation définies par défaut ne peuvent être modifiées (à savoir 90 jours pour les logs Office 365 et 7 ou 30 jours pour les logs Azure avec des licences standards). Ceci à une exception près, un administrateur Exchange a la possibilité d’effacer les journaux des boîtes aux lettres, en modifiant la durée de rétention associée.

Si on reprend nos exemples, on pourrait tout à fait imaginer un administrateur malveillant se donnant des droits pour accéder à une boîte mail, puis regarder les mails et effacer les logs d’accès en fixant une durée de rétention nulle. Dans ce cas, ne serait conservée que l’élévation de privilège réalisée dans les Administrator Audit Logs.

Afin de se mettre en conformité avec les exigences de sécurité ou la réglementation, il pourra de plus être nécessaire de s’assurer que les journaux des différents services soient conservés plus de 7, 30 ou 90 jours.

Quelques étapes pour implémenter une journalisation pertinente au sein d’Office 365

1. Définition et activation des logs nécessaires: les Unified Audit Logs peuvent ne pas être suffisants (suivi des API Office 365 et Azure AD, journalisation des accès des administrateurs aux boîtes aux lettres, etc.)
2. Configuration d’un export automatique des journaux identifiés vers un stockage externe  (via PowerShell ou les API Management) ;
3. Suivi de l’état du tenant : implémentation d’un tableau de bord des paramètres du tenant configuration d’alertes liées à un changement de la configuration des journaux (via le Centre de Sécurité ou Conformité, les API Office 365 Management ou PowerShell), comme la désactivation des Unified logs ou à une modification de la rétention des logs d’une boîte aux lettres ;

Figure 3 – Bonnes pratiques pour la journalisation du tenant

Après avoir réalisés ces trois actions, l’entreprise aura les informations nécessaires pour auditer les actions d’utilisation et d’administration du tenant. Cependant, elles ne répondent pas encore au besoin plus large de supervision des administrateurs. Il pourra être utile de mettre en place des alertes (via le Centre de Sécurité ou de Conformité ou des outils tierces spécialisés).

1. (Pour aller plus loin) Mise en place d’une supervision basique : définition de scénarii de détection sécurité généralistes, identification des logs concernés, activation de l’alerte associée dans les Centres de Sécurité ou de Conformité ;
2. (Pour aller encore plus loin) Mise en place d’une supervision avancée : identification de scénarii liés à un contexte métier, implémentation, définition de la gouvernance associée, amélioration continue.

Quels outils utiliser pour analyser les journaux ? Quels scénarios de détection prioriser ? Quelle gouvernance mettre en place pour définir, implémenter et suivre des alertes ? Autant de questions qui doivent être traitées dans l’implémentation de la supervision de la plateforme de collaboration.

Il faudra également prendre en compte les changements réguliers apportés par Microsoft sur ces services, ainsi que sur la structure des logs et des API. D’autant plus que cohabitent les fonctionnalités en Preview et celles en General Availability.

Cet article Journalisation d’Office 365 : un cas concret avec les administrateurs est apparu en premier sur RiskInsight.

Début octobre 2014, Microsoft reprend son destin en main et lance une 1^ère  version d’évaluation de son futur système d’exploitation : Windows 10. Ce dernier est mis en circulation pour entamer une grande phase de séduction et de reconquête des décideurs et du grand public. Mais pourquoi passer de 8 à 10 ? L’idée est ici de marquer une rupture franche avec le passé.

Cette sortie anticipée a pour objectif d’obtenir un maximum de retours terrain avant la mise sur le marché finale prévue pour mi-2015 et perpétuant le rythme désormais triennal des sorties de systèmes d’exploitation. Cette sortie est aussi l’occasion de voir comment Microsoft se projette, en particulier sur le secteur des terminaux mobiles.

Microsoft doit faire ses preuves sur les terminaux mobiles

Plus de deux ans après sa sortie, le parc déployé sur les PCs de Windows 8 et Windows 8.1 (~18%) est légèrement supérieur au vieillissant Windows XP (~12%) tout en restant en retrait par rapport à Windows 7 (~56%) qui reste aujourd’hui le système d’exploitation majoritaire. Néanmoins, sur le marché en pleine mutation des terminaux mobiles la situation est totalement inversée, Android (~54,5%) et iOS (~31%) écrasent le marché et Windows reste marginal (~2%). Le constat que fait Microsoft est que l’omniprésence du PC dans un environnement de travail n’est plus garantie du fait de l’augmentation constante de la part des terminaux mobiles.

La révolution ergonomique proposée par Windows 8 et Windows 8.1 n’a pas trouvé son public. Pire ! Elle a mis Microsoft en difficulté. Par conséquent, Windows 10 arrive dans un contexte difficile et son adoption n’est pas acquise par avance. Des réponses doivent plus que tout être apportées sur les nouveaux usages (ATAWAD en particulier – Any Time, Any Where, Any Device) et sur son interface graphique. Microsoft a compris qu’il devait se remettre en question afin de séduire de nouveau le grand public et les entreprises.

Un positionnement désormais global pour couvrir l’ensemble des terminaux et des usages

Microsoft a confirmé que Windows 10 serait un système d’exploitation unique pour l’ensemble des terminaux qu’ils soient tactiles ou non : smartphones, XBOX, PCs, tablettes. Cette unification du système d’exploitation ouvre la voie à l’unification du Store applicatif. La récente communication de Microsoft sur le nombre d’applications présentes au sein du Windows Store(525 000 applications contre 1,5 million pour Google Play – 1,3 million pour l’AppleStore) démontre que ce dernier est désormais le nerf de la guerre pour séduire le marché. En particulier pour les entreprises, la mise en place d’un Store applicatif équivalent mais dédié, comme vecteur de distribution d’applications, permet d’envisager des réductions de coûts.

Le défi que doit relever Microsoft est la possibilité de développement unifié des applications, quelles que soient l’architecture sous-jacente (ARM, x86, x64), les form factors des terminaux (écran de petite taille en mode portait jusqu’au grand écran en mode paysage) et les périphériques de saisie (dalle tactile, clavier physique ou virtuel, souris …). Ce dernier point était par exemple l’un des griefs principaux faits à Windows 8, son interface ayant été pensée tactile et finalement peu exploitable en mode clavier/ souris. Malgré les efforts d’évangélisation menés par Microsoft pour conforter les possibilités de développement unifié au travers de ModernUI, à ce jour des doutes persistent sur la faisabilité. Par ailleurs, les applications dites « traditionnelles » restant majoritaires, leurs conversions et redéveloppements en ModernUI vont nécessiter des investissements conséquents sur plusieurs années.

La question résiduelle sur laquelle il n’est pas encore possible de statuer est l’empreinte en termes de ressources requises au bon fonctionnement de Windows 10. Sur PC les besoins en ressources sont similaires à Windows 8.1. Sur les terminaux légers (smartphones et tablettes) le confort d’utilisation reste une interrogation majeure.

De 1ers résultats prometteurs pour Windows 10, mais des incertitudes persistantes

Les évolutions apportées à l’interface graphique vont dans le sens d’un alignement de l’ergonomie avec Windows 7. En effet le Menu Démarrer fait son grand retour. Les applications ModernUI subissent aussi des évolutions importantes avec la possibilité d’exécution en mode classique couplée à une adaptation des informations affichées selon la taille de la fenêtre (sur Windows 8 et Windows 8.1, le mode plein écran était obligatoire). Il s’agit d’une 1^ère étape pour le support natif des tailles et résolutions d’écrans variées.

Dans un 2^nd temps, Microsoft prévoit d’implémenter des mécanismes permettant d’adapter le comportement Windows 10 en fonction des périphériques de saisie détectés. Le but étant de déporter la gestion des interfaces de saisie au niveau du système d’exploitation. La vertu de cette approche est que tout type de terminal fonctionnant sous Windows 10 pourra désormais exécuter les applications sans avoir à gérer le type d’interfaces utilisées. Ce mode de fonctionnement permettrait d’alléger le processus de développement des applications de la plupart des tests de validation de bon fonctionnement, phase généralement coûteuse en termes de budget et de temps.

Le dernier point est la tarification de Windows 10. Les 1^ères pistes laissent présager une approche en mode « rupture » (un coût réduit voire une gratuité envisagée des mises à jour depuis Windows 8 et Windows 8.1 ), confirmant le fait que le système d’exploitation devient une commodité permettant de consommer des services (en particulier Office 365) depuis tous types de terminaux sans contrainte.

Des orientations prometteuses qui permettent aux entreprises d’envisager plus sereinement les réflexions nécessaires au remplacement de Windows 7 qui aura atteint la moitié de son cycle de vie en janvier 2015.

Le grand public un vecteur de pénétration en entreprise ?

Les retours d’expérience basés sur la pénétration des nouveaux terminaux mobiles depuis la sortie de l’iPhone en 2007 montrent que les entreprises sont de plus en plus soumises aux tendances du marché et doivent se questionner sur le phénomène croissant du BYOD. En effet, les utilisateurs souhaitent disposer de terminaux professionnels aussi avancé que ceux qu’ils ont à titre personnel.

Nos retours terrain nous laissent présager que sur le PC, Windows 10 trouvera facilement son public car il répond,  de par son interface graphique, aux attentes communes du grand public et des directions IT. Microsoft a en tous cas bien démontré sa volonté d’aligner son système d’exploitation aux besoins des entreprises et aux attentes du grand public. Néanmoins sur les terminaux mobiles, en comparaison de Google et d’Apple, Microsoft présente un fort déficit d’image et l’adhésion est loin d’être acquise. Pénétrer le marché reste néanmoins possible et Microsoft mise largement dessus.  Il suffit de regarder les nombreuses initiatives menées auprès du grand public (publicité, etc.) et des dirigeants (campagnes de séduction lors du lancement de la version d’évaluation de Windows 10, volonté de BMW de migrer sa flotte de mobiles sur Windows). Si l’adhésion se confirme, les entreprises pourront clairement y trouver un fort intérêt en termes de rationalisation des outils de gestion de parc et de sécurité (réduction des besoins en outils tierces) et de développement des applicatifs métiers.

Quoiqu’il en soit, Microsoft n’a pas encore tout dévoilé et il compte bien enrichir encore Windows 10 avant de le sortir !

Cet article Windows 10 : fer de lance de la nouvelle stratégie de Microsoft est apparu en premier sur RiskInsight.

Microsoft est-il vraiment capable de mettre en difficulté VMware ? Faut-il migrer vers Hyper-V ? Adopter une stratégie « multi-sourcing » ? Autant de questions que se pose le marché et auxquelles nous avons tenté de répondre.

Microsoft, un sérieux challenger de VMware

Depuis l’avènement de la virtualisation x86, VMware est le leader incontesté du marché. La majorité des grandes entreprises utilisent sa solution vSphere et en sont satisfaites.

Cependant, comme toute situation de quasi-monopole, cette domination du marché entraîne des préoccupations. Les produits VMware sont chers et la politique commerciale peut évoluer rapidement (la mise en place d’une facturation à la mémoire vive utilisée, abandonnée par VMware par la suite, avait suscité un tollé auprès de ses clients).  De plus la réversibilité est complexe et coûteuse.

De son côté, Microsoft a décidé d’accélérer sa pénétration du marché en intégrant le produit Hyper-V dans Windows Server depuis la version 2008. Jusqu’ici en retard techniquement, Hyper-V s’est amélioré à chaque itération jusqu’à devenir, avec Windows Server 2012 R2 et la suite System Center, un sérieux challengeur de VMware.

Aujourd’hui, la course entre VMware et Microsoft ne se concentre plus sur les caractéristiques techniques maximales ou sur les fonctionnalités. En effet, bien que différentes, les deux solutions répondent à la très grande majorité des besoins (qui a besoin d’une machine virtuelle avec plus de 64 vCPU ?).

Alors comment choisir ? En pratique, VMware reste encore en avance au niveau de l’exploitabilité  et dispose d’un plus grand écosystème de composants compatibles, alors qu’Hyper-V est généralement plus compétitif financièrement.

Au-delà de ces points (qui sont à relativiser selon le contexte de chaque client et les accords éditeurs), ce sont la vision et les trajectoires des deux géants qui doivent être pris en considération.

Deux trajectoires différentes, mais une vision Cloud commune

Les deux constructeurs partagent en effet une vision du Cloud similaire, basée sur le pilotage unifié de ressources internes au sein d’un Cloud privé et externes au sein de leur Cloud public ou de celui d’un partenaire. En revanche leurs trajectoires sont différentes et liées à l’historique.

Ainsi VMware, fort sur la virtualisation on-premise, a développé une offre de Cloud privé complète et résiliente avant de développer des services de Cloud public (vCHS) et une interconnexion avec un réseau de partenaires (Amazon, OVH, et plus généralement tout fournisseur proposant un connecteur vCloud).

De son côté Microsoft a eu une approche inverse. Il est parti de son Cloud public Azure, lancé bien plus tôt, et a développé dans un second temps son offre de Cloud privé basée sur Hyper-V (avec la suite System Center et Azure pack) en intégrant progressivement les fonctionnalités développées pour Azure.

Qu’en conclure ? Nos deux géants ont une vision fondamentalement différente dans la conception des architectures du Cloud public ! Quand Microsoft adopte une approche où l’application doit intégrer la haute-disponibilité au sein de son architecture (concept dit du design for failure), VMware part au contraire du principe que c’est à l’infrastructure d’offrir des services résilients.

Qu’aller chercher avec Hyper-V ?

Le principal intérêt reste financier : Hyper-V est compétitif. Pour une entreprise ayant un important parc Windows Server, les licences nécessaires sont souvent déjà acquises par l’entreprise (licences Windows Server Datacenter et System center). Le levier d’économie est alors substantiel.

Un autre intérêt est la mise en place d’une stratégie de Dual Sourcing, en ayant une ligne de service Hyper-V et une ligne de service VMware. Ainsi, l’entreprise peut rester indépendante des fournisseurs tout en ayant de plus gros leviers de négociation.

En revanche, il ne faut pas sous-estimer la complexité et le coût d’un projet de migration d’une partie d’un parc. Une approche « Big Bang » est trop risquée et nous conseillons plutôt d’adopter une approche progressive.

Comment ? En commençant par expérimenter Hyper-V en démarrant un pilote sur un périmètre limité et non critique (par exemple quelques environnements de test / staging). Ce pilote permettra de vérifier l’exploitabilité de la plateforme et d’acquérir les compétences en interne. Une généralisation pourra être envisagée par la suite sur une filière complète (environnements de développements et de tests par exemple), selon  les résultats et les opportunités.

Si vous souhaitez aller plus loin en matière de « dual sourcing » et simplifier l’architecture globale, il est préférable de piloter les infrastructures Hyper-V et VMware avec la même solution. Microsoft (avec SCVMM), VMware (avec vCAC) ou des tiers (comme HP avec HP OO) proposent des outils, permettant alors de tirer bénéfice des deux plateformes, tout en simplifiant l’exploitation.

Et la cerise sur le gâteau ? Opter pour ces outils permettront à l’entreprise de se préparer à une approche Cloud Hybride !

Cet article Virtualisation : une hyper compétition entre VMware et Microsoft est apparu en premier sur RiskInsight.

La téléphonie Lync, un démarrage difficile

Microsoft Office Communicator, lancé en 2007 et permettant des échanges en temps réel entre collaborateurs (IM, appels audio/vidéo, présence), devient Lync en 2010 (contraction de « Link » et « Sync »). Ce nouveau produit offre à Microsoft l’opportunité de faire son entrée dans le monde convoité de la téléphonie et des communications unifiées. En se basant sur son historique et son expertise reconnus sur les solutions logicielles collaboratives, Microsoft anticipe une adoption rapide de cette nouvelle brique téléphonie. Cependant, de 2010 à 2012, Lync a du mal à convaincre les Grands Comptes qui ne se sentent pas prêts à jouer les pilotes sur une fonctionnalité aussi critique que la téléphonie, avec un produit sur lequel les intégrateurs n’ont pas vraiment d’expérience.

Moins d’un an après les premiers déploiements à grande échelle, la question la plus fréquemment posée est encore « quels avantages aurais-je à utiliser la téléphonie Lync ?« . Une question qui mérite d’être posée au vu de l’intérêt croissant des entreprises pour les outils collaboratifs – et de fait toute solution les englobant.

Des fonctionnalités distinctes selon le type de licence

Lync a été pensé pour différents usages, traduits par différents niveaux de licences cumulatives. La licence Standard supportant les fonctions « basiques » – IM, présence, appels audio/vidéo poste à poste, interconnexion Skype -, il faudra investir dans la licence Enterprise afin d’avoir accès à l’organisation de réunions, de conférences audio, vidéo ou web. Enfin une souscription supplémentaire à la licence Plus donnera accès aux fonctions de téléphonie telles que les appels vers/depuis l’extérieur de l’entreprise, les renvois d’appel, les groupes de réponse, la délégation patron/secrétaire ou encore les appels d’urgence.

La licence Plus permet réellement d’utiliser le poste de travail comme élément central de la téléphonie, en s’appuyant sur différents périphériques. Il est envisageable d’utiliser les haut-parleurs et le micro de l’ordinateur, ce qui n’engage aucun frais de matériel supplémentaire (sauf pour certains PC/Mac fixes) mais nécessite en revanche des composants de bonne qualité et un environnement sonore extrêmement calme. Le casque audio USB ou sans-fil est souvent le meilleur investissement, permettant une qualité sonore appréciable dans la plupart des cas. Un téléphone physique relié en USB, sans aucune intelligence embarquée, peut être également mis en place. Dans ces deux derniers cas, l’extinction du PC entraîne bien entendu la désactivation du périphérique audio.

Semblables aux solutions classiques de ToIP, des téléphones IP stand-alone peuvent aussi être utilisés, une fois reliés au même compte Lync que celui auquel est connecté le client PC/Mac. Il est alors toujours possible de recevoir et émettre des appels, même avec un PC éteint. Pour les usages en salle de réunion, les Meeting-Phones (ou « Pieuvres audioconférence ») seront préférées, tandis que les solutions naissantes DECT et téléphones Wi-Fi seront destinées aux usines et aux gardiens, embarquant des fonctions avancées telles que la détection d’homme à terre.

La version mobile, Lync Mobile 2013 permet de retrouver la plupart des fonctionnalités offertes par le client (IM, appels audio/vidéo sur IP, partage de présentation PowerPoint réunions en ligne…) sur smartphone ou tablette iOS, Android ou Windows Phone à travers les applications dédiées. À noter que cette version 2013 permet de réels appels Lync (qui rejoignent le réseau de l’entreprise à travers le serveur Edge et le Reverse Proxy) via Wi-Fi ou 3G/4G.

Du point de vue de l’architecture et du sourcing ?

Au niveau architecture globale, Lync ne diffère pas réellement des solutions que peuvent proposer les autres constructeurs de téléphonie, si ce n’est que l’ensemble des services peut être concentré sur un seul serveur (« Front End »), là où d’autres solutions pourraient nécessiter un serveur par application.

Microsoft a également profité de la montée de version majeure de Lync (2010 à 2013) pour faire ses premiers pas dans le Cloud en proposant non plus un seul modèle d’architecture physique (« Server » ou « On Premise« ) mais également une version « Online« , avec la possibilité de mettre en place une architecture « hybride » mixant les deux solutions.

Si la plupart des fonctions de base sont supportées dans les trois versions, seule la version Server permet l’activation de la téléphonie. A l’instar de ses concurrents, Lync permet une connexion au Réseau Téléphonique Commuté (RTC) centralisée ou en local via des passerelles. Sur les sites où la téléphonie a un impact direct sur les métiers (centres d’appels notamment), il est possible d’installer en sus de la passerelle un serveur Lync Standard Edition (SE) ou une Survivable Branch Appliance (SBA) pour conserver l’ensemble de fonctions de téléphonie avancées en cas de perte du WAN (groupes de réponses, conférences,…).

À noter que Microsoft n’est pas fournisseur de ces passerelles, contrairement à Cisco qui fabrique ses propres « Cisco Integrated Services Routers ». L’entreprise de Redmond oriente alors ses clients vers des fournisseurs homologués tels que AudioCodes ou encore Sonus (ex-NET). Il est également important de savoir que l’offre Lync Online (à travers la solution Office 365) ne supporte pas la téléphonie.

Cet article De l’outil collaboratif à la téléphonie, Lync peut-il trouver sa place en entreprise ? est apparu en premier sur RiskInsight.

En 2011, Microsoft avait déjà déboursé $8,5 milliards pour s’emparer de Skype. Si l’on considère que la même année la valeur de la division Smartphones de Nokia était alors évaluée à $30 milliards, 3,79 milliards € semblerait être une bonne affaire pour le groupe.

Les raisons du rachat : vers un modèle vertical pour plus de rentabilité

Le marché du mobile évolue vers un modèle plus vertical, dans lequel le fournisseur de l’OS contrôle de plus en plus les étapes de la fabrication du smartphone. Cette stratégie évite la fragmentation des OS et des spécifications matérielles et permet de garantir que tout téléphone Windows se comportera exactement comme les ingénieurs l’ont voulu.

Même Android, dont  la réussite repose sur le modèle inverse – une plateforme fragmentée entre des centaines de terminaux de marques différentes – doit aujourd’hui produire son propre smartphone « étendard » dont il contrôle la conception et la fabrication (acquisition de la division Consumer de Motorola en 2011, puis sortie du MotoX en 2013).

En 2011, Microsoft avait adopté une stratégie similaire en développant  un partenariat stratégique avec Nokia. Cet accord avec un seul constructeur avait effrayé les autres partenaires de Microsoft, qui ne s’investirent ni ne produisirent jamais réellement en masse les Windows Phones. Microsoft s’était donc retrouvé contraint de travailler avec un seul et unique partenaire, néanmoins fiable, Nokia.

Une plus grande rentabilité par smartphone vendu permettra d’investir  dans la plateforme. Une part importante des bénéfices de chaque vente est aujourd’hui reversée au constructeur du téléphone. Ainsi, Microsoft ne gagne en moyenne que $10 par smartphone Nokia Lumia vendu.

Une meilleure maîtrise de la chaîne de fabrication permet à Microsoft d’espérer un accroissement de sa rentabilité, pour atteindre $40 par smartphone vendu. Cette marge accrue devrait permettre d’investir massivement dans la plateforme (marketing, R&D, soutien aux développeurs). Par cette opération, Microsoft ambitionne de quasiment quadrupler sa part de marché, de 4% à 15% d’ici 2018.

Le rachat permettrait d’évoluer vers une plus grande souplesse opérationnelle pour les deux partenaires. Le partenariat signé en 2011, a pâti d’un grand nombre de frictions. D’une part, les deux entreprises avaient le difficile challenge de faire cohabiter des équipes aux prérogatives similaires, mais aux organisations et modes de travail différents. D’autre part, elles devaient promouvoir et faire vivre 3 marques en parallèle : Microsoft, Nokia et Lumia.

Ainsi, la réunion des activités téléphonie des deux sociétés devrait permettre de dégager une plus grande flexibilité et réactivité pour répondre aux attentes du marché.

Un succès loin d’être garanti

Microsoft n’ayant jamais été un bon fabriquant de hardware, cette acquisition s’avère être un défi pour le groupe. En effet, le Zune, le Kin, la tablette Surface RT sont autant d’initiatives et autant d’échecs de Microsoft dans le hardware. Seule la Xbox rencontra un succès public, sans empêcher toutefois une perte de $3 milliards en 10 ans !

De même, ne comptant que 3,6% de parts de marché, Windows Phone reste très loin derrière Android et Apple, qui se partagent respectivement 69% et 16% des parts de marché mondiales des smartphones.

La capacité d’accroître ses parts sur le marché du mobile est en grande partie dépendante de l’attractivité de la plateforme pour les développeurs. Il faudra par conséquent à Microsoft beaucoup d’énergie pour les convaincre d’investir dans une plateforme représentant aujourd’hui moins de 4% de parts de marché dans le monde.

La troisième plateforme mobile n’est peut-être pas celle que l’on imagine

Microsoft  souhaite se positionner durablement en alternative à Android et Apple, mais sa place pourrait lui être ravie par un acteur particulièrement agressif et immensément riche : Amazon.

Depuis plusieurs années, Amazon prépare en effet un smartphone basé sur une version d’Android  dépourvue de tout service Google. Cette plateforme a de fortes chances d’être une concurrence de poids pour Microsoft, d’autant qu’Amazon ($61 milliards en 2012) n’a pas pour objectif de tirer des bénéfices directement de ses smartphones, mais plutôt de favoriser les achats en ligne de ses marchandises, réelles ou virtuelles, quitte à vendre, à perte, un smartphone de qualité pour un prix très compétitif.

Cet article Pourquoi Microsoft rachète les smartphones Nokia est apparu en premier sur RiskInsight.

Après 9 mois d’existence, force est de constater que Windows 8 peine à convaincre le grand public. Pour les grands comptes, l’arrivée de Windows 8 suscite des réactions diverses.

Pour ceux qui n’ont pas encore fait le pas vers Windows 7, l’éventualité d’un passage vers Windows 8 a été écartée. Les raisons de ce rejet tiennent en deux points majeurs. D’une part, des surcoûts sont induits par la nouvelle interface utilisateur ModernUI, déroutante et nécessitant une conduite du changement renforcée. D’autre part, l’absence de support de la part des éditeurs et la faible visibilité sur sa mise en place génèrent un risque important pour la bonne tenue du planning.

Quant aux Grands Comptes ayant déjà déployé Windows 7 (ou qui sont en train de le faire), la plupart choisissent d’expérimenter Windows 8 auprès de populations nomades, majoritairement des profils commerciaux, en vue de les doter d’un terminal unique couvrant à la fois les usages de type poste de travail et tablettes (matériel dit « transformable »).

En effet, l’intérêt majeur de Windows 8 concerne le développement des usages mobiles et tactiles. Pour autant, si la DSI est enthousiaste à l’idée de gérer son parc de PC et tablettes de façon unifiée, la réaction des utilisateurs est quant à elle plus mitigée : en effet, les tablettes Windows 8 Pro restent encore à l’heure actuelle nettement plus lourdes que des matériels équivalents sous iOS ou Androïd.

Au final, les grands comptes ne se sont pas empressés pour adopter Windows 8. A l’heure où nombre d’entre eux accélèrent leurs chantiers de migration vers Windows 7 pressés par l’échéance de fin de support de Windows XP, seuls quelques-uns envisagent un déploiement tactique de transformables Windows 8 sur des populations ciblées.

Windows 8.1 : trois pas en arrière, un pas en avant

Fort de ce constat, Microsoft revient avec une nouvelle version : Windows 8.1. Cette version est marquée avant tout par une vraie remise en question des choix ergonomiques de Windows 8 : le bouton « Démarrer » est de retour, il est possible de démarrer directement sur le bureau et plus généralement de se passer complètement de l’interface ModernUI ! Il devient ainsi possible de « brider » le terminal pour lui donner une ergonomie beaucoup plus proche de Windows 7.

Les apports fonctionnels sont – quant à eux – plus mesurés. À noter toutefois la fonctionnalité de Workplace Join qui permet à un collaborateur d’intégrer ses devices personnels (smartphone et poste de travail) au SI de l’entreprise. Une fois joint, le device est reconnu en tant que périphérique personnel et peut se voir attribuer des accès aux applications de l’entreprise. De plus, il est possible de  synchroniser du contenu professionnel (Work Folders) directement sur le device personnel. Les données sont marquées comme étant du contenu professionnel, via une gestion des droits numériques (type DRM), et peuvent être effacées à distance par un administrateur.

Avec Windows 8.1, Microsoft cherche donc avant tout à répondre en urgence aux inquiétudes des grandes comptes déroutés par ModernUI. Et en cela Windows 8.1 atteint son but. Reste la problématique du support des applications et le form factor peu avantageux des matériels Windows 8 : sur ces 2 points, éditeurs et constructeurs progressent, et il est raisonnable de penser qu’à horizon d’un an, ces freins auront été levés.

Un nouveau cycle de vie…oui, mais lequel ?

Mais avec Windows 8.1, Microsoft inaugure aussi une nouvelle stratégie de mise à jour de son OS. Finis les services packs : Windows sera désormais revu complètement sur un rythme annuel.

Si l’intention de Microsoft est claire – aligner le rythme d’évolution de Windows sur celui des concurrents (Apple et Google) – la firme de Redmond n’a pour l’instant donné que peu d’éléments concrets permettant d’en appréhender l’impact sur l’organisation des DSI.

Or, cet impact pourrait être majeur. En effet les DSI ont jusqu’à présent fait évoluer leur parc de poste de travail par paliers (migration de Windows 2000 vers XP, de XP vers 7) opérés à l’occasion de migrations majeures tous les 6 à 7 ans et nécessitant des chantiers très lourds de design, d’inventaires, et de mise en compatibilité du parc applicatif.

Les DSI devront-elles demain être capables de conduire ces chantiers en continu ? Et donc pérenniser des activités qui aujourd’hui sont menées en mode projet ? Pourront-elles maîtriser le cycle de vie de leur OS ? Ou seront-elles « forcées » à suivre le nouveau rythme imposé par Microsoft ?

Là encore, les grands comptes s’inquiètent… et attendent de Microsoft des réponses claires avant de s’engager plus loin. Un point c’est tout.

[Article écrit en collaboration avec Arthur Georges, consultant]

Cet article Windows 8.1 : un point c’est tout ? est apparu en premier sur RiskInsight.

 Un outil collaboratif améliorant la productivité et l’efficacité des équipes

L’utilisation de Lync répond en premier lieu à un besoin utilisateur : il leur permet en effet de retrouver les fonctionnalités dont ils disposent dans leur environnement privé. Au-delà de satisfaire ce besoin, l’outil permet une amélioration de la productivité au quotidien.

Cette solution collaborative, qui s’intègre nativement avec l’écosystème Microsoft (Active Directory, Exchange…),  offre des fonctionnalités de messagerie instantanée, de partage d’écran et d’applications, très simples à utiliser, et disponibles via un seul et même outil.

Le chat, au contraire du mail, est un outil synchrone permettant des échanges rapides et adaptés à des situations moins formelles, alors que le statut présentiel permet de visualiser si le contact recherché est disponible à cet instant. Les fonctionnalités de partage d’écran, d’application, ou de tableau blanc rendent plus efficaces les discussions téléphoniques, quand un simple clic permet d’afficher le contenu visualisé par le correspondant, et d’interagir avec lui. Il est également possible pour des collaborateurs à distance de suivre en direct le déroulement d’une présentation menée par l’animateur depuis son poste. Lync Web App permet  au présentateur de réaliser ce partage avec des collaborateurs externes à l’entreprise ou ne disposant de compte ou de client Lync. Avec la version 2013, et le module Office Web Apps, le partage est rendu disponible sur de nombreux appareils mobiles.

Si l’utilisation de ces fonctionnalités est très simple au quotidien, il ne faut toutefois pas négliger la communication et l’accompagnement du changement, qui est une clé essentielle pour obtenir l’adhésion des utilisateurs.

Une solution de communication génératrice d’économies ?

Une partie des entreprises se tournent vers Lync à des fins de réduction de coûts, notamment les frais de déplacements et de téléphonie. En effet, Lync, grâce à la VoIP, permet de réaliser des communications audio et vidéo, avec une ou plusieurs personnes, évitant par exemple à des collaborateurs d’une entreprise internationale de se déplacer.

Toutefois, pour assurer le bon fonctionnement de ce type de communications, le facteur clé est la bande passante qui leur est allouée. Le débit nécessaire est à calculer en fonction des besoins et usages auxquels on souhaite répondre à l’aide d’abaques officiels. Il sera éventuellement nécessaire de procéder à l’augmentation de cette capacité, pouvant donc générer des coûts récurrents supplémentaires. Pour limiter les débits engendrés, il existe une solution de bridage dans la console d’administration, la CAC (Call Admission Control). Il reste recommandé de préférer à son utilisation une augmentation des capacités réseau, sous peine de voir les appels utilisateurs fréquemment refusés, poussant ces derniers à délaisser Lync pour des appels téléphoniques.

Trois solutions d’implémentation de la solution existent : on premise, dans le Cloud, ou de manière hybride (combinaison des deux modes précédents). Certaines sociétés font le choix du Cloud avec Lync Online, afin  de réduire les coûts d’infrastructure. Cette alternative leur apporte une certaine souplesse d’administration, et facilite également les migrations vers des versions supérieures, qui permettent d’intégrer rapidement les innovations. Des calculs de ROI standards existent, mais restent à projeter sur des contextes techniques et contractuels propres à chaque entreprise. Nombre d’entre elles préfèrent néanmoins garder la maîtrise de leur infrastructure.

 La solution collaborative Lync offre donc un large éventail de fonctionnalités répondant à un  besoin utilisateur, et permettant une augmentation de la productivité qui ne se mesure que de manière qualitative, et qui ne garantit pas une réduction des coûts IT. Comparé à d’autres solutions plus traditionnelles de salles de conférence, Lync apporte souplesse d’utilisation et facilité d’intégration. Néanmoins, cette solution implique une conduite du changement et une intégration de ce nouveau service dans un environnement déjà existant, et donc des contraintes d’architecture à ne pas sous-estimer.

Cet article Lync : un levier de productivité et d’économie en entreprise ? est apparu en premier sur RiskInsight.

Cet article L’actualité IT commentée par Laurent Bellefin sur BFM Business est apparu en premier sur RiskInsight.

Dans la guerre qui met en concurrence Google et Microsoft dans le détrônement de l’Ipad, Google a opté pour une tablette low cost pour mettre en avant le contenu. Nous avons lors du premier épisode vu les forces et faiblesses de cette stratégie. Qu’en est-il de notre deuxième géant Microsoft ? Qui de de Google ou de Microsoft saura s’imposer ?

La convergence tablette – PC par Microsoft

Après le succès de la Xbox et l’échec cuisant du Zune, Surface marque le grand retour de Microsoft sur le secteur du matériel. Mais cette fois-ci, sa position est plus délicate puisqu’elle place l’entreprise en concurrence directe avec ses partenaires constructeurs. Même si Microsoft a annoncé que Surface serait avant tout une vitrine de promotion de Windows 8, visant à encourager son adoption au détriment d’Androïd, ses partenaires n’en demeurent pas moins inquiets

Avec Surface, Microsoft s’attaque au marché des tablettes sur deux segments différents. À travers la version ARM tout d’abord, la société espère concurrencer l’iPad auprès du grand public. De format similaire à ce dernier, elle embarque Windows RT et une multitude d’accessoires qui font défaut aux modèles de tablettes numériques actuels : port usb, lecteur de carte et grande capacité de stockage. Mais la nouveauté provient surtout du support intégré et de la TouchCover qui abrite clavier et pad : ainsi, la surface peut aussi bien être utilisée en format « tablette » que « PC ».

C’est ensuite le monde de l’entreprise qui est dans le viseur de Surface, à travers sa version x86. Dotée d’un port USB 3.0, et surtout d’un processeur de PC, elle embarquera Windows 8 Pro : de quoi se substituer à un ordinateur professionnel.

« Surface est un PC. Surface est une tablette » a dit Steve Ballmer, illustrant ce que Surface peut apporter à l’entreprise : la possibilité de fournir à ses utilisateurs un unique terminal bénéficiant des avantages des deux mondes : les applications pro, existantes dans l’entreprise pour l’un, la mobilité, l’image et l’expérience utilisateur pour l’autre. Mais au-delà de cette nouvelle approche, il faudra également compter sur l’écosystème riche de Microsoft, où la convergence peut aller encore plus loin : Pourquoi en effet ne pas envisager de commencer un jeu sur Xbox et de le continuer sur sa tablette ou son PC ?  Ou encore, de basculer l’exécution d’une application pro de son PC vers sa tablette ou son smartphone, le tout grâce aux services cloud SkyDrive ? Ces scénarios pourraient réellement fédérer les utilisateurs et apporter de l’innovation par rapport aux usages actuels.

Hélas, c’est là également que se situe son talon d’Achille, car cet écosystème n’est pas encore équipé d’applications tablettes. Car si Windows 8 Pro permet de conserver ses applications historiques, Windows RT part de zéro : Microsoft devra être persuasifs pour séduire les développeurs et obtenir rapidement du contenu et faire face à un concurrent fort de plus de 250 000 applications pour Ipad.

Autre point faible de la tablette Microsoft, son prix. Une tablette Surface 32 Go coûtera 489 euros TTC, soit 100 euros de moins que son équivalent Apple. A cela, s’ajoute le prix de la « Touch Cover » qui culmine à plus de 100 euros. Avec un tel positionnement tarifaire  il sera difficile pour Microsoft de justifier la pauvreté de services disponibles sur sa tablette Surface en comparaison de ceux disponibles sous iOS ou Androïd.

Microsoft n’a toujours pas divulgué le prix de la version Surface x86. Mais si ce prix se place au-delà des 800€, comme annoncé par certains constructeurs, sur quoi se portera le choix des utilisateurs (et des entreprises !) entre une tablette Surface, un Sony Vaio ou un Mac Book Air haut de gamme ? Vu sous un autre angle, les utilisateurs seront-ils prêts à investir 200 à 400€ de plus pour transformer leur PC en tablette, à performances égales ?

Une actualité à suivre de près…

De nombreuses questions restent donc ouvertes, et les prochaines annonces des constructeurs seront très attendues. Quel sera le positionnement tarifaire des Surfaces x86 ? Quel sera celui de l’iPad 7″, annoncé en octobre, par rapport à la Nexus 7 ?

Si Microsoft mise sur la convergence séduisante entre tablette et PC, qui pourrait être fort appréciée du côté des entreprises, cela reste porté par l’OS. La douce évolution du monde applicatif vers une indépendance vis-à-vis des OS pourrait-il faire pencher la balance du côté de Google, qui mise plutôt sur ses services en ligne ? Il faudra vraisemblablement attendre la fin d’année pour voir quelle stratégie a payé et qui est en mesure de croquer dans la pomme.

Pour lire la première partie, cliquez ici.

Cet article Microsoft Vs Google : qui pour détrôner l’iPad ? (2ème épisode) est apparu en premier sur RiskInsight.

Construit sous l’impulsion d’Apple, le marché des tablettes numériques est aujourd’hui scindé en deux : l’historique Apple et son iPad d’un côté, Google et ses multiples constructeurs de l’autre.

Dans ce duel de titans, quels sont les terrains d’affrontement ? Et surtout, qui aura le dernier mot ?

Un marché bipolaire

L’affrontement qui oppose Apple à ses rivaux ne se joue pas sur le terrain du matériel, où l’iPad règne en maître à près de 50 points devant son premier concurrent.  L’affrontement se joue sur le système d’exploitation, où iOS culmine à 57,6% de parts de marché, contre un Androïd en-dessous de la barre des 40%.

Face à la main mise d’Apple, deux autres géants de l’informatique veulent eux aussi tenter la stratégie du « big Apple » – un contenant maîtrisé et un écosystème solide :

• Google, leader du marché OS sur smartphones avec Androïd et principal concurrent d’Apple sur les tablettes, lance une tablette à son nom, en partenariat avec le constructeur Asus. La Nexus 7, au format novateur de 7″, adresse un nouveau marché avec un prix d’entrée très agressif.
• Microsoft, leader incontesté du marché OS sur PC, lance une tablette de sa propre fabrication. La Surface sera déclinée sous 2 versions : une version ARM tournée vers le grand public, concurrente directe de l’iPad, et une version x86 plutôt tournée vers le monde professionnel.

Une stratégie  low-cost pour permettre à tous l’accès aux services Google

Pour moins de 200$, Google casse les prix du marché, en proposant une tablette aux caractéristiques plutôt « correctes » : processeur Tegra 3, 1 Go de RAM, une résolution de 1280×800 et une autonomie de plus de  9h en lecture vidéo HD. Ses accessoires sont en revanche assez réduits car elle n’intègre pas de caméra au dos, ni de sortie vidéo ou encore de lecteur de carte. Toutefois, la Nexus 7 se distingue par une bonne connectivité avec Wifi, Bluetooth et NFC.

L’objectif annoncé de ce nouveau produit est avant tout de mettre en avant le contenu, les bénéfices de la firme sur la vente de la tablette étant réduits au maximum afin de permettre à toutes les bourses l’accès aux services Google. Son format « livre », 7 pouces pour 340g, devrait d’ailleurs permettre le lancement du service ebook de la marque dans les meilleures conditions.

À travers la Nexus 7, Google veut donc s’assurer de la mise en avant de ses propres services en ligne et éviter ainsi qu’elle ne soit qu’une passerelle vers internet et les multiples offres concurrentes. Mais au-delà de la promotion de services, la tablette pourrait bien avoir un impact sur les prix du marché, incitant les autres constructeurs à réduire leurs marges pour rester dans la course.

Que serait alors la stratégie d’Apple, qui se positionne sur un marché « haut de gamme et pratique aujourd’hui près de 40% de marge sur ses produits ?

Peut-on s’attendre à voir évoluer le marché des tablettes vers celui du PC : de forts volumes mais de faibles marges unitaires ?

La réponse dépendra fortement du succès rencontré par le nouveau-né de Google. Si la version 16 Go est déjà en rupture de stock, moins d’un mois après sa sortie, c’est à plus long terme qu’il faudra l’étudier, afin de s’affranchir de l’effet d’annonce. Car si les tablettes Androïd sont encore loin derrière l’iPad c’est en partie à cause de leur faiblesse en contenus et applications dédiées disponibles. C’est sur ce point-là que Google sera attendu : hormis la taille de l’écran, il faudra justifier la valeur ajoutée d’une tablette 7″ par rapport à un smartphone, que l’utilisateur possède généralement déjà.

Mais si  Google doit encore faire ses preuves, qu’en est-il de Microsoft ? C’est ce que nous verrons lors du prochain épisode…

Pour lire la suite, cliquez ici.

Cet article Microsoft vs Google : qui pour détrôner l’iPad ? (1er épisode) est apparu en premier sur RiskInsight.

Après l’énorme campagne de communication déployée par Microsoft depuis quelques mois sur la nouvelle version de l’OS (Operating System) le plus répandu au monde, la sortie de la Consumer Preview de Windows 8 (le 19 février dernier) permet d’en apprécier les nouveautés et d’alimenter le débat sur toutes les problématiques posées par cette nouvelle mouture. Un changement stratégique et ergonomique, annoncé comme le plus important depuis l’avènement de Windows 95.

Pour l’utilisateur, les nouveautés sont de taille, et la plus marquante est certainement la coexistence de deux interfaces : le « Bureau », similaire à Windows 7, et « Metro », orientée vers un usage tactile, pour le web et les applications. Et c’est l’arrivée de Metro qui aujourd’hui fait débat, par le changement qu’il implique dans la manière d’utiliser son poste.

En effet, la suppression du bouton Windows et la philosophie d’utilisation « tablette » vont certainement surprendre la majorité des utilisateurs et la prise en main risque de prendre un certain temps. Et si cette interface a été pensée pour faciliter la consommation d’informations, usage majeur dans la sphère privée, sera-t-elle pour autant adaptée à la production de contenus en entreprise ? Toujours est-il que, malgré l’aide que pourra apporter la généralisation de l’OS dans le monde grand public, toute apparition de Metro en entreprise nécessitera une importante conduite du changement, dont l’ampleur sera fonction de la politique adoptée par l’entreprise (promotion, autorisation ou blocage de l’interface).

Quels changements pour l’entreprise ?

Outre une nouvelle interface, avec Metro arrive aussi une nouvelle génération d’applications, basées sur un nouveau framework (WinRT) et destinées au monde tactile.

En effet, si les applications compatibles Windows 7 devraient également l’être pour le « Bureau » de Windows 8, il sera nécessaire de les repenser entièrement pour les adapter à l’interface Metro. Et si Microsoft a voulu proposer un OS véloce, c’est au détriment de certaines fonctionnalités, comme le non support d’add-ons sur la version Metro d’internet explorer. Cette adaptation, dans laquelle l’entreprise se trouvera confrontée à l’introduction du HTML 5, pourrait constituer un chantier supplémentaire après la difficile migration des applications de XP vers Windows 7. Concernant les éditeurs, très peu d’éléments ont été rendus publics sur leur stratégie, mais ils vont vraisemblablement devoir s’adapter et proposer une version pour chaque « monde ». Parallèlement, le développement vers Metro est aujourd’hui encore très peu documenté.

Mais au-delà de Metro, on retrouve également une meilleure intégration des solutions de connectivité (Wi-Fi Direct, NFC, USB 3.0…), une gestion native du cloud (Microsoft) et de la virtualisation, ainsi qu’une optimisation des performances permettant notamment un démarrage en 8 secondes. On peut noter quelques innovations comme « Windows To Go », permettant d’avoir une version personnalisée et exécutable de l’OS sur une clé USB, et une migration annoncée « transparente pour l’utilisateur » depuis Windows 7. Mais la force majeure de Windows 8 est de proposer un OS unique pour PC et tablettes (et très similaire pour smartphones), à l’heure où l’augmentation des tablettes est inéluctable dans le SI des entreprises (forces de vente, commerciaux, relation client…).

De par son approche moderniste et sa présence en standard sur de nombreux matériels neufs, Windows 8 devrait progresser rapidement sur le marché grand public. Le tout est maintenant de savoir ce qu’il va en être de son adoption par les entreprises. Après l’échec de Vista et le succès toujours grandissant de Windows 7, la version 8 va-t-elle respecter la règle de « une version performante sur deux » généralement constatée au sein des grandes entreprises ?

L’approche « user-centric », une grande nouveauté Microsoft

L’objectif de Windows 8 est également de replacer l’utilisateur au centre de l’environnement de travail. Il lui permettra de retrouver son environnement personnalisé et ses données sur n’importe quel poste grâce à SkyDrive[1], et de télécharger ses applications favorites via la boutique en ligne Windows Store. Tout ceci à travers l’utilisation de son compte personnel Windows Live. Une façon de rassembler les services en ligne Microsoft autour de l’utilisateur, et de normaliser leur usage. En d’autres termes, Microsoft réinvente l’Apple world.

Cette approche « user-centric » pourra nécessiter la revue des modalités d’intégration des machines au sein d’un SI d’entreprise, de par la nécessité de s’authentifier avec un compte personnel. Faudrait-il alors considérer les terminaux Windows 8 comme forme de BYOD[2] ?

Une actualité à suivre de près

De nombreuses questions restent donc ouvertes, et vont encore faire débat dans les mois qui viennent au fil des annonces de Microsoft et des autres grands acteurs. Faut-il migrer vers Windows 8 ? Est-il préférable de migrer au fil de l’eau ou de mettre toutes les applis en conformité Metro avant de migrer ?

À l’heure où les annonces et les spéculations vont bon train, il faudra suivre de près les débats publics d’un côté et les réflexions stratégiques des entreprises de l’autre, afin de savoir qui sera dans le wagon de tête pour migrer vers Metro.

Cet article Windows 8 – Metro, boulot, perso ? est apparu en premier sur RiskInsight.