Le besoin de collaboration avec l’externe : éternel point de souffrance des entreprises

Les entreprises ont toujours eu besoin de collaborer entre elles en partageant des ressources et en échangeant des données. Pour ce faire, leurs collaborateurs doivent être capables d’interagir en toute sécurité avec des utilisateurs extérieurs à leur environnement.

Plusieurs cas d’usages sont à couvrir, dont un des plus fréquents devient la collaboration bornée dans le temps avec des partenaires, des prestataires externes, des fournisseurs ou des clients B2B.

Aussi, il est courant d’observer une collaboration continue entre filiales d’un même groupe, qui ont besoin d’avoir accès aux ressources et données de l’entreprise, et qui ne partagent pas nécessairement le même Système d’Information.

Historiquement, la collaboration pouvait se réaliser de plusieurs façons présentant des inconvénients :

• Par échange successifs de mails, à la fois peu efficaces et entrainant une perte de contrôle de la donnée échangée ;
• En utilisant des solutions dédiées au partage de document à des tiers, qui s’avèrent coûteuses et peu adaptées d’un point de vue expérience utilisateur ;
• En créant une nouvelle identité dans les systèmes historiques (Active Directory, etc.), et en dotant les entités tierces de moyens pour accéder au SI de l’entreprise (VPN, machines virtuelles, machines physiques, etc.), ce qui augmentait considérablement la surface d’attaque de l’entreprise.

Microsoft a introduit Azure AD B2B pour ce besoin de collaboration

Aujourd’hui, l’usage d’Azure AD B2B permet à deux entités ou plus de collaborer au sein du tenant Azure de l’entreprise d’accueil. Les ressources partagées peuvent être des applications, des documents, des sites SharePoint, des OneDrive ou des équipes Teams.

Dans les faits, la solution Azure B2B permet à un utilisateur externe d’accéder au tenant de l’entreprise d’accueil via son compte habituel en lui créant une identité « invité » au sein de l’Azure Active Directory (AAD) de l’entreprise.

Le tenant « client » fait alors totalement ou en partie confiance au tenant « externe » pour l’authentification via un mécanisme d’échange de jeton.

Il existe trois possibilités natives pour créer une identité « invité » :

• Directement depuis le portail Azure ;
• Via un partage de document sur OneDrive/SharePoint/Teams ;
• Via l’utilisation de la graph API.

Au niveau du tenant d’accueil, le propriétaire peut autoriser ou non le partage de données à des externes et également administrer les comptes invités (création, désactivation, suppression…).

Cette solution de collaboration présente un avantage direct : la facilité d’utilisation pour les utilisateurs habitués aux environnement Microsoft.

Le deuxième avantage à prendre en compte, est bien évidemment le coût de la solution. En effet, une identité « invité » présente une économie de licence : jusqu’à un plafond de 50 000 identités « invité », leur licence est gratuite. Au-delà et selon les souscriptions de l’entreprise, une licence pourra coûter entre 0,003€ et 0,015€ / mois / utilisateur, auxquels viennent se rajouter des frais fixes d’un montant de 0,029 € pour chaque tentative d’authentification multi facteur. Cette politique tarifaire est en décalage avec le tarif habituel d’une licence M365 : entre 10€ et 50€ / mois / utilisateur selon le plan de licence.

Cependant Azure AD B2B présente une configuration par défaut trop ouverte, qui engendre des risques pour l’entreprise

Azure AD B2B introduit plusieurs facteurs qui peuvent induire des risques :

• La création des identités invités est très simple et non contrôlée (pas de responsable pour l’identité, pas de traçabilité, pas de restrictions…) ;
• Le nombre d’identité invité peut augmenter de façon non contrôlée et il est compliqué de gérer simplement leur cycle de vie ;
• L’entreprise ne maitrise pas la sécurité du tenant initial de l’identité « invité » ;
• Aucune règle d’accès conditionnel n’est mise en place par défaut (pas d’authentification forte, pas de restriction d’accès au portail Azure AD, etc.) ;
• L’identité « invité » à accès aux attributs Azure AD des autres utilisateurs.

Ces facteurs engendrent des risques pour les données de l’entreprise, étant donné qu’une identité « invité » peut avoir des droits sur un nombre important de documents et des informations sur son tenant d’accueil.

On peut considérer deux évènements déclencheurs pour les différents scénarios de menaces :

• Une identité « invité » malveillante ;
• Une identité « invité » compromise par un attaquant.

Ensuite, et selon le niveau de configuration et les droits de l’identité « invité », cette dernière aurait l’opportunité de :

• Récupérer de la donnée confidentielle, à laquelle l’identité a accès ;
• Détruire l’ensemble des données accessibles par cette identité ;
• Compromettre l’AD via attribution de rôles à cette identité ;
• Réaliser de l’ingénierie sociale via l’accès à l’ensemble des données des utilisateurs.

En fonction du niveau de maturité de l’entreprise et de la volonté de couvrir le risque, il est nécessaire de mettre en œuvre un certain nombre de mesures

Pour bien commencer : durcir la configuration par défaut

Maitriser les moyens d’ajouter des identités « invité » sur le tenant

Un des premiers points à traiter est de couper l’accès au portail Azure aux collaborateurs non-administrateur de l’entreprise, pour qu’il ne soit plus un vecteur de création d’identités « invité ».

Il faut noter qu’il est également possible de restreindre la population pouvant inviter des externes à collaborer, mais dans les faits cela ne sera pas applicable à toutes les entreprises, et notamment celles qui souhaitent décentraliser la gestion de cette population. En effet le fait de restreindre cette population oblige à créer un service dédié à la création de ces identités, ce qui va à l’encontre du principe même de ce service, qui est de laisser la main aux utilisateurs.

Enfin, il existe une fonctionnalité permettant de positionner des contraintes sur l’adresse mail des identités « invité », via white-list ou black-list de nom de domaine. Cependant avant de se lancer dans ce chantier, il est nécessaire de tenir compte de la complexité de sa mise en œuvre (notamment pour une entreprise qui ne maitrise pas les partenaires avec qui elle collabore), et de la faible réduction du risque associé.

Restreindre ce à quoi peuvent avoir accès ces identités

Il est possible de restreindre les attributs qui peuvent être consultés par les identités invités, afin que ces dernières soient dans l’incapacité de récupérer un gros volume d’information sur le tenant d’accueil.

Renforcer l’authentification et le contrôle d’accès des identités « invité »

Le mécanisme d’authentification multi facteur (MFA) pour une identité « invité » est quasi natif et permet de diminuer le risque d’usurpation par un attaquant. En effet il suffit de mettre en place une politique d’accès conditionnel qui cible spécifiquement ces identités « invité », et qui applique le contrôle relatif au MFA.

Plusieurs défis viennent néanmoins complexifier cette opération, et sont à prendre en compte

• La gestion de la conduite du changement sur ces populations « invité » reste complexe à effectuer, même si les opérations d’onboarding des utilisateurs sont simples et guidées ;
• La gestion des processus de réinitialisation de second facteur en cas de perte ou de vol peut être coûteuse et complexe si elle n’est pas maitrisée.

Sensibiliser les utilisateurs aux risques et aux bonnes pratiques de collaboration

La complexité majeure de la solution Azure AD B2B est l’absence de mécanisme de gestion des identités « invités ». Les utilisateurs sont donc les principaux acteurs de la stratégie de gestion, et doivent être sensibilisés au bon niveau, en insistant sur :

• Les bonnes pratiques de collaboration : dans quel cas doivent-ils utiliser la solution, comment créer un invité, etc ;
• La bonne gestion de leurs accès : ils doivent être supprimés dès que possible afin d’éviter un accès illégitime ultérieur ;
• La désactivation des identités lorsqu’elles ne sont plus utilisées, en particulier pour les prestataires / partenaires, en insistant sur le fait que les documents produits ne sont pas perdus.

Protéger la donnée à laquelle peut avoir accès les invités

Il ne faut pas non plus oublier de protéger la donnée à laquelle peut avoir accès un invité légitime, ce qui donne lieu à plusieurs mesures :

• Il est possible de mettre en place des contraintes pour les identités « invité » via des règles d’accès conditionnels : utilisation obligatoire des clients légers (clients web), ayant pour effet d’empêcher la synchronisation des données et prérequis à des mesures avancées que nous verrons ensuite, l’interdiction du téléchargement des données, contraintes sur les terminaux à utiliser ;
• Si l’entreprise a déployé l’outil de classification AIP (Azure Identity Protection), une autre solution peut être la création d’une étiquette de confidentialité chiffrant la donnée pour les identités « invité ». Cette étiquette pourra également servir à restreindre certaines actions pour cette population : restriction des modifications (via les permissions associées), restriction du téléchargement (via une règle DLP), etc.

Pour aller plus loin, un Cloud Access Security Broker (comme Microsoft Defender for Cloud Apps de Microsoft) peut permettre la mise en place de règles avancées et ciblées comme par exemple : empêcher le téléchargement sur des espaces Sharepoint spécifiques.

Bien gérer le cycle de vie des identités « invité » : 3 Scénarios à considérer

Comme évoqué précédemment, le sujet clé reste la maitrise du cycle de vie des identités « invités » : Création, suppression, et revue des accès. 3 scénarios peuvent être envisagés, en fonction de la couverture du risque souhaitée, du niveau de maturité de la gestion des identités et des accès, et du coût de mise en œuvre du scénario.

Scénario 1 – Rester pragmatique avec un petit budget : utiliser les outils et configurations natives

Dans ce scénario, l’entreprise dédie une certaine typologie de groupe au partage à l’externe, et donc à la création d’invités. La distinction peut se faire par la nomenclature du groupe par exemple : tous les groupes externes doivent commencer par « X_ », ce qui nécessite de contrôler la création des groupes au préalables.

Elle peut ainsi réaliser des contrôles plus facilement sur ce périmètre restreint de groupes.

Le prérequis principal est de bloquer les ajouts d’identités « invités » aux groupes de type « Internes », et il est possible de le faire de deux façons :

• Si l’entreprise a déployé l’outil de classification AIP sur les espaces SharePoint et Teams : utilisation d’une étiquette dédiée pour empêcher le partage aux externes sur ces espaces. Exemple : création d’un label « Interne » qui bloque le partage avec les identités « invité » ; – LIEN
• Via un script PowerShell, bloquer le partage avec les identités « invité » pour les groupes « Internes », en les identifiant via leur nomenclature. – LIEN

Création d’une identité « invité »

La seule possibilité pour créer une identité « invité » est de les ajouter des utilisateurs externes dans des groupes de type « Externes ».

Si l’entreprise a besoin de donner accès à son tenant à une filiale ou une entité entière, il est possible de synchroniser régulièrement leur AD ou Azure AD, et ainsi créer leurs identités en « invité » dans le tenant de l’entreprise.

Suppression d’une identités « invité »

Le processus de suppression des identités reste basique, avec à minima la suppression des identités « invités » inactif, en utilisant par exemple un script PowerShell s’appuyant sur la notion de « Sign In Activity ». Il pourra également être intéressant de supprimer les identités « invité » n’ayant accès à aucun groupe via un script PowerShell.

Revue des accès « invité »

Pour couvrir le risque lié à la revue des accès dans ce scénario, il est possible de faire expirer les accès des identités « invité » sur les groupes SharePoint ou les OneDrive au bout de 60 jours. Il est à noter que le propriétaire des groupes SharePoint ou OneDrive sera notifié de l’expiration 21 jours avant échéance.

Enfin, il est envisageable d’utiliser la fonctionnalité « Guest Access Review » pour les groupes externes où le partage à des invités est possible. Il faut cependant noter qu’elle nécessite des licences avancées (AAD P2) attribuées aux utilisateurs devant effectuer les revues, donc tous les propriétaires des groupes en question (normalement en nombre limité).

Ce scénario est un bon moyen de réduire le risque lié aux invités, en gardant une solution quasi native, et sans trop investir dans la solution.

Scénario 2 – Pour aller plus loin dans le niveau de sécurité : développer une application de gestion des invités

Dans ce second scénario, l’entreprise souhaite avoir complètement la main sur la gestion du cycle de vie des identités « invité », et sortir du mécanisme natif trop permissif de Microsoft. Pour ce faire, l’entreprise crée une application (par exemple en utilisant Power App) pour gérer ce cycle de vie, en en faisant le point unique de création et suppression.

Une fois ce cycle de vie mis en place, il est nécessaire de positionner le paramètre de partage SharePoint sur le mode « Existing guest only », permettant uniquement de partager du contenu avec des identités « invité » déjà existante dans le tenant Azure AD. Ceci permet d’empêcher la création de nouvelles identités via ce vecteur.

 Création d’une identité « invité »

Dans ce scénario les utilisateurs utilisent l’application dédiée pour créer les identités « invité », en renseignant une date de fin. L’utilisateur désigne alors le propriétaire de l’identité créée.

Suppression d’une identité « invité »

Pour supprimer les identités, il est possible de déclencher un workflow automatique en amont de la date de fin, pour demander au propriétaire de l’identité en question s’il faut effectivement la supprimer ou prolonger sa date de fin. Il est à noter que si le propriétaire a quitté l’entreprise sans faire le changement de propriétaire, on peut envisager de réaffecter l’invité à son supérieur hiérarchique.

Revue des accès « invité »

Avec ce type d’application « maison », il est compliqué d’aller beaucoup plus loin dans la gestion du cycle de vie, et notamment quand il s’agit de revue des accès.

Il est toujours possible comme pour le scénario 1 de faire expirer les accès des invités ou d’utiliser la fonctionnalité « Guest Access review » (avec les mêmes contraintes qu’énoncé précédemment).

Pour aller plus loin, on peut également envisager l’utilisation d’outils tiers type IDECSI ou Sharegate qui permettent notamment de gérer ces revues d’accès de façon automatique et intuitive.

Ce scénario change le comportement natif et permet de mieux maitriser le cycle de vie, mais à un coup important au regard du déploiement et de la conduite du changement à mettre en œuvre.

Scénario 2’ – Intégrer les identités « invité » dans les processus IAM classiques

Le dernier scénario à considérer est une variante du scénario précédent, où l’entreprise souhaite toujours avoir la main sur la gestion du cycle de vie des identités « invité ». L’entreprise peut dans ce cas intégrer la gestion des identités « invités » dans ses outils de gestion des identités et des accès (IAM), au même titre que les identités « externe ».

L’outil IAM devient alors la source autoritaire pour ce type de population, et sa gestion s’y fait directement.

Dans ce scénario comme dans le précédent il faut également positionner le paramètre de partage SharePoint sur le mode « Existing guest only ».

Création d’une identité « invité »

La création des identités se fait via les formulaires de création d’externes depuis les outils IAM, en choisissant le type « invité » pour l’identité. L’identité « invité » pourra ensuite être provisionnée automatiquement dans l’Azure AD par les outils IAM.

Suppression d’une identité « invité »

La suppression de l’identité est également faite par l’outil IAM en fonction de la date de fin positionnée, et selon les workflows déjà définis.

Revues des accès « invité »

Dans le cas où les outils IAM de l’entreprise sont utilisés pour gérer les droits sur les espaces Sharepoint, il est possible d’utiliser les capacités de revue d’accès de ces outils pour faire la revue des accès aux ressources sensibles auxquelles ont accès les identités « invité ».

Une deuxième option peut également être d’utiliser les fonctionnalités de gouvernance des accès via les solutions IAM type Sailpoint, OneIdentity ou via des solutions dédiées d’Identity and Access Governance type Brainwave ou Varonis. On peut imaginer récupérer les droits attribués directement dans l’Azure AD, et les faire vérifier aux propriétaires des ressources à travers ces outils.

Ce scénario est une variante du scénario 2, qui permet aux entreprises les plus matures sur la gestion des identités et des accès de capitaliser sur les outils et processus existant.

Enfin, ne pas négliger la surveillance de cette population exposée

En premier lieu il est pertinent de construire un reporting adapté à l’aide de KPI et tableaux de bord. Beaucoup d’informations sont disponibles nativement dans l’Azure AD (date de dernière connexion, activité sur le tenant ainsi que sur Office 365 via les « unified audit logs »). Ces informations peuvent assez simplement être exploités par exemple via Power bi pour la génération de tableaux de bord.

Ensuite, il est important de surveiller les activités de ces populations particulièrement exposées. Deux niveaux de détection peuvent être mis en place en fonction des capacités de surveillance :

• Implémenter des règles de DLP natives ou des scénarios d’alertes classiques dans la console Microsoft : certains scénarios d’alertes sont préconfigurés comme la suppression massive de documents, une élévation de privilège etc.
• Mettre en place des règles DLP avancées et des scénarios de détection ou des seuils spécifiques pour les invités avec l’appui du SOC de l’entreprise. Par exemple, le seuil de téléchargement de données autorisé pour un invité peut être inférieur à celui autorisé pour un interne.

Pour aller plus loin on peut imaginer l’utilisation du module Azure AD Identity Protection, afin de déclencher des alertes pour les invités ayant un niveau de risque élevés.

En conclusion, AAD B2B facilite grandement la collaboration, mais sa configuration nécessite d’être durcie pour réduire le niveau de risque induit par la solution

AAD B2B simplifie grandement la collaboration avec des utilisateurs externes à l’entreprise, mais induit des risques liés à l’ouverture par défaut de la solution. Pour maitriser ces risques, il est nécessaire de réduire l’ouverture, et de contrôler le cycle de vie de ces identités de façon plus ou moins avancé, en fonction de l’investissement possible sur le sujet. Enfin il faut également mettre l’accent sur leur surveillance via les outils natifs ou les outils utilisés par l’entreprise, étant donné la forte exposition de ces populations.

Cet article Bien gérer les identités « Invités » Azure AD B2B est apparu en premier sur RiskInsight.

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.

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.