D’ailleurs, s’il y a bien une chose que vous devez protéger, ce sont bien vos administrateurs !

Qu’elles concernent les méthodes d’authentification, les permissions des applications tierces via les API (en autorisant une application tierce à synchroniser des données avec un service de stockage externe par exemple) ou encore la modification des politiques de rétention, Une action d’administration peut considérablement affecter les données et la sécurité du tenant à plus large échelle. S’il est nécessaire d’expliciter encore ce point, un Administrateur général (ou Global Administrator en anglais) a la capacité d’accéder à l’ensemble des données ou de gérer tous les paramétrages d’Office 365, Windows 10, d’Azure AD… mais également d’Azure !

Quelles fonctionnalités natives dans la plateforme de Microsoft ?

Quels modèles de droits au sein de Microsoft 365 ?

A ce jour, Microsoft 365 comporte deux niveaux de droits principaux. Ces deux niveaux permettent schématiquement de déléguer des droits d’administration en s’adaptant aux différents modèles d’organisations (petites / moyennes / grandes, centralisées / décentralisées) :

• Rôles Azure AD : Administration des services Azure AD et Microsoft 365 ;
• Rôles RBAC : Administration des objets au sein des services.

Premier niveau : Utilisation des rôles Azure AD pour gérer les services

La personne à l’origine de l’ouverture du tenant récupère automatiquement le rôle d’Administrateur Général. Il peut alors nommer d’autres administrateurs pour l’accompagner dans ses tâches. Dans la mesure du possible, les droits de Global Admin ne doivent pas être utilisés afin de limiter une surexposition des comptes d’administration. Une bonne pratique, consiste à limiter ce rôle général à un maximum de 3-4 comptes. De plus, pour la quasi-totalité des actions, il existe un rôle d’administration de service équivalent (ex : SharePoint Administrator, User Administrator, etc.).

Ces rôles d’administration de services sont également appelés rôles Azure AD. En effet, chaque service peut être vu comme une application Azure AD. Un administrateur serait ainsi équivalent au propriétaire du service en question. A l’heure de l’écriture de cet article, Microsoft propose 59 rôles différents, ce qui permet d’avoir un bon niveau de ségrégation des droits dans la plupart des cas.

Cependant, les rôles proposés par défaut donnent accès à l’intégralité du service administré pour l’ensemble du tenant et peut donner certains cas donner accès aux données sous-jacentes (notamment pour SharePoint Administrator, Exchange Administrator et User Administrator).

Figure 1 – Exemples de rôles sensibles

Dans le cas d’une maturité avancée, il est possible d’aller plus loin dans la ségrégation des droits en créant des rôles Azure AD personnalisés. Concrètement, cela revient à décider de quelles permissions bénéficie ce rôle (ex : « microsoft.directory/applications/create » permet de créer des applications dans Azure Active Directory).

Le revers de la médaille sera qu’il sera plus compliqué d’auditer l’administration et qu’il sera nécessaire de veiller à l’évolution des services afin de s’assurer que les permissions restent cohérentes avec les besoins des administrateurs.

Second niveau : Utilisation du modèle RBAC pour gérer les objets

Certains services tels que Exchange Online, Intune, les Centres de Securité et de Conformité ou encore Cloud App Security proposent des modèles de droits RBAC spécifiques.

Comme son nom l’indique, le Role Based Access Control (RBAC), permet d’implémenter une gestion des permissions plus fine ; avec la capacité de définir des rôles pour des périmètres définis (exemple sur certains groupes d’utilisateurs). Par exemple, il sera possible de créer « Helpdesk A » et « Helpdesk B » dans Exchange Online pour donner des droits de support à deux équipes distinctes sur un périmètre A et un périmètre B.

Comment provisionner les comptes d’administrations ?

La première question est de savoir comment créer l’identité d’un administrateur. Deux stratégies sont possibles :

• La création d’un compte dans le référentiel d’identité de l’organisation, qui sera ensuite synchronisé avec Azure AD (ex : wavestone.com) ;
• La création du compte directement dans Azure AD. Ce compte sera alors dit « cloud-only » (exemple : wavestone.onmicrosoft.com).

Quel que soit le rôle d’administration, il est recommandé pour un service SaaS comme Microsoft 365 que le compte se situe au plus près de la ressource administrée. Ici, cela revient à utiliser des comptes cloud-only. L’objectif est double : se prémunir d’une éventuelle indisponibilité ou d’une compromission du référentiel d’identité de l’organisation.

Comment attribuer des permissions ?

La deuxième question est de savoir comment attribuer les bons privilèges aux rôles d’administration créés.

Dans le cas de l’administration des services

Afin d’attribuer un rôle AAD, il est possible d’utiliser 3 méthodes (via le portail ou la commande PowerShell correspondante) :

• Le portail Azure (portal.azure.com) : c’est la méthode qui doit être privilégiée, car elle permet l’association de droits au plus près des ressources et l’utilisation de PIM, dont nous parlerons dans la suite de l’article ;
• Le portail Microsoft 365 (admin.microsoft.com) : il est possible de réaliser l’attribution des rôles directement à travers le portail principal d’administration. Cependant cette méthode n’est pas compatible avec PIM ;
• L’utilisation d’outils IAM tiers: ces solutions présentent aujourd’hui des connecteurs avec Office 365 pour réaliser le provisioning des identités et des privilèges. Ces solutions offrent une granularité moindre, ne sont pas compatibles avec PIM et sont source d’erreurs courantes. Par exemple, la synchronisation est généralement en sens unique, ce qui entraîne la réapparition du compte d’administration si celui-ci n’est supprimé que dans Azure AD.

A noter, il est également désormais possible d’assigner un rôle Azure AD à un groupe de sécurité (Cloud uniquement) via une fonctionnalité en preview. Cela pourrait simplifier certains modèles d’administration, dans lesquels l’équipe Communications Unifiées doit par exemple bénéficier du rôle SharePoint Administrator et de Teams Administrator. Attention cependant à la gestion de ce groupe.

Dans le cas de l’administration des objets

Pour les rôles RBAC, la définition des rôles se fait directement dans la plateforme d’administration du service concerné. Il est alors possible d’assigner le rôle en question manuellement ou à un groupe de sécurité, dans le portail ou via une solution IAM.

Figure 2 – Fonctionnalités natives de la solution

Comment bâtir et implémenter son modèle d’administration ?

Quelle stratégie pour définir son modèle de droits ?

La construction d’un modèle de délégation doit se faire sur le principe du moindre privilège. Le cœur du travail est faire l’inventaire des cas d’usages d’administration d’Office 365 et de faire la correspondance entre vos équipes et les droits disponibles.

Cela peut être l’occasion de remettre à plat l’organisation des équipes traitant de l’environnement de travail. Deux constats sont assez significatifs :

• Les terminaux mobiles et les postes de travail sont destinés à être gérés par des solutions unifiées (UEM) comme Intune, Workspace One ou MobileIron, et donc par la même équipe.
• Les outils de sécurité et de conformité sont de plus en plus intégrés nativement dans Office 365. Il est donc nécessaire de faire tomber le mur qui existait entre le monde workplace et le monde sécurité, afin de créer une équipe ayant la même ambition : créer et maintenir une plateforme maîtrisée et sécurisée.

Office 365 a pour particularité de rassembler une multitude de services différents, tels que le stockage de fichier ou d’informations (SharePoint, OneDrive), des outils de communication (Exchange, Teams) mais aussi de sécurité (Defender, Information Protection, etc.). Il est alors indispensable de regrouper les services en catégorie et de définir une matrice de correspondance entre équipe et rôles d’administration.

Concrètement, nous vous conseillons dans un premier temps d’utiliser les rôles Azure AD par défaut pour l’administration des services, et ensuite de définir des rôles plus granulaires avec RBAC et les rôles personnalisés.

Il est également intéressant d’identifier les rôles les plus sensibles, comme ceux permettant l’accès aux données ou paramètres de sécurité (par exemple : Global Admin, Exchange Admin, Security Administrator et Application Administration) afin de pouvoir adapter la sécurisation de ces rôles.

Comment déléguer des droits d’administration sur les objets dans un contexte multi-entité ?

Avant de parler sécurisation à proprement parler, se pose encore une autre question. Bien que la configuration des services et des paramètres de sécurité ne puisse se faire que centralement, les équipes locales ont besoin de faire actions de support : création ou modification d’un compte interne ou invité, réinitialisation des authentifiants, création de groupe Microsoft 365 ou d’une liste de distribution, etc.

Les rôles d’administration de services, les rôles Azure AD, n’offrent pas de ségrégation de privilège par périmètre ; un administrateur Exchange Online sera ainsi en mesure de manipuler l’ensemble des boîtes mails. Il ne sera pas envisageable de donner des dans des organisations complexes ou encore dans des contextes réglementés. Plusieurs stratégies sont disponibles, en fonction de la maturité et de la complexité de l’organisation.

Dans le cas de petites structures, le plus simple reste d’utiliser les fonctionnalités natives :

• Rôles RBAC: les rôles RBAC Exchange et Intune permettent généralement d’avoir le bon niveau de granularité pour gérer les objets dans les portails natifs ;
• Administrative Units: les Unités administratives, enfin en GA depuis fin Septembre, sont l’équivalent du RBAC pour Azure Active Directory. Elles prennent la forme de conteneurs dans lesquels un administrateur a la possibilité de créer ou de modifier des objets, ce qui trouve tout son sens pour les activités de support.

Dans le cas de structures plus importantes, la bonne pratique est de ne pas gérer les objets (utilisateurs, boites mail, groupes, sites SharePoint, etc.) directement dans les portails natifs. Il faut une interface permettant de gérer l’ensemble de ces objets, tout en tenant compte des logiques métiers et du modèle d’administration cible. Ci-dessous, trois exemples d’interface :

• Développement maison d’un « Custom Automation Engine» : cette interface sera décorrélée de de l’IAM et bien souvent une grosse machine à powershell / Graph API ;
• Intégration d’un connecteur à la solution IAM en vigueur afin de présenter une gestion complète des objets en faisant abstraction de leur hébergement direct ;
• Investissement dans une SaaS Management Plateform(SMP) : des éditeurs se sont spécialisés dans la création d’outil de gestion d’Office 365, mêlant fonctionnalités d’administration des objets, de gestion de licences ou encore de supervision sécurité et opérationnelle. Parmi ces solutions, encore peu connues, on retrouve notamment ManageEngine, CoreView et Quadrotech.

A noter : cette interface, dédiée aux équipes de supports, sera distincte d’une interface ouverte à tous les utilisateurs leurs permettant de créer centralement des utilisateurs invités, et des sites SharePoint, des Teams, etc. Concrètement, cette deuxième interface pourra être intégré aux outils de ITSM, à la SMP ou encore être développée à base de Power Apps et de Graph API.

Comment protéger l’accès à ces comptes

10 mesures pour sécuriser les comptes d’administrations

En fonction des licences de sécurité, principalement du bundle EMS, Microsoft fournit un certain nombre de contrôles pour sécuriser les comptes d’administration.

La plupart de ces mesures pourraient également être obtenues via des outils tierces.

Les mesures basiques de la sécurisation du compte d’administration

1. Un compte d’administrateur dédié

Un administrateur doit posséder un compte dédié à l’administration, différent du compte bureautique. Ce compte devrait être cloud-only dans la mesure du possible (ex : wavestone.onmicrosoft.com).

2. Authentification Multi-Facteur

L’authentification à plusieurs facteurs n’est plus une option aujourd’hui, et ce encore moins pour les administrateurs.

Cette mesure est disponible pour tous, pour toutes les licences :

• Via MFA pour Office 365 (également appelé MFA avec héritage par personne) qui force un challenge à chaque connexion ;
• Via les Security Defaults qui impose l’enregistrement d’un facteur additionnel pour tous les utilisateurs et impose le MFA pour les administrateurs à chaque connexion ;

Il est également important également de veiller à la désactivation des protocoles d’authentification héritée qui ne prennent pas en charge le MFA. Ces derniers permettraient en effet de passer outre l’authentification simple.

Il sera également pertinent de limiter les types de facteurs supplémentaires disponibles ; à quoi bon sécuriser les comptes d’administration si le second facteur est l’adresse Gmail de l’administrateur.

Des mesures de sécurisations fortement recommandées

3. Compte sans licence Office 365 

Sans licence, il se sera pas possible pour un administrateur d’accéder aux différents services et données de la plateforme, ou encore d’avoir une boite mail.

A noter, certains services, comme Power Apps ou Power BI, requièrent une licence pour accéder au portail d’administration. En pratique, il peut être intéressant de créer un groupe de sécurité attribuant les licences nécessaires pour les administrateurs.

4. Conditional Access (avec Azure AD P1)

L’accès conditionnel permet d’évaluer le contexte lors de l’accès à un service Office 365, et d’autoriser en fonction l’accès. Il permet par exemple de bloquer l’accès en fonction du type de poste utilisé (géré par l’entreprise ou non), du réseau sur lequel l’utilisateur est connecté, de l’application en question ou encore de son rôle d’administration.

Dans une logique Zero Trust, il ne faudrait pas différencier le réseau interne et le réseau externe, en particulier pour les administrateurs, mais plutôt se concentrer sur l’état du poste de travail et le risque de la connexion.

5. Protection de mot de passe (avec Azure AD P1)

Aure AD Password Protection apporte des contrôles sur les mots de passe. Il sera ainsi possible d’interdire l’utilisation d’un mot de passe courant ou d’un dérivé (avec une liste prédéfinie par Microsoft ou maintenue par l’organisation).

Une bonne pratique consiste à appliquer à minima cette protection sur l’ensemble des comptes d’administration Cloud-only.

6. Azure AD Identity Protection (avec Azure AD P2)

Azure AD Identity Protection permet d’ajouter une notion de risque dans l’évaluation des accès et des comportements des utilisateurs. Concrètement, il sera opportun des définir les politiques suivantes ;

• Risky users : Forcer le changement de mot de passe pour un administrateur susceptible d’être compromis (avec un risque Medium ou High) ;
• Risky sign-in : Forcer un challenge MFA lors d’un accès à risque (ex : IP anonyme ou inhabituelle).

7. Azure AD Privileged Identity Management (avec Azure AD P2):

Azure AD Privileged Identity Management est un service permettant de contrôler l’attribution et l’utilisation des rôles d’administration :

• Attribuer de droits « just-in-time » en donnant un rôle éligible au lieu de permanent ;
• Soumettre l’activation d’un rôle à une validation d’une tierce partie ;
• Mettre en place une date de fin de droit pour un rôle d’administration ;
• Forcer les recertifications des administrateurs.

Il sera pertinent de distinguer les rôles dits sensibles des autres, lors de l’implémentation.

Le suivi des administrateurs éligibles permet en bonus, de prendre conscience de l’utilisation réelle des droits d’administration et donc de nettoyer plus facilement la liste des administrateurs.

A noter, les fonctionnalités de PIM ont récemment été étendus aux différents groupes, ce qui permet de mettre en place du « Just-in-time » pour des cas plus exotiques comme les Super-Users RMS / AIP.

Pour aller encore plus loin

8. Supervision des action administrateurs pour détecter les comportements anormaux

Une fois toutes ces mesures de sécurisation en place, il ne vous reste plus qu’à implémenter de la supervision afin de détecter les non-conformités aux règles précédentes et les comportements anormaux.

Et pour cela, rien de mieux que de se référer à notre article sur le sujet pour comprendre les journaux disponibles.

9. Mettre en place une Privileged Access Workstation

L’administration étant une action par définition critique. Il est nécessaire qu’elle soit réalisée dans un périmètre de confiance. La mise à disposition de PAW, ou poste d’administration, permettra d’aller dans cet objectif.

La configuration du poste d’administration devrait être simple (pas de droits d’administration local, navigation Internet restreinte, ports USB bloqués, modules PowerShell préinstallés, etc.). Mais le fait de restreindre la connexion d’un administrateur Office 365 depuis ce poste peut poser plus de soucis. Pour cela, plusieurs possibilités existent :

• Dans un contexte moderne, une réponse simple est de s’appuyer sur les outils Microsoft : définir un profil de poste d’administration dans Intune et l’assigner aux administrateurs. Avec une règle d’accès conditionnel, il est possible d’exiger un poste conforme lors de la connexion.
• Dans un modèle plus classique, il est possible de mettre en place un silo d’authentification avec les administrateurs et les postes associés. On aurait ainsi un modèle se rapprochant du modèle en tiers bien connu des équipes AD.
• D’autre pistes sont également possibles, même si plus complexes : association d’un certificat et d’un reverse proxy ou encore d’un bastion.

10. Rester informé des bonnes pratiques et des nouveautés

On ne rappellera jamais assez qu’Office 365 étant une plateforme Cloud, elle est en évolution constante. Se tenir au courant permettra de continuer à augmenter son niveau de sécurisation au fil du temps.

Figure 3 – La sécurisation des comptes, des mesures qui se comptent sur les doigts de la main

Focus sur les comptes bris de glace

Une bonne pratique d’administration de la plateforme de Microsoft est la mise en place de comptes d’administrateur permettent en cas d’incident de récupérer le contrôle sur la plateforme.  Ce sont ce que l’on appelle des comptes bris de glace. Ces comptes doivent permettent un total contrôle sur le tenant Office 365 et le rôle de Global Administrator leur est donc attribué.

Ces comptes doivent faire preuve d’une sécurisation, cependant il ne faut pas oublier leur spécificité qui consiste à les utiliser en cas d’incident. Ainsi la sécurisation imposée à ces comptes doit rester compatible avec le caractère urgent de leur utilisation.  Ces comptes doivent donc répondre aux recommandations suivantes :

• Être des comptes cloud-only
• Pas de MFA configuré (ou du moins un MFA tiers)
• Stockage du mot de passe dans un coffre auquel seulement des personnes identifiées de l’équipe sécurité ou Office 365 peuvent accéder
• Mise en place d’alerte afin de vérifier que ces comptes ne sont pas utilisés hors d’une procédure d’incident nécessitant l’utilisation du bris de glace.

Il est également recommandé de ne pas utiliser de convention de nommage spécifique pour ces comptes, ils ne doivent pas attirer l’œil d’un possible attaquant !

Conclusion

La sécurité sur Office 365 repose sur des mesures techniques de protection des comptes administrateurs, ainsi que l’implémentation d’un modèle d’administration cible, ce qui comprend une gouvernance et des processus clairs, des outils pour mettre en place cette délégation de droits, et des dispositifs pour le maintenir dans le temps.

Mais quelles que soient les mesures de protection implémentées, la sécurité repose avant tout sur les administrateurs de la solution. Sensibilisation des administrateurs et contrôles seront indispensables.

Les administrateurs doivent garder à l’esprit que leurs comptes donnent accès à des informations et des actions extrêmement sensibles : ils sont donc la cible privilégiée des pirates informatiques !

O365 étant en constante évolution, chaque nouveauté introduite par Microsoft pourra amener également son lot de problèmes de sécurité qu’il faudra étudier et prendre en compte. Profitez-en pour mettre à jour vos documentations : analyses de risques O365, configuration des services, modèle de délégation…toujours sans oublier de permettre à vos administrateurs de se former !

Cet article Comment maîtriser l’administration dans Microsoft 365 ? est apparu en premier sur RiskInsight.

A l’heure du modern workplace, il est indispensable pour les équipes sécurité et conformité de connaître les capacités natives des plateformes de collaboration et de communication. Cette maîtrise permettra de définir une stratégie cohérente prenant en compte aussi bien les besoins de protection des données que les réglementations, l’urbanisation du système d’information et l’incontournable sujet de l’expérience utilisateur.

Pour les entreprises bénéficiant du plan de licences le plus élevé, Microsoft 365 E5, il n’y a pas de problème : toutes les fonctionnalités sont disponibles. Pour les autres, le sujet est autrement plus complexe.

Cet article est orienté pour les entreprises ayant plus de 300 collaborateurs. Pour les autres organisations (éducation, associations, petites et moyennes entreprises) les plans de licences sont légèrement différents, mais les informations ci-dessous restent applicables pour la plupart.

La partie 1 de cet article est disponible ici.

2/ S’approprier la logique de licensing

Pour les personnes profanes au licensing Microsoft, trois principes régissent l’attribution de licences en fonction de la population concernée :

• Un utilisateur interne d’un service ou bénéficiant indirectement dudit produit (ex : groupe dynamique, classification d’un site SharePoint, partage de tableaux de bords Power BI) doit avoir la licence requise ;
• La plupart des rôles d’administrations nécessitent la licence du service administré pour accéder au portail d’administration ou aux commandes PowerShell associées ;
• Les utilisateurs externes ou les utilisateurs invités (guest en anglais) n’ont pas besoin de licence spécifique pour collaborer sur du contenu Office 365. Cela est permis grâce aux capacités gratuites d’Azure AD. Néanmoins, si utilisateur invité est soumis à des fonctionnalités d’Azure AD Premium (P1 ou P2), un nombre suffisant de licences doit être disponible (à raison de 1 licence achetée pour 5 utilisateurs invités).

Les licences sont nominatives et s’entendent par utilisateur et par mois.

A noter qu’un même produit peut être disponible avec des fonctionnalités plus ou moins avancées en fonction du niveau des licences choisi. Un exemple récurrent concerne les journaux d’audits unifiés : ces logs sont conservés 90 jours avec des licences Office E1 ou E3 tandis qu’avec des licences Office E5 la durée est de 365 jours.

3/ Percer le mystère des plans de licences

Pour rappel, le modèle des licences Microsoft est constitué des éléments suivants :

• Plan de licences : Un plan définit les services souscrits à l’éditeur qui sont disponibles dans le tenant. La plupart du temps, un plan de licences sera un bundle collaboratif (Office 365), un bundle de sécurité (EMS) ou un package (Microsoft 365) ;
• Licence : Pour être considéré comme actif, et donc pouvoir se connecter au tenant, un utilisateur doit au moins posséder une licence ;
• Service : Un service est un produit, une fonctionnalité ou une capacité de Microsoft 365 nécessitant une licence. Cette licence peut provenir de plusieurs plans de licences différents : par exemple Office 365 E1 octroie SharePoint Online Plan 1 tandis qu’Ofice 365 E3 et E5 apportent SharePoint Online Plan 2 ;
• SKU : En langage Microsoft, ce terme tiré de la gestion des stocks désigne l’implémentation d’une licence pouvant être assignée à un utilisateur.

Les bundles collaboratifs Office 365 : des fonctionnalités de protection de la donnée et conformité incluses nativement

Les plans de licences collaboratifs, également appelés bundles Office 365, sont à la base du licensing Microsoft 365. Ces plans intègrent nativement des fonctionnalités croissantes de conformité. Les options de sécurité sont quant à elles assez limitées et doivent être souscrites indépendamment.

Le premier plan est Office 365 E1. Ce plan intègre l’ensemble des services bureautiques en mode web uniquement. Les produits de conformité et de sécurité correspondent au minimum vital de ce que l’on peut attendre d’un service SaaS d’entreprise aujourd’hui : Security Defaults (MFA basique), Journaux d’audits, Recherche de contenus et Etiquettes de rétention.

Office 365 E3 ajoute à E1 les clients lourds de la suite bureautique (désormais appelée Microsoft 365 Apps), ainsi que des fonctionnalités de protection de la donnée (Information Protection for Office 365 et Office DLP), Core eDiscovery et des politiques de rétention par défaut. Ce plan de licences est celui préféré par les entreprises aujourd’hui pour des utilisateurs standards.

Enfin, Office 365 E5 s’adresse plutôt à des populations particulières sur le plan bureautique avec la téléphonie, Power BI Pro et des statistiques sur l’utilisation de la suite Office 365. Ce plan intègre également la classification automatique (hors machine learning), des options de conformité pour les populations soumises à des réglementations (Records Management, Customer Key, Customer Lockbox, Information Barriers, Communications Compliance) et des options d’investigations avancées (Advanced eDiscovery et Data Investigations), ainsi qu’Office ATP et Office CAS.

Deux points importants à noter :

• Office DLP et AIP P1 peuvent être souscrits comme licences additionnelles pour des utilisateurs Office E1, afin d’avoir des fonctionnalités de protection de la donnée similaires à Office E3 ;
• L’option de Multi-Géo est une licence additionnelle, quel que soit le plan de licences choisi.

Les bundles de sécurité : des fonctionnalités de sécurité complémentaires

Introduit dès 2014, le bundle de sécurité EMS (Enterprise Mobility Suite, puis Enterprise Mobility + Security) intègre divers produits de sécurité. Ces produits ont pour vocation à maîtriser les identités, les terminaux en situation de mobilité et les applications accédant aux données Office 365.

• EMS E3 : Intune, Azure AD P1, AIP 1, Advanced Threat Analytics ;
• EMS E5 : Azure AD P2, AIP P2, Azure ATP et Microsoft Cloud App Security.

Aujourd’hui, EMS E3 se révèle indispensable pour des organisations faisant le choix de partir sur une stratégie « Full Microsoft ». En effet, Intune et Azure AD P1 offrent une stratégie cohérente pour gérer les accès à la plateforme Office 365. En revanche, peu d’organisations ont fait le choix de généraliser EMS E5, un bundle plutôt orienté pour des populations sensibles ou administrateurs, en raison d’un manque de cohérence entre les différents produits de sécurité inclus.

Les packages Microsoft 365 : une offre complète mais onéreuse

Annoncé en 2017, Microsoft 365 est désormais le produit phare de l’éditeur de Redmond. Ce plan de licences combine les fonctionnalités d’Office 365, de la suite EMS et de Windows 10 :

• Microsoft 365 E3 = Office 365 E3 + EMS E3 + Windows 10 E3 ;
• Microsoft 365 E5 = Office 365 E5 + EMS E5 + Windows 10 E5.

Contrairement à une idée répandue, et malgré les divers changements de noms introduits en 2020 (Office 365 Groups en Microsoft 365 Groups, Office Pro Plus en Microsoft 365 Apps), la marque Office 365 n’a pas disparu.

Il peut être opportun de noter, que Microsoft 365 E5 est le seul abonnement bureautique incluant les Trainable Classifiers (classification via Machine Learning), Insider Risk Management ou Safe Documents (extension de Windows Defender ATP pour scanner les documents ouverts en mode protégé).

Microsoft 365 E5 Compliance et Sécurité : un tournant dans la gestion des licences sécurité et conformité

Microsoft 365 E5 Compliance et Microsoft 365 Sécurité ont été introduits début 2020, afin de simplifier le licensing sécurité et conformité en regroupant les produits sous des plans de licences cohérents. Une bonne nouvelle, car la situation était devenue complexe entre les produits EMS et les produits de conformité historiques (ex : Advanced Data Governance et Advanced Data Compliance).

Microsoft 365 E5 Compliance combine l’ensemble des fonctionnalités de protection de l’information, de gouvernance et d’investigation. En fonction des besoins, trois sous-bundles peuvent être envisagés :

• Microsoft 365 E5 Information Protection & Governance : AIP P2, Microsoft Cloud App Security, Advanced Retention Policies, Records Management, Advanced Office DLP et Advanced OME, Customer Key et Trainable Classifiers ;
• Microsoft 365 E5 Insider Risk Management : Insider Risk Management, Communications Compliance, Information Barriers, Customer Lockbox et PAM ;
• Microsoft 365 E5 eDiscovery & Audit : Advanced eDiscovery, Advanced Auditing et Data Investigations.

Présentées officiellement comme des extensions de Microsoft 365 E3, la documentation laisse entendre que les prérequis en termes de licences seraient moindres. L’extension Information Protection & Governance ne nécessiterait « que » AIP P1 et les Plans 2 d’Exchange Online et SharePoint Online (soit Office 365 E3).

Microsoft 365 E5 Sécurité combine Azure AD P2, la suite Advanced Threat Protection (Azure ATP, Office ATP, Windows Defender ATP) et Cloud App Security. Ce bundle sera intéressant pour les organisations peu dimensionnées pour gérer de nombreux outils de sécurité (MFA, EDR, AD Monitoring, Passerelle mail, CASB).

Focus sur les Firstline Workers

Les plans de licences Office 365 F3 et Microsoft 365 F1 et F3 sont destinés aux Firstline Workers :

• Microsoft 365 F1 est un plan de licences qui regroupe EMS E3, Teams et SharePoint (uniquement en partage et consommation de contenu) ;
• Microsoft 365 F3 combine EMS E3, Windows 10 E3 et Office 365 F3 ;
• Office 365 F3 est une version allégée de Office 365 E1, avec des fonctionnalités similaires (Exchange, SharePoint, OneDrive, Teams et Power Platform principalement) mais du stockage nettement plus limité pour OneDrive et Exchange.

Microsoft définit cette population par « utilisateur sans terminal dédié, avec un usage occasionnel. » Concrètement, un terminal dédié est un matériel informatique ayant un écran de plus de 10,1 pouces, utilisé par un collaborateur à hauteur de plus de 60% de son temps de travail. Des exemples peuvent être des populations médicales, des vendeurs dans un magasin ou des ouvriers dans une usine.

Les licences Fx ne peuvent donc pas être utilisées pour optimiser les coûts de licensing pour des populations n’ayant pas de besoins avancés.

4/ Se doter des bons outils pour trouver les informations pertinentes

Il n’existe pas de cartographie officielle permettant de se retrouver facilement entre les produits et les niveaux de licences (E1, E3, E5, F1, F3, etc.), à croire que tout semble fait pour orienter les entreprises vers les licences les plus onéreuses. Il n’est pas donc étonnant de voir que des entreprises se soient spécialisées sur le segment très spécifique du licensing Microsoft (conseil en optimisation ou éditeurs de solution de gestion).

Comment se renseigner sur ce qui existe (sources officielles)

Concernant les licences liées aux produits conformité et sécurité, la référence la plus complète est la documentation « Conseils de licence Microsoft 365 pour la conformité & la sécurité« . Malheureusement, cette documentation officielle n’est pas exhaustive, il y manque par exemple :

• Les produits concernés par les préversions privées ou publiques. Par exemple, le nouvel Endpoint DLP nécessite par exemple une licence Microsoft 365 E5 Compliance ou Microsoft 365 E5 Information Protection & Governance ;
• Des détails concernant certains produits conformité. Par exemple, Office DLP est disponible avec une licence additionnelle ;
• Les informations liées aux fonctionnalités Azure Active Directory Premium P1 ou P2 et celles liées à Intune.

A noter, un tableau assez complet, disponible en .pdf et en .xlsx, propose un recoupage de cas d’usages et des licences conformité. Attention, ce tableau peut faire peur !

Concernant les licences sécurité, il n’existe pas encore de synthèse officielle équivalente. La documentation des produits (ex : Intune) et les pages d’informations sur le licensing (ex : Azure Active Directory restent les meilleures sources d’information.

Point important : la plupart des sources officielles précisent qu’elles ne constituent pas un engagement contractuel suffisant. Seul un échange avec le TAM Microsoft permettra de confirmer la disponibilité d’une licence spécifique et le prix associé.

Comment se renseigner sur ce qui existe (sources non-officielles)

En dehors de la documentation officielle, j’utilise deux sources assez intéressantes lorsque l’on évoque le sujet du licensing Microsoft 365 :

• Cartographie non-officielle des produits Microsoft 365, faite par Aaron Dinnage (Microsoft) : il s’agit du document disponible le plus complet sur le sujet ;
• Détails et prix publics (en dollars) des différents plans de licences Microsoft 365, faite par Dan Chemistruck (Infused Innovation).

Comment se renseigner sur ce qui est disponible dans le tenant

Il existe trois possibilités pour maîtriser les licences (unitaires, bundles ou packages) et les produits acquis dans un tenant Office 365.

La première et la plus simple consiste tout simplement à utiliser les informations disponibles dans les portails d’administration Office 365 ou Azure. Cependant, ces portails ne proposent que des fonctionnalités assez basiques : pas d’actions pour un grand nombre d’utilisateurs, un tableau de bord (licences acquises, utilisées et non conformes) global sans granularité par pays ou par entité, etc.

La deuxième option est d’acquérir un outil de gestion ou d’optimisation des licences (ex : ManageEngine, QuadroTech, CoreView). Ce type de solutions s’adresse plus au PME qu’aux grands groupes qui préfèrent la troisième option en raison d’économies d’échelle.

Cette dernière option consiste à développer un outil (à base de scripts PowerShell et d’API Microsoft Graph) d’attribution des licences et un tableau de bord (généralement sur Power BI). Ce choix permettra de palier les limites des outils natifs, mais également de déléguer la maîtrise des licences aux différents Local IT dans un contexte décentralisé.

Focus sur le développement : comment se retrouver parmi les noms

Le développement en lui-même ne présente pas de complexité particulière. En revanche, un problème courant apparaît très rapidement. Les noms des services obtenus par PowerShell et Graph API sont tout simplement incompréhensibles. Ces noms sont souvent issus de rachats ou de noms de projets internes Microsoft (ex : ADALLOM pour MCAS, RIGHTSMANAGEMENT pour AIP P1 ou encore SPE_E3 pour Microsoft 365 E3).

Par expérience, il est alors indispensable de garder à jour une liste de correspondances entre les noms des SKUs obtenus par scripting et les noms officiels :

–         La liste officielle Microsoft est malheureusement loin d’être exhaustive et n’est pas mise à jour régulièrement ;

–         Plusieurs listes non officielles sont maintenues tant bien que mal et disponibles sur Internet.

5/ Sept conseils pour définir sa stratégie de licensing sécurité et conformité

1. Identifier ses besoins en termes de sécurité (identité, menaces, terminaux, etc.) et conformité (protection de la donnée, conformité réglementaire, etc.) pour Office 365 ;
2. Formaliser l’inventaire de l’ensemble des outils de sécurité et de conformité liés au Digital Workplace disponibles dans l’entreprise (incluant passerelle mail, EDR, classification, DLP, etc.) ;
3. Formaliser une feuille de route pour l’outillage sécurité et conformité, dans une logique cohérente avec le modern workplace (rationalisation, sécurité native sans agents, zéro trust) ;
4. Définir un modèle de licences avec différents profils utilisateurs, conjointement avec les équipes architecte et workplace. Il peut être intéressant de privilégier des bundles en prenant en considération les besoins moyens et long terme. L’acquisition de licences unitaires (ou add-on) hors négociation globale se fera au prix fort ;
5. Anticiper les capacités de ciblage des produits. Certains produits (comme les fonctionnalités d’Azure Active Directory ou MCAS) s’adaptent difficilement à un modèle de licences compliqué dans un contexte multi-entités international ;
6. Activer ce qui est disponible sur opportunité dans les bundles acquis, en évitant les doublons avec les outils existants afin de ne pas brouiller les signaux ;
7. Faire de la veille. Les fonctionnalités associées à une licence peuvent évoluer à la suite d’un développement ou d’un rachat de solution tierce. Plus rare, Microsoft peut embarquer des fonctionnalités premium dans des plans basiques. Le centre de messages du portail d’administration et les blogs Sécurité et Conformité sont ici indispensables.

Pour aller plus loin, retrouvez dans cet article les différents sujets à traiter lors de la préparation de l’aventure Microsoft 365.

Cet article « Petit » guide pour se retrouver dans la jungle des licences sécurité et conformité Microsoft 365 – Partie 2 est apparu en premier sur RiskInsight.

Cet article « Petit » guide pour se retrouver dans la jungle des licences sécurité et conformité Microsoft 365 – Partie 1 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.

Cette réflexion doit permettre de couvrir les risques principaux que sont la fuite de données et l’accès aux données par des administrateurs, Microsoft et des personnes ou des applications tierces.

Un nouveau modèle de gouvernance imposé par Microsoft

Office 365 est une solution de communication et de collaboration SaaS. En tant que telle, la plateforme est en constante évolution, contrairement aux solutions historiques dites « on-premise » : de nouvelles fonctionnalités ou paramétrages apparaissent, sont modifiés tandis que d’autres disparaissent ; on peut citer la disparition annoncée de Skype en 2021 ou la fin du support de l’authentification legacy pour Exchange Online en 2020. Le rythme de cette livraison continue, « continuous delivery » en anglais, est imposée par Microsoft sans contrôle possible, ce qui nécessite un tout nouveau modèle de gouvernance.

L’intégration des changements ne peut plus se faire en mode projet, mais doit suivre un processus établi. Dans ce modèle, les équipes workplace et sécurité doivent travailler main dans la main et être représentées dans l’ensemble des comités projets et d’architecture, et ce dès la conception des cas d’usages de la plateforme. Ces équipes également auront pour responsabilité commune de veiller à la bonne santé et à la conformité réglementaire de la plateforme.

L’équipe sécurité ainsi voit son périmètre évoluer : elle n’a plus la main sur les outils de sécurité et peut, voire doit, avoir un rôle de business enabler afin d’accompagner la migration vers le Cloud en proposant de nouveaux usages (ex : ouverture d’un service maîtrisé d’échange de fichiers à l’externe). Une organisation adéquate doit être mise en place ; on pourrait même envisager d’avoir un Security officer dédiée à la plateforme au plus près des métiers, ayant pour rôle de conseiller les projets, de suivre la configuration de la plateforme, d’assurer le suivi des alertes de sécurité, etc.

Un autre sujet à traiter concerne la délégation de l’administration. Il n’est pas envisageable d’avoir près de 20 Administrateurs Généraux pour un tenant O365, même si cela n’est pas une situation si rare. La mise en place d’une solution de délégation d’administration des comptes utilisateurs et des objets doit être envisagée, via la mise en place d’une interface ou d’un connecteur basé sur PowerShell ou Graph API. Ce traitement devra permettre de gérer l’ensemble de objets tout en tenant compte des logiques métiers. Autour de cette nouvelle gouvernance, doivent s’articuler les piliers de la sécurité ci-dessous :

• La gestion des identités ;
• La maîtrise des services et des usages ;
• Le contrôle du bon respect des politiques de l’entreprise.

La gestion des identités au cœur du sujet

Dans une solution conçue pour permettre une collaboration interne ou externe, avec une utilisation ATAWAD (Any Time, Any Where, Any Device), la gestion de l’identité et donc des authentifications est le cœur de la gestion plateforme.  Comme pour tout projet, la phase de définition de qui peut accéder à quoi, quand et où est fondamentale.

Sur Office 365, on retrouve trois types d’utilisateurs ayant chacun des niveaux de privilèges différents : les administrateurs, les utilisateurs internes et les invités (externes invités à collaborer sur un fichier ou au sein d’un Groupe O365 ou d’un site SharePoint).

Pour chacun de ces types de comptes, l’implémentation des mesures de sécurité définies va être pleine de défis. Outre l’incontournable authentification multi-facteur, mise en valeur par la fuite de données ayant touché Deloitte en 2017 se posent notamment les problématiques essentielles de la maîtrise des accès des administrateurs (rôles personnalisés ou prédéfinis, accès permanent ou ponctuel etc.) et du cycle de vie des utilisateurs invités (rien n’étant clairement défini par défaut). La question du coût des licences Azure AD Premium ou d’un outil tiers va être élément majeur de la discussion.

À noter également, Office 365 permet à des applications externes, de communiquer avec ses APIs. L’application externe peut alors agir au nom d’un utilisateur avec ses droits propres ou d’un administrateur avec des privilèges plus élevés. Ces applications peuvent provenir de différents magasins d’applications (comme AppSource ou AAD) ou être développées localement. La gestion des permissions accordées à ces applications doit faire preuve d’un point d’attention pour les entreprises. En effet, à travers les APIs, il est très facile d’imaginer une fuite de données massives en cas de dupe d’un utilisateur (ex : cas d’une application requérant des permissions non nécessaires, comme celui de l’accès aux mails).

Une maîtrise des services et des usages indispensable mais délaissée

Une fois les accès à Office 365 sous contrôle, le sujet suivant est de maîtriser l’usage qui en est fait. Il n’est pas rare d’observer que des services, non priorisés lors de la migration vers le Cloud (Power BI, Teams, Flow, accès aux API etc.) sont laissés accessibles avec leur configuration par défaut. Les deux raisons avancées sont généralement de favoriser l’adoption et le manque de temps à consacrer à ces services non prioritaires. En plus du paramétrage du service, il est également indispensable de définir des règles précises autour des usages afin de clarifier qui peut faire quoi et quand (ex : gestion des habilitations SharePoint, création des Groupes). L’idéal étant bien sûr de mettre en place des mesures techniques (paramétrages généraux ou configuration via PowerShell) cohérentes avec la politique définie.

L’absence de sécurisation de ces services laisse toutefois là porte ouverte à de potentielle fuites de données : transfert automatique vers l’extérieur, exposition sur Internet ou encore perte de contrôle la donnée. Comme écrit plus haut, la gouvernance doit prendre en compte la sécurité dès la conception des futurs usages. Les services doivent être analysés et testés sur des populations réduites. En effet, il sera toujours plus facile d’ouvrir une fonctionnalité, que de restreindre un usage déjà bien répandu. Dans le deuxième cas, il sera nécessaire de faire une analyse d’impact, de bricoler une solution de contournement et de sensibiliser largement les utilisateurs. Des actions qui peuvent nécessiter un investissement important et qui pourraient être évitées.

Le suivi des services ne doit pas s’arrêter à la fin de l’adoption des utilisateurs. Les équipes sécurité et workplace auront ainsi la charge de faire un suivi des évolutions d’Office 365 (programme Evergreen, mise en place d’une veille, suivi des blogs Microsoft, …) afin d’évaluer les nouvelles opportunités et menaces.

Le contrôle du bon respect des politiques de l’entreprise

Le dernier pilier, et pas le moindre, consiste en l’implémentation des politiques de sécurité de l’entreprise. Cela passe notamment par la mise en place d’outils de sécurité : protection de l’information, anti-malware, supervision et alerting.

Concernant la sécurité d’Office 365, on peut différencier 3 niveaux de maturité aujourd’hui. Les moyens mis en place vont être conditionnés par les expertises disponibles (les ressources étant limitées sur le marché) et le budget (dépendant notamment de la stratégie de l’entreprise de gestion des licences Microsoft) :

• Niveau 1 – Maîtrise des identités, des services et utilisation du Centre de Sécurité et de Conformité : l’entreprise met en place les solutions de sécurité natives du Security Center et du Compliance Center (incluant notamment Office DLP, Exchange Online Protection, eDiscovery) accessibles avec des licences basiques ;
• Niveau 2 – Développement d’ « outils maisons »: l’entreprise crée un ensemble de scripts simples ou tableaux de bords, en s’appuyant sur Graph API, Security Graph API et PowerShell, pour mettre en place des contrôles et des mesures de sécurité adaptés à son contexte (ex : gestion du cycle de vie des utilisateurs invités) ;
• Niveau 3 –Utilisation d’outils de sécurité avancée : l’entreprise met en place des solutions additionnelles pour renforcer le niveau de sécurité : outils permettant de lutter contre les fuites de données, d’analyser les malwares sur les mails, de revoir les droits, de détecter comportements anormaux ou encore de durcir l’utilisation de la plateforme en fonction du contexte.

La maîtrise des services Office 365, de leurs usages et des fonctionnalités natives de sécurité est indispensable, et doit précéder toute réflexion concernant l’ajout d’un outil de sécurité supplémentaire, qui ne couvrirait pas les failles existantes et ne ferait qu’ajouter de la complexité.

Exemple de contrôles de notre méthodologie d’Audit Office 365

Office 365 est un cas intéressant de l’ouverture des applications métiers sur Internet via le Cloud. Cette évolution requière d’adapter le modèle de sécurité historique de l’entreprise, en tendant vers le modèle de la compagnie aérienne avec l’adoption du Cloud.

La sécurisation d’Office 365 ne doit toutefois pas omettre celle des briques on-premise nécessaires au fonctionnement de la plateforme le cas échéant, comme c’est le cas généralement pour l’authentification qui est portée par l’ADFS.

Cet article Un Office 365 sécurisé, une perle rare ? 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.