Les récents événements ont montré que le télétravail n’est plus un luxe pour les collaborateurs, mais une nécessité pour assurer les activités des organisations.
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 :
- Création d’un Custom Automation Engine décorrélé de l’IAM, via une application maison développée en PowerShell ;
- 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).
