통합 메시징 VoIP 보안 이해

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

네트워크 보안에서 중요한 한 가지 측면은 UM(통합 메시징) 인프라를 보호하는 기능입니다. 통합 메시징 환경 내에는 네트워크의 통합 메시징 서버를 통해 주고받는 데이터를 보호하기 위해 올바르게 구성해야 하는 구성 요소가 있습니다. 여기에는 통합 메시징 서버와 다이얼 플랜 같은 구성 요소가 포함됩니다. 이 항목에서는 조직의 통합 메시징 네트워크 데이터 및 서버에 대한 보호 기능을 강화할 수 있는 방법에 대해 설명합니다. 통합 메시징 환경을 안전하게 보호하고 VoIP(Voice over IP) 보안을 사용할 수 있도록 하려면 다음 단계를 수행해야 합니다.

1. 통합 메시징 서버 역할을 설치합니다.

2. 상호 TLS에 사용할 수 있는 자체 서명된 인증서 또는 공용 인증서를 새로 만듭니다.

3. 인증서를 UM 서버와 연결합니다.

4. UM 다이얼 플랜을 SIP 보안 또는 보안으로 구성합니다.

5. UM 서버에서 시작 모드를 구성합니다.

6. 통합 메시징 서버를 UM 다이얼 플랜에 연결합니다.

7. FQDN(정규화된 도메인 이름)을 갖고 TCP 포트 5061을 사용하기 위해 사용되는 UM IP 게이트웨이를 구성합니다.

8. 통합 메시징 서버, IP 게이트웨이, IP PBX(IP Private Branch eXchange) 및 Microsoft Exchange Server 2010을 실행하는 그 밖의 서버에서 상호 TLS(상호 전송 계층 보안)를 사용할 수 있도록 필요한 인증서를 내보내고 가져옵니다.

목차

통합 메시징 보호

인증서 종류

상호 TLS 구성

IPsec

UM 다이얼 플랜 및 VoIP 보안

통합 메시징의 보안 모드 확인 및 인증서 선택 방법

통합 메시징 보호

IP 게이트웨이와 통합 메시징 서버 간에 전송되고 통합 메시징 서버와 조직의 다른 Exchange 2010 서버 간에 전송되는 통합 메시징 서버 및 네트워크 트래픽을 보호할 수 있는 보안 방법이 몇 가지 있습니다. 다음 표에서는 통합 메시징 인프라와 해당 인프라를 보호하는 데 도움을 주기 위해 구현할 수 있는 보안 방법에 위협이 될 수 있는 몇 가지 요소를 나열합니다.

통합 메시징 보호

보호가 필요한 상황	보호 방법
음성 트래픽 모니터링	IPsec(인터넷 프로토콜 보안)을 사용합니다. IP 게이트웨이나 IP PBX가 IPsec을 지원해야 합니다. SRTP(Secure Realtime Transport Protocol)를 사용합니다.
IP 게이트웨이 또는 IP PBX에 대한 공격	강력한 인증 방법을 사용합니다. 강력한 관리자 암호를 사용합니다. SSL(Secure Sockets Layer)을 사용하여 관리자 자격 증명을 보호합니다. IP 게이트웨이나 IP PBX가 SSL을 지원해야 합니다. 텔넷 대신 SSH(Secure Shell)를 사용합니다.
허가되지 않은 시외 전화	UM 다이얼 플랜 규칙과 전화 걸기 제한을 사용합니다. 이러한 사항은 UM 다이얼 플랜과 UM 사서함 정책에 구성할 수 있습니다. PBX를 구성하여 다른 전화 걸기 제한을 적용할 수도 있습니다.
서비스 거부 공격	통합 메시징 서버는 신뢰할 수 있는 VoIP 장치 또는 서버 목록에 포함된 UM IP 게이트웨이나 IP PBX와만 통신합니다. 신뢰할 수 있는 이 VoIP 장치 또는 서버 목록은 Active Directory 디렉터리 서비스에 UM IP 게이트웨이가 만들어질 때 생성됩니다. 상호 TLS를 사용합니다.
SIP(Session Initiation Protocol) 프록시 가장	상호 TLS를 사용합니다. IPsec을 사용합니다. IP 게이트웨이나 IP PBX가 IPsec을 지원해야 합니다. VLAN(가상 LAN)과 같은 신뢰할 수 있는 LAN, 전용 WAN 회로 또는 VPN(가상 사설망)을 구성합니다.
도청 및 세션 강탈	상호 TLS를 사용하여 신호 도청을 줄입니다. IPsec을 사용합니다. IP 게이트웨이나 IP PBX가 IPsec을 지원해야 합니다. VLAN과 같은 신뢰할 수 있는 LAN, 전용 WAN 회로 또는 VPN을 구성합니다.

이전 표에는 통합 메시징 환경을 보호하는 데 사용할 수 있는 보안 방법이 몇 가지 나와 있습니다. 통합 메시징에서 생성되는 네트워크 트래픽과 통합 메시징 인프라를 보호하기 위한 가장 중요한 메커니즘 중 하나는 상호 TLS입니다.

상호 TLS를 사용하여 IP 게이트웨이, IP PBX 및 그 밖의 Exchange 2010 서버와 네트워크의 통합 메시징 서버 사이에 전달되는 VoIP(Voice over IP) 트래픽을 암호화할 수 있습니다. 이 데이터를 보호하기 위한 가장 좋은 방법은 상호 TLS를 사용하여 VoIP 데이터를 암호화하는 것입니다.

그러나 보안 위협에 따라 IP 게이트웨이나 IP PBX와 통합 메시징 서버 간 또는 통합 메시징 서버와 네트워크의 다른 Exchange 2010 서버 간에 데이터 암호화를 사용하도록 IPsec 정책을 구성할 수도 있습니다. 일부 환경에서는 IPsec을 사용할 수 없거나 또는 IP 게이트웨이나 IP/PBX에서 IPsec이 지원되지 않기 때문에 IPsec을 사용할 수 없는 경우도 있습니다. 뿐만 아니라 IPsec은 통합 메시징 서버의 시스템 리소스에 처리 부하를 가중시킵니다. 이러한 두 가지 사항을 고려할 경우 상호 TLS는 통합 메시징 환경에서 VoIP 네트워크 트래픽을 보호하는 가장 좋은 방법입니다.

상호 TLS를 올바르게 구현하고 구성한 경우에는 IP 게이트웨이 간, IP PBX 간, 그리고 다른 Exchange 서버에서 통합 메시징 서버로 전송되는 VoIP 트래픽이 암호화됩니다. 그러나 통합 메시징 서버와 주고받는 트래픽의 보안을 유지하는 데 상호 TLS를 사용할 수 없는 경우, 예를 들어, 통합 메시징 서버가 네트워크의 다른 서버(예: Active Directory 도메인 컨트롤러나 Exchange 2010 사서함 서버)와 통신하는 경우 데이터를 보호하는 데 다른 유형의 암호화가 사용됩니다. 다음 그림에서는 통합 메시징을 보호하는 데 사용할 수 있는 암호화 방법을 보여 줍니다.

UM VoIP 보안

맨 위로 이동

인증서 종류

디지털 인증서는 사용자나 컴퓨터의 ID를 확인하는 온라인 여권 같은 역할을 하는 전자 파일로, 데이터 보호에 사용되는 암호화된 채널을 만드는 데 사용됩니다. 인증서는 기본적으로 인증 기관(CA)에서 인증서 소유자의 신원을 보증하기 위해 발급한 디지털 내역서이며 이 인증서를 통해 해당 당사자들은 암호화를 사용하여 안전한 방식으로 통신할 수 있습니다. 인증서는 신뢰 받은 제3자 CA가 발급(예: 인증서 서비스)하거나 자체 서명할 수 있습니다. 인증서의 종류마다 그에 해당하는 장단점이 있습니다. 그러나 인증서는 위조할 수 없도록 변조 방지되어 있습니다. 웹 사용자 인증, 웹 서버 인증, S/MIME, IPsec, TLS 및 코드 서명 등 다양한 기능의 인증서를 발급할 수 있습니다.

인증서는 공개 키를 해당 개인 키를 소유하는 사용자, 컴퓨터 또는 서비스의 ID에 바인딩합니다. 클라이언트와 서버에서 회선을 통해 데이터를 전송하기 전에 데이터를 먼저 암호화할 때 공개 키와 개인 키가 사용됩니다. 인터넷 등의 네트워크를 통한 보안 통신 기능, 데이터 무결성 및 인증을 제공하는 다양한 공개 키 보안 서비스 및 응용 프로그램에서 인증서를 사용합니다. Windows 기반 사용자, 컴퓨터, 서비스의 경우 신뢰할 수 있는 루트 저장소에 루트 인증서 사본이 있고 인증서에 올바른 인증 경로가 있으면 CA에 대한 신뢰가 설정됩니다. 이는 인증 경로에 해지되거나 유효 기간이 만료된 인증서가 없는 것을 의미합니다.

디지털 인증서를 사용하여 다음을 수행할 수 있습니다.

• 인증서 소유자, 즉 사용자, 웹 사이트, 심지어는 라우터 같은 네트워크 리소스가 실제로 해당 본인 또는 대상이 맞는지 인증합니다.

• 온라인으로 교환되는 데이터의 도용 또는 변조로부터 보호합니다.

일반적으로 통합 메시징과 IP 게이트웨이 또는 IP PBX에서 사용할 수 있는 인증서에는 세 가지가 있습니다. 세 가지 경우 모두 인증서 소유자의 공개 키는 상대편의 서버, 사용자, 웹 사이트 또는 그 밖의 리소스가 메시지의 암호를 해독할 수 있도록 인증서에 포함되어 있습니다. 개인 키는 인증서 서명자에게만 공개됩니다. 인증서마다 인증서의 특정 용도를 나타내도록 EnhancedKeyUsage 특성이 설정되어 있습니다. 예를 들어 서버 인증 전용 또는 파일 암호화 시스템에서 사용하기 위한 용도로 지정할 수 있습니다. 통합 메시징에서는 서버 인증 및 데이터 암호화 용도로 인증서를 사용합니다.

자체 서명 인증서

자체 서명 인증서는 생성자가 직접 서명한 인증서입니다. 인증서 제목과 이름이 일치합니다. 자체 서명 인증서에서는 발급자와 제목이 인증서에 정의되어 있습니다. 자체 서명 인증서에는 해당 조직이나 제3자의 CA가 필요 없습니다. 인증서를 발급한 통합 메시징 서버에서 이러한 인증서를 신뢰하도록 하려면 인증서를 명시적으로 구성하여 각 IP 게이트웨이, IP PBX, 그 밖의 통합 메시징 서버 및 기타 Exchange 2010 컴퓨터의 신뢰할 수 있는 루트 인증서 저장소에 복사해야 합니다.

PKI(공개 키 인프라) 기반 인증서나 제3자 인증서를 사용할 수 없으면 통합 메시징 서버가 로컬 인증서 저장소에서 자체 서명 인증서를 검색합니다. PKI 또는 타사 인증서를 찾지 못하면 상호 TLS를 위한 자체 서명 인증서를 생성합니다. 그러나 자체 서명 인증서의 경우 네트워크의 IP 게이트웨이, IP PBX 또는 네트워크의 다른 서버에서 신뢰하지 않습니다. 자체 서명 인증서를 IP 게이트웨이, IP PBX 또는 그 밖의 서버에서 신뢰할 수 있도록 하려면 자체 서명 인증서를 장치와 서버에 대한 신뢰할 수 있는 루트 인증서의 로컬 저장소로 가져와야 합니다. 그런 다음 통합 메시징 서버에서 이 자체 서명 인증서를 IP 게이트웨이, IP PBX 또는 서버에 제공하면 발급자가 자체 서명 인증서에 정의된 제목과 같아지므로 신뢰할 수 있는 기관에서 발급한 인증서임을 확인할 수 있습니다.

자체 서명 인증서만 사용할 경우에는 각 IP 게이트웨이, IP PBX 또는 서버마다 자체 서명 인증서를 하나씩 가져와야 합니다. 장치나 컴퓨터가 여러 개 있는 대규모 네트워크 환경에서는 이 방법이 상호 TLS를 구현하는 것이 가장 좋은 방법이 아닐 수도 있습니다. 대규모 엔터프라이즈 네트워크에서 자체 서명 인증서를 사용하면 관리 오버헤드가 가중되므로 적합하지 않습니다. 그러나 여러 장치를 사용하면서 PKI 또는 상업용 제3자 인증서를 사용하는 경우에는 관리 오버헤드가 발생해도 문제가 되지 않습니다. 신뢰할 수 있는 동일한 루트 인증 기관에서 발급한 인증서가 각 장치마다 있기 때문입니다. 신뢰할 수 있는 동일한 루트 인증 기관에서 발급한 인증서를 사용하면 모든 IP 게이트웨이, IP PBX 및 그 밖의 서버에서 통합 메시징 서버를 신뢰하게 됩니다.

자체 서명 인증서를 사용하여 상호 TLS를 실행하기 위해서는 다음을 수행해야 합니다.

1. 통합 메시징 서버의 자체 서명 인증서를 각 IP 게이트웨이, IP PBX 및 통합 메시징 서버가 상호 TLS를 사용하여 통신하는 기타 서버에 있는 신뢰할 수 있는 루트 인증서 저장소로 가져옵니다.

2. 자체 서명 인증서를 각 IP 게이트웨이, IP PBX 및 그 밖의 서버에서 통합 메시징 서버의 신뢰할 수 있는 루트 인증서 저장소로 가져옵니다. PKI나 제3자 인증서를 사용하는 경우에는 인증 기관의 인증서를 모든 장치 및 서버의 신뢰할 수 있는 루트 인증서 저장소로 가져옵니다.

상호 TLS 또는 인증서 기반 인증을 배포할 때는 자체 서명 인증서가 가장 좋은 인증서 옵션이 아닐 경우가 많습니다. 그러나 장치나 컴퓨터 수가 제한된 소규모 조직에서는 상호 TLS를 구현할 때 비용이 가장 적게 들고 구성이 가장 쉬운 자체 서명 인증서 방법을 사용하도록 결정할 수 있습니다. 소규모 조직에서는 관리자가 인증서 계층 구조를 직접 만들 수 있는 지식과 경험이 부족하거나 아니면 비용 때문에 또는 두 가지 이유 모두로 인해 제3자 인증서를 사용하지 않도록 결정하거나 인증서를 직접 발급하기 위한 PKI를 설치하도록 결정하는 경우가 많습니다. 자체 서명 인증서를 사용할 경우 설치가 간단하고 비용도 최소한으로 유지됩니다. 그러나 자체 서명 인증서의 경우 인증서 수명 주기 관리, 갱신, 신뢰 관리 및 해지를 위한 인프라를 설정하기가 훨씬 더 어렵습니다. TLS에 대한 인증서를 만드는 방법에 대한 자세한 내용은 TLS 인증서 이해를 참조하십시오.

맨 위로 이동

공개 키 인프라

PKI는 공개 키 암호화를 사용하여 전자 거래에서 각 당사자의 유효성을 확인 및 인증하는 디지털 인증서, CA 및 RA(등록 기관)로 구성되는 시스템입니다. Active Directory를 사용하는 조직에 CA를 구현할 때는 인증서 수명 주기 관리, 갱신, 신뢰 관리 및 해지를 위한 인프라를 제공합니다. 이를 통해 조직의 모든 인증서에 대한 확실한 인프라가 구축됩니다. 그러나 이러한 종류의 인증서를 만들고 관리하려면 서버 및 인프라를 추가로 배포해야 하므로 약간의 비용이 듭니다.

도메인의 어떤 서버에나 인증서 서비스를 설치할 수 있습니다. 도메인 Windows 기반 CA에서 인증서를 받으면 해당 CA를 사용하여 네트워크에서 사용 중인 서버나 컴퓨터에 발급할 인증서를 요청하거나 서명할 수 있습니다. 따라서 타사 인증서 공급업체를 사용하는 것과 비슷하지만 비용이 저렴한 PKI를 사용할 수 있습니다. 다른 종류의 인증서를 공개적으로 배포할 수 있는 것처럼 이러한 PKI를 배포할 수는 없지만 PKI가 사용되면 CA가 개인 키를 사용하여 요청자의 인증서에 서명하고 해당 요청자가 확인됩니다. 이 CA의 공개 키는 CA에서 발급하는 인증서에 포함됩니다. 이 CA 인증서를 루트 인증서로 사용하는 사람은 누구나 해당 공개 키를 사용하여 요청자의 인증서 암호를 해독하고 요청자를 인증할 수 있습니다.

PKI 인증서를 사용하여 상호 TLS를 구현할 때는 필요한 인증서를 IP 게이트웨이나 IP PBX에 복사해야 합니다. 그런 다음 IP 게이트웨이나 IP PBX의 인증서를 보안 모드로 구성된 UM 다이얼 플랜에 연결되어 있는 통합 메시징 서버에 복사해야 합니다.

PKI 인증서와 타사 인증서 사용을 위한 설치 및 구성 과정은 자체 서명 인증서를 가져오고 내보낼 때 수행하는 절차와 비슷합니다. 그러나 트러스트된 루트 인증서 저장소에 컴퓨터 인증서를 설치해야 할 뿐 아니라 PKI에 대해 트러스트된 루트 인증서를 네트워크의 통합 메시징 서버와 IP 게이트웨이 및 IP PBX에 있는 트러스트된 루트 인증서 저장소로 가져오거나 복사해야 합니다.

PKI 인프라를 이미 배포한 상태에서 상호 TLS를 배포하려면 다음 단계를 수행합니다.

1. 각 IP 게이트웨이나 PBX에 대한 인증서 요청을 생성합니다.

2. 인증 기관에 인증서를 요청할 때 사용할 인증서 요청을 복사합니다.

3. 해당 인증서 요청을 사용하여 인증 기관에 인증서를 요청합니다. 인증서를 저장합니다.

4. 저장한 인증서를 각 장치나 컴퓨터로 가져옵니다.

5. PKI에 대한 신뢰할 수 있는 루트 인증서를 다운로드합니다.

6. 각 장치의 PKI에서 신뢰할 수 있는 루트 인증서를 가져옵니다. 통합 메시징 역할을 실행하는 Exchange 2010 컴퓨터에 신뢰할 수 있는 루트 인증서를 가져오는 경우 그룹 정책을 사용하여 통합 메시징 서버나 다른 Exchange 2010 서버의 신뢰할 수 있는 루트 인증서 저장소로 신뢰할 수 있는 루트 인증서를 가져올 수도 있습니다. 그러나 통합 메시징 서버 역할을 실행하는 서버를 구성하는 경우에도 이 프로세스가 사용됩니다.

   참고

   상업용 타사 인증서를 사용하여 상호 TLS를 구현하는 경우 동일한 단계를 수행합니다.

인증서 및 PKI에 대한 자세한 내용은 다음 항목을 참조하십시오.

• 인증서에 대한 자세한 내용은 Public Key Infrastructure for Windows Server 2003을 참조하십시오.

• Windows Server 2003 공개 키 인프라 구현을 위한 유용한 정보에 대한 자세한 내용은 Microsoft Windows Server 2003 공개 키 인프라 구현을 위한 유용한 정보를 참조하십시오.

• Windows Server 2008 기반 PKI를 배포하는 방법에 대한 자세한 내용은 구성 관리자 기본 모드에 필요한 PKI 인증서의 단계별 예제 배포: Windows Server 2008 인증 기관을 참조하십시오.

• Windows Server 2008 기반 PKI용 Windows Server 2008 인증서 서비스에 대한 자세한 내용은 Active Directory 인증서 서비스 개요를 참조하십시오.

타사 인증 기관

제3자 인증서나 상업용 인증서는 타사 또는 영리 CA가 생성한 인증서를 사용자 네트워크 서버에 사용할 수 있도록 구입한 것입니다. 자체 서명 인증서와 PKI 기반 인증서의 한 가지 문제점은 신뢰된 인증서가 아니기 때문에 클라이언트 컴퓨터, 서버 및 기타 장치의 신뢰할 수 있는 루트 인증서 저장소로 인증서를 반드시 가져와야 한다는 것입니다. 제3자 인증서나 상업용 인증서에는 이러한 문제가 없습니다. 영리 CA가 발급한 인증서는 대부분 신뢰할 수 있는 루트 인증서 저장소에 이미 있기 때문에 이미 신뢰된 상태입니다. 발급자를 신뢰할 수 있으면 해당 인증서도 신뢰할 수 있습니다. 제3자 인증서를 사용하면 배포 과정이 매우 간편해집니다.

대규모 조직 또는 인증서를 공개적으로 배포해야 하는 조직의 경우 인증서 관련 비용이 들더라도 타사 인증서나 상업용 인증서를 사용하는 것이 가장 좋습니다. 소규모나 중간 규모의 조직에서는 상업용 인증서가 가장 좋은 방법이 아닐 경우도 있으므로 사용 가능한 다른 인증서 옵션 중 하나를 사용하도록 결정할 수 있습니다.

IP 게이트웨이나 IP PBX의 구성에 따라 타사 인증서나 상업용 인증서를 IP 게이트웨이와 IP PBX의 신뢰할 수 있는 인증서 저장소에 가져와야만 타사 인증서를 상호 TLS에 사용할 수 있는 경우도 있습니다. 그러나 경우에 따라 제3자 인증서는 통합 메시징 서버와 조직의 다른 Exchange 2010 컴퓨터에 있는 신뢰할 수 있는 루트 인증서 저장소에 포함되기도 합니다.

상호 TLS 사용을 위해 상업용 타사 인증서를 사용할 때 수행하는 절차는 PKI 인증서를 사용할 때 수행하는 절차와 같습니다. 유일하게 다른 점은 사용 중인 네트워크의 서버와 장치에 있는 신뢰할 수 있는 루트 인증서 저장소로 가져올 인증서를 타사 영리 인증서 공급업체로부터 구입했기 때문에 PKI 인증서를 생성하지 않아도 된다는 것입니다.

맨 위로 이동

상호 TLS 구성

기본적으로 IP 게이트웨이로부터 들어오는 호출이 도착할 때 VoIP 트래픽은 암호화되지 않고 상호 TLS를 사용하지 않습니다. 그러나 통합 메시징 서버에 대한 보안 설정은 통합 메시징 서버에 연결된 UM 다이얼 플랜에서 구성됩니다. 통합 메시징 서버에서 IP 게이트웨이, IP PBX 및 그 밖의 Exchange 2010 서버와 안전하게 통신할 수 있도록 하려면 Set-UMDialPlan cmdlet을 사용하여 UM 다이얼 플랜에 VoIP 보안을 구성한 다음 UM 다이얼 플랜에 연결된 통합 메시징 서버에 상호 TLS를 사용하도록 설정해야 합니다.

UM 다이얼 플랜에서 VoIP 보안을 사용하도록 설정하면 해당 UM 다이얼 플랜과 연결된 모든 통합 메시징 서버가 안전한 방식으로 통신할 수 있습니다. 그러나 상호 TLS 사용 설정에 사용하는 인증서의 종류에 따라 먼저 통합 메시징 서버와 IP 게이트웨이 및 PBX에서 필요한 인증서를 가져오고 내보내야 합니다. 필요한 인증서를 통합 메시징 서버에 가져왔으면 Microsoft Exchange 통합 메시징 서비스를 다시 시작해야 가져온 인증서를 사용하여 IP 게이트웨이나 IP PBX에 암호화된 연결을 설정할 수 있습니다. 인증서 가져오기 및 내보내기 방법에 대한 자세한 내용은 Import and Export Certificates를 참조하십시오.

신뢰할 수 있는 인증서를 필요한 만큼 가져오고 내보낸 경우에는 IP 게이트웨이가 통합 메시징 서버에 인증서를 요청한 다음 IP 게이트웨이에 인증서를 요청합니다. IP 게이트웨이와 통합 메시징 서버 간에 신뢰할 수 있는 인증서를 교환하면 IP 게이트웨이와 통합 메시징 서버에서 상호 TLS를 사용하여 암호화된 연결을 통해 통신할 수 있습니다. IP 게이트웨이나 IP PBX로부터 들어오는 호출이 도착하면 통합 메시징 서버에 상호 TLS를 사용하여 인증서 교환과 보안 협상을 시작합니다. 인증서 교환 프로세스나 인증서가 올바른지 확인하는 과정에는 Microsoft Exchange 통합 메시징 서비스가 사용되지 않습니다. 그러나 통합 메시징 서버에서 신뢰할 수 있는 인증서를 찾을 수 없거나, 신뢰할 수 있는 인증서가 올바르지 않거나, 상호 TLS 협상 실패로 인해 호출이 거부되면 Microsoft Exchange 통합 메시징 서비스로부터 통합 메시징 서버에 알림이 도착합니다.

Microsoft Exchange 통합 메시징 서비스에서 통합 메시징 서버와 IP 게이트웨이 간 인증서 교환에 관여하지 않지만 Microsoft Exchange 통합 메시징 서비스에서는 다음을 수행합니다.

• FQDN 목록을 Microsoft Exchange Speech 서비스에 제공하여 목록에 포함된 IP 게이트웨이나 IP PBX로부터의 호출만 수락하도록 합니다.

• 인증서의 issuerName 및 SerialNumber 특성을 Microsoft Exchange Speech 서비스에 전달합니다. 이러한 특성은 IP 게이트웨이나 IP PBX에서 인증서를 요청할 때 통합 메시징 서버에서 사용할 인증서를 고유하게 식별합니다.

통합 메시징 서버와 IP 게이트웨이 또는 IP PBX에서 키 교환을 수행하여 상호 TLS를 통해 암호화된 연결을 설정한 경우에는 통합 메시징 서버에서 암호화된 연결을 사용하여 IP 게이트웨이 및 IP PBX와 통신합니다. 통합 메시징 서버에서는 상호 TLS를 사용하는 암호화된 연결을 통해 클라이언트 액세스 서버와 허브 전송 서버 같은 그 밖의 Exchange 2010 서버와도 통신합니다. 그러나 상호 TLS는 통합 메시징 서버에서 허브 전송 서버로 전송되는 트래픽이나 메시지를 암호화하는 데만 사용됩니다.

중요

UM IP 게이트웨이와 보안 모드로 작동하는 다이얼 플랜 사이에 상호 TLS를 사용할 수 있도록 하려면 먼저 FQDN과 함께 UM IP 게이트웨이를 구성한 다음 포트 5061에서 수신 대기하도록 구성해야 합니다. UM IP 게이트웨이를 구성하려면 다음 명령을 실행합니다. Set-UMIPGateway -Identity MyUMIPGateway -Port 5061.

맨 위로 이동

IPsec

IPsec의 경우도 인증서를 사용하여 데이터를 암호화합니다. 개인 네트워크 및 인터넷 공격을 방지할 수 있는 방법을 제공해 줍니다.

IPsec의 목표는 다음과 같습니다.

• IP 패킷의 콘텐츠를 보호합니다.

• 패킷 필터링과 신뢰할 수 있는 통신 강화를 통해 네트워크 공격을 방어합니다.

IPsec은 암호화 보안 서비스를 사용하여 IP 네트워크를 통해 전용 보안 통신을 지원하는 개방형 표준 프레임워크입니다.

IPsec은 암호화 기반 보호 서비스, 보안 프로토콜 및 동적 키 관리를 사용하며 개인 네트워크 컴퓨터, 도메인, 사이트, 원격 사이트, 엑스트라넷 및 전화 접속 클라이언트 간의 통신을 보호할 수 있는 강력한 기능과 융통성을 제공합니다. 특정 유형의 트래픽 수신 또는 송신을 차단하는 데도 사용될 수 있습니다.

IPsec은 원본 IP 주소에서 대상 IP 주소로 신뢰와 보안을 설정하는 종단 간 보안 모델을 기반으로 합니다. IP 주소 자체는 ID로 인식되지 않아도 됩니다. 대신 IP 주소 뒤의 시스템은 인증 과정을 통해 유효성이 확인된 ID를 갖습니다. 보안이 유지되는 트래픽에 대해 알고 있어야 하는 컴퓨터는 보내는 컴퓨터와 받는 컴퓨터뿐입니다. 각 컴퓨터는 해당 종단에서 보안을 처리하며 통신이 이루어지는 미디어에 보안이 적용되지 않았음을 전제로 작동합니다. 원본에서 대상으로만 데이터를 라우팅하는 컴퓨터에서는 방화벽 유형의 패킷 필터링이나 네트워크 주소 변환이 두 컴퓨터 사이에서 수행되지 않을 경우 IPsec을 지원할 필요가 없습니다. 따라서 조직의 다음과 같은 시나리오에서 IPsec을 배포할 수 있습니다.

• LAN   클라이언트와 서버 간, 서버 간 및 서버와 VoIP 장치 간

• WAN   라우터 간 및 게이트웨이 간

• 원격 액세스   전화 접속 클라이언트 및 개인 네트워크로부터의 인터넷 액세스

일반적으로 두 시스템이 서로 간의 트래픽에 보안을 적용하도록 돕는 방법에 대해 동의할 수 있는 옵션과 보안 설정을 지정하기 위한 IPsec 구성은 양쪽 모두에 필요합니다. 이를 IPsec 정책이라고 합니다. Microsoft Windows 2000 Server, Windows XP, Windows Server 2003 및 Windows Server 2008 운영 체제의 IPsec 구현은 IETF(Internet Engineering Task Force) IPsec 작업 그룹에서 개발한 업계 표준을 기반으로 합니다. IPsec 관련 서비스 중 일부는 Microsoft 및 Cisco Systems, Inc.에서 공동으로 개발했습니다. IPsec 정책을 구성하는 방법에 대한 자세한 내용은 IPSec 정책 생성, 수정 및 할당을 참조하십시오.

IPsec에 대한 자세한 내용은 IPSec 개념(페이지는 영문일 수 있음)을 참조하십시오.

경고

네트워크에 현재 IPsec 정책이 구성되어 있는 경우 IPsec 정책에서 IP 게이트웨이와 IP PBX를 제외해야 합니다. 그렇지 않으면 음성 메시지에서 3초마다 1초씩 음성 송신이 끊깁니다. 이것은 알려진 문제이며 Windows Server 2003에 대한 핫픽스가 있습니다. 이 핫픽스에 대한 자세한 내용은 Windows Server 2003 및 Windows XP에서 Internet Protocol(IPsec) 보안 필터의 생성과 유지 관리를 단순화하는 방법(페이지는 영문일 수 있음)을 참조하십시오.

UM 다이얼 플랜 및 VoIP 보안

통합 메시징 서버는 UM 다이얼 플랜의 구성 방법에 따라 IP 게이트웨이, IP PBX 및 보안되지 않음, SIP 보안됨 또는 보안 모드의 Exchange 2010 컴퓨터와 통신할 수 있습니다. 통합 메시징 서버는 보안되지 않은 요청은 TCP 포트 5060에서, 보안된 요청은 TCP 포트 5061에서 동시에 수신할 수 있도록 구성되어 있으므로 다이얼 플랜에 구성된 모든 모드에서 작동될 수 있습니다. 통합 메시징 서버는 하나 또는 여러 UM 다이얼 플랜과 연결될 수 있으며 다른 VoIP 보안 설정을 갖는 다이얼 플랜과 연결될 수 있습니다. 단일 통합 메시징 서버는 보안되지 않음, SIP 보안됨 또는 보안 모드의 조합을 사용하도록 구성된 다이얼 플랜과 연결될 수 있습니다.

기본적으로 UM 다이얼 플랜을 만들 때는 보안되지 않음 모드로 통신하며, UM 다이얼 플랜과 연결된 통합 메시징 서버는 암호화를 사용하지 않고 IP 게이트웨이, IP PBX 및 기타 Exchange 2010 컴퓨터와 데이터를 주고받습니다. 보안되지 않음 모드에서는 RTP(Realtime Transport Protocol) 미디어 채널과 SIP 신호 정보가 모두 암호화되지 않습니다.

다른 장치 및 서버와 주고받는 SIP 및 RTP 트래픽을 상호 TLS를 사용하여 암호화하도록 통합 메시징 서버를 구성할 수 있습니다. 통합 메시징 서버를 UM 다이얼 플랜에 추가하고 SIP 보안됨 모드를 사용하도록 다이얼 플랜을 구성하면 SIP 신호 트래픽만 암호화되고, RTP 미디어 채널은 여전히 TCP를 사용합니다. TCP는 암호화되지 않습니다. 그러나 통합 메시징 서버를 UM 다이얼 플랜에 추가하고, 보안 모드를 사용하도록 다이얼 플랜을 구성하면 SIP 신호 트래픽과 RTP 미디어 채널이 모두 암호화됩니다. SRTP(Secure Realtime Transport Protocol)를 사용하는 보안 신호 미디어 채널에서도 상호 TLS를 사용하여 VoIP 데이터를 암호화합니다.

Exchange 관리 콘솔이나 Set-UMDialPlan cmdlet을 사용하여 새로운 다이얼 플랜을 만드는 중이나 다이얼 플랜을 만든 후 VoIP 보안 모드를 설정할 수 있습니다. SIP 보안됨 모드 또는 보안 모드를 사용하도록 UM 다이얼 플랜을 구성하면 UM 다이얼 플랜에 연결된 통합 메시징 서버가 SIP 신호 트래픽이나 RTP 미디어 채널 또는 둘 다를 암호화합니다. 그러나 통합 메시징 서버와 암호화된 메시지를 주고받으려면 UM 다이얼 플랜을 올바르게 구성해야 하며 IP 게이트웨이나 IP PBX 같은 장치에서 상호 TLS를 지원해야 합니다.

Exchange 관리 셸에서 Get-UMDialPlan cmdlet을 사용하여 특정 UM 다이얼 플랜에 대한 보안 설정을 확인할 수 있습니다. VoIP 보안 매개 변수를 사용할 수 있는 경우 응용 프로그램 이벤트 로그에 1114 및 1112번 정보 이벤트가 기록되었는지 확인하여 Microsoft Exchange 통합 메시징 서비스가 보안 모드로 시작되었는지 확인할 수 있습니다.

중요

상호 TLS를 구성하여 Dialogic 모델 2000 또는 4000 IP 게이트웨이 간에 교환되는 데이터를 암호화하려는 경우 서버와 클라이언트 인증을 모두 지원하는 Computer V3 인증서 템플릿을 사용해야 합니다. 서버 인증을 지원하는 웹 서버 인증서 템플릿은 Dialogic 1000 및 3000 IP 게이트웨이, AudioCodes IP 게이트웨이 및 Microsoft Office Communications Server 2007에서만 제대로 작동합니다.

맨 위로 이동

통합 메시징의 보안 모드 확인 및 인증서 선택 방법

Microsoft Exchange 통합 메시징 서비스를 시작하면 해당 서비스에서는 연결된 UM 다이얼 플랜과 VoipSecurity 매개 변수 설정을 확인하고, 보안 모드로 시작할지 또는 보안되지 않음 모드로 시작할지를 결정합니다. 보안 모드로 시작하기로 결정이 되면 필요한 인증서에 액세스할 수 있는지 여부를 확인합니다. 통합 메시징 서버가 UM 다이얼 플랜에 연결되지 않은 경우에는 Msexchangeum.config 파일에서 StartSecured 매개 변수를 확인하여 시작 모드를 결정합니다. 이 매개 변수의 값은 0 또는 1로 설정할 수 있습니다. 값이 1이면 VoIP 트래픽을 보호하기 위해 암호화를 사용하여 통합 메시징 서버가 시작됩니다. 값이 0이면 VoIP 트래픽을 보호하기 위한 암호화가 사용되지 않고 서버가 시작됩니다. 통합 메시징 서버의 시작 작업을 보안 모드에서 보안되지 않음 모드로 또는 그 반대로 변경하려면 서버를 해당 UM 다이얼 플랜에 연결한 다음 통합 메시징 서버를 다시 시작하면 됩니다. Msexchangeum.config 구성 파일의 구성 설정을 변경하고 Microsoft Exchange 통합 메시징 서비스를 다시 시작할 수도 있습니다.

Microsoft Exchange 통합 메시징 서비스가 보안되지 않음 모드로 시작되면 시작이 올바르게 진행됩니다. 그러나 IP 게이트웨이와 IP PBX도 보안되지 않은 모드로 실행되고 있는지 확인해야 합니다. 또한 통합 메시징 서버의 연결을 보안되지 않음 모드로 테스트하는 경우에는 Test-UMConnectivity cmdlet을 -Secured:false 매개 변수와 함께 사용하십시오. 

Microsoft Exchange 통합 메시징 서비스가 보안 모드로 시작되면 암호화 사용을 위해 상호 TLS에 사용할 올바른 인증서를 찾기 위해 로컬 인증서 저장소를 쿼리합니다. 서비스에서는 먼저 올바른 PKI 또는 상업용 인증서를 찾은 다음 적절한 인증서가 없을 경우 자체 서명 인증서를 찾습니다. PKI, 상업용 인증서 또는 자체 서명 인증서가 없으면 Microsoft Exchange 통합 메시징 서비스에서는 보안 모드로 시작할 때 사용할 자체 서명 인증서를 만듭니다. 통합 메시징 서버를 보안되지 않음 모드로 시작하는 경우에는 인증서가 필요하지 않습니다.

보안 모드로 시작하는 데 사용할 인증서의 모든 세부 사항은 인증서를 사용할 때마다 또는 인증서가 변경될 경우에 기록됩니다. 기록되는 세부 사항 중 일부는 다음과 같습니다.

• 발급자 이름

• 일련 번호

• 지문

지문은 사용되는 인증서를 고유하게 식별할 때 사용할 수 있는 SHA1(Secure Hash Algorithm) 해시입니다. Microsoft Exchange 통합 메시징 서비스에서 보안 모드로 시작할 때 사용하는 인증서를 로컬 인증서 저장소로부터 내보낸 다음 네트워크의 IP 게이트웨이와 IP PBX에서 신뢰할 수 있는 인증서 저장소로 이 인증서를 가져올 수 있습니다.

적절한 인증서를 찾아 사용한 다음 추가적인 변경이 이루어지지 않았으면 Microsoft Exchange 통합 메시징 서비스에서 사용할 인증서가 만료되기 한 달 전에 이벤트를 기록합니다. 이 기간 동안 인증서를 변경하지 않으면 Microsoft Exchange 통합 메시징 서비스에서 인증서가 만료될 때까지 날마다 그리고 인증서 만료 후에도 날마다 이벤트를 기록합니다.

통합 메시징 서버에서 암호화된 채널을 설정하기 위해 상호 TLS에 사용할 인증서를 찾는 경우 신뢰할 수 있는 루트 인증서 저장소를 확인합니다. 발급자가 서로 다른 올바른 인증서가 여러 개 있으면 통합 메시징 서버에서 인증서 만료 기간이 가장 오래 남은 올바른 인증서를 선택합니다. 인증서가 여러 개이면 통합 메시징 서버에서 발급자와 인증서 만료 날짜를 기준으로 인증서를 선택합니다. 통합 메시징 서버에서 올바른 인증서를 선택하는 기준은 순서대로 다음과 같습니다.

1. 만료 기간이 가장 오래 남은 PKI 또는 상업용 인증서

2. 만료 기간이 가장 적게 남은 PKI 또는 상업용 인증서

3. 만료 기간이 가장 오래 남은 자체 서명 인증서

4. 만료 기간이 가장 적게 남은 자체 서명 인증서 올바른 상업용 인증서, PKI 인증서 또는 자체 서명 인증서가 필요합니다. 올바른 인증서가 없으면 통합 메시징 서버에서 자체 서명 인증서를 생성합니다. 통합 메시징 서버를 SIP 보안됨 모드 또는 보안 모드로 실행하는 경우, VoIP 트래픽을 암호화하기 위해 올바른 인증서가 필요합니다.

   중요

   클라이언트 액세스 서버와 통합 메시징 서버 간의 전화에서 재생 데이터를 암호화하는 데 사용되는 클라이언트 액세스 서버에 새 인증서를 설치하는 경우 명령 프롬프트에서 IISreset 명령을 실행하여 올바른 인증서를 로드해야 합니다.

맨 위로 이동

 © 2010 Microsoft Corporation. 모든 권리 보유.