W tej sekcji przedstawiono dodatkowy kontekst dotyczący kluczowych elementów konfiguracji związanych z usługami hybrydowymi.

Te punkty są kluczowe, jeśli chcesz pomyślnie wdrożyć funkcję połączeń hybrydowych 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 poczuł się pewnie.

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

• Należy je traktować jako działania przed dniem zerowym: ich ukończenie może potrwać nieco dłużej niż typowa konfiguracja w interfejsie użytkownika, więc poświęć czas na posortowanie tych elementów.

• Po uwzględnieniu tych kwestii w środowisku reszta konfiguracji usług hybrydowych przebiegnie bezproblemowo.

Wdrożenie pary Expressway-C i Expressway-E umożliwia wykonywanie połączeń do i z Internetu przy użyciu technologii omijania zapór sieciowych. To wdrożenie umożliwia bezpieczne przejęcie kontroli nad połączeniami lokalnymi i połączenie jej z platformą 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. Komunikat ten jest przydatny w przypadku połączenia serwer-serwer, np. podczas rozmowy telefonicznej między Expressway-E a chmurą Webex. Koncepcja ta nazywa się TLS z uwierzytelnianiem wzajemnym i jest wymagana w przypadku integracji z 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 hybrydowe Webex korzystają z tego samego rekordu SIP TLS, co usługi B2B. W przypadku portu 5061 niektóre inne usługi, które nie mogą dostarczyć certyfikatu klienta TLS, nie będą działać.

Jeśli istniejący rekord jest już używany do komunikacji między firmami, zalecamy określenie poddomeny domeny firmowej jako miejsca docelowego SIP w Control Hub, a co za tym idzie, publicznego rekordu DNS SRV 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 Business-to-Business, mobilny i zdalny oraz ruch Webex na tej samej parze Expressway

Połączenia typu Business-to-Business (B2B) oraz Mobile and Remote Access (MRA) korzystają z portu 5061 w przypadku protokołu SIP TLS, a ruch Webex korzysta z portu 5062 w przypadku protokołu SIP TLS z uwierzytelnianiem wzajemnym.

Sprawdzanie własności domeny jest częścią weryfikacji tożsamości. Weryfikacja domeny to środek bezpieczeństwa i kontrola tożsamości wdrażana przez chmurę Webex, która ma na celu potwierdzenie, ż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.

Znaczenie sprawdzenia własności domeny

Chmura Webex sprawdza własność domeny w celu zapewnienia bezpieczeństwa. 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, której domena DNS jest ustawiona 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 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 aplikacji Webex 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 numer john.doe@example.com z jej aplikacji Webex. John siedzi w swoim biurze i widzi na swoim urządzeniu wideo połączenie od jane.roe@example.com; jest to 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 stosuje wiele sposobów ochrony przed oszukańczymi połączeniami pochodzącymi z Internetu, ale jednym z obowiązków chmury Webex jest upewnienie się, że tożsamość każdej osoby dzwoniącej z Webex jest poprawna i nie jest sfałszowana.

Aby sprawdzić tożsamość, Webex wymaga od firmy udowodnienia, że jest właścicielem domen używanych w połączeniach hybrydowych. W przeciwnym razie usługi hybrydowe nie będą dział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. Następnie chmura Webex wykonuje zapytanie o rekord TXT dla danej domeny.

   • Jeśli zapytanie TXT zakończy się powodzeniem i wynik będzie zgodny z tokenem wygenerowanym w chmurze Webex, domena zostanie zweryfikowana.

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

   • Za pomocą https://admin.webex.comrozpoczyna proces weryfikacji, tworząc rekord TXT odpowiadający tokenowi wygenerowanemu przez chmurę 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.

Aby funkcja połączeń hybrydowych działała, łącznik urządzeń Webex musi komunikować się z Webex.

Rozwiązanie Webex Device Connector jest wdrażane w sieci wewnętrznej, a komunikacja z chmurą odbywa się za pośrednictwem połączenia wychodzącego HTTPS — tego samego typu, którego używa każda przeglądarka łącząca się z serwerem internetowym.

Komunikacja z chmurą Webex odbywa się przy użyciu protokołu TLS. Webex Device Connector jest klientem TLS, a chmura Webex jest serwerem TLS. W związku z tym Webex Device Connector 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.

Aby narzędzie Webex Device Connector mogło zweryfikować certyfikat dostarczony przez chmurę, musi użyć klucza publicznego urzędu certyfikacji, który podpisał ten certyfikat, w celu zdekodowania podpisu. Klucz publiczny jest zawarty w certyfikacie urzędu certyfikacji. Aby nawiązać zaufanie z urzędami certyfikacji używanymi przez chmurę, lista certyfikatów tych zaufanych urzędów certyfikacji musi znajdować się w magazynie zaufanych certyfikatów Webex Device Connector.

Do komunikacji z urządzeniami narzędzie wykorzystuje zaufane certyfikaty dostarczone przez Ciebie. Obecnie można to zrobić umieszczając je w [home folder]/.devicestool/certs.

Lista certyfikatów urzędu certyfikacji jest również wymagana dla drogi ekspresowej E w parze trawersów. Expressway-E komunikuje się z chmurą Webex za pomocą protokołu SIP z TLS, wymuszanego przez wzajemne uwierzytelnianie. Expressway-E ufa połączeniom przychodzącym i wychodzącym z chmury tylko wtedy, gdy nazwa CN lub SAN certyfikatu przedstawionego przez chmurę podczas konfiguracji połączenia TLS pasuje do nazwy podmiotu skonfigurowanej dla strefy DNS w Expressway („callservice.webex.com”). Urząd certyfikacji wydaje certyfikat dopiero po sprawdzeniu tożsamości. Aby uzyskać podpis certyfikatu, należy udowodnić własność domeny callservice.webex.com. Ponieważ my (Cisco) jesteśmy właścicielami tej domeny, nazwa DNS „callservice.webex.com” jest bezpośrednim dowodem na to, że zdalnym partnerem jest naprawdę Webex.

łącznik kalendarza integruje Webex z Microsoft Exchange 2013, 2016, 2019 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.

Zalecaną przez firmę Microsoft metodą wykonania tego zadania jest użycie konta personifikującego Exchange. 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 ekspresowej C.

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.

Aby uzyskać dodatkowe zabezpieczenia, wykonaj kroki opisane w temacie Wdrażanie łącznika kalendarza expressway dla programu Microsoft Exchange , aby włączyć protokół TLS w celu zabezpieczenia połączeń EWS na przewodzie.