Wdrożenie pary Expressway-C i Expressway-E umożliwia połączenia do i z Internetu przy użyciu technologii przechodzenia przez zaporęogniową. To wdrożenie jest tym, co bezpiecznie przejmuje lokalną kontrolę połączeń i łączy ją z Cisco Webex.

Drogi ekspresowe C i drogi ekspresowe E nie wymagają otwierania żadnego portu przychodzącego w zaporze strefy zdemilitaryzowanej (DMZ) ze względu na architekturę przechodzenia zapory. Ale porty sygnalizacyjne TCP SIP i porty multimediów UDP muszą być otwarte przychodzące na zaporze internetowej, aby umożliwić połączenia przychodzące. Należy dać czas na otwarcie odpowiedniego portu na zaporze przedsiębiorstwa.

Architekturę przechodzenia zapory pokazano na poniższym diagramie:

Na przykład w przypadku przychodzących połączeń między firmami (B2B) przy użyciu protokołu SIP porty TCP 5060 i 5061 (5061 jest używany do SIP TLS) muszą być otwarte na zewnętrznej zaporze wraz z portami multimedialnymi UDP używanymi do usług takich jak głos, wideo, udostępnianie zawartości, podwójne wideo i tak dalej. To, które porty multimediów mają być otwarte, zależy od liczby jednoczesnych wywołań i liczby usług.

Port nasłuchiwania SIP na expressway można skonfigurować tak, aby był dowolną wartością z okresu od 1024 do 65534. Jednocześnie ta wartość i typ protokołu muszą być anonsowane w publicznych rekordach DNS SRV, a ta sama wartość musi być otwarta na zaporze internetowej.

Chociaż standardem dla SIP TCP jest 5060 i dla SIP TLS 5061, nic nie stoi na przeszkodzie, aby korzystać z różnych portów, jak pokazuje poniższy przykład.

Przykład

W tym przykładzie zakładamy, że port 5062 jest używany do przychodzących wywołań SIP TLS.

Rekord DNS SRV dla klastra dwóch serwerów Expressway wygląda następująco:

_sips._tcp. example.com lokalizacja usługi SRV:

priorytet = 10

waga = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp. example.com lokalizacja usługi SRV:

priorytet = 10

waga = 10

port = 5062

svr hostname = us-expe2.example.com

Zapisy te oznaczają, że połączenia są kierowane do us-expe1.example.com i us-expe2.example.com z równym podziałem obciążenia (priorytet i waga) przy użyciu TLS jako typu transportu i 5062 jako numeru portu nasłuchowego.

Urządzenie, które jest zewnętrzne w stosunku do sieci (w Internecie) i które wykonuje wywołanie SIP do użytkownika domeny firmowej (user1@example.com), musi wysłać zapytanie do dns, aby zrozumieć, jakiego typu transportu użyć, numeru portu, sposobu ładowania i współdzielenia ruchu oraz do których serwerów SIP należy wysłać połączenie.

Jeśli wpis DNS zawiera _sips. , wpis określa_tcpSIP TLS.

TLS jest protokołem klient-serwer i w najczęstszych implementacjach używa certyfikatów do uwierzytelniania. W scenariuszu połączenia między firmami klient TLS jest urządzeniem wywołującym, a serwer TLS jest urządzeniem wywoływanym. W przypadku protokołu TLS klient sprawdza certyfikat serwera, a jeśli sprawdzenie certyfikatu nie powiedzie się, rozłącza wywołanie. Klient nie potrzebuje certyfikatu.

Uzgadnianie TLS pokazano na poniższym diagramie:

Jednak specyfikacja TLS stanowi, że serwer może również sprawdzić certyfikat klienta, wysyłając komunikat Żądanie certyfikatu do klienta podczas protokołu uzgadniania TLS. Ten komunikat jest przydatny w połączeniu serwer-serwer, takim jak połączenie podczas połączenia, które jest ustanawiane między Expressway-E a chmurą Cisco Webex. Ta koncepcja nazywa się TLS z wzajemnym uwierzytelnianiem i jest wymagana podczas integracji z Cisco Webex.

Zarówno strony wywołujące, jak i wywoływane sprawdzają certyfikat drugiego elementu równorzędnego, jak pokazano na poniższym diagramie:

Chmura sprawdza tożsamość drogi ekspresowej, a droga ekspresowa sprawdza tożsamość chmury. Na przykład, jeśli tożsamość chmury w certyfikacie (CN lub SAN) nie jest zgodna z tym, co jest skonfigurowane na Expressway, połączenie zostanie przerwane.

Jeśli uwierzytelnianie wzajemne jest włączone, Expressway-E zawsze żąda certyfikatu klienta. W rezultacie dostęp mobilny i zdalny (MRA) nie będzie działać, ponieważ w większości przypadków certyfikaty nie są wdrażane na klientach Jabber. W scenariuszu między firmami, jeśli jednostka wywołująca nie jest w stanie dostarczyć certyfikatu, połączenie jest rozłączane.

Zaleca się użycie wartości innej niż 5061 dla protokołu TLS z wzajemnym uwierzytelnianiem, takiej jak port 5062. Usługi Cisco Webex Hybrid Services używają tego samego rekordu SIP TLS, który jest używany w B2B. W przypadku portu 5061 niektóre inne usługi, które nie mogą dostarczyć certyfikatu klienta TLS, nie będą działać.

Komunikacja biznesowa, mobilny i zdalny dostęp oraz ruch Cisco Webex na tej samej parze dróg ekspresowych

Połączenia business-to-business oraz połączenia z dostępem mobilnym i zdalnym używają portu 5061 dla SIP TLS, a ruch Cisco Webex używa portu 5062 dla SIP TLS z wzajemnym uwierzytelnianiem.

Sprawdzanie własności domeny jest częścią weryfikacji tożsamości. Weryfikacja domeny to środek bezpieczeństwa i kontrola tożsamości, które wdraża chmura Cisco Webex, aby udowodnić, że jesteś tym, za kogo się podajesz.

Kontrola tożsamości odbywa się w dwóch etapach:

1. Sprawdzanie własności domeny. Ten krok obejmuje trzy typy domen i jest jednorazową weryfikacją:

   • Domena e-mail

   • Domena DNS Expressway-E

   • Domena URI katalogu

2. Kontrola własności nazw DNS Expressway-E. Ten krok jest wykonywany poprzez implementację TLS z wzajemnym uwierzytelnianiem i obejmuje użycie publicznych certyfikatów zarówno w chmurze, jak i na drodze ekspresowej. W przeciwieństwie do sprawdzania tożsamości domeny, ten krok jest wykonywany podczas każdego połączenia wykonanego i odebranego z chmury.

Historia pokazująca znaczenie kontroli własności domeny

Chmura Cisco Webex sprawdza własność domeny w celu wymuszenia zabezpieczeń. Kradzież tożsamości jest jednym z możliwych zagrożeń, jeśli ta kontrola nie zostanie przeprowadzona.

W poniższej historii szczegółowo opisuje, co może się stać, jeśli kontrola własności domeny nie zostanie przeprowadzona.

Firma z domeną DNS ustawioną na "hacker.com" kupuje usługi Cisco Webex Hybrid Services. Inna firma, z własną domeną ustawioną na "example.com", również korzysta z usług hybrydowych. Jeden z dyrektorów generalnych firmy Example.com nazywa się Jane Roe i ma jane.roe@example.com identyfikator URI katalogu.

Administrator firmy Hacker.com ustawia jeden ze swoich identyfikatorów URI katalogu na jane.roe@example.com, a adres e-mail na jane.roe@hacker.com. Może to zrobić, ponieważ chmura nie sprawdza domeny SIP URI w tym przykładzie.

Następnie loguje się do Cisco Webex Teams za pomocą jane.roe@hacker.com. Ponieważ jest właścicielem domeny, wiadomość e-mail weryfikacyjna jest odczytywana i odbierana, a ona może się zalogować. Na koniec dzwoni do kolegi, Johna Doe, wybierając john.doe@example.com z aplikacji Cisco Webex Teams. John siedzi w swoim biurze i widzi połączenie na swoim urządzeniu wideo pochodzące z jane.roe@example.com; to jest identyfikator URI katalogu powiązany z tym kontem e-mail.

"Ona jest za granicą", myśli. "Może potrzebować czegoś ważnego." Odbiera telefon, a fałszywa Jane Roe prosi o ważne dokumenty. Wyjaśnia, że jej urządzenie jest zepsute, a ponieważ podróżuje, prosi go o przesłanie dokumentów na jej prywatny adres e-mail, jane.roe@hacker.com. W ten sposób firma zdaje sobie sprawę dopiero po powrocie Jane Roe do biura, że ważne informacje wyciekły poza firmę.

Firma Example.com ma wiele sposobów ochrony przed nieuczciwymi połączeniami pochodzącymi z Internetu, ale jednym z obowiązków chmury Cisco Webex jest upewnienie się, że tożsamość każdej osoby dzwoniącej z Cisco Webex jest poprawna i nie jest sfałszowana.

Aby sprawdzić tożsamość, Cisco Webex wymaga, aby firma udowodniła, że jest właścicielem domen używanych w połączeniach hybrydowych. Jeśli nie, nie zadziała.

Aby zapewnić tę własność, wymagane są dwa kroki weryfikacji domeny:

1. Udowodnij, że firma jest właścicielem domeny e-mail, domeny Expressway-E, domeny URI katalogu.

   • Wszystkie te domeny muszą być rutowalne i znane publicznym serwerom DNS.

   • Aby udowodnić własność, administrator DNS musi wprowadzić rekord tekstowy DNS (TXT). Rekord TXT to typ rekordu zasobu w systemie DNS używany do kojarzenia dowolnego i niesformatowanego tekstu z hostem lub inną nazwą.

   • Administrator DNS musi wprowadzić ten rekord TXT w strefie, której własność musi zostać potwierdzona. Po wykonaniu tego kroku chmura Cisco Webex wykonuje zapytanie o rekord TXT dla tej domeny.

   • Jeśli zapytanie TXT zakończy się pomyślnie, a wynik będzie zgodny z tokenem wygenerowanym z chmury Cisco Webex, domena zostanie zweryfikowana.

   • Na przykład administrator musi udowodnić, że jest właścicielem domeny "example.com", jeśli chce, aby usługi Cisco Webex Hybrid Services działały w jej domenie.

   • Za pośrednictwem https://admin.webex.com, rozpoczyna proces weryfikacji, tworząc rekord TXT pasujący do tokenu wygenerowanego przez chmurę Cisco Webex:

     

   • Następnie administrator DNS tworzy rekord TXT dla tej domeny z wartością ustawioną na 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, jak w poniższym przykładzie:

     

   • W tym momencie chmura może sprawdzić, czy rekord TXT dla domeny example.com jest zgodny z tokenem.

   • Chmura wykonuje wyszukiwanie DNS TXT:

     

   • Ponieważ wartość TXT jest zgodna z wartością tokenu, to dopasowanie dowodzi, że administrator dodał rekord TXT dla własnej domeny do publicznego systemu DNS i że jest właścicielem domeny.

2. Kontrola własności nazw DNS Expressway-E.

   • Chmura musi sprawdzić, czy droga ekspresowa E ma potwierdzoną tożsamość jednego z urzędów certyfikacji, którym ufa chmura. Administrator drogi ekspresowej E musi zwrócić się o publiczny certyfikat dla swojej drogi ekspresowej E do jednego z tych urzędów certyfikacji. Aby wystawić certyfikat, urząd certyfikacji przeprowadza proces weryfikacji tożsamości na podstawie sprawdzenia poprawności domeny (w przypadku certyfikatów zweryfikowanych przez domenę) lub sprawdzenia poprawności organizacji (w przypadku certyfikatów zweryfikowanych przez organizację).

   • Połączenia do i z chmury zależą od certyfikatu wydanego dla Expressway-E. Jeśli certyfikat jest nieprawidłowy, połączenie zostanie przerwane.

Host łącznika Expressway-C musi być zarejestrowany w Cisco Webex, aby usługi hybrydowe działały.

Expressway-C jest wdrażany w sieci wewnętrznej, a sposób, w jaki rejestruje się w chmurze, odbywa się za pośrednictwem wychodzącego połączenia HTTPS - tego samego typu, który jest używany w każdej przeglądarce łączącej się z serwerem WWW.

Rejestracja i komunikacja z chmurą Cisco Webex odbywa się przy użyciu protokołu TLS. Expressway-C jest klientem TLS, a chmura Cisco Webex jest serwerem TLS. W związku z tym Expressway-C sprawdza certyfikat serwera.

Urząd certyfikacji podpisuje certyfikat serwera przy użyciu własnego klucza prywatnego. Każda osoba posiadająca klucz publiczny może odkodować ten podpis i udowodnić, że ten sam urząd certyfikacji podpisał ten certyfikat.

Jeśli Expressway-C musi zweryfikować certyfikat dostarczony przez chmurę, musi użyć klucza publicznego urzędu certyfikacji, który podpisał ten certyfikat, aby odkodować podpis. Klucz publiczny jest zawarty w certyfikacie urzędu certyfikacji. Aby ustanowić zaufanie z urzędami certyfikacji używanymi przez chmurę, lista certyfikatów tych zaufanych urzędów certyfikacji musi znajdować się w magazynie zaufania drogi ekspresowej. W ten sposób droga ekspresowa może sprawdzić, czy połączenie rzeczywiście pochodzi z chmury Cisco Webex.

Ręczne przekazywanie umożliwia przekazywanie wszystkich odpowiednich certyfikatów urzędu certyfikacji do magazynu zaufania Expressway-C.

Dzięki automatycznemu przesyłaniu chmura sama przesyła te certyfikaty do magazynu zaufania Expressway-C. Zalecamy korzystanie z automatycznego przesyłania. Lista certyfikatów może ulec zmianie, a automatyczne przekazywanie gwarantuje, że otrzymasz najbardziej zaktualizowaną listę.

Jeśli zezwolisz na automatyczną instalację certyfikatów urzędu certyfikacji, nastąpi przekierowanie do https://admin.webex.com (portalu zarządzania). Przekierowanie odbywa się przez samą drogę ekspresową C bez interwencji użytkownika. Ty, jako administrator Cisco Webex, musisz uwierzytelnić się za pośrednictwem połączenia HTTPS. Wkrótce potem chmura wypycha certyfikaty CA na drogę ekspresową C.

Dopóki certyfikaty nie zostaną przekazane do magazynu zaufania Expressway-C, nie można ustanowić połączenia HTTPS.

Aby uniknąć tego problemu, Expressway-C jest preinstalowany z certyfikatami Cisco Webex-trusted CA. Te certyfikaty są używane tylko do konfigurowania i sprawdzania poprawności początkowego połączenia HTTPS i nie pojawiają się na liście zaufania Expressway-C. Po usunięciu certyfikatów zaufanych urzędów certyfikacji z chmury za pośrednictwem tego początkowego połączenia HTTPS certyfikaty te są dostępne do użytku na całej platformie; następnie pojawiają się na liście zaufania Expressway-C.

Ta lista zawiera certyfikaty urzędu certyfikacji, których obecnie używa chmura Cisco Webex. Ta lista może ulec zmianie w przyszłości:

• 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. — tylko do autoryzowanego użytku, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

Lista certyfikatów urzędu certyfikacji jest również wymagana dla drogi ekspresowej E w parze trawersów. Expressway-E komunikuje się z chmurą Cisco Webex za pomocą SIP z TLS, wymuszonym przez wzajemne uwierzytelnianie. Expressway-E ufa połączeniom przychodzącym z chmury i przechodzącym do chmury tylko wtedy, gdy CN lub SAN certyfikatu przedstawionego przez chmurę podczas konfiguracji połączenia TLS jest zgodna z nazwą podmiotu skonfigurowaną dla strefy DNS na Expressway ("callservice.ciscospark.com"). Urząd certyfikacji wydaje certyfikat dopiero po sprawdzeniu tożsamości. Własność domeny callservice.ciscospark.com musi zostać udowodniona, aby uzyskać certyfikat podpisany. Ponieważ my (Cisco) jesteśmy właścicielami tej domeny, nazwa DNS "callservice.ciscospark.com " jest bezpośrednimdowodem na to, że zdalny element równorzędny to naprawdę Cisco Webex.

Calendar Connector integruje Cisco Webex z Microsoft Exchange 2010, 2013, 2016 lub Office 365 za pośrednictwem konta personifikacji. Rola zarządzania personifikacją aplikacji w programie Exchange umożliwia aplikacjom personifikowanie użytkowników w organizacji w celu wykonywania zadań w imieniu użytkownika. Rola personifikacji aplikacji musi być skonfigurowana w programie Exchange i jest używana w łączniku kalendarza jako część konfiguracji programu Exchange w interfejsie Expressway-C.

Konto personifikacji programu Exchange jest zalecaną przez firmę Microsoft metodą dla tegozadania. Administratorzy Expressway-C nie muszą znać hasła, ponieważ wartość może być wprowadzona w interfejsie Expressway-C przez administratora programu Exchange. Hasło nie jest wyraźnie pokazane, nawet jeśli administrator Expressway-C ma uprawnienia administratora do skrzynki Expressway-C. Hasło jest przechowywane w postaci zaszyfrowanej przy użyciu tego samego mechanizmu szyfrowania poświadczeń, co inne hasła na drodze ekspresowejC.

Aby uzyskać dodatkowe zabezpieczenia, wykonaj kroki opisane w Przewodniku wdrażania usługi Cisco Webex Hybrid Calendar Service, aby włączyć protokół TLS w celu zabezpieczenia połączeń EWS na przewodzie.