Ta sekcja zawiera dodany kontekst dotyczący kluczowych elementów konfiguracji odnoszących się do usług hybrydowych.

Punkty te mają kluczowe znaczenie, jeśli chcesz pomyślnie wdrożyć połączenia hybrydowe dla urządzeń Webex. Wyróżniliśmy te elementy w szczególności z następujących powodów:

• Chcemy je wyjaśnić, abyś zrozumiał ich rolę we wdrożeniu hybrydowym i czuł się spokojny.

• Są to obowiązkowe warunki wstępne, które zapewniają bezpieczne wdrożenie między naszą chmurą a środowiskiem lokalnym.

• Powinny być traktowane jako działania zerowe przed dniem: ich ukończenie może potrwać nieco dłużej niż typowa konfiguracja w interfejsie użytkownika, więc pozwól sobie na ramy czasowe, aby posortować te elementy.

• Po tym, jak te elementy zostaną rozwiązane w Twoim środowisku, reszta konfiguracji usług hybrydowych przebiegnie płynnie.

Wdrożenie par Expressway-C i Expressway-E umożliwia połączenia z i z Internetu przy użyciu technologii trawersalnych zapory ogni owej. To wdrożenie bezpiecznie przejmuje kontrolę nad połączeniami lokalnymi i łączy ją z Webex.

Expressway-C i Expressway-E nie wymagają otwierania żadnego portu przychodzącego w zaporze strefy zdemilitaryzowanej (DMZ) ze względu na architekturę ruchu zapory ogniowej. Ale porty sygnalizacyjne TCP SIP i porty multimedialne UDP muszą być otwierane przychodząco w zaporze internetowej, aby umożliwić przychodzenie połączeń przychodzących. Musisz poświęcić czas na otwarcie odpowiedniego portu w zaporze korporacyjnej.

Architektura ruchu zapory jest pokazana na poniższym schemacie:

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

Port odsłuchu SIP na drodze Expressway można skonfigurować tak, aby miał dowolną wartość między 1024 a 65534. Jednocześnie ta wartość i typ protokołu muszą być reklamowane w DNS SRV rejestrach publicznych, a ta sama wartość musi zostać otwarta w zaporze internetowej.

Chociaż standardem dla SIP TCP jest 5060, a dla SIP TLS 5061, nic nie stoi na przeszkodzie, jak pokazuje poniższy przykład.

Przykład

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

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

_łyki. _tcp.example .com Lokalizacja usługi SRV:

priority = 10

weight = 10

port = 5062

nazwa hosta svr = us-expe1.example.com

_łyki. _tcp.example .com Lokalizacja usługi SRV:

priority = 10

weight = 10

port = 5062

nazwa hosta svr = us-expe2.example.com

Rekordy 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 odsłuchowego.

Urządzenie, które jest zewnętrzne od sieci (w Internecie) i które wykonuje połączenie SIP do użytkownika domeny korporacyjnej (user1@example.com), musi zapytać DNS, aby dowiedzieć się, jakiego typu transportu użyć, numer portu, sposób ładowania i udostępniania ruchu oraz do jakich serwerów SIP wysłać połączenie.

Jeśli wpis DNS zawiera _sips. _tcp, wpis określa protokół SIP TLS.

TLS jest protokołem klient-serwer i w najpopularniejszych implementacjach używa certyfikatów do uwierzytelniania. W scenariuszu połączeń między przedsiębiorstwami klient TLS jest urządzeniem wywołującym, a serwer TLS jest urządz eniem wywołującym. W TLS klient sprawdza certyfikat serwera, a jeśli sprawdzenie certyfik atu nie powiedzie się, rozłącza połączenie. Klient nie potrzebuje certyfikatu.

Uścisk dłoni TLS pokazano na poniższym schemacie:

Jednak specyfikacja TLS stwierdza, że serwer może również sprawdzić certyfikat klienta, wysyłając komunikat z żądaniem certyfikatu do klienta podczas protokołu TLS handshake. Ten komunikat jest pomocny w przypadku połączenia serwer-serwer, na przykład podczas połączenia, które jest ustanowione między Expressway-E a chmurą Webex. Ta koncepcja nazywa się TLS z wzajemnym uwierzytelnianiem i jest wymagana podczas integracji z Webex.

Zarówno strony dzwoniące, jak i wezwane sprawdz ają certyfikat drugiego partnera, jak pokazuje poniższy schemat:

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

Jeśli wzajemne uwierzytelnianie jest włączone, Expressway-E zawsze żąda certyfikatu klienta. W rezultacie urządzenia Mobile i Remote Access (MRA) nie będą działać, ponieważ w większości przypadków certyfikaty nie są wdrażane na klientach Jabber . W scenariuszu typu business-to-business, jeśli jednostka wywołująca nie jest w stanie dostarczyć certyfikatu, połączenie zostanie odłączone.

Zalecamy użycie wartości innej niż 5061 dla protokołu TLS z wzajemnym uwierzytelnianiem, takiej jak port 5062. Webex Hybrid Services korzysta z 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ą zapewnić certyfikatu klienta TLS, nie będą działać.

Jeśli istniejący rekord jest już używany do komunikacji między przedsiębiorstwami, zalecamy określenie subdomeny domeny korporacyjnej jako miejsca docelowego SIP w Control Hub, a co za tym idzie, DNS SRV rejestru publicz nego, w następujący sposób:

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

Ruch typu Business-to-Business, Mobile Remote Access i Webex na tej samej parze Expressway

Połączenia typu Business-to-Business (B2B) oraz połączenia mobilne i Remote Access (MRA) używają portu 5061 dla protokołu SIP TLS, a ruch Webex wykorzystuje port 5062 dla protokołu SIP TLS z wzajemnym uwier zytelnianiem.

Kontrola własności domeny jest częścią weryfikacji tożsamości. Weryfikacja domeny to środek bezpieczeństwa i sprawdzanie tożsamości, który chmura Webex implementuje, aby udowodnić, że jesteś tym, za kogo się podajesz.

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

1. Kontrola 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. Sprawdzenie własności nazwy DNS Expressway-E. Ten krok jest wykonywany poprzez implementację TLS z wzajemnym uwierzytelnianiem i obejmuje wykorzystanie 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 wykonywanego i odbieranego z chmury.

Znaczenie sprawdzania własności domeny

Chmura Webex przeprowadza kontrolę własności domeny w celu wymuszenia bezpieczeństwa. Kradzież tożsamości jest jednym z możliwych zagrożeń, jeśli ta kontrola nie zostanie wykonana.

Poniższa historia szczegółowo opisuje, co może się zdarzyć, jeśli kontrola własności domeny nie zostanie przeprowadzona.

Firma z domeną DNS ustawioną na „hacker.com” kupuje 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 katalog URI jane.roe@example.com.

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

Następnie zaloguje się do aplikacji Webex pod adresem jane.roe@hacker.com. Ponieważ jest właścicielem domeny, e-mail weryfikacyjny jest odczytywany i odpowiadany, i może się zalogować. Wreszcie dzwoni do kolegi Johna Doe, dzwoniąc pod adres john.doe@example.com ze swojej aplikacji Webex. John siedzi w swoim biurze i widzi połączenie na swoim urządzeniu wideo pochodzące z jane.roe@example.com; jest to identyfikator URI katalogu powiązany z tym kontem e-mail.

„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 fałszywymi połączeniami pochodzącymi z Internetu, ale jednym z obowiązków chmury Webex jest upewnienie się, że tożsamość każdego dzwoniącego z Webex jest poprawna i nie sfałszowana.

Aby sprawdzić tożsamość, Webex wymaga, aby firma udowodniła, że jest właścicielem domen używanych w Hybrid Calling. Jeśli tak się nie stanie, usługi hybrydowe nie będą działać.

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

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

   • Wszystkie te domeny muszą być routingowe i znane przez publiczne serwery DNS.

   • Aby udowodnić własność, administrator DNS musi wprowadzić rekord tekstu DNS (TXT). Rekord TXT to rodzaj rekordu zasobów w DNS używany do zapewnienia możliwości skojarzenia dowolnego i niesformatowanego tekstu z hostem lub inną nazwą.

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

   • Jeśli zapytanie TXT zakończy się powodzeniem, a wynik jest zgodny z tokenem wygenerowanym z chmury Webex, domena jest weryfikowana.

   • Na przykład administrator musi udowodnić, że jest właścicielem domeny „example.com”, jeśli chce, aby Webex Hybrid Services działało na jej domenie.

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

     

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

     

   • W tym momencie chmura może zweryfikować, czy rekord TXT dla domeny example.com pasuje do tokena.

   • Chmura wykonuje wyszukiwanie DNS TXT:

     

   • Ponieważ wartość TXT odpowiada wartości tokena, to dopasowanie dowodzi, że administrator dodał rekord TXT dla swojej własnej domeny do publicznego DNS i że jest właścicielem domeny.

2. Sprawdzenie własności nazwy DNS Expressway-E.

   • Chmura musi sprawdzić, czy Expressway-E posiada potwierdzoną tożsamość jednego z organów certyfikacji, którym ufa chmura. Administrator Expressway-E musi zażądać publicznego certyfikatu dla swojego Expressway-E do jednego z tych organów certyfikacji. Aby wydać certyfikat, organ certyfikacji przeprowadza proces weryfikacji tożsamości w oparciu o sprawdzenie walidacji domeny (dla certyfikatów zatwierdzonych w domenie) lub sprawdzanie walidacji organizacji (dla certyfikatów zatwierdzonych przez organizację).

   • Połączenia do i z chmury zależą od certyfikatu, który został wydany do Expressway-E. Jeśli certyfikat nie jest ważny, połączenie zostanie odrzucone.

Aby połączenie hybrydowe działało, złącze urządzenia Webex musi komunikować się z Webex.

Webex Device Connector jest wdrażany w sieci wewnętrznej, a sposób komunikacji z chmur ą 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.

Komunikacja z chmurą Webex wykorzystuje protokół TLS. Webex Device Connector to klient TLS, a chmura Webex to serwer TLS. W związku z tym Webex Device Connector sprawdza certyfikat serwera.

Organ certyfikacji podpisuje certyfikat serwera przy użyciu własnego klucza prywatnego. Każdy, kto posiada klucz publiczny, może zdekodować ten podpis i udowodnić, że ten sam organ certyfikacji podpisał ten certyfikat.

Jeśli Webex Device Connector musi zweryfikować certyfikat dostarczony przez chmurę, musi użyć klucza publicznego organu certyfik acji, który podpisał ten certyfikat, aby zdekodować podpis. K lucz publiczny znajduje się w certyfikacie organu certyfikującego. Aby ustanowić zaufanie do organów certyfikacji używanych przez chmurę, lista certyfikatów tych zaufanych organów certyfikacji musi znajdować się w magazynie zaufania Webex Device Connector.

Podczas komunikacji z urządzeniami narzędzie korzysta z zaufanych certyfikatów, które udostępniasz. Obecnie sposobem na to jest umieszczenie ich w [home folder]/.devicestool/certs.

Lista certyfikatów urzędu certyfikacji jest również wymagana dla Expressway-E w parze obro towej. Expressway-E komunikuje się z chmurą Webex za pomocą SIP z TLS, wymuszonego przez wzajemne uwierzytelnianie. Expressway-E ufa połącz eniom pochodzącym z chmury i przechodzącym do chmury tylko wtedy, gdy CN lub SAN certyfikatu prezentowanego przez chmurę podczas konfiguracji połączenia TLS odpowiada nazwie tematu skonfigurowanej dla strefy DNS na Expressway („callservice.webex.com”). Organ certyfikacyjny wydaje certyfikat dopiero po sprawdzeniu tożsamości. Aby uzyskać podpisanie certyfikatu, należy udowodnić własność domeny callservice.webex.com. Ponieważ my (Cisco) posiadamy tę domenę, nazwa DNS „callservice.webex.com” jest bezpośrednim dowodem na to, że zdalny peer to naprawdę Webex.

Złącze kalendarza integruje Webex z Microsoft Exchange 2013, 2016, 2019 lub Office 365 za pośrednictwem konta podszywania się pod siebie. Rola zarządzania podszywaniem się pod aplikacje w programie Exchange umożliwia aplikacjom podszywanie się pod użytkowników w organizacji w celu wykonywania zadań w imieniu użytkownika. Rola podszywania się pod aplikację musi być skonfigurowana w programie Exchange i jest używana w złączu kalendarza jako część konfiguracji programu Exchange w interfejsie Expressway-C.

Konto podszywania się w Exchange jest zalecaną przez firmę Microsoft metodą tego zadania. Administratorzy Expressway-C nie muszą znać hasła, ponieważ wartość ta może zostać wprowadzona w interfejsie Expressway-C przez administratora Exchange. Hasło nie jest wyraźnie pokazane, nawet jeśli administrator Expressway-C ma dostęp root do pola Expressway-C. Hasło jest przechowywane zaszyfrowane przy użyciu tego samego mechanizmu szyfrowania poświadczeń, co inne hasła w Expressway-C.

Aby uzyskać dodatkowe zabezpieczenia, wykonaj czynności opisane w Przewodniku wdrażania usługi kalendarza Cisco Webex hybry dowego, aby włączyć protokół TLS w celu zabezpieczenia połączeń EWS na przewodzie.

Aby uzyskać dodatkowe zabezpieczenia, wykonaj czynności opisane w sekcji Wdrażaj złącze kalendarza drogi ek spresowej, Microsoft Exchange aby włączyć protokół TLS w celu zabezpieczenia połączeń EWS na przewodzie.