Cette section fournit un contexte supplémentaire sur les éléments clés de configuration qui se rapportent aux Services hybrides .

Ces points sont essentiels si vous souhaitez déployer avec succès l’appel hybride pour les périphériques Webex. Lorsque le Cisco Spark Hybrid Calendar Service ajoute des détails de jointure à une invitation programmée avec @spark ou @webex, la façon dont il détermine la langue à utiliser dépend du système de calendrier.

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

• Ce sont les conditions préalables obligatoires qui garantissent un déploiement sécurisé entre notre Cloud et votre environnement sur site.

• Ils doivent être traités en tant que journée sans activité : ils peuvent prendre un peu plus de temps que la configuration standard dans une interface utilisateur, alors prévoyez un délai pour trier ces éléments.

• Une fois ces éléments traités 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 les appels vers et depuis Internet en utilisant les technologies de traversée de pare-feu. Ce déploiement permet de sécuriser le contrôle des appels sur site et de le relier à Webex.

L'Expressway-C et Expressway-E n'exigent pas l'ouverture d'un port d'entrée dans la zone démilitarisée (DMZ) à cause de l'architecture de traversée du pare-feu. Les services hybrides utilisent le même enregistrement SIP TLS utilisé pour le B2B. Vous devez laisser le temps d'avoir le port approprié ouvert sur votre pare-feu d'entreprise.

L'architecture de traversée du pare-feu est démontrée dans le diagramme suivant :

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

Vous pouvez configurer le port d'écoute SIP sur Expressway pour qu'il ait une valeur comprise entre 1024 et 65534. En même temps, cette valeur et le type de protocole doivent être annoncés dans les enregistrements publics SRV DNS 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 l'utilisation de différents ports, comme le montre l'exemple suivant.

Exemple

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

L'enregistrement SRV DNS pour un cluster de deux serveurs Expressway ressemble à ceci :

_sips._tcp.exemple.com emplacement du service SRV :

priorité = 10

poids = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.exemple.com emplacement du service SRV :

priorité = 10

poids = 10

port = 5062

svr hostname = us-expe2.example.com

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

Un périphérique qui est externe au réseau (sur Internet) et qui fait un appel SIP à un utilisateur du domaine d'entreprise (user1@example.com) doit interroger le DNS pour comprendre le type de transport à utiliser, le numéro de port, la manière de charger le partage du trafic et les serveurs SIP à envoyer.

Si l'entrée DNS inclut _sips._tcp, l'entrée spécifie SIP TLS.

TLS est un protocole de type client-serveur et 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 le périphérique appelant et le serveur TLS est le périphérique appelé. Avec TLS, le client vérifie le certificat du serveur, si la vérification du certificat échoue, elle déconnecte l'appel. Le client n'a pas besoin d'un certificat.

La liaison TLS est montrée dans le diagramme suivant :

Cependant, la spécification TLS indique que le serveur peut également vérifier le certificat client en envoyant un message de demande de certificat au client pendant le protocole de liaison TLS. Ce message est utile sur 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 requis lors de l’intégration à Webex.

Les parties appelante et appelée vérifient le certificat de l'autre pair, comme le montre le schéma suivant :

Le Cloud contrôle les identités Expressway et Expressway vérifie l'identité du Cloud. Par exemple, si l'identité du Cloud dans le certificat (CN ou SAN) ne correspond pas à ce qui est configuré sur Expressway, la connexion est abandonnée.

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 d'entreprise à entreprise, si l'entité appelante n'est pas en mesure de fournir un certificat, l'appel est déconnecté.

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

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

 Service et protocole : _sips._tcp.mtls.example.com Priorité : 1 Poids : 10 Numéro de port : 5062 Cible : us-expe1.exemple.com 

Trafic Business-to-Business, Mobile and Remote Access et Webex sur la même paire Expressway

Les appels interentreprises (B2B) et mobiles et accès à distance (MRA) utilisent le port 5061 pour SIP TLS, et le trafic Webex utilise le port 5062 pour 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 une vérification d’identité que le Cloud Webex met en œuvre pour prouver que vous êtes qui vous prétendez être.

La vérification de l'identité se fait en deux étapes :

1. Vérification de la propriété du domaine. Cette étape implique trois types de domaines et il s'agit d'une vérification unique :

   • Domaine de messagerie

   • Domaine DNS de l'Expressway-E

   • Domaine URI du répertoire

2. Vérification de la propriété du nom Expressway-E DNS. Cette étape est réalisée par la mise en œuvre de TLS avec authentification mutuelle et implique l'utilisation de certificats publics sur le Cloud et l'Expressway. Contrairement à la vérification d'identité de domaine, cette étape est effectuée lors de tout appel effectué vers le Cloud et reçu à partir de celui-ci.

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

Le Cloud Webex effectue le contrôle de propriété du domaine pour renforcer la sécurité. L'emprunt d'identité est une menace possible si cette vérification n'est pas effectuée.

L'histoire suivante détaille ce qui pourrait se produire si une vérification de propriété de domaine n'est pas effectuée.

Une entreprise dont le domaine DNS est configuré sur « hacker.com » achète les services hybrides Webex. Une autre société, avec son propre domaine, « example.com », utilise également les services hybrides. Un des directeurs généraux de la société Example.com est nommé Jane Roe et possède le répertoire URI jane.roe@example.com.

L'administrateur de la société Hacker.com met l'un de ses URI de répertoire à jane.roe@example.com et l'adresse électronique à jane.roe@hacker.com. Elle peut le faire parce que le Cloud ne vérifie pas le domaine SIP URI dans cet exemple.

Ensuite, elle se connecte à Webex App avec jane.roe@hacker.com. Parce qu'elle possède le domaine, le courriel de vérification est lu et répondu 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 voit un appel sur son appareil vidéo en provenance de jane.roe@example.com ; l'URI de répertoire est associé à ce compte de messagerie.

« Elle est à l'étranger » pense t-il. « Elle pourrait avoir besoin 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 vu qu'elle voyage, elle lui demande d'envoyer les documents à son adresse électronique privée, jane.roe@hacker.com. De cette façon, l'entreprise réalise seulement après que Jane Roe retourne au bureau et que des informations importantes ont été divulguées en dehors de la société.

La société Example.com a de nombreuses façons 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 appelant à partir de Webex est correcte et non falsifiée.

Pour vérifier l’identité, Webex exige que l’entreprise prouve qu’elle possède les domaines utilisés dans l’appel hybride. Si ce n’est pas le cas, les services hybrides ne fonctionneront pas.

Pour assurer cette acquisition, les deux étapes de vérification du domaine sont requises :

1. Démontrer que l'entreprise possède le domaine de messagerie, le domaine Expressway-E, le domaine répertoire URI.

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

   • Pour prouver la propriété, l'administrateur DNS doit entrer un enregistrement Txt DNS (TXT). Un enregistrement TXT est un type d'enregistrement de ressource dans le DNS utilisé pour fournir la possibilité d'associer un texte arbitraire et non formaté à un nom d'organisateur ou autre.

   • L'administrateur DNS doit entrer l'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 est réussie et que le résultat correspond au jeton généré à partir du Cloud Webex, le domaine est vérifié.

   • Par exemple, l’administrateur doit prouver qu’il possède le domaine « example.com », s’il souhaite que les services hybrides Webex fonctionnent sur son domaine.

   • Grâce à https://admin.webex.com, elle lance 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 configurée sur 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, comme dans l'exemple suivant :

     

   • À ce moment précis, le Cloud peut vérifier que l'enregistrement TXT pour le domaine example.com correspond au jeton.

   • Le Cloud effectue une recherche TXT DNS :

     

   • Parce que la valeur TXT correspond à la valeur du jeton, cette correspondance prouve que l'administrateur a ajouté l'enregistrement TXT pour son propre domaine au DNS public et qu'elle possède le domaine.

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

   • Le Cloud doit vérifier que l'Expressway-E a une identité confirmée à partir de l'une des autorités de certification dont 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 exécute un processus de vérification d'identité, basé sur une vérification de validation de domaine (pour les certificats validés par le domaine) ou sur une validation d'organisation (pour les certificats validés par l'organisation).

   • Les appels vers et à partir du Cloud dépendent du certificat qui a été délivré à l'Expressway-E. Si le certificat n'est pas valide, l'appel est coupé.

Le connecteur de périphérique Webex doit communiquer avec Webex pour que l’appel hybride fonctionne.

Webex Device Connector est déployé dans le réseau interne et sa façon de communiquer avec le Cloud passe par 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 TLS. Webex Device Connector est le client TLS, et le Cloud Webex est le serveur TLS. En tant que tel, Webex Device Connector vérifie le certificat du serveur.

L'autorité de certification signe un certificat de serveur en utilisant sa propre clé privée. Toute personne qui a la clé publique peut décoder cette signature et prouver que la même autorité de certification a signé ce certificat.

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. Une clé publique est contenue dans le certificat de l'autorité de certification. 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 de confiance doit se trouver dans le magasin de confiance du connecteur de périphérique Webex.

Lors de la communication avec des périphériques, l'outil utilise les certificats de confiance que vous fournissez. Actuellement, la façon de le faire est de les placer dans [home folder]/.devicestool/certs.

Une liste de certificats d'autorité de certification est également requise pour l'Expressway-E dans la paire traversante. Expressway-E communique avec le Cloud Webex en utilisant SIP avec TLS, renforcée par l'authentification mutuelle. Expressway-E fait confiance aux appels en provenance et en direction du Cloud, uniquement si le CN ou le SAN du certificat présenté par le Cloud pendant la configuration de la connexion TLS correspond au nom du sujet configuré pour la zone DNS sur Expressway (« callservice.webex.com »). L'autorité de certification publie un certificat uniquement après une vérification d'identité. La propriété du domaine callservice.webex.com doit être prouvée pour obtenir un certificat signé. Étant donné que nous (Cisco) possédons ce domaine, le nom DNS « callservice.webex.com » est une preuve directe que le pair distant est vraiment Webex.

le connecteur de calendrier intègre Webex avec Microsoft Exchange 2013, 2016, 2019 ou Office 365 via un compte d’usurpation d’identité. Le rôle de gestion d'emprunt d'identité d'application dans Exchange permet aux applications d'emprunter l'identité d'utilisateurs dans une organisation pour effectuer des tâches au nom de l'utilisateur. Le rôle d’emprunt d’identité d’application doit être configuré dans Exchange et est utilisé dans le connecteur du calendrier en tant que partie de la configuration Exchange sur l’interface Expressway-C.

Le compte d'emprunt d'identité Exchange est la méthode recommandée par Microsoft pour cette tâche. Expressway-C n’ont pas besoin de connaître le mot de passe, car la valeur peut être saisie dans l’interface Expressway-C par un administrateur Exchange. Le mot de passe n'est pas clairement affiché, même si l'administrateur de l'Expressway-C dispose d'un accès racine à la boîte Expressway-C. Le mot de passe est conservé chiffré en utilisant le même mécanisme de chiffrement des informations d’identification que les autres mots de passe sur Expressway-C.

Pour plus de sécurité, suivez les étapes contenues dans le Guide de déploiement du service de calendrier hybride Cisco Webex pour activer TLS afin de sécuriser les connexions EWS sur la ligne.

Pour plus de sécurité, suivez les étapes de déploiement du connecteur de calendrier Expressway pour Microsoft Exchange pour activer TLS afin de sécuriser les connexions EWS sur la ligne.