Bu bölüm, Karma Hizmetler ile ilgili temel yapılandırma öğeleri hakkında ek bağlam sağlar.

Bu noktalar, Webex cihazları için Karma Çağrı’yı başarılı bir şekilde dağıtmak istiyorsanız çok önemlidir. Bu öğeleri, özellikle aşağıdaki nedenlerle vurguladık:

• Karma dağıtımdaki rollerini anlamanızı sağlamak ve endişelerinizi gidermek için bunları size anlatmak istiyoruz.

• Bulutumuz ile şirket içi ortamınız arasında güvenli bir dağıtım sağlayan zorunlu ön koşullar vardır.

• Bunların, sıfırıncı gün öncesi etkinlikler olarak ele alınmaları gerekir: Kullanıcı arayüzündeki tipik bir yapılandırmaya göre tamamlanmaları daha uzun sürebilir, bu nedenle bu öğelerin ele alınması için belirli bir zaman tanıyın.

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

Expressway-C ve Expressway-E çifti dağıtımı , güvenlik duvarı geçiş teknolojilerini kullanarak Internet'e gelen ve giden çağrılara olanak tanır. Bu dağıtım, şirket içi çağrı kontrolünüzü güvenli bir şekilde alan ve Webex’e bağlayan şeydir.

Expressway-C ve Expressway-E, güvenlik duvarı geçiş mimarisi nedeniyle tarafsız bölge (DMZ) güvenlik duvarında gelen bağlantı noktasının açılmasını gerektirmez. Ancak TCP SIP sinyali bağlantı noktaları ve UDP ortam bağlantı noktaları, gelen çağrıların ulaşması için İnternet güvenlik duvarında gelen olarak açılmalıdır. Kuruluş güvenlik duvarınızda uygun bağlantı noktasının açılması için zaman tanımanız gerekir.

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

Örneğin, SIP protokolünü kullanan gelen işletmeden işletmeye (B2B) çağrılar için ses, video, içerik paylaşımı, çift video, vb. hizmetlere yönelik olarak kullanılan UDP ortam bağlantı noktalarıyla birlikte harici güvenlik duvarında TCP bağlantı noktaları 5060 ve 5061 (SIP TLS için 5061 kullanılır) açılmalıdır. Hangi ortam bağlantı noktalarının açılacağı, eş zamanlı çağrıların ve hizmetlerin sayısına bağlıdır.

Expressway’deki SIP dinleme bağlantı noktasını, 1024 ile 65534 arasında bir değer olacak şekilde yapılandırabilirsiniz. Aynı zamanda, bu değer ve protokol türü genel DNS SRV kayıtlarında gösterilmeli ve İnternet güvenlik duvarında aynı değer açılmalıdır.

SIP TCP’nin standardı 5060 ve SIP TLS’nin standardı 5061 olsa da aşağıdaki örnekte gösterildiği gibi hiçbir şey farklı bağlantı noktalarının kullanılmasını engelleyemez.

Örnek

Bu örnekte, gelen SIP TLS çağrıları için bağlantı noktası 5062’nin kullanıldığını varsayarız.

İki Expressway sunucusunun kümesi için DNS SRV kaydı şunun gibi görünür:

_sips._tcp.example.com SRV hizmet konumu:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV hizmet konumu:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

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

Ağda (internette) harici olan ve kurumsal etki alanının (user1@example.com) kullanıcısına SIP çağrısı yapan cihaz, kullanılacak taşıma türünü, bağlantı noktası numarasını, trafiğin yük paylaşımını ve çağrının gönderileceği SIP sunucularını anlamak için DNS’i sorgulamalıdır.

DNS girişi _sipsiçeriyorsa_tcp, giriş SIP TLS'yi belirtir.

TLS, istemci sunucu protokolüdür ve en yaygın uygulamalarda kimlik doğrulama için sertifikalar kullanır. İşletmeden işletmeye çağrı senaryosunda, TLS istemcisi arayan cihaz ve TLS sunucusu aranan cihaz olur. 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. İstemcinin sertifikaya ihtiyacı yoktur.

TLS el sıkışması, aşağıdaki diyagramda gösterilmiştir:

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

Hem arayan hem de aranan taraf, aşağıdaki diyagramda gösterildiği gibi diğer eşin sertifikasını kontrol eder:

Bulut Expressway kimliğini, Expressway de bulut kimliğini kontrol eder. Örneğin, sertifikadaki (CN veya SAN) bulut kimliği Expressway’de yapılandırılanla eşleşmezse bağlantı kesilir.

Karşılıklı kimlik doğrulama etkinleştirilirse Expressway-E her zaman istemci sertifikasını ister. Sonuç olarak çoğu durumda sertifikalar Jabber istemcilerinde dağıtılmadığı için Mobil ve Remote Access (MRA) çalışmaz. İşletmeden işletmeye senaryoda, arayan varlık sertifika sağlayamazsa çağrının bağlantısı kesilir.

Karşılıklı kimlik doğrulama ile TLS için 5062 gibi 5061’den farklı bir değer kullanmanızı öneririz. Webex Karma Hizmetler, B2B için kullanılan SIP TLS kaydını kullanır. Bağlantı noktası 5061’de, TLS istemci sertifikası sağlayamayan bazı diğer hizmetler çalışmaz.

Işletmeden işletmeye iletişimler için mevcut bir kayıt 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 DNS SRV kaydını aşağıdaki gibi belirtmenizi öneririz:

 Hizmet ve protokol: _sips._tcp.mtls.example.com Önceliği: 1 Ağırlık: 10 Bağlantı noktası numarası: 5062 Hedef: us-expe1.ornek.com 

Aynı Expressway çiftinde Işletmeden Işletmeye, Mobil ve Remote Access ve Webex trafiği

Işletmeden işletmeye (B2B) ve Mobil ve Uzaktan Erişim (MRA) çağrıları, SIP TLS için 5061 bağlantı noktası kullanır ve Webex trafiği, karşılıklı kimlik doğrulamalı SIP TLS için 5062 bağlantı noktası kullanır.

Etki alanı sahibi kontrolü, kimlik doğrulamanın parçasıdır. Etki alanı doğrulama, 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, üç etki alanı türü içerir ve bir kerelik doğrulama kontrolüdür:

   • E-posta etki alanı

   • Expressway-E DNS etki alanı

   • Dizin URI'sı etki alanı

2. Expressway-E DNS adı sahiplik kontrolü. Bu adım, karşılıklı kimlik doğrulama ile TLS uygulanarak gerçekleştirilir ve hem bulut hem de Expressway’de genel sertifikaların kullanımını içerir. Etki alanı kimlik kontrolünün aksine, bu adım buluta yapılan ve buluttan alınan tüm çağrılar sırasında gerçekleştirilir.

Etki alanı sahipliği kontrolünün önemi

Webex bulutu, güvenliği uygulamak için etki alanı sahiplik kontrolünü gerçekleştirir. Bu kontrol yapılmazsa kimlik hırsızlığı tehdidi oluşabilir.

Aşağıdaki hikayede, etki alanı sahipliği kontrolü yapılmazsa neler yaşanabileceği ayrıntılı olarak açıklanmıştır.

"hacker.com" olarak ayarlanmış DNS etki alanına sahip bir şirket, Webex Karma Hizmetleri satın alır. Etki alanı "example.com" olarak ayarlanan başka bir şirket de karma hizmetleri kullanmaktadır. Example.com şirketinin genel müdürlerinden birinin adı Jane Roe ve dizin URI’si jane.roe@example.com’dur.

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

Ardından, jane.roe@hacker.com ile Webex Uygulamasında oturum açar. Etki alanına sahip olduğu için doğrulama e-postası okunup yanıtlanır ve oturum açabilir. Son olarak, Webex Uygulamasından john.doe@example.com'u arayarak bir iş arkadaşı olan John Doe'yu arar. John ofisinde oturuyor ve e-posta hesabıyla ilişkili dizin URI’si olan jane.roe@example.com’dan gelen video cihazında bir çağrı görüyor.

"O yurt dışında." diye düşünür. “Önemli bir şeye ihtiyacı olabilir.” Telefonu yanıtlar ve sahte Jane Roe önemli belgeler ister. Cihazının bozuk olduğunu söyler ve seyahatte olduğu için ondan belgeleri özel e-posta adresi jane.roe@hacker.com’a göndermesini ister. Bu şekilde, şirket yalnızca Jane Roe ofise döndükten sonra önemli bilgilerin şirket dışına sızdırıldığında fark edebilir.

Example.com adlı şirketin Internet'ten gelen sahte çağrılara karşı korumanın birçok yolu vardır, ancak Webex bulutunun sorumluluklarından biri, Webex'ten çağrı yapan herkesin kimliğinin doğru olduğundan ve sahte olmadığından emin olmaktır.

Webex, kimliği kontrol etmek için şirketin Karma Çağrı'da kullanılan etki alanlarına sahip olduğunu kanıtlamasını gerektirir. Çalışmazsa Karma Hizmetler çalışmaz.

Bu sahiplikten emin olmak için iki etki alanı doğrulama adımı gereklidir:

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

   • Tüm bu etki alanı, yönlendirilebilir olmalı ve genel DNS sunucuları tarafından tanınmalıdır.

   • DNS yöneticisi, sahipliği kanıtlamak için DNS Metin kaydı (TXT) girmelidir. TXT kaydı, bazı rastgele ve biçimlendirilmemiş metinleri bir ana bilgisayarla veya başka bir adla ilişkilendirme imkanı sağlamak için kullanılan, DNS’teki kaynak kaydı türüdür.

   • DNS yöneticisi, bu TXT kaydını sahipliğinin kanıtlanması gereken bölgeye girmelidir. Bu adımdan sonra, Webex bulutu o 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ç ile eşleşirse etki alanı doğrulanır.

   • Örnek olarak, yönetici Webex Karma Hizmetleri'nin etki alanında çalışmasını istiyorsa "example.com" etki alanına sahip olduğunu kanıtlamalıdır.

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

     

   • DNS yöneticisi daha sonra bu etki alanı için aşağıdaki örnekte olduğu gibi 123456789abcdef123456789abcdef123456789abcdef123456789abcdef123456789abcdef olarak 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, TXT DNS araması gerçekleştirir:

     

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

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

   • Bulut, Expressway-E’nin, bulutun güvendiği sertifika yetkililerinin birinden gelen kimliği onayladığını kontrol etmelidir. Expressway-E yöneticisi, bu sertifika yetkililerinden birine Expressway-E için genel bir sertifika istemelidir. Sertifika yetkilisi, sertifikayı vermek için etki alanı doğrulama kontrolünü (etki alanı doğrulanmış sertifikalar için) veya kuruluş doğrulama kontrolünü (kuruluşu doğrulanmış sertifikalar için) temel alan bir kimlik doğrulama süreci gerçekleştirir.

   • Buluta ve buluttan yapılan çağrılar, Expressway-E’ye verilen sertifikaya bağlı olur. Sertifika geçerli değilse çağrı kesilir.

Karma Çağrının çalışması için Webex Cihaz Bağlayıcısı, Webex ile iletişim kurmalıdır.

Webex Cihaz Bağlayıcısı, dahili ağda dağıtılır ve bulutla iletişim kurma şekli giden bir HTTPS bağlantısı (bir web sunucusuna bağlanan tüm tarayıcılar için kullanılan türden) aracılığıyla olur.

Webex bulutla yapılan iletişimde TLS kullanılır. Webex Cihaz Bağlayıcısı TLS istemcisidir ve Webex bulutu TLS sunucusudur. Bu nedenle, Webex Cihaz Bağlayıcısı sunucu sertifikasını kontrol eder.

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

Webex Cihaz Bağlayıcısı'nın bulut tarafından sağlanan sertifikayı doğrulaması gerekiyorsa, imzanın şifresini çözmek için bu sertifikayı imzalayan sertifika yetkilisinin genel anahtarını kullanması gerekir. Genel anahtar, sertifika yetkilisinin sertifikasında yer alır. Bulut tarafından kullanılan sertifika yetkililerine güven oluşturmak için, bu güvenilir sertifika yetkililerinin sertifika listesi Webex Cihaz Bağlayıcısı güven deposunda olmalıdır.

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

Geçiş çiftinde Expressway-E için sertifika yetkilisi sertifikalarının listesi de gerekir. Expressway-E, karşılıklı kimlik doğrulamasıyla zorunlu kılınan TLS ile SIP kullanarak Webex bulutu ile iletişim kurar. Expressway-E, yalnızca TLS bağlantı kurulumu sırasında bulut tarafından sunulan sertifikanın CN veya SAN’si Expressway’deki DNS bölgesi için yapılandırılan konu adıyla eşleşiyorsa buluttan gelen ve buluta giden çağrılara güvenir ("callservice.webex.com"). Sertifika yetkilisi, yalnızca kimlik kontrolünden sonra bir sertifika yayınlar. Bir sertifika imzalanması için callservice.webex.com etki alanının sahipliği kanıtlanmalıdır. Bu etki alanına (Cisco) sahip olduğumuz için “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 bir kimliğe bürünme hesabı aracılığıyla takvimi Microsoft Exchange 2013, 2016, 2019 veya Office 365 ile entegre olur. Exchange’deki Uygulama kimliğe bürünme yönetim rolü, uygulamaların bir kuruluştaki kullanıcı adına görevler gerçekleştirmek için o kullanıcının kimliğine bürünmesini sağlar. Uygulama kimliğe bürünme rolü, Exchange'de yapılandır olmalı ve takvim bağlayıcısında Expressway-C arayüzünde Exchange yapılandırmasının parçası olarak kullanılır.

Exchange kimliğe bürünme hesabı, bu görev için Microsoft'un önerilen yöntemidir. Expressway-C yöneticilerinin, değer Exchange yöneticisi tarafından Expressway-C arayüzüne girilebilir olduğundan parolayı bilmiyor olması gerekir. Expressway-C yöneticisi Expressway C kutusuna kök erişimi olsa bile parola açıkça Expressway gösterilmez. Parola, Expressway-C'de diğer parolalar ile aynı kimlik şifreleme mekanizması kullanılarak Expressway depolanır.

Ek güvenlik olarak, hat üzerindeki EWS bağlantılarının güvenliğini sağlamak amacıyla TLS’i etkinleştirmek için Cisco Webex Karma Takvim Hizmeti Uygulama Kılavuzundaki adımları izleyin.

Ek güvenlik olarak, hat üzerinde EWS bağlantılarının güvenliğini Expressway TLS'yi etkinleştirmek için Microsoft Exchange için Dağıtım Expressway Takvim Bağlayıcısı'nın adımları uygulayın.