Cisco Webex Karma Hizmetleri Dağıtılmadan Önce Hazırlanacak Şeyler

list-menuGeri Bildirim?
Ortamınızda Cisco Webex Karma Hizmetlerini dağıtırken sorun yaşıyor olabilirsiniz. Veya tasarımla ilgili dikkate alınması gereken bazı şeyleri daha iyi anlamak istiyorsunuzdur. Bu makale; güvenlik duvarıyla ilgili dikkate alınması gerekenler, sertifika yetkilileri ve etki alanı sahipliği gibi önemli karma öğeleri anlamanıza yardımcı olacak bir kontrol listesi olarak kullanılabilir.

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

Webex cihazları için Hibrit Arama özelliğini başarıyla devreye almak istiyorsanız bu noktalar ç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.

  • Ortamınızda bu maddeler ele alındıktan sonra, Hibrit Hizmetler yapılandırmanızın geri kalanı sorunsuz bir şekilde ilerleyecektir.

Expressway-C ve Expressway-E çiftinin konuşlandırılması güvenlik duvarı geçiş teknolojilerini kullanarak İnternet'e yapılan ve İnternet'ten gelen çağrıları mümkün kılar . Bu kurulum, şirket içi çağrı kontrol sisteminizi güvenli bir şekilde Webex'e entegre eder.

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:

Güvenlik duvarı geçiş mimarisini gösteren diyagram.

Ö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 kaydı _sips._tcpiçeriyorsa, kayıt 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:

TLS el sıkışmasının üst düzey genel görünümünü gösteren şema.

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 ile Webex bulutu arasında kurulan görüşme gibi sunucular arası bağlantılarda faydalıdır. Bu kavrama karşılıklı kimlik doğrulamalı TLS denir ve Webex ile entegrasyon yapılırken gereklidir.

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

TLS istemcisinin ve TLS sunucusunun diğer tarafın sertifikasını kontrol ettiği karşılıklı kimlik doğrulamalı TLS el sıkışmasının şematik gösterimi.

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 Hibrit Hizmetleri, B2B için kullanılan aynı SIP TLS kaydını kullanır. Bağlantı noktası 5061’de, TLS istemci sertifikası sağlayamayan bazı diğer hizmetler çalışmaz.

İşletmeler arası iletişim için halihazırda mevcut bir kayıt kullanılıyorsa, Control Hub'da SIP hedefi olarak kurumsal alan adının bir alt alan adını ve dolayısıyla aşağıdaki gibi bir genel DNS SRV kaydını belirtmenizi öneririz:

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

İşletmeler arası (B2B), mobil ve uzaktan erişim ve Webex trafiği aynı otoyol çifti üzerinde.

İşletmeler arası (B2B) ve Mobil ve Uzaktan Erişim (MRA) aramaları SIP TLS için 5061 numaralı bağlantı noktasını kullanırken, Webex trafiği karşılıklı kimlik doğrulamalı SIP TLS için 5062 numaralı bağlantı noktasını kullanır.

Etki alanı sahibi kontrolü, kimlik doğrulamanın parçasıdır. Alan adı doğrulaması, Webex bulutunun sizin kim 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.

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

Webex bulut platformu, güvenliği sağlamak için alan adı sahipliği 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.

DNS alan adı "hacker.com" olarak ayarlanmış bir şirket, Webex Hybrid Services'ı satın alıyor. 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 Webex uygulamasına giriş yapıyor. jane.roe@hacker.com. Etki alanına sahip olduğu için doğrulama e-postası okunup yanıtlanır ve oturum açabilir. Son olarak, John Doe adlı bir meslektaşını aramak için numarayı çeviriyor. john.doe@example.com Webex uygulamasından. John ofisinde otururken görüntülü görüşme cihazında bir arama geldiğini görüyor. jane.roe@example.com; Bu, söz konusu e-posta hesabıyla ilişkili dizin URI'sidir.

"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 şirketi, internetten gelen dolandırıcılık amaçlı aramalara karşı birçok koruma yöntemine sahip; ancak Webex bulutunun sorumluluklarından biri de Webex'ten arayan herhangi bir kişinin kimliğinin doğru ve sahte olmadığından emin olmaktır.

Kimliği doğrulamak için Webex, şirketin Hibrit Arama'da kullanılan alan adlarının sahibi olduğunu kanıtlamasını şart koşuyor. Eğer öyle olmazsa, Hibrit 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 alan adı için bir TXT kaydı sorgusu gerçekleştirir.

    • TXT sorgusu başarılı olursa ve sonuç Webex bulutundan oluşturulan belirteçle eşleşirse, alan adı doğrulanmış olur.

    • Örneğin, Webex Hybrid Services'ın kendi alan adında çalışmasını istiyorsa, yöneticinin "example.com" alan adının sahibi olduğunu kanıtlaması gerekir.

    • https://admin.webex.comaracılığıyla, Webex bulutunun oluşturduğu belirteçle eşleşen bir TXT kaydı oluşturarak doğrulama sürecini başlatır:

      Alan adını doğrulama penceresinde "alan adının size ait olduğunu kanıtlamak için DNS doğrulama belirtecinizi TXT kaydı bölümüne kopyalayıp yapıştırmanız gerekir" mesajı ve doğrulama düğmesi bulunur.

    • DNS yöneticisi daha sonra bu etki alanı için değeri 123456789abcdef123456789abcdef123456789abcdef123456789abcdefolarak ayarlanmış bir TXT kaydı oluşturur, aşağıdaki örnekte olduğu gibi:

      TXT kayıt değeri doldurulmuş kayıt kümesi düzenleme penceresi

    • 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:

      Bulut, kod kullanarak TXT DNS sorgusu gerçekleştiriyor.

    • 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.

Hibrit aramaların çalışabilmesi için Webex Aygıt Bağlayıcısının Webex ile iletişim kurması gerekmektedir.

Webex Aygıt Bağlayıcısı dahili ağda konuşlandırılmıştır ve bulutla iletişim kurma şekli, herhangi bir tarayıcının web sunucusuna bağlanması için kullanılanla aynı türde olan giden bir HTTPS bağlantısı üzerindendir.

Webex bulutuna iletişim TLS kullanılarak sağlanır. Webex Device Connector, TLS istemcisi; Webex bulutu ise TLS sunucusudur. Bu nedenle, Webex Aygıt 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 Aygıt Bağlayıcısı, bulut tarafından sağlanan sertifikayı doğrulamak zorundaysa, imzayı çözmek için o sertifikayı imzalayan sertifika otoritesinin genel anahtarını kullanmalıdır. Genel anahtar, sertifika yetkilisinin sertifikasında yer alır. Bulut tarafından kullanılan sertifika yetkilileriyle güven ilişkisi kurmak için, bu güvenilir sertifika yetkililerinin sertifika listesinin Webex Aygıt Bağlayıcısı güven deposunda bulunması gerekir.

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

Geçiş çiftinde Expressway-E için sertifika yetkilisi sertifikalarının listesi de gerekir. Expressway-E, karşılıklı kimlik doğrulama ile desteklenen TLS özellikli SIP kullanarak Webex bulutuyla iletişim kurar. Expressway-E, buluttan gelen ve buluta giden aramaları yalnızca TLS bağlantı kurulumu sırasında bulut tarafından sunulan sertifikanın CN veya SAN'ı, Expressway'de DNS bölgesi için yapılandırılmış konu adıyla ("callservice.webex.com") eşleşiyorsa güvenilir kabul eder. Sertifika yetkilisi, yalnızca kimlik kontrolünden sonra bir sertifika yayınlar. Sertifika imzalanması için callservice.webex.com alan adının sahipliğinin kanıtlanması gerekmektedir. Çünkü bu alan adı bize (Cisco) ait, "callservice.webex.com" DNS adı, karşı tarafın 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 kimlik taklit hesabı, Microsoft'un bu görev için önerdiği yöntemdir. 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.

Bu makale yararlı oldu mu?
Bu makale yararlı oldu mu?