Cinq choses importantes à préparer avant de déployer les services hybrides Cisco Spark

Document created by Cisco Localization Team on Feb 4, 2017
Version 1Show Document
  • View in full screen mode
 

Pourquoi ces cinq points sont importants pour le déploiement des services hybrides Cisco Spark

 

Ce document fournit plus de contexte sur cinq éléments de configuration clés qui se rapportent aux services hybrides Cisco Spark.

  

Ces cinq points sont essentiels si vous souhaitez déployer avec succès les services hybrides Cisco Spark hébergés par Expressway (Service d'appels Aware/Connect et Service de calendrier). Nous avons souligné ces cinq 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é.

      

  •  

    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 pour s'aligner par rapport à la configuration typique dans une interface utilisateur, alors laissez un délai pour que ces éléments soient triés.

      

  •  

    Lorsque ces éléments sont traités dans votre environnement, le reste de votre configuration des services hybrides Cisco Spark se déroulera sans problèmes.

      

  

Port TCP 5062 sur le pare-feu Internet

 

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 représente ce qui relie en toute sécurité votre contrôle d'appel sur site avec Cisco Spark via Cisco Collaboration Cloud.

L'Expressway-C et l'Expressway-E n'exigent pas qu'un port entrant soit ouvert dans le pare-feu de la zone démilitarisée (DMZ) en raison de l'architecture de traversée du pare-feu. 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 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.

 

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 de serveur à serveur, comme sur un appel passé entre l'Expressway-E et le Cisco Collaboration Cloud. Ce concept est appelé TLS avec authentification mutuelle et est requis lors de l'intégration avec Cisco Spark.

 
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 Cisco Spark utilisent le même enregistrement SIP TLS 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.

     

Trafic interentreprises , mobile et Remote Access (Accès à distance) et Spark sur la même paire Expressway

Les appels interentreprises et les appels mobiles et à distance utilisent le port 5061 pour SIP TLS et le trafic Cisco Spark utilise le port 5062 pour SIP TLS avec authentification mutuelle.

Pourquoi le Cloud vérifie la propriété du domaine

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.

 

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

Cisco Collaboration Cloud effectue le contrôle de propriété du domaine pour renforcer la sécurité. L'usurpation 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 Cisco Spark Hybrides. 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 à Cisco Spark 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 passe un appel à un collègue, John Doe, en composant john.doe@example.com de son client Cisco Spark. 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 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 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 de Cisco Collaboration Cloud est de s'assurer que l'identité de toute personne appelant à partir de Cisco Spark est correcte et non falsifiée.

 

Pour vérifier l'identité, Cisco Spark exige que la société prouve qu'elle possède les domaines utilisés dans les appels hybrides Spark. Si ce n'est pas le cas, les services hybrides Cisco Spark 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, Cisco Collaboration 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é par Cisco Collaboration Cloud, le domaine est vérifié.

        

    •  

      Par exemple, l'administrateur doit prouver qu'elle possède le domaine « example.com », si elle veut que Cisco Spark et Cisco Spark Hybrid Services travaillent sur son domaine.

        

    •  
      Via le portail de gestion, elle démarre le processus de vérification en créant un enregistrement TXT correspondant au jeton généré par Cisco Collaboration Cloud :


        
    •  
      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é.

        

    

Autorités de certification prises en charge

L'organisateur du connecteur Expressway-C doit être enregistré dans le Cisco Collaboration Cloud pour que les services 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.

 

Enregistrement et communication avec les applications Cisco Collaboration Cloud de TLS. L'Expressway-C est le client TLS et le Cisco collaboration 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, l'Expressway peut vérifier que l'appel provient véritablement du Cisco Collaboration 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 certification, vous êtes redirigé vers Cisco Cloud Collaboration Management (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 Spark, vous 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 CA approuvés par Cisco Spark. 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.

 
Ce processus est sécurisé pour ces raisons :
  •  

    Nécessite un accès administrateur à Expressway-C et à Cisco Cloud Collaboration Management (admin.ciscospark.com). Ces connexions utilisent HTTPS et sont cryptées.

      

  •  

    Les certificats sont envoyés du Cloud vers l'Expressway en utilisant la même connexion cryptée.

      

   

Cette liste montre les certificats de l'autorité de certification que Cisco Collaboration Cloud utilise actuellement. 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 Cisco Collaboration Cloud en utilisant SIP avec TLS, renforcée par l'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 pendant la connexion TLS correspond au nom de domaine configuré pour la zone DNS sur Expressway (« callservice.ciscospark.com »). L'autorité de certification publie un certificat uniquement après une vérification d'identité. La propriété du domaine callservice.ciscospark.com doit être prouvée pour obtenir un certificat signé. Parce que nous (Cisco) possédons ce domaine, le nom DNS « callservice.ciscospark.com » est une preuve directe que le pair distant est vraiment le Cisco Collaboration Cloud.

 

Compte d'emprunt d'identité Exchange

 

Le connecteur de calendrier intègre Cisco Spark avec Microsoft Exchange 2010, 2013, 2016 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'usurpation d'identité dde l'application doit être configuré dans Exchange et est utilisé dans le connecteur de 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. L'accès à l'aide des services Web Exchange (ESW) à l'aide du compte d'emprunt d'identité est sécurisé parce que :

  • L'accès n'est pas disponible pour les utilisateurs et les connexions EWS peuvent être sécurisées sur le fil via TLS.

     

  • Le compte ne peut être utilisé que par EWS ; les utilisateurs ayant accès à un compte possédant des droits d'usurpation d'identité devront écrire une application EWS pour accéder à la boîte aux lettres d'un utilisateur et ne peuvent pas accéder directement à la boîte aux lettres via un client de boîte aux lettres.

     

  • Le mot de passe du compte d'emprunt d'identité est enregistré chiffré sur Expressway-C.

     

  

Pour cette raison, les administrateurs d'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.

 

La sécurité assure que seule l'application Expressway-C utilise ce mot de passe.

 

Le déploiement de plusieurs Expressway

L'organisateur du connecteur Expressway-C peut accueillir jusqu'à six serveurs. Dans des scénarios avec plusieurs clusters Unified CM dans différentes régions, vous pouvez déployer plusieurs clusters Expressway-C—un par cluster Unified CM—avec une redondance locale uniquement. Si l'un des nœuds Expressway-C diminue, un autre nœud du cluster se connecte au Cisco Collaboration Cloud et au Unified CM. La redondance géographique n'est actuellement pas disponible.

Expressway-C et Expressway-E utilisés pour la signalisation et les médias SIP

   

Vous pouvez avoir plusieurs clusters Expressway-C et Expressway-E dans différentes régions. Unified CM utilise les clusters Expressway les plus proches pour les appels sortants d'Unified CM vers Cisco Collaboration Cloud, en fonction des partitions et de la configuration de l'espace de recherche d'appel.

  

Pour les appels entrants, vous devez comprendre comment répartir le trafic entre les différents clusters Expressway-E d'Internet Edge.

  
  •  

    Si l'Internet Edge est déployé dans le même centre de données ou dans la même zone, l'équilibrage de charge peut se produire au niveau SRV DNS. À titre d'exemple, si le réseau d'entreprise comprend trois Edges Internet utilisées pour Spark Hybrid Calling, chacune constituée d'un cluster de deux nœuds Expressway-E et Expressway-C, the_sips._tcp.example.com comprendra les six Expressway-E (3 Expressway-E multipliés par 2) avec la même priorité et le même poids. Cette configuration distribue également les appels du Cisco Collaboration Cloud aux différents clusters Expressway-E et Expressway-C.

      

  •  

    Si l'Internet Edge est déployé dans différentes régions, la meilleure solution consiste à utiliser les services Geo DNS.

      

    Les services DNS Geo sont fournis par de nombreux fournisseurs DNS et sont basés sur la capacité du DNS Geo de vérifier l'adresse IP source, de comprendre le pays ou la région à laquelle appartient l'adresse IP et de transmettre la requête Edge qui est physiquement la plus proche de cette région. Notez qu'un appel hybride à Expressway-E provient du Cisco Collaboration Cloud et pas directement du client Spark. Pour cette raison, l'adresse IP source est l'une des adresses IP que Cisco Collaboration Cloud utilise.

      

    Basé sur cette classification et de la configuration sur le DNS Geo, l'appel est envoyé à l'Expressway-E qui est physiquement la plus proche de la zone à laquelle appartient l'adresse IP appelante.

      

  
Par exemple, les services AWS Geo DNS sont configurés de la façon suivante :


  

Une fois l'enregistrement SRV créé, une étiquette « Emplacement » est appliquée et le pays est spécifié. Un appel venant du Cloud avec une adresse IP qui fait partie du même emplacement (Italie, dans cet exemple) est envoyé à emea-expe1.example.com. De nombreux enregistrements SRV peuvent être créés en fonction du nombre de régions.

  

La configuration de Geo DNS dépend du fournisseur DNS et cet exemple de configuration est fourni uniquement comme référence.

  
Dans le cas de deux clusters Expressway-C et Expressway-E déployés aux États-Unis et en EMEA (Europe, milieu de l'est et l'Afrique), l'enregistrement DNS SRV _sips._tcp.example.com est configuré comme appartenant à deux zones différentes. L'utilisation de AWS nécessite deux enregistrements SRV DNS pour _sips._tcp.example.com, comme le montre l'exemple suivant :


  

De cette façon, un appel sortant du Cisco Collaboration Cloud aux États-Unis entre dans l'Expressway-E aux États-Unis et uniquement dans le cas où ce cluster Expressway-E aux États-Unis n'est pas disponible, le cluster Expressway-E dans EMEA (Europe, milieu de l'est et l'Afrique) est utilisé. Si l'appel quitte le Cisco Collaboration Cloud dans EMEA (Europe, milieu de l'est et l'Afrique), il se rend dans le cluster Expressway-E situé dans EMEA et n'utilise le cluster US que si le cluster EMEA n'est pas disponible.

  
 

Attachments

    Outcomes