IT 관리 / 개발자 / 보안

"초강력 보안" 마이크로소프트 익스체인지 서버 구축하기

Jonathan Hassell | CSO 2017.11.08
정보 유출, 해커, 암호화에 대한 뉴스가 쏟아져 나오는 지금 보안 관리자에게 자연스럽게 떠오르는 질문은 일급 기밀 정보 전송 이외의 모든 목적으로 사용 가능한 초강력 보안 마이크로소프트 익스체인지 서버(Exchange Server)를 구축하는 방법이다.


Credit: Getty Images Bank

이 글에서는 하이퍼-V 가상 머신에서 익스체인지 서버 2016을 구축하는 방법을 살펴본다. 사용성을 유지하는 한도 내에서 필자가 할 수 있는 최대한으로 안전한 방법이다. 포함되는 내용은 보관 중일 때와 전송 중일 때 모두 잠금 및 암호화하기, 원격 위치에서의 안전한 접근, 침입자에 대한 방어 강화 등이다.

구체적으로 필자는 다음과 같은 방향으로 서버를 구축할 것이다.
- 익스체인지 서버의 보안성
물론 많은 이가 의심쩍은 눈으로 마이크로소프트 익스체인지는 아무리 해도 적절히 보호할 수 없고 진정한 보안은 센드메일(Sendmail)이나 포스트픽스(Postfix) 커스텀 컴파일을 통해서만 가능하다고 말할 것이다. 필자는 그 주장에 동의하지 않는다. 개인 용도, 잘해봐야 두세 명의 다른 사람들과 함께 사용할 서버를 호스팅한다면 이런 솔루션이 통할 수 있지만 익스체인지에는 유용한 그룹웨어 기능이 있다. 
둘째, 정보는 이메일과 달력과 연락처에 모두 존재한다. 센드메일이나 포스트픽스 어느 쪽도 이런 부분을 통합적 방법으로 처리하지 않는다. 익스체인지를 보호하면 달력, 연락처, 받은 편지함, 저널 항목, 인스턴스 메시지 대화 내역을 비롯해 그 외의 많은 것을 보호하게 된다. 마지막으로, 대부분의 사람은 아웃룩을 선호하는데 아웃룩은 익스체인지와 함께 사용하는 것이 최선이다.

- 사무실과 외부에서 모두 통하는 솔루션
필자는 모바일을 통한 익스체인지 접근을 최대한 보호하는 데 집중하고자 한다. 안전한 모빌리티는 극히 중요하다. 필자의 설계에서 어느 부분을 타협해야 한다면 그건 보안을 위해서일뿐 편의성을 위해서가 아닐 것이다. 이 업계에서 조금이라도 경험이 있는 사람이라면 알겠지만 보안과 편의성은 상충한다. 이 구축 방법에서 필자의 목표는 전체적인 시스템 무결성을 저해하지 않으면서 일부 편의성을 허용하는 현명하고 합리적인 선택을 내리는 것이다.

- 간단한 원박스 솔루션
여기서 가용성 그룹의 일부로 여러 익스체인지 서버를 구축하지는 않을 것이다. 또한 윈도우 서버 머신을 클러스터링하지도 않고, 연결된 스토리지를 두거나 SAN 연결을 관리하지도 않을 것이다. 목표는 스토리지, 서버, 익스체인지가 모두 하나의 박스 안에 존재하는 단순한 형태다. 이를 통해 하나의 가상 머신에서 이 솔루션을 설정해 내부적으로 실행하거나 아마존 웹 서비스 또는 마이크로소프트 애저와 같은 서비스 형태의 인프라 환경에 배포할 수 있도록 할 계획이다.

이 작업은 3단계로 구성된다. 첫째, 익스체인지를 배포한다. 둘째, 윈도우 서버와 익스체인지, 두 관점에서 기초 부분을 보호한다. 마지막으로 네트워크를 보호하고 최신 암호화와 감사 기술을 구현해 가능한 가장 안전한 싱글 익스체인지 서버 구현을 완성할 것이다. 사실 필자는 이 시스템을 필자가 운영하는 회사의 프로덕션 환경에 배치할 것이므로 이 기사는 결코 이론 교육이 아니다. 필자의 회사가 실제로 이 서버 배치에 의존하게 된다.

서버에 익스체인지 서버 2016 설치하기
익스체인지를 설치하는 경우 익스체인지 서버 2016을 시스템에 세심하게 안착시켜 주는 마이클 드 루이즈(Michel de Rooij)의 파워셸 스크립트를 사용할 것을 권장한다. 다른 스크립트도 많지만 필터 팩을 포함한 모든 사전 조건을 완비하는 측면에서 보면 이 스크립트가 가장 뛰어나다.

스크립트는 설치할 운영체제에 따라 필요한 스키마 업데이트를 통해 액티브 디렉터리 설치를 준비하며, 오류와 예외도 매끄럽게 처리한다(필자는 최신 릴리스이며 지원도 잘 되는 윈도우 서버 2016을 사용하지만 스크립트는 윈도우 서버 2008 R2 서비스 팩 1부터 최신 릴리스까지 지원한다). 스크립트는 자주 업데이트된다. 이 글을 쓰는 시점을 기준으로 최신은 2017년 6월 28일자 업데이트다.

이 스크립트를 사용하려면 익스체인지 ISO 또는 소스 파일을 준비해 둬야 한다. 익스체인지 2013부터 적용된 좋은 점 가운데 하나는 모든 누적 업데이트가 실제로 익스체인지의 전체 사본이라는 점이다. 따라서 누적 업데이트 파일의 압축을 디렉터리에 풀고 이 디렉터리에서 익스체인지 설치를 바로 시작하면 처음부터 최신 상태로 설치된다. 즉, 최신 누적 업데이트를 로컬에 풀어서 준비하는 것이 항상 유리하다는 의미다.

기존 서버를 패치하는 데 상당히 오랜 시간이 소요된다는 점을 감안하면 이 방법으로 몇 시간 분의 업데이트 작업을 피할 수 있다. 이 작업은 이미 배포된 서버에서만 사용하면 된다. 이 기사를 쓰는 시점을 기준으로 최신 익스체인지 2016 버전은 2017년 9월 19일에 릴리스된 누적 업데이트 7이다.

파워셸 스크립트를 실행하는 명령은 다음과 같다.

Install-Exchange15.ps1 -InstallBoth -SourcePath c:\exchange2016cu7 -Organization EightyTwoVentures -AutoPilot –Credentials

이 명령을 실행하면 관리자 인증 정보를 요구하는 상자가 표시된다. 이 인증 정보는 스크립트 실행이 완료될 때까지 저장되었다가 삭제된다(재부팅을 하더라도 스크립트에 인증 정보가 보관된다). 가상 머신 내에 물리적 익스체인지를 배치하려면 5~6번의 재부팅과 한 시간 정도의 시간이 필요하지만 그 과정만 끝나면 즉시 사용 가능한, 아직 구성되지는 않은 익스체인지가 준비된다.

비트로커 암호화 설정
보안에는 암호화가 포함된다. 여기서 암호화란 보관 중(디스크에 저장된 상태)일 때와 전송 중(유선 전송 중인 상태)일 때 모두 데이터를 암호화하는 것을 의미한다. 익스체인지라면 윈도우 서버고, 그 말은 곧 산업용 등급의 드라이브 암호화 메커니즘인 비트로커(Bitlocker)를 사용할 수 있음을 의미한다.

사실 비트로커는 익스체인지의 모든 강점을 활용하고 모든 약점을 완화하는 철벽 같은 익스체인지 배포를 원하는 사람에게 마이크로소프트가 제시하는 "이상적인 세계" 시나리오인 익스체인지 우선 아키텍처(Exchange Preferred Architecture)를 위한 가이드라인의 일부이기도 하다.

윈도우 서버에서 비트로커를 설정해 전체 드라이브를 암호화하면 되는, 2단계 프로세스다(단, 백업 암호화 키를 분실해서는 안 된다).

전송 계층 보안(TLS)으로 전송 규칙 만들기
안전한 익스체인지 배포에는 전송 중 보안을 위해 TLS(Transport Layer Security) 사용이 의무적이다. TLS는 메일 전송에서 HTTPS, SSL과 동격으로, 메일 서버 간 SMTP 대화의 데이터 전송 부분 전체를 암호화한다. 이메일이 전송되면 트랜잭션에 관여하는 메일 서버는 인증서를 교환한 다음 암호화된 채널에서 통신하기로 합의한다. 그러면 메시지 헤더와 본문, 모든 첨부 파일은 이 보안 채널을 통해 전송된다.

요즘 대부분의 SMTP 서버는 기회적 TLS(opportunistic TLS)를 지원한다. 즉, 원격 메일 서버와 접촉할 때, 그리고 외부에서 전송된, 조직 내의 사용자에게 가는 인바운드 메일을 수락할 때 기본적으로 TLS를 사용하려고 시도하지만 상대방이 TLS를 지원하지 않을 경우 보안이 되지 않는 전통적인 일반 텍스트 SMTP로 후퇴한다.

TLS를 요구하는 전송 규칙을 만들어야 한다. 익스체인지 2016과 2013)에서 이 작업은 2007, 2010과 같은 예전 버전과는 다르므로 익스체인지에 익숙하다 해도 다음 과정을 주의해서 읽기 바란다(이 규칙을 사용하면 인증서는 더 이상 효력이 없으므로 인증서 때문에 애를 먹을 일이 없다).

1. 익스체인지 제어판(Exchange Control Panel) 내에 전송 규칙을 만든다. 로그인한 다음 왼쪽에서 "메일 흐름(mail flow)"을 클릭하고 맨 위에서 "규칙(rules)"을, 그 다음 "+" 아이콘을 선택하고 "새 규칙 만들기…(Create a new rule…)"를 선택한다.

2. 이 규칙을 모든 메시지에 적용해야 하므로 규칙에 알아보기 쉬운 이름을 붙인다. 이후 "*다음의 경우 이 규칙 적용…(*Apply this rule if…)" 아래에서 맨 밑의 옵션 "[모든 메시지에 적용(Apply to all messages)]"을 선택한다. 다음으로 "*다음 작업 실행(*Do the following)" 아래에서 마우스 커서로 "메시지 보안 수정…(Modify the message security…)"을 가리키고 "TLS 암호화 필요(Require TLS encryption)"를 클릭한다.

3. "이 규칙의 모드 선택(Choose a mode for this rule)" 아래에서 "적용(Enforce)" 라디오 버튼이 선택되어 있는지 확인한 다음 주석 세션 아래에 변경한 부분 또는 기타 참고할 메모 사항을 입력한다.

4. 마지막으로 창 하단의 저장(save) 버튼을 클릭한다. "이 규칙을 앞으로 받게 되는 모든 메시지에 적용하시겠습니까?"라는 경고 메시지가 표시되면 "예"를 클릭한다.

SSL VPN을 통한 원격 접근 설정
이 보안 익스체인지 서버 배포의 핵심적 부분은 익스체인지 서버에 대화를 시도하는 상대가 알려진 주체인지 아니면 알려진 장소의 상대인지 확인하는 것이다(후자에 대해서는 나중에 더 자세히 다루자).

SSL VPN은 일반적으로 원격으로 서비스에 접근하는 실용적인 방법 가운데 가장 안전한 방법으로 간주된다. 방화벽에서 특수한 포트를 열 필요가 없고 강력한 암호화 계층으로 세션을 둘러싸며, 서비스 연결을 시도하는 요청자의 현재 상태를 평가해 침해 여부 확인이 가능하기 때문이다.

또한 SSL VPN에는 로컬 보안 네트워크의 원격 클라이언트 부분을 만들어 필요에 따라 관리해서 안전하게 유지할 수 있다는 장점도 있다. 이 초강력 보안 익스체인지 배포에서 아웃룩 클라이언트에서의 표준 액티브싱크(ActiveSync) 연결을 허용하는 로컬 네트워크 접근을 제외하면 시스템에 접근하는 유일한 방법은 SSL VPN을 통한 방법이다. SSL VPN 어플라이언스는 여러 공급업체에서 판매하는 좋은 제품이 많다. 이미 갖고 있다면 그걸 배포하면 된다.

방화벽 설정
익스체인지를 보호하려면 안전한 네트워크도 필요하다. 하이퍼-V 호스트에서는 물리적 호스트 어댑터의 네트워크 바인딩을 제거해서 호스트 운영체제가 손상되는 경로 하나를 제거하고 다른 워크로드가 호스트에서 실행되지 않도록 차단해야 한다.

에지에서 이와 같은 메일 서버 보안은 기본적으로 두 개의 포트를 여는 것을 의미한다. SMTP 트랜잭션을 수행하는 데 필요한 포트 25, 그리고 일반적으로 SSL VPN 세션을 설정하는 데 사용되는 HTTPS 연결을 위한 포트 443이다.

주로 모호함을 통한 약간의 보안성을 추가하려면 SSL VPN 포트 번호를 무작위로 바꾸면 되지만 이를 위한 절차는 SSL VPN 제조업체에 따라 다르다. 일반적으로는 1024보다 큰 대체 포트 번호를 선택해야 한다. 이 경우 이 포트를 사용해 SSL VPN에 연결해 메일을 받아야 한다는 점을 사용자에게 교육시켜야 한다.

포트 25를 더 안전하게 만들 방법으로는 두 가지 이론이 있다.
- 철저한 사람들은 교육되지 않은 사용자를 상대로 한 악성코드, 바이러스, 스팸의 위험 외에 모든 메일을 로컬로 받을 때 서버에 미칠 부하도 고려한다. 이들은 서드파티 메시징 위생 서비스를 고집한다. 마이크로소프트의 익스체인지 온라인 프로텍션(Exchange Online Protection)도 유용하지만 필자는 메일프로텍터(Mailprotector)를 선호한다.

- 서드파티 위생 서비스를 사용해 스팸과 바이러스를 차단하기로 선택한다면 에지 방화벽에서 메시지 위생 서비스가 사용하는 IP 범위로만 포트 25를 한층 더 조일 수 있다. 이렇게 하면 방화벽은 다른 소스에서 온 패킷을 알아서 버리고 위생 서비스의 서버를 거친 메일만 배달되도록 보장한다. 전송 암호화를 그대로 유지하려면 서비스 제공업체가 TLS 필수 조건을 지원하는지 확인해야 하며, 아웃바운드 보안까지 확보하려면 이 업체의 서비스를 스마트호스트로 사용하는 방법도 고려할 만하다(마찬가지로 TLS 필수).

- 고도로 편집증적인 사람들은 메일이 어느 지점에서든 클라우드 서비스를 거친다는 것을 신뢰하지 않으므로 모든 메일이 직접 배달되도록 해야 한다. 실제로 직접 배달이 필수 조건인 경우가 있다. 이와 같은 경우 대부분 연결에 TLS 암호화를 강제 설정해야 한다. 익스체인지를 포함한 대부분의 메일 서버는 일반 텍스트의 수락 및 전송을 차단하기 위해 전송 시작 시 교환된 인증서를 검사하지 않으므로 완전히 안전한 암호화 메커니즘은 아니다. 미리 경고하자면 이 시나리오는 시간이 지날수록 스팸의 양이 엄청나게 늘어난다.

구축을 마쳤지만 보안 여정은 계속된다
안전한 독립형 익스체인지 배포를 구축하는 것은 체크리스트가 아닌 계속 이어지는 여정이다. 이 기사에서는 보관 중인 데이터와 전송 중인 데이터를 암호화하고 최대한 공격 표면을 줄인 견고한 기반 위에 구축된 메일 서버를 제시했지만 위협은 계속해서 진화한다.

메일 서버 관리는 그것 자체가 하나의 사업이 될 만큼 복잡한 일이다. 여기서 제시한 방법은 시작 지점으로 좋지만 이후에도 서버를 잘 살펴야 한다. editor@itworld.co.kr  

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.