이 섹션은 하이브리드 서비스와 관련된 주요 구성 항목에 대해 추가된 개념을 제공합니다.

Webex 기기에서 하이브리드 통화를 성공적으로 배포하려면 다음 사항들이 매우 중요합니다. 다음의 이유 때문에 해당 항목을 특별히 강조합니다.

• 귀하에게 해당 작업을 설명하고, 하이브리드 배포에서 해당 역할을 이해하여 작업에 대해 확신할 수 있도록 하기 위함입니다.

• 해당 작업은 저희 클라우드와 귀하의 온-프레미스 환경 간의 안전한 배포를 위한 필수 전제 조건입니다.

• 해당 작업은 준비 날짜 제로 활동으로 간주합니다. 이는 사용자 인터페이스에서 완료하는 데 있어 일반적인 구성보다 더 긴 시간이 소요될 수 있기 때문에 해당 항목을 정리하기 위한 시간 범위를 허용해야 합니다.

• 환경에서 해당 항목이 처리된 후에 나머지 하이브리드 서비스 구성이 원활하게 진행됩니다.

Expressway-C와 Expressway-E 쌍 배포는방화벽 통과 기술을 사용하여 인터넷과의 통화를 허용합니다. 이 배포를 통해 온프레미스 통화 제어 시스템을 Webex와 안전하게 연동할 수 있습니다.

Expressway-C 및 Expressway-E는 방화벽 순회 아키텍처로 인해 비무장지대(DMZ) 방화벽에 인바운드 포트를 열 필요가 없습니다. 걸려오는 전화가 통과할 수 있도록 인터넷 방화벽에서 TCP SIP 시그널링 포트 및 UDP 미디어 포트를 열어 두어야 합니다. 기업 방화벽에서 적당한 포트가 열릴 때까지 충분한 시간을 허용해야 합니다.

방화벽 순회 아키텍처는 다음 다이어그램에서 표시됩니다.

예를 들어, SIP 프로토콜을 사용하는 인바운드 비즈니스 간(B2B) 통화에 대해 TCP 포트 5060 및 5061(5061은 SIP TLS를 위해 사용됨)은 음성, 비디오, 콘텐츠 공유, 듀얼 비디오 등의 서비스에 사용되는 UDP 미디어 포트와 함께 외부 방화벽에 열려 있어야 합니다. 어떤 미디어 포트를 열어 두어야 하는지는 동시 통화의 수 및 서비스의 수에 따라 달라집니다.

Expressway에서 SIP 수신 대기 포트를 1024부터 65534 사이의 값으로 구성할 수 있습니다. 동시에 이 값 및 프로토콜 유형은 공개 DNS SRV 레코드에 광고되어야 하며, 해당 동일한 값은 인터넷 방화벽에 열려 있어야 합니다.

SIP TCP에 대한 표준은 5060이며 SIP TLS 5061이지만, 다음 예제에서 표시하는 바와 같이 다른 포트를 사용할 수도 있습니다.

예제

이 예제에서 인바운드 SIP TLS 통화에 대해 포트 5062가 사용된다고 가정합니다.

두 개의 Expressway 서버의 클러스터에 대한 DNS SRV 레코드는 다음과 같습니다.

_sips._tcp.example.com SRV 서비스 위치:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV 서비스 위치:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

해당 레코드는 전송 유형으로 TLS를 사용하고 수신 대기 포트 번호로 5062를 사용하여 동일한 로드 공유(우선순위(priority) 및 가중치(weight}로 통화가 us-expe1.example.com 및 us-expe2.example.com으로 디렉트됨을 의미합니다.

네트워크에 대해 외부이며(인터넷에서) 기업 도메인의 사용자(user1@example.com)에게 SIP 통화를 실행하는 장치는 DNS를 쿼리하여 어떠한 전송 유형을 사용할지, 포트 번호, 트래픽을 로드-공유하는 방법 및 어떤 SIP 서버에서 통화를 발송하는지 이해해야 합니다.

DNS 항목에 _sips._tcp가 포함되어 있으면 해당 항목은 SIP TLS를 지정합니다.

가장 일반적인 실행에 있어 TLS가 클라이언트-서버 프로토콜이며 인증서를 사용하여 인증합니다. 비즈니스 간 통화 시나리오에서 TLS 클라이언트는 전화를 거는 장치이며, TLS 서버는 전화를 받는 장치입니다. TLS를 사용하여 클라이언트는 서버의 인증서를 확인하며, 인증서 확인에 실패하는 경우에 통화의 연결을 끊습니다. 클라이언트는 인증서가 필요하지 않습니다.

TLS 핸드쉐이크는 다음 다이어그램에서 표시됩니다.

단, TLS 사양은 TLS 핸드쉐이크 프로토콜 과정 중에 클라이언트에게 인증서 요청 메시지를 발송하여 서버 또한 클라이언트 인증서를 확인할 수 있음을 설명합니다. 이 메시지는 Expressway-E와 Webex 클라우드 간에 설정된 통화와 같은 서버 간 연결에서 유용합니다. 이 개념은 상호 인증을 사용하는 TLS라고 하며 Webex와 통합할 때 필요합니다.

다음 다이어그램에 표시된 바와 같이 전화를 거는 사용자 및 전화를 받는 사용자 모두 다른 피어의 인증서를 확인합니다.

클라우드는 Expressway 아이덴티티를 확인하고, Expressway는 클라우드 아이덴티티를 확인합니다. 예를 들어, 인증서(CN 또는 SAN)에 있는 클라우드 아이덴티티가 Expressway에 구성된 아이덴티티와 일치하지 않는 경우 연결은 끊깁니다.

상호 인증이 켜져 있으면 Expressway-E는 항상 클라이언트 인증서를 요청합니다. 결과적으로 모바일 및 Remote Access(MRA)는 작동하지 않게 됩니다. 이는 대부분의 경우에 Jabber 클라이언트에 인증서가 배포되어 있지 않기 때문입니다. 비즈니스 간 시나리오에서 전화를 거는 엔티티가 인증서를 제공할 수 없는 경우, 전화의 연결이 끊깁니다.

상호 인증을 포함하는 TLS에 대해 5062 등 5061 이외의 값을 사용할 것을 권장합니다. Webex 하이브리드 서비스는 B2B에 사용되는 것과 동일한 SIP TLS 레코드를 사용합니다. 포트 5061의 경우, TLS 클라이언트 인증서를 제공할 수 없는 일부 다른 서비스는 작동하지 않습니다.

기업 간 통신에 이미 기존 레코드가 사용 중인 경우, Control Hub에서 SIP 대상으로 회사 도메인의 하위 도메인을 지정하고 다음과 같이 공용 DNS SRV 레코드를 생성하는 것이 좋습니다.

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

기업 간 거래(B2B), 모바일 및 원격 접속, Webex 트래픽이 동일한 Expressway 쌍에서 처리됩니다.

기업 간(B2B) 통화 및 모바일 및 원격 접속(MRA) 통화는 SIP TLS에 5061번 포트를 사용하고, Webex 트래픽은 상호 인증을 사용하는 SIP TLS에 5062번 포트를 사용합니다.

도메인 소유권 확인은 아이덴티티 인증의 일부입니다. 도메인 인증은 Webex 클라우드에서 사용자가 본인임을 확인하기 위해 구현하는 보안 조치 및 신원 확인 절차입니다.

아이덴티티 확인은 다음 두 단계로 실행됩니다.

1. 도메인 소유권 확인하기. 이 단계에는 다음 세 가지 유형의 도메인이 포함되며, 이는 일회성 인증 확인입니다.

   • 이메일 도메인

   • Expressway-E DNS 도메인

   • 디렉토리 URI 도메인

2. Expressway-E DNS 이름 소유권 확인하기. 이 단계는 상호 인증이 포함되는 TLS의 실행을 통해 수행되며, 클라우드 및 Expressway 모두에 있는 공개 인증서가 사용됩니다. 도메인 아이덴티티 확인과 달리, 이 단계는 클라우드에서 발신 및 수신하는 모든 통화 중에 실행됩니다.

도메인 소유권 확인의 중요성

Webex 클라우드는 보안 강화를 위해 도메인 소유권 확인을 수행합니다. 이 확인 작업이 실행되지 않는 경우에 신원 도용의 위험이 있을 수 있습니다.

다음 스토리는 도메인 소유권 확인이 실행되지 않는 경우에 발생할 수도 있는 사례를 소개합니다.

DNS 도메인이 "hacker.com"으로 설정된 회사가 Webex Hybrid Services를 인수했습니다. 도메인이 "example.com"으로 설정된 다른 회사에서도 하이브리드 서비스를 사용합니다. 회사 Example.com의 관리자 중 한 명의 이름은 Jane Roe이며, 디렉토리 URI jane.roe@example.com를 갖고 있습니다.

Hacker.com 회사의 관리자가 디렉토리 URI 중 하나를 jane.roe@example.com, 이메일 주소를 jane.roe@hacker.com으로 설정합니다. 이 예제에서 클라우드가 SIP URI 도메인을 확인하지 않았기 때문에 해당 관리자는 이와 같은 작업을 할 수 있습니다.

다음으로 그녀는 Webex 앱에 로그인합니다. jane.roe@hacker.com. 해당 관리자가 도메인을 소유하고 있기 때문에 인증 이메일을 읽고 응답한 후 로그인할 수 있습니다. 마지막으로 그녀는 동료인 존 도에게 전화를 걸기 위해 다음 번호를 누릅니다. john.doe@example.com 그녀의 웹엑스 앱에서. 사무실에 있는 John은 비디오 장치에서 jane.roe@example.com(이는 해당 이메일 계정과 연계된 디렉토리 URI임)으로부터 걸려오는 전화를 확인합니다.

John은 "Jane이 출장을 갔나보군." "중요한 일이 있나?" 라고 생각하고 전화에 응답하며, 가짜 Jane Roe가 중요한 문서를 요청합니다. 가짜 Jane은 현재 출장 중인데 장치가 고장났으며, 개인 이메일 주소인 jane.roe@hacker.com으로 해당 문서를 보내 줄 것을 요청합니다. 이러한 방법으로 회사는 실제 Jane Roe가 출근한 후에야 중요한 정보가 외부로 유출되었음을 알게 됩니다.

Example.com은 인터넷을 통해 걸려오는 사기성 전화를 차단하기 위한 다양한 방법을 보유하고 있지만, Webex 클라우드의 책임 중 하나는 Webex에서 전화를 거는 사람의 신원이 정확하고 위조되지 않았는지 확인하는 것입니다.

Webex는 신원 확인을 위해 해당 기업이 하이브리드 통화에 사용되는 도메인을 소유하고 있음을 증명하도록 요구합니다. 그렇지 않으면 하이브리드 서비스가 작동하지 않습니다.

이 소유권을 확인하기 위해 도메인 인증의 두 단계가 필요합니다.

1. 회사에서 이메일 도메인, Expressway-E 도메인, 디렉토리 URI 도메인을 소유하고 있는지 증명합니다.

   • 해당되는 모든 도메인은 라우팅할 수 있으며, 공개 DNS 서버에서 알고 있어야 합니다.

   • 소유권을 증명하기 위해 DNS 관리자는 DNS 텍스트 레코드(TXT)를 입력해야 합니다. TXT 레코드는 DNS에서 호스트 또는 다른 이름과 일부 임의적이고 서식화되지 않은 텍스트를 연계하는 기능을 제공하기 위해 사용되는 리소스 레코드의 유형입니다.

   • DNS 관리자는 누구의 소유권이 증명되어야 하는지 영역에 TXT 레코드를 입력해야 합니다. 그 단계가 끝나면 Webex 클라우드는 해당 도메인에 대한 TXT 레코드 쿼리를 수행합니다.

   • TXT 쿼리가 성공하고 결과가 Webex 클라우드에서 생성된 토큰과 일치하면 도메인이 인증됩니다.

   • 예를 들어, 관리자는 Webex 하이브리드 서비스를 자신의 도메인 "example.com"에서 사용하려면 해당 도메인의 소유권을 증명해야 합니다.

   • 그녀는 https://admin.webex.com를 통해 Webex 클라우드에서 생성된 토큰과 일치하는 TXT 레코드를 생성하여 검증 프로세스를 시작합니다.

     

   • DNS 관리자는 다음 예시와 같이 해당 도메인에 대해 값을 123456789abcdef123456789abcdef123456789abcdef123456789abcdef로 설정한 TXT 레코드를 생성합니다.

     

   • 이 단계에서 클라우드는 도메인 example.com에 대한 TXT 레코드가 토큰과 일치하는지 확인할 수 있습니다.

   • 클라우드는 TXT DNS 조회를 실행합니다.

     

   • TXT 값이 토큰 값과 일치하기 때문에 이 일치 작업은 관리자가 공개 DNS에 사용자 자신의 도메인에 대한 TXT 레코드를 추가했으며, 해당 사용자가 도메인을 소유하고 있음을 증명합니다.

2. Expressway-E DNS 이름 소유권 확인하기.

   • 클라우드는 Expressway-E가 클라우드에서 신뢰하는 인증 기관 중 하나에서 확인된 아이덴티티를 갖고 있는지 확인해야 합니다. Expressway-E 관리자는 Expressway-E에 대해 해당 인증 기관 중 하나로 공개 인증서를 요청해야 합니다. 인증서를 발행하려면 도메인 유효성 검증 확인(도메인 유효성이 검증된 인증서) 또는 조직 유효성 검증 확인(조직 유효성이 검증된 인증서)에 기반하여 인증 기관에서 아이덴티티 인증 프로세스를 실행해야 합니다.

   • 클라우드에서 발신 및 수신되는 통화는 Expressway-E에 발행된 인증서에 따라 다릅니다. 인증서가 유효하지 않은 경우, 통화는 끊깁니다.

하이브리드 통화 기능을 사용하려면 Webex 장치 커넥터가 Webex와 통신해야 합니다.

Webex Device Connector는 내부 네트워크에 배포되며, 클라우드와의 통신은 웹 서버에 연결하는 모든 브라우저에서 사용하는 것과 동일한 유형의 아웃바운드 HTTPS 연결을 통해 이루어집니다.

Webex 클라우드와의 통신에는 TLS가 사용됩니다. Webex Device Connector는 TLS 클라이언트이고, Webex 클라우드는 TLS 서버입니다. 따라서 Webex Device Connector는 서버 인증서를 확인합니다.

인증 기관은 자신의 비공개 키를 사용하여 서버 인증서에 서명합니다. 공개 키가 있는 사용자는 해당 서명을 디코딩하고 동일한 인증 기관이 해당 인증서에 서명했는지 증명할 수 있습니다.

Webex Device Connector가 클라우드에서 제공하는 인증서를 검증해야 하는 경우, 해당 인증서에 서명한 인증 기관의 공개 키를 사용하여 서명을 해독해야 합니다. 공개 키는 인증 기관의 인증서에 포함되어 있습니다. 클라우드에서 사용하는 인증 기관과의 신뢰를 설정하려면 이러한 신뢰할 수 있는 인증 기관의 인증서 목록이 Webex Device Connector 신뢰 저장소에 있어야 합니다.

기기와 통신할 때, 이 도구는 사용자가 제공하는 신뢰할 수 있는 인증서를 사용합니다. 현재로서는 그것들을 대괄호 [home folder]/.devicestool/certs([]) 안에 넣는 것이 그 방법입니다.

인증 기관 인증서의 목록은 순회 페어에서 Expressway-E를 요구합니다. Expressway-E는 상호 인증을 통해 TLS를 사용하는 SIP 프로토콜을 이용하여 Webex 클라우드와 통신합니다. Expressway-E는 클라우드에서 들어오고 나가는 통화를 클라우드와의 TLS 연결 설정 중에 클라우드에서 제공하는 인증서의 CN 또는 SAN이 Expressway의 DNS 영역에 대해 구성된 주체 이름("callservice.webex.com")과 일치하는 경우에만 신뢰합니다. 인증 기관은 아이덴티티 확인 후에만 인증서를 릴리즈합니다. callservice.webex.com 도메인의 소유권을 증명해야 인증서에 서명할 수 있습니다. 저희(시스코)가 해당 도메인을 소유하고 있기 때문에 DNS 이름 "callservice.webex.com"은 원격 서버가 실제로 Webex라는 것을 직접적으로 증명하는 것입니다.

캘린더 커넥터는 가장 계정을 통해 Webex를 Microsoft Exchange 2013, 2016, 2019 또는 Office 365에 통합합니다. Exchange에 있는 응용프로그램 가장 관리 역할은 응용프로그램이 조직에 있는 사용자를 가장하도록 활성화하여 사용자 대신 작업을 실행합니다. 응용 프로그램 가장 역할은 Exchange에 구성되어야 합니다. 및 은(는) Expressway-C 인터페이스에 있는 Exchange 구성의 일부로 캘린더 커넥터에서 사용됩니다.

Exchange 가장 계정은이 작업을 위해 Microsoft에서 권장하는 방법입니다. Expressway-C 관리자는 비밀번호를 알아야 할 필요가 없습니다. 해당 값은 Exchange 관리자가 Expressway-C 인터페이스에 입력할 수 있기 때문입니다. Expressway-C 관리자가 Expressway-C 박스에 대한 루트 액세스를 사용할 수 있더라도 비밀번호는 명확하게 표시되지 않습니다. 비밀번호는 Expressway-C에 있는 다른 비밀번호와 같이 동일한 자격 증명 메커니즘을 사용하여 암호화되어 저장됩니다.

추가 보안을 위해 Cisco Webex 하이브리드 캘린더 서비스의 배포 안내서에 있는 단계를 따라 TLS를 활성화하면 전화에서 보안 EWS 연결을 사용할 수 있습니다.

추가 보안을 위해 Microsoft Exchange용 Expressway 캘린더 커넥터 배포에 있는 단계를 따라 TLS를 활성화하면 전화에서 보안 EWS 연결을 사용할 수 있습니다.