Bu bölüm, Hibrit Hizmetlerle ilgili anahtar yapılandırma öğeleri hakkında ek bağlam sağlar.

Webex cihazları için Hibrit Çağrıyı başarıyla dağıtmak istiyorsanız bu noktalar çok önemlidir. Bu öğeleri özellikle aşağıdaki nedenlerle vurguladık:

• Hibrit bir dağıtımdaki rollerini anlamanız ve kendinizi güvende hissetmeniz için bunları açıklamak istiyoruz.

• Bunlar, bulutumuz ile şirket içi ortamınız arasında güvenli bir dağıtım sağlayan zorunlu ön koşullardır.

• Gün öncesi sıfır etkinlikler olarak ele alınmalıdır: tamamlanması bir kullanıcı arayüzündeki tipik yapılandırmadan biraz daha uzun sürebilir, bu nedenle bu öğelerin sıralanması için bir zaman dilimine izin verin.

• Bu öğeler ortamınızda ele alındıktan sonra, Hibrit Hizmetler yapılandırmanızın geri kalanı sorunsuz bir şekilde devam edecektir.

Expressway-C ve Expressway-E çifti dağıtımı, güvenlik duvarı geçiş teknolojilerini kullanarak İnternet'e ve İnternet'ten gelen çağrılara izin verir . Bu dağıtım, şirket içi çağrı kontrolünüzü güvenli bir şekilde alan ve We bex'e bağlayan şeydir.

Expressway-C ve Expressway-E, güvenlik duvarı geçiş mimarisi nedeniyle askerden arındırılmış bölge (DMZ) güvenlik duvarında herhangi bir gelen bağlantı noktasının açılmasını gerektirmez. Ancak gelen aramaların gelmesine izin vermek için TCP SIP sinyal bağlantı noktaları ve UDP medya bağlantı noktaları İnternet güvenlik duvarında gelen olarak açılmalıdır. Kur umsal güvenlik duvarınızda uygun bağlantı noktasının açılması için zaman ayırmanız gerekir.

Güvenlik duvarı geçiş mimarisi aşağıdaki şemada gösterilmiştir:

Örneğin, SIP protokolünü kullanan gelen işletmelerden işletmeye (B2B) çağr ıları için, ses, video, içerik paylaşımı, çift video vb. hizmetler için kullanılan UDP medya bağlantı noktaları ile birlikte harici güvenlik duvarında 5060 ve 5061 TCP bağlantı noktaları (5061 SIP TLS için kullanılır) açılmalıdır. Hangi medya bağlantı noktalarının açıl acağı eşzamanlı aramaların sayısına ve hizmet sayısına bağlıdır.

Expressway üzerindeki SIP dinleme bağlantı noktasını 1024 ile 65534 arasında herhangi bir değer olacak şekilde yapılandırabilirsiniz. Aynı zamanda, bu değer ve protokol türü genel DNS SRV kayıt larda ilan edilmeli ve aynı değ erin İnternet güvenlik duvarında açılması gerekir.

SIP TCP için standart 5060 ve SIP TLS 5061 olmasına rağmen, aşağıdaki örnekte gösterildiği gibi hiçbir şey farklı bağlantı noktalarının kullanılmasını engellemez.

Örnek

Bu örnekte, gelen SIP TLS çağrıları için 5062 bağlantı noktasının kullanıldığını varsayıyoruz.

İki Expressway sunucusundan oluşan bir kümenin kaydı şöyle görünür: DNS SRV

_yudumlar. _tcp.example .com SRV servis konumu:

priority = 10

weight = 10

port = 5062

svr ana bilgisayar adı = us-expe1.example.com

_yudumlar. _tcp.example .com SRV servis konumu:

priority = 10

weight = 10

port = 5062

svr ana bilgisayar adı = us-expe2.example.com

Bu kayıtlar, aramaların, taşıma türü olarak TLS ve dinleme bağlantı noktası numarası olarak 5062 kullanılarak eşit yük paylaşımı (öncelik ve ağırlık) ile us-expe1.example.com ve us-expe2.example.com adresine yönlendirildiği anlamına gelir.

Ağ dışında (İnternet üzerinde) olan ve kurumsal etki alanının (user1@example.com) bir kullanıcısına SIP çağrısı yapan bir aygıt, hangi aktarım türünü kullanacağını, bağlantı noktası numarasını, trafiğin nasıl yükleneceğini ve aramanın hangi SIP sunucularına gönderileceğini anlamak için DNS'yi sorgulamalıdır.

DNS girişi _sips içeriyorsa. _tcp, giriş SIP TLS'yi belirtir.

TLS bir istemci-sunucu protokolüdür ve en yaygın uygulamalarda kimlik doğrulama için sertifikalar kullanır. İşletmeler arası arama sen aryosunda, TLS istemcisi arayan cihazdır ve TLS sunucusu ç ağrılan aygıttır. TLS ile istemci sunucunun sertifikasını kontrol eder ve sertifika kontrolü başarısız olursa çağrının bağlantısını keser. Müşterinin sertifikaya ihtiyacı yoktur.

TLS el sıkışma aşağıdaki şemada gösterilmiştir:

Ancak, TLS spesifikasyonu, sunucunun TLS el sıkışma protokolü sırasında istemciye Sertifika İsteği iletisi göndererek istemci sertifikasını da kontrol edebileceğini belirtir. Bu ileti, Expressway-E ve Webex bulutu arasında kurulan çağrı gibi sunucudan sunucuya bağlantıda yararlıdır. Bu kavram karşılıklı kimlik doğrulamalı TLS olarak adlandırılır ve Webex ile entegre edilirken gereklidir.

Hem arayan hem de çağrılan taraflar, aşağıdaki şem ada gösterildiği gibi diğer akranın sertifikasını kontrol eder:

Bulut, Expressway kimliğini kontrol eder ve Expressway bulut kim liğini kontrol eder. Örneğin, sertifikadaki (CN veya SAN) bulut kimliği Expressway'de yapılandırılanlarla eşleşmiyorsa bağlantı kesilir.

Karşılıklı kimlik doğrulama açıksa, Expressway-E her zaman istemci sertifik asını ister. Sonuç olarak, çoğu durumda sertifik alar Jabber istemcilerinde dağıtılmadığından Mobile ve Remote Access (MRA) çalışmaz. İşletmeler arası senaryoda, arayan varlık bir sertifika sağlayamazsa, arama bağlantısı kesilir.

Karşılıklı kimlik doğrulamasına sahip TLS için 5061 dışında bir değer kullanmanızı öneri riz, örneğin bağlantı noktası 5062. Webex Hibrit Hizmetleri, B2B için kullanılan aynı SIP TLS kaydını kullanır. Bağlantı noktası 5061 durumunda, TLS istemci sertifikası sağlayamayan diğer bazı hizmetler çalışmaz.

Mevcut bir kayıt işletmeler arası iletişim için zaten kullanılıyorsa, Control Hub'da SIP hedefi olarak kurumsal etki alanının bir alt etki alan ını ve dolayısıyla genel bir kaydı aşağıdaki gibi belirtmenizi öneri DNS SRV riz:

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

Aynı Expressway çiftinde işletmeler Remote Access arası, Mobil ve Webex trafiği

İşletmeler arası (B2B) ve Mobil ve Remote Access (MRA) ç ağrıları SIP TLS için 5061 bağlantı noktasını kullanır ve Webex trafiği karşılıklı kimlik doğrulamalı SIP TLS için 5062 bağlantı noktasını kullanır.

Etki alanı sahipliği kontrolü kimlik doğrulamasının bir parçasıdır. Etki alanı doğrulaması, Webex bulutunun söylediğiniz kişi olduğunuzu kanıtlamak için uyguladığı bir güvenlik önlemi ve kimlik kontrolüdür.

Kimlik kontrolü iki aşamada gerçekleştirilir:

1. Etki alanı sahipliği kontrolü. Bu adım üç tür etki alanı içerir ve tek seferlik doğrulama kontrolüdür:

   • E-posta alan adı

   • Expressway-E DNS etki alanı

   • Dizin URI etki alanı

2. Expressway-E DNS adı sahipliği kontrolü. Bu adım, karşılıklı kimlik doğrulama ile TLS'nin uygulanması yoluyla gerçekleştirilir ve hem bulutta hem de Expressway'de genel sertifikaların kullanılmasını içerir. Etki alanı kimliği kontrolünden farklı olarak, bu adım buluta yapılan ve buluta alınan herhangi bir arama sırasında gerçekleştirilir.

Alan adı sahipliği kontrolünün önemi

Webex bulutu, güvenliği uygulamak için etki alanı sahipliği denetimini gerçekleştirir. Bu kontrol yapılmazsa kimlik hırsızlığı olası bir tehdittir.

Aşağıdaki hikaye, etki alanı sahipliği denetimi yapılmazsa neler olabileceği ayrıntılarıyla açıklanmaktadır.

DNS etki alanı “hacker.com” olarak ayarlanmış bir şirket, Webex Hibrit Hizmetlerini satın alır. Kendi etki alanı “example.com” olarak ayarlanmış başka bir şirket de hibrit hizmetler kullanıyor. Example.com şirketinin genel yöneticilerinden biri Jane Roe'dir ve URI jane.roe@example.com dizinine sahiptir.

Hacker.com şirketinin yöneticisi, dizin URI'lerinden birini jane.roe@example.com ve e-posta adresini jane.roe@hacker.com olarak ayarlar. Bunu yapabilir çünkü bulut bu örnekte SIP URI etki alanını kontrol etmiyor.

Ardından, Webex Uygulamasında jane.roe@hacker.com ile oturum açar. Alan adının sahibi olduğu için doğrulama e-postası okunur ve yanıtlanır ve oturum açabilir. Son olarak, bir meslektaşı olan John Doe'yi Webex Uygulamasından john.doe@example.com arayarak bir arama yapar. John ofisinde oturuyor ve video cihazında jane.roe@example.com adresinden gelen bir çağrı görüyor; bu, o e-posta hesabıyla ilişkili dizin URI'sidir.

“Yurtdışında,” diye düşündü. “Önemli bir şeye ihtiyacı olabilir.” Telefona cevap verir ve sahte Jane Roe önemli belgeler ister. Cihazının bozuk olduğunu ve seyahat ettiği için belgeleri özel e-posta adresine göndermesini istediğini açıklıyor: jane.roe@hacker.com. Bu şekilde, şirket ancak Jane Roe ofise geri döndükten sonra önemli bilgilerin şirket dışına sızdırıldığını fark eder.

Example.com şirketinin İnternet'ten gelen sahte aramalara karşı koruma sağlamanın birçok yolu vardır, ancak Webex bulutunun sorumluluklarından biri, Webex'ten arayan herkesin kimliğinin doğru olduğundan ve tahrif edilmediğinden emin olmaktır.

Kimliği kontrol etmek için Webex, şirketin Hibrit Çağrıda kullanılan etki alanlarına sahip olduğunu kanıtlamasını gerektirir. Aksi takdirde , Hibrit Hizmetler çalışmaz.

Bu sahipliği sağlamak için iki etki alanı doğrulama adımı gereklidir:

1. Şirketin e-posta etki alanına, Expressway-E etki alanına, Directory URI etki alanına sahip olduğunu kanıtlayın.

   • Tüm bu etki alanları yönlendirilebilir olmalı ve genel DNS sunucuları tarafından bilinmelidir.

   • Sahipliği kanıtlamak için DNS yöneticisinin bir DNS Metin kaydı (TXT) girmesi gerekir. TXT kaydı, bazı keyfi ve biçimlendirilmemiş metinleri bir ana bilgisayar veya başka bir adla ilişkilendirme yeteneği sağlamak için kullanılan DNS'deki bir kaynak kaydı türüdür.

   • DNS yöneticisi, sahipliği kanıtlanması gereken bölgeye bu TXT kaydını girmelidir. Bu adımdan sonra, Webex bulutu söz konusu etki alanı için bir TXT kayıt sorgusu gerçekleştirir.

   • TXT sorgusu başarılı olursa ve sonuç Webex bulutundan oluşturulan belirteçle eşleşirse etki alanı doğrulanır.

   • Örnek olarak, yönetici, Webex Hibrit Hizmetlerinin etki alanı üzerinde çalışmasını istiyorsa, “example.com” etki alanına sahip olduğunu kanıtlamalıdır.

   • https://admin.webex.com aracılığıyla, Webex bulutunun oluşturduğu belirteçle eşleşecek bir TXT kaydı oluşturarak doğrulama işlemini başlatır:

     

   • DNS yöneticisi bu etki alanı için aşağıdaki örnekte olduğu gibi 123456789abcdef 123456789abcdef123456789abc def değerine ayarlanmış bir TXT kaydı oluşturur:

     

   • Bu noktada bulut, example.com etki alanı için TXT kaydının belirteçle eşleştiğini doğrulayabilir.

   • Bulut bir TXT DNS araması gerçekleştirir:

     

   • TXT değeri belirteç değeriyle eşleştiğinden, bu eşleşme yöneticinin kendi etki alanı için TXT kaydını genel DNS'ye eklediğini ve etki alanının sahibi olduğunu kanıtlar.

2. Expressway-E DNS Adı sahiplik kontrolü.

   • Bulut, Expressway-E'nin bulutun güvendiği sertifika yetkililerinden birinden onaylanmış bir kimliğe sahip olup olmadığını kontrol etmelidir. Expressway-E yöneticisi, Expressway-E için bu sertifika yetkililerinden birine genel bir sertifika talep etmelidir. Sertifikayı vermek için sertifika yetkilisi, etki alanı doğrulama kontrolüne (etki alanı doğrulanmış sertifikalar için) veya kuruluş doğrulama kontrolüne (kuruluş doğrulanmış sertifikalar için) dayalı bir kimlik doğrulama işlemi gerçekleştirir.

   • Buluta ve buluta yapılan aramalar, Expressway-E'ye verilen sertifikaya bağlıdır. Sertifika geçerli değilse, çağrı kesilir.

Hibrit Çağrının çalışması için Webex Aygıt Bağlayıcısının Webex ile iletişim kurması gerekir.

Webex Aygıt Bağlayıcısı dahili ağda dağıtılır ve bul utla iletişim kurma şekli, bir web sunucusuna bağlanan herhangi bir tarayıcı için kullanılan türün aynısı olan giden bir HTTPS bağlantısı üzerinden gerçekleşir.

Webex bulutu ile iletişim TLS kullanır. Webex Aygıt Bağlayıcısı TLS istemcisidir ve Webex bulutu TLS sunucusudur. Bu nedenle, Webex Aygıt Bağlayıcısı sunucu sertifikasını denetler.

Sertifika yetkilisi, kendi özel anahtarını kullanarak bir sunucu sertifikasını imzalar. Açık anahtara sahip herkes bu imzanın kodunu çözebilir ve aynı sertifika yetkilisinin bu sertifikayı imzaladığını kanıtlayabilir.

Webex Aygıt Bağlayıcısının bulut tarafından sağlanan sertifikayı doğrulaması gerekiyorsa, imzanın kodunu çözmek için bu sertifikayı imzalayan sertifika yetkilisinin ortak anahtarını kullanmalıdır. Ser tifika yetkilisinin sertifikasında bir ortak anahtar bulunur. Bulut tarafından kullanılan sertifika yetkililerine güven oluşturmak için, bu güvenilir sertifika yetkililerinin sertifikalarının listesi Webex Aygıt Bağlayıcısı güven deposunda olmalıdır.

Cihazlarla iletişim kurarken, araç sağladığınız güvenilir sertifikaları kullanır. Şu anda bunu yapmanın yolu onları yerleştirmektir [home folder]/.devicestool/certs..

Geçiş çiftindeki Expressway-E için sertifika yetkilisi sertifikalarının bir listesi de gereklidir. Expressway-E, karşılıklı kimlik doğrulama ile zorlanan TLS ile SIP kullanarak Webex bulutu ile iletişim kurar. Expressway-E, yalnızca TLS bağlantısı kurulumu sırasında bulut tarafından sunulan sertifikanın CN veya SAN'ı Expressway'deki DNS bölgesi (“callservice.webex.com”) için yapılandırılan konu adıyla eşleşiyorsa, buluttan gelen ve buluta giden ç ağrılara güvenir. Sertifika yetkilisi bir sertifikayı yalnızca kimlik kontrolünden sonra yayınlar. Bir sertifikanın imzalanması için callservice.webex.com etki alanının sahipliği kanıtlanmalıdır. Biz (Cisco) bu etki alanına sahibiz , “callservice.webex.com” DNS adı, uzak eşin gerçekten Webex olduğunun doğrudan kanıtıdır.

takvim bağlayıcısı, Webex'i bir Microsoft Exchange kimliğe bürünme hesabı aracılığıyla 2013, 2016, 2019 veya Office 365 ile entegre eder. Exchange'deki uygulama kimliğine bürünme yönetimi rolü, uygulamaların kullanıcı adına görevleri gerçekleştirmek üzere bir kuruluştaki kullanıcıları taklit etmesine olanak tanır. Uygulama kimliğine bürünme rolü Exchange'de yapılandırılmalıdır ve takvim bağlayıcısında Expressway-C arabiriminde Exchange yapılandırmasının bir parçası olarak kullanılır.

Exchange kimliğine bürünme hesabı, Microsoft'un bu görev için önerdiği yöntemdir. Expressway-C yöneticilerinin parolayı bilmesi gerekmez, çünkü değer Expressway-C arayüzüne bir Exchange yöneticisi tarafından girilebilir. Expressway-C yöneticisinin Expressway-C kutusuna kök erişimi olsa bile şifre açıkça gösterilmez. Şifre, Expressway-C'deki diğer şifrelerle aynı kimlik bilgisi şifreleme mekanizması kullanılarak şifrelenmiş olarak saklanır.

Ek güvenlik için, kablo üzerindeki EWS bağlantılarını güvence altına almak için T Cisco Webex LS'yi etkinleştirmek için Karma Takvim Hizmet i Dağıtım Kılavuzu'ndaki adımları izleyin.

Ek güvenlik için, kablodaki EWS bağlantılarını güvence altına almak için TLS"yi etkin Microsoft Exchange leştirmek için Ekspres Takvim Bağlayıcısını Dağıtma bölümündeki adımları izleyin.