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 plupart des entreprises ont démarré un projet de migration afin de gérer l’obsolescence des composants XP, tant au niveau du système d’exploitation que des outils fournis aux utilisateurs (navigateur internet, suite bureautique, etc.), mais aussi pour améliorer leur attractivité et l’image de leur DSI. Ce type de projet doit également être un levier de réduction du TCO (Total Cost of Ownership) du poste de travail.

Compte tenu des enjeux économiques et de support, il faut noter une forte volonté de réduire au maximum le nombre de postes fonctionnant sous Windows XP d’ici avril 2014. Néanmoins, il peut être envisageable qu’une partie du parc soit maintenue sous cet OS. Selon la quantité de postes restant à migrer après avril 2014, une négociation avec Microsoft peut en effet être envisagée afin de bénéficier d’une extension de support. Mais les risques induits ne sont pas à négliger : risques opérationnels dus à des applications potentiellement non compatibles, risques techniques dus à des pilotes matériels qui ne sont plus pris en charge, risques liés à la sécurité des postes, etc. Il est donc préférable de réduire au maximum le nombre de postes sous Windows XP, afin d’éviter notamment des coûts liés à une double administration d’OS.

Une industrialisation du processus de déploiement au service de la migration

L’industrialisation du processus de déploiement doit permettre d’optimiser au maximum la migration tout en la sécurisant. Pour cela, les choix d’architecture réalisés en amont devront être pensés de façon à minimiser les impacts éventuels sur la migration, tout en assurant la reprise des données. Il est en effet impératif d’assurer la sauvegarde de certaines données utilisateurs. Se baser sur les outils de sauvegarde existants ou sur les outillages de synchronisation de données pourra faciliter la démarche. Certaines entreprises font le choix de laisser la responsabilité à l’utilisateur. Il est alors chargé de récupérer et stocker ses données avant la migration de son poste, puis de les restaurer une fois la migration effectuée.

À moins d’un an de la fin de support XP, la stratégie de déploiement doit désormais être pensée de façon à optimiser les délais et les coûts. Plusieurs types de scénarios peuvent être considérés, d’une gestion manuelle à l’utilisation d’outils et de technologies d’automatisation. La migration « au fil de l’eau », basée sur le renouvellement du matériel, peut être un levier simple à mettre en place. Cette stratégie est généralement complétée par un projet de migration compte tenu des échéances.

Au vu des délais de moins en moins flexibles, il faudra si possible capitaliser au maximum sur les outils de télédistribution déjà implémentés au sein de l’entreprise. Pour les parcs informatiques importants, se baser sur les infrastructures existantes, permettra d’industrialiser le déploiement, tout en faisant baisser le TCO du poste de travail, notamment sur les aspects de gestion courante, comme la remasterisation et le renouvellement du poste.

L’industrialisation du déploiement se base également sur un inventaire détaillé des utilisateurs et des machines, la planification des rendez-vous avec les utilisateurs, le suivi du déploiement via des outils de reporting, le provisioning et la masterisation des postes. Il faudra veiller à définir le type de support apporté aux utilisateurs durant la migration, tout en mettant en place une véritable conduite du changement, à adapter aux profils plus ou moins technophiles, à leur localisation par plaque régionale pour un ajustement à la culture locale, à leur mobilité, à leur statut dans l’entreprise et de façon plus générale à la culture d’entreprise.

Piloter les inventaires, qualifications et remédiations applicatives

La gestion des applications et de leur compatibilité avec le futur système d’exploitation est un autre levier important pour sécuriser le désengagement de Windows XP et son déploiement.

En premier lieu, il est important d’identifier les applications critiques avec un fort impact business. La qualification de ces applications permettra de mettre en évidence et d’anticiper les éventuelles incompatibilités logicielles de façon proactive. Celles-ci devront alors faire l’objet d’une remédiation pour les adapter au système d’exploitation cible. Le déploiement devra être bloqué tant que ces incompatibilités n’auront pas été remédiées. En se basant sur le statut éditeur ou en réalisant des tests fonctionnels, plusieurs méthodes permettent d’évaluer la compatibilité des applications vers l’OS cible. Les applications web par exemple, devront généralement être redéveloppées, de même que les macros Excel et les développements VBA.

La virtualisation d’applications présente alors un intérêt fort en tant que solution de contournement. Cette technologie va permettre de supprimer les adhérences de l’application avec le système d’exploitation, en créant une bulle applicative où elle s’exécutera. Utiliser la virtualisation d’application pour faire de la remédiation reste toutefois un détournement de la solution et n’offre aucune garantie. D’un point de vue fonctionnel, la virtualisation peut effectivement permettre une montée de version de l’application, car indépendante de l’OS. Mais d’un point de vue technique, cela ne doit être envisagé qu’en tant que solution palliative court-terme. La virtualisation d’application, MED-V ou Citrix ne sont en aucun cas des solutions définitives. Pour faciliter l’étape de remédiation, il est ainsi conseillé de mettre à disposition des métiers des processus de remédiation standards, tout en industrialisant et en pilotant les travaux de ce chantier de packaging applicatif.

Idéalement, ces étapes permettront de participer à la rationalisation du portefeuille applicatif en éliminant notamment quelques logiciels non utilisés ou en doublons. La connaissance fine du parc applicatif étant généralement trop faible, il est illusoire de penser pouvoir traiter simultanément déploiement du poste de travail et rationalisation profonde du parc applicatif. Pour les contextes les plus matures, la gestion de portefeuille applicatif est légèrement enrichie et la mise en œuvre d’une solution de self-service est réalisée. Cette stratégie de shift-left visant à apporter un maximum d’autonomie à l’utilisateur sur les activités de gestion du poste à faible valeur-ajoutée, peut constituer un levier important de réduction du TCO des postes.

Il s’agit d’un chantier long et laborieux à anticiper, la meilleure solution étant de définir des processus récurrents, afin de suivre les mises à jour logicielles de façon optimale. Il faudra pour cela veiller à identifier les couches métier impactées et intégrer ces processus avec les plannings de migration, afin de lisser le déploiement selon les Métiers. Mais cela nécessite l’implémentation d’une vraie gouvernance et un bon niveau de maturité sur la gestion applicative et de leurs composants, ainsi que sur la gestion des licences.

Quoiqu’il en soit, lancer un projet de migration suscite bien des remises en question ! Elle permet de réviser les règles de sécurité déjà implémentées pour mieux les adapter au contexte de l’entreprise. Mais c’est aussi par exemple l’occasion d’adapter les services aux nouveaux usages, tout en réduisant le TCO des postes et en favorisant la flexibilité des services fournis aux utilisateurs, via par exemple des outils modernes de self-service du type application store. Un projet riche sur bien des plans donc.

Cet article Obsolescence programmée : comment réussir le passage à un nouvel environnement de travail ? est apparu en premier sur RiskInsight.

Pourquoi et comment adopter le Zero Touch ?

Le choix d’une stratégie de déploiement se fait en premier lieu en fonction du nombre de postes concernés. Un parc informatique composé de quelques dizaines de postes impliquera une action manuelle, là où un parc plus conséquent nécessitera l’automatisation de tout ou partie de ce processus. Les solutions d’automatisation permettent de limiter, voire de supprimer totalement les interactions avec les utilisateurs pendant la phase de déploiement. Cela induit une industrialisation du processus – via une action de nuit sans interaction humaine – et par là-même une réduction des coûts de support.

Mais comment y aller ? En réalité, le choix du déploiement Zero Touch (déploiement automatisé) implique le plus souvent la création d’un « master » (ou socle) unique et modulaire. Ce master doit comporter l’ensemble des composants qui seront distribués et installés sur le poste (OS, pilotes de périphériques, base applicative commune…). Ces éléments peuvent être structurés par couches permettant justement ce découpage modulaire en fonction de variables d’environnements collectées en amont du processus ou lors de la phase de déploiement (le modèle de poste, la langue cible, les usages métiers etc.).

Les avantages du master modulaire

Une stratégie de master unique et modulaire permet de se détacher des contraintes liées à la dépendance matérielle. Le tronc commun des composants peut ainsi être entièrement dissocié des éléments spécifiques au poste.

Sur le long terme, cela permet aussi une forte évolutivité et un meilleur support des modifications du master. Par exemple, l’ajout d’un nouveau modèle supporté nécessite beaucoup moins de d’actions. Il suffit d’intégrer les spécificités matérielles (pilotes de périphériques) au master existant, plutôt que de le recréer dans sa totalité.

Par ailleurs, le packaging applicatif unifié est un autre avantage non négligeable inhérent au choix de master unique. En effet, on utilise la même méthode de packaging pour la conception du master que pour la télédistribution d’une application sur un poste préalablement déployé. Cela permet une rationalisation des éléments constituants le master, et ainsi d’en faciliter l’exploitation, le support et la maîtrise dans le temps.

Le Zero Touch, une source d’économies potentielles

Lorsqu’une entreprise répond aux critères permettant l’emploi d’une stratégie Zero Touch, elle peut envisager, comme nous l’avons vu précédemment, de réaliser des économies significatives sur les phases de déploiement et de post-déploiement :

• La réduction d’interactions humaines en bout de chaîne permet de limiter les coûts unitaires liés au déploiement d’un poste.
• La configuration cible unique sur l’ensemble du parc permet de réduire les risques d’incompatibilité. Cela se traduit par une limitation des coûts d’assistance post-déploiement ainsi que les coûts de maîtrise de parc.
• Sur le long terme, la cellule de gestion du parc peut s’appuyer sur le master modulaire pour réaliser ses actions récurrentes (telles que la montée de version applicatives, télédistribution de nouvelles applications, l’intégration et le support de nouveaux matériels …) et réduire significativement les durées associées.

« Tout le monde ne peut pas faire du Zero Touch ! »

Si le Zero Touch peut sembler la solution miracle, il a pourtant certaines contraintes qu’il parait important de rappeler :

• L’infrastructure requise pour mettre en place ce type de stratégie est conséquente. Seules les grandes entreprises peuvent en réalité l’adopter. L’infrastructure réseau doit notamment pouvoir supporter le transit d’images système lourdes.
• La construction de ce type de master ainsi que la conception de l’infrastructure implique un niveau de compétence élevé. Ce niveau d’expertise est rarement trouvé en interne.
• Le déploiement sans interaction humaine nécessite de récolter les informations relatives aux utilisateurs cibles en amont du déploiement. Ce recueil d’informations représente un travail conséquent. La constitution d’une cartographie organisationnelle de l’entreprise doit permettre de définir les éléments modulaires à déployer ainsi que les variables d’attributions sur une échelle macroscopique.

Windows 8, tremplin vers de nouvelles opportunités ?

Si le déploiement reste sensiblement le même avec Windows 8, la dernière mouture du système d’exploitation de Microsoft n’est pas en reste sur les actions post-déploiement. L’écosystème offre en effet de nouvelles possibilités intéressantes concernant la télédistribution d’applications.

La  télédistribution d’applications peut actuellement se faire par deux biais : le déploiement d’une base applicative lors de l’installation du nouveau système et la télédistribution à l’initiative des équipes IT post-déploiement. L’écosystème Windows 8 vient proposer un troisième vecteur : la télédistribution à l’initiative de l’utilisateur. En effet, Windows 8 propose nativement un « Store applicatif ». Celui-ci peut être rendu inaccessible par la plupart des réseaux d’entreprises mais la DSI peut choisir de proposer par substitution son propre « Store d’entreprise ».

Ce portail permet de distribuer 4 types de ressources logicielles :

• Les applications « Metro » développées en interne et non publiées dans le « Windows Store » classique.
• Les logiciels qui sont distribués sous licence en interne dans l’organisation.
• Les web-applications, lancées directement via le navigateur.
• Des liens vers les applications autorisées du « Windows Store ». Ceci permet d’informer les utilisateurs d’applications utiles autorisées par l’entreprise.

Dans ce contexte, le rôle de la DSI évolue. Elle doit désormais gérer la notion d’approbation pour la gestion des licences ainsi que les droits d’attributions des applications sur l’ensemble de son parc.

Cet article Zero Touch : une migration bénéfique ? est apparu en premier sur RiskInsight.