Le déploiement de la paire Expressway-C et Expressway-E permet des appels vers et depuis Internet en utilisant les technologies de traversée de pare-feu. Ce déploiement est un élément qui prend en toute sécurité votre contrôle d’appel sur site et le lie à Cisco WebEx.

L’Expressway-C et Expressway-E ne nécessitent pas un port entrant être ouverts dans le pare-feu de zone démilitarisée (DMZ) en raison de l’architecture de traversée de pare-feu. Mais la signalisation SIP TCP ports et les ports UDP média doivent être ouverts entrants sur le pare-feu Internet pour permettre les appels entrants sont fournis. 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.example.com SRV service location:

priorité = 10

poids = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

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 serveur à serveur, comme lors d’un appel établi entre Expressway-E et le Cisco WebEx Cloud. Ce concept est appelé TLS avec authentification mutuelle et il est requis lors de l'intégration avec Cisco 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. Cisco WebEx Les services hybrides utilisent le même enregistrement TLS SIP utilisé pour l'activité inter-entreprises (B2B). Dans le cas du port 5061, certains autres services qui ne peuvent pas fournir un certificat de client TLS ne fonctionneront pas.

Les appels inter-entreprises, l'accès mobile et Remote Access (Accès à distance) et le trafic Cisco WebEx sur le même pair Expressway

Les appels interentreprises et les appels mobiles et à distance utilisent le port 5061 pour SIP TLS et le trafic Cisco WebEx utilise le port 5062 pour TLS SIP 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 Cisco Collaboration Cloud implémente pour prouver que vous êtes qui vous prétendez être.Cisco WebEx

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.

Une histoire pour montrer l'importance du contrôle de propriété du domaine

Le Cisco WebEx sur le Cloud 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 société dont le domaine DNS est configuré sur « hacker.com » achète les services hybrides Cisco 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 à Partage Cisco Webex 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 à partir de son application Partage Cisco Webex. John est assis dans son bureau et voit un appel sur son périphérique vidéo provenant de jane.roe@example.com ; c'est l'annuaire URI 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 Cisco Collaboration Cloud est de s'assurer que l'identité de toute personne appelant à partir de est correcte et non falsifiée.Cisco WebExCisco WebEx

Pour vérifier l'identité, Cisco WebEx exige que la société prouve qu'elle possède les domaines utilisés dans l'appel hybride. S’il ne démarre pas, 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 Cisco WebEx sur le Cloud exécute une requête d’enregistrement TXT pour ce domaine.

   • Si la requête TXT est réussie et que le résultat correspond à l'unité générée par Cisco Collaboration Cloud, le domaine est vérifié.Cisco WebEx

   • À titre d'exemple, l'administrateur doit prouver qu'il possède le domaine « example.com », s'il veut que et les services hybrides fonctionnent sur son domaine.Cisco WebEx

   • Grâce à , elle lance le processus de vérification en créant un enregistrement TXT correspondant au jeton généré par Cisco Collaboration Cloud :https://admin.webex.comCisco WebEx

     

   • L'administrateur DNS crée alors un enregistrement TXT pour ce domaine avec la valeur 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é.

L’hôte du connecteur Expressway-C doit être enregistré pour que les Cisco WebExservices hybrides fonctionnent.

Expressway-C est déployé dans le réseau interne et la façon dont il s'inscrit dans le Cloud est à travers une connexion HTTPS sortante—le même type qui est utilisé pour tout navigateur qui se connecte à une connexion de serveur Web.

L’enregistrement et la communication avec le Cisco WebEx Cloud utilisent TLS. Expressway-C est le client TLS et le Cisco WebEx Cloud est le serveur TLS. Par conséquent, l'Expressway-C vérifie le certificat de 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 l'Expressway-C valide le certificat fourni par le Cloud, il doit utiliser la clé publique de l'autorité de certification qui a signé le 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 être dans le magasin de confiance de l'Expressway. Ainsi, le Expressway peut vérifier que l’appel provient véritablement du Cisco WebEx Cloud.

Avec le téléchargement manuel, vous pouvez télécharger tous les certificats d'autorité de certification dans le magasin de confiance d'Expressway-C.

Avec le téléchargement automatique, le Cloud lui-même télécharge ces certificats dans le magasin de confiance d'Expressway-C. Nous vous recommandons d'utiliser le téléchargement automatique. La liste des certificats peut changer et le téléchargement automatique vous garantit la liste la plus à jour.

Si vous autorisez l’installation automatique des certificats d’autorité de certificat, vous êtes redirigé vers https://admin.webex.com (le portail de gestion). La redirection est effectuée par l'Expressway-C elle-même sans aucune intervention de l'utilisateur Vous, en tant qu'administrateur Cisco WebEx, devez vous authentifier via une connexion HTTPS. Peu de temps après, le Cloud envoie les certificats CA vers l'Expressway-C.

Jusqu'à ce que les certificats soient téléchargés dans le magasin de confiance Expressway-C, la connexion HTTPS ne peut pas être établie.

Pour éviter ce problème, l'Expressway-C est préinstallé avec les certificats Cisco WebEx approuvés par une AC. Ces certificats ne sont utilisés que pour configurer et valider la connexion HTTPS initiale et ne figurent pas dans la liste de confiance Expressway-C. Une fois que les certificats des autorités de certification de confiance sont extraits du Cloud via cette connexion HTTPS initiale, ces certificats sont disponibles pour une utilisation au niveau de la plate-forme ; puis, ils figurent dans la liste de confiance Expressway-C.

Cette liste affiche les certificats de l’autorité de certification Cisco WebEx actuellement utilisés par le Cloud. Cette liste pourrait changer dans le futur :

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

Une liste de certificats d'autorité de certification est également requise pour l'Expressway-E dans la paire traversante. Expressway-E communique avec le Cisco WebEx Cloud en utilisant SIP avec TLS, appliqué par authentification mutuelle. Expressway-E approuve les appels qui proviennent et sont en cours sur le Cloud, seulement 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 callservice.webex.com domaine doit être prouvée pour obtenir un certificat signé. Parce que nous (Cisco) possédons ce domaine, le nom DNS «callservice.webex.com» est une preuve directe que l’homologue distant est véritablement Cisco WebEx.

Connecteur du calendrier intègre Cisco WebEx avec Microsoft Exchange 2010, 2013, 2016 ou Office 365 via un compte d’emprunt 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é de l'application doit être configuré dans Exchange et être utilisé dans le Connecteur du calendrier dans le cadre 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 les administrateurs 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 Expressway-C a accès à la racine de la case Expressway-C. Le mot de passe est enregistré chiffré en utilisant le même mécanisme de chiffrement des informations d’identification que les autres mots de passe sur le 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.