이 섹션은 하이브리드 서비스와 관련된 주요 구성 항목에 대한 추가 컨텍스트를 제공합니다.

Webex 장치용 하이브리드 통화를 성공적으로 배포하려면 이러한 점이 중요해요. 우리는 특히 다음과 같은 이유로 이들 항목을 강조했어요.

• 하이브리드 배포에서 이들의 역할을 이해하고 안심할 수 있도록 설명하려고 해요.

• 클라우드와 온프레미스 환경 간의 안전한 배포를 보장하는 필수 전제 조건이에요.

• 하루 전 제로 활동으로 취급해야 돼요. 일반적인 사용자 인터페이스 구성보다 완료하는 데 시간이 좀 더 걸릴 수 있으니 일정 기간을 두고 항목을 정렬하세요.

• 이러한 항목이 사용자 환경에서 해결되면 나머지 하이브리드 서비스 구성이 순조롭게 진행돼요.

익스프레스웨이-C와 익스프레스웨이-E 페어 배포에서는 방화벽 트래버설 기술을 사용하여 인터넷으로 전화를 걸고 받을 수 있어요. 이 배포는 온-프레미스 통화 제어를 안전하게 가져와 웹엑스에 연결하는 거예요.

익스프레스웨이-C와 익스프레스웨이-E는 방화벽 트래버설 아키텍처 때문에 비무장지대 (DMZ) 방화벽에서 인바운드 포트를 열 필요가 없어요. 하지만 걸려오는 전화를 받으려면 TCP SIP 신호 포트와 UDP 미디어 포트를 인터넷 방화벽에서 인바운드로 열어야 해요. 기업 방화벽에 적절한 포트가 열리려면 시간이 걸려야 해요.

방화벽 트래버설 아키텍처가 다음 다이어그램에 나와 있어요.

예를 들어 SIP 프로토콜을 사용하는 인바운드 B2B (B2B) 통화의 경우 음성, 비디오, 콘텐츠 공유, 듀얼 비디오 등과 같은 서비스에 사용되는 UDP 미디어 포트와 함께 TCP 포트 5060 및 5061 (SIP TLS에 5061이 사용) 을 외부 방화벽에서 열어야 해요. 열 미디어 포트는 동시 통화 수와 서비스 수에 따라 달라요.

고속도로의 SIP 수신 포트를 1024에서 65534 사이의 값으로 구성할 수 있어요. 동시에 이 값과 프로토콜 유형은 공개 DNS SRV 기록에 광고되어야 하고 인터넷 방화벽에서 같은 값을 열어야 해요.

SIP TCP의 표준은 5060이고 SIP TLS 5061의 표준이지만, 다음 예에서 보듯이 다른 포트의 사용을 막는 것은 없어요.

예시

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

고속도로 서버 두 대 클러스터 DNS SRV 기록은 다음과 같아요.

_모금._tcp.example.com SRV 서비스 위치:

priority = 10

weight = 10

port = 5062

svr 호스트 이름 = us-expe1.example.com

_모금._tcp.example.com SRV 서비스 위치:

priority = 10

weight = 10

port = 5062

svr 호스트 이름 = us-expe2.example.com

이러한 기록을 보면 TLS를 전송 유형으로 사용하고 5062를 수신 포트 번호로 사용하여 동일한 부하 공유 (우선 순위 및 가중치) 로 통화가 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라고 하며 웹엑스와 통합할 때 필요해요.

다음 다이어그램에서 보듯이 발신자와 수신자 모두 상대 피어의 인증서를 확인해요.

클라우드는 고속도로 ID를 검사하고 고속도로는 클라우드 ID를 확인해요. 예를 들어 인증서의 클라우드 ID (CN 또는 SAN) 가 고속도로에서 구성된 것과 일치하지 않으면 연결이 끊어져요.

상호 인증이 켜져 있으면 익스프레스웨이-E는 항상 클라이언트 인증서를 요청해요. 결과적으로 모바일 및 Remote Access (MRA) 는 작동하지 않아요. 대부분의 경우 인증서가 Jabber 클라이언트에 배포되지 않기 때문이죠. B2B 시나리오에서 전화 주체가 인증서를 제공하지 못하면 통화 연결이 끊어져요.

상호 인증을 사용하는 TLS에는 5061 이외의 값 (예: 포트 5062) 을 사용하는 것이 좋습니다. 웹엑스 하이브리드 서비스는 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, 모바일 Remote Access 및 Webex 트래픽

기업 간 거래 (B2B) 및 모바일 및 Remote Access (MRA) 통화는 SIP TLS에 포트 5061을 사용하고 웹엑스 트래픽은 상호 인증을 사용하는 SIP TLS에 포트 5062를 사용해요.

도메인 소유권 확인은 신원 확인의 일부예요. 도메인 인증은 자신이 누구인지 증명하기 위해 Webex 클라우드가 구현하는 보안 조치 및 신원 확인이에요.

신원 확인은 두 단계로 수행돼요.

1. 도메인 소유권 확인. 이 단계에는 세 가지 유형의 도메인이 포함되고 일회성 확인 검사예요.

   • 이메일 도메인

   • 익스프레스웨이-E DNS 도메인

   • 디렉토리 URI 도메인

2. 익스프레스웨이-E DNS 이름 소유권 확인. 이 단계는 상호 인증을 사용하는 TLS 구현을 통해 수행되며 클라우드와 고속도로 모두에서 공인 인증서를 사용해요. 도메인 ID 검사와는 다르게, 이 단계는 클라우드로 전화를 걸고 클라우드에서 받는 동안 수행돼요.

도메인 소유권 검사의 중요성

Webex 클라우드는 보안을 강화하기 위해 도메인 소유권 검사를 수행해요. 이 검사를 수행하지 않을 경우 신원 도용은 가능한 위협 중 하나예요.

다음 이야기는 도메인 소유권 검사를 수행하지 않을 경우 일어날 수 있는 일을 자세히 설명해요.

DNS 도메인이 “hacker.com”으로 설정된 회사가 웹엑스 하이브리드 서비스를 구매해요. 자체 도메인이 “example.com”으로 설정된 다른 회사도 하이브리드 서비스를 사용하고 있어요. Example.com 회사의 제너럴 매니저 중 한 명이 제인 로이고 디렉토리 URI가 jane.roe@example.com 이에요.

Hacker.com 회사 관리자가 디렉토리 URI 중 하나를 jane.roe@example.com 으로 설정하고 이메일 주소를 jane.roe@hacker.com 으로 설정했어요. 이 예시에서 클라우드가 SIP URI 도메인을 확인하지 않기 때문에 그녀가 그렇게 할 수 있어요.

다음으로, 그녀는 jane.roe@hacker.com 으로 웹엑스 앱에 로그인해요. 그녀가 도메인을 소유하고 있기 때문에 확인 이메일을 읽고 답장을 받고 로그인할 수 있어요. 드디어 그녀가 웹엑스 앱에서 john.doe@example.com 으로 전화를 걸어 동료 John Doe에게 전화를 걸어요. 존이 사무실에 앉아 있는데 비디오 장치에서 jane.roe@example.com 으로 걸려오는 전화를 봤어요. 그게 그 이메일 계정에 연결된 디렉터리 URI예요.

“그녀는 해외에 있어요.” 그는 생각해요. “걔한테 중요한 게 필요할지도 몰라요.”전화를 받는데 가짜 제인 로가 중요한 서류를 요구해요. 기기가 고장났다고 설명하는데 여행 중이니 개인 이메일 주소인 jane.roe@hacker.com 으로 문서를 보내달라고 부탁해요. 이렇게 해서 회사는 제인 로가 사무실로 돌아와서야 중요한 정보가 회사 외부로 유출되었다는 것을 알게 돼요.

Example.com은 인터넷에서 오는 사기성 전화로부터 보호할 수 있는 여러 가지 방법을 가지고 있지만, Webex 클라우드의 책임 중 하나는 Webex에서 전화하는 모든 사람의 신원이 정확하고 위조가 아닌지 확인하는 것입니다.

신원을 확인하려면 웨벡스에서는 회사에서 하이브리드 통화에 사용되는 도메인을 소유하고 있음을 증명할 것을 요구해요. 안 되면 하이브리드 서비스가 안 돼요.

소유권을 보장하려면 두 가지 도메인 인증 단계가 필요해요.

1. 회사가 이메일 도메인, 익스프레스웨이-E 도메인, 디렉토리 URI 도메인을 소유하고 있다는 것을 증명하세요.

   • 모든 도메인은 라우팅이 가능해야 하고 공용 DNS 서버에 알려져야 해요.

   • 소유권을 증명하려면 DNS 관리자가 DNS 텍스트 레코드 (TXT) 를 입력해야 해요. TXT 레코드는 형식화되지 않은 임의의 텍스트를 호스트나 다른 이름과 연결하는 기능을 제공하는 데 사용되는 DNS의 리소스 레코드 유형이에요.

   • DNS 관리자가 소유권을 증명해야 하는 영역에 TXT 레코드를 입력해야 해요. 그 단계가 끝나면 Webex 클라우드가 해당 도메인에 대해 TXT 레코드 쿼리를 수행해요.

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

   • 예를 들어, 관리자가 자신의 도메인에서 Webex 하이브리드 서비스를 작동시키려면 관리자가 자신이 “example.com” 도메인을 소유하고 있음을 증명해야 해요.

   • https://admin.webex.com 통해 그녀는 Webex 클라우드가 생성한 토큰과 일치하는 TXT 레코드를 생성하여 인증 프로세스를 시작해요.

     

   • 그러면 DNS 관리자가 값을 123456789abcdef123456789abcdef123456789abcdef123456789abcdef123456789abcdef123456789abcdef로 설정하여 이 도메인에 TXT 레코드를 생성해요.

     

   • 이때 클라우드는 example.com 도메인의 TXT 레코드가 토큰과 일치하는지 확인할 수 있어요.

   • 클라우드가 TXT DNS 조회를 수행해요:

     

   • TXT 값이 토큰 값과 일치하기 때문에 이 일치 항목은 관리자가 자신의 도메인에 대한 TXT 레코드를 퍼블릭 DNS에 추가했고 관리자가 도메인을 소유하고 있다는 것을 증명해요.

2. 익스프레스웨이-E DNS 이름 소유권 확인.

   • 클라우드는 Expresway-E가 클라우드가 신뢰하는 인증 기관으로부터 확인된 ID를 가지고 있는지 확인해야 해요. 익스프레스웨이-E 관리자가 그 인증 기관 중 한 곳에 익스프레스웨이-E 공인 인증서를 요청해야 해요. 인증서를 발급하기 위해 인증 기관은 도메인 검증 검사 (도메인 검증 인증서의 경우) 또는 조직 검증 검사 (조직 검증 인증서의 경우) 를 기반으로 ID 확인 프로세스를 수행해요.

   • 클라우드로 걸고 받는 통화는 Expresway-E에 발급된 인증서에 따라 달라져요. 인증서가 유효하지 않으면 전화가 끊겨요.

하이브리드 통화가 작동하려면 Webex 장치 커넥터가 Webex와 통신해야 해요.

웹엑스 장치 커넥터는 내부 네트워크에 배포되며 클라우드와 통신하는 방식은 아웃바운드 HTTPS 연결을 통해서예요. 웹 서버에 연결하는 모든 브라우저에 사용되는 것과 같은 유형이에요.

Webex 클라우드와 통신은 TLS를 사용해요. 웹엑스 장치 커넥터는 TLS 클라이언트이고 웹엑스 클라우드는 TLS 서버예요. 따라서, 웹엑스 장치 커넥터는 서버 인증서를 확인해요.

인증 기관이 자체 개인 키로 서버 인증서에 서명해요. 공개 키를 가진 사람은 누구나 그 서명을 해독하고 동일한 인증 기관이 인증서에 서명했다는 것을 증명할 수 있어요.

Webex Device Connector가 클라우드에서 제공한 인증서를 검증해야 하는 경우, 인증서에 서명한 인증 기관의 공개 키를 사용하여 서명을 디코딩해야 해요. 공개 키는 인증 기관 인증서에 들어 있어요. 클라우드에서 사용하는 인증 기관과 신뢰를 설정하려면 이러한 신뢰할 수 있는 인증 기관의 인증서 목록이 Webex Device Connector 신뢰 저장소에 있어야 해요.

장치와 통신할 때 도구는 당신이 제공한 신뢰할 수 있는 인증서를 사용해요. 지금은 그걸 배치하는 방법이 돼요 [home folder]/.devicestool/certs.

트래버설 페어의 익스프레스웨이-E에는 인증 기관 인증서 목록도 필요해요 . 익스프레스웨이-E는 상호 인증으로 적용되는 SIP와 TLS를 사용하여 Webex 클라우드와 통신해요. 익스프레스웨이-E는 TLS 연결 설정 시 클라우드가 제공하는 인증서의 CN 또는 SAN이 고속도로의 DNS 영역에 구성된 제목 이름과 일치하는 경우에만 클라우드에서 오고 가는 전화를 신뢰해요 (“callservice.webex.com”). 인증 기관은 신원 확인 후에만 인증서를 공개해요. 인증서에 서명하려면 callservice.webex.com 도메인의 소유권을 증명해야 해요. 우리 (시스코) 가 그 도메인을 소유하고 있기 때문에 “callservice.webex.com”이라는 DNS 이름은 원격 피어가 진정한 웹엑스라는 직접적인 증거예요.

캘린더 커넥터는 사칭 계정을 통해 웹엑스를 Microsoft Exchange 2013, 2016, 2019 또는 오피스 365와 통합해요. Exchange의 응용 프로그램 사칭 관리 역할을 사용하면 응용 프로그램이 조직의 사용자를 가장하여 사용자를 대신하여 작업을 수행할 수 있어요. 응용 프로그램 사칭 역할은 Exchange에서 구성해야 하고 캘린더 커넥터에서 Expresway-C 인터페이스의 교환 구성의 일부로 사용돼요.

이 작업에는 마이크로소프트가 Exchange 사칭 계정을 추천하는 방법이에요. 익스프레스웨이-C 관리자는 암호를 알 필요가 없어요. Exchange 관리자가 익스프레스웨이-C 인터페이스에 값을 입력할 수 있으니까요. 익스프레스웨이-C 관리자가 익스프레스웨이-C 박스에 대한 루트 액세스 권한을 가지고 있더라도 암호는 명확하게 표시되지 않아요. 비밀번호는 Expresway-C의 다른 비밀번호와 동일한 자격 증명 암호화 메커니즘을 사용하여 암호화되어 저장돼요.

보안을 강화하려면 Cisco Webex하이브리드 캘린더 서비스용 배포 안내서의 단계에 따라 TLS를 활성화하여 유선 EWS 연결을 보호하세요.

보안을 강화하려면 고속도로 캘린더 커넥터 배포에 있는 단계를 따라 TLS를 Microsoft Exchange 활성화해 유선상의 EWS 연결을 보호하세요.