Cette section fournit un contexte supplémentaire sur les principaux éléments de configuration liés aux services hybrides.

Ces points sont cruciaux si vous voulez réussir à déployer Hybrid Calling pour les appareils Webex. Nous avons mis en avant ces points en particulier pour les raisons suivantes :

• Nous voulons les expliquer, afin que vous compreniez leur rôle dans un déploiement hybride et que vous vous sentiez rassurée.

• Ce sont des prérequis obligatoires qui garantissent un déploiement sécurisé entre notre cloud et votre environnement sur site.

• Elles doivent être considérées comme des activités antérieures à la journée zéro : elles peuvent prendre un peu plus de temps que la configuration habituelle d'une interface utilisateur. Prévoyez donc un certain temps pour trier ces éléments.

• Une fois ces points résolus dans votre environnement, le reste de la configuration de vos services hybrides se déroulera sans problème.

Le déploiement de la paire Expressway-C et Expressway-E permet de passer des appels depuis et vers Internet à l'aide de technologies de traversée de pare-feu. Ce déploiement permet de relier en toute sécurité votre contrôle des appels sur site à Webex.

L'Expressway-C et l'Expressway-E ne nécessitent l'ouverture d'aucun port entrant dans le pare-feu de la zone démilitarisée (DMZ) en raison de leur architecture de traversée. Mais les ports de signalisation TCP SIP et les ports multimédia UDP doivent être ouverts en entrée sur le pare-feu Internet pour laisser passer les appels entrants. Vous devez prévoir du temps pour que le port approprié soit ouvert sur le pare-feu de votre entreprise.

L'architecture traversale du pare-feu est illustrée dans le schéma suivant :

Par exemple, pour les appels entrants interentreprises (B2B) utilisant le protocole SIP, les ports TCP 5060 et 5061 (5061 est utilisé pour le SIP TLS) doivent être ouverts sur le pare-feu externe, de même que les ports multimédia UDP utilisés pour des services tels que la voix, la vidéo, le partage de contenu, la double vidéo, etc. Les ports multimédia à ouvrir dépendent du nombre d'appels simultanés et du nombre de services.

Vous pouvez configurer le port d'écoute SIP d'Expressway sur une valeur comprise entre 1024 et 65534. En même temps, cette valeur et le type de protocole doivent être publiés dans les DNS SRV archives publiques, et cette même valeur doit être ouverte sur le pare-feu Internet.

Bien que la norme pour le SIP TCP soit 5060 et pour le SIP TLS 5061, rien n'empêche d'utiliser différents ports, comme le montre l' exemple suivant.

Exemple

Dans cet exemple, nous partons du principe que le port 5062 est utilisé pour les appels SIP TLS entrants.

Le DNS SRV record pour un cluster de deux serveurs Expressway est le suivant :

_gorgées. Emplacement du service SRV _tcp.example.com :

priority = 10

weight = 10

port = 5062

nom d'hôte svr = us-expe1.example.com

_gorgées. Emplacement du service SRV _tcp.example.com :

priority = 10

weight = 10

port = 5062

nom d'hôte svr = us-expe2.example.com

Ces enregistrements signifient que les appels sont dirigés vers us-expe1.example.com et us-expe2.example.com avec un partage de charge égal (priorité et poids) en utilisant TLS comme type de transport et 5062 comme numéro de port d'écoute.

Un appareil externe au réseau (sur Internet) qui passe un appel SIP à un utilisateur du domaine de l'entreprise (user1@example.com) doit interroger le DNS pour savoir quel type de transport utiliser, le numéro de port, comment partager la charge du trafic et vers quels serveurs SIP envoyer l'appel.

Si l'entrée DNS inclut _sips. _tcp, l'entrée indique le protocole SIP TLS.

Le TLS est un protocole client-serveur qui, dans les implémentations les plus courantes, utilise des certificats pour l'authentification. Dans un scénario d'appel interentreprises, le client TLS est l'appareil appelant et le serveur TLS est l'appareil appelé. Avec le protocole TLS, le client vérifie le certificat du serveur, et si la vérification échoue, il déconnecte l' appel. Le client n'a pas besoin de certificat.

La poignée de main TLS est illustrée dans le schéma suivant :

Cependant, la spécification TLS indique que le serveur peut également vérifier le certificat du client en envoyant un message de demande de certificat au client dans le cadre du protocole TLS handshake. Ce message est utile pour établir une connexion de serveur à serveur, par exemple lors d'un appel établi entre Expressway-E et le cloud Webex. Ce concept s'appelle TLS avec authentification mutuelle et est obligatoire lors de l'intégration à Webex.

L'appelant et l'appelé vérifient le certificat de l'autre pair, comme le montre le schéma suivant :

Le cloud vérifie l'identité d'Expressway, et Expressway vérifie l'identité du cloud. Par exemple, si l' identité cloud figurant sur le certificat (CN ou SAN) ne correspond pas à celle configurée sur Expressway, la connexion est interrompue.

Si l'authentification mutuelle est activée, Expressway-E demande toujours le certificat client. Par conséquent, Mobile et Remote Access (MRA) ne fonctionneront pas, car dans la plupart des cas, les certificats ne sont pas déployés sur les clients Jabber . Dans un scénario interentreprises, si l'entité appelante n'est pas en mesure de fournir de certificat, l'appel est déconnecté.

Nous vous recommandons d'utiliser une valeur autre que 5061 pour le protocole TLS avec authentification mutuelle, comme le port 5062. Les services hybrides Webex utilisent le même enregistrement SIP TLS que celui utilisé pour le B2B. Dans le cas du port 5061, certains autres services qui ne peuvent pas fournir de certificat client TLS ne fonctionneront pas.

Si un enregistrement existant est déjà utilisé pour les communications interentreprises, nous vous recommandons de spécifier un sous-domaine du domaine de l'entreprise comme destination SIP dans Control Hub, et par conséquent un DNS SRV enregistrement public, comme suit :

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

Trafic interentreprises, mobile Remote Access et Webex sur la même paire d'autoroutes

Les appels interentreprises (B2B), mobiles et Remote Access (MRA) utilisent le port 5061 pour le SIP TLS, et le trafic Webex utilise le port 5062 pour le SIP TLS avec authentification mutuelle.

Le contrôle de propriété du domaine fait partie de la vérification d'identité. La vérification de domaine est une mesure de sécurité et un contrôle d'identité que le cloud Webex met en œuvre pour prouver que vous êtes bien celle que vous prétendez être.

Le contrôle d'identité s'effectue en deux étapes :

1. Vérification de la propriété du domaine. Cette étape implique trois types de domaines et constitue un contrôle de vérification unique :

   • Domaine de messagerie

   • Domaine DNS Expressway-E

   • Domaine URI de l'annuaire

2. Vérification de la propriété du nom DNS Expressway-E. Cette étape passe par la mise en œuvre du protocole TLS avec authentification mutuelle et implique l'utilisation de certificats publics à la fois sur le cloud et sur l'autoroute. Contrairement à la vérification de l'identité du domaine, cette étape est effectuée lors de tout appel passé et reçu depuis le cloud.

L'importance du contrôle de propriété du domaine

Le cloud Webex vérifie la propriété du domaine pour renforcer la sécurité. L'usurpation d'identité est l'une des menaces possibles si ce contrôle n'est pas effectué.

L'histoire suivante explique ce qui peut se passer si aucun contrôle de propriété de domaine n'est effectué.

Une entreprise dont le domaine DNS est défini sur « hacker.com » achète Webex Hybrid Services. Une autre entreprise, dont le nom de domaine est « exemple.com », utilise également des services hybrides. L'une des directrices générales de la société Example.com s'appelle Jane Roe et possède l'adresse URL jane.roe@example.com.

L'administratrice de la société Hacker.com définit l'URL de l'un de ses annuaires sur jane.roe@example.com et l'adresse e-mail sur jane.roe@hacker.com. Elle peut le faire parce que le cloud ne vérifie pas le domaine d'URI SIP dans cet exemple.

Ensuite, elle se connecte à l'application Webex avec jane.roe@hacker.com. Comme elle est propriétaire du domaine, l'e-mail de vérification est lu et répondue, et elle peut se connecter. Enfin, elle appelle un collègue, John Doe, en composant john.doe@example.com depuis son application Webex. John est assis dans son bureau et reçoit un appel sur son appareil vidéo provenant de jane.roe@example.com ; il s'agit de l'URI du répertoire associé à ce compte e-mail.

« Elle est à l'étranger », pense-t-il. « Elle a peut-être besoin de quelque chose d'important. » Il répond au téléphone et la fausse Jane Roe demande des documents importants. Elle explique que son appareil est cassé et, comme elle est en voyage, elle lui demande d'envoyer les documents sur son adresse e-mail privée, jane.roe@hacker.com. Ainsi, l'entreprise ne se rend compte qu'une fois de retour au bureau de Jane Roe que des informations importantes ont été divulguées en dehors de l'entreprise.

La société Example.com propose de nombreux moyens de se protéger contre les appels frauduleux provenant d'Internet, mais l'une des responsabilités du cloud Webex est de s'assurer que l'identité de toute personne qui appelle depuis Webex est correcte et non falsifiée.

Pour vérifier l'identité, Webex demande à l'entreprise de prouver qu'elle est propriétaire des domaines utilisés dans Hybrid Calling. Si ce n'est pas le cas, les services hybrides ne fonctionneront pas.

Pour garantir cette propriété, les deux étapes de vérification du domaine sont requises :

1. Prouvez que l'entreprise est propriétaire du domaine de messagerie, du domaine Expressway-E, du domaine Directory URI.

   • Tous ces domaines doivent être routables et connus des serveurs DNS publics.

   • Pour prouver la propriété, l'administrateur DNS doit saisir un enregistrement texte DNS (TXT). Un enregistrement TXT est un type d'enregistrement de ressource dans le DNS utilisé pour associer du texte arbitraire et non formaté à un nom d'hôte ou à un autre nom.

   • L'administrateur DNS doit saisir cet enregistrement TXT dans la zone dont la propriété doit être prouvée. Après cette étape, le cloud Webex effectue une requête d'enregistrement TXT pour ce domaine.

   • Si la requête TXT aboutit et que le résultat correspond au jeton généré depuis le cloud Webex, le domaine est vérifié.

   • Par exemple, l'administratrice doit prouver qu'elle est propriétaire du domaine « example.com » si elle souhaite que Webex Hybrid Services fonctionne sur son domaine.

   • Sur https://admin.webex.com, elle entame le processus de vérification en créant un enregistrement TXT correspondant au jeton généré par le cloud Webex :

     

   • L'administrateur DNS crée ensuite un enregistrement TXT pour ce domaine avec la valeur définie sur 123456789abcdef123456789abcdef123456789abcdef123456789abcdef123456789abcdef, comme dans l'exemple suivant :

     

   • À ce stade, le cloud peut vérifier que l'enregistrement TXT du domaine example.com correspond au jeton.

   • Le cloud effectue une recherche DNS TXT :

     

   • Comme la valeur TXT correspond à la valeur du jeton, cette correspondance prouve que l'administratrice a ajouté l'enregistrement TXT de son propre domaine au DNS public et qu'elle est propriétaire du domaine.

2. Vérification de la propriété du nom DNS Expressway-E.

   • Le cloud doit vérifier que l'identité de l'Expressway-E a été confirmée par l'une des autorités de certification auxquelles le cloud fait confiance. L'administrateur de l'Expressway-E doit demander un certificat public pour son Expressway-E à l'une de ces autorités de certification. Pour délivrer le certificat, l'autorité de certification effectue un processus de vérification d'identité, sur la base d'un contrôle de validation du domaine (pour les certificats validés par domaine) ou d'un contrôle de validation de l'organisation (pour les certificats validés par l'organisation).

   • Les appels depuis et vers le cloud dépendent du certificat délivré à l'Expressway-E. Si le certificat n'est pas valide, l'appel est interrompu.

Le connecteur d'appareil Webex doit communiquer avec Webex pour que les appels hybrides fonctionnent.

Le Webex Device Connector est déployé sur le réseau interne et communique avec le cloud via une connexion HTTPS sortante, le même type que celui utilisé pour tout navigateur qui se connecte à un serveur Web.

La communication vers le cloud Webex utilise le protocole TLS. Webex Device Connector est le client TLS et le cloud Webex est le serveur TLS. Webex Device Connector vérifie donc le certificat du serveur.

L'autorité de certification signe un certificat de serveur à l'aide de sa propre clé privée. Toute personne possédant la clé publique peut décoder cette signature et prouver que c'est la même autorité de certification qui l'a signé.

Si Webex Device Connector doit valider le certificat fourni par le cloud, il doit utiliser la clé publique de l'autorité de certification qui a signé ce certificat pour décoder la signature. Le certificat de l'autorité de certification contient une clé publique. Pour établir la confiance avec les autorités de certification utilisées par le cloud, la liste des certificats de ces autorités de certification fiables doit se trouver dans la boutique sécurisée Webex Device Connector.

Lorsque vous communiquez avec des appareils, l'outil utilise les certificats fiables que vous fournissez. Actuellement, le moyen de le faire est de les placer dedans [home folder]/.devicestool/certs.

Une liste des certificats d'autorité de certification est également requise pour l'Expressway-E in the Traversal. Expressway-E communique avec le cloud Webex via le protocole SIP et TLS, renforcé par une authentification mutuelle. Expressway-E fait confiance aux appels en provenance et à destination du cloud, uniquement si le CN ou le SAN du certificat présenté par le cloud lors de la configuration de la connexion TLS correspond au nom du sujet configuré pour la zone DNS d'Expressway (« callservice.webex.com »). L'autorité de certification délivre un certificat uniquement après un contrôle d'identité. La propriété du domaine callservice.webex.com doit être prouvée pour faire signer un certificat. Comme nous (Cisco) sommes propriétaires de ce domaine, le nom DNS « callservice.webex.com » est la preuve directe que l'homologue distant est vraiment Webex.

calendar connector intègre Webex à Microsoft Exchange 2013, 2016, 2019 ou Office 365 par le biais d'un compte usurpé d'identité. Le rôle de gestion de l'usurpation d'identité des applications dans Exchange permet aux applications de se faire passer pour des utilisateurs au sein d'une organisation afin d'effectuer des tâches pour le compte de l'utilisateur. Le rôle d'usurpation d'identité de l'application doit être configuré dans Exchange et est utilisé dans le connecteur de calendrier dans le cadre de la configuration Exchange sur l'interface Expressway-C.

L'usurpation d'identité du compte Exchange est la méthode recommandée par Microsoft pour cette tâche. Les administrateurs d'Expressway-C n'ont pas besoin de connaître le mot de passe, car celui-ci peut être saisi dans l'interface Expressway-C par un administrateur Exchange. Le mot de passe n'est pas clairement affiché, même si l'administrateur d'Expressway-C dispose d'un accès root au boîtier Expressway-C. Le mot de passe est stocké crypté selon le même mécanisme de cryptage des informations d'identification que les autres mots de passe de l'Expressway-C.

Pour plus de sécurité, suivez les étapes du Guide de déploiement du service de calendrier Cisco Webex hybride afin d'activer le protocole TLS afin de sécuriser les connexions EWS sur le câble.

Pour plus de sécurité, suivez les étapes décrites dans Deploy Expressway Calendar Connector Microsoft Exchange pour activer le protocole TLS afin de sécuriser les connexions EWS sur le câble.