Über die Expressway-C- und Expressway-E-Bereitstellung sind Anrufe mithilfe der Firewall-Traversal-Technologien über das Internet möglich. Diese Bereitstellung übernimmt Ihre lokale Anrufsteuerung sicher und bindet sie ein Cisco WebEx.

Für Expressway-C und Expressway-E müssen aufgrund der Firewall-Traversal-Architektur 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 Firewall-Traversal-Architektur 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-Dienstadresse:

Priorität = 10

Gewichtung = 10

Port = 5062

SVR-Hostname = us-expe1.example.com

_sips._tcp.example.com SRV-Dienstadresse:

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.

Der DNS-Eintrag umfasst _sips._tcp, in dem Eintrag ist das SIP TLS angegeben.

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 Zertifikatü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 Zertifikatanforderungsmeldung an den Client sendet. Diese Meldung ist nützlich bei einer Server-zu-Server-Verbindung, wie z. B. bei einer Verbindung, die zwischen Expressway-E und der Cisco WebEx Cloud hergestellt wird. Dieses Konzept wird als TLS mit gegenseitiger Authentifizierung bezeichnet und ist bei der Integration mit Cisco 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 Cloudidentität. Wenn beispielsweise die Cloudidentitä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. Cisco WebEx Hybride Dienste verwenden bei SIP TLS den gleichen Eintrag wie für B2B. Im Fall von Port 5061 funktionieren einige Dienste nicht, die kein TLS-Client-Zertifikat bereitstellen können.

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

Business-to-Business-, Mobil- und Remote-Access-Anrufe verwenden Port 5061 für SIP TLS, während Cisco WebEx-Datenverkehr Port 5062 für SIP TLS mit gegenseitiger Authentifizierung verwendet.

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 Cisco WebEx Cloud implementiert ist, damit Sie nachweisen können, 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.

Ein Bericht zur Veranschaulichung der Relevanz der Domänenbesitz-Überprüfung

Das Cisco WebEx Cloud führt die Domänenbesitzprü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, dessen DNS-Domäne auf „hacker.com“ festgelegt ist, erwirbt Cisco WebEx hybride Dienste. Ein anderes Unternehmen, dessen eigene Domäne auf „example.com“ festgelegt ist, setzt ebenfalls Hybriddienste ein. 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 mit jane.roe@hacker.com bei Cisco Webex Teams 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 über ihre Cisco Webex Teams-App john.doe@example.com anwählt. John sitzt in seinem Büro und sieht auf seinem Videogerät einen eingehenden Anruf von jane.roe@example.com; hierbei handelt es sich um den mit dem E-Mail-Konto verknüpften 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, ein Verantwortungsbereich der Cisco WebEx Cloud besteht jedoch darin, sicherzustellen, dass die Identität des Anrufers aus Cisco WebEx korrekt ist und nicht gefälscht wurde.

Für die Identitätsüberprüfung muss das Unternehmen gegenüberCisco WebEx nachweisen, dass die in hybriden Anrufen verwendeten Domänen dem Unternehmen gehören. Wenn nicht, wird nicht funktionieren.

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, der Cisco WebEx Cloud führt eine TXT-Datensatzabfrage für diese Domäne durch.

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

   • Der Administrator muss beispielsweise nachweisen, dass er die Domäne „example.com“ besitzt, um Cisco WebEx hybride Dienste mit der Domäne verwenden zu können.

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

     

   • Der DNS-Administrator erstellt anschließend einen TXT-Datensatz für diese Domäne, dabei wird der Wert auf 123456789abcdef123456789abcdef123456789abcdef123456789abcdef festgelegt, siehe folgendes 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.

Der Expressway-C Connector-Host muss registriert sein Cisco WebEx damit hybride Dienstleistungen arbeiten.

Expressway-C wird im internen Netzwerk bereitgestellt und die Cloudregistrierung erfolgt durch eine ausgehende HTTPS-Verbindung – dieselbe Art von Verbindung wie zwischen Browsern und Webservern.

Registrierung und Kommunikation mit der von Cisco WebEx Cloud verwendeten TLS. Expressway-C ist der TLS-Client und die Cisco WebEx Cloud ist der TLS-Server. Deshalb überprüft Expressway-C 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 Expressway-C das von der Cloud bereitgestellte Zertifikat validieren muss, muss es den öffentlichen Schlüssel der Zertifizierungsstelle verwenden, die das Zertifikat zum Entschlüsseln der Signatur signiert hat. Im Zertifikat der Zertifizierungsstelle ist ein öffentlicher Schlüssel enthalten. Um eine Vertrauensstellung mit den von der Cloud eingesetzten Zertifizierungsstellen herzustellen, muss im Vertrauensspeicher von Expressway eine Liste der Zertifikate dieser vertrauenswürdigen Zertifizierungsstellen enthalten sein. Dabei kann Expressway verifizieren, dass der Anruf wirklich aus der Cisco WebEx Cloud stammt.

Beim manuellen Upload können Sie alle relevanten Zertifikate der Zertifizierungsstellen in den Vertrauensspeicher von Expressway-C hochladen.

Beim automatischen Upload lädt die Cloud diese Zertifikate in den Vertrauensspeicher von Expressway-C hoch. Wir empfehlen die Verwendung des automatischen Uploads. Die Zertifikatliste kann sich ändern und der automatische Upload stellt sicher, dass Sie die aktuellste Liste erhalten.

Wenn Sie die automatische Installation der Zertifizierungsstellenzertifikate zulassen, werden Sie zu https://admin.webex.com (dem Verwaltungsportal) weitergeleitet. Die Weiterleitung wird von Expressway-C ohne Benutzereingriff vorgenommen. Sie als Cisco WebEx-Administrator müssen sich über eine HTTPS-Verbindung authentifizieren. Kurz darauf leitet die Cloud die CA-Zertifikate per Push an Expressway-C.

Die HTTPS-Verbindung kann erst hergestellt werden, nachdem die Zertifikate in den Vertrauensspeicher von Expressway-C hochgeladen wurden.

Zur Vermeidung dieses Problems ist Expressway-C bereits mit von Cisco WebEx als vertrauenswürdig eingestuften CA-Zertifikaten vorinstalliert. Diese Zertifikate dienen nur für die Einrichtung und Validierung der ersten HTTPS-Verbindung und sie werden nicht in der Vertrauensliste von Expressway-C angezeigt. Nachdem die Zertifikate der vertrauenswürdigen Zertifizierungsstellen über die HTTPS-Verbindung abgerufen wurden, stehen diese Zertifikate zur plattformweiten Nutzung zur Verfügung; anschließend werden sie in der Vertrauensliste von Expressway-C angezeigt.

In dieser Liste sind die Zertifikate der Zertifizierungsstellen aufgeführt, die die Cisco WebEx Cloud aktuell verwendet. Diese Liste kann sich zukünftig ändern:

• 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

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 Cisco 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 durch die 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. Das Eigentum an der CallService.WebEx.com Domain muss nachgewiesen werden, um ein Zertifikat signiert zu bekommen. Da wir (Cisco) diese Domain besitzen, lautet der DNS-Name „CallService.WebEx.com“ und ist der direkte Beweis dafür, dass die Gegenstelle wirklich ist Cisco WebEx.

Calendar Connector integriert Cisco WebEx in Microsoft Exchange 2010, 2013, 2016 oder Office 365 über ein Konto für Identitätswechsel. 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 Anwendungsidentitätswechselrolle muss in Exchange konfiguriert werden und dient in Calendar Connector als Teil der Exchange-Konfiguration auf der Expressway-C -Oberfläche.

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 in der Expressway-C-Schnittstelle eingegeben werden kann. Das Passwort wird nicht komplett angezeigt, selbst wenn der Expressway-C -Administrator Stammzugriff auf das Feld Expressway-C hat. Das Passwort wird verschlüsselt mit dem gleichen Anmeldemechanismus wie andere Passwörter auf dem Expressway-C.

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.