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

Punkty te mają kluczowe znaczenie dla pomyślnego wdrożenia usługi Hybrid Calling 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 zaadresowaniu tych elementów w środowisku pozostała część konfiguracji usług hybrydowych będzie płynnie działać.

Wdrożenie pary Expressway-C i Expressway-E umożliwia wykonywanie połączeń do i z Internetu przy użyciu technologii przesyłania przez zaporę sieciową. To wdrożenie bezpiecznie przenosi kontrolę połączeń w siedzibie i łączy ją z usługą 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 przypadku połączenia między serwerem, na przykład połączenia nawiązanego między usługą Expressway-E a chmurą Webex. Ta koncepcja nosi nazwę TLS z wzajemnym uwierzytelnianiem i jest wymagana podczas 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 używają tego samego rekordu SIP TLS, który jest używany w przypadku 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 docelowego adresu SIP w Control Hub, a w konsekwencji publicznego rekordu SRV DNS w następujący sposób:

 Usługa i protokół: _sips._tcp.mtls.example.com Priorytet: 1 waga: 10 Numer portu: 5062 Cel: us-expe1.przykład.com 

Dostęp między użytkownikami, dostęp mobilny i dostęp zdalny i ruch Webex na tej samej parze Expressway

Połączenia między firmami (B2B) oraz dostęp mobilny i zdalny (MRA) używają portu 5061 dla SIP TLS, a ruch Webex używają 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 wdrażana w chmurze Webex w celu udowodnienia, że jesteś tym, kim mówisz.

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 kontroli własności domeny

Chmura Webex przeprowadza kontrolę własności domeny w celu wymuszania 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 hybrydowe Webex. 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ą adresu jane.roe@hacker.com. Ponieważ jest właścicielem domeny, wiadomość e-mail weryfikacyjna jest odczytywana i odbierana, a ona może się zalogować. Wreszcie dzwoni do swojego współpracownika, Jana Kowalskiego, wybierając adres john.doe@example.com w aplikacji Webex. John siedzi w biurze i widzi na swoim urządzeniu wideo połączenie pochodzące z jane.roe@example.com, czyli 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 fałszywymi połączeniami pochodzącymi z Internetu, ale jednym z obowiązków chmury Webex jest zapewnienie, że tożsamość osób dzwoniących z Webex jest poprawna i nie jest sfałszowana.

Aby sprawdzić tożsamość, Webex wymaga, aby firma udowodniła, że jest właścicielem domen używanych w usłudze Hybrid Calling. Jeśli nie, 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. Po wykonaniu tego kroku chmura Webex wykonuje zapytanie o rekord TXT dla tej domeny.

   • Jeśli zapytanie TXT powiedzie się, a wynik jest zgodny z tokenem wygenerowanym z chmury Webex, domena zostanie zweryfikowana.

   • Na przykład administrator musi udowodnić, że jest właścicielem domeny „example.com”, jeśli chce, aby usługi hybrydowe Webex działały w swojej domenie.

   • W https://admin.webex.com rozpoczyna proces weryfikacji od utworzenia rekordu TXT, aby pasował do tokenu wygenerowanego przez chmurę Webex:

     

   • Następnie administrator DNS tworzy rekord TXT dla tej domeny o wartości ustawionej na 123456789abcdef123456789abcdef123456789abcdef, 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 usługa Hybrid Calling działała, narzędzie Webex Device Connector musi komunikować się z usługą Webex.

Narzędzie Webex Device Connector jest wdrażane w sieci wewnętrznej, a sposób komunikuje się z chmurą za pośrednictwem wychodzącego połączenia HTTPS — tego samego typu, który jest używany w przypadku dowolnej przeglądarki łączącej się z serwerem WWW.

Komunikacja z chmurą Webex korzysta z TLS. Webex Device Connector to klient TLS, a chmura Webex to serwer 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.

Jeśli Webex Device Connector musi zweryfikować certyfikat dostarczony przez chmurę, do odkodowania podpisu musi użyć klucza publicznego urzędu certyfikacji, który podpisał ten certyfikat. Klucz publiczny jest zawarty w certyfikacie urzędu certyfikacji. Aby ustanowić zaufanie do urzędów certyfikacji używanych przez chmurę, lista certyfikatów tych zaufanych urzędów certyfikacji musi znajdować się w zaufanym magazynie Webex Device Connector.

Podczas komunikacji z urządzeniami narzędzie korzysta z podanych przez Ciebie zaufanych certyfikatów. Obecnie można to zrobić, umieszczając je w folderze [home folder]/.devicestool/certs.

Lista certyfikatów urzędu certyfikacji jest również wymagana dla drogi ekspresowej E w parze trawersów. Rozwiązanie Expressway-E komunikuje się z chmurą Webex przy użyciu protokołu SIP z protokołem TLS, co jest wymuszone przez uwierzytelnianie wzajemne. Rozwiązanie Expressway-E ufa połączenia przychodzące i przechodzące do chmury tylko wtedy, gdy CN lub SAN certyfikatu prezentowanego przez chmurę podczas konfiguracji połączenia TLS jest zgodne z nazwą podmiotu skonfigurowaną dla strefy DNS w usłudze Expressway („callservice.webex.com”). Urząd certyfikacji wydaje certyfikat dopiero po sprawdzeniu tożsamości. Aby uzyskać podpisany certyfikat, należy udowodnić własność domeny callservice.webex.com. Ponieważ my (Cisco) jesteśmy właścicielem tej domeny, nazwa DNS „callservice.webex.com” jest bezpośrednim dowodem na to, że zdalny element równorzędny 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.

Konto personifikacji Exchange jest zalecaną metodą firmy Microsoft w tym zadaniu. 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.