Sécurité et Skype Entreprise En ligne

• S’applique à:

  Skype for Business, Skype for Business Online, Microsoft Teams

Important

Skype Entreprise Online exploité par 21Vianet en Chine sera mis hors service le 1er octobre 2023. Si vous n’avez pas encore mis à niveau vos utilisateurs Skype Entreprise Online, ils sont automatiquement planifiés pour une mise à niveau assistée. Si vous souhaitez mettre à niveau votre organization vers Teams vous-même, nous vous recommandons vivement de commencer à planifier votre chemin de mise à niveau dès aujourd’hui. N’oubliez pas qu’une mise à niveau réussie aligne la préparation technique et la préparation des utilisateurs. Veillez donc à tirer parti de nos conseils de mise à niveau lorsque vous naviguez vers Teams.

Skype Entreprise Online, à l’exception du service exploité par 21Vianet en Chine, a été mis hors service le 31 juillet 2021.

Skype Entreprise Online (SfBO), dans le cadre des services Microsoft 365 et Office 365, suit toutes les bonnes pratiques et procédures de sécurité telles que la sécurité au niveau du service par le biais d’une défense en profondeur, les contrôles clients au sein du service, le renforcement de la sécurité et les meilleures pratiques opérationnelles. Pour plus d’informations, consultez le Centre de gestion de la confidentialité Microsoft (https://microsoft.com/trustcenter).

Confiance en conception

Skype Entreprise Online est conçu et développé dans le respect du Microsoft Trustworthy Computing Security Development Lifecycle (SDL), décrit à https://www.microsoft.com/sdl/default.aspx. Pour créer un système de communications unifiées plus sûr, la première étape a consisté à concevoir des modèles de menace, puis à tester chaque nouvelle fonctionnalité durant sa conception. Plusieurs améliorations liées à la sécurité ont été intégrées au processus et aux pratiques de codage. Au moment de la création, des outils détectent les dépassements de mémoire tampon et d’autres risques de sécurité potentiels avant l’archivage du code dans le produit final. Il est impossible de concevoir contre toutes les menaces de sécurité inconnues. Aucun système ne peut garantir une sécurité totale. Toutefois, étant donné que le développement de produits a adopté les principes de conception sécurisée dès le départ, Skype Entreprise Online intègre des technologies de sécurité standard comme partie fondamentale de son architecture.

Fiable par défaut

Les communications réseau dans Skype Entreprise Online sont chiffrées par défaut. Avec l’exigence que tous les serveurs utilisent des certificats et avec l'utilisation d'OAUTH, de TLS, du protocole SRTP (Secure Real-Time Transport Protocol) et d'autres techniques de chiffrement standard, notamment le chiffrement AES (Advanced Encryption Standard) 256 bits, toutes les données de Skype Entreprise Online sont protégées sur le réseau.

Comment SFBO gère-t-il les menaces de sécurité courantes

Cette section identifie les menaces les plus courantes pour la sécurité du service SfBO et la façon dont Microsoft atténue chaque menace.

Attaques par clé compromise

Une clé est un code ou un nombre secret utilisé pour chiffrer, déchiffrer ou valider des informations confidentielles. Deux clés sensibles utilisées dans l’infrastructure à clé publique (PKI) doivent être prises en compte : la clé privée de chaque détenteur de certificat et la clé de session utilisée après une identification réussie et un échange de clés de session par les partenaires communicants. Une attaque par clé compromise se produit lorsqu’un intrus parvient à identifier la clé privée ou la clé de session. Lorsque l’intrus parvient à déterminer la clé, il s’en sert pour déchiffrer des données chiffrées, à l’insu de l’expéditeur des données.

Skype Entreprise Online utilise les fonctionnalités PKI du système d’exploitation Windows Server pour protéger les données de clé utilisées pour le chiffrement des connexions TLS (Transport Layer Security). Les clés utilisées pour le chiffrement multimédia sont échangées via des connexions TLS.

Attaque par déni de service réseau

L’attaque par déni de service se produit lorsque l’agresseur empêche l’utilisation normale du réseau et la fonctionnement par des utilisateurs valides. À l’aide d’une attaque par déni de service, l’agresseur peut :

• envoyer des données non valides à des applications et des services exécutés sur le réseau faisant l’objet de l’attaque, afin de perturber leur exécution normale ;
• envoyer un volume de trafic important, de manière à surcharger le système jusqu’à ce que celui-ci cesse de fonctionner ou nécessite beaucoup de temps pour répondre aux demandes légitimes ;
• masquer les signes d’attaque ;
• empêcher les utilisateurs d’accéder aux ressources réseau.

SfBO atténue ces attaques en exécutant la protection réseau Azure DDOS et en limitant les demandes des clients à partir des mêmes points de terminaison, sous-réseaux et entités fédérées.

Protection contre l’écoute

Une attaque par écoute peut se produire lorsqu’une personne malveillante parvient à accéder au chemin d’accès des données d’un réseau et qu’elle peut ainsi surveiller et lire le trafic. Cette attaque est également appelée reniflage (« sniffing ») ou surveillance (« snooping »). Si le trafic consiste en du texte simple, l’intrus peut lire le trafic lorsqu’il accède au chemin d’accès des données. Par exemple, une attaque peut être lancée en contrôlant un routeur sur le chemin de données.

SfBO utilise le protocole TLS mutuel (MTLS) pour les communications serveur dans Microsoft 365 ou Office 365 et TLS entre les clients et le service, ce qui rend cette attaque difficile voire impossible à réaliser dans la période pendant laquelle une conversation donnée peut être attaquée. TLS authentifie toutes les parties et chiffre tout le trafic. Cela n’empêche pas les écoutes clandestines, mais l’attaquant ne peut pas lire le trafic, sauf si le chiffrement est rompu.

Le protocole TURN est utilisé pour les médias en temps réel. Le protocole TURN n’exige pas le chiffrement du trafic et les informations qu’il envoie sont protégées par l’intégrité du message. Bien qu’il soit ouvert aux écoutes clandestines, les informations qu’il envoie (c’est-à-dire les adresses IP et le port) peuvent être extraites directement en examinant les adresses source et de destination des paquets. Le service SFBO s’assure que les données sont valides par la vérification de l’intégrité du message en utilisant la clé dérivée de quelques éléments comprenant un mot de passe TURN, qui n'est jamais envoyé en clair. SRTP est utilisé pour le trafic multimédia et est également chiffré.

Usurpation d’identité (usurpation d’adresse IP)

On parle d’usurpation d’identité lorsqu’une personne malveillante parvient à déterminer et à utiliser l’adresse IP d’un réseau, d’un ordinateur ou d’un composant réseau, sans y avoir été autorisée. Une attaque réussie permet à l’agresseur de fonctionner comme si l’utilisateur malveillant était l’entité identifiée normalement par l’adresse IP. Dans le contexte de Microsoft Lync Server 2010, cette situation n’entre en jeu que si un administrateur a effectué les deux opérations suivantes :

• Connexions configurées qui prennent uniquement en charge le protocole TCP (Transmission Control Protocol) (ce qui n’est pas recommandé, car les communications TCP ne sont pas chiffrées).
• marqué les adresses IP de ces connexions en tant qu’hôtes approuvés.

Ce problème est moins grave pour les connexions TLS (Transport Layer Security), car TLS authentifie toutes les parties et chiffre le trafic. L’utilisation du protocole TLS empêche une personne malveillante d’usurper une adresse IP sur une connexion spécifique (par exemple, les connexions Mutual TLS). Mais un attaquant peut toujours usurper l’adresse du serveur DNS utilisé par SfBO. Toutefois, étant donné que l’authentification dans SfBO est effectuée avec des certificats, un attaquant n’aurait pas de certificat valide requis pour usurper l’une des parties dans la communication.

Attaque de l'homme du milieu

Une attaque de l’intercepteur se produit lorsqu’une personne malveillante redirige les communications entre deux utilisateurs via son propre ordinateur, à l’insu des deux participants. L’intrus peut surveiller et lire le trafic avant de l’acheminer vers le destinataire concerné. Chaque utilisateur de la communication envoie sans le savoir du trafic à et reçoit le trafic de l’attaquant, tout en pensant qu’il communique uniquement avec l’utilisateur prévu. Cela peut se produire si une personne malveillante modifie les services de domaine Active Directory pour ajouter son serveur en tant que serveur approuvé, ou si elle modifie DNS (Domain Name System) pour faire en sorte que les clients se connectent au serveur via l’ordinateur de l’intrus à l’origine de l’attaque.

Une attaque de l’intercepteur peut également se produire avec le trafic multimédia entre deux clients, sauf que dans SfBO, les flux audio, vidéo et de partage d’applications point à point sont chiffrés avec SRTP à l’aide de clés cryptographiques négociées entre les homologues utilisant le protocole SIP (Session Initiation Protocol) sur TLS.

Attaque par relecture RTP

Une attaque par relecture se produit lorsqu’une transmission multimédia valide entre deux correspondants est interceptée, puis retransmise à des fins malveillantes. SfBO utilise SRTP conjointement avec un protocole de signalisation sécurisé qui protège les transmissions contre les attaques par relecture en permettant au récepteur de conserver un index de paquets RTP déjà reçus et de comparer chaque nouveau paquet avec ceux déjà répertoriés dans l’index.

SPIM

Spim est un message instantané commercial non sollicité ou une demande d’abonnement de présence. Bien qu’il ne soit pas de lui-même une compromission du réseau, il est pour le moins gênant, peut réduire la disponibilité et la production des ressources et peut conduire à une compromission du réseau. Par exemple, les utilisateurs se font du spimming mutuellement en envoyant des demandes. Les utilisateurs peuvent se bloquer pour empêcher cela, mais avec la fédération, si une attaque de spim coordonné est établie, cela peut être difficile à surmonter, sauf si vous désactivez la fédération pour le partenaire.

Virus et vers

Un virus est une unité de code dont l’objectif est de reproduire d’autres unités de code similaires. Pour fonctionner, un virus a besoin d’un hôte, par exemple un fichier, un e-mail ou un programme. Comme un virus, un ver est une unité de code codée pour reproduire davantage d’unités de code similaires, mais qui, contrairement à un virus, n’a pas besoin d’un hôte. Les virus et les vers apparaissent principalement lors des transferts de fichiers entre clients ou lorsque des URL sont envoyées par d’autres utilisateurs. Si vous avez un virus sur votre ordinateur, il peut, par exemple, utiliser votre identité et envoyer des messages instantanés en votre nom. Les meilleures pratiques standard de sécurité client, telles que la recherche périodique de virus, peuvent atténuer ce problème.

Informations d’identification personnelle

SfBO a le potentiel de divulguer des informations sur un réseau public qui pourrait être en mesure d’être liée à un individu. Ces informations appartiennent à deux catégories :

• Données de présence améliorées Les données de présence améliorées sont des informations qu’un utilisateur peut choisir de partager ou non via un lien vers un partenaire fédéré ou avec des contacts au sein d’un organization. Ces données ne sont pas partagées avec les utilisateurs sur un réseau de messagerie instantanée public. Selon les stratégies de groupe en vigueur et la configuration du client, l’administrateur système peut contrôler ces informations. Dans le service SfBO, le mode de confidentialité de présence améliorée peut être configuré pour un utilisateur individuel afin d’empêcher les utilisateurs SfBO qui ne se trouvent pas dans la liste des contacts de l’utilisateur de voir les informations de présence de l’utilisateur.
• Données obligatoires Les données obligatoires sont des données requises pour le bon fonctionnement du serveur ou du client. Il s’agit d’informations nécessaires au niveau d’un serveur ou d’un réseau à des fins de routage, de maintenance de l’état et de signalisation. Les tableaux suivants répertorient les données nécessaires au fonctionnement de SFBO.

Tableau 1 - Données de présence enrichies

Données	Paramètres possibles
Données personnelles	Nom, Titre, Société, adresse Email, Fuseau horaire
Numéros de téléphone	Bureau, Mobile, Domicile
Informations de calendrier	Disponibilité, avis d’absence de la ville, détails de la réunion (pour ceux qui ont accès à votre calendrier)
Statut de présence	Absent, Disponible, Occupé, Ne pas déranger, Hors connexion

Tableau 2 - Données obligatoires

Données	Paramètres possibles
Adresse IP	Adresse réelle de l’ordinateur ou adresse traduite via NAT
URI SIP	david.campbell@contoso.com
Nom	David Campbell (tel que défini dans les services de domaine Active Directory)

Infrastructure de sécurité pour SfBO

Cette section fournit une vue d’ensemble des éléments fondamentaux qui forment l’infrastructure de sécurité pour Microsoft SfBO. Ces éléments sont les suivants :

• Microsoft Entra ID fournit un référentiel principal approuvé unique pour les comptes d’utilisateur.
• L’infrastructure à clé publique (PKI) utilise des certificats émis par des autorités de certification approuvées pour authentifier les serveurs et garantir l’intégrité des données.
• Le protocole de transport TLS (Transport Layer Security), HTTPS sur SSL (HTTPS) et MTLS (Mutual TLS) permettent l’authentification des points de terminaison et le chiffrement des messages instantanés. Les flux de données audio, vidéo et de partage d’applications point à point sont chiffrés et l’intégrité est vérifiée à l’aide du protocole SRTP (Secure Real-Time Transport Protocol).
• Protocoles standard d’authentification des utilisateurs, le cas échéant.

Les articles de cette section décrivent comment chacun de ces éléments fondamentaux fonctionne pour améliorer la sécurité du service SfBO.

Microsoft Entra ID

Microsoft Entra ID fonctionne en tant que service d’annuaire pour Microsoft 365 et Office 365. Il stocke toutes les affectations de stratégie et les informations de l’annuaire utilisateur.

Infrastructure à clé publique pour SFBO

Le service SfBO s’appuie sur des certificats pour l’authentification du serveur et pour établir une chaîne d’approbation entre les clients et les serveurs et entre les différents rôles de serveur. L’infrastructure à clé publique (PKI) de Windows Server fournit l’infrastructure nécessaire à l’établissement et à la validation de cette chaîne de confiance. Les certificats sont des ID numériques. Ils identifient un serveur par son nom et indiquent ses propriétés. Pour garantir que les informations d’un certificat sont valides, le certificat doit être émis par une autorité de certification approuvée par les clients ou d’autres serveurs qui se connectent au serveur. Si le serveur se connecte uniquement avec d’autres clients et serveurs sur un réseau privé, la CA peut être une CA d’entreprise. Si le serveur interagit avec des entités en dehors du réseau privé, une CA publique peut être requise.

Même si les informations du certificat sont valides, il doit exister un moyen de vérifier que le serveur présentant le certificat est en fait celui représenté par le certificat. C’est ici que le PKI de Windows entre en jeu. Chaque certificat est lié à une clé publique. Le serveur nommé sur le certificat contient une clé privée correspondante que lui seul connaît. Un client ou serveur se connectant utilise la clé publique pour chiffrer une information aléatoire et l’envoie au serveur. Si le serveur déchiffre l’information et la retourne sous forme de texte simple, l’entité se connectant peut ainsi être sûre que le serveur contient la clé privée du certificat et qu’il s’agit donc du serveur nommé sur le certificat.

Points de distribution

SfBO exige que tous les certificats de serveur contiennent un ou plusieurs points de distribution de liste de révocation de certificats (CRL). Les points de distribution de CRL sont des emplacements à partir desquels les listes de révocation de certificats peuvent être téléchargés afin de vérifier que le certificat n’a pas été révoqué depuis l’émission du certificat et qu’il est toujours dans la période de validité. Un point de distribution CRL est indiqué dans les propriétés du certificat sous forme d’URL et il s’agit d’une adresse HTTP sécurisée. Le service SfBO vérifie la liste de révocation de certificats avec chaque authentification de certificat.

Utilisation avancée de la clé :

Tous les composants du service SfBO nécessitent tous les certificats de serveur pour prendre en charge l’utilisation améliorée de la clé (EKU) pour l’authentification du serveur. La configuration du champ de l’EKU pour l’authentification du serveur signifie que le certificat est valide pour l’authentification des serveurs. Cette EKU est essentielle pour MTLS.

TLS et MTLS pour SfBO

Les protocoles TLS et MTLS fournissent des communications chiffrées et une authentification de point de terminaison sur Internet. SfBO utilise ces deux protocoles pour créer le réseau de serveurs approuvés et pour s’assurer que toutes les communications sur ce réseau sont chiffrées. Toutes les communications SIP entre les serveurs interviennent sur MTLS. Les communications SIP du client au serveur interviennent sur TLS.

TLS permet aux utilisateurs, via leur logiciel client, d’authentifier les serveurs SfBO auxquels ils se connectent. Sur une connexion TLS, le client demande un certificat valide du serveur. Pour être valide, le certificat doit avoir été émis par une autorité de certification qui est également approuvée par le client et le nom DNS du serveur doit correspondre au nom DNS dans le certificat. Si le certificat est valide, le client utilise la clé publique du certificat pour chiffrer les clés de chiffrement symétriques à utiliser pour la communication, de sorte que seul le propriétaire d’origine du certificat peut utiliser sa clé privée pour déchiffrer le contenu de la communication. La connexion obtenue est approuvée et, à partir de ce point, n’est pas remise en question par d’autres serveurs ou clients approuvés. Dans ce contexte, le protocole SSL (Secure Sockets Layer) utilisé avec les services Web peut être associé au protocole TLS.

Les connexions de serveur à serveur reposent sur le protocole TLS (MTLS) mutuel pour l’authentification mutuelle. Sur une connexion MTLS, le serveur à l’origine d’un message et le serveur le recevant échangent des certificats à partir d’une autorité de certification mutuellement approuvée. Les certificats prouvent l’identité d’un serveur à un autre. Dans le service SfBO, cette procédure est adoptée.

Les protocoles TLS et MTLS évitent les attaques par écoute clandestine et les attaques d’homme intercepteurs. Dans le cas d’une attaque d’intercepteur, l’attaquant réachemine les communications entre deux entités de réseau via l’ordinateur de l’attaquant sans que l’autre partie n’en ait connaissance. Les spécifications de serveurs approuvés de TLS et SfBO atténuent le risque d’attaque de l’intercepteur partiellement sur la couche application en utilisant un chiffrement de bout en bout coordonné à l’aide du chiffrement à clé publique entre les deux points de terminaison, et un attaquant doit disposer d’un certificat valide et approuvé avec la clé privée correspondante et émis au nom du service auquel le client communique pour déchiffrer la communication.

Chiffrement pour SFBO

SfBO utilise TLS et MTLS pour chiffrer les messages instantanés. Tout le trafic de serveur à serveur requiert MTLS, que le trafic soit confiné au réseau interne ou qu’il traverse le périmètre réseau interne.

Le tableau suivant résume le protocole utilisé par SfBO.

Tableau 3 - Protection du trafic

Type de trafic	Protégé par
Serveur à serveur	MTLS
Client à serveur	TLS
Messagerie instantanée et présence	TLS (si TLS est configuré)
Partage multimédia audio, vidéo et de bureau	SRTP
Partage du bureau (signalisation)	TLS
Conférence web	TLS
Téléchargement de contenu de réunion, téléchargement de carnet d’adresses, développement de groupe de distribution	HTTPS

Chiffrement multimédia

Le trafic multimédia est chiffré à l'aide du protocole SRTP (Secure Real-time Transport Protocol), un profil du protocole RTP (Real-Time Transport Protocol) qui offre confidentialité, authentification et protection contre les attaques sur le trafic RTP. SRTP utilise une clé de session produite à l’aide d’un générateur de nombres aléatoires sécurisé et échangée en utilisant le canal TLS de signalisation. De plus, les données multimédias acheminées dans les deux directions entre le serveur de médiation et son tronçon suivant interne sont également chiffrées avec SRTP.

SfBO génère un nom d’utilisateur/mot de passe pour un accès sécurisé aux relais de média sur TURN. Les relais de média échangent le nom d’utilisateur/mot de passe sur un canal SIP sécurisé par TLS.

FIPS

SFBO utilise des algorithmes qui sont conformes aux normes FIPS (Federal Information Processing Standard) pour les échanges de clés de chiffrement.

Authentification utilisateur et client

Un utilisateur approuvé est un utilisateur dont les informations d’identification ont été authentifiées par Microsoft Entra ID dans Microsoft 365 ou Office 365.

L’authentification consiste à fournir des informations d’identification d’utilisateur à un serveur approuvé ou service. SfBO utilise les protocoles d’authentification suivants, en fonction de la status et de l’emplacement de l’utilisateur.

• L’authentification moderne est l’implémentation Microsoft d’OAUTH 2.0 pour la communication client à serveur. Il active des fonctionnalités de sécurité telles que l’authentification basée sur les certificats, l’authentification multifacteur et l’accès conditionnel. Pour utiliser AM, les clients online et client doivent être activés pour AM. L'authentification multifacteur est activée par défaut pour les clients de SDBO créés après mai 2017. Pour les clients créés avant cette date, suivez les instructions qui suivent pour l’activer. Les clients suivants prennent tous en charge l’authentification multifacteur : client Skype Entreprise 2015 ou 2016, Skype Entreprise sur Mac, client Lync 2013, téléphones IP 3PIP, iOS et Android.
• L’ID d’organisation est utilisé lorsque l’authentification moderne n’est pas activée (ou n’est pas disponible).
• Protocole Digest pour utilisateurs anonymes. Les utilisateurs anonymes sont des utilisateurs externes qui n’ont pas d’informations d’identification Active Directory reconnues, mais qui ont été invités à une conférence locale et qui possèdent une clé de conférence valide. L’authentification Digest n’est pas utilisée pour les autres interactions client.

L’authentification SfBO se compose de deux phases :

1. Une association de sécurité est établie entre le client et le serveur.
2. Le client et le serveur utilisent l’association de sécurité existante pour signer les messages qu’ils envoient et vérifier les messages qu’ils reçoivent. Les messages non authentifiés d’un client ne sont pas acceptés lorsque l’authentification est activée sur le serveur.

La confiance de l’utilisateur est associée à chaque message qui provient d’un utilisateur, et non à l’identité de l’utilisateur. Le serveur vérifie chaque message à la recherche d’informations d’identification d’utilisateur valides. Si les informations d’identification de l’utilisateur sont valides, le message n’est pas contesté non seulement par le premier serveur à le recevoir, mais par tous les autres serveurs dans SfBO.

Les utilisateurs disposant d’informations d’identification valides émises par un partenaire fédéré sont approuvés mais peuvent éventuellement subir des contraintes supplémentaires les empêchant de profiter de la gamme complète de privilèges accordés aux utilisateurs internes.

Pour l’authentification multimédias, les protocoles de glace et de tournage utilisent également la stimulation Digest, comme décrit dans l’IETF TURN RFC. Pour plus d’informations, consultez La traversée des médias.

Les certificats clients fournissent un autre moyen pour les utilisateurs d’être authentifiés par SfBO. Au lieu de fournir un nom d’utilisateur et un mot de passe, les utilisateurs disposent d’un certificat et d’une clé privée correspondant au certificat requis pour résoudre un défi cryptographique.

Outils de gestion Windows PowerShell et SfBO

Dans SFBO, les administrateurs informatiques peuvent gérer leur service via le portail d’administration d’O365 ou en utilisant TRPS (Tenant Remote PowerShell). Les administrateurs de client utilisent l’authentification moderne pour s’authentifier auprès de TRPS.

Configuration de l'accès à SfBO à votre frontière Internet

Pour que SfBO fonctionne correctement (utilisateurs pouvant participer à des réunions, etc.), les clients doivent configurer leur accès à Internet de sorte que le trafic UDP et TCP sortant vers les services dans le cloud SfBO soit autorisé. Pour plus d’informations, consultez ici : https://support.office.com/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_lyo

UDP 3478-3481 et TCP 443

Les ports UDP 3478-3481 et TCP 443 sont utilisés par les clients pour demander un service auprès du service Edge A/V. Un client utilise ces deux ports pour allouer des ports UDP et TCP respectivement à la partie distante à laquelle se connecter. Pour accéder au service Edge A/V, le client doit d’abord avoir établi une session de signalisation SIP authentifiée auprès du bureau d’enregistrement SfBO pour obtenir les informations d’identification d’authentification du service Edge A/V. Ces valeurs sont envoyées à travers le canal de signalisation protégé par TLS et générées par ordinateur pour pallier les attaques par dictionnaire. Les clients peuvent ensuite utiliser ces informations d’identification pour l’authentification Digest avec le service Edge A/V afin d’allouer les ports à utiliser dans une session multimédia. Une requête d’allocation initiale est envoyée par le client et répond par un message de défi/nonce 401 provenant du service Edge A/V. Le client envoie une seconde allocation contenant le nom d’utilisateur et un hachage HMAC (Hash Message Authentication Code) du nom d’utilisateur et du nonce.

Un mécanisme de numéro de séquence est également en place pour empêcher les attaques par rejeu. Le serveur calcule le HMAC attendu sur la base de sa connaissance du nom d’utilisateur et du mot de passe et si les valeurs HMAC concordent, la procédure d’allocation est exécutée. Sinon, le paquet est abandonné. Ce même mécanisme HMAC est également appliqué aux messages subséquents dans cette session d’appel. La durée de vie de cette valeur de nom d’utilisateur/mot de passe est de huit heures au maximum, au bout desquelles le client réacquiert un nouveau nom d’utilisateur/mot de passe pour les appels subséquents.

UDP/TCP 50 000 à 59 999

Le port TCP 50 000 sortant est utilisé pour SFBO, y compris pour le partage d’applications et de bureau ainsi que pour le transfert de fichiers. Les plages de ports UDP/TCP 50 000-59 999 sont utilisées pour les sessions multimédia avec les partenaires Microsoft Office Communications Server 2007 qui nécessitent un service de traversée NAT/de pare-feu à partir du service Edge A/V. Étant donné que le service Edge A/V est le seul processus utilisant ces ports, la taille de la plage de ports n’indique pas la surface d’attaque potentielle. Une bonne pratique de sécurité consiste toujours à minimiser le nombre total de ports d’écoute en n’exécutant pas de services réseau inutiles. Si un service réseau n’est pas en cours d’exécution, il n’est pas exploitable par un attaquant distant et la surface d’attaque de l’ordinateur hôte est réduite. Toutefois, au sein d’un même service, la réduction du nombre de ports n’offre pas le même avantage. Le logiciel de service Edge A/V n’est pas plus exposé à une attaque qu’il y ait 10 000 ports ouverts ou 10. L’allocation des ports dans cette plage est effectuée de manière aléatoire et les ports qui ne sont pas actuellement alloués n’écoutent pas les paquets.

Traversée de trafic A/V des utilisateurs externes

Pour permettre aux utilisateurs externes et aux utilisateurs internes d’échanger des médias, un service Edge d’accès doit gérer la signalisation SIP nécessaire pour configurer et détruire une session. Un service Edge A/V est également requis pour agir en tant que relais pour le transfert des médias. La séquence d’appel est illustrée dans la figure suivante.

1. Un utilisateur reçoit un e-mail contenant une invitation à rejoindre une réunion SfBO. L’e-mail contient une clé de conférence et une URL au format HTTP établissant un lien vers la conférence. La clé et l’URL sont spécifiques à une réunion particulière.

   L’utilisateur lance la procédure de participation en cliquant sur l’URL de la réunion dans l’e-mail, ce qui lance un processus de détection du client sur l’ordinateur de l’utilisateur. Si le client est détecté, il est lancé. S’il n’est pas détecté, l’utilisateur est redirigé vers le client web.

2. Le client SFBO envoie une INVITATION SIP contenant les informations d’identification de l’utilisateur. Un utilisateur fédéré ou distant rejoint une conférence à l’aide de ses informations d’identification d’entreprise. Pour un utilisateur fédéré, l’INVITATION SIP est d'abord envoyée à son serveur d’origine, lequel authentifie l’utilisateur et transmet l’INVITATION à SFBO. Un utilisateur anonyme est requis pour réussir l’authentification digest.

   SDBO authentifie l’utilisateur distant ou anonyme et notifie le client. Comme mentionné à l’étape 2, les utilisateurs fédérés qui rejoignent une conférence sont authentifiés par leur entreprise.

3. Le client envoie une demande d’informations pour ajouter l’utilisateur à la conférence A/V.

   Les conférences A/V envoient une réponse Ajouter un utilisateur qui contient le jeton à présenter au service Edge de conférence A/V, entre autres informations.

   [Remarque] Tout le trafic SIP précédent a transité par le service Access Edge.

   Le client se connecte au serveur de conférence A/V, qui valide le jeton et transfère par proxy la demande, qui contient un autre jeton d’autorisation au serveur de conférence A/V interne. Le serveur de conférence A/V valide le jeton d’autorisation, qu'il a émis initialement sur le canal SIP, afin de s’assurer qu’un utilisateur valide rejoint la conférence.

4. Entre le client et le serveur de conférence A/V, une connexion multimédia est négociée et configurée sur SRTP.

5. Un utilisateur reçoit un e-mail contenant une invitation à rejoindre une réunion SfBO. L’e-mail contient une clé de conférence et une URL au format HTTP établissant un lien vers la conférence. La clé et l’URL sont spécifiques à une réunion particulière.

Protections de fédération pour SfBO

La fédération fournit à votre organisation la possibilité de communiquer avec d’autres organisations pour partager la messagerie instantanée et la présence. Dans SFBO, la fédération est activée par défaut. Toutefois, les administrateurs de locataire ont la possibilité de contrôler cela via le portail Microsoft 365 ou Office 365 Admin. En savoir plus.

Répondre aux menaces pesant sur les conférences SFBO

SFBO offre aux utilisateurs d’entreprise la possibilité de créer et de rejoindre des conférences Web en temps réel. Les utilisateurs d’entreprise peuvent également inviter des utilisateurs externes qui n’ont pas de compte Microsoft Entra ID, Microsoft 365 ou Office 365 à participer à ces réunions. Les utilisateurs qui sont employés par des partenaires fédérés avec une identité sécurisée et authentifiée peuvent également participer à des réunions et, s’ils sont promus, ils peuvent agir en tant que présentateurs. Les utilisateurs anonymes ne peuvent pas créer ou participer à une réunion en tant que présentateur, mais ils peuvent être promus présentateurs après leur participation.

Permettre aux utilisateurs externes de participer aux réunions SFBO augmente considérablement la valeur de cette fonctionnalité, mais comporte également certains risques de sécurité. Pour répondre à ces risques, SFBO fournit les garanties supplémentaires suivantes :

• Les rôles de participant déterminent les privilèges de contrôle de conférence.
• Les types de participants vous permettent de limiter l’accès à des réunions spécifiques.
• Les types de réunion définis déterminent quels types de participants peuvent participer.
• La planification des conférences est limitée aux utilisateurs disposant d’un compte Microsoft Entra et d’une licence SfBO.
• Les utilisateurs anonymes, c’est-à-dire non authentifiés, qui souhaitent rejoindre une conférence rendez-vous composent l’un des numéros d’accès à la conférence, puis sont invités à entrer l’ID de conférence. Les utilisateurs anonymes qui souhaitent participer à une conférence composent un des numéros d’accès à la conférence, puis sont invités à entrer l’ID de conférence. Le nom enregistré identifie les utilisateurs non authentifiés au sein de la conférence. Les utilisateurs anonymes ne sont pas admis à la conférence tant qu’au moins un responsable ou un utilisateur authentifié n’a pas rejoint la conférence et qu’aucun rôle prédéfini ne leur est attribué.

Rôles des participants

Les participants à la réunion se répartissent en trois groupes, chacun ayant ses propres privilèges et restrictions :

• Organisateur L’utilisateur qui crée une réunion, qu’elle soit impromptue ou programmée. Un organisateur doit être un utilisateur d’entreprise authentifié et avoir un contrôle sur tous les aspects de l’utilisateur final d’une réunion.
• Présentateur Un utilisateur autorisé à présenter des informations lors d’une réunion, quel que soit le média pris en charge. Un organisateur de réunion est par définition également un présentateur et détermine qui d’autre peut être un présentateur. Il peut effectuer cette détermination lorsqu’une réunion est planifiée ou pendant son déroulement.
• Participant Un utilisateur qui a été invité à participer à une réunion, mais qui n’est pas autorisé à agir en tant que présentateur.

Un présentateur peut également promouvoir un participant au rôle de présentateur pendant la réunion.

Types de participants

Les participants à la réunion sont également classés par localisation et informations d’identification. Vous pouvez utiliser ces deux caractéristiques pour préciser les utilisateurs pouvant avoir accès à des réunions spécifiques. Les utilisateurs peuvent être répartis globalement dans les catégories suivantes :

1. Utilisateurs appartenant au locataire Ces utilisateurs ont des informations d’identification dans Microsoft Entra ID pour le locataire.
   a. À l’intérieur d’un réseau d’entreprise : ces utilisateurs rejoignent à partir du réseau d’entreprise.
   b. Utilisateurs distants : ces utilisateurs se rejoignent en dehors du réseau de l’entreprise. Ce sont, par exemple, des employés qui travaillent à domicile ou en déplacement, ou d’autres personnes, comme les employés de fournisseurs de confiance, qui ont reçu des informations d’identification d’entreprise pour leurs conditions d’utilisation du service. Les utilisateurs distants peuvent créer et rejoindre des conférences et agir en tant que présentateurs.
2. Utilisateurs qui n’appartiennent pas au locataire Ces utilisateurs n’ont pas d’informations d’identification dans Microsoft Entra ID pour le locataire.
   a. Utilisateurs fédérés : les utilisateurs fédérés possèdent des informations d’identification valides avec des partenaires fédérés et sont donc traités comme authentifiés par SfBO. Les utilisateurs fédérés peuvent participer à des conférences et être promus en présentateurs après avoir rejoint la réunion, mais ils ne peuvent pas créer de conférences dans les entreprises avec lesquelles ils sont fédérés.
   b. Utilisateurs anonymes : les utilisateurs anonymes n’ont pas d’identité Active Directory et ne sont pas fédérés avec le locataire.

Les données client montrent que de nombreuses conférences impliquent des utilisateurs externes. Ces mêmes clients veulent également être rassurés en ce qui concerne l’identité des utilisateurs externes avant de permettre à ces utilisateurs de participer à une conférence. Comme le décrit la section suivante, SfBO limite l’accès aux réunions aux types d’utilisateurs qui ont été explicitement autorisés et exige que tous les types d’utilisateurs présentent des informations d’identification appropriées en entrant dans une réunion.

Admission des participants

Dans SfBO, les utilisateurs anonymes sont transférés dans une zone appelée salle d’attente Les présentateurs peuvent ensuite admettre ces utilisateurs à la réunion ou les rejeter. Ces utilisateurs sont transférés dans la salle d’attente, le leader est averti, et les utilisateurs attendent alors qu’un leader les accepte ou les rejette ou que leur connexion expire. Pendant qu’ils sont dans la salle d’attente, les utilisateurs entendent de la musique.

Par défaut, les participants qui se connectent à partir du RTPC vont directement à la réunion, mais cette option peut être modifiée pour forcer les participants à entrer dans le salle d’attente.
Les organisateurs de la réunion contrôlent si les participants peuvent rejoindre une réunion sans attendre dans la salle d’attente. Chaque réunion peut être configurée pour autoriser l’accès à l’aide de l’une des méthodes suivantes :

• Seul moi, l’organisateur de la réunion Tout le monde, sauf l’organisateur, doit attendre dans la salle d’attente jusqu’à ce qu’il soit admis.
• Personnes j’invite de ma société Tout le monde de votre entreprise peut accéder directement à la réunion, même s’il n’est pas invité.
• Toute personne de mon organization Tous les utilisateurs sfBO dans le client Microsoft 365 ou Office 365 peut rejoindre la réunion sans attendre dans la salle d’attente, même si ceux qui ne figurent pas dans la liste de distribution. Tous les autres, y compris tous les utilisateurs externes et anonymes, doivent attendre dans la salle d’attente jusqu'à ce qu’ils soient admis.
• Quelqu'un Toute personne (il n’y a aucune restriction) qui a accès au lien de réunion accède directement à la réunion. Lorsque l’une des méthodes est spécifiée, à l'exception d’« Organisateur uniquement » (rôle verrouillé), l’organisateur de la réunion peut également indiquer que les personnes qui appellent par téléphone ne passent pas par le lobby.

Fonctions du présentateur

Les organisateurs de la réunion contrôlent si les participants peuvent présenter lors d’une réunion. Chaque réunion peut être configurée pour limiter les présentateurs à l’une des entités suivantes :

• Organisateur uniquement Seul l’organisateur de la réunion peut présenter.
• Les personnes de mon entreprise Tous les utilisateurs internes peuvent présenter.
• Tout le monde y compris les personnes extérieures à mon entreprise Toute personne (sans restrictions) qui se joint à la réunion peut présenter.
• Personnes Je choisis L’organisateur de la réunion spécifie quels utilisateurs peuvent présenter en les ajoutant à une liste de présentateurs.

Articles connexes

Centre de gestion de la confidentialité Microsoft