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

Diese Punkte sind entscheidend für die erfolgreiche Implementierung von Hybrid Calling für Webex-Geräte. 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 Bereitstellungdes Expressway-C- und Expressway-E - Paares ermöglicht Anrufe ins und aus dem Internet unter Verwendung von Firewall -Traversal- Technologien. Diese Bereitstellung verbindet Ihre lokale Anrufsteuerung sicher mit Webex.

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-Servicestandort:

Priorität = 10

Gewichtung = 10

Port = 5062

SVR-Hostname = us-expe1.example.com

_sips._tcp.example.com SRV-Servicestandort:

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._tcpenthä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 Meldung ist hilfreich bei einer Server-zu-Server-Verbindung, wie beispielsweise bei einem Anruf zwischen Expressway-E und der Webex-Cloud. Dieses Konzept heißt TLS mit gegenseitiger Authentifizierung und ist für die 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 Hybrid Services verwenden denselben SIP-TLS-Datensatz wie für B2B-Unternehmen. Im Fall von Port 5061 funktionieren einige Dienste nicht, die kein TLS-Client-Zertifikat bereitstellen können.

Wenn bereits ein Eintrag für die Kommunikation zwischen Unternehmen verwendet wird, empfehlen wir, in Control Hub eine Subdomain der Unternehmensdomain als SIP-Ziel anzugeben und folglich einen öffentlichen DNS-SRV-Eintrag wie folgt zu erstellen:

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

Business-to-Business-, Mobil- und Fernzugriffs- sowie Webex-Datenverkehr auf demselben Autobahnpaar

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

Die Domänenbesitz-Überprüfung ist Teil der Identitätsverifizierung. Die Domainverifizierung ist eine Sicherheitsmaßnahme und Identitätsprüfung, die die Webex-Cloud implementiert, um zu beweisen, dass Sie die Person sind, für die 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 Überprüfung des Domaininhabers

Die Webex-Cloud führt eine Überprüfung der Domaininhaberschaft durch, um die Sicherheit zu gewährleisten. 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 mit der DNS-Domain "hacker.com" kauft Webex Hybrid Services. 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.

Als Nächstes meldet sie sich bei der Webex-App an mit jane.roe@hacker.com. Da sie die Domäne besitzt, wird die Verifizierungs-E-Mail gelesen und beantwortet und sie kann sich anmelden. Schließlich ruft sie einen Kollegen, John Doe, an, indem sie die Nummer wählt. john.doe@example.com über ihre Webex-App. 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 verfügt über viele Möglichkeiten, sich vor betrügerischen Anrufen aus dem Internet zu schützen. Eine der Aufgaben der Webex-Cloud besteht jedoch darin, sicherzustellen, dass die Identität derjenigen, die über Webex anrufen, korrekt und nicht verfälscht ist.

Zur Überprüfung der Identität verlangt Webex einen Nachweis des Unternehmens, dass es die im Rahmen von Hybrid Calling verwendeten Domains besitzt. Wenn das nicht der Fall ist, funktionieren Hybriddienste 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. Im Anschluss daran führt die Webex-Cloud eine TXT-Record-Abfrage für diese Domain durch.

   • Wenn die TXT-Abfrage erfolgreich ist und das Ergebnis mit dem Token übereinstimmt, das von der Webex-Cloud generiert wurde, wird die Domain verifiziert.

   • Beispielsweise muss die Administratorin nachweisen, dass sie die Domain "example.com" besitzt, wenn sie möchte, dass Webex Hybrid Services auf ihrer Domain funktionieren.

   • Über https://admin.webex.comstartet sie den Verifizierungsprozess, indem sie einen TXT-Eintrag erstellt, der dem Token entspricht, das die Webex-Cloud generiert hat:

     

   • Der DNS-Administrator erstellt dann einen TXT-Eintrag für diese Domain mit dem Wert 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, 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.

Damit Hybrid Calling funktioniert, muss der Webex Device Connector mit Webex kommunizieren.

Der Webex Device Connector wird im internen Netzwerk eingesetzt und kommuniziert mit der Cloud über eine ausgehende HTTPS-Verbindung – denselben Verbindungstyp, der auch für Browser verwendet wird, die eine Verbindung zu einem Webserver herstellen.

Die Kommunikation mit der Webex-Cloud erfolgt über TLS. Der Webex Device Connector fungiert als TLS-Client, die Webex-Cloud als 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 der Webex Device Connector das von der Cloud bereitgestellte Zertifikat validieren muss, muss er den öffentlichen Schlüssel der Zertifizierungsstelle verwenden, die dieses Zertifikat signiert hat, um die Signatur zu entschlüsseln. Im Zertifikat der Zertifizierungsstelle ist ein öffentlicher Schlüssel enthalten. Um Vertrauen zu den von der Cloud verwendeten Zertifizierungsstellen herzustellen, muss die Liste der Zertifikate dieser vertrauenswürdigen Zertifizierungsstellen im Truststore des Webex Device Connectors vorhanden sein.

Bei der Kommunikation mit Geräten verwendet das Tool vertrauenswürdige Zertifikate, die Sie bereitstellen. Aktuell geschieht dies, indem man sie in [home folder]/.devicestool/certssetzt.

Für Expressway-E im Traversal-Paar ist ebenfalls eine Liste von Zertifikaten der Zertifizierungsstellen erforderlich. Expressway-E kommuniziert mit der Webex-Cloud über SIP mit TLS, wobei eine gegenseitige Authentifizierung gewährleistet ist. Expressway-E vertraut Anrufen, die von und zur Cloud gehen, nur dann, wenn der CN oder SAN des von der Cloud während des TLS-Verbindungsaufbaus vorgelegten Zertifikats mit dem für die DNS-Zone auf Expressway konfigurierten Subjektnamen übereinstimmt ("callservice.webex.com"). Die Zertifizierungsstelle veröffentlicht ein Zertifikat erst nach der Identitätsüberprüfung. Um ein Zertifikat signieren zu lassen, muss der Besitz der Domain callservice.webex.com nachgewiesen werden. Da wir (Cisco) Eigentümer dieser Domain sind, ist der DNS-Name "callservice.webex.com" ein direkter Beweis dafür, dass der Remote-Peer tatsächlich Webex ist.

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-Identitätswechselkonto 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.