Ces nouveaux usages mobiles, reposant de plus en plus sur l’usage des smartphones et tablettes, induisent de nouveaux risques qui doivent être maîtrisés. En effet, la surface d’attaque de l’entreprise se voit considérablement augmenter, du fait de la nature même de ces équipements. Parmi les risques majeurs liés à l’utilisation des terminaux mobiles, on retrouve : 

• Le vol ou la perte de l’équipement et donc notamment des données stockées localement, pouvant mener à un accès aux données d’entreprise à distance 
• L’utilisation de terminaux mobiles non maîtrisés. Cette absence de maîtrise pouvant permettre des comportements à risques tels que l’utilisation de réseaux non maîtrisés (e.g., Wi-Fi public), l’installation d’applications tierces non maîtrisées, des retards dans les mises à jour de sécurité ou même le jailbreak du mobile, 
• L’échange risqué de données, filaire ou sans fil, avec d’autres équipements (e.g., synchronisation USB avec un ordinateur, AirDrop, etc.) 

Les quelques constats ci-dessous viennent confirmer la réalité de ces menaces. En effet : 

• 53 % des appareils mobiles ont accès à plus de données sensibles qu’il y a un an (source Akamai),  
• 45 % des organisations ont récemment été confrontées à une compromission liée à la téléphonie mobile (source CTM), 
• 85 % des attaques par hameçonnage mobile se produisent en dehors des mails mais sur d’autres vecteurs liés aux usages des mobiles (source Verizon). 

La sécurisation des terminaux mobiles ne peut être efficace sans une stratégie d’entreprise claire définissant les usages autorisés, les niveaux de contrôle et les responsabilités associées.  

La sécurité des mobiles est un sujet qui a longtemps été décalé, l’effort étant concentré sur les postes de travail, alors qu’elle peut directement menacer la sécurité du système d’information dans sa globalité. Ainsi, alors que les GPO (Group Policy Object) étaient couramment utilisées dans la gestion d’un parc d’ordinateurs, les appareils mobiles n’en n’ont pas hérité simplement.  

Pour répondre à ce besoin, les éditeurs historiques de la sécurisation des ordinateurs (Microsoft, Ivanti, IBM…), mais également de nouveaux acteurs (ManageEngine) proposent des logiciels SaaS ou On-Premise afin de répondre au besoin de gestion et de sécurisation des appareils mobiles : les MDM (Mobile Device Management).  

Au-delà de participer activement à la sécurisation d’un parc mobile pour l’entreprise, le MDM permet d’améliorer l’expérience des utilisateurs, qui disposent d’un appareil à jour et en permanence conforme aux exigences de l’entreprise. 

Nous proposons dans cet article de découvrir comment sécuriser ses terminaux mobiles d’entreprise en utilisant un MDM, qui est un must-have dans la course à la sécurisation des systèmes d’information, et de partager des recommandations quant à leur configuration. 

Les politiques d’usages mobiles : une stratégie d’entreprise à définir  

En entreprise, les politiques d’usage des appareils mobiles ont fortement évolué. 

Aujourd’hui, nous en distinguons 3 usages (détaillés en fin de section dans la figure 1) les plus répandues dans les organisations : 

• COBO – Corporate-owned, business only 
• COPE – Corporate-owned, personal enabled 
• BYOD – Bring your own device 

Il est nécessaire en premier lieu de définir la stratégie d’entreprise autour de ces usages mobiles : les accès mobiles sont-ils autorisés / légitimes d’un point de vue business ? Si oui, de nombreuses questions complémentaires sont à adresser dans le cadre de la définition de la stratégie d’entreprise :  

• Quels sont les utilisateurs autorisés (uniquement les VIP ou tous les internes ou internes et externes également…) ? 
• Quels sont les types de mobiles autorisés (entreprises ou personnels ou les deux) ?  
• Quelles applications ou données peuvent être accédées (mails uniquement, toute la suite bureautique…) ? 

Cette stratégie est centrale pour donner une direction et guider les efforts de sécurisation qui vont suivre. Elle permettra de mieux cibler les risques applicables à l’entreprise, de mieux maîtriser son SI et de définir des règles cohérentes avec les usages autorisés ou non, tout en apportant de la clarté aux utilisateurs quant aux usages acceptés ou non. 

Figure 1 : Les profils de gestion des terminaux mobiles 

La sécurisation autour des terminaux mobiles en 4 outils : MDM, MAM, EMM et MTD 

Avant de rentrer dans le détail concernant les outils type MDM, il est bon de rappeler qu’il existe plusieurs solutions complémentaires pour la sécurisation des mobiles. Ces outils permettent d’agir à plusieurs niveaux :  

• Le MDM (Mobile Device Management) : outil de gestion de flotte et de sécurisation des terminaux d’entreprise (couche OS essentiellement) 
• Le MAM (Mobile Application Management) : outil de gestion et de sécurisation des applications (couche applicative essentiellement) 
• L’EMM (Enterprise Mobility Management) : outil centralisant les fonctionnalités des MDM et des MAM, 
• Le MTD (Mobile Threat Detection) : outil de détection d’attaque sur mobile, similaire à un outil d’Endpoint Detection & Response (EDR) pour les laptops (couche OS et applicative) 

La figure ci-dessous illustre cet écosystème au sein d’un mobile : 

Figure 2 : L’écosystème de la sécurisation de la mobilité en entreprise 

Un MDM, un MAM ou un MTD ne répondent pas aux mêmes besoins et sécurisent le parc mobile à des niveaux différents. Nous nous focaliserons dans la suite sur les MDM seulement. 

Les MDM répondent aux besoins de sécurisation des terminaux appartenant à l’entreprise, et donc aux politiques COBO et COPE décrites ci-dessus. 

Un point s’attention sur le BYOD : il est important de garder à l’esprit que les appareils non détenus par l’entreprise ne peuvent être entièrement configurés par celle-ci. Afin de sécuriser le cas d’usage BYOD, c’est-à-dire l’accès aux données et applications d’entreprise depuis un appareil personnel non managé, les MAM peuvent répondre au besoin, via la sécurisation des applications et la création d’un conteneur professionnel.  

Dans la suite de cet article, le cas BYOD est considéré hors périmètre : en effet, l’appareil appartenant à l’utilisateur ou à une entreprise partenaire, l’entreprise n’a pas vraiment la main sur la configuration et la sécurité de ces terminaux, car elle peut difficilement contraindre l’utilisateur à installer certaines configurations ou applications, ou à partager certaines données d’appareil. En revanche, il est possible de durcir les accès à son système d’information pour rendre impossible l’usage du BYOD, mais cela nécessite une analyse d’impact poussée, en considérant l’ensemble des cas d’usage (double authentification sur mobile, gestion des partenaires / prestataires externes, conflits entre outils de gestion de flotte, accès à des formations…). 

Le Mobile Device Management, au cœur de la sécurisation des terminaux mobiles de son entreprise  

Les outils Mobile Device Management permettent d’administrer et de sécuriser efficacement une flotte complète de terminaux mobiles, à travers 3 fonctions piliers, qui seront détaillées par la suite :  

• Gestion de flotte : connaître et configurer les terminaux accédant à son système d’information, déployer des applications d’entreprise ou tierces. 
• Contrôle de conformité : s’assurer que les appareils sont conformes aux politiques et standards de sécurité de l’entreprise. 
• Sécurité et durcissement : implémenter des mesures de sécurité sur les appareils afin de renforcer la protection contre les menaces. 

Attention : les paragraphes suivants visent à présenter des fonctionnalités proposées par la plupart des MDM, il convient de s’assurer de la présence de la fonctionnalité désirée avant toute souscription à une solution MDM. 

Administrer la flotte d’appareils mobiles d’entreprise : l’inventaire, l’administration et la mise à disposition 

Face aux besoins de sécurisation et réglementaires de gestion de ses appareils, le MDM permet de centraliser un bon nombre de fonctionnalités de management des terminaux mobiles, en une unique interface : 

• Déployer / retirer : le MDM facilite la mise à disposition de nouveaux appareils d’entreprise pour les équipes IT, possiblement à distance avec installation des configurations d’entreprise et des applications métiers, mais également le retrait de ces configurations et la suppression des données liées à l’entreprise en cas de besoin, par exemple en cas de fin de vie de l’appareil, de suspicion de compromission ou de vol (fonction wipe-out). 
• Gérer : le MDM inventorie l’ensemble des appareils mobiles d’entreprise et présente leurs attributs clés, par exemple le type d’O/S, version de l’O/S, nom du détenteur, statut du chiffrement, IMEI, date de dernière connexion… en assurant une conformité au Règlement Général sur la Protection des Données (RGPD). 
• Surveiller : des alertes sont paramétrables dans les solutions MDM afin de suivre la santé de son parc et prendre connaissance de toute déviation de la flotte par rapport aux règles préalablement définies par l’entreprise. 
• Assister : le MDM intègre des fonctions de prise en main à distance des appareils et de diagnostic des appareils, afin de faciliter les interventions des équipes IT. 

En fournissant des données à jour sur son parc mobile, le MDM peut permettre de répondre à différents besoins réglementaires, notamment sur les volets de connaissance et capacité de gestion de son parc, mais aussi de réaction en cas de compromission. Plusieurs réglementations, par exemple l’ISO 27002 (paragraphe 5.9 Inventaire des informations et autres actifs associés), demandent aux entreprises d’identifier et de manager leurs terminaux.  

Cette centralisation permet une vue globale sur son parc, mais également de le classifier pour mieux l’administrer. Notamment, des systèmes de tag d’appareils ou de regroupements permettent de gérer aisément des sous-ensembles d’appareils qui présenteront des variations de configuration ou des exceptions (en fonction du métier notamment, par exemple les équipes réseaux, les personnes VIP…) 

Les politiques de conformité : évaluer la conformité des appareils mobiles accédant aux données et applications d’entreprise 

Bien plus qu’un simple logiciel de gestion de flotte, les solutions de MDM disposent d’une capacité d’évaluation du parc mobile par rapport aux politiques de sécurité d’entreprises, appelées les politiques de conformité. 

Cette mise en avant des appareils non conformes peut s’avérer essentielle, afin de prendre des actions ciblées : par exemple, leur retirer l’accès au SI via l’accès conditionnel si l’appareil est jailbreak ou ne dispose pas des dernières versions d’O/S. Cette évaluation pouvant s’effectuer à chaque connexion du terminal, la conformité du parc peut être considérée en permanence à jour. 

Il convient de tirer parti de cette fonctionnalité majeure des MDM. Un appareil non conforme représente un danger pour l’entreprise et son SI (présence de vulnérabilités non patchées…). Afin d’éviter de nuire à la productivité des équipes, il est possible de notifier l’utilisateur dès qu’une non-conformité est détectée, et de retirer les droits d’accès aux données d’entreprises via l’accès conditionnel si la non-conformité n’est pas résolue, en ajustant la durée de validité du statut de conformité (Compliance status validity period). 

Les profils de configuration : configurer les appareils déployés par l’entreprise  

Lorsque des appareils mobiles d’entreprise sont proposés aux employés, il convient d’appliquer une configuration afin de protéger ces appareils et de les conformer à un socle prédéfini : ceci est possible grâce aux profils de configuration. 

Pour sécuriser ses terminaux mobiles, il est possible de personnaliser le socle afin de professionnaliser l’appareil, et ce pour diverses plateformes (iOS, Android). Parmi les mesures classiques de durcissement du socle : 

• Durcissement des configurations de sécurité et restrictions de fonctionnalités 
• Déploiement de configuration d’entreprise 
• Restriction d’installation d’application tierce hors magasin d’application 

Les appareils peuvent alors rechercher, selon une fréquence à renseigner, les dernières mises à jour des profils de configuration et les appliquer (recommandation : une fois par jour). Ce paramétrage permet de s’assurer d’être en permanence au plus proche des meilleures pratiques de sécurité. 

Nous recommandons les mesures suivantes dans le cadre de l’utilisation d’un MDM : 

• Pousser la configuration de sécurité lors de l’inscription de l’appareil, incluant à minima : 
• Le chiffrement du stockage 
• Une politique d’authentification durcie (code d’accès à 6 chiffres ou biométrie, avec blocage des codes simples) 
• Déployer des correctifs d’O/S et d’applications en direct 
• Détecter et bloquer les appareils non conformes (a minima, jailbreakés) 
• Déployer un plan d’actions pour les dispositifs non conformes (alertes, blocage…) 

En synthèse, le MDM est une brique fondamentale et un prérequis à la sécurisation des accès au SI 

Les solutions de MDM proposent de nombreuses interfaces, notamment avec d’autres outils de sécurité.  

Particulièrement, pour tirer pleinement profit du MDM, il est commun et recommandé de l’interfacer avec son Identity Provider (IDP). L’intégration du MDM avec le gestionnaire d’identité et des accès au SI permet de proposer de l’accès conditionnel selon la conformité des appareils ou leurs attributs (par exemple, retirer les accès aux données d’entreprise distants aux appareils mobiles non conformes aux politiques de conformité définies dans le MDM). Cela participe notamment aux stratégies Zero-Trust, en renforçant la posture de l’entreprise en maîtrisant davantage les accès à son système d’information. 

Également, il est possible de connecter son outil MDM avec un fournisseur Mobile Threat Defense (MTD). Cette interface avec cet outil complémentaire de protection des terminaux mobiles permet de remonter des informations au MDM sur la conformité de l’appareil, sur sa santé, s’il présente des risques de compromission (malware, connexion à un réseau non sécurisé…). Cette analyse du terminal et de ses risques peut alors conditionner l’accès au SI d’entreprise. 

Enfin, il est parfois nécessaire, bien qu’il ne soit pas recommandé d’accumuler les MDM, d’interfacer sa solution MDM avec d’autres solutions de gestion de flotte afin de centraliser les informations et de gérer centralement l’ensemble de sa flotte. Par exemple, il est commun d’interfacer la solution Microsoft Intune avec le MDM Apple Business Manager qui peut contenir l’ensemble de la base d’appareils iOS. 

Conclusion : Les éléments clés pour sécuriser efficacement sa flotte d’appareils mobiles

Dans un contexte de mobilité croissante en entreprise, le MDM s’impose assurément comme un must-have dans la course à la sécurisation des accès aux SI d’entreprise.  

Bien plus qu’un simple inventaire centralisé des terminaux mobiles, cette solution simplifie également l’expérience des utilisateurs finaux, disposant d’un appareil durci et sécurisé « clé en mains », conforme aux politiques d’entreprise. 

Pour implémenter efficacement une solution MDM, il convient de : 

• Couvrir tous les appareils mobiles de son parc (tout type, toute marque, toute plateforme et tous métiers) : la robustesse d’un SI s’évaluant à l’aune de ses maillons les plus fragiles 
• Formaliser une politique de gestion des appareils mobiles adaptée aux besoins de l’entreprise, sans contraintes majeures pour les utilisateurs finaux, afin d’éviter les contournements utilisateurs et réduire l’impact métier 
• Décliner cette politique en profils de configuration et des politiques de conformité, et les maintenir à jour 
• Sensibiliser les utilisateurs à la politique d’entreprise choisie, en partageant une charte d’utilisation des terminaux mobiles d’entreprise à ses utilisateurs, expliquant les bénéfices de la gestion centralisée et le respect de la vie privée des utilisateurs, ce qui nécessite une stratégie d’entreprise claire 
• Penser la sécurité mobile dans sa globalité, et en particulier adresser le sujet des BYOD en parallèle pour éviter les contournements via ce canal, en combinant le déploiement d’un MDM avec celui d’un MAM, afin de couvrir par exemple: 
• Le risque de fuite de données (stockage local sur l’appareil non managé, synchronisation avec des services cloud personnels (par exemple, Google Drive), partage involontaire via des applications non sécurisées 
• Le risque d’interception des données au sein de connexions non sécurisées (cafés, hôtels, transports) 
• Le risque de propagation de malwares sur le système d’information 

En synthèse, si le MDM constitue aujourd’hui un socle incontournable de la sécurisation des terminaux mobiles d’entreprise, son efficacité repose avant tout sur une stratégie d’entreprise claire et sur un niveau de durcissement suffisant des appareils. 

Les organisations les plus matures pourront ensuite compléter ce socle avec des solutions de MAM et de MTD, dans une logique progressive et adaptée à leurs enjeux (notamment le déploiement du MAM pour permettre l’ouverture aux usages BYOD). Il est à noter que les MTD sont peu déployés à date, la priorité étant à la mise en place de la combinaison MDM et MAM qui, bien configurés, permettent de couvrir une grande majorité des cas d’usage mobiles, du téléphone professionnel managé au téléphone personnel. 

Cet article Securing Your Mobile Devices: Introduction to MDM (Mobile Device Management)  est apparu en premier sur RiskInsight.

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.