Si les peurs autour de la sécurité du Cloud ont été quelque peu évacuées, il faut garder en mémoire que les protections généreusement fournies par les services cloud doivent encore être mises en place et gérées. Microsoft 365, avec ses 150 millions d’utilisateurs, ne déroge pas à cette règle, d’autant plus qu’il est particulièrement attrayant pour les cybercriminels de tous bords. Article paru dans L'Informaticien n°193.
Le « Solorigate » est le sujet de ce début 2021. L’ensemble du monde de l’informatique en parle. Il faut dire que ce ne sont pas que les agences fédérales américaines qui ont été espionnées. Les pirates ont eu accès également au code source de certains programmes de Microsoft. Ce qui pourrait mener à d’autres attaques, plus massives encore. Le géant de Redmond a pris les devants et ne ménage pas ses efforts pour nous inonder d’informations. L’éditeur a été jusqu’à mettre en place un Solorigate Resource Center (https://aka.ms/solorigate), particulièrement bien fourni et mis à jour régulièrement. Mais imaginons un instant que ce ne soit pas Microsoft 365, qui s’impose un peu partout, qui soit compromis, mais votre SI. Comment alors éviter que les attaquants ne compromettent votre environnement 365 tout entier, par federation trust relationships (1) ou synchronisation des comptes ? Dans ces lignes, il ne sera pas question de CASB ni d’outils tiers, mais bien de fonctionnalités de Microsoft 365, et des services qui y sont liés. Des basiques pour certains, sans doute, mais compte tenu du nombre d’attaques qui touchent au but, une piqûre de rappel ne fera pas de mal. Et avant toute chose, signalons que le centre de sécurité Microsoft 365 affiche un score de sécurité. Lequel donne un aperçu de la robustesse des défenses et moyens d’authentification en place, à l’aide d’un système de points qui renseigne en un coup d’œil les principales faiblesses. L’outil permet d’améliorer la sécurité des identités, données, applications, appareils et infrastructure Microsoft 365 en recommandant ainsi certaines tâches, mais aussi en se penchant sur les programmes tiers utilisés.
Des outils intégrés à Microsoft 365
Avant de commencer à pointer du doigt l’utilisateur lambda, commençons par les admins – vous qui nous lisez sans doute… Vous utilisez votre compte à privilège pour vous connecter à vos mails? Arrêtez tout de suite. Les comptes d’administration sont les victimes les plus lucratives pour les cybercriminels parce qu’ils disposent de privilèges élevés qui donnent accès à tout ou presque dans Microsoft 365. C’est pourquoi ils ne doivent servir qu’à l’administration. Allez donc créer un compte utilisateur bien distinct, sans privilège, pour toutes les tâches qui ne relèvent pas de l’administration. Et plus largement, il est nécessaire de connaître les besoins de chacun quant aux ressources, et à limiter les droits et accès qu’à ces seules ressources nécessaires à mener à bien sa mission. Ainsi, lorsqu’un compte du helpdesk est compromis, l’attaquant ne dispose que d’un accès aux ressources nécessaires au helpdesk, et non à l’ensemble du SI de l’entreprise.
Évidemment, la première bonne pratique qui vient à l’esprit en termes de sécurité est le mot de passe. Fort de préférence. S’il échoit bien souvent dans les organisations de taille modeste aux utilisateurs de définir leur mot de passe, les admins doivent garder à l’esprit que Azure Active Directory permet d’interdire par défaut une liste personnalisée de mots de passe. Ainsi, lorsque les utilisateurs modifient leur mot de passe, la liste est vérifiée de sorte à empêcher l’utilisation de mots de passe faibles. À noter que la liste personnalisée de mots de passe interdits est limitée à un maximum de 1 000 termes. Outre ceux propres à votre organisation (imaginons dans le cas de ce magazine un mot de passe «linformaticien » ou « magazine »), on trouve en ligne des listes prédéfinies des mots de passe faibles les plus utilisés, et auquel vous pouvez être sûr qu’un collaborateur aura recours pour Microsoft 365.
Deux facteurs valent mieux qu’un
Toutefois, si le Score de sécurité de Microsoft 365 nous apprend une chose, c’est bien de mettre en place l’authentification multifacteur. Le mot de passe, aussi robuste soit-il, peut être compromis, si l’utilisateur le renseigne par exemple sur une fausse page de connexion suite à un phishing efficace. D’où le MFA, qui exigera des utilisateurs qu’ils se connectent en utilisant le combo identifiant/mot de passe, mais aussi un autre facteur d’authentification, à l’instar d’un code reçu par SMS ou dans l’application Microsoft Authenticator, ou encore en utilisant Windows Hello.
L’activation du MFA peut être automatique pour peu que les « valeurs par défaut de sécurité » soient activées dans le Centre d’administration Azure Active Directory. Le MFA peut être obligatoire uniquement pour les administrateurs, ou pour tous les utilisateurs. À sa prochaine connexion, l’utilisateur sera invité à définir un second mode d’authentification. Rappelons à toutes fins utiles que mieux vaut utiliser des dispositifs FIDO plutôt que l’envoi d’un code par SMS, dont les chercheurs en sécurité démontrent depuis maintenant quelques temps que cette méthode est loin d’être sûre.
Selon la licence d’Azure AD choisie, il est possible de configurer des stratégies d’accès conditionnel plus précises que les valeurs de sécurité par défaut. Ici, l’administrateur va pouvoir définir des règles excluant des utilisateurs en fonction du risque utilisateur (par exemple un combo identifiant/mot de passe compromis) ou du risque connexion. Lequel est particulièrement pertinent pour des organisations dont l’ancrage est exclusivement local ou national. Il est en effet peu probable qu’un salarié d’une PME française dont tous les employés travaillent en France cherche à s’identifier depuis le Canada, la Russie ou la Corée du Nord. Notons que les règles d’accès conditionnel, tout comme les paramètres de sécurité par défaut permettent également de bloquer les tentatives d’authentification dites legacy, de protocoles quelque peu obsolètes tels que les anciens clients Office ou de vieux protocoles d’outils de messagerie.
Les e-mails, encore et toujours
La protection standard incluse dans Microsoft 365, sans coût supplémentaire, intègre donc ce Score de sécurité, la protection des mots de passe, les accès conditionnels ainsi que des fonctionnalités de MDM (Mobile Devices Management) et l’outil Information Rights Management qui permet de paramétrer les contrôles des accès aux données de l’entreprise. Pour un surcroît de sécurité, la version EMS (Enterprise Mobility & Security Services) de Microsoft 365 intègre du Threat Intelligence, afin notamment de détecter les comportements suspects, du DLP (Data Loss Prevention) et l’outil Advanced Threat Protection, qui va notamment fournir du filtrage des mails avec analyse des liens et des pièces jointes.
L’environnement Microsoft 365 inclut par défaut une protection contre les programmes malveillants, mais il est possible de l’étendre par plusieurs moyens, qui tous concernent les e-mails. Ainsi, dans le Centre de sécurité, il est possible d’édicter des règles bloquant les pièces jointes pour peu que l’extension du fichier soit particulièrement suspecte (les .chm, .msc, .wsh, pcd et autres .shs), ou du moins avertissant l’utilisateur d’un risque si l’extension est de nature à faire se lever un sourcil à tout RSSI qui se respecte, ou si la pièce jointe contient des macros. Toujours sur le sujet des e-mails – le saviez-vous? – il est possible de chiffrer les messages Microsoft 365, chiffrement fonctionnant avec Outlook.com, Yahoo!, Gmail et d’autres services de messagerie. Dans Outlook sur PC, il suffit pour ce faire de se rendre dans Options, puis dans Autorisations pour pouvoir chiffrer un message. Enfin, il semble indispensable d’autoriser les fonctions de logs et d’audit, gratuites dans Microsoft 365 et disponible contre paiement mensuel avec Azure AD, tandis que Azure Security Center ou Cloud App Security fournissent, eux, aussi des données sur l’utilisation ici des machines sous Windows Server, là de celles sous Windows 10.
(1) : Les relations d’approbation fédérées, à l’instar de l’authentification SAML, sont utilisées pour s’authentifier auprès de Microsoft 365 via une infrastructure d’identité locale. Si un certificat SAML est compromis, la fédération permet à toute personne possédant ce certificat d’usurper l’identité de n’importe quel utilisateur de votre cloud.
