- Accueil
- /
- Article
Exigences de sécurité pour Webex Calling
Cet article est destiné aux administrateurs réseau, en particulier aux administrateurs de pare-feu et de sécurité proxy qui souhaitent utiliser Webex Calling au sein de leur organisation.
Pour connaître les informations de référence des ports pour le pare-feu et les conditions d’accès requises, consultez Informations de référence des ports pour Cisco Webex Calling.
Configuration requise pour les terminaux
Webex Calling Edge
Pour effectuer un enregistrement ou un appel SIP, procédez comme suit :
-
Recherchez l’adresse hôte d’un terminal SIP pour les nœuds Edge opérationnels.
-
Remplissez toutes les conditions préalables liées à la configuration de l’utilisateur et du périphérique.
-
Vérifiez que le terminal dispose d’une connectivité au réseau public pour lancer la détection des services.
-
Terminez la configuration des conditions préalables d’amorçage du terminal à l’aide d’une configuration de mise à disposition spécifique à la région ou au centre de données. Cette configuration permet d’obtenir le suffixe du nom de domaine approprié pour la détection des services.
IPv4 par rapport à IPv6
Les périphériques peuvent fonctionner en mode simple version ou double pile. La configuration détermine les modifications du protocole préféré et ces modifications ne font pas partie de la détection des services.
-
Mode simple pile–n’active qu’un seul protocole IP (par exemple, IPv4) et ignore les adresses des autres protocoles.
-
Mode double pile–sélectionne une version IP préférée en fonction de la configuration.
Le client considère que la priorité de toutes les adresses préférées est plus faible (c’est-à-dire qu’elles sont préférées) par rapport à toutes les adresses de l’IP. Si le protocole IPv4 est préféré, toutes les adresses IPv4 sont tentées avant de tenter une adresse IPv6. Si toutes les adresses échouent, le cycle recommence avec l’adresse de protocole préférée de priorité la plus basse.
Un client mobile qui s’inscrit à la réception d’une notification push peut décider d’optimiser le mode en fonction des inscriptions précédentes.
Résolution de l’adresse de l’hôte à partir de l’adresse DNS SRV
Dans le fichier de configuration du terminal obtenu lors de la mise à disposition, l’indicateur de domaine spécifie le nom de domaine pour découvrir le service de périphérie d’accès. Voici un exemple de nom de domaine :
wxc.edge.bcld.webex.com
D’après cet exemple, le terminal effectuant une recherche DNS SRV pour ce domaine peut donner une réponse similaire à la suivante :
# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com _sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com. _sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.
Dans ce cas, l’enregistrement SRV pointe sur 3 enregistrements A.
sip-edge1.us-dc1.bcld.webex.com sip-edge2.us-dc1.bcld.webex.com
Dans l’exemple, tous les hôtes sont annoncés pour contacter le port 5061 avec un coefficient et une priorité différents.
Considérez ces conditions requises pour les terminaux.
-
Un point de terminaison doit utiliser
_sips._tcp
(combinaison de service et de protocole) comme préfixe pour effectuer une recherche DNS SRV pour obtenir l'adresse de l'hôte pour initier une communication basée sur TLS. -
Un terminal doit effectuer une consultation SRV du DNS pour les conditions expliquées dans la section Résolution de l’adresse de l’hôte à partir de l’adresse DNS SRV.
-
Un terminal doit respecter l’hôte, le port, le coefficient et la priorité tels qu’ils sont annoncés pour chacune des adresses d’hôtes. Il doit également créer une affinité entre l’hôte et le port lors de la création d’une connexion par socket pendant l’enregistrement SIP.
-
En ce qui concerne l’utilisation de l’enregistrement SRV du DNS, les critères de sélection des hôtes basés sur la priorité et l’importance sont expliqués dans la norme RFC 2782.
Configuration requise pour les protocoles SIP et média
Conditions requise pour le protocole SIP sécurisé avec mTLS (TLS mutuel)
Les conditions requises sont expliquées en détail ici.
Un certificat signé est nécessaire pour une autorisation et une authentification réussies des appels à partir du trunk. Le certificat doit répondre aux conditions suivantes :
-
Le certificat doit être signé par une autorité de certification mentionnée dans Quelles autorités de certification racine sont prises en charge pour les appels vers les plateformes audio et vidéo Cisco Webex ?
-
Téléchargez le bundle de confiance mentionné dans Quelles autorités de certification racine sont prises en charge pour les appels vers les plateformes audio et vidéo Cisco Webex ? sur le CUBE.
-
Le certificat doit toujours être valide :
-
les certificats signés doivent toujours avoir une période d’expiration valide.
-
les certificats racine ou intermédiaires doivent avoir une période d’expiration valide et ne doivent pas être révoqués.
-
les certificats doivent être signés pour une utilisation client et serveur.
-
les certificats doivent contenir le Nom de Domaine Pleinement Qualifié (FQDN) comme nom commun ou nom de substitution de sujet dans le certificat avec le FQDN choisi dans le Control Hub. Par exemple :
-
Un trunk configuré à partir du Control Hub de votre organisation avec london.lgw.cisco.com:5061 comme FDQN doit contenir london.lgw.cisco.com dans le CN ou SAN du certificat.
-
Un trunk configuré à partir du Control Hub de votre organisation avec london.lgw.cisco.com comme SRV doit contenir london.lgw.cisco.com dans le CN ou SAN du certificat. Les enregistrements vers lesquels l’adresse SRV se résout (enregistrement CNAME/A/adresse IP) sont facultatifs dans le SAN.
-
-
Vous pouvez partager des certificats avec plusieurs passerelles locales, mais assurez-vous que les exigences relatives aux FQDN sont respectées.
-
Hors du champ d’application
Cet article n’inclut pas les informations suivantes relatives à la sécurité du réseau :
-
Exigences F5 pour CA et Ciphers
-
Une API basée sur HTTP pour télécharger les règles de pare-feu pour Webex.
-
API pour un bundle de confiance
-
Exigences en matière de pare-feu et désactivation d’ALG