Expressway-C 및 Expressway-E 페어 배포는 방화벽 순회 기술을 사용하여 통화가 인터넷에서 수신, 발신되도록 허용합니다. 이 배포는 온-프레미스 통화 제어를 안전하게 실행하고 Cisco 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 service location:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

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 및 Cisco Webex 클라우드 간에 설정된 통화 등 서버 간 연결에 있어 유용합니다. 이 개념은 상호 인증을 사용하는 TLS로 지칭하며, Cisco Webex에 통합할 때 필요합니다.

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

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

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

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

동일한 Expressway 페어에서 비즈니스 간, 모바일 및 Remote Access, Cisco Webex 트래픽

비즈니스 간 및 모바일 및 Remote Access 통화는 SIP TLS에 대해 포트 5061을 사용하며, Cisco Webex 트래픽은 상호 인증이 포함된 SIP TLS에 대해 포트 5062를 사용합니다.

도메인 소유권 확인은 아이덴티티 인증의 일부입니다. 도메인 인증은 Cisco Webex 클라우드에서 귀하가 실제 본인인지 증명하기 위해 실행하는 보안 측정이며, 아이덴티티 확인입니다.

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

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

   • 이메일 도메인

   • Expressway-E DNS 도메인

   • 디렉터리 URI 도메인

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

도메인 소유권 확인의 중요성을 보여주는 스토리

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

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

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

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

그 후 jane.roe@hacker.com으로 Cisco Webex Teams에 로그인합니다. 해당 관리자가 도메인을 소유하고 있기 때문에 인증 이메일을 읽고 응답한 후 로그인할 수 있습니다. 마지막으로, Cisco Webex Teams 앱에서 john.doe@example.com으로 다이얼하여 동료인 John Doe에게 전화를 겁니다. 사무실에 있는 John은 비디오 장치에서 jane.roe@example.com(해당 이메일 계정과 연계된 디렉터리 URI)으로부터 걸려오는 전화를 확인합니다.

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

회사 Example.com은 인터넷에서 걸려오는 사기적인 통화로부터 자사를 보호할 수 있는 많은 방법이 있습니다. Cisco Webex 클라우드의 책임 중 하나는 Cisco Webex로부터 걸려오는 전화의 사용자에 대한 아이덴티티가 올바른지, 위조된 것이 아닌지를 확인하는 것입니다.

아이덴티티를 확인하기 위해 Cisco Webex는 해당 회사에서 하이브리드 통화에 사용된 도메인을 소유하고 있는지 증명하도록 요구합니다. 소유하고 있지 않은 경우, 은(는) 작동하지 않게 됩니다.

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

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

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

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

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

   • TXT 쿼리가 성공적으로 실행되고 결과가 Cisco Webex 클라우드에서 생성된 토큰과 일치하는 경우에 해당 도메인은 인증됩니다.

   • 예를 들어, 관리자는 사용자가 자신의 도메인에서 Cisco Webex 하이브리드 서비스를 작동하게 하려는 경우에 해당 사용자가 도메인 "example.com"을 소유하고 있는지 증명해야 합니다.

   • https://admin.webex.com을(를) 통해 사용자는 Cisco 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에 발행된 인증서에 따라 다릅니다. 인증서가 유효하지 않은 경우, 통화는 끊깁니다.

하이브리드 서비스가 작동하게 하려면 Expressway-C 커넥터 호스트가 Cisco Webex에 등록되어야 합니다.

Expressway-C는 내부 네트워크에 배포되며, 클라우드에 등록하는 방법은 아웃바운드 HTTPS 연결을 통합니다. 이는 웹 서버에 연결하는 브라우저에 대해 사용된 것과 동일한 유형입니다.

Cisco Webex 클라우드에 대한 등록 및 통신은 TLS를 사용합니다. Expressway-C는 TLS 클라이언트이며, Cisco Webex 클라우드는 TLS 서버입니다. 이와 같이 Expressway-C는 서버 인증서를 확인합니다.

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

Expressway-C가 클라우드에서 제공한 인증서의 유효성을 검증해야 하는 경우, 서명을 디코딩하려면 인증서를 서명한 인증 기관의 공개 키를 사용해야 합니다. 공개 키는 인증 기관의 인증서에 포함되어 있습니다. 클라우드에서 사용하는 인증 기관을 신뢰하려면 신뢰하는 해당 인증 기관의 인증서 목록이 Expressway의 신뢰 스토어에 있어야 합니다. 이렇게 하면 Expressway는 해당 통화가 실제로 Cisco Webex 클라우드에서 걸려오는 것으로 인증할 수 있습니다.

수동 업로드를 사용하여 Expressway-C의 신뢰 스토어에 관련된 모든 인증 기관 인증서를 업로드할 수 있습니다.

자동 업로드를 사용하여 Expressway-C의 신뢰 스토어에 클라우드가 직접 해당 인증서를 업로드하도록 할 수 있습니다. 자동 업로드를 사용할 것을 권장합니다. 인증서 목록은 변경될 수도 있으며, 자동 업로드는 가장 업데이트된 목록이 유지되도록 보장합니다.

인증 기관 인증서의 자동 설치를 허용하는 경우, https://admin.webex.com(관리 포털)로 리디렉션됩니다. 리디렉션은 사용자가 실행하지 않아도 Expressway-C에서 직접 실행합니다. Cisco Webex 관리자인 귀하는 HTTPS 연결을 통해 인증해야 합니다. 그 후 곧 클라우드에서 CA 인증서를 Expressway-C로 푸시합니다.

인증서가 Expressway-C 신뢰 스토어에 업로드될 때까지 HTTPS 연결을 시작할 수 없습니다.

이 문제를 예방하기 위해 Expressway-C는 Cisco Webex-신뢰하는 CA 인증서를 포함하여 미리 설치됩니다. 해당 인증서는 첫 HTTPS 연결을 설정하고 유효성을 검증하기 위해서만 사용되며, Expressway-C 신뢰 목록에 나타나지 않습니다. 신뢰하는 인증 기관의 인증서가 이 첫 HTTPS 연결을 통해 클라우드로부터 축출되면 해당 인증서는 플랫폼 전반에서 사용할 수 있습니다. 그 후 Expressway-C 신뢰 목록에 나타납니다.

이 목록은 현재 Cisco Webex 클라우드에서 사용하는 인증 기관 인증서를 표시합니다. 이 목록은 향후에 변경될 수도 있습니다.

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

인증 기관 인증서의 목록은 순회 페어에서 Expressway-E를 요구합니다. Expressway-E는 SIP와 TLS(상호 인증에서 강제함)를 사용하여 Cisco Webex 클라우드와 통신합니다. Expressway-E는 TLS 연결 설치 중에 클라우드에서 표시하는 인증서의 CN 또는 SAN이 Expressway에서 DNS 영역에 대해 구성된 주체명과 일치하는 경우에만("callservice.webex.com") 클라우드로부터 걸려오는 전화 및 거는 전화를 신뢰합니다. 인증 기관은 아이덴티티 확인 후에만 인증서를 릴리즈합니다. 서명된 인증서를 확보하려면 callservice.webex.com 도메인의 소유권이 증명되어야 합니다. Cisco에서 해당 도메인을 소유하고 있기 때문에 DNS 이름 "callservice.webex.com"은(는) 해당 원격 피어가 실제 Cisco Webex임에 대한 직접적인 증명입니다.

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

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

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