Les migrations vers la plateforme de Digital Workplace de Microsoft, Office 365, (solution majoritairement adoptée par les grands comptes français) sont bien avancées, voire terminées. L’heure est maintenant à l’amélioration des processus, mais également, et surtout enfin, à la sécurisation.
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
- 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.)
- Configuration d’un export automatique des journaux identifiés vers un stockage externe (via PowerShell ou les API Management) ;
- 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).
- (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é ;
- (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.
