In diesem Abschnitt werden die wichtigsten Konfigurationselemente, die im Zusammenhang mit hybriden-Diensten auftreten, detailliert erläutert.

Diese Punkte sind von entscheidender Bedeutung, wenn Sie Hybrid Calling für Webex-Geräte erfolgreich bereitstellen möchten. Diese Punkte möchten wir aus den folgenden Gründen besonders hervorheben:

• Wir möchten sie erläutern, damit Sie Ihre Rolle in einer Hybrid-Bereitstellung besser verstehen und sich sicher fühlen.

• Dabei handelt es sich um obligatorische Voraussetzungen, die für eine sichere Bereitstellung zwischen unserer Cloud und Ihrer lokalen Umgebung sorgen.

• Diese Aktivitäten sollten vor dem Tag der Bereitstellung ausgeführt werden: Die Einrichtung kann etwas länger als eine typische Konfiguration auf einer Benutzeroberfläche in Anspruch nehmen, berücksichtigen Sie also einen ausreichenden Zeitrahmen für diese Elemente.

• Nachdem diese Elemente in Ihrer Umgebung eingerichtet wurden, verläuft die Konfiguration der restlichen, hybriden -Dienste reibungslos.

Die Bereitstellung des Expressway-C- und Expressway-E-Paares ermöglicht Anrufe über das und vom Internet mithilfe von Firewall-Traversal-Technologien. Mit dieser Bereitstellung wird Ihre lokale Anrufsteuerung sicher mit Webex verknüpft.

Für Expressway-C und Expressway-E müssen aufgrund der Firewall-Traversalarchitektur keine eingehenden Ports in der Firewall der demilitarisierten Zone (DMZ) geöffnet werden. Die TCP SIP-Signalports und UDP-Medienports müssen jedoch für eingehende Verbindungen in der Internet-Firewall geöffnet werden, um eingehende Anrufe durchzulassen. Dafür muss die Zeitspanne zum Öffnen des entsprechenden Ports in Ihrer Unternehmensfirewall berücksichtigt werden.

Die Traversalarchitektur der Firewall wird im folgenden Diagramm dargestellt:

Für eingehende Business-to-Business-Anrufe (B2B) über das SIP-Protokoll müssen beispielsweise die TCP-Ports 5060 und 5061 (5061 wird für SIP TLS eingesetzt) in der externen Firewall geöffnet werden, außerdem müssen die UDP-Medienports für Dienste wie Voice, Video, Inhaltsfreigabe, Dualvideo usw. geöffnet werden. Welche Medienports geöffnet werden müssen, hängt von der Anzahl gleichzeitiger Anrufe und der Anzahl der Dienste ab.

Sie können den SIP-Überwachungsport in Expressway auf einen Wert zwischen 1024 und 65534 konfigurieren. Gleichzeitig muss dieser Wert und der Protokolltyp in den öffentlichen DNS-SRV-Datensätzen angekündigt werden und derselbe Wert muss in der Internet-Firewall geöffnet werden.

Obwohl der Standardport für SIP TCP 5060 und für SIP TLS 5061 lautet, können auch andere Ports verwendet werden, wie das folgende Beispiel zeigt.

Beispiel

In diesem Beispiel wird davon ausgegangen, dass Port 5062 für eingehende SIP TLS-Anrufe verwendet wird.

Der DNS-SRV-Datensatz für ein Cluster aus zwei Expressway-Servern sieht folgendermaßen aus:

_sips._tcp.example.com SRV-Dienststandort:

Priorität = 10

Gewichtung = 10

Port = 5062

SVR-Hostname = us-expe1.example.com

_sips._tcp.example.com SRV-Dienststandort:

Priorität = 10

Gewichtung = 10

Port = 5062

SVR-Hostname = us-expe2.example.com

Diese Datensätze bedeuten, dass Anrufe an us-expe1.example.com und us-expe2.example.com mit gleichmäßiger Lastverteilung (Priorität und Gewichtung) und TLS als Transporttyp sowie 5062 als Überwachungsportnummer weitergeleitet werden.

Ein externes Gerät (im Internet), das einen SIP-Anruf an einen Benutzer der Unternehmensdomäne (user1@example.com) tätigt, muss eine DNS-Abfrage stellen, um den Transporttyp, die Portnummer, die Art der Lastenverteilung und die SIP-Server herauszufinden, die für den Anruf verwendet werden müssen.

Wenn der DNS-Eintrag _sips._tcp enthält, gibt der Eintrag SIP TLS an.

TLS ist ein Client-Server-Protokoll, bei dem in den gängigsten Umsetzungen Zertifikate zur Authentifizierung eingesetzt werden. In einem Business-to-Business-Anrufszenario ist der TLS-Client der Anrufapparat und der TLS-Server der angerufene Apparat. Mit TLS überprüft der Client das Serverzertifikat und wenn die Zertifikatsüberprüfung fehlschlägt, wird der Anruf getrennt. Der Client benötigt kein Zertifikat.

Der TLS-Handshake wird im folgenden Diagramm veranschaulicht:

Die TLS-Spezifikation gibt an, dass der Server das Client-Zertifikat ebenfalls überprüfen kann, indem er in dem TLS-Handshakeprotokoll eine Zertifikatsanforderungsmeldung an den Client sendet. Diese Nachricht ist hilfreich bei einer Server-zu-Server-Verbindung, z. B. bei einer Verbindung, die zwischen Expressway-E und der Webex-Cloud hergestellt wird. Dieses Konzept wird als TLS mit gegenseitiger Authentifizierung bezeichnet und ist bei der Integration mit Webex erforderlich.

Der Anrufer und Angerufene überprüfen das Zertifikat des anderen Gesprächsteilnehmers, wie das folgende Diagramm veranschaulicht:

Die Cloud überprüft die Expressway-Identität und Expressway überprüft die Cloud-Identität. Wenn beispielsweise die Cloud-Identität im Zertifikat (CN oder SAN) nicht mit der Konfiguration in Expressway übereinstimmt, wird die Verbindung abgebrochen.

Wenn die gegenseitige Authentifizierung aktiviert wird, fordert Expressway-E stets das Client-Zertifikat an. Infolge dessen funktioniert der Mobile and Remote Access (MRA) nicht, da Zertifikate bei den meisten Jabber-Clients nicht bereitgestellt werden. Kann der Anrufer in einem Business-to-Business-Szenario kein Zertifikat angeben, wird der Anruf getrennt.

Wir empfehlen, dass Sie einen anderen Wert als 5061 für TLS mit gegenseitiger Authentifizierung verwenden, z. B. Port 5062. Webex-Hybriddienste verwenden den gleichen SIP TLS-Datensatz wie für B2B. Im Fall von Port 5061 funktionieren einige Dienste nicht, die kein TLS-Client-Zertifikat bereitstellen können.

Wenn ein vorhandener Datensatz bereits für die Business-to-Business-Kommunikation verwendet wird, empfehlen wir, eine Unterdomäne der Unternehmensdomäne als SIP-Ziel in Control Hub und folglich einen öffentlichen DNS-SRV-Datensatz wie folgt anzugeben:

 Dienst und Protokoll: _sips._tcp.mtls.example.com Priorität: 1 Gewicht: 10 Portnummer: 5062 Ziel: us-expe1.example.com 

Datenverkehr für Business-to-Business, Mobile und Remote Access und Webex auf demselben Expressway-Paar

Business-to-Business (B2B)- und Mobile and Remote Access (MRA)-Anrufe verwenden Port 5061 für SIP TLS, und der Webex-Datenverkehr verwendet Port 5062 für SIP TLS mit gegenseitiger Authentifizierung.

Die Domänenbesitz-Überprüfung ist Teil der Identitätsverifizierung. Die Domänenverifizierung ist eine Sicherheitsmaßnahme und eine Identitätsüberprüfung, die in der Webex-Cloud implementiert ist, um zu beweisen, dass Sie derjenige sind, für den Sie sich ausgeben.

Die Identitätsüberprüfung wird in zwei Stufen vorgenommen:

1. Domänenbesitz-Überprüfung. Dieser Schritt umfasst drei Arten von Domänen und ist eine einmalige Verifizierungsüberprüfung:

   • E-Mail-Domäne

   • Expressway-E DNS-Domäne

   • Verzeichnis-URI-Domäne

2. Expressway-E DNS-Name-Besitz-Überprüfung. Dieser Schritt wird durch die Implementierung des TLS mit gegenseitiger Authentifizierung vorgenommen und umfasst den Einsatz öffentlicher Zertifikate in der Cloud und in Expressway. Im Gegensatz zur Domänenidentitätsüberprüfung wird dieser Schritt während eines über die Cloud getätigten und von der Cloud angenommenen Anrufs durchgeführt.

Die Bedeutung der Domänenbesitz-Überprüfung

Die Webex-Cloud führt die Domänenbesitz-Überprüfung durch, um die Sicherheit zu erzwingen. Identitätsdiebstahl ist eine mögliche Bedrohung, wenn diese Überprüfung nicht durchgeführt wird.

In den folgenden Berichtsdetails wird veranschaulicht, was passieren kann, wenn die Domänenbesitz-Überprüfung nicht durchgeführt wird.

Ein Unternehmen, bei dem die DNS-Domäne auf „hacker.com“ festgelegt ist, erwirbt hybride Webex-Dienste. Ein anderes Unternehmen, dessen eigene Domäne auf „example.com“ festgelegt ist, nutzt ebenfalls hybride Dienste. Eine der Geschäftsführerinnen des Unternehmens Example.com heißt Jane Roe und besitzt den Verzeichnis-URI jane.roe@example.com.

Der Administrator des Unternehmens Hacker.com legt einen ihrer Verzeichnis-URIs auf jane.roe@example.com und die E-Mail-Adresse auf jane.roe@hacker.com fest. Das kann sie machen, da die Cloud die SIP URI-Domäne in diesem Beispiel nicht überprüft.

Anschließend meldet sie sich mit jane.roe@hacker.com bei der Webex-App an. Da sie die Domäne besitzt, wird die Verifizierungs-E-Mail gelesen und beantwortet und sie kann sich anmelden. Schließlich ruft sie ihren Kollegen John Doe an, indem sie in ihrer Webex-App john.doe@example.com wählt. John sitzt in seinem Büro und sieht auf seinem Videogerät einen eingehenden Anruf von jane.roe@example.com; das ist die mit dem E-Mail-Konto verknüpfte Verzeichnis-URI.

Er denkt sich: „Jane ist im Ausland“. „Vielleicht braucht sie etwas Dringendes“. Er nimmt das Gespräch an und die falsche Jane Roe fragt nach wichtigen Dokumenten. Sie erklärt ihm, dass ihr Gerät kaputt ist und da sie unterwegs ist, bittet sie ihn, die Dokumente an ihre private E-Mail-Adresse zu senden, jane.roe@hacker.com. Auf diesem Weg bemerkte das Unternehmen erst nach der Rückkehr von Jane Roe im Büro, dass Unternehmensinformationen nach außen durchgesickert sind.

Das Unternehmen Example.com hat viele Maßnahmen zum Schutz vor betrügerischen Anrufen aus dem Internet ergriffen. Eine der Aufgaben der Webex Cloud besteht jedoch darin, sicherzustellen, dass die Identität des Anrufers aus Webex korrekt ist und nicht gefälscht wurde.

Für die Identitätsüberprüfung muss Webex nachweisen, dass die in Hybrid Calling verwendeten Domänen dem Unternehmen gehören. Wenn dies nicht der Fall ist, funktionieren Hybrid-Dienste nicht.

Damit dieser Besitz sichergestellt werden kann, sind zwei Verifizierungsschritte erforderlich:

1. Es muss ein Nachweis erbracht werden, dass das Unternehmen die E-Mail-Domäne, Expressway-E-Domäne, Verzeichnis-URI-Domäne besitzt.

   • All diese Domänen müssen routingfähig und den öffentlichen DNS-Servern bekannt sein.

   • Für den Nachweis des Besitzes muss der DNS-Administrator einen DNS-Textdatensatz (TXT) eingeben. Ein TXT-Datensatz ist eine Art Ressourcendatensatz im DNS, mit dem beliebiger und unformatierter Text mit einem Host- oder anderen Namen verknüpft werden kann.

   • Der DNS-Administrator muss den TXT-Datensatz in den Bereich eingeben, dessen Besitz nachgewiesen werden muss. Nach diesem Schritt führt die Webex-Cloud eine TXT-Datensatzabfrage für diese Domäne durch.

   • Wenn die TXT-Abfrage erfolgreich ist und das Ergebnis mit dem in der Webex-Cloud generierten Token übereinstimmt, ist die Domäne verifiziert.

   • Der Administrator muss beispielsweise nachweisen, dass er die Domäne „example.com“ besitzt, wenn er möchte, dass die hybriden Webex-Dienste mit seiner Domäne funktionieren.

   • Der Administrator startet den Verifizierungsprozess über https://admin.webex.com, indem er einen TXT-Datensatz erstellt, der mit dem in der Webex-Cloud generierten Token übereinstimmt:

     

   • Der DNS-Administrator erstellt dann einen TXT-Datensatz für diese Domäne, wobei der Wert auf 123456789abcdef123456789abcdef123456789abcdef123456789abcdef festgelegt ist, wie im folgenden Beispiel:

     

   • Zu diesem Zeitpunkt kann die Cloud verifizieren, dass der TXT-Datensatz für die Domäne example.com mit dem Token übereinstimmt.

   • Die Cloud führt eine TXT DNS-Suche durch:

     

   • Da der TXT-Wert mit dem Tokenwert übereinstimmt, wird mit dieser Übereinstimmung nachgewiesen, dass der Administrator den TXT-Datensatz für die eigene Domäne zum öffentlichen DNS hinzugefügt hat und Besitzer der Domäne ist.

2. Expressway-E DNS-Name-Besitz-Überprüfung.

   • Die Cloud muss überprüfen, dass Expressway-E eine bestätigte Identität von einer der Zertifizierungsstellen besitzt, der die Cloud vertraut. Der Expressway-E-Administrator muss für Expressway-E von einer der Zertifizierungsstellen ein öffentliches Zertifikat anfordern. Zum Ausstellen des Zertifikats führt die Zertifizierungsstelle einen Identitätsverifizierungsvorgang durch, der auf einer Domänenvalidierungsüberprüfung (für domänenvalidierte Zertifikate) oder Organisationsvalidierungsüberprüfung (für organisationsvalidierte Zertifikate) basiert.

   • Anrufe in und aus der Cloud hängen von dem Zertifikat ab, das für Expressway-E ausgestellt wurde. Wenn das Zertifikat ungültig ist, wird die Verbindung getrennt.

Webex Device Connector muss mit Webex kommunizieren, damit Hybrid Calling funktioniert.

Der Webex Device Connector wird im internen Netzwerk bereitgestellt und kommuniziert mit der Cloud über eine ausgehende HTTPS-Verbindung. Dieser Typ wird von jedem Browser verwendet, der eine Verbindung zu einem Webserver herstellt.

Die Kommunikation mit der Webex-Cloud verwendet TLS. Webex Device Connector ist der TLS-Client und die Webex-Cloud ist der TLS-Server. Daher überprüft der Webex Device Connector das Serverzertifikat.

Die Zertifizierungsstelle signiert ein Serverzertifikat mit einem eigenen privaten Schlüssel. Jeder mit dem öffentlichen Schlüssel kann die Signatur entschlüsseln und nachweisen, dass dieselbe Zertifizierungsstelle das Zertifikat signiert hat.

Wenn Webex Device Connector das von der Cloud bereitgestellte Zertifikat validieren muss, muss es den öffentlichen Schlüssel der Zertifizierungsstelle verwenden, die das Zertifikat signiert hat, um die Signatur zu entschlüsseln. Im Zertifikat der Zertifizierungsstelle ist ein öffentlicher Schlüssel enthalten. Um eine Vertrauensstellung mit den von der Cloud verwendeten Zertifizierungsstellen herzustellen, muss sich die Liste der Zertifikate dieser vertrauenswürdigen Zertifizierungsstellen im Vertrauensspeicher von Webex Device Connector befinden.

Bei der Kommunikation mit Geräten verwendet das Tool vertrauenswürdige Zertifikate, die Sie bereitstellen. Derzeit können Sie dies tun, indem Sie sie in [Home Folder]/.devicestool/certs ablegen.

Für Expressway-E im Traversal-Paar ist ebenfalls eine Liste von Zertifikaten der Zertifizierungsstellen erforderlich. Expressway-E kommuniziert über SIP mit TLS mit der Webex-Cloud, das durch die gegenseitige Authentifizierung erzwungen wird. Expressway-E vertraut aus der Cloud stammenden und in die Cloud getätigten Anrufen nur, wenn der CN- oder SAN-Wert des während der TLS-Verbindungseinrichtung von der Cloud bereitgestellten Zertifikats mit dem Antragstellernamen übereinstimmt, der für die DNS-Zone in Expressway („callservice.webex.com“) konfiguriert ist. Die Zertifizierungsstelle veröffentlicht ein Zertifikat erst nach der Identitätsüberprüfung. Der Besitz der Domäne callservice.webex.com muss nachgewiesen werden, um ein signiertes Zertifikat zu erhalten. Da wir (Cisco) diese Domäne besitzen, ist der DNS-Name „callservice.webex.com“ der direkte Beweis dafür, dass es sich bei der Gegenstelle wirklich um Webex handelt.

Der Calendar Connector integriert Webex in Microsoft Exchange 2013, 2016, 2019 oder Office 365 über ein Impersonationskonto. Mithilfe der Anwendungsidentitätswechsel-Verwaltungsrolle in Exchange können Anwendungen die Identität von Benutzern in einer Organisation annehmen, um Vorgänge im Namen des Benutzers durchzuführen. Die Anwendungswechselrolle muss in Exchange konfiguriert werden und wird im Calendar Connector als Teil der Exchange-Konfiguration auf der Expressway-C-Oberfläche verwendet.

Das Exchange-Konto für Identitätswechsel ist die von Microsoft empfohlene Methode für diese Aufgabe. Expressway-C-Administratoren müssen das Passwort nicht kennen, da der Wert von einem Exchange-Administrator über die Expressway-C-Oberfläche eingegeben werden kann. Das Passwort wird nicht als Klartext dargestellt, selbst wenn der Expressway-C-Administrator über Stammzugriff auf das Expressway-C-Feld verfügt. Das Passwort wird verschlüsselt mit demselben Anmeldeinformationsverschlüsselungsmechanismus wie andere Passwörter auf der Expressway-C gespeichert.

Führen Sie die folgenden Schritte im Bereitstellungshandbuch für Cisco Webex Hybrid Calendar Service aus, um zusätzliche Sicherheit zu gewährleisten, um TLS zu aktivieren, damit EWS-Verbindungen auf der Leitung gesichert werden können.

Führen Sie für zusätzliche Sicherheit die Schritte in Bereitstellen Expressway Calendar Connector für Microsoft Exchange aus, um TLS zu aktivieren, um EWS-Verbindungen auf der Leitung zu sichern.