Les attaques par hameçonnage (phishing) sont connues de tous. L’objectif de ce type d’attaque est de réaliser des actions depuis le compte d’une victime ou de récupérer des informations sur la personne ou l’entreprise ciblée.

Malgré leur notoriété, elles restent très efficaces pour les attaquants. En effet, parmi les attaques investiguées par le CERT Wavestone, environ 51% d’entre elles commencent par l’utilisation de comptes valides, ce qui inclut les attaques par hameçonnage (phishing).

Face aux attaques par l’hameçonnage, nous sommes tous vulnérables ! Un attaquant disposant de suffisamment de ressources et d’informations sur sa cible peut générer un piège assez élaboré pour faire baisser la garde du destinataire. De même, les suites de produits Office365 et Azure disposent de fonctionnalités pouvant être exploitées dans le cadre d’attaques moins conventionnelles et dont les impacts peuvent être méconnus des utilisateurs.

La sensibilisation des employées, bien que nécessaire pour faire face aux menaces les plus répandues, ne suffit pas face à certains types d’attaques plus ciblées ou moins traditionnelles. Un durcissement des conditions d’accès aux ressources hébergées sur le cloud, une bonne hygiène dans la gestion des droits d’accès ainsi que la détection d’accès inhabituels et suspicieux sont primordiales dans la stratégie de défense des entreprises.

Les attaquants disposent d’une large gamme d’outils et de possibilités pour accéder aux documents stockés sur le SharePoint d’une entreprise, tenter de récupérer des emails sensibles ou récupérer des informations sur les employés. L’attaque par hameçonnage traditionnelle ainsi que par l’authentification « device code » seront brièvement expliquées ci-dessous avant d’examiner plus en détails les attaques par consentement illicite.

L’attaque de phishing traditionnelle : une menace connue et évitable via l’usage d’authentification multi facteur

Les attaques de phishing traditionnelles reposent généralement sur l’envoi d’un lien dirigeant les victimes ciblées vers un site qu’il contrôle. Grace à une mire d’authentification similaire à celles auxquelles sont habituées les employées de l’entreprise ciblée, l’attaquant récupère les identifiants et mots de passe des utilisateurs piégés.

L’attaque par hameçonnage traditionnelle est simple à mettre en œuvre en l’absence d’authentification multi-facteur

La simplicité de mise en œuvre à grande échelle d’une telle attaque en fait un outil de choix pour les attaques non ciblées. Une méthode pour se prémunir contre ce type d’attaque est d’imposer l’utilisation d’un second facteur d’authentification.

Il est à noter cependant que bien que plus complexe à mettre en œuvre, l’interception du second facteur d’authentification est techniquement réalisable et fera l’objet d’un article dédié.

L’attaque via l’authentification « device code » : une méthode méconnue d’authentification détournée par des attaquants

Cette attaque repose sur la fonctionnalité d’octroi d’autorisation d’appareil (device authorization grant)[1]. Cette méthode d’authentification permet d’authentifier un utilisateur sur un appareil ne disposant pas de navigateur web. Un code s’affichant sur cet appareil doit alors être renseigné sur un ordinateur ou un smartphone via le site de Microsoft dédié. Cet appareil disposera ensuite d’une partie des droits d’accès aux ressources Office 365 que l’utilisateur ayant renseigné le code.

Cette procédure peu connue des utilisateurs, peut être exploitée par un attaquant à des fins malveillantes :

• L’attaquant génère tout d’abord un code d’appareil, en utilisant le même processus utilisé par les appareils ne disposant pas de navigateur web.
• Ensuite, l’objectif de l’attaquant sera d’amener la victime à renseigner son code d’appareil sur la page https://microsoft.com/devicelogin. Par exemple, l’attaquant pourrait prétexter que pour accéder à un document sensible, il est nécessaire de se connecter à ce lien en utilisant le code qu’il a généré.
• Si la cible accède au lien, renseigne le code et s’authentifie, cela permettra à l’attaquant d’usurper l’identité de la victime.

Exemple d’attaque par hameçonnage par device code

Cette attaque est plus difficile à réaliser pour un attaquant en raison de la faible durée de vie des « device codes » : ces derniers sont uniquement valables pendant une durée de 15min et doivent donc être générés peu de temps avant que l’utilisateur ne le renseigne. Cette attaque est donc plus facilement réalisable dans le cadre d’attaques par « phoning » ou de phishing via Teams. Par exemple, l’attaquant pourrait appeler la victime, prétexter faire partie de l’équipe du support IT de l’entreprise pour demander à l’utilisateur de s’authentifier sur le lien indiqué et de renseigner le code de son choix.

Pour se prémunir contre ce type d’attaque, les politiques d’accès conditionnel sur Azure permettent notamment d’interdire les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise.

L’attaque par consentement illicite

En plus de ces deux méthodes, l’attaque par consentement illicite permet aussi à un attaquant de récupérer un accès à un environnement Azure de manière illégitime. Cette dernière était même initialement plus simple à mettre en œuvre pour un attaquant que les attaques via l’authentification « device code ». Face à la recrudescence de cette menace, des actions ont été menées en 2020 par Microsoft pour limiter les conditions de réalisation de l’attaque. Si des configurations durcies d’Azure permettent de totalement bloquer cette menace, les configurations implémentées par certaines entreprises les exposent à ce type d’attaque. Quels sont les prérequis pour la réalisation d’une telle attaque, quelles sont les conséquences possibles et comment s’en prémunir ?

Qu’est-ce qu’une attaque par consentement illicite ?

Pour comprendre le principe de cette attaque, mettons-nous dans la peau d’un employé victime d’une telle attaque :

• La victime reçoit un mail d’hameçonnage indiquant une action urgente à réaliser pour maintenir son compte Microsoft activé. Les employés sont sensibilisés à ne pas cliquer sur des liens de phishing et à ne pas entrer leur mot de passe sur des plateformes inconnues. Le lien sous le format https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<CLIENT_ID>&redirect_uri=<Attacker_controled_URL>&response_type=code&response_mode=query&scope=Mail.ReadWrite%20Files.Read.All%20Mail.Send%20User.Read contient un domaine associé à Microsoft, ce qui rassure la victime.
• En cliquant sur le lien, la victime doit s’authentifier. Cette authentification est souvent automatique puisqu’elle bénéficie de l’authentification unique (SSO) de Microsoft. La victime reçoit alors une demande de délégation de permissions:

L’application malveillante demande à l’utilisateur de lui déléguer ses permissions

• Si la victime clique sur « Annuler » par prudence, elle est redirigée vers le serveur de l’attaquant avec une URL du type <Attacker_controled_URL>/?error=consent_required &error_description=AADSTS65004%3a+User+declined+to+consent+to+access+the+app.&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d65004#. L’attaquant, comprenant que la victime n’a pas accepté la délégation de permissions, peut ensuite rediriger la victime sur la page de phishing, lui donnant l’impression que les permissions demandées doivent être acceptées pour passer à l’étape suivante.
• En raison du nom de domaine légitime et la vue de l’urgence indiquée dans le mail d’hameçonnage, la victime de l’attaque choisit d’accepter. Elle observe alors un message indiquant que son compte sera bien maintenu activé, comme suggéré dans le mail initial. Elle reprend donc une activité normale.

Or, ce consentement permet à l’attaquant de réaliser des actions au nom de la victime, en fonction des permissions accordées. A noter que l’attaque par consentement illicite a de nombreux avantages pour un attaquant, notamment :

• L’utilisation d’une URL associée à Microsoft lors de la demande de consentement, considérée comme de confiance et impliquant donc moins de méfiance de la part des utilisateurs ciblés.
• L’obtention d’un accès persistant pendant 90 jours, sans connaissance du mot de passe de l’utilisateur ni du second facteur d’authentification, si aucune stratégie d’accès conditionnels n’est implémentée.
• La possibilité de requêter directement les APIs de Microsoft pour récupérer de manière automatisée les fichiers, emails et autres ressources de l’entreprise accessibles par l’utilisateur piégé.

Aparté technique

D’un point de vue technique, l’attaque par consentement illicite repose sur la capacité d’un attaquant à créer une application demandant des délégations de permissions. La délégation de permission est une fonctionnalité qui est régulièrement utilisée par les utilisateurs sans qu’ils s’en rendent compte, par exemple le client Outlook est autorisé par défaut à récupérer et les notifier de l’arrivée de nouveaux emails.

Voici les étapes clés lors de la réalisation de ce type d’attaque (qui repose sur la cinématique Authorization Code Grant d’OAuth 2.0) :

• L’attaquant crée une application d’entreprise sur Azure AD (application registration) et configure les permissions qu’il souhaite obtenir de la part des utilisateurs. Il peut instancier également un « client_secret» sur l’application. Certaines contraintes liées à cette application sont détaillées plus bas.
• Il met en place un serveur vers lequel les utilisateurs seront redirigés suite aux consentements et indique son URL en tant qu’URL de redirection valide pour l’application.
• À la suite du consentement d’un utilisateur, celui-ci sera redirigé vers le site malveillant et un code sera fourni à l’attaquant. Ce code est la preuve à montrer à Microsoft que l’utilisateur autorise l’application à faire des actions en son nom.
• A l’aide de ce code et du « client_secret » de l’application, l’attaquant pourra récupérer un jeton OAuth. Ce jeton est un récépissé signé par Microsoft qui précise les actions que la victime autorise à faire en son nom. L’attaquant peut également récupérer un « refresh_token » permettant de renouveler la validité du jeton OAuth.
• Ce jeton OAuth est alors utilisable pour envoyer des requêtes à la Graph API au nom de la victime et par conséquent permet d’usurper son identité.

Quelles sont les conséquences d’une telle attaque ?

Si certaines permissions nécessitent par défaut l’approbation d’un administrateur pour être déléguées, d’autres permissions peuvent être déléguées directement par les utilisateurs dans les environnements Azure non durcis. Les permissions pouvant être récupérées par l’attaquant lors de ce type d’attaque dépendent donc de la configuration du tenant Azure AD ciblé.

Voici quelques exemples d’abus possibles par un attaquant qui aurait réussi à récupérer les permissions d’un utilisateur sur un environnement non durci.

Actions réalisables à la suite d’une attaque par consentement illicite réussie sur en environnement Azure non durci

• Azure Active Directory :
  • La permission Microsoft Graph User.ReadBasic.All permet de récupérer les adresses email des tous les utilisateurs d’un tenant, ce qui permet de déployer des attaques de phishing à plus grande échelle à partir d’une première compromission.
• Outlook :
  • L’envoi d’un email au nom d’un utilisateur peut permettre la réalisation d’attaques dites de « fraude au président » à l’aide des permissions Microsoft Graph Mail.Send et Mail.ReadWrite. Un employé compromis disposant d’un niveau hiérarchique élevé pourrait par exemple demander par email l’envoi en urgence d’une somme important d’argent à un compte non répertorié par l’entreprise.
  • Les emails envoyés peuvent également être dissimulés à l’aide de règles de filtrage Outlook pouvant être modifiées à l’aide de la permission MailboxSettings.ReadWrite. L’attaquant pourra alors rediriger tous les emails liés à son attaque et les réponses associées vers un dossier différent des boites d’envoi et de réception.
• Teams :
  • La lecture et l’envoi de messages via Teams (Microsoft Graph Chat.ReadWrite) est une méthode efficace pour un attaquant d’usurper l’identité d’un utilisateur. Cette méthode peut également être utilisée pour réaliser des attaques de « fraude au président ».
• OneDrive et SharePoint :
  • L’accès en lecture aux fichiers accessibles sur OneDrive et SharePoint (Microsoft Graph Files.Read.All) peut donner accès à l’ensemble des fichiers accessibles par l’utilisateur. De plus, les droits d’accès aux fichiers SharePoint sont souvent stockés avec des droits d’accès permissifs ce qui permet aux attaquants de récupérer un très grand nombre de fichiers. Il n’est pas rare par exemple d’avoir à accès à des scripts ou fichiers de configurations contenant des mots de passe en clair.
  • Par ailleurs, les fonctionnalités de recherche de SharePoint, permettant notamment la lecture et l’indexation du contenu des fichiers Office, peuvent être utilisées afin de cibler certains mots clés tels que « mot de passe ».
  • Les droits d’écriture sur un fichier SharePoint (Microsoft Graph Files.ReadWrite.All) peuvent également avoir un impact important : les fonctionnalités de versioning de SharePoint limitent par défaut l’enregistrement des anciennes versions des fichiers à 100 versions. Cela signifie qu’en cas de réécritures automatisées et successives plus de 100 fois, la version initiale du fichier ne serait plus récupérable. Cela permettrait donc à un attaquant d’effacer un grand nombre de données en cas de compromission d’un compte disposant de droits d’écriture sur des fichiers sensibles. En cas d’effacement, il faudrait alors contacter le support Microsoft pour tenter de récupérer les données sur les sauvegardes quotidiennes à froid.
• OneNote :
  • Les fichiers OneNote synchronisés (Microsoft Graph Notes.ReadWrite ou Read.All) peuvent contenir des informations sensibles tels que des comptes-rendus de réunion, confidentielles, mais aussi des informations techniques telles que des mots de passes stockés de manière non sécurisée.
• Ressources Azure :
  • L’accès aux key vaults et storage accounts (Azure Key Vault et Azure Storage user_impersonation) peuvent donner accès à des éléments sensibles en cas de compromission de comptes de développeurs ou d’utilisateurs techniques. Ces éléments peuvent faciliter la compromission de ressources Azure telles que des machines virtuelles et servir de point de rebond pour un attaquant externe.

Ces actions peuvent avoir de graves impacts pour une entreprise. Par ailleurs, elles peuvent faciliter la réalisation d’attaques plus élaborées en divulguant des informations sensibles à un attaquant externe.

En cas d’approbation par un administrateur, des permissions plus sensibles peuvent être récupérées comme l’accès en écriture à l’ensemble des informations de l’annuaire Azure Active Directory.

Enfin, les administrateurs disposent du droit de déléguer à une application les permissions de tous les utilisateurs du tenant. Dans cette éventualité, l’identité de l’ensemble des utilisateurs pourraient être usurpée pour la permission déléguée.

La mise en place par Microsoft du « risk-based consent step up » pour limiter les attaques par consentement illicite

Face à cette menace Microsoft a implémenté en novembre 2020 des protections supplémentaires pour limiter l’impact de ce type d’attaques. La fonctionnalité de « risk-based consent step up » a pour objectif de lever un avertissement et de demander la validation d’un administrateur en cas de demande de permission semblant frauduleuse.

La demande d’accès depuis une application non vérifiée de droits considérés comme sensible est bloquée par défaut

Celle-ci s’applique dans le cas d’une demande de permissions par une application non vérifiée crée hors du tenant ciblée. Par défaut, toutes les permissions sont concernées, à l’exception de la lecture du profil de l’utilisateur cible, pour faciliter l’authentification unique (SSO) avec des applications tierces.

Cette restriction est implémentée par défaut sur tous les tenants Azure.

Si ces restrictions permettent de limiter les attaques, 3 types d’applications sont cependant toujours utilisables à des fins malveillantes : les applications « legacy », les applications internes au tenant ciblé et les applications vérifiées.

• Applications « legacy » :
  • Afin de permettre une rétrocompatibilité, aucun message d’avertissement n’est affiché pour une demande de permissions provenant d’une application créée avant novembre 2020.
  • Prérequis pour l’attaquant : disposer d’une application créée sur un tenant Azure avant novembre 2020 ou compromettre un tenant contenant de telles applications.
• Applications internes au tenant ciblé :
  • Ces applications ne sont pas couvertes par le « risk based consent step up ». Par défaut, tous les utilisateurs d’un tenant Azure disposent du droit de création d’une application d’entreprise sur leur tenant ce qui facilite la réalisation de l’attaque sur un environnement non durci.
  • Prérequis pour l’attaquant : disposer d’un premier compte compromis sur le SI de l’entreprise ciblée, s’apercevoir que la création des applications est autorisée pour les utilisateurs standards et déployer une application interne au tenant.
• Applications vérifiées :
  • Les applications vérifiées ne sont pas couvertes par le « risk based consent step up ». La procédure de vérification de Microsoft nécessite d’intégrer le Microsoft Partner Network.
  • Prérequis pour l’attaquant : disposer d’une application vérifiée ou compromettre un tenant Azure disposant d’applications vérifiées et détourner l’utilisation de ces applications légitimes.

Remédiations possibles

Afin de limiter la probabilité et l’impact de telles attaques, les recommandations suivantes peuvent être appliquées et adaptées au contexte de l’entreprise :

• Autoriser uniquement les applications explicitement approuvées par les administrateurs. Cette configuration est la plus sécurisée, mais l’étape de validation peut constituer un goulot d’étranglement puisque ce sont généralement les Global Administrators et Privileged Role Administrators qui doivent faire la validation. En pratique, certains droits peuvent être aussi délégués via les Cloud Application Administrators ou les Application Administrators.

Le consentement de délégation de privilèges par les utilisateurs standards peut être bloqué via les configurations Azure AD

• Limiter les permissions pour lesquelles les délégations peuvent être réalisées. Un administrateur peut spécifier les permissions à faible risque (Low) pour lesquelles les délégations peuvent être directement faites par les utilisateurs.

Le consentement de délégation de privilèges par les utilisateurs standards peut être limité aux droits considérés non sensibles via les configurations Azure AD

• Créer un processus de validation des applications légitimes et de admin consent workflow pour tracer et justifier ces validations. En durcissant les modalités d’octroi de consentements, il est nécessaire de conjointement mettre en place un manière simple et intuitive pour les utilisateurs de demander des dérogations pour déléguer des permissions liées à des cas d’usage légitimes. Ces exceptions doivent être tracées et justifiées afin de s’assurer de la légitimité des demandes.
• Faire une revue régulière des droits délégués aux applications (Entreprise applications) : les permissions déléguées par les utilisateurs doivent être revues afin de s’assurer que seules des applications légitimes disposent de droits sur les ressources Office 365 du tenant.

La revue régulière des applications disposant de droits sur un tenant Azure permet de valider que les privilèges octroyés sont toujours d’actualité

• Superviser les accès suspects aux ressources Office 365. Il est possible par exemple de mettre en place des règles d’alerte sur le nombre de fichiers téléchargés sur un temps court afin d’identifier les tentatives d’exfiltration de données.
• Limiter les droits d’accès aux fichiers SharePoint au strict nécessaire: les fichiers accessibles à tous les utilisateurs d’un tenant doivent être vérifiés à intervalle régulier et les droits d’accès aux fichiers les plus sensibles doivent être revus pour s’assurer que seules les personnes nécessaires y ont accès.

Conclusion

Les différentes attaques par phishing présentées dans cet article reposent sur un manque de durcissement des configurations Azure AD. La mise en place d’un second facteur d’authentification, bien que nécessaire face aux attaques par phishing traditionnelles, n’est pas suffisante pour se prémunir des autres attaques présentées. Pour les attaques via l’authentification « device code », les administrateurs peuvent mettre en place des politiques d’accès conditionnel pour limiter les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise. Pour les attaques par consentement illicite, la mesure la plus efficace consiste à autoriser uniquement les applications approuvées par les administrateurs.

Ces trois éléments de durcissement, bien que simples en apparence, peuvent faire l’objet de véritables chantiers de sécurisation afin de prendre en compte l’historique, notamment en s’assurant que les applications existantes ne soient pas bloquées par ces mesures, et en implémentant des processus de revues régulières et de validation des nouvelles applications.

Bibliographie

https://aadinternals.com/post/phishing/

https://jeffreyappel.nl/protect-against-oauth-consent-phishing-attempts-illicit-consent-attack/

https://positivethinking.tech/insights/what-is-an-illicit-consent-grant-attack-in-office-365/

https://docs.microsoft.com/en-us/azure/active-directory/develop/publisher-verification-overview

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/user-admin-consent-overview

https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent

https://www.microsoft.com/en-us/security/blog/2021/07/14/microsoft-delivers-comprehensive-solution-to-battle-rise-in-consent-phishing-emails

[1] https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code

Cet article Les attaques par consentement illicite ciblant Azure et Office 365 : une menace toujours d’actualité ? 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.

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.