Bon, maintenant que j’ai Office 365, je fais quoi ? Partie 2

Office 365

Avant toute chose, il convient de définir la gouvernance. D’après la définition de Microsoft, il s’agit de « l’ensemble des stratégies, rôles, responsabilités et processus permettant de contrôler la façon dont les services commerciaux et les équipes informatiques d’une organisation collaborent pour réaliser leurs objectifs ». Cela couvre donc… tous les sujets ! et évidemment, tous les sujets ne peuvent pas être couverts de la même manière. (Redécouvrez la Partie 1 de la série)

Pour ma part, j’ai identifié quatre niveaux de gouvernance. Lorsque je les présente, je pars d’une gouvernance version 0 ou 0.x qui utilise les outils standard d’Office 365 pour arriver à une gouvernance version 3.0, résolument prédictive, qui ne tirera pas grand-chose des outils fournis par défaut.

Au niveau 1 (ou aussi gouvernance version « 0.x »), je définis un mode de gouvernance qui s’appuie sur les outils standard (portail d’administration, centrale d’administration SharePoint ou menu site settings) ; ou bien sur un ou plusieurs outils ou scripts destinés à des tâches très spécifiques. Ce mode de gouvernance est contraignant principalement sur deux points : la gestion de la supportabilité doit être continue pour suivre les mises à jour d’Office 365, et la charge de maintenance associée nécessite des compétences rares (scripting / développement et maîtrise d’Office 365). Dans ce mode de gouvernance, le travail est réactif. C’est le cas typique du helpdesk.

Au niveau 2 (gouvernance version « 1 »), je définis un mode de gouvernance qui s’appuie sur une plateforme regroupant plusieurs outils, intégrés ou non. Cette plateforme doit permettre de planifier des tâches récurrentes et le reporting associé, ainsi que d’automatiser la réponse à des opérations non autorisées (mais qui restent possibles parce que certains utilisateurs en ont la permission technique). Ce mode de gouvernance garantit la cohérence de la plateforme par une gestion automatique de la configuration, et permet de supprimer des opérations de maintenance répétitives.

Au niveau 3 (gouvernance version « 2.0 »), je définis un mode de gouvernance qui permet de réduire le niveau de permissions techniques des utilisateurs, en les transformant en permissions fonctionnelles (administrateur de site SharePoint par exemple, dont les permissions en contrôle total seraient abaissées à de la simple contribution). Il s’appuie sur une offre de services pour offrir aux utilisateurs une palette d’actions administratives. Ces services sont configurés et maintenus par l’IT pour garantir la cohérence de la plateforme.

Au niveau 4 (gouvernance version « 3.0 »), je définis un mode de gouvernance qui doit permettre de répondre à des menaces identifiées mais aléatoire. Par exemple, automatiser le traitement de la sécurité : l’information est-elle où elle est censée être ? Visible de ceux qui ont le droit de la voir ? quelle réponse apportée si ce n’est pas le cas ? Dans un contexte hybride, assurer le cloisonnement des données onpremises vs. Online. La sécurisation des OneDrive est également un sujet qui peut être traité par ce biais.

Cette présentation des quatre niveaux de gouvernance faite, posez-vous les questions suivantes :

• à quel niveau de gouvernance vous situez-vous ?
• quel niveau souhaiteriez-vous implémenter ?

Une fois la réponse établie, la question reste de savoir comment mettre en place votre plan de gouvernance. Je me souviens d’un rendez-vous client pendant lequel ce dernier évoque le retard pris dans le projet d’ouverture de Office 365. Pour des tergiversations internes essentiellement, mais qui ont fait prendre deux ans de retard au projet. Pendant ce laps de temps, l’équipe initiale de quatre personne a été réduite à une seule, devant moi, me disant que « oui, ce que vous me dites est très vrai, mais je suis seul à gérer la plateforme et 100% de mon temps est passé à faire du support et des corrections d’environnement ». Je lui ai donc proposé une approche en deux phases.

Phase 1 : (re)prendre le contrôle de votre environnement

Selon le contexte, la première chose à faire est de prendre (nouvelle plateforme) ou reprendre (plateforme existante) le contrôle de votre environnement.

Le but de cette opération est de vous libérer du temps. Parce que si le temps – ou les ressources – manque, alors vous ne pourrez simplement pas faire autre chose que travailler en réaction.

Une approche intéressante pour organiser les priorités peut être de lister les demandes au support et les classer selon deux critères qui vous sont propres. Par exemple, demandes techniques (backup, restauration, récupération de permissions) versus demandes fonctionnelles (provisionning, configuration d’intégrations SharePoint / Yammer / CRM, demandes d’accès) ; demandes chronophages versus demandes fréquentes ; etc.

Ensuite, adapter la réponse : automatique ou manuelle ? Réactive (dans le cas d’une criticité faible car pas de perte de données par exemple, ou si aucun risque de risque sécurité n’est identifié) ou proactive (empêcher une action dont le mode opératoire est connu) ? Pourquoi ne pas répondre par un catalogue de services ?

Cette dernière approche est intéressante car elle permet de verrouiller techniquement le niveau de permission des utilisateurs (par exemple, en faire de simples contributeurs sur SharePoint) et de créer des niveaux fonctionnels (par exemple, un administrateur de site) qui pourront exécuter des services tels que la création d’un site, la création d’un utilisateur Office 365 ou d’un groupe, etc.

Les services étant configurés par l’IT, vous avez via cette solution une option pour à la fois éviter d’avoir des utilisateurs avec des permissions techniques trop élevées mais qui peuvent néanmoins utiliser la plateforme et également une IT en contrôle sur l’environnement.

Quel que soit votre choix, commencez par implémenter une bonne solution plutôt qu’une solution « acceptable ».

Phase 2 : adopter une approche par objectif

Attention à la condition sine qua non : connaître les objectifs (ce qui n’est pas toujours le cas). Il arrive très souvent que ces derniers soient peu ou pas du tout expliqués, ce qui conduit à tourner en rond. Ou encore que les objectifs des uns ne soient pas ceux des autres.

Par exemple, on pourrait citer :

• D’un point de vue IT, la réduction du temps de gestion de la plateforme, pour permettre de dégager du temps à l’IT. Par ce biais, elle pourra se concentrer sur l’évolution des outils et proposer plus de services. Tout en en réduisant le coût d’administration et de maintenance
• D’un point de vue Métier, la simplification de l’utilisation de l’outil : moins d’options pour l’utilisateur final mais plus claires et adaptées à son métier. Ceci pour susciter l’adoption par exemple
• D’un point de vue sécurité, éviter la fuite d’information vers d’autres supports parce que les usages ne sont pas implémentés correctement, ou mettre en place des processus de gestion de la conformité ou de DLP.
• D’un point de vue économique, passer sur un mode « as a Service » dans lequel le coût d’une partie des fonctionnalités, standard, pourra être supporté par l’IT alors que des fonctionnalités plus avancées pourront être refacturées

Une fois les objectifs définis, il faut les placer dans un contexte temporel : ils sont des indicateurs d’un but à atteindre mais également des directives devant servir à orienter le SI vers une stratégie précise. Ils ne doivent donc pas être figés, mais revus régulièrement : quels seront vos besoins dans un voire deux ans ?

Admettons que votre objectif à l’ouverture d’Office 365 soit l’adoption de l’outil par les utilisateurs mais dans un contexte de sécurisation pour l’IT et le RSSI. On peut envisager dans ce cas la mise en place d’un catalogue de services, ce qui permet aux utilisateurs d’utiliser SharePoint, créer des groupes Yammer ou Office Groups, faire de l’intégration SharePoint Dynamics 365, tout en étant simples contributeurs sur la plateforme. Donc de façon très sécurisée pour l’IT.

Admettons également que l’adhésion soit forte et que de nombreux containers et de nombreuses synergies existent désormais sur votre Office 365. Un an après l’ouverture, quels seront vos objectifs de gouvernance ? L’adoption n’en est plus un, puisqu’il est atteint. En revanche, des objectifs de sécurité accrus seront probablement à envisager, de même que la gestion des éléments devenus dormants, etc.

La plupart des organisations fonctionnent avec une IT toute puissante dont le rôle (hérité d’une longue tradition) est de prendre des décisions seule. C’est une erreur. L’IT est aujourd’hui au service des utilisateurs. Mais en revanche elle est directement responsable / incriminée lorsqu’un problème survient.

Le plan de gouvernance doit être à la fois au service de l’IT (en la protégeant), des utilisateurs (en évitant de les contraindre) et du RSSI. User à la fois d’efficience et d’efficacité (faire les bonnes choses, et les faire bien).

Une bonne gouvernance doit mixer les deux approches, sous peine de mettre en place des règles peu utiles ou de ne pas prendre les bonnes décisions.

« J’aimerai vivre en théorie, parce qu’en théorie tout va bien »

En pratique, certaines choses sont à ne pas faire. Par exemple :

• Cadenasser le SI au détriment de l’adoption ou au contraire l’ouvrir en grand à son profit
• Sous-estimer la (montée en) charge de maintenance réactive et penser « qu’au début du projet, on n’aura pas besoin d’être outillé »
• Se dire que les utilisateurs savent se servir d’Office 365 (ou ont été formés pour cela)
• Croire que les mauvaises utilisations du SI ne sont que le fruit d’une volonté de nuire
• Juger que la gouvernance n’est pas nécessaire ou que l’on n’est pas « mûr » pour l’implémenter

Pour illustrer ma théorie sur la gouvernance, je vous présente donc un cas pratique. Imaginez un environnement de gestion de communautés dans une grande organisation (dans ce cas, un peu plus de 5000 utilisateurs). A l’état initial, l’IT est complétement débordée : elle comptait deux personnes l’année du lancement de la plateforme Office 365, une seule l’année suivante. Dans ce contexte, nous avions identifié les rôles suivants :

Administrateur SharePoint (IT) : crée les communautés et assure le Backup / Restauration. Le processus est le suivant : un utilisateur fait une demande de création d’une communauté par mail. L’IT traite le mail dans la semaine, crée une collection de site. Le demandeur est propriétaire de sa collection, y a tous les droits. L’IT se dédouane ensuite de tout ce qui pourrait se produire dans cette collection de site, et ne s’occupe que de l’inclure dans un plan de sauvegarde globale.

Administrateur de communauté (Métier) : gère un ensemble de communautés. Les tâches techniques associées sont simples : création de site communautaires, de bibliothèque de documents, de forums de discussions. Il gère également les permissions et peut être modérateur d’une communauté. Son niveau de permission technique est en contrôle total sur la collection de site et les éléments enfants.

Modérateur de communauté (Métier) : gère une communauté, c’est à dire un site de type communauté. Les tâches techniques associées sont simplement la création de bibliothèques de documents ou l’attribution de permissions. Son niveau de permission technique est en contrôle total sur le site.

En phase 1, nous allons reprendre le contrôle sur l’environnement. En mettant en place un audit de permissions nous nous rendons compte que quasiment tous les utilisateurs ont fini par être promus et sont en contrôle total sur les communautés auxquelles ils ont accès.

Action : nettoyage de permissions, tous se retrouvent contributeurs, les propriétaires de sites restant seuls avec le contrôle total. Puis mise en place d’une règle automatisée pour s’assurer que ces permissions resteront dans cet état (avec un rollback automatique si un utilisateur non autorisé venait à les changer). Cette opération protège également les héritages, et diminue de 60% les requêtes adressées à l’IT. Économie d’une charge de trois jours par semaine.

En phase 2, définir un objectif. Dans ce contexte, l’IT souhaitait à la fois passer en mode plutôt proactif, mais également promouvoir Yammer. Nous avons donc procédé en deux temps. Le premier temps voyait une refonte du système de permissions : tous les utilisateurs réduit à des contributeurs, tandis que trois groupes fonctionnels sont créés dans l’annuaire (Administrateur, Community lead, Modérateur). Puis des services sont mis à disposition de ces groupes, avec une dénomination fonctionnelle. Les groupes étant imbriqués, les services de niveau le plus fin sont accessibles au niveau le plus élevé.

Pour faciliter l’adoption de Yammer, le service de création d’une communauté permet, via l’utilisation d’un web service Azure et des API Microsoft, de demander à l’utilisateur s’il souhaite créer un nouveau groupe Yammer et l’intégrer dans sa communauté, en remplacement du flux RSS de SharePoint.

Après quelques mois de fonctionnement, les objectifs sont largement atteints. En termes d’adoption, environ 300 communautés et groupe Yammer sont créés. En termes de charge de maintenance, le nombre de demandes au support concernant des points relatifs aux permissions sont réduit à quelques-uns (essentiellement pour de nouveaux arrivants).

En revanche, de nouveaux objectifs peuvent être identifier : automatiser la gestion du cycle de vie des communautés, création et gestion des Groups, etc. La méthode ayant montré son efficacité une fois, la deuxième itération est en cours.

Office 365 pour les RSSI ?

Dans le troisième article de cette série, je m’intéresserai plus particulièrement à la version 3.0 de ma gouvernance, résolument orientée sécurité et conformité.

J’y parlerai notamment de protection des données, en temps réel, mais également de problématiques plus fonctionnelles.

J’y dépoussièrerai également quelques idées reçues, aujourd’hui encore freinant l’adoption d’Office 365, en montrant que la plateforme possède tous les arguments pour favoriser son adoption, et que des éditeurs tiers permettent d’aller beaucoup plus loin si les besoins sont exprimés.