Microsoft Teams est devenu un point central de la collaboration professionnelle. La plateforme regroupe les conversations instantanées, les réunions, les appels, les fichiers, les applications et les échanges avec des partenaires externes.
Cette concentration de services augmente naturellement les enjeux de sécurité. Une mauvaise configuration peut faciliter l’accès non maîtrisé aux réunions, l’exposition de documents sensibles, l’installation d’applications non approuvées ou le maintien d’invités devenus inutiles.
La sécurisation de Microsoft Teams ne peut donc pas se limiter aux paramètres disponibles dans le Centre d’administration Teams. Elle doit couvrir l’ensemble de l’écosystème Microsoft 365 :
- Microsoft Entra ID ;
- Microsoft Teams ;
- SharePoint Online ;
- OneDrive ;
- Exchange Online ;
- Microsoft Purview ;
- Microsoft Defender ;
- Microsoft Intune ;
- Microsoft Defender for Endpoint ;
- les applications et services tiers.
Ce guide présente les principaux contrôles à mettre en œuvre pour assurer une utilisation sécurisée et maîtrisée de Microsoft Teams.
Les objectifs de la sécurisation de Microsoft Teams
Une stratégie de sécurisation de Teams doit poursuivre plusieurs objectifs complémentaires :
- protéger les identités des utilisateurs ;
- sécuriser les comptes administratifs ;
- contrôler les accès externes ;
- maîtriser les comptes invités ;
- protéger les réunions sensibles ;
- encadrer les participants anonymes ;
- contrôler les applications et les bots ;
- sécuriser les fichiers partagés ;
- protéger les informations sensibles ;
- surveiller les activités inhabituelles ;
- préparer la réponse aux incidents ;
- organiser le cycle de vie des équipes.
L’objectif n’est pas de supprimer la collaboration externe, mais de l’organiser selon le niveau de risque et la sensibilité des informations manipulées.
1. Comprendre le périmètre de sécurité de Teams
Microsoft Teams ne stocke pas seul l’ensemble des informations utilisées par les collaborateurs.
Selon le type de contenu, plusieurs services Microsoft 365 interviennent :
- les identités sont gérées dans Microsoft Entra ID ;
- les fichiers des équipes et des canaux sont stockés dans SharePoint Online ;
- certains fichiers partagés dans les conversations utilisent OneDrive ;
- les calendriers et invitations reposent sur Exchange Online ;
- les étiquettes de sensibilité et les politiques DLP reposent sur Microsoft Purview ;
- la protection des liens et des fichiers utilise les capacités de Microsoft Defender ;
- les conditions d’accès peuvent dépendre de Microsoft Entra Conditional Access et de Microsoft Intune.
Une configuration sécurisée de Teams doit donc être cohérente avec les autres composants Microsoft 365.
2. Protéger les identités avec Microsoft Entra ID
La protection de Teams commence par celle des identités.
Un attaquant qui compromet un compte utilisateur peut potentiellement accéder aux conversations, aux équipes, aux réunions et aux fichiers auxquels cette identité est autorisée.
Les mesures prioritaires comprennent :
- l’authentification multifacteur ;
- les stratégies Conditional Access ;
- la protection des comptes administratifs ;
- la gestion des comptes invités ;
- le contrôle des terminaux ;
- la surveillance des connexions à risque ;
- la révocation des sessions lors d’un incident.
Généraliser l’authentification multifacteur
La MFA doit être imposée aux utilisateurs autorisés à accéder à Microsoft Teams.
Une stratégie renforcée doit être appliquée aux comptes sensibles :
- Global Administrator ;
- Teams Administrator ;
- SharePoint Administrator ;
- Security Administrator ;
- Conditional Access Administrator ;
- comptes de support ;
- comptes techniques disposant de privilèges.
Pour les administrateurs et les populations sensibles, il est recommandé d’étudier des méthodes d’authentification résistantes au phishing :
- Windows Hello for Business ;
- clés de sécurité FIDO2 ;
- passkeys ;
- authentification par certificat lorsque le contexte le justifie.
Séparer les comptes administratifs
Un administrateur Teams ne devrait pas utiliser quotidiennement son compte privilégié pour consulter sa messagerie, naviguer sur Internet ou participer à des réunions.
Une séparation doit être mise en place entre :
- le compte bureautique ;
- le compte administratif.
Exemple :
Compte bureautique : prenom.nom@organisation.mc
Compte administratif : prenom.nom.adm@organisation.mc
Le compte administratif doit disposer uniquement des permissions nécessaires à sa fonction.
3. Appliquer Conditional Access à Teams
Conditional Access permet de contrôler les conditions dans lesquelles un utilisateur peut accéder à Microsoft Teams et aux services associés.
Les stratégies doivent notamment prendre en compte :
- le type d’utilisateur ;
- le rôle administratif ;
- le niveau de risque ;
- l’état du terminal ;
- la localisation ;
- l’application utilisée ;
- la sensibilité des ressources.
Les principales politiques à envisager sont les suivantes :
Protection des administrateurs
Imposer une authentification forte et, lorsque l’architecture le permet, un accès depuis un appareil maîtrisé.
Protection des utilisateurs
Exiger une authentification multifacteur selon la politique de sécurité de l’organisation.
Protection des invités
Appliquer des contrôles adaptés aux utilisateurs externes et aux identités invitées.
Terminaux non maîtrisés
Limiter certaines opérations depuis les équipements personnels ou non conformes, notamment le téléchargement de documents sensibles.
Connexions à risque
Renforcer ou bloquer l’accès lorsque Microsoft Entra ID identifie une connexion présentant un niveau de risque important.
Toute nouvelle stratégie doit être testée progressivement :
- conception de la politique ;
- identification des exclusions nécessaires ;
- activation en mode Report-only ;
- analyse des résultats ;
- test sur une population pilote ;
- correction des effets indésirables ;
- activation progressive ;
- documentation de la configuration.
4. Distinguer l’accès externe et l’accès invité
Microsoft Teams propose plusieurs mécanismes permettant de collaborer avec des personnes extérieures à l’organisation.
Ils ne fournissent pas le même niveau d’accès.
Accès externe
L’accès externe permet à des utilisateurs appartenant à une autre organisation Teams de communiquer avec les utilisateurs internes.
Les fonctionnalités concernent principalement :
- les conversations ;
- les appels ;
- la présence ;
- certaines interactions inter-organisations.
Accès invité
Un utilisateur invité possède une identité dans le tenant de l’organisation.
Il peut être ajouté comme membre d’une équipe et accéder aux ressources autorisées, notamment certains canaux et documents.
Participant anonyme
Un participant anonyme peut rejoindre une réunion sans utiliser une identité organisationnelle vérifiée.
Ce type d’accès doit être traité avec davantage de précautions dans les réunions sensibles.
5. Sécuriser l’accès externe
L’accès externe peut être configuré selon plusieurs modèles :
- ouverture à toutes les organisations ;
- ouverture générale avec blocage de certains domaines ;
- autorisation limitée à certains domaines ;
- fermeture complète.
Pour un environnement institutionnel, une ouverture contrôlée peut être privilégiée lorsque les besoins métier le permettent.
Les partenaires réguliers peuvent être autorisés selon des domaines précisément identifiés.
Avant d’autoriser un domaine, il convient de vérifier :
- l’identité du partenaire ;
- la justification métier ;
- la durée du partenariat ;
- la nature des échanges prévus ;
- la sensibilité des informations ;
- le propriétaire interne de la relation.
Une politique trop restrictive peut toutefois déplacer les échanges vers la messagerie ou des outils non maîtrisés. La décision doit donc prendre en compte le risque et les usages opérationnels.
6. Maîtriser les comptes invités
Les utilisateurs invités doivent être intégrés dans un véritable cycle de vie.
Le processus recommandé est le suivant :
Invitation → validation → création de l’identité → accès à l’équipe → revue périodique → maintien ou suppression.
Chaque compte invité doit idéalement disposer :
- d’une justification métier ;
- d’un responsable interne ;
- d’un périmètre d’accès identifié ;
- d’une durée adaptée au besoin ;
- d’une date de révision ;
- d’une procédure de suppression.
Les propriétaires d’équipes doivent régulièrement vérifier :
- que les invités ont toujours besoin de leur accès ;
- qu’ils travaillent toujours avec l’organisation ;
- que leurs permissions restent adaptées ;
- qu’ils n’accèdent pas à des canaux devenus sensibles.
Les invités inutilisés ou dont la justification n’est plus valide doivent être supprimés.
7. Sensibiliser aux indicateurs de confiance
Teams affiche différents éléments visuels permettant d’identifier les personnes extérieures à l’organisation.
Les utilisateurs doivent apprendre à distinguer :
- les collaborateurs internes ;
- les utilisateurs externes ;
- les invités ;
- les participants non vérifiés ;
- les bots ou assistants externes.
Avant de partager une information sensible, l’utilisateur doit se poser trois questions :
- Qui participe réellement à la conversation ou à la réunion ?
- Quelle est la sensibilité de l’information ?
- Chaque participant doit-il recevoir cette information ?
La liste des participants doit être vérifiée avant le début d’une réunion sensible et après l’arrivée d’un nouveau participant.
8. Sécuriser les réunions Teams
Les réunions Teams constituent un périmètre particulièrement exposé.
Elles peuvent associer :
- collaborateurs internes ;
- prestataires ;
- invités ;
- participants anonymes ;
- utilisateurs appelant par téléphone ;
- applications ;
- bots de prise de notes ;
- assistants utilisant l’intelligence artificielle.
Les paramètres à examiner comprennent :
- la salle d’attente ;
- les participants anonymes ;
- les présentateurs ;
- le partage d’écran ;
- la prise de contrôle ;
- l’enregistrement ;
- la transcription ;
- Copilot ;
- les applications de réunion ;
- les bots externes ;
- les rapports de présence.
9. Utiliser la salle d’attente
La salle d’attente permet de contrôler les personnes admises dans une réunion.
Pour les réunions sensibles, les participants externes et anonymes ne devraient pas rejoindre automatiquement la réunion.
L’organisateur doit pouvoir vérifier :
- le nom affiché ;
- le domaine de l’organisation ;
- la présence attendue de la personne ;
- le statut externe ou invité ;
- l’éventuelle présence d’un bot.
Pour les réunions présentant un niveau de risque élevé, l’admission depuis la salle d’attente doit être réservée aux organisateurs et co-organisateurs.
10. Encadrer les participants anonymes
Les participants anonymes présentent un niveau de confiance plus faible qu’un utilisateur authentifié.
L’accès anonyme peut rester nécessaire pour certains événements :
- réunions publiques ;
- événements ouverts ;
- webinaires ;
- assistance à des personnes ne disposant pas d’un compte compatible.
En revanche, il doit être désactivé ou fortement encadré pour les réunions manipulant :
- des informations de sécurité ;
- des données personnelles ;
- des informations juridiques ;
- des informations financières ;
- des documents classifiés ;
- des informations stratégiques.
Un participant anonyme ne doit pas être autorisé à démarrer seul une réunion.
11. Limiter les présentateurs
Tous les participants n’ont pas besoin de disposer du rôle de présentateur.
Le principe du moindre privilège doit également être appliqué pendant les réunions.
Le modèle recommandé est le suivant :
- organisateur ;
- co-organisateurs ;
- présentateurs explicitement désignés ;
- participants.
Pour les réunions sensibles, il convient d’éviter que tous les participants deviennent automatiquement présentateurs.
Cette restriction réduit les risques d’action accidentelle ou malveillante pendant la réunion.
12. Bloquer la prise de contrôle externe
La prise de contrôle permet à une personne d’interagir avec l’écran ou la fenêtre partagée par un présentateur.
Cette fonctionnalité peut être utile dans certains scénarios de support, mais elle augmente également le niveau de risque.
Sauf besoin métier validé, les participants externes ne devraient pas être autorisés à prendre le contrôle :
- d’un ordinateur ;
- d’un bureau partagé ;
- d’une application ;
- d’une fenêtre contenant des informations sensibles.
Si un scénario de support nécessite cette capacité, une politique spécifique doit être créée pour la population concernée plutôt que d’activer la fonctionnalité globalement.
13. Sécuriser le partage d’écran
Le partage d’écran peut provoquer une fuite accidentelle d’informations.
Un utilisateur peut afficher involontairement :
- une notification Outlook ;
- un message Teams ;
- une console d’administration ;
- des données personnelles ;
- un document confidentiel ;
- un mot de passe ;
- un secret applicatif ;
- les coordonnées d’un utilisateur.
Pour les réunions externes, il est préférable de partager une fenêtre spécifique plutôt que l’intégralité du bureau.
Avant le partage, l’utilisateur doit :
- fermer les documents inutiles ;
- masquer les informations sensibles ;
- désactiver les notifications ;
- vérifier les participants ;
- contrôler la classification du document ;
- utiliser un profil utilisateur adapté.
14. Contrôler les bots externes
Les bots de réunion peuvent assurer différentes fonctions :
- transcription ;
- prise de notes ;
- résumé automatique ;
- analyse des échanges ;
- enregistrement ;
- traduction ;
- intégration avec un service tiers.
Un bot peut cependant transmettre le contenu d’une réunion vers une plateforme externe.
Les bots détectés doivent rester dans la salle d’attente jusqu’à leur admission explicite.
L’organisateur doit vérifier :
- le nom du bot ;
- son éditeur ;
- son propriétaire ;
- sa finalité ;
- les données collectées ;
- le lieu de traitement des informations ;
- les conditions de conservation ;
- la justification de sa présence.
L’admission des bots doit être réservée aux organisateurs ou co-organisateurs.
La détection des bots ne doit être désactivée que pour un scénario métier identifié, documenté et validé.
15. Encadrer les enregistrements
Un enregistrement de réunion constitue une nouvelle copie des informations échangées.
Il peut contenir :
- de l’audio ;
- de la vidéo ;
- un écran partagé ;
- des données personnelles ;
- des informations confidentielles ;
- le nom ou l’image des participants.
L’organisation doit définir :
- qui peut démarrer un enregistrement ;
- pour quels types de réunions ;
- où l’enregistrement est stocké ;
- qui peut y accéder ;
- combien de temps il est conservé ;
- comment il est supprimé ;
- comment les participants sont informés.
L’enregistrement automatique ne doit pas être activé sans justification.
16. Encadrer les transcriptions et Copilot
Une transcription transforme les échanges oraux en contenu textuel exploitable.
Ce contenu peut ensuite être utilisé pour produire :
- un résumé ;
- une liste de décisions ;
- des actions ;
- une recherche ;
- une synthèse par Copilot.
Une politique doit préciser les réunions pour lesquelles la transcription est autorisée.
Les réunions sensibles peuvent nécessiter :
- la désactivation de la transcription ;
- une autorisation réservée à l’organisateur ;
- une durée de conservation limitée ;
- des contrôles d’accès renforcés ;
- une information explicite des participants.
L’utilisation de Copilot dans les réunions doit être alignée sur la politique de transcription, la classification des informations et les règles de conservation.
17. Créer plusieurs profils de réunion
Une politique unique ne permet pas toujours de couvrir correctement tous les cas d’usage.
Il est préférable de définir plusieurs niveaux.
Réunion standard
Destinée à la collaboration quotidienne entre utilisateurs internes.
Réunion externe
Destinée aux échanges avec des partenaires ou prestataires.
Elle doit appliquer des contrôles renforcés sur :
- la salle d’attente ;
- le partage d’écran ;
- les présentateurs ;
- les participants anonymes ;
- les bots.
Réunion sensible
Destinée aux échanges contenant des informations internes sensibles.
Elle peut nécessiter :
- uniquement des participants authentifiés ;
- un contrôle strict de la salle d’attente ;
- des présentateurs explicitement désignés ;
- la désactivation de l’enregistrement ;
- la désactivation de la transcription ;
- une limitation des applications de réunion.
Réunion hautement sensible
Destinée aux sujets de sécurité, de direction, d’investigation ou aux informations stratégiques.
Elle peut nécessiter les restrictions les plus fortes, selon les licences disponibles et la politique de l’organisation.
18. Exploiter les fonctions de Teams Premium
Teams Premium propose des mécanismes supplémentaires pouvant être utilisés pour les réunions sensibles.
Selon les fonctionnalités disponibles, l’organisation peut étudier :
- les filigranes sur les vidéos ;
- les filigranes sur le contenu partagé ;
- les modèles de réunion ;
- les étiquettes de sensibilité appliquées aux réunions ;
- les contrôles renforcés sur les enregistrements ;
- la détection de contenu sensible pendant le partage.
Ces fonctions doivent être ciblées selon la sensibilité des réunions plutôt qu’appliquées indistinctement à tous les utilisateurs.
19. Sécuriser les fichiers partagés
Les fichiers Teams reposent principalement sur SharePoint Online et OneDrive.
La sécurisation documentaire doit donc couvrir :
- le partage externe ;
- les liens anonymes ;
- les liens accessibles à toute l’organisation ;
- les permissions des équipes ;
- les permissions des sites SharePoint associés ;
- les membres et propriétaires ;
- les invités ;
- les documents sensibles ;
- les appareils utilisés pour accéder aux fichiers.
Le niveau de partage doit être cohérent avec la classification du document.
20. Utiliser Microsoft Purview
Microsoft Purview Information Protection permet d’organiser la classification et la protection des données.
Une classification peut par exemple reposer sur trois niveaux.
Information Publique
Information dont la diffusion est autorisée.
Information Interne
Information destinée à un usage interne ou institutionnel.
Diffusion Restreinte
Information sensible nécessitant une protection et un contrôle renforcés.
Selon la classification, les mesures peuvent comprendre :
- marquage visuel ;
- chiffrement ;
- restrictions d’accès ;
- limitation du partage externe ;
- limitation de l’impression ;
- contrôle du téléchargement ;
- protection des réunions ;
- application de politiques DLP.
La classification doit être compréhensible par les utilisateurs et associée à des règles concrètes.
21. Déployer des politiques DLP
Les politiques Data Loss Prevention permettent de détecter et de contrôler certaines informations sensibles dans Microsoft 365.
Pour Teams, une politique DLP peut contribuer à limiter le partage d’informations sensibles dans les conversations et les canaux.
Le déploiement doit être progressif :
- identifier les données sensibles ;
- créer une politique pilote ;
- utiliser un mode de simulation ou d’audit ;
- analyser les événements ;
- ajuster les conditions ;
- informer les utilisateurs ;
- activer les restrictions nécessaires ;
- mesurer les faux positifs.
Il est déconseillé de commencer directement par un blocage global.
22. Protéger les liens et les fichiers
Les conversations Teams peuvent être utilisées pour transmettre :
- des liens de phishing ;
- des fichiers malveillants ;
- des documents hébergés sur des plateformes externes ;
- des invitations vers de faux services Microsoft.
La protection doit être étudiée conjointement avec Microsoft Defender, SharePoint Online et OneDrive.
Il faut notamment vérifier :
- la protection des URL ;
- l’analyse des fichiers ;
- le blocage des éléments identifiés comme malveillants ;
- le signalement des messages ;
- les alertes de sécurité ;
- les procédures d’investigation.
Les utilisateurs doivent pouvoir signaler rapidement une activité ou un contenu suspect.
23. Désactiver l’intégration e-mail des canaux si elle n’est pas utilisée
L’intégration e-mail permet d’envoyer un message électronique directement vers un canal Teams.
Cette fonctionnalité peut être utile, mais elle crée également un chemin d’entrée supplémentaire pour du contenu externe.
Si aucun besoin métier ne la justifie, sa désactivation doit être envisagée.
Si elle reste utilisée, il convient de définir :
- les équipes autorisées ;
- les expéditeurs autorisés ;
- les contrôles appliqués ;
- la surveillance des messages reçus ;
- la procédure de traitement des abus.
24. Gouverner les applications Teams
Les applications Teams peuvent accéder à des données ou connecter Teams à des services externes.
L’organisation doit distinguer :
- les applications Microsoft ;
- les applications tierces ;
- les applications personnalisées ;
- les bots ;
- les connecteurs ;
- les extensions de message.
Un processus d’autorisation doit être mis en place :
Demande → analyse fonctionnelle → analyse de sécurité → analyse des permissions → validation → déploiement → surveillance → révision.
Chaque application doit disposer :
- d’un propriétaire ;
- d’une justification métier ;
- d’une liste de permissions validées ;
- d’un éditeur identifié ;
- d’une date de révision ;
- d’une procédure de retrait.
Les applications inutilisées ou présentant des permissions excessives doivent être bloquées ou supprimées.
25. Gouverner la création des équipes
Une création incontrôlée des équipes entraîne progressivement :
- des espaces abandonnés ;
- des propriétaires absents ;
- des invités oubliés ;
- des documents obsolètes ;
- des permissions difficiles à comprendre ;
- une augmentation du risque de fuite.
Le cycle de vie recommandé est le suivant :
Création → utilisation → revue → archivage → suppression.
Chaque équipe doit disposer :
- d’une finalité ;
- d’au moins un propriétaire actif ;
- d’un niveau de sensibilité ;
- d’une population définie ;
- d’une date de révision ;
- d’une règle d’archivage ou de suppression.
26. Contrôler les canaux partagés et privés
Les canaux privés et partagés doivent faire l’objet d’une attention spécifique.
Ils peuvent créer des périmètres de collaboration différents de celui de l’équipe principale.
Il convient de vérifier :
- les personnes autorisées à créer ces canaux ;
- les membres réels ;
- les propriétaires ;
- les organisations externes concernées ;
- la sensibilité des documents ;
- la durée de la collaboration ;
- les sites SharePoint associés.
Les canaux partagés ne doivent pas devenir un moyen de contourner les procédures de validation des accès externes.
27. Protéger les terminaux
Une configuration Teams sécurisée ne suffit pas si les données sont consultées depuis un terminal compromis ou non maîtrisé.
La stratégie doit associer Teams aux capacités disponibles dans :
- Microsoft Entra Conditional Access ;
- Microsoft Intune ;
- Microsoft Defender for Endpoint ;
- Microsoft Purview ;
- les contrôles de session.
Pour les populations sensibles, certaines opérations peuvent être réservées aux appareils gérés ou conformes.
Selon le contexte, les restrictions peuvent concerner :
- le téléchargement ;
- la synchronisation ;
- le copier-coller ;
- l’impression ;
- l’accès hors ligne ;
- le partage vers une application personnelle.
28. Auditer les activités Teams
Un environnement sécurisé doit être observable.
L’organisation doit pouvoir investiguer les événements importants concernant :
- les modifications de stratégies ;
- les changements administratifs ;
- la création d’équipes ;
- l’ajout de membres ;
- l’ajout d’invités ;
- les changements de propriétaires ;
- les applications ;
- les bots ;
- le partage de fichiers ;
- les activités inhabituelles ;
- les opérations sur les données sensibles.
Les journaux doivent être accessibles aux équipes chargées de la sécurité.
Lorsque l’architecture le prévoit, ils peuvent être centralisés dans Microsoft Sentinel ou dans un autre SIEM.
29. Configurer les alertes de sécurité
Des alertes doivent être définies pour les scénarios présentant le plus de risques.
Exemples :
- ajout inhabituel d’utilisateurs externes ;
- création massive d’équipes ;
- téléchargement massif de fichiers ;
- modification d’une stratégie Teams ;
- ajout d’une application non approuvée ;
- consentement accordé à une application sensible ;
- activité inhabituelle d’un administrateur ;
- accès depuis une localisation ou un appareil à risque ;
- utilisation inhabituelle d’un bot ;
- partage externe d’un document sensible.
Chaque alerte doit être associée à une procédure de qualification.
30. Préparer la réponse aux incidents
La sécurisation doit inclure des procédures opérationnelles.
Compromission d’un compte Teams
Les actions peuvent comprendre :
- confirmer l’identité de l’utilisateur ;
- bloquer temporairement la connexion ;
- révoquer les sessions ;
- réinitialiser les secrets concernés ;
- contrôler les méthodes MFA ;
- examiner les connexions récentes ;
- vérifier les conversations et équipes concernées ;
- rechercher les fichiers partagés ;
- contrôler les applications autorisées ;
- supprimer les accès suspects ;
- documenter l’incident ;
- corriger la cause initiale.
Équipe exposée accidentellement
Il faut identifier :
- les propriétaires ;
- les membres ;
- les invités ;
- les canaux ;
- les fichiers ;
- les liens de partage ;
- les informations potentiellement exposées ;
- les accès devant être révoqués.
Application ou bot suspect
L’investigation doit examiner :
- les permissions accordées ;
- l’éditeur ;
- les utilisateurs concernés ;
- les données accessibles ;
- la période d’activité ;
- les actions effectuées ;
- les éventuels transferts de données.
31. Prioriser les actions
Priorité 1 : mesures critiques
- généraliser la MFA ;
- protéger les comptes administratifs ;
- appliquer Conditional Access ;
- maîtriser les participants anonymes ;
- sécuriser la salle d’attente ;
- limiter la prise de contrôle externe ;
- contrôler les applications et bots ;
- vérifier le partage externe ;
- sécuriser les fichiers SharePoint et OneDrive.
Priorité 2 : mesures importantes
- organiser le cycle de vie des invités ;
- limiter les présentateurs ;
- encadrer les enregistrements ;
- encadrer les transcriptions et Copilot ;
- déployer une classification Purview ;
- vérifier les protections Defender ;
- auditer les applications Teams ;
- organiser le cycle de vie des équipes.
Priorité 3 : amélioration de la maturité
- déployer les politiques DLP ;
- créer plusieurs profils de réunion ;
- utiliser les protections Teams Premium ;
- automatiser les revues d’accès ;
- centraliser les événements dans un SIEM ;
- tester régulièrement les procédures d’incident ;
- réaliser une revue périodique de la baseline Teams.
32. Checklist de sécurisation Microsoft Teams
Identités
- La MFA est généralisée.
- La MFA est renforcée pour les administrateurs.
- Les comptes administratifs sont séparés.
- Conditional Access protège Teams.
- Les utilisateurs à risque sont pris en compte.
- Les appareils non maîtrisés font l’objet de restrictions adaptées.
- Les méthodes résistantes au phishing sont étudiées.
Accès externes et invités
- L’accès externe est documenté.
- Les domaines autorisés sont maîtrisés.
- L’accès grand public est évalué.
- L’accès invité est documenté.
- Chaque invité possède une justification.
- Les invités sont régulièrement révisés.
- Les comptes inutilisés sont supprimés.
- Les propriétaires d’équipes connaissent leurs responsabilités.
Réunions
- La salle d’attente est configurée.
- Les participants anonymes sont maîtrisés.
- Les utilisateurs anonymes ne peuvent pas démarrer une réunion.
- Le contournement de la salle d’attente est contrôlé.
- Les présentateurs sont limités.
- Le partage d’écran est encadré.
- La prise de contrôle externe est désactivée lorsqu’elle n’est pas nécessaire.
- Les enregistrements sont encadrés.
- Les transcriptions sont encadrées.
- L’utilisation de Copilot est documentée.
- Les bots externes nécessitent une approbation.
Données
- Le partage SharePoint Online est maîtrisé.
- Le partage OneDrive est maîtrisé.
- Les liens anonymes sont contrôlés.
- Les étiquettes de sensibilité sont déployées.
- Les politiques DLP sont évaluées.
- Les documents sensibles disposent de protections adaptées.
- Les canaux privés et partagés sont contrôlés.
Applications
- Les applications Teams sont inventoriées.
- Les applications tierces sont évaluées.
- Les permissions sont examinées.
- Chaque application possède un propriétaire.
- Les bots sont inventoriés.
- Les applications inutilisées sont supprimées.
- Un processus d’autorisation est documenté.
Menaces
- La protection des URL est vérifiée.
- L’analyse des fichiers est vérifiée.
- Les contenus malveillants sont bloqués.
- Les utilisateurs peuvent signaler un contenu suspect.
- Les alertes pertinentes sont configurées.
- Les événements sont accessibles aux équipes de sécurité.
Gouvernance
- La création des équipes est gouvernée.
- Chaque équipe possède un propriétaire actif.
- Les équipes abandonnées sont détectées.
- Une procédure d’archivage existe.
- Une procédure de suppression existe.
- Les politiques sont régulièrement révisées.
- Les changements sont documentés.
Réponse aux incidents
- Une procédure de compromission de compte existe.
- Une procédure d’exposition accidentelle existe.
- Une procédure concernant les applications suspectes existe.
- Les sessions peuvent être révoquées rapidement.
- Les équipes de sécurité savent retrouver les événements.
- Les procédures sont régulièrement testées.
Conclusion
La sécurisation de Microsoft Teams ne repose pas sur un paramètre unique.
Elle nécessite une approche globale associant :
Microsoft Entra ID → Conditional Access → Teams → SharePoint Online → OneDrive → Microsoft Purview → Microsoft Defender → terminaux → supervision.
Les premières actions doivent porter sur la protection des identités, la MFA, les comptes administratifs, les accès externes, les invités et les politiques de réunion.
La protection doit ensuite être étendue aux fichiers, aux applications, aux bots, aux enregistrements, aux transcriptions et aux données sensibles.
Enfin, l’audit, les alertes et les procédures de réponse aux incidents permettent de transformer les paramètres techniques en un dispositif de sécurité réellement opérationnel.
La sécurité de Microsoft Teams doit faire l’objet d’une amélioration continue. Les politiques doivent être testées, documentées, révisées et adaptées à l’évolution des usages ainsi qu’aux nouveaux risques
