IPsec 및 그룹 정책을 통한 서버 및 도메인 격리

아티클
12/06/2019

5장: 격리 그룹을 위한 IPsec 정책 만들기

업데이트 날짜: 2005년 2월 16일

이 장의 목표는 서버 및 도메인 격리 설계 구현을 위한 지침을 제공하는 것입니다. 앞 장에서는 설계 프로세스와 이 장이 제공하는 지침 이면의 논리적 근거를 설명합니다. 아직 하지 않았다면 이 장을 계속하기 전에 이러한 장을 읽어 두는 것이 좋습니다.

이 장은 4장 "격리 그룹 설계 및 계획"에서 설계한 도메인 격리 및 서버 격리 그룹의 보안 요구 사항 구현을 위한 완벽한 지침을 제공합니다. 다음 요소의 조합이 이러한 요구 사항을 구현합니다.

격리 도메인과 격리 그룹을 위한 인바운드 및 아웃바운드 액세스 요구 사항:
- 인바운드 및 아웃바운드 연결을 위한 IPsec IKE(인터넷 키 교환) 협상을 요구하는 격리 그룹을 위해 특별히 설계된 IPsec(인터넷 프로토콜 보안) 정책
- IPsec으로 보호되는 트래픽을 사용할 때 네트워크 액세스를 허용하거나 거부하는 네트워크 액세스 그룹이라고 하는 도메인 기반 보안 그룹
격리 도메인 및 격리 그룹을 위한 네트워크 트래픽 보호 요구 사항:
- 어떤 트래픽을 보호해야 하는지 적절히 식별하도록 설계된 IPsec 정책 필터
- 필터가 식별하는 트래픽을 위해 필요한 인증 및 암호화 수준을 협상하는 IPsec 필터 동작
- 신뢰할 수 있는 호스트가 아웃바운드 연결을 시작할 때 일반 텍스트 통신을 허용할지 여부를 제어하는 IPsec 필터 동작 설정

이 지침은 Microsoft® Windows Server™ 2003을 사용하는 Active Directory® 디렉터리 서비스 및 Windows Server 2003과 Microsoft Windows® XP를 사용하는 도메인 구성원의 구성에서 그룹 정책과 IPsec 정책을 사용하는 솔루션 준비에 대해 설명합니다 또한 이 장에서는 설계 대안과 롤아웃 옵션을 설명합니다. 최종 검사 목록은 설계가 모든 비즈니스 및 보안 요구 사항을 충족하는지 확인하도록 제공됩니다.

이 페이지에서

장 전제 조건
Active Directory에서 IPsec 정책 만들기
격리 그룹에 대한 인바운드 액세스 승인
추가 IPsec 고려 사항
요약

장 전제 조건

이 절에는 IPsec 솔루션을 구현하는 조직의 준비 상태를 확인하는 데 도움을 주는 정보가 포함되어 있습니다. 준비 상태란 비즈니스 측면이 아니라 물류적인 측면을 의미합니다. 이 솔루션 구현을 위한 비즈니스 측면은 이 가이드의 1장 "서버 및 도메인 격리 소개"에서 설명합니다.

지식 전제 조건

IPsec, 특히 IPsec의 Microsoft 구현에 대한 일반적인 개념을 숙지하고 있어야 합니다. 다음을 수행하기 위해서는 Windows Server 2003에도 익숙해야 합니다.

Active Directory® 개념(Active Directory 구조와 도구를 포함하여 사용자, 그룹, 기타 Active Directory 개체 조작 및 그룹 정책의 사용)
Windows 시스템 보안(사용자, 그룹, 감사 및 ACL[액세스 제어 목록], 보안 템플릿 사용 및 그룹 정책이나 명령줄 도구를 사용하는 보안 템플릿의 응용 프로그램 포함)
핵심 네트워킹 및 IPsec 원칙에 대한 이해

이 장을 계속하기 전에 이 가이드 앞 장이 제공하는 계획 지침을 읽고 솔루션의 아키텍처와 설계를 완벽하게 이해하고 있어야 합니다. 또한 솔루션 요구 사항 매트릭스의 일부로 솔루션의 비즈니스 요구 사항을 정의하고 문서화해야 합니다.

조직 전제 조건

다음과 같은 사람들을 포함하여 이 솔루션의 구현에 참여할 필요가 있는 조직의 다른 사람들로부터 의견을 경청해야 합니다.

회사 후원자
보안 및 감사 담당자
Active Directory 엔지니어링, 관리 및 운영 담당자
DNS(Domain Name System), 웹 서버 및 네트워크 엔지니어링 관리와 운영 직원

참고: IT(정보 기술) 조직의 구조에 따라 이러한 역할은 여러 사람들로 채워지거나, 몇 명이 여러 역할을 겸할 수도 있습니다.

IT 인프라 전제 조건

이 장에서는 다음 IT 인프라가 있다고 가정합니다.

혼합 모드 또는 기본 모드에서 실행되는 Microsoft Windows Server 2003 Active Directory 도메인. 이 솔루션은 GPO(그룹 정책 개체) 응용 프로그램을 위해 유니버설 그룹을 사용합니다. 조직이 혼합 모드 또는 기본 모드를 실행하고 있지 않은 경우 표준 글로벌 및 로컬 그룹 구성을 사용하여 GPO를 적용할 수도 있습니다. 단, 이러한 옵션이 너무 복잡하여 관리할 수 없기 때문에 이 솔루션이 이 옵션을 사용하지 않습니다.

참고: Windows Server 2003에는 IPsec 정책에 영향을 미치는 많은 개선점이 있습니다. 이 솔루션에는 Windows 2000 작동을 막을 수 있는 특정적인 것이 없습니다. 그러나 이 솔루션은 Windows Server 2003 Active Directory에 대해서만 테스트되었습니다. Windows Server 2003에서의 IPsec 개선 사항에 대한 자세한 내용은 Microsoft 웹 사이트의 New features for IPsec (영문)페이지(www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/ipsec\_whatsnew.asp)를 참조하십시오.
Windows 2000 Server, Windows Server 2003 Standard Edition 및 Windows Server 2003 Enterprise Edition 라이센스, 설치 미디어 및 제품 키

이 장에서 환경의 의도하는 호스트에 올바른 정책을 배포하려면 기존 IT 인프라를 완벽하게 이해하고 있어야 합니다. 3장 "IT 인프라의 현재 상태 확인"에서는 필요한 정보 및 구하는 방법에 대해 설명합니다. 최소한 다음 정보를 얻을 때까지는 이 장에서 설명하는 단계를 시작해서는 안 됩니다.

설계를 위한 격리 그룹 정의. 필요한 각 격리 그룹은 보안 요구 사항을 설명하고 이러한 요구 사항을 적용할 자산(예: 격리 그룹 구성원)을 식별하는 분명한 설명을 갖추고 있어야 합니다.
필요한 여러 가지 IPsec 정책 목록 및 할당 방법을 포함하여 IPsec 정책을 사용하여 격리 그룹을 구현하는 방법에 대한 자세한 설명.
IPsec을 적용하여 격리 그룹을 실행하는 영향에 대한 자세한 요약. 이 요약은 문제점과 해결 방법 목록으로 수행할 수 있습니다.
IPsec 정책이 시간에 따라 어떻게 변하는지, IPsec 정책 변경을 요구하는 절차 목록은 무엇인지에 대한 자세한 설명. 이 목록은 보안 문제 대응, 네트워크 구성 요소 추가 및 모든 격리 그룹에 클라이언트나 서버 추가 등의 절차를 포함해야 합니다.
조직의 네트워크 토폴로지와 IP 주소 지정 구성표에 대한 이해.

페이지 위쪽

Active Directory에서 IPsec 정책 만들기

필요한 격리 그룹을 지원하기 위해 필요한 정책을 만드는 프로세스는 다음과 같은 주요 작업으로 구성되어 있습니다.

필터 목록 만들기
필터 동작 만들기
격리 그룹을 구현하는 IPsec 정책 만들기

이러한 구성 요소를 만드는 프로세스를 시작하기 전에 4장 "격리 그룹 설계 및 계획"의 트래픽 모델 다이어그램과 표 및 호스트와 네트워크 매핑 표를 얻는 것이 중요합니다. 이러한 표는 정책이 필수 기능을 제공하고 올바른 격리 그룹에 할당되도록 하는 데 필요한 정보를 제공합니다.

다음 그림은 Woodgrove 은행 시나리오를 시뮬레이션하는 데 사용된 네트워크 구성을 보여줍니다.

그림 5.1 Woodgrove 은행 네트워크 구성

Woodgrove 은행 테스트 실험 구성은 솔루션의 다음과 같은 주요 기능을 보여줍니다.

IPsec을 사용할 때 위험은 높지만 도메인의 신뢰할 수 있는 특정 호스트를 차단하기 위해 네트워크 액세스 그룹을 사용하여 도메인 격리
IPsec을 사용하여 연결하도록 승인할 신뢰할 수 있는 호스트 클라이언트를 제한하기 위해 네트워크 액세스 그룹을 사용하여 서버 격리

또한 이 실험 환경은 다음과 같은 Windows IPsec의 필수 기능을 보여주고 실제 환경에서 사용되는 다른 보안 기술과의 호환성을 테스트합니다.

Windows 2000 서비스 팩(SP) 4(NAT-T(Network Address Translation Traversal) 업데이트 포함), Windows XP SP2 및 Windows Server 2003을 도메인 구성원으로 실행하는 컴퓨터의 호환성
Microsoft Windows 보안 가이드에 따른 권장 강화를 사용하여 보호할 때 이러한 플랫폼의 호환성. 격리마다 보호 요구 사항이 다르기 때문에 IPsec 필터를 사용하여 트래픽을 허용하고 차단하는 트래픽 맵은 이 솔루션과 통합되지 않았습니다. 각 패킷에 대해 종단간 보안을 제공하는 IPsec과 독립적으로 많은 경우 허용/차단 필터링에 Windows 방화벽이 보다 적합하기 때문에 서버 격리 IPsec 정책의 복잡성을 줄이기 위한 것이 트래픽 맵을 통합하지 않는 또 다른 이유였습니다.
웹(HTTP), SQL Server, DFS(분산 파일 시스템), 파일 및 인쇄 공유, MOM(Microsoft Operations Manager ), Microsoft Systems Management Server(SMS) 서버와 트래픽을 보호하는 IPsec 응용 프로그램 기능
다음 조건 모두에 대해 UDP(User Datagram Protocol)-ESP 암호화를 사용하는 ESP(보안 페이로드 캡슐화) NAT-T의 호환성
- IKE Kerberos 인증을 사용하여 NAT 뒤에 있는 도메인 구성원의 아웃바운드 액세스
- IKE Kerberos 인증을 사용하여 NAT 뒤에 있는 도메인 구성원의 인바운드 액세스

그림 5.1에서 볼 수 있는 실험 시나리오는 솔루션을 위한 모든 격리 그룹에서 수행되었습니다. 총 4개의 IPsec 정책을 만들고 그림에서 굵은 대시로 표시된 격리 그룹(즉, 격리 도메인, 암호화 격리 그룹, 대체 없음 격리 그룹 및 Boundary 격리 그룹)에 할당되었습니다. 다음 절에서는 이러한 정책을 만든 방법을 설명합니다.

IPsec 정책 구성 요소 개요

IPsec 정책은 조직의 IPsec 보안 구성 요소를 실행하는 데 사용되는 많은 구성 요소로 구성되어 있습니다. 다음 그림은 IPsec 정책의 다양한 구성 요소 및 서로 연결되는 방법을 보여줍니다.

그림 5.2 IPsec 정책 구성 요소

IPsec 정책은 어떤 네트워크 통신 트래픽이 어떻게 허용되는지 결정하는 규칙에 대한 컨테이너의 역할을 합니다. 각 규칙은 필터 목록과 관련 동작으로 구성되어 있습니다. 필터 목록에는 필터 그룹이 들어 있습니다. 트래픽은 특정 필터와 비교되어 관련 필터 동작이 트리거됩니다. 또한 규칙은 호스트 간에 사용되는 인증 방법을 정의합니다.

이 다이어그램은 위에서 아래까지 정책 구성 요소를 보여줍니다. 그러나 필터 및 필터 목록이 어떤 트래픽을 보호할지 제어하는 기본 구성 요소이기 때문에 정책을 작성하는 가장 효과적인 방법은 필터 및 필터 목록으로 시작하는 것입니다.

IPsec 필터 목록

IPsec 필터 목록은 각 필터의 기준에 따라 네트워크 트래픽을 일치시키는 데 사용되는 하나 이상의 필터 목록 모음입니다. 필터 목록의 각 필터는 다음을 정의합니다.

원본 및 대상 네트워크 또는 주소
프로토콜
원본 및 대상 TCP(Transmission Control Protocol) 또는 UDP 포트

필터 목록과 필터 동작은 IPsec 정책이 공유하도록 설계되었습니다. 이 방법을 사용하면 특정 종류의 예외에 대해 한 필터 목록을 유지하고 각 격리 그룹의 개별 IPsec 정책에서 사용할 수 있습니다. 그러나 필터 목록을 구성하는 필터는 필터 목록 간에 공유할 수 없습니다. 두 필터 목록이 동일한 필터를 갖고 있는 경우 각 필터 목록에 한 번씩 필터를 두 번 만들어야 합니다.

필터는 개별 동작을 가질 수 있기 때문에 IPsec 관리자는 IPsec 정책에서 중복 필터를 피하도록 주의를 기울여야 합니다. IPsec 서비스가 패킷 처리에 대한 중복 필터의 순서를 변경하고 일관되지 않은 결과를 초래할 수 있습니다. 허용이나 차단 같이 필터에 정확히 같은 동작이 있으면 필요한 경우 중복 필터가 사용될 수 있으며 성능에는 영향이 없습니다.

앞에서 수집한 네트워크 정보는 관리자가 보호하려는 다양한 트래픽 패턴을 식별하는 데 사용됩니다. 또한 IPsec 제한에서 제외해야 할 수 있는 트래픽을 식별하는 데도 이 정보가 사용됩니다.

다음 표는 일반적인 조직에 있을 수 있는 몇 가지 기본 필터 목록을 설명합니다. 조직의 업무 요구 사항 및 네트워크 디자인에 따라 추가 필터 목록이 필요할 수 있습니다.

표 5.1: 솔루션에서 제공하는 필터 목록

필터 목록	설명
안전한 서브넷 목록	조직에서 IPsec을 사용하여 보호할 모든 서브넷이 포함
DNS 예외 목록	IPsec 없이 통신을 허용할 DNS 서버의 IP 주소 포함
도메인 컨트롤러 예외 목록	IPsec 없이 통신을 허용할 도메인 컨트롤러의 IP 주소 포함
WINS 예외 목록	IPsec 없이 통신을 허용할 WINS(Windows Internet Naming Service) 서버의 IP 주소 포함
DHCP, 협상 트래픽	UDP 68을 통해 DHCP(Dynamic Host Configuration Protocol) 협상 트래픽이 발생하는 것을 허용할 필터 포함
ICMP, 모든 트래픽	문제 해결 목적으로 조직 내에서 ICMP(Internet Control Message Protocol) 기능을 허용할 필터 포함

안전한 서브넷 목록에는 조직의 내부 네트워크 내에 있는 모든 서브넷이 포함되어 있습니다. 이 필터 목록은 특정 격리 그룹에 필요한 동작을 구현하는 필터 동작과 연결되어 있습니다. ICMP용처럼 필터마다 그와 관련이 많은 다른 동작(예: 허용)을 요구하기 때문에 이 동작은 해당 서브넷에 대한 가장 광범위한 보안 동작(예: IPsec 협상)입니다. 이 방법은 신뢰할 수 없거나 비 IPsec 호스트는 이러한 서브넷에 있어야 한다는 것을 의미한다는 점을 알아야 합니다. 필터는 인바운드와 아웃바운드 보안 요구 사항을 모두 구현해야 합니다. 필터를 정의할 때 미러링된 것처럼 구성해야 합니다. 미러링은 정확히 반대 원본과 대상 주소가 사용될 때 트래픽이 일치하도록 합니다. 필터를 설명할 때 필터가 미러링된 것을 나타내기 위해 "<->" 기호를 사용합니다. 미러링된 필터는 필터 동작이 IPsec 캡슐화를 위한 보안 방법을 협상할 때마다 사용해야 합니다. ##### 원본 및 대상 주소 각 필터마다 원본과 대상 주소에 대한 설정이 있습니다. Windows XP 및 Windows Server 2003에는 Windows 2000보다 더 많은 주소 옵션이 있습니다. 따라서 이 플랫폼이 도메인의 구성원일 때는 Windows 2000 설정만 사용해야 합니다. Windows 2000 설정은 다음과 같이 설명됩니다. - **내 IP 주소**. 이 옵션은 정적 IP 주소 또는 DHCP 할당 주소를 갖고 있는지에 관계 없이 Active Directory에서 일반 IPsec 정책을 대부분 또는 모든 컴퓨터에 적용할 수 있도록 설계되었습니다. 도메인의 중앙 집중형 정책 할당을 지원하기 위해 IPsec은 실제 네트워크 인터페이스에 대한 필터 구성은 지원하지 않고, LAN이나 WAN 같은 인터페이스 종류(예: 전화 접속 또는 VPN(가상 사설망) 인터페이스)만 지원합니다. **내 IP 주소**를 사용하면 IPsec 서비스가 정책 실행을 준비할 때 컴퓨터가 사용하는 각 IP 주소가 포함된 특정 필터에 일반 IPsec 정책 필터가 복사됩니다. 또한 적절한 필터 수를 유지할 수 있도록 IPsec 서비스가 주소 변경이나 새 네트워크 인터페이스도 검색합니다. 컴퓨터에 두 개의 IP 주소가 구성된 네트워크 카드가 하나 있는 경우 두 개의 다른 IP 주소를 사용하여 만든 두 개의 다른 IPsec 관련 필터가 있게 됩니다. - **모든 IP 주소**. 이 옵션을 사용하면 IPsec 필터가 모든 IP 주소에 대해 일치됩니다. - **특정 DNS 이름**. 이 옵션을 사용하면 IPsec이 특정 DNS 이름의 IP 주소를 평가한 다음 해당 IP 주소를 사용하여 필터를 만듭니다. 결과는 관리자가 IP 주소를 필터에 입력한 것과 같습니다. 처음 필터를 만드는 동안 DNS 이름이 확인되고 대응하는 IP 주소가 필터에 저장됩니다. DNS 서버에 필터에서 지정한 DNS 이름에 대한 잘못된 리소스 레코드가 있는 경우 틀린 IP 주소가 필터에 추가됩니다. **참고**: 정책에서 처음으로 필터를 만든 후에는 DNS 이름이 절대 평가되지 않습니다. DNS 이름은 많은 해당 IP 주소(예: 도메인에 있는 각 도메인 컨트롤러용)를 갖고 있기 때문에 많은 필터를 만들어야 할 때 DNS 이름 옵션이 유용합니다. 주어진 DNS 이름에 대한 IP 주소 목록을 최신 상태로 유지하는 필터를 자동으로 만드는 방법은 없습니다. - **특정 주소**. 이 옵션은 트래픽을 필터에 제공된 IP 주소와 일치시킵니다. - **특정 서브넷**. 이 옵션을 사용하면 관리자가 특정 서브넷을 구성할 수 있습니다. 특정 서브넷 내의 모든 IP 주소가 필터와 비교됩니다. 이 옵션을 사용할 때는 서브넷에 대해 예외를 만든 경우 해당 서브넷의 IP 주소를 스푸핑하는 악의적인 사용자도 제외되므로 특히 주의해야 합니다. **참고:** Windows XP 및 Windows Server 2003은 추가 주소 옵션 및 이러한 릴리스가 지원하는 많은 다른 옵션을 제공하도록 향상되었습니다. 같은 IPsec 정책을 여러 플랫폼에 적용할 경우 관리자는 Windows 2000 옵션만 정책 설계에 사용되도록 해야 합니다. ##### 프로토콜 원본과 대상 주소 구성 외에 특정 프로토콜이나 포트와 비교하도록 각 필터를 구성할 수 있습니다. 기본적으로 필터는 모든 프로토콜과 모든 포트의 트래픽을 비교합니다. 포트를 지원하는 특정 프로토콜이 필터 기준의 일부로 선택된 경우 관리자는 원본과 대상 포트를 구성하는 옵션도 갖습니다. ##### 원본 및 대상 포트 TCP 또는 UDP 포트를 비교하도록 필터를 구성할 수 있지만 이 솔루션은 포트 관련 필터를 만드는 것을 권장하지 않습니다. 포트 필터링은 IPsec 필터 구성의 관리 오버헤드와 복잡성을 크게 증가시키며 IKE가 보안을 성공적으로 협상하려면 클라이언트와 서버 정책 사이에 복잡한 조정이 필요할 수 있습니다. 이 솔루션은 신뢰할 수 있는 컴퓨터 사이의 통신은 사실상 신뢰할 수 있는 것으로 가정하기 때문에 필터는 IPsec으로 보호되는 모든 트래픽(ICMP 제외)을 허용합니다. 신뢰할 수 있는 호스트에서 포트 필터링이 필요한 경우 **Business\_Requirements.xls**에서 IPsec 및 IPsec 계층 위에 있는 호스트 기반 방화벽(예: Windows 방화벽)의 조합을 사용하여 충족되는 보안 요구 사항을 참조하십시오. "내 IP 주소"를 사용하는 필터 동작에 관해 부록 A에서 설명하는 여러 가지 문제점을 해결하기 위해 이 솔루션은 Woodgrove 은행 시나리오에서 모든 <-> 서브넷 필터를 사용합니다. 필터 목록은 모든 조직의 서브넷이 명시적으로 나열되는 여러 개의 모든 IP 주소 <-> 특정 서브넷 필터로 구성되어 만들어집니다. 이 방법을 사용하면 관리자는 보호해야 하는 특정 서브넷을 정의할 수 있습니다. 특정 서브넷 외부의 트래픽은 IPsec 필터와 비교되지 않으며 대상 호스트에 일반 텍스트를 통해 보내집니다. 필터 설계에 권장하는 최선의 방법에 대한 자세한 내용은 Microsoft TechNet(www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx)에 있는 IT Showcase 백서 "[Improving Security with Domain Isolation: Microsoft IT implements IP Security(IPsec)](https://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx) (영문)"의 "Best Practices" 절을 참조하십시오. ##### 예외 목록 고려 사항 일부 트래픽은 지원, 기술 또는 비즈니스적 이유로 IPsec을 통해 보호할 수 없습니다. 또한 Windows 운영 체제를 실행하지 않는 컴퓨터는 IPsec을 지원하거나 IPsec을 쉽게 배포하지 못할 수 있습니다. Microsoft Windows NT® 버전 4.0, Windows 95 및 Windows 98 등 오래된 Windows 버전을 실행하는 컴퓨터는 그룹 정책 기반 IPsec을 사용할 수 없습니다. 마지막으로, Windows 2000 이상을 실행하는 관리되지 않는 컴퓨터는 개별 컴퓨터에 정책을 수동으로 롤아웃하고 Kerberos 버전 5 프로토콜(예: 미리 공유한 키 또는 인증서) 이외의 일부 인증 형식을 사용하는 경우에만 IPsec 협상에 참가할 수 있습니다. 또한 Windows 2000 이상을 실행하는 컴퓨터는 IPsec을 설정하기 전에 네트워크에 연결되어 도메인으로부터 IPsec 정책을 얻을 수 있어야 합니다. 현재 네트워크에 연결하고, 도메인 컨트롤러를 찾고, 정책을 검색하려면 지원하는 인프라 서비스를 IPsec 보안에서 제외시켜야 합니다. 이러한 서비스는 DNS와 WINS 및 도메인 컨트롤러 같은 이름 지정 서비스를 포함합니다. 이러한 인프라 서비스 이외에 IPsec을 지원하지 않는 다른 서비스가 조직에 있을 수 있습니다. 예를 들어, ADS(Advanced Deployment Services) 또는 RIS(Remote Installation Services)에서 이미지를 다운로드해야 하는 씬 클라이언트 또는 다른 부트스트랩 클라이언트는 IPsec을 지원하지 않습니다. 이러한 서비스를 제공하는 서버가 네트워크에 있을 경우 IPsec을 사용할 수 없는 호스트로부터 네트워크 통신을 받을 수 있도록 예외 목록에 포함할지 검토하거나 경계 격리 그룹의 구성원으로 만들어야 합니다. **참고:** ADS, RIS 또는 다른 서비스를 제공하는 서버를 예외 목록에 포함시키거나 경계 격리 그룹의 구성원으로 만들지 여부를 결정하는 것은 위험과 관리 효율성의 요소를 기준으로 합니다. 어느 경우나 선택한 접근 방식을 철저히 테스트해야 합니다. 클라이언트가 IPsec 인프라에 참가할 수 없지만 비즈니스가 IPsec을 사용하는 서버에 액세스해야 하는 경우 통신 경로를 설정할 수 있는 몇 가지 방법을 구현해야 합니다. 이 가이드의 솔루션은 예외 필터 목록을 사용하여 허용을 통해 이러한 트래픽 요구 사항을 제어합니다. 예외 목록은 IPsec 협상을 사용할 수 없는 경우라도 필요한 모든 호스트 통신이 발생할 수 있도록 보장하기 위해 IPsec 인프라에 설계됩니다. 예외 목록은 예외 목록의 필터에 일치하는 트래픽을 허용함으로써 트래픽을 IPsec 인프라에 참가하지 못하도록 선택적으로 제외시키는 데 사용됩니다. 이러한 목록은 IPsec이 구현하는 보안 메커니즘을 트래픽이 무시하기 때문에 신중하게 설계해야 합니다. 예를 들어, 소유 정보를 보호하기 위해 일반적으로 암호화를 사용하여 보호되는 서버를 예외 목록에 두면 게스트 컴퓨터가 IPsec을 사용하지 않고 서버와 직접 통신할 수 있습니다. 예외 목록은 보다 쉬운 UI(사용자 인터페이스) 구성을 위해 파일 크기를 최소화할 수 있게 필터 목록으로 구현됩니다. 예를 들어, 모든 도메인 컨트롤러 또는 각 도메인의 도메인 컨트롤러에 대한 필터를 포함하는 필터 목록을 갖고 있어야 합니다. 여러 가지 필터 목록을 갖고 있을 때의 두 번째 장점은 허용 규칙이 각 필터 목록에 대해 IPsec 정책을 설정/해제할 수 있다는 점입니다. IPsec 정책에서 예외를 구현하는 규칙을 설계할 때 IPsec이 보호할 필요가 있는 트래픽의 최소량을 허용할 수 있습니다. 그러나 대부분 특정 필터를 사용하여 얻어지는 보안과 반대로 IPsec 정책의 복잡성과 크기 측면에서 타협점이 있습니다. 한 도메인이나 포리스트의 클라이언트가 다른 신뢰할 수 있는 도메인이나 포리스트를 위한 Kerberos 티켓을 얻을 수 있으려면 모든 신뢰할 수 있는 포리스트의 *모든* 도메인 컨트롤러 IP 주소를 제외해야 합니다. Windows Kerberos 클라이언트는 자체 도메인 컨트롤러 및 다른 도메인의 도메인 컨트롤러 모두에 대해 ICMP, LDAP(Lightweight Directory Access Protocol) UDP 389 및 Kerberos UDP 88과 TCP 88 트래픽을 요구합니다. 도메인 구성원은 SMB(서버 메시지 블록) TCP 445, RPC(원격 프로시저 호출) 및 LDAP TCP 389 같은 자체 도메인의 도메인 컨트롤러에서 추가 트래픽 종류를 요구합니다. 보안 요구 사항이 극단적이지 않은 경우 예외는 단순성을 위해 도메인 컨트롤러 IP 주소를 가진 "모든 트래픽"에 대해 구현되며 필터 수를 줄입니다. TCP 포트 23을 사용하여 UNIX 시스템에 액세스하는 아웃바운드 Telnet 같이 주소 목록을 유지할 필요가 없도록 대상 주소 대신 포트로 특정 응용 프로그램 트래픽을 제외하려는 경우가 있습니다. 예를 들어, 다음 아웃바운드 예외를 고려하십시오. My IP Address to Any IP address, TCP, src port Any, dst port 23, mirrored 해당하는 인바운드 필터는 다음과 같습니다. Any IP Address to My IP address, TCP, src port 23, dst port Any 이 인바운드 필터는 Telnet 연결 요청의 응답을 허용하지만 공격자가 IPsec 인증 요구 사항을 우회하고 호스트의 열린 포트에 액세스할 수 있습니다. 조직은 이 필터 설계를 사용하기 전에 이러한 잠재적 공격의 보안 위험을 신중하게 검토해야 합니다. 대상 IP 주소를 지정하는 경우 위험은 확실히 최소화됩니다. Kerberos 인증 프로토콜에 대한 기본 예외를 해제하는 경우 이와 동일한 상황이 존재할 수 있습니다. 기본 예외의 설계 및 보안 영향에 대한 자세한 내용은 Microsoft 기술 자료 문서 [811832](https://support.microsoft.com/?kbid=811832)(https://support.microsoft.com/?kbid=811832) 및 [810207](https://support.microsoft.com/?kbid=810207)(https://support.microsoft.com/?kbid=810207)을 참조하십시오. 기본 예외를 사용하지 않는다는 가정 하에 IPsec 정책을 설계해야 합니다. 예외 목록에 시스템 주소를 저장하면 예외 목록을 구현하는 모든 IPsec 정책에 대해 IPsec 호스트로 참가하지 못하도록 시스템을 효과적으로 제외합니다. 게스트 클라이언트를 포함하여 조직에 있는 대부분의 클라이언트는 일반적으로 DHCP, DNS 또는 WINS 같은 인프라 서비스에 액세스해야 하기 때문에 이러한 서비스를 제공하는 서버는 대개 이 방식으로 구현됩니다. ##### Woodgrove 은행 필터 목록 4장의 트래픽 요구 사항 출력을 분석한 후에 Woodgrove 은행 관리자는 다음 표의 필터 목록을 매핑했습니다. **표 5.2: Woodgrove 은행 필터 목록 예**

필터 목록	정의된 필터	프로토콜 또는 포트
안전한 서브넷	Any <-> 192.168.1.0/24 Any <-> 172.10.1.0/24	모두
DNS 예외 목록	Any <-> 192.168.1.21 Any <-> 192.168.1.22	모두
도메인 컨트롤러 예외 목록	Any <-> 192.168.1.21 Any <-> 192.168.1.22	모두
LOB 응용 프로그램 서버 예외 목록	Any <-> 192.168.1.10	모두
WINS 예외 목록	Any <-> 192.168.1.22	모두
DHCP, 협상 트래픽	내 IP 주소 <-> Any	UDP 원본 68, 대상 67
ICMP, 모든 트래픽	내 IP 주소 <-> Any	ICMP 전용

Woodgrove 은행 디자이너는 이 장에서 제공한 지침에 따라 이러한 필터 목록을 만들었습니다. 첫 번째 목록인 안전한 서브넷 목록은 두 필터로 구성됩니다. - Any <-> 192.168.1.0/24 - Any <-> 172.10.1.0/24 이러한 서브넷 필터는 인바운드와 아웃바운드 트래픽을 모두 일치시키도록 미러링되며 모든 프로토콜에서 트리거되도록 구성됩니다. 적절한 필터 동작과 쌍을 이룬 이 필터 목록은 격리 그룹을 구현합니다. Woodgrove 은행 디자이너는 ICMP 네트워크 트래픽에 대한 예외 목록을 구현하기로 선택했습니다. 이 필터 목록은 ICMP 네트워크 트래픽 전용으로 구성된 단일의 미러링된 필터(내 IP 주소 <-> Any)로 구성됩니다. 이 접근 방식을 사용하면 IPsec SA(보안 연결)를 협상했는지에 여부에 관계 없이 관리자는 Ping 유틸리티를 환경에서 문제 해결 도구로 사용할 수 있습니다. 이 솔루션이 제대로 작동하려면 경로 MTU(최대 전송 단위) 검색이 요구되기 때문에 이 방식도 필요했습니다. DHCP 트래픽의 경우 Woodgrove 은행 디자이너는 UDP 포트 68을 위한 새 필터를 만들어 DHCP 클라이언트가 DHCP 서버의 트래픽을 수신하는 것을 허용했습니다. 또한 Woodgrove 은행에는 일부 LOB(업무용) 응용 프로그램이 IPsec 인프라에 참가할 수 없는 서버에서 실행되고 있었습니다. 이러한 서비스를 수용하기 위해 LOB 응용 프로그램 서버 예외 목록이라는 새 예외 필터를 만들어 LOB 응용 프로그램을 호스팅하는 시스템을 위해 Any <-> 192.168.1.10 필터를 추가했습니다. 마지막으로 Woodgrove 은행 설계 팀은 인프라 서비스를 식별하고 해당 예외 목록을 만들어 격리 그룹에 대한 IPsec 설정에 관계 없이 모든 클라이언트가 이러한 서비스를 제공하는 서버와 직접 통신할 수 있도록 했습니다. 다음 서비스와 관련된 예외 목록을 만들었습니다. - **DNS**. 이 목록은 네트워크에 있는 모든 클라이언트가 이름 조회를 수행할 수 있도록 DNS 서버를 제외합니다. - **도메인 컨트롤러**. 이 목록을 사용하면 도메인 참가 시스템이 도메인 컨트롤러를 사용하여 인증할 수 있습니다. - **WINS**. 이 목록은 특히 호스트 장치가 WINS 서버에서 NetBIOS 이름을 조회하는 것을 허용합니다. 이러한 필터는 Any <-> Specific IP Address를 정의하는 미러링된 필터로 구성되어 있으며 모든 프로토콜에서 트리거되도록 구성됩니다. 이러한 컴퓨터에 대한 모든 트래픽이 제외되고 예외 목록의 모든 컴퓨터는 격리 도메인에 있는 모든 신뢰할 수 있는 호스트에 대해 완벽한 TCP/IP 액세스 권한을 갖기 때문에 예외 필터 목록에 있는 컴퓨터 수는 최소한으로 유지되어야 합니다. 따라서 이 접근 방식을 사용하지 않을 경우보다 더 많은 공격 허점을 가질 수 있습니다. 제외된 IP 주소의 인바운드 트래픽 위험을 완화하는 요구 사항에 대한 자세한 내용은 Tools and Templates 폴더에 있는 **Business\_Requirements.xls** 스프레드시트를 참조하십시오. Woodgrove 은행은 IP 주소가 동일하더라도 DNS 서버 및 도메인 컨트롤러에 대해 두 개의 개별 목록을 관리하기로 선택했습니다. Woodgrove는 두 필터 목록 모두 같은 허용 동작을 갖기 때문에 이 접근 방식을 사용했습니다. 또한 Woodgrove 프로덕션 네트워크는 도메인 컨트롤러가 아닌 일부 영역에서 DNS 서버를 사용합니다. 특정 대상 IP 주소를 가지는 대신 DHCP용 필터는 모든 DHCP 클라이언트 아웃바운드 트래픽과 일치하도록 설계되었습니다. 이 필터의 미러는 DHCP 서버의 응답을 허용합니다. 설명한 것처럼 원본 포트 67을 사용하는 모든 IP 주소의 인바운드 공격도 허용할 수 있습니다. 그러나 인바운드 공격은 DHCP 클라이언트가 사용하는 클라이언트의 대상 포트 68로 제한됩니다. Woodgrove 은행은 모든 DHCP 서버용 필터를 갖지 못하도록 하고 위험 평가가 DHCP 클라이언트 포트에 대한 인바운드 공격 위험이나 승인 받지 않은 DHCP 서버의 위험 등급을 높게 지정하지 않았기 때문에 이 설계를 사용했습니다. 이 절에는 각 필터에 대한 자세한 설명이 포함되어 있지 않습니다. 그러나 IPsec 모니터 및 명령줄 도구가 필터 목록의 정보가 아닌 각 필터 설명을 표시하기 때문에 필터 설명 필드를 사용하여 각 필터를 신중하게 정의하는 것이 좋습니다. #### IPsec 필터 동작 필터 동작은 필터 목록 내의 필터와 일치된 후에 IP 패킷을 처리하는 방법을 정의합니다. 필터 동작은 다양한 격리 그룹을 구현하는 기초입니다. Windows 운영 체제와 함께 제공되는 세 가지 기본 필터 동작이 있지만 이것을 제거하고 새 필터 동작을 만드는 것이 좋습니다. 이 접근 방식을 사용하면 설계의 일부로 만드는 동작만 사용되도록 보장할 수 있습니다. 각 필터 동작은 이름, 설명 및 보안 방법으로 구성되어 있습니다. ##### 이름 필터 동작에 필터 동작이 무엇을 수행하는지 반영하는 의미 있는 이름을 지정합니다. ##### 설명 설명 필드에 필터 동작에 대한 자세한 설명을 입력합니다. ##### 보안 방법 필터 동작 내에 구현되는 보안 방법은 필터 목록의 관련 필터에 일치하는 패킷 처리를 위한 요구 사항에 의해 결정됩니다. 다음과 같은 세 가지 옵션을 사용할 수 있습니다. - **차단**. IP 패킷이 관련 필터와 일치하는 경우 패킷이 차단됩니다. 즉, 패킷이 버려지거나 무시됩니다. - **허용**. IP 패킷이 관련 필터와 일치하는 경우 패킷은 IPsec에 의해 더 이상 처리되지 않고 IPsec 계층을 통과할 수 없습니다. - **협상**. 아웃바운드 패킷이 필터 기준을 충족하는 경우 IPsec은 상대적 순서에 따라 필터 동작에 있는 보안 방법 중 하나를 협상하려고 시도합니다. 목록에서 보안 방법이 위에 있을 수록 가지고 있는 기본 설정이 높습니다. 각 보안 방법은 무결성을 사용할지 여부, 암호화를 설정할지 여부 및 암호화 알고리즘이 어떤 기능을 제공할지 결정할 수 있습니다. 협상 동작을 가진 필터와 일치하는 인바운드 패킷의 처리는 **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답** 설정에 의해 결정됩니다. 다음 표는 각 보안 방법에 대해 가능한 암호화 옵션을 나열합니다. **표 5.3: 보안 및 암호화 옵션**

보안 방법	암호화 옵션	설명
AH(인증 헤더)	MD5 SHA-1	IP 페이로드(데이터)와 IP 헤더(주소) 무결성 및 암호화 없는 인증을 모두 제공합니다. AH는 NAT를 실행하는 장치를 통과할 수 없습니다.
ESP – 무결성	<없음> MD5 SHA-1	IP 페이로드(데이터)에 대해서만 데이터 무결성과 인증을 제공합니다. 암호화와 함께 또는 암호화 없이 사용할 수 있습니다. 인증 없이 ESP를 사용하는 것은 좋지 않습니다.
ESP – 암호화	<없음> 3DES DES	DES 또는 3DES를 사용하여 IP 페이로드(데이터) 암호화를 제공합니다. 암호화가 필요하지 않을 때 널 암호화 알고리즘과 함께 사용할 수 있습니다.

Windows 2000 SP4, Windows XP SP2 및 Windows Server 2003 IPsec 구현은 이제 IPsec 전송 모드 ESP에 대해 NAT-T 기술을 지원할 뿐만 아니라 L2TP/IPsec VPN 클라이언트 터널에 대해 NAT-T를 지원합니다. Windows 2000 SP4의 경우 NAT-T를 업데이트해야 합니다. IPsec 전송 모드 NAT-T에 대한 Windows 2000 및 Windows XP 지원은 IPsec으로 보호되는 TCP 트래픽에 TCP PMTU(Path MTU) 검색이 지원되지 않기 때문에 SP2 이전의 Windows 2000 및 Windows XP 버전으로 제한됩니다. Windows Server 2003은 이 지원을 제공합니다. NAT-T 기술은 IP 헤더 다음에 UDP 헤더를 사용하여 ESP를 캡슐화합니다. IKE는 NAT가 경로에 존재할 때 자동으로 검색하고 ESP가 보안 방법 목록에서 허용될 때마다 UDP-ESP를 사용합니다. 또한 현재 Windows IPsec 구현은 미국 연방 정부 AES(Advanced Encryption Standard)를 지원하지 않습니다. 이것은 향후 Windows 버전에서 변경될 것입니다. 다음 암호화 옵션을 AH 및 ESP에 사용할 수 있습니다. - **MD5**. 이 해시 알고리즘은 128비트 암호화 키를 사용하여 패킷 콘텐츠의 다이제스트를 생성합니다. MD5는 미국 연방 보안 시나리오의 승인된 알고리즘이 아닙니다. - **SHA-1**. 이 해시 알고리즘은 보다 강력한 160비트 암호화 키를 사용하여 패킷 콘텐츠의 다이제스트를 생성합니다. SHA-1의 더 긴 키 길이는 높은 처리 오버헤드가 있기는 하지만 더욱 강력한 보안을 제공합니다. SHA-1은 미국 연방 보안 규정에 승인된 알고리즘입니다. ESP는 데이터 무결성과 인증을 적용하는 경우에만 암호화 알고리즘을 사용하지 않도록 구성할 수 있습니다. 이 구성을 일반적으로 ESP-널이라고 하며 통신 연결을 설정하고 ESP 패킷 내에 들어 있는 IP 패킷의 데이터 일부에 대해 무결성 검사를 수행하기 전에 호스트를 인증하는 기능을 제공합니다. 또한 ESP는 IP 패킷의 데이터 섹션을 암호화할 수도 있습니다. 다음 두 가지 암호화 옵션을 사용할 수 있습니다. - **DES**. 이 옵션은 단일 56비트 키를 사용하며 각 블록을 한 번 처리합니다. DES는 RFC(Request for Comment) 준수를 위해 제공됩니다. DES 암호화를 손상시키는 공격자의 능력이 발전되었기 때문에 DES를 사용하지 않는 것이 좋습니다. - **3DES**. 이 옵션은 세 가지 고유한 56비트 키를 사용하여 각 블록을 세 번 처리합니다. DES가 지원되기는 하지만 더욱 안전한 3DES를 사용하는 것이 좋습니다. 그러나 3DES는 성능이 다소 느리며 DES보다 처리 오버헤드가 더 높습니다. 매우 높은 보안 요구 사항을 충족시킬 필요가 있을 경우 AH 및 ESP 프로토콜을 서로 결합할 수 있습니다. 예를 들어, 데이터 암호화 외에 IP 헤더 무결성에 대한 명확한 요구 사항이 있을 경우 AH를 SHA-1 무결성 및 ESP – 3DES 암호화와 함께 사용하도록 보안 방법을 구성할 수 있습니다. 데이터 무결성만 요구되는 경우에는 ESP-널을 SHA-1과 함께 사용할 수 있습니다. 보안 옵션의 모든 조합을 선택할 수 있지만 AH는 데이터와 주소 헤더 무결성을 모두 제공한다는 것을 알아야 합니다. AH 및 ESP를 사용하여 무결성을 제공하는 것은 패킷 데이터에 대해 추가 무결성 보호를 제공하지 못하며 패킷 처리와 관련된 작업 부하만 증가할 뿐입니다. 또한 AH와 ESP를 조합해도 AH가 겪고 있는 NAT 장벽 문제를 극복하지 못합니다. 따라서 ESP 이외에 AH를 사용하는 것은 가장 높은 보안 환경의 경우에만 적합합니다. 필터 동작의 보안 방법을 설계할 때는 신중한 계획이 요구됩니다. 두 컴퓨터가 성공적으로 협상하려면 해당 필터 동작에 공통된 보안 방법이 적어도 하나가 있어야 합니다. 각 필터 동작은 다른 종류의 협상을 수용하기 위해 둘 이상의 협상 방법을 포함할 수 있습니다. 예를 들어, 일반적으로 시스템은 ESP-널만 협상할 수 있지만, 필터 동작은 ESP-3DES에 대한 협상 방법도 포함할 수 있습니다. 이 접근 방식은 필요할 경우 시스템이 3DES 암호화 연결을 협상할 수 있도록 합니다. 보안 방법을 선택하는 것 외에 필요할 경우 각 보안 방법에 대해 세션 키 설정을 설정할 수 있습니다. 기본 설정에서 IPsec SA 수명은 100MB의 데이터가 통과할 때 또는 1시간이 경과한 후로 구성됩니다. 이러한 설정은 IKE 빠른 모드에 의해 IPsec 보안 연결의 새로운 쌍이 언제 재협상되는지 제어합니다. IKE 빠른 모드 프로세스를 "키 다시 대조(rekeying)"라고 하지만 기존 IPsec SA 쌍에 대해서 실제로 키가 새로 고쳐지지는 않습니다. IPsec은 수명이 만료될 경우 패킷을 버려야 합니다. 따라서 바이트 또는 초 단위 수명이 만료되기 전에 재협상을 시도합니다. 수명을 너무 낮게 설정한 경우 패킷이 손실될 수 있습니다. 마찬가지로 서버가 많은 클라이언트의 IPsec SA를 유지하는 경우 CPU 사용이 증가할 수 있습니다. IPsec SA를 갱신하면 공격자가 세션 키 중 하나를 확인한 경우에도 공격자가 전체 통신을 해독할 수 없도록 합니다. 수명을 늘리면 공격자가 세션 키에 대해 더 많은 정보를 알 수 있습니다. 따라서 작업에 반드시 필요하고 정교한 암호 공격으로부터 적절한 수준의 보호를 정의하는 특정 보안 요구 사항을 작성할 수 있는 경우가 아니면 수명을 변경해서는 안 됩니다. ##### 보안 협상 옵션 IPsec 정책에 대해 다음과 같은 보안 협상 옵션을 설정할 수 있습니다. - 인바운드 통과 - 선택 취소 - 세션 키 전달 완전 보안 사용 ###### 인바운드 통과 인바운드 통과 옵션은 클라이언트 정책이 비침입 "기본 응답" 규칙을 사용할 수 있도록 내부 서버 정책에서 사용하도록 설계되었습니다. 이 옵션을 설정하면 인바운드 필터와 일치하는 일반 텍스트 연결 요청이 허용됩니다. 서버의 연결 응답이 아웃바운드 필터와 일치하여 클라이언트에 대한 IKE 주 모드 협상 요청이 트리거됩니다. 인터넷에 연결된 컴퓨터에서는 인바운드 공격이 IPsec 계층을 통과할 수 있기 때문에 이 옵션을 설정해서는 안 됩니다. 또한 들어오는 패킷의 원본 IP에 대해 강제로 서버가 IPsec SA 협상을 시도하도록 합니다. 원본 IP 주소를 스푸핑함으로서 공격자는 IKE가 잘못된 수 많은 IP 주소와 협상을 시도할 때 서버에서 서비스 거부를 야기할 수 있습니다. 인바운드 통과를 설정하려면 **필터 관리 동작** 대화 상자에서 **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답**을 선택합니다. **참고:** 클라이언트에 할당된 정책이 기본 응답 규칙을 설정하지 않은 경우 IPsec 통신에 대한 응답이 없기 때문에 이 옵션을 해제해야 합니다. 또한 서비스 거부 공격 벡터로 사용될 수 있습니다. ###### 비보안 상태로 복구 선택 취소 옵션은 초기 IKE 주 모드 협상이 대상 컴퓨터로부터 응답을 얻지 못하는 경우 IPsec 보호 없이 트래픽이 보내지도록 허용하는(원본) 컴퓨터의 기능을 제어합니다. IPsec을 지원하지 않는 호스트는 IKE 협상 요청에 대해 IKE를 사용하여 응답할 수 없게 됩니다. 이러한 호스트는 "IPsec을 인식하지 않는" 컴퓨터라고 합니다. 그러나 IKE 주 모드 응답이 없다고 해서 반드시 컴퓨터에 IPsec의 기능이 없다는 것을 의미하지는 않습니다. IPsec을 사용할 수 있는 컴퓨터에 활성 IPsec 정책이 없는 것일 수 있습니다. 또는 활성 IPsec 정책에 허용 및 차단 동작만 있는 것일 수 있습니다. 활성 IPsec 정책이 원본 컴퓨터의 IP 주소를 사용하여 협상하도록 설계되지 않았을 수도 있습니다. IPsec 용어로 IPsec을 사용하지 않는 네트워크 트래픽을 *일반 텍스트*로 되었다고 말합니다. 3초 동안 대상 컴퓨터에서 응답이 없을 경우 소프트 보안 연결(소프트 SA)이 만들어지고 통신은 일반 텍스트로 시작됩니다. 초기 배포의 경우 클라이언트가 IPsec이 설정되지 않은 호스트와 통신할 수 있도록 이 옵션을 설정하는 것이 좋습니다. 또한 이 옵션을 사용하면 문제 해결을 위해 IPsec 서비스를 중지했을 때 임시로 일반 텍스트 연결을 다시 설정할 수도 있습니다. 대상 컴퓨터가 IKE 응답을 제공하지 않고 어떤 이유로 IKE 협상 동안 실패한 경우 원본 컴퓨터의 IPsec은 아웃바운드 패킷을 버려 통신을 효과적으로 차단합니다. 선택 취소 옵션을 설정하려면 필터 **동작 관리 대화** 상자에서 **IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용**을 선택합니다. **참고:** 이 옵션이 작동하는 방식이 Windows 2000 SP3 이상, Windows XP SP1 또는 Windows Server 2003을 실행하는 컴퓨터에서 변경되었습니다. 이 옵션만 설정한 경우 시스템은 암호화되지 않은 상태로 통신을 시작할 수 있지만 IPsec을 인식하지 않는 시스템의 통신 요청은 허용하지 않습니다. 시스템이 IPsec을 인식하지 않는 시스템의 요청에 응답하고 통신을 시작해야 하는 경우 **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답** 옵션 및 **IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용** 옵션을 모두 선택해야 합니다. 시스템이 적절한 서비스 팩이 설치되지 않은 Windows 2000 또는 Windows XP를 실행하는 경우 **IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용**을 선택하고 **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답**을 선택하지 않은 경우에도 클라이언트는 보안되지 않은 통신 요청을 허용하게 됩니다. 이 동작은 **IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용** 옵션을 선택했을 때 IPsec은 관련된 인바운드 필터를 인바운드 통과 필터로 처리하기 때문에 발생합니다. **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답**이 선택되었을 때도 같은 동작이 발생합니다. ###### 세션 키 전달 완전 보안 사용 세션 키 전달 완전 보안(PFS) 사용 옵션은 마스터 키 자료를 사용하여 모든 세션 키 또는 첫 번째 세션 키만 생성할 수 있는지 여부를 결정합니다. 이 옵션을 설정한 경우 마스터 키는 한 번만 사용될 수 있으며 각 추가 세션 키 재협상을 위해서는 세션 키를 생성하기 전에 새 키 교환을 수행하여 새 마스터 키를 생성해야 합니다. 이 요구 사항은 마스터 키가 손상된 경우 공격자가 추가 세션 키를 생성하여 트래픽 스트림을 암호 해독할 수 없도록 합니다. 각 세션 키 갱신 간격으로 키 교환을 수행하는 추가 오버헤드 비용 때문에 이 옵션을 설정하지 않는 것이 좋습니다. 인바운드 통과, 선택 취소 및 세션 키와 마스터 키 PFS 옵션에 대한 자세한 내용은 Microsoft 다운로드 센터의 [Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server](https://www.microsoft.com/download/details.aspx?familyid=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en) (영문)(www.microsoft.com/downloads/details.aspx?familyid=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en)에서 "Security Negotiation Options" 절을 참조하십시오. ##### Woodgrove 은행 IPsec 필터 동작 다음 표는 Woodgrove 은행 시나리오의 다양한 격리 그룹을 구현하는 데 사용되는 필터 동작 이름과 설명을 제공합니다. **표 5.4: IPsec 필터 동작 및 설명**

필터 작업	설명
IPsec – 차단	필터와 일치하는 트래픽을 차단합니다.
IPsec – 허용	필터와 일치하는 트래픽을 허용합니다.
IPsec – 요청 모드 (인바운드 수락, 아웃바운드 허용)	호스트는 IPsec 또는 일반 텍스트의 인바운드 패킷을 수락합니다. 아웃바운드 트래픽의 경우 응답이 없는 경우 IKE 협상을 트리거하고 선택 취소를 허용합니다. 이 필터 동작은 경계 격리 그룹을 구성하는 데 사용됩니다.
IPsec – 보안 요청 모드(인바운드 무시, 아웃바운드 허용)	호스트는 패킷이 IPsec에 의해 보호될 때만 인바운드 TCP/IP 액세스를 허용하고 비 IPsec 인바운드 패킷은 무시합니다. 아웃바운드 트래픽의 경우 응답???´ 없는 경우 IKE 협상을 트리거하고 선택 취소를 허용합니다. 이 필터 동작은 신뢰할 수 없는 호스트에 대한 ••„웃 바운드 연결이 허용되는 격리 도메인을 구현하는 데 사용됩니다.
IPsec – 전체 요청 모드(인바운드 무시, 아웃바운드 허용 안 함)	호스트는 인바운드와 아웃바운드 패킷 모두에 대해 IPsec으로 보호되는 통신을 요구합니다. 이 필터 동작은 모든 통신이 IPsec으로 보호되는 대체 없음(No Fallback) 격리 그룹을 구현하는 데 사용됩니다.
IPsec – 암호화 요구 모드(인바운드 무시, 아웃바운드 허용 안 함)	호스트는 패킷이 IPsec ESP 3DES 암호화에 의해 보호될 때만 인바운드 TCP/IP 액세스를 허용하고 비 IPsec 인바운드 패킷은 무시합니다. 아웃바운드 트래픽의 경우 IPsec ESP 3DES 암호화를 요구하는 IKE 협상을 트리거합니다. 이 필터 동작은 암호화 격리 그룹을 구현하는 데 사용됩니다.

처음 두 필터 동작은 간단합니다. 차단 필터 동작은 이 동작과 관련된 필터 목록의 필터와 일치하는 모든 트래픽을 취소합니다. 허용 필터 동작은 일치하는 필터를 갖는 모든 관련 필터 목록에 대해 트래픽이 발생하는 것을 허용합니다. 표 5.4에서 마지막 4개의 •„터 동작?€ Woodgrove 은행 시나리오에서 격리 그룹을 구현하는 데 사용됩니다. Woodgrove 은행 관리자는 4가지 보안 격리 그룹을 구현합니다. 이 구성을 배포하려면 허용과 차단 필터 동작 이외에 사용자 지정 보안 협상 방법을 가진 최소 세 가지 필터 동작을 정의해야 합니다. Woodgrove 은행에는 특정 보안 격리 그룹 내에서 컴퓨터를 서로 격리하기 위한 추가 요구 사항이 없습니다. 은행은 다음 표에서 4가지 협상된 필터 동작이 환경을 구현하기에 충분하다고 결정했습니다. **표 5.5: 지원되는 보안 방법**

필터 작업	지원되는 보안 방법
IPsec – 요청 모드(인바운드 수락, 아웃바운드 허용)	ESP – SHA-1, <없음> ESP – SHA-1, 3DES
IPsec – 보안 요청 모드(인바운드 무시, 아웃바운드 허용)	ESP – SHA-1, <없음> ESP – SHA-1, 3DES
IPsec – 전체 요청 모드(인바운드 무시, 아웃바운드 허용 안 함)	ESP – SHA-1, <없음> ESP – SHA-1, 3DES
IPsec – 암호화 요구 모드(인바운드 무시, 아웃바운드 허용 안 함)	ESP – SHA-1, 3DES

Woodgrove는 NAT를 사용하는 조직에 네트워크 장치가 있기 때문에 AH 대신 IPsec ESP를 사용합니다. 또한 Woodgrove 은행에는 조직의 일부 서버를 위한 암호화를 구현하는 요구 사항도 있었습니다. 따라서 모든 정책에 암호화를 사용하는 옵션이 필요했습니다. 이런 이유로 Woodgrove 은행은 전적으로 IPsec ESP를 기반으로 하는 보안을 구현하기로 선택했습니다. ESP 무결성을 위해 Woodgrove 은행은 보다 강력한 보안을 위해서 뿐만 아니라 포함된 재무 정보 처리에 승인된 알고리즘을 사용하는 미국 정부 규정을 만족해야 하기 때문에 MD5 대신 SHA-1을 사용하기로 선택했습니다. Woodgrove 은행은 PFS의 사용을 요구하는 특정 보안 위협은 없었기 때문에 모든 필터 동작에 PFS를 구현하지 않기로 선택했습니다. 또한 Woodgrove는 키 재협상으로 인한 컴퓨터의 성능 영향을 피하기로 결정했습니다. ##### 격리 도메인 필터 동작 격리 도메인을 구현하기 위해 Woodgrove 은행 관리자는 IPSEC – 보안 요청 모드(인바운드 무시, 아웃바운드 허용) 필터 동작을 만들었습니다. Woodgrove 은행에는 격리 도메인과 기타 격리 그룹 사이의 통신을 위한 여러 가지 비즈니스 요구 사항이 있습니다. 따라서 격리 도메인에 있는 클라이언트는 이 가이드 4장의 표 4.5 및 4.6에서 설명하는 다음과 같은 동작을 수행합니다. - 대체 없음 격리 그룹에 있는 호스트와 통신 시작 - 대체 없음 격리 그룹에 있는 호스트의 통신 수락 - 암호화 격리 그룹에 있는 호스트와 통신 시작 - 암호화 격리 그룹에 있는 호스트의 통신 수락 - 경계 격리 그룹에 있는 호스트와 통신 시작 - 경계 격리 그룹에 있는 호스트의 통신 수락 - 신뢰할 수 있는 시스템과 통신 시작 격리 도메인에 있는 클라이언트는 신뢰할 수 없는 시스템의 통신을 수락할 수 없습니다. IPsec 정책은 필터와 필터 동작을 사용하여 인바운드와 아웃바운드 IP 패킷을 가로챕니다. IKE는 두 컴퓨터를 모두 인증하지만 특정 IP 주소를 사용하는 컴퓨터의 그룹 구성원은 초기 연결 요청을 아웃바운드로 보낸 시간에 알려지지 않습니다. 따라서 특히 IPsec 및 IKE는 특정 ID나 격리 그룹을 사용한 특정 방식으로 통신을 시작하도록 구성할 수 없습니다. 또한 이러한 격리 그룹의 구성원인 컴퓨터는 내부 네트워크 어디에나 위치할 수 있습니다. 그러므로 IP 주소를 사용하여 격리 그룹을 정의하거나 이와 유사한 작업을 수행할 수 없습니다. IPsec 정책에서 이러한 요구 사항을 구현하려면 모든 내부 서브넷을 지정하는 필터 목록으로 작동하는 필터 동작을 설계해야 합니다. 앞의 요구 사항을 두 가지 기본 동작으로 줄일 수 있습니다. - 아웃바운드 - 해당 필터(모든 내부 서브넷)와 일치하는 패킷의 경우 ESP-널을 기본으로 하고 ESP–SHA-1–3DES를 포함하는 IPsec ESP를 사용하여 트래픽을 보호하려고 시도하는 IKE 협상 요청을 트리거합니다. 대상 호스트가 IKE에 응답하지 않는 경우 선택 취소를 허용합니다. - 인바운드 - 해당 필터(모든 내부 서브넷)와 일치하는 패킷의 경우 유효한 IPsec ESP 패킷 내에서 아직 보호되지 않으면 트래픽을 무시합니다. 통신에 암호화 격리 그룹을 설정하려면 보안 방법은 암호화 격리 그룹에 정의된 보안 방법(ESP–SHA-1–3DES 알고리즘)을 포함합니다. 암호화 보안 협상 방법에 대한 자세한 내용은 이 장 뒷부분의 "암호화 격리 그룹 필터 동작" 절을 참조하십시오. 격리 도메인 내의 트래픽, 경계 및 대체 없음 격리 그룹에서 Woodgrove 은행은 ESP-널을 SHA-1과 함께 사용합니다. 인바운드 일반 텍스트를 무시하도록 필터 동작에서 **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답** 옵션을 해제해야 합니다. 이 접근 방식은 격리 도메인의 호스트가 IPsec 환경에 참가하지 않는 컴퓨터의 트래픽을 수락하지 않도록 합니다. IPSEC – 안전한 요청 보안(인바운드 무시, 아웃바운드 허용) 필터 동작은 격리 도메인의 구성원이 신뢰할 수 없는 시스템과 통신을 시작하는 것을 허용하도록 구성됩니다. 이 동작은 필터 동작에서 **IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용** 옵션을 설정하여 구현됩니다. 격리 도메인의 신뢰할 수 있는 호스트가 신뢰할 수 없는 호스트(또는 다른 ipsec을 인식하지 않는 시스템)에 대해 아웃바운드 연결을 시작하는 경우 IPsec 소프트 SA가 설정되며 트래픽 흐름이 멈춘 후 5분 동안 활성 상태를 유지합니다. 따라서 신뢰할 수 없는 시스템이 이 시간 동안 신뢰할 수 있는 호스트로 다시 일반 텍스트 연결을 시작할 수 있습니다. 소프트 SA가 시간 초과된 후에 신뢰할 수 있는 호스트는 해당 시스템의 일반 텍스트 트래픽을 더 이상 수락하지 않습니다. IPsec 필터링 및 소프트 SA 지원은 많은 방화벽이 수행하는 것처럼 상태 저장 필터링 같은 연결 관련 보호를 제공하도록 설계되지 않았습니다. 소프트 SA는 관련 필터와 일치하는 모든 트래픽을 허용합니다. 이 프로세스에 대한 자세한 내용은 부록 A "IPsec 정책 개념의 개요"의 "IKE 주 모드 SA 및 IPsec SA"를 참조하십시오. ##### 경계 격리 그룹 필터 동작 경계 격리 도메인을 구현하기 위해 Woodgrove 은행 관리자는 IPSEC – 요청 모드(인바운드 수락, 아웃바운드 허용) 필터 동작을 만들었습니다. Woodgrove 은행에는 경계 격리 그룹과 기타 격리 그룹 사이의 통신에 관한 여러 가지 비즈니스 요구 사항이 있습니다. 따라서 경계 격리 그룹의 클라이언트는 4장의 표 4.5 및 4.6에서 설명하는 다음 동작을 수행할 수 있습니다. - 대체 없음 격리 그룹에 있는 호스트와 통신 시작 - 대체 없음 격리 그룹에 있는 호스트의 통신 수락 - 격리 도메인에 있는 호스트와 통신 시작 - 격리 도메인에 있는 호스트의 통신 수락 - 암호화 격리 그룹에 있는 호스트의 통신 수락 - 신뢰할 수 있는 시스템과 통신 시작 - 신뢰할 수 없는 시스템의 통신 수락 IPsec 정책에서 이러한 요구 사항을 구현하려면 모든 내부 서브넷을 지정하는 필터 목록으로 작동하는 필터 동작을 설계해야 합니다. 나열된 요구 사항을 두 가지 기본 동작으로 줄일 수 있습니다. - 아웃바운드 - 해당 필터(모든 내부 서브넷)와 일치하는 패킷의 경우 ESP-널을 기본으로 하고 ESP–SHA-1–3DES를 포함하는 IPsec ESP를 사용하여 트래픽을 보호하려고 시도하는 IKE 협상 요청을 트리거합니다. 대상 호스트가 IKE에 응답하지 않는 경우 선택 취소를 허용합니다. - 인바운드 - 해당 필터(모든 내부 서브넷)와 일치하는 일반 텍스트 패킷을 수락합니다. 격리 도메인 및 대체 없음 격리 그룹과의 트래픽을 시작하고 수락하는 요구 사항을 충족시키기 위해 Woodgrove 은행은 격리 도메인과 대체 없음 격리 그룹에 사용되는 보안 협상 방법을 필터 동작에 제공하도록 했습니다. 무결성을 위해 Woodgrove가 선택한 일반 보안 협상은 SHA-1을 사용한 ESP입니다. 경계 격리 그룹의 호스트는 신뢰할 수 없는 시스템과 통신하는 것이 허용됩니다. 이 기능을 이용하기 위해 Woodgrove 은행 관리자 팀은 이 필터 동작에 대해 **IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용** 및 **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답** 옵션을 모두 설정했습니다. 이러한 옵션을 둘 모두 설정함으로써 Woodgrove 은행은 호스트가 보안되지 않은 인바운드 트래픽을 수락하고 보안되지 않은 아웃바운드 트래픽의 경우 선택 취소할 수 있도록 했습니다. ##### 대체 없음 격리 그룹 필터 동작 대체 없음 격리 그룹을 구현하기 위해 Woodgrove 은행 관리자는 IPSEC – 전체 요청 모드(인바운드 무시, 아웃바운드 허용 안 함) 필터 동작을 만들었습니다. Woodgrove 은행에는 대체 없음 격리 그룹과 기타 격리 그룹에 있는 호스트 사이의 통신을 위한 여러 가지 비즈니스 요구 사항이 있습니다. 따라서 대체 없음 격리 그룹은 다음 동작을 수행할 수 있습니다. - 격리 도메인에 있는 호스트와 통신 시작 - 격리 도메인에 있는 호스트의 통신 수락 - 암호화 격리 그룹에 있는 호스트와 통신 시작 - 암호화 격리 그룹에 있는 호스트의 통신 수락 - 경계 격리 그룹에 있는 호스트와 통신 시작 - 경계 격리 그룹에 있는 호스트의 통신 수락 대체 없음 격리 그룹의 클라이언트는 신뢰할 수 있는 시스템과 통신을 시작하거나 통신을 수락할 수 없습니다. IPsec 정책에서 이러한 요구 사항을 구현하려면 모든 내부 서브넷을 지정하는 필터 목록으로 작동하는 필터 동작을 설계해야 합니다. 나열된 요구 사항을 두 가지 기본 동작으로 줄일 수 있습니다. - 아웃바운드 - 해당 필터(모든 내부 서브넷)와 일치하는 패킷의 경우 ESP-널을 기본으로 하고 ESP–SHA-1–3DES를 포함하는 IPsec ESP를 사용하여 트래픽을 보호하려고 시도하는 IKE 협상 요청을 트리거합니다. 대상 호스트가 IKE에 응답하지 않는 경우 선택 취소를 허용하지 *않습니다*. - 인바운드 - 해당 필터(모든 내부 서브넷)와 일치하는 일반 텍스트 패킷의 경우 무시합니다. 통신에 암호화 격리 그룹을 설정하려면 보안 협상 방법은 암호화 격리 그룹에 정의된 암호화 협상 방법을 포함합니다. 암호화 보안 협상 방법에 대한 자세한 내용은 이 장의 "암호화 격리 그룹 필터 동작" 절을 참조하십시오. 경계 격리 그룹과 대체 없음 격리 그룹에 대한 트래픽의 경우 무결성 보안 협상 방법을 위해 Woodgrove 은행은 ESP를 SHA-1과 함께 사용합니다. 필터 동작의 **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답** 확인란을 선택 취소하여 대체 없음 격리 그룹을 만듭니다. 이 접근 방식은 대체 없음 격리 그룹의 호스트가 IPsec을 사용하여 모든 인바운드 및 아웃바운드 트래픽을 반드시 보호하도록 합니다. IPsec 환경에 참가하지 않는 컴퓨터의 트래픽은 수락하지 않습니다. IPSEC – 전체 요청 모드(인바운드 무시, 아웃바운드 허용 안 함) 필터 동작은 이 필터 동작을 사용하는 컴퓨터가 IPsec 인프라에 참가하지 않는 컴퓨터와 통신을 시작하는 것을 허용하지 않습니다. 이 요구 사항을 적용하기 위해 **IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용** 옵션을 해제했습니다. ##### 암호화 격리 그룹 필터 동작 Woodgrove 은행은 ESP를 기본 무결성 프로토콜로, SHA-1을 암호화 옵션으로 선택했습니다. 또한 암호화 격리 그룹의 호스트는 격리 도메인 및 대체 없음 격리 그룹의 호스트와 통신해야 합니다. 필터 동작은 정보를 암호화하는 보안 협상 방법을 포함하도록 구성했습니다. Woodgrove 은행에는 암호화 격리 그룹과 기타 격리 그룹에 있는 호스트 사이의 통신에 관한 여러 가지 비즈니스 요구 사항이 있습니다. 따라서 암호화 격리 그룹의 클라이언트는 표 4.6의 다음 동작을 수행할 수 있습니다. - 격리 도메인에 있는 호스트와 통신 시작 - 격리 도메인에 있는 호스트의 통신 수락 - 대체 없음 격리 그룹에 있는 호스트와 통신 시작 - 대체 없음 격리 그룹에 있는 호스트의 통신 수락 - 경계 격리 그룹에 있는 호스트와 통신 시작 암호화 격리 그룹의 컴퓨터는 경계 격리 그룹에 있는 호스트의 통신을 받는 것이 금지됩니다. IPsec 정책에서 이러한 요구 사항을 구현하려면 모든 내부 서브넷을 지정하는 필터 목록으로 작동하도록 필터 동작을 설계해야 합니다. 나열된 요구 사항을 두 가지 기본 동작으로 줄일 수 있습니다. - 아웃바운드 - 해당 필터(모든 내부 서브넷)와 일치하는 패킷의 경우 IPsec ESP–SHA-1–3DES만 사용하여 트래픽을 보호하려고 시도하는 IKE 협상 요청을 트리거합니다. 대상 호스트가 IKE에 응답하지 않는 경우 선택 취소를 허용하지 *않습니다*. - 인바운드 - 해당 필터(모든 내부 서브넷)와 일치하는 일반 텍스트 패킷의 경우 무시합니다. IPsec ESP–SHA-1–3DES를 허용하는 신뢰할 수 있는 호스트의 IKE 협상 요청만 수락합니다. 암호화 격리 그룹의 클라이언트는 경계 격리 그룹의 통신을 수락할 수 없으며 신뢰할 수 없는 시스템과 통신을 시작하거나 통신을 수락할 수 없습니다. 격리 도메인과 통신을 설정하려면 IPSEC – 암호화 요구 모드(인바운드 무시, 아웃바운드 허용 안 함)에 사용되는 암호화 보안 협상 방법이 IPSEC – 보안 요청(인바운드 무시, 아웃바운드 허용) 및 IPSEC – 전체 요청 모드(인바운드 무시, 아웃바운드 허용 안 함) 필터 동작에도 제공됩니다. Woodgrove 은행은 DES보다 나은 보안을 제공하지만 추가 오버헤드 비용 부담이 있는 3DES 암호화 방법을 사용합니다. 신뢰할 수 없는 시스템과의 통신을 시작하거나 수락하지 않는 요구 사항 때문에 Woodgrove 은행은 **보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답** 옵션을 설정하지 않았습니다. 이 구성은 암호화 격리 그룹의 호스트가 IPsec 환경에 참가하지 않는 컴퓨터의 트래픽을 수락하지 않도록 합니다. 또한 컴퓨터가 IPsec 환경에 참가하지 않은 컴퓨터와 통신을 시작하려고 시도하지 않도록 **IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용** 옵션도 해제했습니다. 경계 격리 그룹 컴퓨터로부터 IPsec 통신을 차단하려면 추가 구성이 필요했습니다. Woodgrove 은행 관리자는 "네트워크에서 이 컴퓨터 액세스 거부" 권한을 사용하여 암호화 격리 그룹 컴퓨터에 대해 IPsec 정책을 제공하는 GPO를 구성했습니다. 이 권한은 경계 격리 그룹에 참가하는 시스템을 위한 모든 컴퓨터 계정을 가진 그룹에 적용되었습니다. 이러한 컴퓨터가 암호화 격리 그룹에 있는 시스템과 통신을 시작하려고 시도한 경우 IKE 인증은 실패하고 통신은 차단됩니다. #### IPsec 정책 IPsec 정책은 IPsec 환경에서 Windows 기반 컴퓨터가 작동하도록 구성합니다. IPsec 정책은 트래픽을 일치시킬 규칙의 모음입니다. Windows 2000을 위한 IPsec 정책은 세 가지 유형이 있습니다. - 로컬 정책 - Active Directory 도메인 정책 - 동적 정책 Windows XP 및 Windows Server 2003은 다음 추가 정책 유형을 지원합니다. - **시작 IPsec 정책**. 로컬 레지스트리에 저장되고 관리됩니다. Windows XP SP2 이상에서만 지원됩니다. 컴퓨터가 IP 주소를 얻는 즉시 적용됩니다. IPsec 서비스를 시작하기 전에 이렇게 할 수 있습니다. 서비스가 영구 정책을 적용할 때 대체됩니다. - **영구 IPsec 정책**. 로컬 컴퓨터의 레지스트리에 저장되고 관리됩니다. 명령줄 도구로 구성합니다. IPsec 서비스를 시작할 때 처음 적용됩니다. 시작 정책을 대체합니다. - **로컬 IPsec 정책**. 로컬 컴퓨터에 저장되고 관리됩니다. Configured by IPsec 정책 관리 MMC(Microsoft 관리 콘솔) 스냅인이나 명령줄 도구로 구성됩니다. 도메인 정책이 할당되지 않은 경우 영구 정책에 추가하여 적용됩니다. - **Active Directory 도메인 IPsec 정책**. Active Directory에 저장됩니다. IPsec 정책 관리 MMC 스냅인 또는 명령줄 도구로 관리됩니다. 할당되었을 수 있는 모든 로컬 정책을 무시합니다. Active Directory IPsec 정책은 그룹 정책 편집기 MMC 스냅인 또는 **Windows 설정**, **보안 설정**, **IPsec 정책** 아래의 그룹 정책 관리 콘솔을 사용하여 GPO에 할당됩니다 - **동적 IPsec 정책**. 메모리에만 저장됩니다. 명령줄 도구로 구성합니다. 기존 정책에 동적으로 추가하는 데 사용됩니다. 동적 정책은 IPsec 서비스를 중지하면 폐기됩니다. 명확한 전달을 위해 이 지침은 Active Directory 도메인 IPsec 정책 사용에 중점을 두고 설명합니다. IPsec 정책을 정의할 때 모든 컴퓨터에 대한 IPsec 인프라 기초를 설정할 일반 정책을 설계하는 것이 가장 좋습니다. 그런 다음 추가 보안 구성을 필요로 하는 보다 엄격한 설정을 적용하는 추가 정책을 만들 수 있습니다. 특정 비즈니스 또는 기술 요구 사항을 충족시키는 데 필요한 컴퓨터의 최대 수에 영향을 주는 각 추가 정책을 설계해야 합니다. 정책의 전체 개수를 최소한으로 유지하면 정책을 문제 해결하고 관리하기가 쉬워집니다. IPsec 정책은 이름, 설명, 규칙 집합, 폴링 간격을 위한 구성 설정, 키 교환 설정 및 키 교환 방법으로 구성되며, 다음 절에서 자세히 설명합니다. ##### 이름 필터 동작 같은 정책에는 프로젝트의 구현과 운영 단계 동안 솔루션 관리와 문제 해결이 쉽도록 의미 있는 이름을 부여해야 합니다. ##### 설명 정책에 대한 자세한 설명은 관리자가 실제로 정책을 열고 규칙을 연구할 필요 없이 어떤 정책을 적용할지 식별하는 데 도움을 줍니다. ##### 규칙 IPsec 규칙은 단일 필터 목록, 관련 필터 동작, 컴퓨터 간에 트러스트를 설정하는 데 사용되는 인증 방법, 연결 유형 및 규칙이 터널 구성인지 여부로 구성됩니다. 각 규칙은 하나 이상의 인증 방법을 정의하여 호스트 간의 트러스트를 설정하는 데 사용합니다. 옵션은 Kerberos 버전 5 프로토콜, 특정 인증 기관의 인증서 및 미리 공유한 키가 있습니다. 연결 유형은 IPsec 정책을 적용할 연결을 정의합니다. 모든 연결, 로컬 영역 연결 또는 원격 액세스 기반 연결에 적용하도록 정책을 구성할 수 있습니다. 터널 유형은 IPsec 정책이 IPsec 터널을 정의할지 여부를 정의합니다. 터널 유형을 사용하지 않을 경우 IPsec은 전송 모드를 사용합니다. 이 가이드의 앞부분에서 식별된 보안 격리 그룹을 지원하기 위해 Woodgrove 은행은 네 가지 IPsec 정책을 구현했습니다. Kerberos 버전 5 인증 프로토콜을 사용하고 모든 연결에 적용하고 IPsec 터널을 적용하지 않도록 네 가지 정책을 모두 구현했습니다. 다음 표는 Woodgrove 은행 시나리오에 사용된 정책을 보여줍니다. **표 5.6: Woodgrove 은행 IPsec 정책**

정책 이름	설명
IPSEC – 격리 도메인 IPsec 정책(1.0.041001.1600)	이 정책은 격리 도메인을 정의합니다. 이 격리 그룹의 호스트는 비 IPsec 호스트와 통신을 시작할 때 선택 취소할 수 있습니다. IPsec 통신을 요구하도록 호스트를 구성합니다. IPsec을 인식하는 클라이언트 사이에 협상이 실패할 경우 통신이 실패합니다.
IPSEC – 경계 격리 그룹 IPsec 정책(1.0.041001.1600)	이 정책은 경계 격리 그룹을 정의합니다. IPsec 통신을 요청하지만 비 IPsec 기반 호스트와 통신이 발생해야 하는 경우 선택 취소를 허용하도록 호스트를 구성합니다.
IPSEC – Fallback 격리 없음 그룹 IPsec 정책(1.0.041001.1600)	이 정책은 대체 없음 격리 그룹을 정의합니다. IPsec 통신을 요구하도록 호스트를 구성합니다. 협상이 실패하거나 IPsec을 사용하지 않는 클라이언트와 통신을 시도한 경우 통신이 실패합니다.
IPSEC – 암호화 격리 그룹 IPsec 정책(1.0.041001.1600)	이 정책은 암호화 격리 그룹을 정의합니다. IPsec 통신과 암호화를 요구하도록 호스트를 구성합니다. 협상이 실패하거나 IPsec을 사용하지 않는 클라이언트와 통신을 시도한 경우 통신이 실패합니다.

각 정책 이름과 관련된 번호는 버전 번호이며 나중에 "정책 버전 관리" 절에서 설명합니다. 각 Woodgrove 은행 정책에는 하나의 특정 격리 그룹에 대해 특정 컴퓨터 집합을 제외하는 요구 사항이 없기 때문에 동일한 예외 목록이 포함되어 있습니다. 다음 표는 앞의 표에서 식별된 네 가지 정책에 동일한 규칙이 설정된 것을 보여줍니다. **표 5.7: Woodgrove 은행 IPsec 정책에 정의된 공통 규칙**

필터 목록	필터 작업	인증 방법	터널 끝점	연결 유형
DNS 예외 목록	IPSEC – 허용	없음	없음	모두
도메인 컨트롤러 예외 목록	IPSEC – 허용	없음	없음	모두
WINS 예외 목록	IPSEC – 허용	없음	없음	모두
DHCP, 협상 트래픽	IPSEC – 허용	없음	없음	모두
ICMP, 모든 트래픽	IPSEC – 허용	없음	없음	모두

이 표에 나열된 규칙 이외에 각 정책에서 기본 클라이언트 응답은 해제되었습니다. Woodgrove 은행이 정의한 네 가지 정책은 예외 필터 목록에서 처리하지 않는 나머지 트래픽을 처리하는 방법에서 약간 차이가 있습니다. 각 규칙에 대해 인증 방법은 Kerberos 버전 5 프로토콜로 설정되었고, 터널 끝점은 없음, 연결 유형은 모두로 설정되었습니다. 다음 표는 네 가지 격리 그룹을 구현하기 위한 Woodgrove 은행 규칙을 보여줍니다. **표 5.8: 격리 그룹 구현을 위한 Woodgrove 은행 기본 규칙**

정책 이름	필터 목록	필터 작업
IPSEC – 격리 도메인 IPsec 정책(1.0.041001.1600)	Woodgrove 은행 보안 서브넷	IPsec – 보안 요청 모드(인바운드 무시, 아웃바운드 허용)
IPSEC – 경계 격리 그룹 IPsec 정책(1.0.041001.1600)	Woodgrove 은행 보안 서브넷	IPsec – 요청 모드(인바운드 수락, 아웃바운드 허용)
IPSEC – Fallback 격리 없음 그룹 IPsec 정책(1.0.041001.1600)	Woodgrove 은행 보안 서브넷	IPsec – 전체 요청 모드(인바운드 무시, 아웃바운드 허용 안 함)
IPSEC – 암호화 격리 그룹 IPsec 정책(1.0.041001.1600)	Woodgrove 은행 보안 서브넷	IPsec – 암호화 요구 모드(인바운드 무시, 아웃바운드 허용 안 함)

Woodgrove 은행은 Kerberos 버전 5 프로토콜을 유일한 인증 프로토콜로 사용하기로 선택했습니다. Woodgrove는 로컬 관리자, 도메인에 있는 모든 인증된 사용자와 컴퓨터가 레지스트리에서 인증 키 값을 읽을 수 있기 때문에 미리 공유한 키는 사용하지 않았습니다. Woodgrove는 은행에 배포된 PKI(공용 키 구조)가 없기 때문에 인증서는 선택하지 않았습니다. Kerberos 버전 5 프로토콜을 사용함으로써 모든 도메인 참가 컴퓨터가 정책을 인증하고 얻을 수 있기 때문에 IPsec 인프라에 참가할 수 있습니다. 도메인에 참가하지 않은 컴퓨터는 인증 메커니즘과 정책 배포 시스템이 없기 때문에 IPsec 환경에 쉽게 참가할 수 없습니다. 이러한 컴퓨터가 신뢰할 수 있는 호스트 기준을 충족하는 경우 인증서 인증을 사용하는 IPsec 로컬 정책을 구성하여 다른 신뢰할 수 있는 호스트와 통신할 수 있습니다. Woodgrove 은행은 현재 비 도메인 컴퓨터를 신뢰할 수 없는 컴퓨터로 취급합니다. **참고:** IKE 인증용 Kerberos 버전 5 프로토콜을 사용해도 비 도메인 기반 컴퓨터가 IPsec 환경에 참가하는 것을 방지하지 못합니다. 예를 들어, UNIX 시스템이 Active Directory가 Kerberos 영역을 사용하도록 적절히 구성되고 IKE 구현이 Kerberos 인증을 지원하는 경우 격리 도메인에 참가하는 것이 가능할 수 있습니다. 그러나 이런 구성은 이 문서의 범위를 초가하며 Microsoft에 의해 테스트되지 않았습니다. ##### 폴링 간격 고려할 폴링 간격은 그룹 정책 폴링 간격과 IPsec 서비스 폴링 간격 등 두 가지가 있습니다. IPsec 서비스 정책 변경 폴링 간격의 기본 설정은 180분이며 Active Directory 기반 IPsec 정책에서 변경을 위한 연속 폴링 사이의 간격입니다. 이러한 폴링은 IPsec 정책의 변경만 검사하며, 도메인이나 OU(조직 구성 단위) 구성원의 변경 또는 GPO에서 IPsec 정책의 할당이나 제거는 검색하지 않습니다. 컴퓨터의 OU 구성원 변경 및 GPO의 할당은 기본적으로 90분마다 발생하는 그룹 정책 서비스 폴링을 통해 검색됩니다. Woodgrove 은행은 보안 응답이 필요한 경우 한 시간 내에 업데이트하거나 배포하여 위험을 완화시킬 수 있도록 두 폴링 간격을 60분으로 설정하기로 선택했습니다. 이 증가된 폴링 빈도는 IPsec 정책의 타임스탬프를 검사하기 위해 LDAP 쿼리의 형태로 추가 폴링 트래픽을 소개했습니다. 이것으로 Woodgrove 은행 시나리오에 상당한 오버헤드가 발생하지 않았지만 많은 수의 클라이언트에 배포하면 이 증가는 상당히 커질 수 있습니다. ##### 키 교환 설정 다음 키 교환 설정은 새 키가 파생되는 방법과 갱신 주기를 정의합니다. "마스터 키"라는 용어는 IKE 주 모드에서 생성된 Diffie-Hellman 공유 비밀 키 자료를 의미합니다. "세션 키"라는 용어는 IPsec 무결성과 암호화 알고리즘에서 사용하기 위한 IKE 빠른 모드에 의해 생성되는 키를 말합니다. 세션 키는 마스터 키에서 파생됩니다. - **PFS(Perfect forward secrecy).** IKE에는 마스터 키 PFS(주 모드 PFS 의미) 및 세션 키 PFS(빠른 모드 PFS 의미) 등 두 종류의 PFS가 있습니다. 주 모드 PFS는 지원되는 다른 키 교환 설정의 기능과 중복되기 때문에 사용하지 않는 것이 좋습니다. 주 모드 PFS는 빠른 모드를 사용하여 세션 키를 새로 고칠 때마다 IKE가 새 마스터 키를 다시 인증하고 협상할 것을 요구합니다. 이 요구 사항은 암호화 키를 새로 고쳐야 할 때마다 두 컴퓨터가 처음부터 새 IKE 주 모드와 빠른 모드 협상을 사용하여 시작하도록 합니다. 이 추가 보호를 위해서는 추가 오버헤드 비용을 부담하게 됩니다. 세션 키 PFS는 빠른 모드(주 모드 인증 없음) 동안 새 마스터 키를 생성한 다음 새 마스터 키에서 새 세션 키를 파생합니다. 이 기능은 통신에서 많은 양 또는 모든 데이터를 한 마스터 키 값만으로 보호하지 않고 공격자가 마스터 키를 검색할 수 있는 경우 적은 양의 암호화된 데이터가 노출되도록 합니다. 세션 키 PFS는 필터 동작을 위한 보안 방법에서 확인란으로 지원됩니다. IPsec으로 보호되는 트래픽이 Diffie-Hellman 마스터 키에서 정교한 암호화 공격 위험이 있는 경우에만 세션 키 PFS를 사용해야 합니다. - **새 키 인증 및 생성 간격: <*숫자*>분.** 이 값은 IKE 주 모드 SA 수명을 설정합니다. 기본값은 480분입니다. 재협상하기 하기 전에 마스터 키와 트러스트 관계를 얼마나 오래 사용할 수 있는지 제어합니다. 고유한 클라이언트에서 호스트로 처음 TCP/IP 연결하면 새 IKE 주 모드 SA가 만들어집니다. 소프트 SA와 달리 주 모드 SA는 5분 이상 사용하지 않아도 호스트에서 제거되지 않습니다. 주 모드 SA는 각각 5KB 정도의 메모리를 사용합니다. 이 값을 조정함으로써 관리자는 IKE에 필요한 CPU 로드와 메모리 사용을 최적화할 수 있습니다. 수명을 줄이면 서버에서 활성 주 모드 SA 수도 줄어듭니다. 따라서 메모리 사용이 줄고 적은 수의 SA를 유지 관리하므로 IKE 처리 시간이 절약됩니다. 그러나 자주 통신하는 클라이언트의 경우 주 모드 SA를 다시 협상하는 데 필요한 CPU 로드를 증가시킬 수 있습니다. - **새 키 인증 및 생성 간격: <*숫자*>세션.** 이 설정은 하나의 주 모드 SA의 수명 동안 허용되는 최대 IKE 빠른 모드 수를 제어하므로 동일한 마스터 키에서 생성할 수 있는 세션 키 수가 제한됩니다. 이 제한에 도달하면 새 마스터 키를 생성하도록 새 IKE 주 모드 SA가 협상됩니다. 기본 설정은 0으로, 제한이 없다는 것을 의미합니다. 따라서 빠른 모드 PFS가 사용되지 않는 경우 마스터 키는 IKE 주 모드 SA 수명이 만료될 때만 새로 고쳐집니다. 마스터 키 PFS 설정과 같은 동작을 얻으려면 이 옵션을 1로 설정합니다. Woodgrove 은행은 마스터 키 PFS를 요구하는 특정 보안 요구 사항이 없기 때문에 마스터 키 PFS를 사용하지 않기로 선택했습니다. 마찬가지로 필터 동작에서 IKE 빠른 모드 PFS는 사용되지 않았습니다. IKE 주 모드 SA 수명을 480분에서 180분으로 변경하여 경계 격리 그룹을 제외한 사용이 많은 서버에서 주 모드 SA를 보다 신속하게 삭제할 수 있었습니다. 경계 격리 그룹의 경우 Woodgrove 은행 관리자는 IKE 주 모드 SA 수명을 20분으로 줄여 암호화 격리 그룹과 협상한 상주 주 모드 SA에 존재하는 공격 허점이 줄어들었습니다. 경계 격리 그룹의 호스트가 암호화 격리 그룹에 있는 호스트와 새로운 IKE 협상을 시작할 수 없지만 그 반대의 경우는 발생할 수 있습니다. 주 모드 SA를 설정한 후에는 주 모드 SA가 삭제될 때까지 경계 호스트는 암호화 격리 그룹에 있는 해당 시스템으로 인바운드되는 트래픽을 보호하기 위해 이 SA를 사용하여 빠른 모드 SA를 협상할 수 있습니다. 경계 서버의 주 모드 SA를 강제로 더 자주 삭제함으로써 이 위험은 줄어듭니다. 마스터 키를 사용하여 세션 키를 생성할 수 있는 세션 수는 기본 설정인 0으로 두었습니다. ##### 키 교환 방법 키 교환 방법은 주 모드 IKE 협상 동안 사용되는 보안 방법을 제어합니다. 구성 옵션은 무결성(SHA-1 및 MD5), 기밀성 또는 암호화(3DES 및 DES) 및 키 교환 프로세스 동안 사용되는 기본 소수 길이입니다. **참고:** 3DES를 사용하려면 Windows 2000을 실행하는 컴퓨터에는 암호화 팩 또는 SP2(이상)가 설치되어 있어야 합니다. IKE 협상의 무결성과 암호화 및 IPsec 데이터 보호를 위해 사용되는 키의 암호화 강도는 소수가 기초를 둔 Diffie-Hellman 그룹의 강도에 따라 다릅니다. Diffie-Hellman 그룹에는 세 가지 옵션이 있습니다. - **높음(3)** – 2048비트 키 입력 강도. 이 옵션은 Diffie-Hellman 그룹 14의 IETF RFC 3526 사양에 해당합니다. 이 키 강도는 3DES가 최대 암호화 강도를 갖는 데 필요합니다. 자세한 내용은 IETF RFC 3526을 참조하십시오. - **보통(2)** – 1024비트 키 입력 강도. - **낮음(1)** – 768비트 키 입력 강도. 높음 구성은 Windows XP SP2 및 Windows Server 2003 기반 시스템에서만 사용할 수 있습니다. 보통 구성은 Windows 2000 및 Windows XP SP1과의 상호 운용성을 제공합니다. 낮음은 이전 버전과의 호환성을 위해 제공되며 상대적으로 약하기 때문에 사용해서는 안 됩니다. 다음 표는 Woodgrove 은행이 구현하기로 선택한 기본 설정 순서로 키 교환 보안 방법을 나열합니다. **표 5.9: 기본 키 교환 보안 방법**

암호화	무결성	Diffie-Hellman 그룹
3DES	SHA-1	높음(3) 2048비트
3DES	SHA-1	보통(2) 1024비트
3DES	MD5	보통(2) 1024비트

**참고:** IPsec 정책에서 2048비트 그룹을 사용하려면 IPsec 정책 관리 MMC 스냅인 또는 Netsh IPsec 명령줄 유틸리티 같은 Windows Server 2003 관리 도구를 사용하여 IPsec 정책을 구성해야 합니다. 이 정책은 도메인에서 2048비트 옵션을 무시하는 Windows 2000 플랫폼에 할당할 수 있습니다. ##### 정책 버전 관리 IPsec 정책 설계는 초기 계획, 실험 테스트, 시험 배포 및 운영하는 동안 여러 번 변경될 수 있습니다. 스크립트, 스프레드시트 또는 기타 문서를 사용하여 IPsec 정책을 만드는 경우 Microsoft Visual SourceSafe®와 유사한 버전 제어 시스템을 사용하여 이러한 파일을 관리해야 합니다. 정책의 특성을 보고는 Active Directory 내에서 IPsec 정책의 버전을 식별하기 어렵습니다. 문제 해결 단계에서는 IPsec 정책의 어느 버전이 컴퓨터에 활성화되어 있는지 확인하는 기능이 필요합니다. 따라서 정책 이름과 정책 규칙 내에서 일부 형식의 버전 관리 정보를 저장하는 것이 좋습니다. 간단한 버전 관리 방법은 다음 공식을 바탕으로 버전 ID를 만드는 것입니다. ```

그룹 이름	설명
No IPsec	IPsec 환경에 참가하지 않는 컴퓨터 계정의 유니버설 그룹. 일반적으로 인프라 컴퓨터 계정으로 구성되어 있습니다.
CG_IsolationDomain_computers	격리 덀„메인의 구성원인 컴퓨터 계정의 유니버설 그룹.
CG_BoundaryIG_computers	경계 격리 그룹의 구성원인 컴퓨터 계정의 유니버설 그룹이므로 신뢰할 수 없는 시스템과 통신이 허용됩니다.
CG_NoFallbackIG_computers	인증되지 않은 아웃바운드 통신이 허용되지 않는 대체 없음 격리 그룹의 일부인 컴퓨터 계정의 유니버설 그룹.
CG_EncryptionIG_computers	암호화 격리 그룹의 구성원인 컴퓨터 계정의 유니버설 그룹이므로 통신을 위해서는 암호화가 요구됩니다.

나열된 그룹 외에 초기 롤아웃 동안 정책 응용을 제한하기 위해 추가 그룹을 만들고 사용할 수 있습니다. IPsec을 배포할 때는 GPO와 IPsec 정책을 만들고 도메인에 있는 모든 컴퓨터에 동시에 할당하지 않는 것이 좋습니다. 어떤 컴퓨터가 GPO를 읽고 해당 IPsec 정책을 받을 수 있는지 세밀한 제어를 위해 도메인 보안 그룹을 사용할 수 있습니다. IPsec 정책을 제공하는 GPO를 전체 도메인에 모두 할당할 수 있습니다. 롤아웃 프로세스는 IPsec과 협상할 것으로 예상되는 모든 노드에서 IPsec 정책을 적절히 설계하고 할당하고 검색할지 여부를 신중하게 고려해야 합니다. 경계 그룹 정책의 설계는 일반적으로 IPsec 정책을 아직 검색하지 않은 컴퓨터에서 인바운드와 아웃바운드의 비 IPsec 통신을 허용하는 데 사용됩니다. ##### Active Directory를 통해 IPsec 정책 배포 세 가지 방법을 조합하여 어떤 GPO를 Active Directory의 컴퓨터에 적용할지 제어할 수 있습니다. - 연결된 GPO가 있는 OU 사용 - GPO에 적용되는 ACL에서 참조되는 보안 그룹에 컴퓨터 계정을 배치 - GPO에서 WMI(Windows Management Instrumentation) 필터 사용 연결된 GPO가 있는 OU를 통해 GPO 응용을 제어하는 것은 Active Directory에서 가장 일반적인 정책 응용 형식입니다. 이 방법은 Active Directory 내에 OU를 만들고 GPO를 사이트, 도메인 또는 OU에 연결합니다. 컴퓨터는 Active Directory의 해당 위치를 기준으로 정책을 받습니다. 컴퓨터가 한 OU에서 다른 OU로 이동하는 경우 폴링 동안 그룹 정책이 변경을 검색하면 두 번째 OU에 연결된 정책이 적용됩니다. 두 번째 방법은 GPO 자체의 보안 설정을 사용합니다. Active Directory에 있는 GPO의 ACL에 그룹이 적용됩니다. 이 그룹에는 그룹 내의 컴퓨터에 적용해야 하는 정책에 대한 읽기 및 그룹 정책 적용 권한이 할당됩니다. 또한 특히 그룹은 그룹 내의 컴퓨터에 적용해서는 안 되는 정책에 대한 권한은 거부합니다. 그러면 정책은 도메인 수준에서 연결됩니다. 세 번째 방법은 정책의 WMI 필터를 사용하여 정책 응용의 범위를 동적으로 제어합니다. WMI SQL 필터가 만들어지고 정책에 연결됩니다. 쿼리한 조건이 참인 경우 정책이 적용되고 아닌 경우 거부됩니다. Windows 2000을 실행하는 컴퓨터는 WMI 필터링을 무시하며 정책을 적용합니다. WMI 쿼리는 GPO 처리 성능을 느리게 할 수 있으며 필요할 때만 사용해야 합니다. Woodgrove 은행은 OU에 직접 연결하는 대신 정책 응용을 제어하기 위해 보안 그룹을 사용하도록 선택했습니다. Woodgrove는 정책을 여러 위치에 강제로 적용하거나 한 OU에서 다른 OU로 컴퓨터를 강제로 이동하여 올바른 정책을 받을 필요 없이 이 접근 방식을 선택하여 환경에서 IPsec 정책을 쉽게 소개했습니다. GPO의 ACL이 매우 크지 않은 경우 첫 번째 방법에 비해 이 방법과 관련된 추가 오버헤드는 없는데, 그 이유는 두 경우 모두 ACL을 평가해야 하기 때문입니다. Woodgrove는 환경에 Windows 2000 시스템이 없기 때문에 WMI 필터링을 선택하지 않았습니다. 다음 표는 최종 그룹 정책 ACL 구성을 보여줍니다. IPsec 정책 개체 자체의 ACL은 사용되지 않으며 권장되지 않습니다. **표 5.11: Woodgrove 은행 정책 GPO 권한**

GPO 이름	보안 그룹 이름	할당된 권한
IPSEC – 격리 도메인 정책	No IPsec	적용 거부 그룹 정책
IPSEC – 격리 도메인 정책	CG_IsolationDomain_computers	읽기 및 적용 허용 그룹 정책
IPSEC – 경계 그룹 정책	No IPsec	적용 거부 그룹 정책
IPSEC – 경계 그룹 정책	CG_BoundaryIG_computers	읽기 및 적용 허용 그룹 정책
IPSEC – Fallback 격리 없음 그룹 정책	No IPsec	적용 거부 그룹 정책
IPSEC – Fallback 격리 없음 그룹 정책	CG_NoFallbackIG_computers	읽기 및 적용 허용 그룹 정책
IPSEC – 암호화 격리 그룹 정책	No IPsec	적용 거부 그룹 정책
IPSEC – 암호화 격리 그룹 정책	CG_EncryptionIG_computers	읽기 및 적용 허용 그룹 정책

###### 격리 도메인 Woodgrove 은행은 조직의 각 도메인에서 격리 도메인 정책을 도메인 수준에 연결하기로 선택했습니다. 정책은 ACL을 사용하여 CG\_IsolationDomain\_computers 그룹의 구성원이 아닌 사람이 정책을 적용하지 못하도록 합니다. 인증된 사용자 그룹의 그룹 정책 적용 권한이 정책 ACL에서 제거되었습니다. 격리 도메인 정책은 조직에 있는 모든 컴퓨터가 기본 IPsec 보안 정책으로 사용하는 정책입니다. 다라서 도메인 컴퓨터 그룹은 정책에 읽기 권한을 부여합니다. 인증된 사용자 그룹의 그룹 정책 적용 권한이 정책 ACL에서 제거되었습니다. 초기 롤아웃 동안 도메인 컴퓨터 그룹이 ACL에서 제거되었고 다른 임시 보안 그룹은 이 정책을 받을 수 있는 사람을 제어하는 데 사용되었습니다. 이 접근 방식을 통해 이 정책의 단계적 배포할 수 있었습니다. ###### 경계 격리 그룹 Woodgrove 은행은 조직의 각 도메인에서 경계 격리 도메인 정책을 도메인 수준에 연결하기로 선택했습니다. 정책은 ACL을 사용하여 CG\_BoundaryIG\_computers 그룹의 구성원이 아닌 사람이 정책을 적용하지 못하도록 합니다. 인증된 사용자 그룹의 그룹 정책 적용 권한이 정책 ACL에서 제거되었습니다. 시스템이 신뢰할 수 없는 시스템의 통신을 수락하는 비즈니스 요구가 있는 경우 시스템의 컴퓨터 계정을 CG\_BoundaryIG\_computers 보안 그룹에 추가할 수 있습니다. ###### 대체 없음 격리 그룹 Woodgrove 은행은 조직의 각 도메인에서 대체 없음 격리 도메인 정책을 도메인 수준에 연결하기로 선택했습니다. 정책은 ACL을 사용하여 CG\_NoFallbackIG\_computers 그룹의 구성원이 아닌 사람이 정책을 적용하지 못하도록 합니다. 인증된 사용자 그룹의 그룹 정책 적용 권한이 정책 ACL에서 제거되었습니다. 시스템이 신뢰할 수 없는 시스템과 통신을 시작하는 기능을 거부하는 비즈니스 요구가 있는 경우 시스템의 컴퓨터 계정을 CG\_NoFallbackIG\_computers 그룹에 추가할 수 있습니다. ###### 암호화 격리 그룹 Woodgrove 은행은 조직의 각 도메인에서 암호화 격리 도메인 정책을 도메인 수준에 연결하기로 선택했습니다. 정책은 ACL을 사용하여 CG\_EncryptionIG\_computers 그룹의 구성원이 아닌 사람이 정책을 적용하지 못하도록 합니다. 인증된 사용자 그룹의 그룹 정책 적용 권한이 정책 ACL에서 제거되었습니다. 시스템이 암호화된 트래픽만 통신하는 비즈니스 요구가 있는 경우 시스템의 컴퓨터 계정을 CG\_EncryptionIG\_computers 그룹에 추가합니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 격리 그룹에 대한 인바운드 액세스 승인 Woodgrove 은행 요구 사항은 신뢰할 수 있는 호스트의 하위 집합만 암호화 격리 그룹에 있는 서버에 인바운드 네트워크 액세스를 허용하는 것이었습니다. 4장의 표 4.8은 다음 NAG(네트워크 액세스 그룹)를 정의하여 이러한 요구 사항을 구현했습니다. - ANAG\_EncryptedResourceAccess\_Users - ANAG\_EncryptedResourceAccess\_Computers - DNAG\_EncryptedResourceAccess\_Computers 클라이언트가 암호화 서버에 대해 IKE를 시작하면 IKE는 클라이언트 컴퓨터가 ANAG 및/또는 DNAG의 구성원인지 여부를 나타내는 도메인 그룹 식별자가 포함된 Kerberos 서비스 티켓을 얻어야 합니다. 암호화 격리 그룹의 모든 컴퓨터가 같은 도메인의 구성원인 경우 이러한 NAG를 도메인 로컬 보안 그룹으로 만들 수 있습니다. 암호화 격리 그룹의 컴퓨터가 별도의 신뢰할 수 있는 도메인의 구성원인 경우 도메인 글로벌 그룹의 한 집합을 NAG에 사용하거나 각 도메인에 도메인 로컬 그룹을 만들 수 있습니다. Woodgrove 은행 시나리오는 한 도메인만 포함하므로 이러한 NAG에 대해 도메인 로컬 그룹을 사용합니다. 인바운드 인증을 구현하는 **네트워크에서 이 컴퓨터 액세스** 권한을 정의할 목적으로 다음 추가 GPO를 만들었습니다. - EncryptionIG 인바운드 네트워크 인증 GPO CG\_EncryptionIG\_Computers 그룹에는 이 GPO에 대한 읽기 및 적용 권한이 부여됩니다. 인증된 사용자 그룹이 읽기 권한에서 제거되어, 이 GPO에서 암호화 격리 그룹의 구성원인 컴퓨터에만 적용됩니다. 4장의 표 4.8에서 본 것처럼 승인된 클라이언트 도메인 컴퓨터 계정 IPS-ST-XP-05가 ANAG\_EncryptedResourceAccess\_Computers 네트워크 액세스 그룹에 추가됩니다. 암호화 서버 계정 자체인 IPS-SQL-DFS-01 및 IPS-SQL-DFS-02도 추가됩니다. 그러나 CG\_EncryptionIG\_computers 그룹을 사용하여 더 큰 목록을 관리하면 같은 결과를 더 쉽게 얻을 수 있습니다. ANAG 구성원을 통하거나, CG\_EncryptionIG\_computers 그룹을 직접 포함하거나, 권한에 컴퓨터 계정의 명시적 나열을 통하는 등 어떤 방법으로든 계정이 **네트워크에서 이 컴퓨터 액세스** 권한을 갖도록 승인해야 합니다. 그렇지 않으면 계정은 응용 프로그램이 요구하는 서로 간에 IPsec으로 보호된 연결을 만들 수 없습니다. 큰 도메인 환경을 시뮬레이션하기 위해 ANAG 그룹은 Woodgrove 은행 시나리오에 대한 인바운드 액세스를 승인하는 유일한 그룹입니다. 승인된 사용자 그룹은 모든 도메인 컴퓨터를 포함하고 있기 때문에 **네트워크에서 이 컴퓨터 액세스** 권한에서 제거해야 합니다. 승인된 사용자를 이제 명시적으로 승인해야 합니다. 이는 도메인 사용자에 대한 기본 제공 그룹을 사용하여 수행할 수 있습니다. 그러나 Woodgrove 은행은 사용자와 컴퓨터에 대해 인바운드 네트워크 액세스 제한을 정의하는 기능을 이용하고자 했습니다. 따라서 ANAG\_EncryptedResourceAccess\_Users라고 하는 도메인 로컬 보안 그룹을 만들고 승인된 응용 프로그램 사용자 계정(예: User7)은 물론 로컬 관리자 그룹과 도메인 관리자 그룹으로 채웠습니다. 이러한 사용자 수준 네트워크 액세스 제한은 IPsec ESP 3DES 연결이 성공적으로 설정된 후에 상위 계층 프로토콜(예: RPC, SMB 및 SQL) 인증 요청 동안 발생합니다. 암호화 서버에 대한 네트워크 로그온 권한을 위해 다음 도메인 보안 그룹을 만들었습니다. 도메인 보안 그룹은 컴퓨터 구성, Windows 설정, 보안 설정, 로컬 정책, 사용자 권한 할당, **네트워크에서 이 컴퓨터 액세스** 권한 아래의 GPO에 있습니다. - ANAG\_EncryptedResourceAccess\_Computers - ANAG\_EncryptedResourceAccess\_Users 같은 GPO, **네트워크에서 이 컴퓨터 액세스 거부**에 대해 다음 그룹이 구성되었습니다. - DNAG\_EncryptedResourceAccess\_Computers User7이 암호화 서버에 직접 로그온할 수 없다고 가정하면 결과적으로 User7이 IPS-ST-XP-05 클라이언트 컴퓨터를 사용하여 IPS-SQL-DFS-01 또는 IPS-SQL-DFS-02 서버에 액세스해야 합니다. IPS-ST-XP-05 컴퓨터는 유효한 도메인 컴퓨터 계정 및 암호화 서버의 IP 주소에 대해 IKE 협상을 시작하는 활성 IPsec 정책이 있어야 합니다. **네트워크에서 이 컴퓨터 액세스** 권한에서 고의로 생략하기 때문에 도메인에 있는 나머지 사용자 및 컴퓨터의 액세스가 효과적으로 거부됩니다. ANAG의 경계 컴퓨터 계정을 포함할 수 있는 향후 그룹 구성원 변경에 대한 심층 방어 방법으로 DNAG를 사용하여 경계 컴퓨터의 액세스만 효과적으로 거부됩니다. 명시적인 거부 매개 변수는 모든 형식의 허용을 무시합니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 추가 IPsec 고려 사항 IPsec 정책 정의 외에 성공적인 IPsec 구현을 위한 몇 가지 추가 고려 사항이 있습니다. IPsec을 사용할 때는 Tools and Templates 폴더의 **Business\_Requirements.xls** 스프레드시트가 세부적인 제약 조건을 제공합니다. #### 기본 예외 Windows 2000 및 Windows XP에서 기본적으로 다음과 같은 트래픽 유형이 필터 일치에서 제외됩니다. - 브로드캐스트 - 멀티캐스트 - Kerberos 인증 프로토콜 - IKE - RSVP(Resource Reservation Protocol) Windows Server 2003 운영 체제 제품군에서 브로드캐스트, 멀티캐스트, RSVP 및 Kerberos 인증 프로토콜은 기본적으로 필터 일치에서 제외되지 않습니다. IKE 트래픽만 제외됩니다. 브로드캐스트 및 멀티캐스트 패킷은 보안을 협상하는 필터 동작을 가진 필터와 일치하는 경우 손실됩니다. 기본적으로 Windows Server 2003 제품군은 브로드캐스트 및 멀티캐스트 트래픽을 필터링하기 위한 제한된 지원을 제공합니다. 모든 IP 주소의 원본 주소를 가진 필터는 멀티캐스트와 브로드캐스트 데이터베이스와 일치합니다. 모든 IP 주소의 원본 주소 및 모든 IP 주소의 대상 주소는 인바운드와 아웃바운드 멀티캐스트 주소와 일치합니다. 이러한 필터를 사용하여 모든 트래픽을 차단할 수 있습니다. 그러나 특정 멀티캐스트 또는 브로드캐스트 트래픽을 차단하거나 허용하는 데 사용되는 한 방향 필터는 지원되지 않습니다. IPsec의 Windows Server 2003 제품군 구현의 기본 예외 동작을 변경한 결과 Windows 2000 또는 Windows XP용으로 설계된 IPsec 정책의 동작을 확인하고 특정 트래픽 유형을 허용하도록 명시적 허용 필터를 구성할지 여부를 결정해야 합니다. IPsec 정책용 기본 Windows 2000 및 Windows XP 동작을 복원하려면 Netsh 명령을 사용하거나 레지스트리를 수정해야 합니다. **Netsh를 사용하여 IPsec 드라이버를 기본 Windows 2000 및 Windows XP 필터링 동작으로 복원하려면** 1. **Netsh** 프롬프트에서 다음 명령을 입력한 다음 **Enter** 키를 누릅니다. ``` netsh ipsec dynamic set config ipsecexempt 0 ``` 2. 컴퓨터를 다시 시작합니다. **레지스트리를 수정하여 IPsec 필터링으로부터 모든 브로드캐스트, 멀티캐스트 및 IKE 트래픽을 제외하려면** 1. **HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\** **Services\\IPSEC\\NoDefaultExempt DWORD** 레지스트리 설정 값을 **1**로 설정합니다. **NoDefaultExempt** 키는 기본적으로 존재하지 않으며 새로 만들어야 합니다. 2. 컴퓨터를 다시 시작합니다. #### NAT-통과 네트워크 주소 변환기가 작동하는 방식 때문에 IPsec NAT-T를 사용하는 네트워크 주소 변환기 뒤에서 Windows 2000 Server 또는 Windows Server 2003을 실행하는 서버와 통신할 때 클라이언트에 예기치 않은 결과가 발생할 수 있습니다. 기본적으로 Windows XP SP2는 이러한 서버에 대해 IPsec NAT-T 보안 연결을 더 이상 지원하지 않습니다. 다음과 같은 일련의 이벤트가 발생하는 상황에서 알려진 보안 위험을 피하기 위해 이렇게 변경되었습니다. 1. 네트워크 주소 변환기가 IKE 및 IPsec NAT-T 트래픽을 NAT 구성 네트워크(서버 1)에 매핑하도록 구성되었습니다. 2. NAT-구성 네트워크(클라이언트 1) 외부의 클라이언트는 IPsec NAT-T를 사용하여 서버 1과 양방향 보안 연결을 설정합니다. 3. NAT-구성 네트워크(클라이언트 2)의 클라이언트는 IPsec NAT-T를 사용하여 클라이언트 1과 양방향 보안 연결을 설정합니다. 4. IKE 및 IPsec NAT-T 트래픽을 서버 1로 매핑하는 정적 네트워크 주소 변환기 매핑으로 인해 클라이언트 1이 클라이언트 2와 보안 연결을 다시 설정하도록 하는 조건이 발생합니다. 이 조건은 클라이언트 1이 보내고 클라이언트 2를 향하도록 되어 있는 IPsec 보안 연결 협상 트래픽이 서버 1로 잘못 경로 지정될 수 있습니다. 이것은 가능성 없는 상황이지만 Windows XP SP2 기반 컴퓨터의 기본 동작은 네트워크 주소 변환기 뒤에 있는 서버에 대한 모든 IPsec NAT-T 기반 보안 연결이 절대 발생하지 않도록 방지합니다. NAT를 통한 IPsec 통신 요구 사항이 있을 경우 인터넷에서 직접 연결할 수 있는 모든 서버에 대해 공용 IP 주소를 사용하는 것이 좋습니다. 이 구성이 가능하지 않을 경우에는 Windows XP SP2의 기본 동작을 변경하여 네트워크 주소 변환기 뒤에 있는 서버에 대해 IPsec NAT-T 보안 연결을 설정할 수 있습니다. **AssumeUDPEncapsulationContextOnSendRule 레지스트리 값을 만들고 구성하려면** 1. **시작**을 클릭하고 **실행**을 클릭한 다음 **regedit**를 입력하고 **확인**을 클릭합니다. 2. 다음 레지스트리 하위 키를 찾아 클릭합니다. ``` HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\ Services\\IPSec ``` 3. **편집** 메뉴에서 **새로 만들기**를 가리킨 다음 **DWORD 값**을 클릭합니다. 4. **새 값 \#1** 상자에 다음을 입력한 다음 Enter 키를 누릅니다. **AssumeUDPEncapsulationContextOnSendRule** **참고:** 이 값 이름은 대/소문자를 구분합니다. 5. **AssumeUDPEncapsulationContextOnSendRule**을 마우스 오른쪽 단추로 클릭한 다음 **수정**을 클릭합니다. 6. **값 데이터** 상자에 다음 값 중 하나를 입력합니다. - **0**(기본값). 값 0(영)은 네트워크 주소 변환기 뒤에 있는 서버와 보안 연결을 설정할 수 없도록 Windows를 구성합니다. - **1**. 값 1은 네트워크 주소 변환기 뒤에 있는 서버와 보안 연결을 설정할 수 있도록 Windows를 구성합니다. - **2**. 값 2는 서버 및 Windows XP SP2 기반 클라이언트 컴퓨터 모두 네트워크 주소 변환기 뒤에 있을 때 보안 연결을 설정할 수 있도록 Windows를 구성합니다. **참고:** 값 2로 표현되는 구성은 Windows XP의 원본 릴리스와 Windows XP 서비스 팩 1(SP1)에 있습니다. 7. **확인**을 클릭한 다음 레지스트리 편집기를 닫습니다. 8. 컴퓨터를 다시 시작합니다. 값 1 또는 2로 **AssumeUDPEncapsulationContextOnSendRule**을 구성한 후에 Windows XP SP2는 네트워크 주소 변환기 뒤에 있는 서버에 연결할 수 있습니다. NAT 장치 뒤에 있을 때 IPsec과 올바르게 작동하려면 Windows Server 2003 기반 서버도 업데이트해야 합니다. [Windows Server 2003 서비스 팩 1](https://go.microsoft.com/fwlink/?linkid=41652)을 구하는 방법에 대한 자세한 내용은 다음 URL을 참조하십시오. https://go.microsoft.com/fwlink/?LinkId=41652 **참고:** 자세한 내용은 기술 자료 문서 885348, "[IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators](https://support.microsoft.com/default.aspx?scid=kb;en-us;885348)"(https://support.microsoft.com/default.aspx?scid=kb;en-us;885348)를 참조하십시오. 이 문서에서는 이 시나리오를 사용하는 보안 위협에 대해 설명합니다. 각 고객은 관련 보안 위협에 대해 이 시나리오에서 IPsec을 사용하는 이점을 평가해야 합니다. Microsoft는 관련 보안 위험으로 인해 시나리오를 권장하지 않지만 이 솔루션에서 설명하는 구성을 사용한 시나리오는 지원할 것입니다. 인바운드 NAT 연결이 성공적으로 작동하려면 PMTU 검색이 설정되고 잘 작동해야 합니다. *Windows XP 강화 가이드* 및 *Windows Server 2003 강화 가이드* 같은 일부 소스는 PMTU 검색을 해제할 것을 권장하며 경우에 따라 PMTU 검색 기능을 해제하는 정책 템플릿을 제공합니다. **PMTU 검색을 설정하려면** 1. **시작**을 클릭하고 **실행**을 클릭한 다음 **regedit**를 입력하고 **확인**을 클릭합니다. 2. 다음 레지스트리 하위 키를 찾아 클릭합니다. ``` HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\ Services\\tcpip\\parameters ``` 3. **편집** 메뉴에서 **새로 만들기**를 가리킨 다음 **DWORD 값**을 클릭합니다. 4. **새 값 \#1** 상자에 **EnablePMTUDiscovery**를 입력한 다음 Enter 키를 누릅니다. 5. **EnablePMTUDiscovery**를 마우스 오른쪽 단추로 클릭한 다음 **수정**을 클릭합니다. 6. **값 데이터** 상자에 1을 입력합니다. 7. **확인**을 클릭한 다음 레지스트리 편집기를 닫습니다. 8. 컴퓨터를 다시 시작합니다. 또한 Windows 2000을 실행하고 NAT-T 시나리오에 참가하는 호스트는 제대로 작동하려면 KB 문서 818043, "[L2TP/IPSec NAT-T update for Windows XP and Windows 2000](https://support.microsoft.com/kb/818043)"과 관련된 핫픽스를 적용해야 합니다. 자세한 내용은 다음 KB 문서를 참조하십시오. - Microsoft 지원 사이트(https://support.microsoft.com/kb/885407)에 있는 885407, "[The default behavior of IPSec NAT traversal(NAT-T) is changed in Windows XP Service Pack 2](https://support.microsoft.com/kb/885407)". - Microsoft 지원 사이트(https://support.microsoft.com/kb/818043)에 있는 818043, "[L2TP/IPSec NAT-T update for Windows XP and Windows 2000](https://support.microsoft.com/kb/818043)". #### IPsec 및 Windows 방화벽 Windows XP SP2를 실행하는 컴퓨터의 Windows 방화벽은 들어오는 원하지 않는 트래픽을 차단하여 공격으로부터 추가 보호를 제공합니다. Windows XP SP2의 IPsec은 Windows 방화벽을 인식합니다. 활성 IPsec 정책이 있으면 Windows XP SP2의 IPsec 구성 요소는 Windows 방화벽에게 UDP 포트 500 및 4500을 열어 IKE 트래픽을 허용하도록 지시합니다. IPsec 지원의 추가 기능은 모든 IPsec으로 보호되는 트래픽이 Windows 방화벽 처리를 우회하도록 그룹 정책을 통해 지정할 수 있는 기능입니다. 자세한 내용은 백서 "[Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2](https://download.microsoft.com/download/6/8/a/68a81446-cd73-4a61-8665-8a67781ac4e8/wf_xpsp2.doc)"(https://download.microsoft.com/download/6/8/a/68a81446-cd73-4a61-8665-8a67781ac4e8/wf\_xpsp2.doc)의 부록 A를 참조하십시오. #### IPsec 및 ICF(인터넷 연결 방화벽) SP2를 실행하지 않는 Windows XP 기반 컴퓨터의 경우 ICF(인터넷 연결 방화벽)는 트래픽 필터링을 위한 보안 요구 사항을 더 잘 충족시킬 수 있습니다. ICF는 필터링을 제공하며 Windows XP SP1에서 인바운드 멀티캐스트 및 브로드캐스트 트래픽을 차단할 수 있습니다. 그러나 ICF는 전송 또는 터널 모드에서 IPsec AH 또는 ESP로 보호되는 트래픽을 인식하지 못합니다. IPsec은 ICF 아래의 네트워크 계층에서 작동하고 IKE는 ICF 위에서 작동하기 때문에 IKE에 대한 정적 허용(UDP 포트 500)을 인바운드 트래픽에 대해 설정해야 합니다. IPsec이 트래픽을 차단하는 경우 ICF 손실 패킷 로그는 IPsec이 폐기한 패킷을 포함하지 않습니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 요약 이 장에서는 4장에서 만든 격리 그룹 설계를 토대로 IPsec 정책을 만들고 배포하는 정보를 제공했습니다. 이 정보는 다음 7가지 기본 작업으로 나뉘었습니다. - 필터 목록 확인 및 만들기 - 필터 동작 확인 및 만들기 - 규칙 확인 및 만들기 - IPsec 정책 확인 및 만들기 - IPsec 정책을 위한 배포 메커니즘 정의 - IPsec 정책을 위한 롤아웃 배포 방법 정의 - 그룹 정책 네트워크 로그온 권한 구성을 사용하여 인바운드 액세스 제어를 위한 인증 정의 이러한 작업은 서버와 도메인 격리 솔루션의 설계와 계획 단계를 마무리합니다. 프로젝트의 다음 단계는 테스트 또는 시험 환경을 배포하여 설계를 확인하는 것입니다. Microsoft는 테스트 실험에서 이 확인을 수행했고 Woodgrove 은행 시나리오를 시험으로 사용했습니다. 이 환경을 다시 만들거나 배포 단계를 연구하려면 이 가이드의 부록 C에 Microsoft가 시나리오의 설계 유효성을 검증하기 위해 테스트 실험에 사용한 배포 프로세스에 대한 단계별 지침이 포함되어 있습니다. #### 추가 정보 이 절에서는 이 장에서 설명한 기술에 대한 추가 정보에 대한 링크를 제공합니다. ##### IPsec에 대한 일반 배경 정보 - Microsoft의 [IPsec 홈 페이지](https://www.microsoft.com/ipsec): (영문) www.microsoft.com/ipsec - Microsoft 웹 사이트의 [IPsec for Windows 2000](https://www.microsoft.com/windows2000/technologies/communications/ipsec/default.asp) (영문)페이지(www.microsoft.com/windows2000/technologies/communications/ipsec/default.asp)는 Windows 2000 관련 IPsec에 대한 광범위한 콘텐츠를 제공합니다. - Microsoft 웹 사이트의 Windows Server 2003 섹션에 있는 [IPsec](https://www.microsoft.com/windowsserver2003/technologies/networking/ipsec/default.mspx) (영문) 페이지(www.microsoft.com/windowsserver2003/technologies/networking/ipsec/default.mspx. - *Windows Server 2003 Deployment* *Kit*:의 [Deploying IPsec](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/0bd06cf7-2ed6-46f1-bb55-2bf870273e15.mspx) (영문) 장: www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/DNSBJ\_IPS\_OVERVIEW.asp. ##### 추가 정보 - Microsoft 웹 사이트의 [Windows Server 2003 Group Policy](https://www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx) (영문)페이지(www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx)는 Active Directory에서 그룹 정책을 사용하여 Windows 시스템을 관리하는 방법에 대한 광범위한 정보를 제공합니다. - 2004년 10월 *Cable Guy* 문서, "[Problems with Using Network Address Translators](https://www.microsoft.com/technet/community/columns/cableguy/cg1004.mspx)" (영문)는 NAT 및 IPsec 사용과 관련한 문제에 대한 추가 정보를 제공합니다. 이 문서는 Microsoft 웹 사이트에서 구할 수 있습니다: www.microsoft.com/technet/community/columns/cableguy/cg1004.mspx. [](#mainsection)[페이지 위쪽](#mainsection) **전체 솔루션 다운로드** [IPsec 및 그룹 정책을 통해 서버 및 도메인 격리](https://go.microsoft.com/fwlink/?linkid=33947) [](#mainsection)[페이지 위쪽](#mainsection)