Exchange 2010 보안 가이드
적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3
마지막으로 수정된 항목: 2016-11-28
MicrosoftExchange Server 2010을 안전하게 배포해야 하는 IT 관리자를 대상으로 작성된 이 가이드는 Exchange가 설치된 전체적인 보안 환경을 IT 관리자가 이해하고 관리하는 데 도움을 줍니다.
이전에는 Microsoft Exchange의 각 버전에 대해 Exchange 팀이 독립 실행형 보안 강화 가이드를 사용 권한 및 보안 정보와 함께 게시했습니다. 이 방법은 Exchange 2010 설치가 실행된 후 서비스와 디렉터리를 잠그는 데 효과적이었습니다. 하지만, MicrosoftExchange Server 2007로 시작할 때, Exchange 설치에서는 설치할 서버 역할에 필요한 서비스만 사용합니다. Microsoft Exchange는 더 이상 설치되어 보안을 위해 강화되지 않습니다. 기본적으로 더욱 강력한 보안을 제공하도록 디자인되었습니다.
따라서 IT 관리자가 여러 절차를 수행하여 Microsoft Exchange를 실행 중인 서버를 잠가야 하는 이전 버전의 Microsoft Exchange와 달리 Exchange 2010에서는 잠그거나 강화하지 않아도 됩니다.
범위
Exchange 2010은 Microsoft SDL(Security Development Lifecycle) 원칙을 사용하여 개발되었습니다. 각 기능과 구성 요소에 대한 보안을 검토했습니다. 엄선된 기본 설정으로 더 안전하게 배포할 수 있습니다. 이 가이드의 범위는 보안 관련 기능과 보안 고려 사항에 영향을 미칠 수 있는 기능에 대해 관리자에게 알려주는 것입니다. 이 가이드는 Exchange 2010 설명서의 보안 관련 항목에 연결됩니다. 이런 항목은 부록 1: 추가 보안 관련 설명서에 설명되어 있습니다. 이 가이드에서는 Windows Server 운영 체제를 강화하기 위한 단계를 다루지 않습니다.
목차
새로운 기능
Exchange 2010 보안 개발 수명 주기
보안 확보—모범 사례
보안 유지—모범 사례
네트워크 포트 사용 및 방화벽 강화
제한 매개 변수 및 클라이언트 제한 정책
역할 기반 액세스 제어
Active Directory
Exchange Server 계정
파일 시스템
서비스
인증서
NTLM 고려 사항
2단계 인증
페더레이션
Secure/Multipurpose Internet Mail Extensions (S/MIME)
서버 역할 고려 사항
부록 1: 추가 보안 관련 설명서
새로운 기능
Exchange 2010에는 다음과 같은 새로운 보안 기능이 포함됩니다.
역할 기반 액세스 제어 Exchange 2010에는 조직에서 받는 사람 관리자, 서버 관리자, 레코드 및 검색 관리자, 조직 관리자와 같이 다양한 이해 관계자에 지정된 사용 권한을 미세하게 관리할 수 있는 새로운 역할 기반 액세스 제어 모델이 포함됩니다.
제한 정책 Exchange 2010에서는 서비스 거부 공격으로부터 조직을 보호하고 해당 공격의 영향을 줄이기 위해 사서함, 클라이언트 액세스 및 전송 서버에 제한 메커니즘을 도입합니다.
페더레이션 위임 Exchange 2010에서는 사용자가 외부 조직의 사용자와 안전하게 공동 작업할 수 있는 새로운 페더레이션 위임 기능을 도입합니다. 사용자는 페더레이션 위임을 사용하여 외부 페더레이션 조직의 사용자와 일정 및 연락처를 공유할 수 있습니다. Active Directory 트러스트 관계를 설정하고 관리할 필요 없이 포리스트 간 공동 작업도 가능합니다.
정보 권한 관리 Exchange 2010에는 조직에서 보호된 콘텐츠를 암호 해독 및 검색하고 이런 콘텐츠에 메시징 정책을 적용하는 능력을 유지하면서 여러 수준에서 중요한 메시지 콘텐츠를 보호할 수 있는 새로운 정보 보호 및 제어 기능이 포함됩니다.
보안 구성 마법사 없음 Exchange 2010에서 설정을 통해 특정 Exchange 서버 역할에 필요한 서비스만 설치하여 사용하고 각 서버 역할에서 실행 중인 서비스와 프로세스에 필요한 포트로만 통신을 제한하기 위해 필수적인 구성 변경 작업을 수행합니다. 그러면 이런 설정을 구성할 때 SCW(보안 구성 마법사)와 같은 도구를 사용할 필요가 없습니다.
Exchange 2010 보안 개발 수명 주기
2002년대 초에 Microsoft는 신뢰할 수 있는 컴퓨팅 이니셔티브를 소개했습니다. 신뢰할 수 있는 컴퓨팅이 소개된 이후 Microsoft 및 Microsoft Exchange 팀의 개발 프로세스는 보안 수준을 더욱 높이는 데 도움이 되는 소프트웨어를 개발하는 데 중점을 두었습니다. 자세한 내용은 신뢰할 수 있는 컴퓨팅을 참조하십시오.
Exchange 2010에서 신뢰할 수 있는 컴퓨팅은 다음 핵심 영역에 구현되었습니다.
디자인으로 보안 Exchange 2010은 신뢰할 수 있는 컴퓨팅 보안 개발 수명 주기를 준수하여 설계 및 개발되었습니다. 안전한 메시징 시스템을 만드는 첫 단계는 위협 모델을 디자인하고 디자인 시 각 기능을 테스트하는 것이었습니다. 보안과 관련하여 향상된 여러 기능이 코딩 프로세스 및 사례에 기본 제공되었습니다. 빌드 시간 도구는 버퍼 오버런 및 기타 잠재적인 보안 위협을 검색합니다. 시스템에서 완전한 보안을 보장할 수는 없습니다. 그러나 보안 디자인 원칙을 전체 디자인 프로세스에 포함한 Exchange 2010은 이전 버전보다 훨씬 안전합니다.
기본적으로 보안 유지 Exchange 2010의 한 가지 목표는 대부분의 네트워크 통신이 기본적으로 암호화되는 시스템을 개발하는 것이었습니다. SMB(서버 메시지 블록) 통신 및 일부 UM(통합 메시징) 통신을 제외하고 목표를 충족했습니다. 자체 서명된 인증서, Kerberos 프로토콜, SSL(Secure Sockets Layer) 및 기타 업계 표준 암호화 기술을 사용하여 거의 모든 Exchange 2010 데이터가 네트워크에서 보호됩니다. 또한 역할 기반 설치를 통해 Exchange 2010을 설치할 수 있으므로 서비스 및 그러한 서비스 관련 사용 권한만 특정 및 적절한 서버 역할과 함께 설치됩니다. 이전 버전의 Microsoft Exchange에서는 모든 기능에 대한 모든 서비스를 설치해야 했습니다.
스팸 방지 및 바이러스 백신 기능 Exchange 2010은 Edge 전송 서버 역할의 경계 네트워크에서 실행되는 스팸 방지 에이전트 제품군을 포함하며, 내부 네트워크에 있는 허브 전송 서버 역할에 설치될 수도 있습니다. 바이러스 백신 기능은 MicrosoftForefront Protection 2010 for Exchange Server를 Microsoft 솔루션으로 추가하여 향상되었습니다.
배포 시 보안 Exchange 2010이 개발될 때 시험판 버전이 Microsoft IT 프로덕션 환경에서 배포되었습니다. 이 배포에서 얻은 데이터를 기준으로 Microsoft Exchange Server Best Practices Analyzer가 업데이트되어 실제 보안 구성을 검색하고 사전 배포 및 사후 배포 모범 사례가 Exchange 2010 도움말에 수록되었습니다.
이전에는 핵심 설명서가 완료된 후에 사용 권한 관리가 문서화되고 전달되었습니다. 그러나 사용 권한 관리는 추가 기능 프로세스가 아닙니다. Exchange 2010 배포의 전체 계획 및 배포에 포함되어 있어야 합니다. 따라서 관리자가 관리 모델을 계획하고 배포할 때 매끄러운 컨텍스트를 제공할 수 있도록 사용 권한 문서를 간소화하여 핵심 설명서에 통합했습니다. Exchange 2010에는 관리자와 사용자가 최소 필수 사용 권한으로 작업을 수행하도록 세분화된 사용 권한을 부여할 수 있는 새 역할 기반 사용 권한 모델이 포함됩니다.
통신 Exchange 2010이 발표되었으므로 Exchange 팀은 소프트웨어를 최신 상태로 유지하고 이에 대해 알려줄 것입니다. Microsoft Update를 사용하여 시스템을 최신으로 유지하면 최신 보안 업데이트가 조직에 설치됩니다. Exchange 2010에는 스팸 방지 업데이트도 포함되어 있습니다. 또한 Microsoft 기술 보안 알림을 구독하면 Exchange 2010의 최신 보안 문제를 놓치지 않고 알 수 있습니다.
보안 확보—모범 사례
몇몇 기본적인 모범 사례가 더 안전한 환경을 만들고 유지 관리하는 데 도움이 될 것입니다. 일반적으로 분석 도구를 정기적으로 실행하고 소프트웨어와 바이러스 백신 서명 파일을 최신으로 유지하는 것이 Exchange 2010 보안 환경을 최적화하는 가장 효율적인 방법입니다.
설치 권장 사항
이 모범 사례는 더 안전한 Exchange 2010 환경을 만드는 데 도움이 됩니다.
설치 위임 조직에 설치하는 첫 번째 Exchange 2010 서버에서는 설치를 실행하는 데 사용하는 계정이 Enterprise Administrators 그룹의 구성원이어야 합니다. 이때 사용하는 계정은 Exchange 2010 설치에서 만든 Organization Management 역할 그룹에 추가됩니다. 위임된 설치를 사용하여 Organization Management 역할 그룹의 구성원이 아닌 관리자가 후속 서버를 설치하도록 허용할 수 있습니다. 자세한 내용은 Exchange 2010 Server 제공 및 설치 위임을 참조하십시오.
파일 시스템 사용 권한 Exchange 2010 설치 프로그램은 Exchange 이진 파일 및 데이터가 저장되는 파일 시스템에 최소 필수 사용 권한을 할당합니다. 파일 시스템의 루트 폴더와 Program Files 폴더에서 ACL(액세스 제어 목록)을 변경하면 안 됩니다.
설치 경로 시스템 드라이브가 아닌 드라이브(운영 체제가 설치되지 않은 볼륨)에 Exchange 2010 이진 파일을 설치하는 것이 좋습니다. Exchange 데이터베이스와 트랜잭션 로그는 크기가 빠르게 증가할 수 있으므로, 용량과 성능을 고려하여 크기를 조정한 시스템 볼륨 이외의 볼륨에 있어야 합니다. 트랜잭션 로그와 같은 다른 Exchange 구성 요소에서 생성한 다른 많은 로그 역시 Exchange 이진 파일과 같은 설치 경로에 저장되고, 구성 및 메시징 환경에 따라 크게 증가할 수 있습니다. Exchange 2010에서는 많은 로그 파일의 최대 크기와 로그 파일 폴더가 차지할 수 있는 최대 저장 공간을 구성할 수 있는데, 이는 기본적으로 250메가바이트로 설정됩니다. 디스크 공간 부족으로 인해 시스템이 중단될 가능성을 예방하기 위해, 각 서버 역할에 대한 로깅 요구 사항을 평가하고 요구 사항에 맞춰 로깅 옵션과 로그 파일 저장 위치를 구성하는 것이 좋습니다.
레거시 Outlook 클라이언트 차단 요구 사항을 바탕으로, 레거시 Outlook 클라이언트 버전을 차단하도록 Outlook 클라이언트 차단을 구성할 수 있습니다. Outlook 보호 규칙 및 개인 보관 파일과 같은 특정 Exchange 2010 기능은 레거시 Outlook 클라이언트를 지원하지 않습니다. Outlook 클라이언트 차단에 대한 자세한 내용은 메시징 레코드 관리를 위한 Outlook 클라이언트 차단 구성을 참조하십시오.
사용자 이름에서 SMTP 주소 분리 기본적으로, Exchange에서는 사서함 사용자의 사용자 이름을 바탕으로 전자 메일 주소와 별칭을 생성합니다. 많은 조직에서 보안 강화를 위해 사용자 이름과 사용자 전자 메일 주소를 분리하기 위한 추가 전자 메일 주소 정책을 만듭니다. 예를 들어, Ben Smith라는 사용자의 사용자 이름이 bsmith이고 도메인이 contoso.com인 경우 기본 전자 메일 주소 정책에서 생성되는 기본 전자 메일 주소는 bsmith@contoso.com입니다. 이 사용자의 별칭이나 사용자 이름을 사용하지 않는 전자 메일 주소를 생성하기 위해 추가적인 전자 메일 주소 정책을 만들 수 있습니다. 예를 들어, 전자 메일 주소 정책을 만들어
%g.%s@domain템플릿을 사용하면 Firstname.Lastname@domain 형식으로 전자 메일 주소가 생성됩니다. Ben Smith라는 사용자의 경우, 이 정책에서는 Ben.Smith@contoso.com이라는 주소를 생성합니다. 또는 사서함을 만들거나 사용할 때 사용자 이름과는 다른 별칭을 지정하여 사용자 이름과 전자 메일 주소를 분리할 수 있습니다.참고
사용자의 기본 SMTP 주소가 계정에 대한 UPN과 일치하지 않는 경우 사용자는 자신의 전자 메일 주소를 사용하여 MicrosoftOfficeOutlook Web App에 로그인할 수 없고 도메인\사용자 이름 형식을 사용하여 사용자 이름을 입력해야 합니다. MicrosoftOutlook 사용 시, Outlook이 자동 검색 서비스에 연결할 때 자격 증명을 요구하는 메시지가 표시되면 도메인\사용자 이름 형식으로 사용자 이름을 입력해야 합니다.
Microsoft Update
Microsoft Update는 MicrosoftWindows Update와 동일한 다운로드에 다른 Microsoft 프로그램의 최신 업데이트를 추가하여 제공하는 서비스로, 서버를 더욱 안전하게 유지하고 서버가 최상의 성능을 내도록 합니다.
Microsoft Update의 주요 기능은 Windows 자동 업데이트입니다. 이 기능은 컴퓨터의 보안 및 안정성에 매우 중요한 우선 순위가 높은 업데이트를 자동으로 설치합니다. 이러한 보안 업데이트가 없을 경우 사용자의 컴퓨터가 침입자 및 악성 소프트웨어(맬웨어)로부터 공격을 받을 수 있습니다.
Microsoft Update를 받는 가장 신뢰할 수 있는 방법은 Windows 자동 업데이트를 사용하여 업데이트가 컴퓨터에 자동으로 제공되도록 하는 것입니다. Microsoft Update에 등록할 때 자동 업데이트를 켭니다.
Windows는 컴퓨터에 설치된 Microsoft 소프트웨어에서 필요한 현재와 이전의 우선 순위가 높은 업데이트가 있는지 분석하고 이러한 업데이트를 자동으로 다운로드하고 설치합니다. 그 후에 인터넷에 연결할 때 Windows는 우선 순위가 높은 새로운 업데이트에 대해 업데이트 프로세스를 반복합니다.
Microsoft Update를 사용하려면 Microsoft Update를 참조하십시오.
Microsoft Update의 기본 모드를 사용하려면 자동 업데이트를 받을 수 있게 각 Exchange 서버가 인터넷에 연결되어 있어야 합니다. 인터넷에 연결되지 않은 서버를 실행 중인 경우 Windows Server Update Services(WSUS)를 설치하여 조직의 컴퓨터에 대한 업데이트 배포를 관리할 수 있습니다. 그런 다음 업데이트를 위해 내부 WSUS 서버에 연결하도록 내부 Microsoft Exchange 컴퓨터에서 Microsoft Update를 구성할 수 있습니다. 자세한 내용은 Microsoft Windows Server Update Services 3.0을 참조하십시오.
WSUS는 사용 가능한 유일한 Microsoft Update 관리 솔루션이 아닙니다. Microsoft 보안 릴리스, 프로세스, 통신 및 도구에 대한 자세한 내용은 Microsoft 보안 업데이트 가이드(영문)를 참조하십시오.
Exchange 2010에서 더 이상 필요하지 않은 작업
더 이상 다음 도구를 설치하거나 실행할 필요가 없습니다.
IIS 7에는 URLScan 보안 도구가 필요하지 않습니다. Microsoft Exchange의 이전 버전에서는 일반적으로 URLScan과 같은 IIS 도구를 설치하여 IIS 설치를 보호했습니다. Exchange 2010에는 IIS 7을 포함하는 Windows Server 2008이 필요합니다. 원래 UrlScan에서 사용 가능했던 보안 기능 중 다수를 IIS 7 요청 필터링 기능에서 사용할 수 있습니다.
이제는 Exchange 모범 사례 분석기를 설치할 필요가 없습니다. Microsoft Exchange의 이전 버전은 일반적으로 Exchange 모범 사례 분석기를 설치하여 실행한 후 설치되었습니다. Exchange 2010 설치 프로그램은 Exchange 모범 사례 분석기 구성 요소를 포함하며 설치 중에 이들 구성 요소를 실행합니다. 설치 전에 Exchange 모범 사례 분석기를 실행할 필요는 없습니다.
더 이상 SCW(보안 구성 마법사)나 SCW를 위한 Exchange 템플릿을 사용하지 않아도 됩니다. Exchange 2010 설치 프로그램은 주어진 Exchange 서버 역할에 필요한 서비스만 설치하고, 고급 보안 규칙으로 Windows 방화벽을 만들어 그 서버 역할을 위한 서비스 및 프로세스에 필요한 포트만 엽니다. 이를 위해 더 이상 SCW(보안 구성 마법사)를 실행할 필요가 없습니다. Exchange Server 2007과는 달리, Exchange 2010에는 SCW 템플릿이 포함되지 않습니다.
보안 유지—모범 사례
다음 모범 사례 권장 사항은 Exchange 2010 환경의 보안을 유지하는 데 도움이 됩니다.
소프트웨어를 최신으로 유지
앞부분에서 언급했듯이 Microsoft Update를 실행하는 것이 가장 좋습니다. 모든 서버에서 Microsoft Update를 실행하는 것 외에도 모든 클라이언트 컴퓨터를 최신 상태로 유지하고 조직의 모든 컴퓨터에서 바이러스 백신 업데이트를 유지 관리하는 것이 좋습니다.
Microsoft 소프트웨어 외에 조직에서 실행 중인 모든 소프트웨어에 대해 최신 업데이트를 실행합니다.
스팸 방지 업데이트
Exchange 2010은 또한 Microsoft Update 인프라를 사용하여 스팸 방지 필터를 최신으로 유지합니다. 기본적으로 수동 업데이트를 사용하는 경우 관리자는 Microsoft Update를 방문하여 콘텐츠 필터 업데이트를 다운로드하고 설치해야 합니다. 콘텐츠 필터 업데이트 데이터는 2주마다 업데이트되어 제공됩니다.
Microsoft Update에서 제공되는 수동 업데이트에는 Microsoft IP 신뢰도 서비스 또는 스팸 서명 데이터가 포함됩니다. Microsoft IP 신뢰도 서비스 및 스팸 서명 데이터는 Forefront Security for Exchange Server 스팸 방지 자동 업데이트에만 사용할 수 있습니다.
Forefront 스팸 방지 자동 업데이트를 사용하는 방법에 대한 자세한 내용은 스팸 방지 업데이트 이해를 참조하십시오.
바이러스 백신 소프트웨어 실행
전자 메일 시스템에 의해 전송되는 바이러스, 웜 및 기타 악의적 콘텐츠는 대부분의 Microsoft Exchange 관리자를 괴롭히고 있습니다. 따라서 모든 메시징 시스템에 적합한 방어형 바이러스 백신 배포를 개발해야 합니다. 이 섹션에서는 Exchange 2010용 바이러스 백신 소프트웨어 배포에 대한 모범 사례 권장 사항을 제공합니다.
바이러스 백신 소프트웨어 공급업체를 선택할 때는 Exchange 2010의 두 가지 중요한 변경 내용에 특히 유의해야 합니다.
Exchange Server 2007부터, Microsoft Exchange는 64비트 아키텍처를 기반으로 합니다.
Exchange 2010에는 전송 에이전트 기능이 포함됩니다.
이러한 두 가지 변경 내용은 바이러스 백신 공급업체에서 Exchange 2010 관련 소프트웨어를 제공해야 함을 의미합니다. 이전 버전의 Exchange용으로 작성된 바이러스 백신 소프트웨어는 Exchange 2010에서 제대로 작동되지 않을 수 있습니다.
체계적인 방어 방법을 채택하려면 사용자 데스크톱의 바이러스 백신 소프트웨어뿐 아니라 메시징 시스템에 사용하도록 만든 바이러스 백신 소프트웨어를 SMTP 게이트웨이 또는 사서함을 호스트하는 Exchange 서버에 배포하는 것이 좋습니다.
감수할 비용과 위험 부담 간의 적절한 균형을 결정하여 사용할 바이러스 백신 소프트웨어 유형과 해당 소프트웨어를 배포할 위치를 결정합니다. 예를 들어, 일부 조직에서는 SMTP 게이트웨이에서 바이러스 백신 메시징 소프트웨어를 실행하고 Exchange 서버에서 파일 수준의 바이러스 백신 검색을 실행하고 사용자 데스크톱에서 바이러스 백신 클라이언트 소프트웨어를 실행합니다. 이 접근 방법에서는 클라이언트에서 메시징 관련 보호를 제공합니다. 기타 조직에서는 높은 비용을 감수할 수 있으므로 Exchange 사서함 서버의 Exchange VSAPI(Virus Scanning Application Programming Interface) 2.5와 호환되는 바이러스 백신 소프트웨어와 함께 SMTP 게이트웨이에서 바이러스 백신 메시징 소프트웨어를 실행하고 Exchange 서버에서 파일 수준의 바이러스 백신 검색을 실행하고 사용자 데스크톱에서 바이러스 백신 클라이언트 소프트웨어를 실행하여 보안을 강화할 수 있습니다.
Edge 전송 서버 및 허브 전송 서버에서 바이러스 백신 소프트웨어 실행
전송 기반 바이러스 백신 소프트웨어는 전송 에이전트로 구현되거나 전송 에이전트를 포함합니다. 전송 에이전트는 전송 이벤트로 사용되며 Microsoft Exchange 이전 버전의 이벤트 싱크와 매우 유사합니다. 자세한 내용은 전송 에이전트 이해를 참조하십시오.
참고
사서함 서버에서만 검색될 수 있으며 전송을 통해 라우팅되지 않는 공용 폴더의 항목, 보낸 편지함, 일정 항목 등의 메시지는 전송 전용 바이러스 검색으로는 보호되지 않습니다.
타사 개발자는 사용자 지정 전송 에이전트를 작성하여 강력한 전송 수준 바이러스 백신 검색을 위한 기본 MIME 구문 분석 엔진을 활용할 수 있습니다. Exchange 바이러스 백신 및 스팸 방지 파트너 목록은 독립 소프트웨어 공급업체(영문)를 참조하십시오.
또한, Forefront Protection for Exchange Server는 Exchange 2010과 강력하게 통합된 바이러스 백신 소프트웨어 패키지로 Exchange 환경에 대한 추가 바이러스 백신 보호를 제공합니다. 자세한 내용은 Microsoft Forefront Protection 2010 for Exchange Server(영문)를 참조하십시오.
메시징 바이러스 백신 소프트웨어는 조직에서 최일선 방어 요소로 실행되어야 합니다. 이는 외부 메시지가 메시징 환경으로 들어가는 통로가 되는 SMTP 게이트웨이입니다. Exchange 2010에서 최일선 방어 요소는 Edge 전송 서버입니다.
Exchange에 앞서 비 Exchange SMTP 서버 또는 게이트웨이를 사용하여 인바운드 전자 메일을 받는 경우 비 Exchange SMTP 호스트에 충분한 스팸 방지 및 바이러스 백신 기능을 구현해야 합니다.
Exchange 2010에서는 모든 메시지가 허브 전송 서버를 통해 라우팅됩니다. 여기에는 Exchange 조직 외부에서 보내거나 받은 메시지와 Exchange 조직 내부에서 보낸 메시지가 포함됩니다. 보낸 사람과 동일한 사서함 서버에 있는 사서함으로 보낸 메시지. 또한, 조직 내부의 바이러스 감염을 더욱 강력히 방지하거나 추가적인 방어 요소를 제공하려면 허브 전송 서버에서 전송 기반 바이러스 백신 소프트웨어를 실행하는 것이 좋습니다.
사서함 서버에서 바이러스 백신 소프트웨어 실행
전송 서버에서의 바이러스 검색 외에도, 사서함 서버에서 실행되는 MicrosoftExchange VSAPI(바이러스 검색 API) 검색 솔루션이 많은 조직에서 중요한 방어 계층일 수 있습니다. 다음 조건 중 하나라도 해당하는 경우 VSAPI 바이러스 백신 솔루션을 실행하는 것을 고려해야 합니다.
조직에 완전하고 믿을 수 있는 데스크톱 바이러스 백신 검색 제품이 배포되어 있지 않은 경우
사서함 데이터베이스 검색을 통해 제공될 수 있는 추가 보호 요소가 조직에 필요한 경우
조직이 Exchange 데이터베이스에 프로그래밍 방식으로 액세스할 수 있는 사용자 지정 응용 프로그램을 개발한 경우
사용자 커뮤니티에서 정기적으로 메시지를 공용 폴더에 게시하는 경우
Exchange VSAPI를 사용하는 바이러스 백신 솔루션은 Exchange 정보 저장소 프로세스 내에서 직접 실행됩니다. VSAPI 솔루션은 표준 클라이언트와 전송 검색을 무시하면서 감염된 콘텐츠를 Exchange 정보 저장소 내에 배치하는 공격 벡터로부터 보호할 수 있는 유일한 솔루션이라고 할 수 있습니다. 예를 들어, VSAPI는 CDO(Collaboration Data Objects), WebDAV 및 EWS(Exchange 웹 서비스)를 통해 데이터베이스에 전송된 데이터를 검색하는 유일한 솔루션입니다. 또한 바이러스에 감염된 경우 대부분의 VSAPI 솔루션은 감염된 메일 데이터베이스에서 바이러스를 가장 빠르게 제거할 수 있는 방법을 제공합니다.
Exchange Server 및 파일 시스템 바이러스 백신
Exchange 서버를 보호하기 위해 파일 시스템 바이러스 백신 소프트웨어를 배포하는 경우 다음 사항을 고려하십시오.
Exchange 사서함과 공용 폴더 데이터베이스가 저장된 Exchange 서버 디렉터리를 파일 시스템 바이러스 검색 프로그램에서 제외해야 합니다. 자세한 내용은 Exchange 2010의 파일 수준 바이러스 백신 검색을 참조하십시오.
파일 시스템 바이러스 검색 프로그램은 파일만 보호합니다. 전자 메일 메시지를 보호하려면 MicrosoftForefront나 적절한 파트너 또는 타사 제품과 같은 Exchange 인식 바이러스 백신 또는 메시징 보안 제품의 구현도 고려해야 합니다. 스팸 방지 및 바이러스 백신 보호에 대한 자세한 내용은 스팸 방지 및 바이러스 백신 기능 이해를 참조하십시오. 자세한 내용은 Forefront Protection 2010 for Exchange Server: 개요(영문)를 참조하십시오.
효과적인 보호를 위해서는 바이러스 백신 및 스팸 방지 서명을 최신으로 유지해야 합니다.
바이러스 백신 및 스팸 방지 소프트웨어 또는 서비스에서 제공하는 보고서를 정기적으로 검토하여 보호 기능이 사용되고 있고 필요에 따른 기능을 수행하는지 확인하고 사건을 빠르게 탐지하고 필요한 조치를 취해야 합니다.
Exchange Hosted Services 사용
스팸 및 바이러스 필터링은 Microsoft Exchange Hosted Services에 의해 개선되며 MicrosoftExchange Hosted Services를 통해 서비스로 사용할 수도 있습니다. Exchange Hosted Services에서는 다음과 같은 네 가지 호스팅 서비스를 제공합니다.
전자 메일을 통해 전파되는 맬웨어로부터 조직을 보호하도록 지원하는 Hosted Filtering
조직에서 준수 및 보존 요구 사항을 충족하도록 하는 Hosted Archive
조직에서 데이터를 암호화하여 기밀을 유지할 수 있도록 하는 Hosted Encryption
조직에서 시스템 중단 시 및 중단 이후에 계속해서 전자 메일에 액세스할 수 있도록 하는 Hosted Continuity
이런 서비스는 사내에서 관리되는 온-프레미스 Exchange 서버와 통합됩니다. 자세한 내용은 Forefront Online Protection for Exchange를 참조하십시오.
첨부 파일 필터링 사용
Exchange 2010에서 첨부 파일 필터링을 통해 Edge 전송 서버에 필터를 적용하여 사용자가 받는 첨부 파일을 제어할 수 있습니다. 많은 첨부 파일 유형에는 중요한 문서를 훼손시키거나 민감한 정보를 노출시킴으로써 사용자 컴퓨터, 또는 조직 전체에 큰 피해를 일으킬 수 있는 유해한 바이러스 또는 부적절한 자료가 포함되어 있기 때문에 첨부 파일 필터링의 중요성이 점차 커지고 있습니다.
다음 유형의 첨부 파일 필터링을 사용하여 Edge 전송 서버를 통해 조직이 받거나 보내는 첨부 파일을 제어할 수 있습니다.
파일 이름 또는 파일 이름 확장명 기반 필터링 필터링할 정확한 파일 이름이나 파일 이름 확장명을 지정하여 첨부 파일을 필터링할 수 있습니다. 예를 들면 BadFilename.exe는 정확한 파일 이름 필터이고 *.exe는 파일 이름 확장명 필터입니다.
MIME 콘텐츠 형식 기반 필터링 필터링할 MIME 콘텐츠 형식을 지정하여 첨부 파일을 필터링할 수도 있습니다. MIME 콘텐츠 형식은 첨부 파일의 형식(JPEG 이미지 파일, 실행 파일, Microsoft Office Excel 2010 파일 또는 그 밖의 파일 형식)을 나타냅니다. 콘텐츠 유형은 유형/하위 유형으로 표현됩니다. 예를 들어, JPEG 이미지 콘텐츠 유형은 이미지/jpeg로 표현됩니다.
첨부 파일이 위와 같은 필터링 조건 중 하나와 일치하는 경우 첨부 파일에 대해 다음 동작을 수행하도록 구성할 수 있습니다.
전체 메시지 및 첨부 파일 차단
첨부 파일 제거 후 메시지 통과 허용
자동으로 메시지 및 첨부 파일 삭제
자세한 내용은 첨부 파일 필터링 이해를 참조하십시오.
참고
첨부 파일 필터 에이전트를 사용하여 첨부 파일의 콘텐츠를 바탕으로 첨부 파일을 필터링할 수 없습니다. 전송 규칙을 사용하여 메시지 및 첨부 파일 콘텐츠를 검사하고 메시지 삭제나 거부 또는 메시지와 첨부 파일 IRM 보호와 같은 조치를 취할 수 있습니다. 자세한 내용은 전송 규칙 이해를 참조하십시오.
Forefront Protection for Exchange Server를 사용하여 파일 필터링
Forefront Protection for Exchange Server에서 제공되는 파일 필터링 기능에는 Exchange 2010에 포함되어 있는 첨부 파일 필터 에이전트에서 사용할 수 없는 고급 기능이 포함됩니다.
예를 들면 다른 파일을 포함하는 파일인 컨테이너 파일에서 잘못된 파일 형식을 검색할 수 있습니다. Forefront Protection for Exchange Server 필터링은 다음 컨테이너 파일을 검색하고 포함된 파일에 적용할 수 있습니다.
PKZip(.zip)
GNU Zip(.gzip)
압축된 보관 파일(.zip) 자동 압축 풀기
압축된 파일(.zip)
Java 보관 파일(.jar)
TNEF(winmail.dat)
구조적 저장소(.doc, .xls, .ppt 등)
MIME(.eml)
SMIME(.eml)
UUEncode(.uue)
Unix 테이프 보관 파일(.tar)
RAR 보관 파일(.rar)
MACBinary(.bin)
참고
Exchange 2010에 포함된 첨부 파일 필터 에이전트는 이름이 바뀌어도 파일 형식을 검색합니다. 첨부 파일 필터링은 또한 파일 이름 확장명을 압축된 Zip 또는 LZH 파일의 파일과 비교하여 압축된 Zip 및 LZH 파일에 차단된 첨부 파일이 없는지 확인합니다. Forefront Protection for Exchange Server 파일 필터링에는 차단된 첨부 파일이 컨테이너 파일 내에서 이름이 바뀌었는지 확인하는 추가 기능이 있습니다.
파일 크기를 기준으로 파일을 필터링할 수도 있습니다. 또한, 필터링된 파일을 격리하거나 Exchange 파일 필터 일치 항목을 기준으로 전자 메일 알림을 보내도록 Forefront Protection for Exchange Server를 구성할 수 있습니다.
자세한 내용은 Microsoft Forefront Security for Exchange Server를 사용하여 Microsoft Exchange 조직 보호를 참조하십시오.
Exchange 모범 사례 분석기 실행
Exchange 모범 사례 분석기는 Exchange 환경이 안전한지 확인하기 위해 정기적으로 실행할 수 있는 매우 효율적인 도구입니다. Exchange 모범 사례 분석기는 Microsoft Exchange 배포를 자동으로 검사하고 Microsoft 모범 사례에 따라 배포가 구성되어 있는지 확인합니다. Exchange 2010에서는 Exchange 모범 사례 분석기가 Exchange 설치 프로그램의 일부로 설치되고 EMC(Exchange 관리 콘솔)의 도구 섹션에서 실행 가능합니다. 적절한 네트워크 액세스를 통해 Exchange 모범 사례 분석기는 모든 AD DS(Active Directory 도메인 서비스) 서버와 Exchange 서버를 검사합니다. Exchange 모범 사례 분석기에는 사용 권한 상속 검사가 포함됩니다. 또한, RBAC 사용 권한의 유효성 검사를 테스트합니다. 여기에는 모든 사용자가 ECP(Exchange 제어판)에 액세스할 수 있고, Exchange 설치 프로그램에서 만든 모든 기본 RBAC 역할이 올바르게 구성되어 있고, Exchange 조직 내부에 하나 이상의 관리 계정이 있는지 확인하는 테스트가 포함됩니다.
네트워크 포트 사용 및 방화벽 강화
Windows Server 2008에는 기본적으로 사용되는 상태 저장 패킷 검사 방화벽으로서, 고급 보안 기능을 가진 Windows 방화벽이 포함됩니다. 고급 보안 기능을 가진 Windows 방화벽은 다음 기능을 제공합니다.
컴퓨터를 드나드는 모든 IP 버전 4(IPv4) 및 IP 버전 6(IPv6) 트래픽 필터링. 수신 트래픽이 컴퓨터에서 보내는 이전 요청(요청된 트래픽)에 대한 응답이 아니거나 그 트래픽을 허용하기 위해 만든 규칙에서 특별히 허용되지 않는 경우, 기본적으로 모든 수신 트래픽이 차단됩니다. 표준 서비스가 예기치 않은 방식으로 통신하지 못하도록 하는 서비스 강화 규칙을 제외하면, 기본적으로 모든 발신 트래픽이 허용됩니다. 포트 번호, IPv4 또는 IPv6 주소, 응용 프로그램의 경로와 이름, 컴퓨터에서 실행 중인 서비스의 이름 또는 다른 기준을 바탕으로 트래픽을 허용하도록 선택할 수 있습니다.
네트워크 트래픽의 무결성을 확인하고 발신 및 수신 컴퓨터 또는 사용자의 ID를 인증하고 기밀 제공을 위해 트래픽을 선택적으로 암호화하기 위한 IPsec 프로토콜을 사용하여 컴퓨터를 드나드는 네트워크 트래픽을 보호합니다.
Exchange 2010은 고급 보안을 사용하는 Windows Server 방화벽에서 작동합니다. Exchange 설치 프로그램에서는 Exchange 서비스 및 프로세스의 통신을 허용하기 위해 필수적인 방화벽 규칙을 만듭니다. 주어진 서버 역할에 설치된 서비스와 프로세스에 필요한 규칙만 만듭니다. 네트워크 포트 사용과 각 Exchange 2010 서버 역할을 위해 만들어진 방화벽 규칙에 대한 자세한 내용은 Exchange 네트워크 포트 참조를 확인하십시오.
Windows Server 2008 및 Windows Server 2008 R2에서 고급 보안이 포함된 Windows 방화벽을 사용하여 포트를 열 프로세스 또는 서비스를 지정할 수 있습니다. 이 방법은 규칙에 지정된 프로세스 또는 서비스에 대한 포트 사용을 제한하므로 보다 안전합니다. Exchange 2010 설치 프로그램은 지정된 프로세스 이름으로 방화벽 규칙을 만듭니다. 경우에 따라 호환성을 목적으로 프로세스에 제한되지 않는 추가 규칙도 만들 수 있습니다. 프로세스에 제한되지 않는 규칙을 사용하지 않도록 설정하거나 제거하고 Exchange 2010 설치 프로그램에서도 만들고 배포에서 지원하는 경우 프로세스에 제한되는 해당 규칙을 유지할 수 있습니다. 프로세스에 제한되지 않는 규칙은 규칙 이름에 (GFW) 단어를 사용하여 구별합니다. 사용 환경에서 해당 규칙을 충분히 테스트한 후 특정 프로세스에 제한되지 않는 규칙을 사용하지 않도록 설정하는 것이 좋습니다.
다음 표에는 Exchange 설치 프로그램에서 만들어지는 Windows 방화벽 규칙이 나와 있습니다(예: 각 서버 역할에서 열리는 포트).
Windows 방화벽 규칙
| 규칙 이름 | 서버 역할 | 포트 |
|---|---|---|
MSExchangeRPCEPMap(GFW)(TCP-In) |
모든 역할 |
RPC-EPMap |
MSExchangeRPC(GFW)(TCP-In) |
클라이언트 액세스, 허브 전송, 사서함, 통합 메시징 |
동적 RPC |
MSExchange - IMAP4(GFW)(TCP-In) |
클라이언트 액세스 |
143, 993(TCP) |
MSExchange - POP3(GFW)(TCP-In) |
클라이언트 액세스 |
110, 995(TCP) |
MSExchange - OWA(GFW)(TCP-In) |
클라이언트 액세스 |
5075, 5076, 5077(TCP) |
MSExchangeMailboxReplication(GFW)(TCP-In) |
클라이언트 액세스 |
808(TCP) |
MSExchangeIS(GFW)(TCP-In) |
사서함 |
6001, 6002, 6003, 6004(TCP) |
MSExchangeTransportWorker(GFW)(TCP-In) |
허브 전송 |
25, 587(TCP) |
SESWorker(GFW)(TCP-In) |
통합 메시징 |
모두 |
UMService(GFW)(TCP-In) |
통합 메시징 |
5060, 5061(TCP) |
UMWorkerProcess(GFW)(TCP-In) |
통합 메시징 |
5065, 5066, 5067, 5068 |
중요
Exchange 2010 서비스에서 사용하는 기본 포트를 수정할 때, 사용하기로 한 기본 포트 이외의 포트를 통해 통신을 허용하도록 고급 보안 방화벽 규칙이 적용된 해당 Windows 방화벽도 수정해야 합니다. Exchange 2010에서는 특정 서비스에 사용되는 기본 포트를 변경할 때 방화벽 규칙을 변경하지 않습니다.
제한 매개 변수 및 클라이언트 제한 정책
Exchange 2010에는 각 프로토콜과 관련된 다양한 연결 매개 변수를 제어하기 위해 전송, 클라이언트 액세스 서버 및 사서함 서버 역할에 대한 제한 매개 변수가 포함됩니다. Exchange 2010에는 클라이언트 액세스 서버에 대한 부하를 제어하기 위한 클라이언트 제한 정책도 포함됩니다. 이런 제한 매개 변수와 정책은 부하를 제어하고 다른 프로토콜을 대상으로 하는 서비스 거부 공격으로부터 Exchange 2010 서버를 보호하는 데 도움이 됩니다.
전송 서버에 대한 제한 매개 변수
Exchange 2010 전송 서버에서는 메시지 처리 속도, SMTP 연결 속도 및 SMTP 세션 시간 제한 값을 제어하기 위해 서버와 전송 및 수신 커넥터에 메시지 제한 매개 변수가 구현됩니다. 이와 함께, 이런 제한 매개 변수는 많은 메시지를 받고 전달하여 전송 서버의 성능이 저하되지 않도록 보호함으로써, Rogue SMTP 클라이언트 및 서비스 거부 공격으로부터 보호합니다.
Set-TransportServer cmdlet을 사용하여 Exchange 2010 전송 서버에 대해 다음 제한 정책을 구성할 수 있습니다.
전송 서버 제한 매개 변수
| 매개 변수 | 설명 |
|---|---|
MaxConcurrentMailboxDeliveries |
MaxConcurrentMailboxDeliveries 매개 변수는 허브 전송 서버에서 메시지를 사서함으로 배달하기 위해 동시에 열어 놓을 수 있는 최대 배달 스레드 수를 지정합니다. 허브 전송 서버의 저장소 드라이버는 사서함 서버로 보내고 받는 메시지의 배달을 담당합니다. 이러한 제한은 Exchange 조직의 모든 사서함으로 배달되는 메시지에 적용됩니다. 기본값 20개 배달 |
MaxConcurrentMailboxSubmissions |
MaxConcurrentMailboxSubmissions 매개 변수는 허브 전송 서버에서 사서함의 메시지를 수락하기 위해 동시에 열어 놓을 수 있는 최대 배달 스레드 수를 지정합니다. 허브 전송 서버의 저장소 드라이버는 사서함 서버로 보내고 받는 메시지의 배달을 담당합니다. 이러한 제한은 Exchange 조직의 모든 사서함으로부터 받는 새 메시지에 적용됩니다. 기본값 20개 전송 |
MaxConnectionRatePerMinute |
MaxConnectionRatePerMinute 매개 변수는 허브 전송 서버 또는 Edge 전송 서버에서 열 수 있는 새 인바운드 연결의 최대 속도를 지정합니다. 이러한 연결은 서버에 있는 모든 수신 커넥터에 대해 열립니다. 기본값 분당 1,200개의 연결 |
MaxOutboundConnections |
MaxOutboundConnections 매개 변수는 허브 전송 서버 또는 Edge 전송 서버가 동시에 열 수 있는 최대 동시 아웃바운드 연결 수를 지정합니다. 아웃바운드 연결은 서버에 있는 송신 커넥터를 사용하여 수행됩니다. MaxOutboundConnections 매개 변수에 지정된 값은 전송 서버에 있는 모든 송신 커넥터에 적용됩니다. 기본값 1,000개 연결 무제한 값을 입력하면 아웃바운드 연결 수 제한이 없어집니다. 이 값은 EMC를 사용하여 구성할 수도 있습니다. |
MaxPerDomainOutboundConnections |
MaxPerDomainOutboundConnections 매개 변수는 인터넷 연결 허브 전송 서버 또는 Edge 전송 서버가 단일 원격 도메인에 대해 열 수 있는 최대 연결 수를 지정합니다. 원격 도메인에 대한 아웃바운드 연결은 서버에 있는 송신 커넥터를 사용하여 수행됩니다. 기본값 도메인당 20개의 연결 무제한 값을 입력하면 도메인당 아웃바운드 연결 수 제한이 없어집니다. 이 값은 EMC를 사용하여 구성할 수도 있습니다. |
PickupDirectoryMaxMessagesPerMinute |
MaxPerDomainOutboundConnections 매개 변수는 Pickup 디렉터리 및 Replay 디렉터리에 대한 메시지 처리 속도를 지정합니다. 각 디렉터리는 PickupDirectoryMaxMessagesPerMinute 매개 변수에 의해 지정된 속도로 메시지 파일을 개별적으로 처리할 수 있습니다. 기본값 기본적으로 Pickup 디렉터리는 분당 100개의 메시지를 처리할 수 있으며 Replay 디렉터리는 분당 100개의 메시지를 동시에 처리할 수 있습니다. Pickup 디렉터리 및 Replay 디렉터리는 5초마다 한 번씩 또는 분당 12번씩 새 메시지 파일을 검색합니다. 이 5초 폴링 간격은 구성할 수 없습니다. 즉, 각 폴링 간격 동안 처리할 수 있는 최대 메시지 수는 PickupDirectoryMaxMessagesPerMinute 매개 변수에 할당한 값을 12로 나눈 값(PickupDirectoryMaxMessagesPerMinute/12)입니다. 기본적으로 5초 폴링 간격마다 최대 8개의 메시지를 처리할 수 있습니다. |
송신 커넥터에 대한 제한 매개 변수
송신 커넥터에 다음 제한 매개 변수를 사용할 수 있습니다. Send-Connector cmdlet을 사용하여 이런 매개 변수를 구성합니다.
송신 커넥터 제한 매개 변수
| 매개 변수 | 설명 |
|---|---|
ConnectionInactivityTimeOut |
ConnectionInactivityTimeOut 매개 변수는 대상 메시징 서버와의 열린 SMTP 연결이 닫히기 전에 유휴 상태를 유지할 수 있는 최대 시간을 지정합니다. 기본값 10분 |
SmtpMaxMessagesPerConnection |
SmtpMaxMessagesPerConnection 매개 변수는 이 송신 커넥터 서버가 연결당 보낼 수 있는 최대 메시지 수를 지정합니다. 기본값 20개의 메시지 |
수신 커넥터에 대한 제한 매개 변수
Exchange 2010 전송 서버의 수신 커넥터에 대해 다음 제한 매개 변수를 구성하여 비활성 시간 제한, 최대 연결 개수 및 연결 중에 허용되는 SMTP 프로토콜 오류 개수와 같은 연결 매개 변수를 제어할 수 있습니다. Set-ReceiveConnector cmdlet을 사용하여 이런 매개 변수를 구성합니다.
수신 커넥터 제한 매개 변수
| 매개 변수 | 설명 |
|---|---|
ConnectionInactivityTimeOut |
ConnectionInactivityTimeOut 매개 변수는 원본 메시징 서버와의 열린 SMTP 연결이 닫히기 전에 유휴 상태를 유지할 수 있는 최대 시간을 지정합니다. 허브 전송 서버에서의 기본값 5분 Edge 전송 서버에서의 기본값 1분 |
ConnectionTimeOut |
ConnectionTimeOut 매개 변수는 원본 메시징 서버가 데이터를 전송 중인 경우에도 원본 메시징 서버와의 SMTP 연결이 열린 상태로 유지될 수 있는 최대 시간을 지정합니다. 허브 전송 서버에서의 기본값 10분 Edge 전송 서버에서의 기본값 5분 ConnectionTimeout 매개 변수에 지정된 값은 ConnectionInactivityTimeout 매개 변수에 지정된 값보다 커야 합니다. |
MaxInboundConnection |
MaxInboundConnection 매개 변수는 이 수신 커넥터가 동시에 허용하는 최대 인바운드 SMTP 연결 수를 지정합니다. 기본값 5,000 |
MaxInboundConnectionPercentagePerSource |
MaxInboundConnectionPercentagePerSource 매개 변수는 수신 커넥터가 단일 원본 메시징 서버에서 동시에 허용하는 최대 SMTP 연결 수를 지정합니다. 이 값은 수신 커넥터에서 사용 가능한 나머지 연결의 백분율로 표시됩니다. 수신 커넥터가 허용하는 최대 연결 수는 MaxInboundConnection 매개 변수로 정의됩니다. 기본값 2% |
MaxInboundConnectionPerSource |
MaxInboundConnectionPerSource 매개 변수는 수신 커넥터가 단일 원본 메시징 서버에서 동시에 허용하는 최대 SMTP 연결 수를 지정합니다. 기본값 100개 연결 |
MaxProtocolErrors |
MaxProtocolErrors 매개 변수는 수신 커넥터에서 원본 메시징 서버와의 연결을 닫기 전에 허용하는 최대 SMTP 프로토콜 오류 수를 지정합니다. 기본값 5개의 오류 |
POP3 서비스를 위한 제한 매개 변수
다음 제한 매개 변수는 클라이언트 액세스 서버에서 MicrosoftExchange POP3 서비스에 사용할 수 있습니다. Set-POPSettings cmdlet을 사용하여 이런 매개 변수를 구성합니다. 자세한 내용은 POP3에 대한 연결 제한 설정을 참조하십시오.
POP3 서비스 제한 매개 변수
| 매개 변수 | 설명 |
|---|---|
MaxCommandSize |
MaxCommandSize 매개 변수는 단일 명령의 최대 크기를 지정합니다. 40바이트에서 1024바이트까지의 값을 사용할 수 있습니다. 기본값 40바이트 |
MaxConnectonFromSingleIP |
MaxConnectionFromSingleIP 매개 변수는 지정된 서버가 수락하는 단일 IP 주소의 연결 수를 지정합니다. 가능한 값은 1에서 25,000까지입니다. 기본값 2,000개 연결 |
MaxConnections |
MaxConnections 매개 변수는 지정된 서버가 수락하는 총 연결 수를 지정합니다. 여기에는 인증된 연결과 인증되지 않은 연결이 모두 포함됩니다. 가능한 값은 1에서 25,000까지입니다. 기본값 2,000개 연결 |
MaxConnectionsPerUser |
MaxConnectionsPerUser 매개 변수는 클라이언트 액세스 서버가 수락하는 특정 사용자의 최대 연결 수를 지정합니다. 가능한 값은 1에서 25,000까지입니다. 기본값 16개 연결 |
PreAuthenticationConnectionTimeOut |
PreAuthenticatedConnectionTimeout 매개 변수는 인증되지 않은 유휴 연결을 닫기 전까지 대기할 시간을 지정합니다. 10초에서 3,600초까지의 값을 사용할 수 있습니다. 기본값 60초 |
IMAP4 서비스를 위한 제한 매개 변수
다음 제한 매개 변수는 클라이언트 액세스 서버에서 MicrosoftExchange IMAP4 서비스에 사용할 수 있습니다. Set-IMAPSettings cmdlet을 사용하여 이런 매개 변수를 구성합니다. 자세한 내용은 IMAP4에 대한 연결 제한 설정를 참조하십시오.
IMAP4 서비스 제한 매개 변수
| 매개 변수 | 설명 |
|---|---|
AuthenticationConnectionTimeOut |
AuthenticatedConnectionTimeout 매개 변수는 유휴 상태의 인증된 연결을 닫기 전까지 대기할 기간을 지정합니다. 30초에서 86,400초까지의 값을 사용할 수 있습니다. 기본값 1,800초 |
MaxCommandSize |
MaxCommandSize 매개 변수는 단일 명령의 최대 크기를 지정합니다. 기본 크기는 40바이트입니다. 40바이트에서 1024바이트까지의 값을 사용할 수 있습니다. 기본값 40바이트 |
MaxConnectionFromSingleIP |
MaxConnectionFromSingleIP 매개 변수는 지정된 서버가 수락하는 단일 IP 주소의 연결 수를 지정합니다. 가능한 값은 1에서 25,000까지입니다. 기본값 2,000개 연결 |
MaxConnections |
MaxConnections 매개 변수는 지정된 서버가 수락하는 총 연결 수를 지정합니다. 여기에는 인증된 연결과 인증되지 않은 연결이 모두 포함됩니다. 가능한 값은 1에서 25,000까지입니다. 기본값 2,000개 연결 |
MaxConnectionsPerUser |
MaxConnectionsPerUser 매개 변수는 클라이언트 액세스 서버가 수락하는 특정 사용자의 최대 연결 수를 지정합니다. 가능한 값은 1에서 25,000까지입니다. 기본값 16개 연결 |
PreAuthenticatedConnectionTimeOut |
PreAuthenticatedConnectionTimeout 매개 변수는 인증되지 않은 유휴 연결을 닫기 전까지 대기할 시간을 지정합니다. 10초에서 3,600초까지의 값을 사용할 수 있습니다. 기본값 60초 |
클라이언트 제한 정책
Exchange 2010에서는 클라이언트 제한 정책을 사용하여 각 클라이언트 액세스 프로토콜에 대한 동시 연결 수, 클라이언트 세션이 LDAP 작업, RPC 작업 및 클라이언트 액세스 작업을 실행하는 데 사용할 수 있는 시간의 비율과 같은 매개 변수를 제어함으로써 클라이언트 액세스 서버 성능을 관리할 수 있습니다. 클라이언트 액세스 서버에 대한 일반적인 부하를 관리하기에 충분한 기본 클라이언트 제한 정책이 있습니다. 기본 정책 매개 변수를 수정하거나 배포 요구 사항을 충족하는 사용자 지정 정책을 만들 수 있습니다.
제한 정책은 다음 사용자 그룹과 액세스 방법에 적용됩니다.
익명 액세스
CPA(크로스-프레미스 액세스)
EAS(Exchange ActiveSync)
EWS(Exchange 웹 서비스)
IMAP
POP
OWA(Outlook Web App)
RCA(RPC 클라이언트 액세스)
이런 사용자 그룹(익명 액세스 및 CPA)과 액세스 방법(EAS, EWS, IMAP, OWA, POP, RCA) 각각에 대한 클라이언트 제한 정책에서 다음 제한 설정을 사용할 수 있습니다.
클라이언트 제한 정책 설정
| 제한 설정 | 익명 액세스 | CPA | EAS | EWS | IMAP | OWA | POP | RCA |
|---|---|---|---|---|---|---|---|---|
최대 동시성 |
예 |
예 |
예 |
예 |
예 |
예 |
예 |
예 |
AD의 시간 비율 |
예 |
해당 없음 |
예 |
예 |
예 |
예 |
예 |
예 |
CAS의 시간 비율 |
예 |
예 |
예 |
예 |
예 |
예 |
예 |
예 |
사서함 RPC의 시간 비율 |
예 |
예 |
예 |
예 |
예 |
예 |
예 |
예 |
CPA 크로스-프레미스 액세스
EAS Exchange ActiveSync
EWS Exchange 웹 서비스
OWA Outlook Web App
사용자 그룹과 액세스 방법을 바탕으로 한 이런 제한 설정 외에도, 클라이언트 제한 정책에서 다음 제한 설정을 사용할 수 있습니다.
클라이언트 제한 정책 매개 변수
| 매개 변수 | 설명 |
|---|---|
CPUStartPercent |
CPUStartPercent 매개 변수는 이 정책에서 제어하는 사용자가 백오프되기 시작하는 프로세스당 CPU 백분율을 지정합니다. 유효한 값은 0에서 100 사이입니다. $null을 사용하여 이 정책에 대한 CPU 백분율 기반 제한을 끌 수 있습니다. |
EASMaxDeviceDeletesPerMonth |
EASMaxDeviceDeletesPerMonth 매개 변수는 한 달에 한 번 삭제할 수 있는 Exchange ActiveSync 파트너 관계 수의 제한을 지정합니다. 기본적으로 각 사용자는 월별 일정에서 최대 20개 파트너 관계를 삭제할 수 있습니다. 제한에 도달하면 파트너 관계 삭제 시도가 실패하고 사용자에게 오류 메시지가 표시됩니다. |
EASMaxDevices |
EASMaxDevices 매개 변수는 사용자가 한 번에 보유할 수 있는 Exchange ActiveSync 파트너 관계 수에 대한 제한을 지정합니다. 기본적으로 각 사용자는 Exchange 계정이 있는 Exchange ActiveSync 파트너 관계 10개를 만들 수 있습니다. 사용자가 제한을 초과하면 새 파트너 관계를 만들기 전에 기존 파트너 관계 중 하나를 삭제해야 합니다. 제한이 초과되면 제한을 설명하는 전자 메일 오류 메시지가 사용자에게 보내집니다. 또한, 사용자가 제한을 초과하면 이벤트 로그가 응용 프로그램 로그에 로깅됩니다. |
EWSFastSearchTimeOutInSeconds |
EWSFastSearchTimeoutInSeconds 매개 변수는 Exchange 웹 서비스를 사용한 검색이 시간 초과되기 전에 계속되는 시간을 지정합니다. 검색이 정책 값에 표시된 시간보다 더 오래 걸릴 경우 검색이 중지되고 오류가 반환됩니다. 이 설정의 기본값은 60초입니다. |
EWSFindCountLimit |
EWSFindCountLimit 매개 변수는 이 현재 프로세스의 이 사용자에 대해 클라이언트 액세스 서버의 메모리에서 동시에 존재할 수 있는 FindItem 또는 FindFolder 호출의 최대 결과 크기를 지정합니다. 정책 제한에서 허용하는 것보다 더 많은 항목 또는 폴더를 찾으려 할 경우 오류가 반환됩니다. 하지만 인덱싱된 페이지 보기의 컨텍스트에서 호출되는 경우 제한이 엄격하게 적용되지 않습니다. 특히 이 시나리오에서는 정책 제한에 맞는 항목 및 폴더의 수를 포함하도록 검색 결과가 잘립니다. 그러면 추가 FindItem 또는 FindFolder 호출을 통해 결과 집합으로 계속 페이징할 수 있습니다. |
EWSMaxSubscriptions |
EWSMaxSubscriptions 매개 변수는 사용자가 특정 클라이언트 액세스 서버에서 동시에 보유할 수 있는 활성 밀어넣기 및 끌어오기 구독의 최대 개수를 지정합니다. 사용자가 구성된 최대값보다 더 많은 구독을 만들려고 할 경우 구독이 실패하며 이벤트가 이벤트 뷰어에 로깅됩니다. |
ExchangeMaxCmdlets |
ExchangeMaxCmdlets 매개 변수는 실행 속도가 느려지기 전에 특정 기간 안에 실행할 수 있는 cmdlet 수를 지정합니다. 이 매개 변수에 지정한 값은 PowerShellMaxCmdlets parameter에 지정한 값보다 작아야 합니다. 이 제한에 사용되는 기간은 PowerShellMaxCmdletsTimePeriod 매개 변수에 지정됩니다. 두 매개 변수에 대한 값을 동시에 설정하는 것이 좋습니다. |
ForwardeeLimit |
ForwardeeLimit 매개 변수는 전달 또는 리디렉션 작업을 사용할 때 받은 편지함 규칙에 구성할 수 있는 받는 사람 수에 대한 제한을 지정합니다. 이 매개 변수는 구성된 받는 사람에게 전달되거나 리디렉션될 수 있는 메시지 수를 제한하지 않습니다. |
MessageRateLimit |
MessageRateLimit 매개 변수는 전송하기 위해 전달할 수 있는 분당 메시지 수를 지정합니다. 사서함 서버 역할(Outlook Web App, Exchange ActiveSync 또는 Exchange 웹 서비스)을 통해 전송되는 메시지의 경우 이렇게 하면 사용자의 할당량을 사용할 수 있을 때까지 메시지가 지연됩니다. 특히 사용자가 MessageRateLimit 매개 변수보다 큰 비율로 메시지를 전송할 때 메시지가 오랫동안 보낸 편지함 또는 임시 보관함 폴더에 표시됩니다. SMTP를 사용하여 메시지를 직접 전송하는 POP 또는 IMAP 클라이언트의 경우 클라이언트가 MessageRateLimit 매개 변수를 초과하는 비율로 전송하면 클라이언트에 일시적인 오류가 발생합니다. Exchange는 나중에 연결하여 메시지를 보내려 합니다. |
PowerShellMaxCmdletQueueDepth |
PowerShellMaxCmdletQueueDepth 매개 변수는 사용자에게 실행이 허용된 작업 수를 지정합니다. 이 값은 PowerShellMaxCmdlets 및 PowerShellMaxConcurrency 매개 변수의 동작에 직접 영향을 줍니다. 예를 들면 PowerShellMaxConcurrency 매개 변수는 PowerShellMaxCmdletQueueDepth 매개 변수에 정의된 두 가지 이상의 작업을 사용하지만 cmdlet 실행에 따라 추가 작업이 사용되기도 합니다. 작업 수는 실행되는 cmdlet에 따라 달라집니다. PowerShellMaxCmdletQueueDepth 매개 변수의 값은 PowerShellMaxConcurrency parameter의 값보다 최소 3배 이상 크게 설정하는 것이 좋습니다. 이 매개 변수는 Exchange 제어판 작업이나 Exchange 웹 서비스 작업에 영향을 주지 않습니다. |
PowerShellMaxCmdlets |
PowerShellMaxCmdlets 매개 변수는 실행이 중지되기 전에 특정 시간 안에 실행할 수 있는 cmdlet 수를 지정합니다. 이 매개 변수에 지정한 값은 ExchangeMaxCmdlets 매개 변수에 지정한 값보다 커야 합니다. 이 제한에 사용되는 기간은 PowerShellMaxCmdletsTimePeriod 매개 변수에 지정됩니다. 두 값을 동시에 설정해야 합니다. |
PowerShellMaxCmdletsTimePeriod |
PowerShellMaxCmdletsTimePeriod 매개 변수는 제한 정책에서 실행되는 cmdlet 수가 PowerShellMaxCmdlets 및 ExchangeMaxCmdlets 매개 변수에 지정한 값을 초과하는지 여부를 결정하는 데 사용하는 기간(초)을 지정합니다. |
PowerShellMaxConcurrency |
PowerShellMaxConcurrency 매개 변수는 컨텍스트에 따라 다양한 정보를 지정합니다. 원격 PowerShell 컨텍스트에서 PowerShellMaxConcurrency 매개 변수는 원격 PowerShell 사용자가 동시에 열 수 있는 최대 원격 PowerShell 세션 수를 지정합니다. Exchange 웹 서비스 컨텍스트에서 PowerShellMaxConcurrency 매개 변수는 사용자가 동시에 보유할 수 있는 최대 cmdlet 실행 수를 지정합니다. 이 매개 변수 값은 반드시 사용자가 연 브라우저 수와 관련될 필요는 없습니다. |
RecipientRateLimit |
RecipientRateLimit 매개 변수는 사용자가 24시간 안에 지정할 수 있는 받는 사람 수에 대한 제한을 지정합니다. |
Exchange 2010 제한 정책에 대한 자세한 내용은 클라이언트 제한 정책 이해를 참조하십시오.
역할 기반 액세스 제어
RBAC(역할 기반 액세스 제어)는 관리자와 사용자가 수행할 수 있는 작업을 폭넓고 세부적인 수준으로 제어할 수 있는 Exchange 2010의 새로운 사용 권한 모델입니다. RBAC를 사용하면 기술 지원팀 운영자와 같은 그룹에 사용 권한을 세부적으로 위임하도록 허용하거나 받는 사람 관리와 같은 기능을 위해 조직 구성 단위 및 컨테이너와 같은 Active Directory 개체에 대한 ACL(액세스 제어 목록)을 수정하지 않아도 됩니다. Active Directory
자세한 내용은 역할 기반 액세스 제어 이해를 참조하십시오. Exchange 2010에 포함된 기본 RBAC 관리 역할의 목록은 기본 제공 관리 역할을 참조하십시오. 기본 역할 그룹의 목록은 기본 제공 역할 그룹을 참조하십시오.
Exchange 2010 설치 프로그램이나 사용자가 만든 역할 그룹은 Active Directory에서 MicrosoftExchange 보안 그룹 OU에 유니버설 보안 그룹으로 만들어집니다. New-RoleGroupMember cmdlet 또는 ECP(Exchange 제어판)를 사용하여 역할 그룹에 구성원을 추가할 수 있습니다. 역할 그룹에 구성원을 추가하면 해당 Active Directory 보안 그룹에 사용자나 그룹이 추가됩니다. 제한된 그룹 정책을 사용하여 Discovery Management와 같은 중요한 RBAC 역할 그룹에 대한 구성원을 제한할 수 있습니다. 제한된 그룹 정책을 구현할 때, 그룹 구성원 자격은 Active Directory 도메인 컨트롤러에 의해 모니터링되고 이 정책에 포함되지 않는 사용자는 모두 자동으로 제거됩니다.
중요
제한된 그룹을 사용하여 RBAC 역할 그룹에 대한 그룹 구성원 자격을 제한하는 경우, Exchange 2010 도구를 사용하여 역할 그룹을 변경하면 Active Directory에서 제한된 그룹 정책도 변경해야 합니다. 자세한 내용은 그룹 정책 보안 설정(영문)을 참조하십시오.
Active Directory
Exchange 서버는 구성 파티션에 구성 데이터를 저장하고 AD DS(Active Directory 도메인 서비스)의 도메인 파티션에 받는 사람 데이터를 저장합니다. Exchange 2010 조직을 설치하는 데 필요한 사용 권한에 대한 자세한 내용은 Exchange 2010 배포 권한 참조를 확인하십시오. Active Directory 도메인 컨트롤러와의 통신은 Kerberos 인증 및 암호화를 사용하여 보안이 유지됩니다.
Exchange 2010은 적절한 사용 권한을 요구하는 모든 계정에 대해 ACE(액세스 제어 항목)를 적용하는 대신, Exchange 내에서 RBAC(역할 기반 액세스 제어)라고 알려진 새 권한 부여 계층을 제공합니다. Microsoft Exchange의 이전 버전에서는 Exchange 설치 프로그램이 도메인 파티션 내부의 개체를 관리할 수 있는 Exchange용 Active Directory 관리자 내부의 ACE에 의존했습니다. Exchange 관리자에게는 RBAC를 통해 특정 범위 내에서 일정한 작업을 수행할 수 있는 권한이 부여됩니다. Exchange 서버는 ExchangeWindows 사용 권한과 Exchange Trusted Subsystem 보안 그룹을 통해 Active Directory 내부에서 부여된 사용 권한을 사용하여 관리자 또는 사용자를 대신하여 권한이 부여된 작업을 실행합니다. RBAC에 대한 자세한 내용은 역할 기반 액세스 제어 이해를 참조하십시오.
Exchange 2010에서 /PrepapareDomain은 ExchangeWindows 사용 권한 유니버설 보안 그룹에 대한 ACE를 Active Directory에 있는 AdminSDHolder 컨테이너에 적용하지 않습니다. /PrepareDomain에서 ExchangeWindows 사용 권한 유니버설 보안 그룹에 부여된 ACE를 검색하면 ACE가 제거됩니다. 여기에는 다음과 같은 의미가 있습니다.
ExchangeWindows 사용 권한 유니버설 보안 그룹의 구성원은 Enterprise Admins 및 Domain Admins와 같이 보호되는 보안 그룹의 구성원 자격을 수정할 수 없습니다. 여기에는 다음과 같은 의미가 있습니다.
ExchangeWindows 사용 권한 유니버설 보안 그룹의 구성원은 AdminSDHolder에 의해 보호되는 계정의 암호를 강제로 원래대로 설정할 수 없습니다.
ExchangeWindows 사용 권한 유니버설 보안 그룹의 구성원은 AdminSDHolder에 의해 보호되는 그룹이나 계정의 사용 권한을 변경할 수 없습니다.
AdminSDHolder에 의해 보호되는 계정에서 사서함 사용이 가능하게 하지 말고 Active Directory 관리자를 위한 별개의 계정을 유지 관리할 것을 모범 사례로서 권장합니다. 즉, Active Directory 관리를 위한 계정 하나와 전자 메일을 포함하여 일상적으로 사용하기 위한 계정 하나를 두는 것이 좋습니다. 자세한 내용은 다음 항목을 참조하십시오.
Exchange Server 계정
Exchange 2010 설치 프로그램은 MicrosoftExchange 보안 그룹이라는 루트 도메인에 새 OU(조직 구성 단위)를 만듭니다. 다음 표는 새 유니버설 보안 그룹을 나타낸 것입니다.
Microsoft Exchange 보안 그룹
| 보안 그룹 | 설명 |
|---|---|
Exchange All Hosted Organizations |
이 그룹에는 모든 Exchange Hosted Organization 사서함 그룹이 포함됩니다. 이 그룹은 호스트된 모든 사서함에 암호 설정 개체를 적용하는 데 사용됩니다. 이 그룹을 삭제하면 안 됩니다. |
Exchange Servers |
이 그룹에는 모든 Exchange 서버가 포함됩니다. 이 그룹을 삭제하면 안 됩니다. 이 그룹의 구성원은 절대 변경하지 마십시오. |
Exchange Trusted Subsystem |
이 그룹에는 관리 서비스를 통해 사용자를 대신하여 Exchange cmdlet을 실행하는 Exchange 서버가 포함됩니다. 이 그룹의 구성원은 모든 Exchange 구성과 사용자 계정 및 그룹을 읽고 수정할 수 있는 사용 권한을 가지게 됩니다. 이 그룹을 삭제하면 안 됩니다. |
ExchangeWindows 사용 권한 |
이 그룹에는 관리 서비스를 통해 사용자를 대신하여 Exchange cmdlet을 실행하는 Exchange 서버가 포함됩니다. 이 그룹의 구성원은 모든 Windows 계정 및 그룹을 읽고 수정할 수 있는 사용 권한을 가지게 됩니다. 이 그룹을 삭제하면 안 됩니다. 이 그룹의 구성원은 절대 변경하지 말고 그룹 구성원을 모니터링하는 것이 좋습니다. |
ExchangeLegacyInterop |
이 그룹은 같은 포리스트 내에 있는 Exchange 2003 서버와의 상호 운용성을 위한 것입니다. 이 그룹을 삭제하면 안 됩니다. |
이런 보안 그룹 외에, 설치 프로그램에서는 같은 이름을 가진 RBAC 역할 그룹에 해당하는 다음 보안 그룹도 만듭니다.
RBAC 역할 그룹에 해당하는 보안 그룹
| 보안 그룹 | RBAC 역할 그룹 |
|---|---|
Delegated Setup |
|
Discovery Management |
|
Help Desk |
|
Hygiene Management |
|
Organization Management |
|
Public Folder Management |
|
Recipient Management |
|
Records Management |
|
Server Management |
|
UM Management |
|
View-Only Organization Management |
또한, 새 역할 그룹을 만들 때 Exchange 2010에서는 역할 그룹과 같은 이름을 가진 보안 그룹을 만듭니다. 자세한 내용은 다음 항목을 참조하십시오.
Add-RoleGroupMember 또는 Remove-RoleGroupMember cmdlet을 사용하거나 ECP에서 RBAC(역할 기반 액세스 제어) 사용자 편집기를 사용하여 역할 그룹에 사용자를 추가하거나 제거할 때 이런 보안 그룹에 사용자가 추가되거나 제거됩니다.
파일 시스템
Exchange 2010 설치 프로그램에서는 Exchange 2010의 작동에 필수적인 최소 사용 권한을 가진 디렉터리를 만듭니다. 설치 프로그램에서 만든 디렉터리의 기본 ACL(액세스 제어 목록)에 사용 권한을 추가로 강화하지 않는 것이 좋습니다.
서비스
Exchange 2010 설치 프로그램에서는 기본적으로 어떤 Windows 서비스도 사용하지 않도록 설정하지 않습니다. 다음 표는 각 서버 역할에 대해 기본적으로 사용되는 서비스를 표시한 것입니다. 특정 Exchange 2010 서버 역할의 작업에 필요한 서비스만 기본적으로 사용됩니다.
Exchange 설치 프로그램으로 설치되는 서비스
| 서비스 이름 | 서비스 약식 이름 | 보안 컨텍스트 | 설명 및 종속성 | 기본 시작 유형 | 서버 역할 | 필수(R) 또는 옵션(O) |
|---|---|---|---|---|---|---|
Microsoft ExchangeActive Directory 토폴로지 |
MSExchangeADTopology |
로컬 시스템 |
Exchange 서비스에 Active Directory 토폴로지 정보를 제공합니다. 이 서비스가 중지되면 대부분의 Exchange 서비스를 시작할 수 없습니다. 이 서비스에는 종속성이 없습니다. |
자동 |
사서함, 허브 전송, 클라이언트 액세스, 허브 전송, 통합 메시징 |
R |
Microsoft Exchange ADAM |
ADAM_MSExchange |
네트워크 서비스 |
Edge 전송 서버에 구성 데이터 및 받는 사람 데이터를 저장합니다. 이 서비스는 Edge 전송 서버를 설치하는 동안 설치 프로그램에 의해 자동적으로 만들어진 AD LDS(Active Directory Lightweight Directory Service)의 명명된 인스턴스를 나타냅니다. 이 서비스는 COM + 이벤트 시스템 서비스에 따라 다릅니다. |
자동 |
Edge 전송 |
R |
Microsoft Exchange 주소록 |
MSExchangeAB |
로컬 시스템 |
클라이언트 주소록 연결을 관리합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
자동 |
클라이언트 액세스 |
R |
Microsoft Exchange 스팸 방지 업데이트 |
MSExchangeAntispamUpdate |
로컬 시스템 |
MicrosoftForefront Protection 2010 for Exchange Server 스팸 방지 업데이트 서비스를 제공합니다. 허브 전송 서버에서 이 서비스는 Microsoft Exchange Active Directory 토폴로지 서비스에 따라 다릅니다. Edge 전송 서버에서 이 서비스는 Microsoft Exchange ADAM 서비스에 따라 다릅니다. |
자동 |
허브 전송, Edge 전송 |
O |
Microsoft Exchange 자격 증명 서비스 |
MSExchangeEdgeCredential |
로컬 시스템 |
AD LDS의 자격 증명 변경 내용을 모니터링하고 Edge 전송 서버에 해당 변경 내용을 설치합니다. 이 서비스는 Microsoft Exchange ADAM 서비스에 따라 다릅니다. |
자동 |
Edge 전송 |
R |
Microsoft Exchange EdgeSync |
MSExchangeEdgeSync |
로컬 시스템 |
허브 전송 서버와 Edge 전송 서버 간의 데이터를 동기화하기 위해 LDAP 보안 채널을 통해 구독 Edge 전송 서버의 AD LDS 인스턴스에 연결합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. Edge 구독이 구성되어 있지 않은 경우 이 서비스는 사용하지 않도록 설정될 수 있습니다. |
자동 |
허브 전송 |
O |
Microsoft Exchange 파일 배포 |
MSExchangeFDS |
로컬 시스템 |
OAB(오프라인 주소록) 및 사용자 지정 통합 메시징 음성 안내를 배포합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 및 워크스테이션 서비스에 따라 다릅니다. |
자동 |
클라이언트 액세스, 통합 메시징 |
R |
Microsoft Exchange 폼 기반 인증 |
MSExchangeFBA |
로컬 시스템 |
Outlook Web App 및 Exchange 제어판에 폼 기반 인증을 제공합니다. 이 서비스가 중지되면 Outlook Web App 및 Exchange 제어판은 사용자를 인증하지 않습니다. 이 서비스에는 종속성이 없습니다. |
자동 |
클라이언트 액세스 |
R |
Microsoft Exchange IMAP4 |
MSExchangeIMAP4 |
네트워크 서비스 |
클라이언트에 IMAP4 서비스를 제공합니다. 이 서비스가 중지되면 클라이언트가 IMAP4 프로토콜을 사용하여 이 컴퓨터에 연결할 수 없습니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
수동 |
클라이언트 액세스 |
O |
Microsoft Exchange 정보 저장소 |
MSExchangeIS |
로컬 시스템 |
Exchange 정보 저장소를 관리합니다. 여기에는 사서함 데이터베이스와 공용 폴더 데이터베이스가 포함됩니다. 이 서비스가 중지되면 이 컴퓨터에 있는 사서함 데이터베이스와 공용 폴더 데이터베이스를 사용할 수 없습니다. 이 서비스를 사용할 수 없을 경우 이 서비스에 명시적으로 종속된 다른 서비스를 시작할 수 없습니다. 이 서비스는 RPC, 서버, Windows 이벤트 로그 및 Workstation 서비스에 종속됩니다. |
자동 |
사서함 |
R |
Microsoft Exchange 메일 전송 서비스 |
MSExchangeMailSubmission |
로컬 시스템 |
사서함 서버의 메시지를 Exchange 2010 허브 전송 서버에 전송합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
자동 |
사서함 |
R |
Microsoft Exchange 사서함 도우미 |
MSExchangeMailboxAssistants |
로컬 시스템 |
Exchange 저장소에서 사서함을 백그라운드 처리합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
자동 |
사서함 |
R |
Microsoft Exchange 사서함 복제 서비스 |
MSExchangeMailboxReplication |
로컬 시스템 |
사서함 이동 및 이동 요청을 처리합니다. 이 서비스는 Microsoft Exchange Active Directory 토폴로지 및 Net.Tcp 포트 공유 서비스에 따라 다릅니다. |
자동 |
클라이언트 액세스 |
O |
Microsoft Exchange 모니터링 |
MSExchangeMonitoring |
로컬 시스템 |
응용 프로그램에서 Exchange 진단 cmdlet을 호출하도록 허용합니다. 이 서비스에는 종속성이 없습니다. |
수동 |
모두 |
O |
Microsoft Exchange POP3 |
MSExchangePOP3 |
네트워크 서비스 |
POP3 서비스를 클라이언트에 제공합니다. 이 서비스가 중지되면 클라이언트가 POP3 프로토콜을 사용하여 이 컴퓨터에 연결할 수 없습니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
수동 |
클라이언트 액세스 |
O |
Microsoft Exchange 보호된 서비스 호스트 |
MSExchangeProtectedServiceHost |
로컬 시스템 |
다른 서비스로부터 보호되어야 하는 여러 Exchange 서비스를 위한 호스트를 제공합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
자동 |
허브 전송, 클라이언트 액세스 |
R |
Microsoft Exchange 복제 서비스 |
MSExchangeRepl |
로컬 시스템 |
DAG(데이터베이스 가용성 그룹)에 있는 사서함 서버의 사서함 데이터베이스에 복제 기능을 제공합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
자동 |
사서함 |
O |
Microsoft Exchange RPC 클라이언트 액세스 |
MSExchangeRPC |
네트워크 서비스 |
Exchange용 클라이언트 RPC 연결을 관리합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
자동 |
사서함, 클라이언트 액세스 |
O(사서함), R(클라이언트 액세스) |
Microsoft Exchange 검색 인덱서 |
MSExchangeSearch |
로컬 시스템 |
사서함 콘텐츠의 인덱싱을 수행하여 콘텐츠 검색 성능을 향상합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 및 Microsoft 검색(Exchange Server) 서비스에 따라 다릅니다. |
자동 |
사서함 |
O |
Windows Server 백업용 Microsoft Exchange Server 확장 |
WSBExchange |
로컬 시스템 |
Windows Server 백업 사용자가 Microsoft Exchange용 응용 프로그램 데이터를 백업하고 복구할 수 있습니다. 이 서비스에는 종속성이 없습니다. |
수동 |
사서함 |
O |
Microsoft Exchange 서비스 호스트 |
MSExchangeServiceHost |
로컬 시스템 |
여러 Exchange 서비스에 호스트를 제공합니다. 내부 서버 역할에서 이 서비스는 Microsoft Exchange Active Directory 토폴로지 서비스에 따라 다릅니다. Edge 전송 서버에서 이 서비스는 Microsoft Exchange ADAM 서비스에 따라 다릅니다. |
자동 |
모두 |
R |
Microsoft Exchange 음성 엔진 |
MSSpeechService |
네트워크 서비스 |
통합 메시징에 대한 음성 처리 서비스를 제공합니다. 이 서비스는 WMI(Windows Management Instrumentation) 서비스에 따라 다릅니다. |
자동 |
통합 메시징 |
R |
Microsoft Exchange 시스템 수행자 |
MSExchangeSA |
로컬 시스템 |
레거시 Outlook 클라이언트의 글로벌 카탈로그 서버에 디렉터리 조회를 전달하고, 전자 메일 주소 및 OAB를 생성하고, 레거시 클라이언트의 약속 있음/없음 정보를 업데이트하고, 서버에 대한 사용 권한 및 그룹 구성원을 유지 관리합니다. 이 서비스를 사용할 수 없을 경우 이 서비스에 명시적으로 종속된 다른 서비스를 시작할 수 없습니다. 이 서비스는 RPC, 서버, Windows 이벤트 로그 및 Workstation 서비스에 종속됩니다. |
자동 |
사서함 |
R |
Microsoft Exchange 제한 |
MSExchangeThrottling |
네트워크 서비스 |
사용자 작업의 비율을 제한합니다. 이 서비스는 Microsoft ExchangeActive Directory 토폴로지 서비스에 따라 다릅니다. |
자동 |
사서함 |
R |
Microsoft Exchange 전송 |
MSExchangeTransport |
네트워크 서비스 |
SMTP 서버 및 전송 스택을 제공합니다. 허브 전송 서버에서 이 서비스는 Microsoft Exchange Active Directory 토폴로지 서비스에 따라 다릅니다. Edge 전송 서버에서 이 서비스는 Microsoft Exchange ADAM 서비스에 따라 다릅니다. |
자동 |
허브 전송, Edge 전송 |
R |
Microsoft Exchange 전송 로그 검색 |
MSExchangeTransportLogSearch |
로컬 시스템 |
Microsoft Exchange 전송 로그 파일에 대한 원격 검색 기능을 제공합니다. 허브 전송 서버에서 이 서비스는 Microsoft Exchange Active Directory 토폴로지 서비스에 따라 다릅니다. Edge 전송 서버에서 이 서비스는 Microsoft Exchange ADAM 서비스에 따라 다릅니다. |
자동 |
허브 전송, 사서함, Edge 전송 |
O |
Microsoft Exchange 통합 메시징 |
MSExchangeUM |
로컬 시스템 |
Microsoft Exchange 통합 메시징 기능을 사용합니다. 이 서비스는 음성 및 팩스 메시지를 Exchange에 저장하고 사용자가 전자 메일, 음성 메일, 일정, 연락처 또는 자동 전화 교환에 전화로 액세스할 수 있도록 합니다. 이 서비스가 중지되면 통합 메시징을 사용할 수 없습니다. 이 서비스는 Microsoft Exchange Active Directory 토폴로지 및 Microsoft Exchange 음성 엔진 서비스에 따라 다릅니다. |
자동 |
통합 메시징 |
R |
Microsoft 검색(Exchange Server) |
msftesql-Exchange |
로컬 시스템 |
이는 Microsoft 검색의 Microsoft Exchange 사용자 지정 버전입니다. 이 서비스는 RPC 서비스에 종속됩니다. |
수동 |
허브 전송, 사서함 |
O |
인증서
Exchange 2010 설치 프로그램에서는 자체 서명 인증서를 만들어 HTTP, SMTP, POP3 및 IMAP4와 같은 다른 프로토콜을 통한 통신의 보안을 설정합니다. 설치 프로그램에서 만드는 자체 서명 인증서는 5년간 유효합니다. 따라서 Exchange 2010 배포의 상당 부분에 대해 자체 서명 인증서를 갱신할 필요가 없고 메시징 서비스가 자체 서명 인증서 만료에 영향을 받지 않습니다.
Outlook Web App, POP3, IMAP4, Outlook Anywhere 및 AutoDiscover와 같은 외부 클라이언트 액세스 메커니즘 및 프로토콜의 경우 다음과 같이 하는 것이 좋습니다.
해당 서비스에 액세스하는 클라이언트에서 신뢰하는 상업용 CA(인증 기관)에서 서명한 인증서를 사용합니다.
새 Exchange 인증서 마법사 또는 New-ExchangeCertificate cmdlet을 사용하여 상업용 CA에 대한 인증서 서명 요청을 만듭니다. 이런 도구를 사용하여 생성되는 인증서 요청을 통해 모든 Exchange 인증서 요구 사항을 충족할 수 있습니다.
외부 클라이언트 액세스를 허용할 각 프로토콜 또는 서비스에 대한 인증서 요구 사항을 고려합니다.
클라이언트 액세스 서버에서 인증서는 SSL(Secure Sockets Layer)을 사용하여 HTTP 트래픽(Outlook Anywhere, Outlook Web App, AutoDiscover, Exchange ActiveSync 및 Exchange 웹 서비스)을 보호하고 SSL 또는 TLS(전송 계층 보안)를 사용하여 POP3 및 IMAP4 트래픽을 보호하는 데 사용됩니다. 자세한 내용은 클라이언트 액세스 서버용 SSL 관리를 참조하십시오.
전송 서버에서는 인증서가 TLS를 사용하여 SMTP 트래픽을 보호하는 데 사용됩니다. 자세한 내용은 TLS 인증서 이해를 참조하십시오.
통합 메시징 서버에서는 인증서가 VoIP(Voice over Internet Protocol) 트래픽을 보호하는 데 사용됩니다. 자세한 내용은 통합 메시징 VoIP 보안 이해를 참조하십시오.
페더레이션의 경우, 인증서는 MFG(Microsoft 페더레이션 게이트웨이) 및 페더레이션 파트너 조직과 교환되는 SAML 토큰을 암호화하는 데 사용됩니다. 자세한 내용은 페더레이션 이해를 참조하십시오.
서비스 중단을 피하려면 인증서 유효 날짜를 모니터링하고 적당한 시점에 CA에서 인증서를 갱신합니다.
연결된 개인 키로 내보낸 인증서를 저장할 때는 인증서가 저장되는 폴더/파일에 대해 알맞은 액세스 제어를 사용하여 내보낸 파일을 보호합니다. 조직의 보안 요구 사항에 따라, 개인 키를 포함한 인증서 파일이 저장되는 폴더에 대한 파일 액세스 감사를 사용하는 방안을 고려하십시오.
NTLM 고려 사항
NTLM 프로토콜은 Kerberos 프로토콜보다 보안 수준이 크게 떨어집니다. Exchange 2010에서 SecureLogin이 LoginType으로 지정되어 있을 때 POP3 및 IMAP4 프로토콜은 NTLM 인증을 지원하지 않습니다. 자세한 내용은 POP3 및 IMAP4에 대한 인증 구성을 참조하십시오. Windows 통합 인증을 사용하는 Exchange 2010 서비스는 NTLM 또는 Kerberos 프로토콜을 사용할 수 있습니다. Kerberos는 Exchange 2010 사서함 서버에 대한 클라이언트 액세스 서버 통신과 Outlook Web App, Exchange ActiveSync 및 Exchange 웹 서비스용 클라이언트 액세스 서버 간의 통신에 사용됩니다. NTLM을 사용하여 인증하는 서비스에 대한 자세한 내용은 Exchange 네트워크 포트 참조를 확인하십시오.
2단계 인증
2단계 인증 메커니즘에서는 PIN과 함께 스마트카드의 디지털 인증서나 임의로 생성되는 토큰과 같이, 사용자 로그온 자격 증명(사용자 이름 및 암호) 이외의 다른 인증자를 사용합니다. 많은 조직에서 조직 네트워크에 안전하게 액세스할 수 있도록 하기 위해 2단계 인증을 배포합니다.
Exchange 2010에는 2단계 인증을 위한 기본 지원이 포함되지 않습니다. Exchange 2010에서는 HTTP(AutoDiscover, Outlook Web App, Outlook Anywhere, Exchange ActiveSync 및 Exchange 웹 서비스)를 통한 클라이언트 액세스를 위해 IIS(Internet Information Server) 7을 사용합니다. 다양한 파트너와 타사에서 IIS와 통합되는 수많은 2단계 인증 제품을 공급하며, 이들 제품은 Outlook Web App 등의 Exchange 클라이언트 액세스 서비스에서 사용됩니다. Exchange 서비스를 위한 2단계 인증 제품을 배포하기 전에 이들 제품을 적절히 테스트하여 제품이 조직의 보안 요구 사항에 부합하고 필요한 기능을 제공하는지 확인하는 것이 좋습니다.
페더레이션
Exchange 2010에서는 페더레이션 Exchange 조직 간의 보안 공동 작업을 지원하는 새로운 페더레이션 기능이 도입되었습니다. Exchange 2010 조직에서는 Microsoft 페더레이션 게이트웨이로 페더레이션 트러스트를 만든 다음 다른 페더레이션 조직과 조직 관계를 설정하여 가용성 정보와 일정을 공유할 수 있습니다. 또한, 조직에서는 사용자가 공유 정책을 사용하여 외부 페더레이션 조직의 사용자와 가용성 정보, 일정 및 연락처를 공유하도록 허용할 수 있습니다. 페더레이션 트러스트와 페더레이션 공유에 대한 자세한 내용은 페더레이션 이해 및 페더레이션 위임 이해를 참조하십시오.
MFG와 페더레이션 트러스트를 설정한 후, 조직 관계를 만들지 않으면 두 페더레이션 조직 간에 공유가 이루어지지 않습니다. 하지만, 기본적으로 사용자에게 할당된 기본 공유 정책을 사용하여 사용자와 외부 페더레이션 조직의 사용자 간 공유가 설정됩니다. 이 정책을 통해 모든 외부 페더레이션 조직의 사용자에게만 약속 있음/없음 정보를 포함한 일정을 공유할 수 있습니다. 사용자가 모든 외부 페더레이션 도메인의 사용자와 일정 및 약속 있음/없음 정보를 공유하도록 허용하지 않으려면 기본 공유 정책을 사용하지 않거나 정책에 지정된 도메인 이름을 공유를 허용할 도메인으로만 변경해야 합니다. 이렇게 변경한 후 MFG를 이용해 페더레이션 트러스트를 만들어야 합니다. 자세한 내용은 공유 정책 사용 안 함 및 공유 정책 속성 구성을 참조하십시오.
MFG를 이용해 조직의 페더레이션 트러스트를 제거함으로써, 페더레이션 위임을 포함하여 조직에 대한 모든 페더레이션 기능을 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 페더레이션 트러스트 제거를 참조하십시오.
S/MIME(Secure/Multipurpose Internet Mail Extensions)
S/MIME(Secure/Multipurpose Internet Mail Extensions)은 공개 키 암호화와 MIME 데이터 서명을 위한 표준으로, 메시징 데이터에 대한 인증, 메시지 무결성, 거부할 수 없음 및 데이터 개인 정보 보호 기능을 제공합니다. 사용자는 S/MIME 인증서를 사용하여 메시지를 서명 또는 암호화하거나 두 가지 작업을 모두 수행할 수 있습니다. S/MIME에 대한 자세한 내용은 S/MIME 이해를 참조하십시오.
S/MIME은 전자 메일 서버에 대한 상호 운용성 요구 사항이 전혀 없는 클라이언트 쪽 기술입니다. 메시지 전송 측면에서 S/MIME 서명 또는 암호화된 메시지는 (암호화되지 않은) 일반 텍스트 메시지와 전혀 다름 없이 전송됩니다. 인증서 및 메시지 유효성 검사 후 클라이언트 쪽에서 실제로 메시지 렌더링이 완료됩니다. Outlook Web App의 경우, S/MIME 지원은 ActiveX 컨트롤을 사용하여 제공됩니다. Outlook Web App에서는 Microsoft Internet Explorer, Mozilla FireFox 및 Safari와 같이 많이 사용되는 브라우저를 대부분 지원하지만, ActiveX 컨트롤은 Internet Explorer 기능입니다. 다른 브라우저를 사용하는 Outlook Web App 사용자는 S/MIME 기능에 액세스할 수 없으므로, S/MIME을 지원하는 다른 전자 메일 클라이언트를 사용해야 할 수도 있습니다. Outlook Web App에서의 S/MIME 지원에 대한 자세한 내용은 Outlook Web App 및 S/MIME을 참조하십시오.
Outlook의 S/MIME 지원에 대한 자세한 내용은 Outlook의 인증서 및 암호화 전자 메일 메시징 개요를 참조하십시오.
S/MIME은 조직에 보안상의 이점을 제공하지만, 이 기술을 평가할 때는 다음 사항을 고려해야 합니다.
S/MIME 암호화 메시지는 조직 입장에서는 불투명한 메시지입니다. 바이러스 백신 및 스팸 방지와 같은 메시징 보안 소프트웨어가 메시지 본문과 첨부 파일을 포함한 메시지 콘텐츠를 검사할 수 없습니다.
메시지 콘텐츠와 첨부 파일이 암호화되기 때문에, S/MIME 암호화 메시지에 전송 규칙을 포함한 조직의 메시징 정책을 적용할 수 없습니다.
예를 들어, 고지 사항 또는 개인 설정 서명을 적용하는 것처럼, 조직의 메시징 정책을 준수하기 위해 S/MIME 서명 메시지를 수정하면 메시지가 무효화됩니다.
암호화된 메시징 콘텐츠에 대한 어떤 콘텐츠 위반도 검사할 수 없고, 조직에서 중요한 정보를 보호할 수 없습니다. 여기에는 조직에서 나가는 PII(개인 식별 정보)가 모두 포함됩니다.
Exchange 검색에서는 S/MIME 암호화 메시지를 인덱싱할 수 없으므로, 검색으로 이런 메시지를 검색할 수 없습니다.
소송 중에 해당 지역의 규정이나 검색 요구 사항을 충족시키기 위해, 조직에서는 암호화되지 않은 모든 암호화 메시지의 복사본을 만들어야 할 수도 있습니다.
Exchange 2010에서는 지정된 받는 사람만 IRM 보호 메시지에 액세스할 수 있도록 조직에서 중요한 메시징 콘텐츠를 지속적으로 보호할 수 있는 IRM(정보 권한 관리) 기능을 제공합니다. 또한, 조직에서는 받는 사람에게 메시지가 배달된 후 그런 콘텐츠의 사용 방법에 대한 컨트롤을 구현할 수 있습니다. 예를 들어, 조직 내부 또는 외부에서 메시지를 인쇄, 회신 또는 전달하지 못하게 할 수 있습니다. 또한, 조직에서는 바이러스 백신 및 스팸 방지 소프트웨어와 다른 전송 에이전트에 의한 검사, 전송 규칙을 사용한 메시징 정책 적용, IRM 보호 메시지의 보관 및 검색을 사용하기 위해 IRM 보호 콘텐츠를 계속해서 암호 해독할 수 있습니다. Outlook Web App에서 지원하는 모든 웹 브라우저와 Windows 모바일 장치에서도 IRM 기능을 사용할 수 있습니다. IRM에 대한 자세한 내용은 정보 권한 관리 이해를 참조하십시오.
서버 역할 고려 사항
이 섹션에서는 Exchange 2010 서버 역할에 대한 보안 관련 고려 사항을 설명합니다.
사서함 서버 고려 사항
Exchange 2010에서는 Outlook과 같은 MAPI 클라이언트에서 Exchange 저장소와 연결의 아키텍처가 변경되었습니다. MAPI 클라이언트는 클라이언트 액세스 서버에 연결하여 사서함 서버를 클라이언트 트래픽으로부터 격리합니다. 사서함 서버는 RPCSec을 사용하는 클라이언트 액세스 서버 및 조직 내 AD DS(Active Directory 도메인 서비스) 서버와만 통신합니다. 사서함 서버에는 인터넷 연결이 필요 없습니다.
저장소
저장소는 사서함 서버의 중요한 구성 요소입니다. 배포를 위해 만족스러운 성능과 적절한 저장소 공간을 사용할 수 있도록 사서함 서버 저장소 하위 시스템을 계획해야 합니다. 사서함 서버 저장소 계획에 대한 자세한 내용은 사서함 서버 저장소 디자인을 참조하십시오.
사서함 서버 배포 후, 다음 사항을 모니터링해야 합니다.
저장소 하위 시스템의 가용성.
사서함 데이터베이스와 트랜잭션 로그가 있는 볼륨에 사용 가능한 충분한 디스크 공간. 데이터베이스나 데이터베이스에 대한 트랜잭션 로그를 저장하는 볼륨에 사용 가능한 디스크 공간이 부족할 때 사서함 또는 공용 폴더 데이터베이스가 분리됩니다.
Microsoft Federation Gateway Systems Center Operations Manager를 사용하여 저장소 가용성과 사용 가능한 디스크 공간을 모니터링할 수 있습니다. 자세한 내용은 Systems Center Operations Manager 2007(영문)을 참조하십시오.
저장소를 계획하고 모니터링할 때 다음 기능을 사용할 계획이라면 저장소 요구 사항을 고려해야 합니다.
저널링 메시지를 장기적으로 보관하기 위해 저널링을 사용할 때는 표준 저널링(사서함마다 데이터베이스가 있음) 또는 고급 저널링(저널 규칙) 중 어떤 것을 사용할지에 따라 사서함 데이터베이스의 모든 받는 사람 또는 저널 규칙에 지정된 받는 사람과 주고받는 메시지가 저널 보고서 형태로 지정된 저널링 사서함 또는 받는 사람에게 배달됩니다. 그 결과, 저널링 사서함으로 많은 수의 저널 보고서가 배달될 수 있습니다. 사서함 서버용 저장소를 계획할 때 저널링 사서함 크기를 고려해야 합니다. 저널링 사서함에 대해 충분한 사서함 할당량을 구성하여 저널링 사서함 크기를 제어할 수 있습니다. 저널링 및 사서함 할당량에 대한 자세한 내용은 다음 항목을 참조하십시오.
소송 자료 보호(Litigation Hold) 소송 자료 보호 대상으로 사서함을 지정하면 소송 자료 보호가 해제될 때까지는 사용자가 삭제한 항목(Outlook 및 Outlook Web App에서 지운 편지함 복구 기능을 사용하여 복구 가능)과 MRM과 같은 자동 프로세스에 의해 삭제된 메시지가 보존됩니다. Exchange 2010에서는 복구 가능한 항목 경고 할당량과 복구 가능한 항목 할당량이 20GB와 30GB로 설정됩니다. 자세한 내용은 다음 항목을 참조하십시오.
높은 가용성
사서함 서버의 고가용성은 메시징 서비스 가용성을 보장하는 데 매우 중요합니다. Exchange 2010에는 사서함 서버의 고가용성을 위한 DAG(데이터베이스 가용성 그룹)가 포함됩니다. DAG는 Exchange 배포 환경에서 저장소 하위 시스템, 서버 또는 네트워크 연결에 오류가 발생하거나 전체 데이터 센터의 운영이 중단될 때 가용성을 제공할 수 있습니다. 고가용성의 Exchange 2010 배포를 계획하고 구현하는 데 대한 자세한 내용은 고가용성 및 사이트 복구를 참조하십시오.
Exchange 2010에서는 기본적으로 서로 다른 Active Directory 사이트에 있는 DAG 멤버 간의 복제(로그 전달) 트래픽이 암호화됩니다. DAG의 NetworkEncryption 속성을 사용으로 설정하여 같은 Active Directory 사이트에 있는 서버 간의 복제 트래픽을 암호화할 수 있습니다. Set-DatabaseAvailabilityGroup cmdlet을 사용하여 DAG의 이 속성을 수정합니다.
복제는 단일 TCP 포트(기본적으로 TCP 포트 64327)를 통해 이루어집니다. 복제에 사용되는 포트는 수정할 수 있습니다. 자세한 내용은 데이터베이스 가용성 그룹 속성 구성을 참조하십시오.
고가용성을 위한 매개 변수
| 매개 변수 | 설명 |
|---|---|
NetworkEncryption |
NetworkEncryption 매개 변수는 네트워크 암호화를 사용할지 여부를 지정합니다. 사용할 수 있는 값은 다음과 같습니다.
기본값 |
ReplicationPort |
ReplicationPort 매개 변수는 복제(로그 전달 및 시드) 작업에 사용할 TCP(Transmission Control Protocol) 포트를 지정합니다. 기본값 이 매개 변수를 지정하지 않으면 기본 포트 TCP 64327이 복제에 사용됩니다. |
사서함 사용 권한 및 액세스
기본적으로 Exchange 2010에서는 관리자가 사서함에 액세스할 수 없습니다. 조직에서 사서함에 액세스해야 하는 응용 프로그램이나 서비스를 사용하는 경우 해당 응용 프로그램이나 서비스에서 사용하는 계정에 적절한 사서함 사용 권한을 할당해야 합니다. 그런 응용 프로그램이나 서비스에서 관리자 자격 증명을 사용하도록 구성하지 않는 것이 좋습니다.
모든 사서함은 조직에 중요한 정보를 포함할 수 있지만, 다음 사서함은 보안 관점에서 각별히 신경을 써야 하고 이런 사서함에 대한 액세스 권한은 조직의 보안 요구 사항을 충족하도록 제어 및 모니터링해야 합니다.
검색 사서함 Exchange 2010 여러 사서함 검색 기능에서 검색 사서함을 사용합니다. Discovery Management 역할 그룹의 구성원인 검색 관리자는 검색 사서함을 사용하여 Exchange 2010 조직의 모든 사서함에서 메시지를 검색할 수 있습니다. 검색에서 반환되는 메시지는 지정된 검색 사서함으로 복사됩니다. Exchange 2010 설치 프로그램은 기본 검색 사서함을 만듭니다. 자세한 내용은 여러 사서함 검색 이해를 참조하십시오.
저널링 사서함 사서함 데이터베이스에 대한 저널링을 구성하거나 지정된 받는 사람과의 메시지 저널링을 위한 저널 규칙을 만들면 저널 보고서가 지정된 저널링 사서함으로 배달됩니다. 자세한 내용은 다음 항목을 참조하십시오.
이런 사서함을 보호하는 것 외에도, 관리자는 전송 규칙을 사용하여 메시지 콘텐츠를 검사하고 다른 받는 사람(숨은 참조로 받는 사람도 포함)에게 메시지 복사본을 배달할 수도 있습니다. 전송 규칙을 관리하는 데 필요한 사용 권한은 메시징 정책 및 규정 준수 권한 항목의 전송 규칙 항목에 나열되어 있습니다. 적절한 컨트롤을 사용하여 전송 규칙 만들기와 수정을 모니터링 및 제어하고, 모든 규칙에 대한 전송 규칙 작업도 정기적으로 감사하는 것이 좋습니다.
클라이언트 액세스 서버 고려 사항
Exchange 2010에서는 다음 클라이언트가 클라이언트 액세스 서버에 연결하여 사서함에 액세스합니다.
Outlook 클라이언트(MAPI 사용)
Outlook 클라이언트(Outlook Anywhere 사용)
웹 브라우저(Outlook Web App 사용),
모바일 장치(Exchange ActiveSync 사용)
POP3 및 IMAP4 클라이언트
EWS(Exchange 웹 서비스)를 사용하는 응용 프로그램
기본적으로 이런 클라이언트 액세스 방법은 암호화된 데이터 경로를 사용하여 보호됩니다. 또한, 기본적으로 MAPI를 사용하여 클라이언트 액세스 서버에 연결하는 Outlook 클라이언트는 RPC 암호화를 사용합니다. Outlook Web App, Outlook Anywhere 및 Exchange ActiveSync 액세스는 SSL(Secure Sockets Layer)을 사용하여 보호됩니다.
외부 클라이언트 액세스를 위해서는 클라이언트가 신뢰하는 CA(인증 기관)에서 서명한 인증서를 구해서 설치해야 합니다. 자세한 내용은 클라이언트 액세스 서버용 SSL 관리를 참조하십시오.
기본적으로 POP3 및 IMAP4 서비스는 Exchange 2010 클라이언트 액세스 서버에서 사용되지 않습니다. 이런 서비스를 사용하는 경우 TLS(전송 계층 보안) 또는 SSL(Secure Sockets Layer) 프로토콜을 사용하여 통신 보안을 유지하는 것이 좋습니다. 자세한 내용은 다음 항목을 참조하십시오.
외부 액세스를 위해 클라이언트 액세스 서버를 게시할 때 적절한 방화벽과 액세스 컨트롤을 사용하는 것이 좋습니다. MicrosoftForefront TMG(Threat Management Gateway) 2010에는 외부 액세스를 위해 Exchange 2010 클라이언트 액세스를 손쉽고 안전하게 게시하기 위한 게시 마법사가 포함됩니다. 자세한 내용은 Forefront Threat Management Gateway (TMG) 2010(영문)을 참조하십시오.
중요
경계 네트워크에 있는 클라이언트 액세스 서버 찾기는 지원되지 않습니다.
클라이언트 액세스 서버에서는 Outlook Web App, Exchange ActiveSync, Outlook Anywhere, AutoDiscover, ECP(Exchange 제어판), Exchange 웹 서비스 및 OAB(오프라인 주소록)와 같은 서비스에 HTTP 프로토콜 액세스를 제공하는 데 IIS(Internet Information Server)가 사용됩니다. 원격 PowerShell에서도 IIS를 사용하고 EMC(Exchange 관리 콘솔)에 의한 요청을 포함한 모든 RPS 요청이 IIS 로그에 로깅됩니다. IIS 로그는 증가하여 대량의 디스크 공간을 사용할 수 있습니다. Windows Server 구성 요소인 IIS에는 로그 파일이 있는 디렉터리의 크기를 바탕으로 오래된 로그를 지우는 메커니즘이 없습니다. 로그 파일 크기가 커져 시스템 볼륨의 디스크 공간이 부족하여 서비스가 중단되지 않도록 IIS 로그를 시스템 볼륨이 아닌 볼륨으로 이동하는 것이 좋습니다. 로그 파일 크기를 모니터링하고 필요에 따라 로그를 수동으로 보관하거나 삭제하는 메커니즘을 구현해야 합니다. 자세한 내용은 IIS 7에서 로깅 구성을 참조하십시오.
전송 서버 고려 사항
Exchange 2010에서는 다른 목적으로 디자인된 두 개의 전송 서버 역할을 제공합니다.
Edge 전송 Edge 전송 서버 역할은 보통 경계 네트워크에 있고 도메인에 가입되지 않은 전송 서버로서, Exchange 조직과 외부 SMTP 호스트 간에 메시지를 전송합니다. Edge 전송 서버는 경계 네트워크용으로 디자인되었지만, 이 서버를 내부 네트워크에서 찾아서 Active Directory 도메인에 구성원 서버로 조인할 수도 있습니다.
허브 전송 허브 전송 서버 역할은 Exchange 서버 간의 메시지, POP3 및 IMAP4를 사용하는 사용자와 같은 SMTP 클라이언트와 응용 프로그램 서버 및 장치에서 받은 메시지를 포함한 메시지를 조직 내부에서 전송합니다.
Exchange 2010에서는 기본적으로 TLS를 사용하여 SMTP 통신 보안을 유지합니다.
허브 전송 서버 간의 SMTP 통신 Exchange 조직의 허브 전송 서버는 TLS를 사용하여 조직 내부의 SMTP 통신 보안을 유지합니다. 허브 전송 서버에서 TLS를 계속 사용하는 것이 좋습니다. Exchange 2010에서는 Exchange를 기반으로 하지 않는 장치 또는 어플라이언스를 사용하는 조직이 허브 전송 서버에서 이런 어플라이언스로 TLS를 오프로드할 수 있습니다. 자세한 내용은 Active Directory 사이트 간 TLS를 사용하지 않도록 설정하여 WAN 최적화 지원을 참조하십시오.
허브 전송 및 Edge 전송 서버 간의 SMTP 통신 허브 전송 서버와 Edge 전송 서버 간의 모든 트래픽은 인증 및 암호화됩니다. 기본 인증 및 암호화 메커니즘은 상호 TLS입니다. Exchange 2010에서는 X.509 유효성 검사를 사용하여 인증서를 유효성 검사하는 대신 직접 신뢰를 사용하여 인증서를 인증합니다. 직접 신뢰란 Active Directory 또는 AD LDS(Active Directory Lightweight Directory Services)에 보관된 인증서의 존재 여부로 인증서의 유효성을 검사하는 것입니다. Active Directory는 신뢰할 수 있는 저장소 메커니즘으로 간주됩니다. 직접 신뢰를 사용하는 경우 인증서가 자체 서명한 것인지 아니면 CA(인증 기관)에서 서명한 것인지는 관계가 없습니다. Edge 전송 서버를 Active Directory 사이트에 가입시키면 Edge 구독에서 Active Directory에 Edge 전송 서버의 인증서를 게시합니다. 허브 전송 서버는 게시된 인증서를 유효한 것으로 간주합니다. Microsoft EdgeSync 서비스는 Edge 전송 서버에서 유효한 것으로 간주하는 허브 전송 서버 인증서를 가진 Edge 전송 서버에서 AD LDS를 업데이트합니다.
Edge 전송 서버와 외부 호스트 간의 SMTP 통신 Exchange 2010에서는 기본적으로 편의적 TLS를 사용하여 Edge 전송 서버와 익명 외부 호스트 간의 SMTP 통신 보안이 유지됩니다. 신뢰할 수 있는 CA에서 발행한 인증서가 필요 없고 구성 단계도 필요 없습니다. 수신 커넥터는 인바운드 SMTP 연결을 위한 TLS 협상 기능을 제공합니다. 또한, 송신 커넥터는 모든 아웃바운드 SMTP 연결을 위해 TLS 협상을 시도합니다. 편의적 TLS는 인증서의 유효성을 검사하지 않으므로 자체 서명한 인증서를 사용할 수 있습니다. 자세한 내용은 Exchange 2010의 TLS 기능 및 관련 용어를 참조하십시오.
참고
익명 호스트의 통신을 허용하는 허브 전송 서버에 수신 커넥터가 없으므로, 기본적으로 허브 전송 서버는 외부 SMTP 호스트와 통신할 수 없습니다. 익명 호스트와 통신하도록 허브 전송 서버를 구성할 수 있습니다. 자세한 내용은 허브 전송 서버를 통한 직접 인터넷 메일 흐름 구성을 참조하십시오. 이 토폴로지는 Exchange 2010 서버와 해당 서버에 설치된 모든 역할이 인터넷에 노출되어 보안 위험이 증가하기 때문에 사용하지 않는 것이 좋습니다. 대신 Edge 전송 서버와 같이 경계 네트워크 기반 SMTP 게이트웨이를 구현하는 것이 좋습니다.
허브 또는 Edge 전송 서버와 스마트 호스트 간의 SMTP 통신 Exchange 2010에서는 인터넷 메일을 포함한 원격 도메인용 메일을 일반적으로 경계 네트워크에 있는 SMTP 게이트웨이로 라우팅하도록 송신 커넥터를 구성할 수 있습니다. 어떤 인증도 사용하지 않고 전자 메일을 스마트 호스트로 라우팅하는 송신 커넥터를 만들 수 있지만, 그런 커넥터에 적절한 인증을 사용하는 것이 좋습니다. 기본 인증을 사용하는 경우 TLS를 통한 기본 인증을 사용하는 것이 좋습니다. 외부 보안 옵션을 선택하는 경우 IPsec과 같은 비 Exchange 메커니즘을 사용하여 인증하는 것으로 간주됩니다. 스마트 호스트의 주소로 커넥터를 구성하면 스마트 호스트의 IP 주소나 FQDN을 사용할 수 있습니다. FQDN을 사용하는 편리성보다는, 악성 DNS를 방지하는 스마트 호스트의 IP 주소를 사용하는 것이 좋습니다.
파트너와의 SMTP 통신에 도메인 보안 사용 Exchange 2010에서는 도메인 보안을 사용하여 파트너 도메인과의 메시지 통신 경로를 안전하게 보호할 수 있습니다. 도메인 보안에서는 상호 TLS를 사용하여 세션 기반 암호화와 인증을 제공합니다. 상호 TLS 인증을 위해, 원본 및 대상 호스트는 X.509 인증서의 유효성을 검사하여 연결을 확인합니다. 도메인 보안을 위해 구성된 파트너 도메인과 통신하는 전송 서버에는 신뢰할 수 있는 타사 또는 내부 인증 기관에서 서명한 인증서가 필요합니다. 내부 CA를 사용하는 경우 CRL(인증서 해지 목록)을 게시해야 하고 파트너 호스트가 CRL에 연결할 수 있어야 합니다. 자세한 내용은 다음 항목을 참조하십시오.
Exchange 2010에서는 SMTP 통신에 기본 SMTP 포트(TCP 포트 25)를 사용합니다. Exchange 설치 프로그램은 기본 포트를 통해 통신할 수 있도록 고급 보안 기능을 가진 Windows 방화벽에서 필수적인 방화벽 규칙을 만듭니다. 커넥터에 다른 포트를 지정하는 경우 Exchange에서는 기본 포트 이외의 포트를 통해 통신을 허용하기 위해 방화벽 규칙을 수정하거나 새 규칙을 자동으로 만들지 않습니다. 기본 포트 이외의 포트를 통한 통신을 허용하려면 방화벽 구성을 수동으로 수정해야 합니다. 기본 설정되지 않은 포트를 위한 수신 커넥터를 구성하면 커넥터로 메시지를 전송하는 SMTP 클라이언트도 기본 설정되지 않은 포트를 사용하도록 구성되어야 합니다.
Exchange 2010에서는 Exchange 2010 사서함 서버에서 허브 전송 서버 역할을 찾을 수 있습니다. 여기에는 DAG(데이터베이스 가용성 그룹)의 구성원인 사서함 서버가 포함됩니다. 사서함 서버를 인터넷으로부터 격리하기 위해, 특히 아무런 Edge 전송 서버도 배포되어 있지 않은 토폴로지에서는 사서함 서버에서 허브 전송 서버 역할을 찾지 않는 것이 좋습니다. 클라이언트 액세스 서버에서 허브 전송 서버 역할을 찾을 수 있습니다. 같은 서버에 서버 역할을 배치할 때 각 서버 역할에 대한 크기 조정 지침을 준수해야 합니다.
허브 전송 서버나 Edge 전송 서버의 송신 커넥터에 대한 스마트 호스트를 지정할 때, 악성 DNS와 스푸핑을 방지하기 위해 스마트 호스트의 FQDN(정규화된 도메인 이름) 대신 IP 주소를 사용하는 것이 좋습니다. 이렇게 하면 전송 인프라에 미치는 DNS 중단의 영향도 최소화됩니다. 경계 네트워크에 사용되는 DNS 서버는 아웃바운드 확인에만 사용해야 합니다. 경계 DNS 서버에는 허브 전송 서버에 대한 레코드가 포함될 수 있습니다. 또한, Edge 전송 서버의 호스트 파일을 사용하여 경계 네트워크에 있는 DNS 서버에서 허브 전송 서버에 대한 레코드를 만들지 않도록 할 수 있습니다.
이 섹션에서 설명한 단계 외에도, 커넥터에 대한 충분한 메시지 크기 제한 사용과 전송 서버에 대한 메시지 제한 설정을 고려해야 합니다. 자세한 내용은 다음 항목을 참조하십시오.
통합 메시징 고려 사항
UM(통합 메시징) 서버 역할을 배포할 계획이라면 IP 게이트웨이 또는 IP PBX와 통신하기 위해 UM에서 사용하는 다른 통신 채널을 고려해야 합니다.
기본적으로 UM 다이얼 플랜을 만들면 보안되지 않음 모드에서 통신이 수행됩니다. 또한, UM 다이얼 플랜과 연결된 통합 메시징 서버는 암호화를 사용하지 않고 IP 게이트웨이, IP PBX 및 기타 Exchange 2010 컴퓨터에서 데이터를 주고받습니다. 보안되지 않음 모드에서는 RTP(Real-time Transport Protocol) 미디어 채널과 SIP 신호 정보가 모두 암호화되지 않습니다.
다른 장치 및 서버와 주고받는 SIP 및 RTP 트래픽을 상호 TLS를 사용하여 암호화하도록 통합 메시징 서버를 구성할 수 있습니다. 통합 메시징 서버를 UM 다이얼 플랜에 추가하고 SIP 보안됨 모드를 사용하도록 다이얼 플랜을 구성하면 SIP 신호 트래픽만 암호화되고, RTP 미디어 채널은 여전히 TCP를 사용합니다. TCP는 암호화되지 않습니다. 그러나 통합 메시징 서버를 UM 다이얼 플랜에 추가하고, 보안 모드를 사용하도록 다이얼 플랜을 구성하면 SIP 신호 트래픽과 RTP 미디어 채널이 모두 암호화됩니다. SRTP(Secure Real-time Transport Protocol)를 사용하는 보안 신호 미디어 채널에서도 상호 TLS를 사용하여 VoIP 데이터를 암호화합니다.
사용하는 IP 게이트웨이나 IP PBX에서 IPsec을 지원하는 경우 IPsec을 사용하여 UM 서버와 IP 게이트웨이 또는 IP PBX 간의 통신 보안을 유지할 수도 있습니다.
자세한 내용은 통합 메시징 VoIP 보안 이해를 참조하십시오.
또한, UM은 부재 중 전화 알림 및 음성 메일 메시지와 같은 메시지를 허브 전송 서버로 전송합니다. 기본적으로 이 통신은 TLS 암호화를 사용하여 SMTP를 통해 이루어집니다.
PIN 없는 액세스가 가능하도록 UM 사서함 정책을 구성할 수 있습니다. 이렇게 하면 발신자가 호출의 CallerID를 바탕으로 PIN을 입력할 필요 없이 음성 메일에 액세스할 수 있습니다. CallerID의 스푸핑은 무의미합니다. 음성 메일에 대해 PIN 없는 액세스를 사용하지 않는 것이 좋습니다. 또한, 기본 PIN 설정을 검토하고 조직의 보안 요구 사항에 부합하도록 이 설정을 구성하는 것이 좋습니다. Set-UMMailboxPolicy cmdlet을 사용하여 UM 사서함 정책에 대해 다음 설정을 구성할 수 있습니다.
음성 메일 액세스를 위한 사용자 PIN을 제어하는 매개 변수
| 매개 변수 | 설명 |
|---|---|
AllowCommonPatterns |
AllowCommonPatterns 매개 변수는 확실한 PIN을 허용할지 여부를 지정합니다. 확실한 PIN의 예로는 반복 번호, 일련 번호, 전화 번호의 하위 집합 등이 있습니다. $false로 설정하면 사서함 내선 번호의 접미사와 일련 번호 및 반복 번호가 거부됩니다. $true로 설정하면 사서함 내선 번호의 접미사만 거부됩니다. |
AllowPinlessVoiceMailAccess |
AllowPinlessVoiceMailAccess 매개 변수는 UM 사서함 정책에 연결된 사용자가 해당 음성 메일에 액세스하기 위해 PIN을 사용해야 하는지 여부를 지정합니다. 전자 메일 및 일정에 액세스하는 경우에는 여전히 PIN이 필요합니다. 기본값 사용 안 함( |
LogonFailusresBeforePINReset |
LogonFailuresBeforePINReset 매개 변수는 사서함 PIN이 자동으로 원래대로 설정되기 전에 연속적으로 시도할 수 있는 로그온 실패 횟수를 지정합니다. 이 기능을 사용하지 않으려면 이 매개 변수를 제한 없음으로 설정합니다. 이 매개 변수를 제한 없음으로 설정하지 않는 경우 MaxLogonAttempts 매개 변수의 값보다 작은 값으로 설정해야 합니다. 0에서 999까지의 값을 사용할 수 있습니다. 기본값 오류 5번 |
MaxLogonAttempts |
MaxLogonAttempts 매개 변수는 UM 사서함이 잠기기 전에 사용자가 연속적으로 시도할 수 있는 로그온 실패 횟수를 지정합니다. 1에서 999까지의 값을 사용할 수 있습니다. 기본값 15회 시도 |
MinPINLength |
MinPINLength 매개 변수는 UM 사용이 가능한 사용자의 PIN에 필요한 최소 자릿수를 지정합니다. 4에서 24까지의 값을 사용할 수 있습니다. 기본값 6 자릿수 |
PINHistoryCount |
PINHistoryCount 매개 변수는 시스템에 저장되어 PIN을 원래대로 설정하는 동안 사용할 수 없는 이전 PIN 수를 지정합니다. 이 수에는 최초로 설정된 PIN도 포함됩니다. 1에서 20까지의 값을 사용할 수 있습니다. 기본값 5개의 PIN |
PINLifetime |
PINLifetime 매개 변수는 새 암호가 필요하기 전까지의 일수를 지정합니다. 1에서 999까지의 값을 사용할 수 있습니다. 제한 없음을 지정하면 사용자의 PIN이 만료되지 않습니다. 기본값 60일 |
Exchange 2010에서는 음성 메일 메시지가 보호됨으로 표시될 수 있습니다. 음성 메일 메시지는 IRM(정보 권한 관리)을 사용하여 보호됩니다. UM 사서함 정책에서 다음 매개 변수를 구성하여 음성 메일 보호 설정을 구성할 수 있습니다. 자세한 내용은 다음 항목을 참조하십시오.
보호된 음성 메일 매개 변수
| 매개 변수 | 설명 |
|---|---|
ProtectAuthenticatedVoicemail |
ProtectAuthenticatedVoiceMail매개 변수는 UM 사서함 정책에 연결된 UM 사용이 가능한 사용자에 대해 Outlook Voice Access 호출에 응답하는 통합 메시징 서버에서 보호된 음성 메일 메시지를 만드는지 여부를 지정합니다. 값이 개인으로 설정되면 개인으로 표시된 메시지만 보호됩니다. 값이 모두로 설정되면 모든 음성 메일 메시지가 보호됩니다. 기본값 없음(음성 메일 메시지에 아무런 보호도 적용되지 않음) |
ProtectUnauthenticatedVoiceMail |
ProtectUnauthenticatedVoiceMail매개 변수는 UM 사서함 정책에 연결된 UM 사용이 가능한 사용자에 대해 호출에 응답하는 통합 메시징 서버에서 보호된 음성 메일 메시지를 만드는지 여부를 지정합니다. 이 매개 변수는 UM 자동 전화 교환에서 UM 사서함 정책에 연결된 UM 사용이 가능한 사용자에게 메시지를 보낼 때에도 적용됩니다. 값이 개인으로 설정되면 개인으로 표시된 메시지만 보호됩니다. 값이 모두로 설정되면 모든 음성 메일 메시지가 보호됩니다. 기본값 없음(음성 메일 메시지에 아무런 보호도 적용되지 않음) |
RequireProtectedPlayOnPhone |
RequireProtectedPlayOnPhone 매개 변수는 UM 사서함 정책에 연결된 사용자가 보호된 음성 메일 메시지에 대해서만 전화에서 재생 기능을 사용할 수 있는지 여부 또는 사용자가 멀티미디어 소프트웨어를 사용하여 보호된 메시지를 재생할 수 있는지 여부를 지정합니다. 기본값 |
중요
UM 서버가 호출에 계속 응답하도록 하려면 UM 서버가 Active Directory에 대한 액세스 권한을 가지고 있어야 합니다. Active Directory 가용성을 모니터링하는 것이 좋습니다.
부록 1: 추가 보안 관련 설명서
이 섹션에는 추가 보안 관련 Exchange 설명서에 대한 링크가 들어 있습니다.
스팸 방지 및 바이러스 백신 기능
인증서
클라이언트 인증 및 보안
Outlook Web App
Outlook Anywhere
POP3 및 IMAP
사용 권한
메일 흐름 보호
메시징 정책 및 준수
페더레이션
© 2010 Microsoft Corporation. 모든 권리 보유.