IPsec 및 그룹 정책을 통한 서버 및 도메인 격리
부록 A: IPsec 정책 개념 개요
업데이트 날짜: 2005년 2월 16일
이 부록은 IPsec 용어, 프로세스 및 개념에 대한 상세 개요를 제공합니다. 이 부록은 "IPsec 및 그룹 정책을 사용한 서버 및 도메인 격리 가이드"에서 설명한 바와 같이 IPsec에 대한 필수적인 이해를 돕기 위해 제작되었습니다.
이 부록의 내용은 원래 "Using Microsoft Windows IPsec to Help Secure an Internal Corporate Network Server" (영문)(Microsoft Windows ipsec을 사용하여 사내 네트워크 서버 보안) 백서(www.microsoft.com/ipsec에서 제공)의 일부로 제작되었으며, Microsoft와 Foundstone Strategic Security가 공동으로 작성했습니다.
백서의 추가 정보는 중요 정보를 처리하거나 저장하는 내부 Microsoft® Windows® 서버에 대한 네트워크 액세스를 ipsec을 사용하여 보호하는 첫 번째 모델을 설명합니다. 이 추가 정보가 IPsec 및 그룹 정책을 사용한 서버 및 도메인 격리 가이드를 이해하는 데 필수적인 것은 아니나 유용한 배경 지식이 될 것입니다.
이 페이지의 내용
소개
IPsec 정책 필터
IKE 협상 프로세스
보안 방법
IPsec 캡슐화 모델 및 프로토콜 무선 형식
IKE 인증
IKE 인증 방법 및 보안 방법 우선 순위
보안 협상 옵션
소개
IPsec 정책을 만들 때, IPsec 규칙(IPsec 동작 결정) 및 설정(구성된 규칙에 관계없이 적용)을 구성합니다. IPsec 정책을 구성한 후에는 이를 정책이 적용될 컴퓨터에 할당해야 합니다. 한 컴퓨터에 여러 IPsec 정책이 존재할 수 있으나, 한 번에 하나의 IPsec 정책만 컴퓨터에 할당될 수 있습니다.
IPsec 규칙은 ipsec이 검사할 트래픽 종류, 트래픽 허용 또는 차단 및 보안 협상 여부, IPsec 피어 인증 방법 및 기타 설정을 결정합니다. IPsec 규칙을 설정할 때, 하나 이상의 필터, 필터 작업, 인증 방법, 연결 종류 및 IPsec 캡슐화 모드(전송 모드 또는 터널 모드) 등을 포함하는 필터 목록을 구성해야 합니다. IPsec 규칙은 보통 특정 목적으로 구성됩니다(예, "인터넷으로부터 TCP 포트 135로 들어오는 모든 인바운드 트래픽 차단").
필터는 방화벽 규칙과 유사하게, 해당 경우 원본 및 대상 IP 주소, 프로토콜, 포트 번호 등으로 검사할 트래픽을 정의합니다. 필터 작업은 네트워크 트래픽에 대한 보안 요구 사항을 정의합니다. 필터 작업을 허용, 차단 또는 보안 협상(IPsec 협상) 등으로 구성할 수 있습니다. 보안을 협상하도록 필터 작업을 구성한 경우, 키 교환 보안 방법(및 우선 순위), 초기 수신 비보안 트래픽 수락 여부, ipsec을 지원하지 않는 컴퓨터와의 비보안 통신 허용 여부, 전달 완전 보안(PFS) 사용 여부 등도 구성해야 합니다.
키 교환 설정 및 키 교환 보안 방법은 IPsec 프로토콜 유선 형식(인증 헤더(AH) 또는 캡슐화된 보안 페이로드(ESP)), 암호화 및 해싱 알고리즘, 키 수명 및 기타 인터넷 키 연결(IKE) 기본 모드와 IPsec 보안 연결(SA)을 구성하는 데 필요한 설정을 결정합니다. SA는 키 지정 자료와 관련한 보안 설정의 협약입니다. 최초 IKE 협상 단계에서 만들어진 SA는 IKE 기본 모드 SA라고 합니다(ISAKMP 기본 보드 SA라고도 함). IKE 기본 모드 SA는 IKE 협상 자체를 보호합니다. 두 번째 IKE 협상 단계에서 만들어진 SA는 IPsec SA라고 합니다(각 IKE 빠른 모드 협상은 각 방향에 대해 IPsec SA를 협상하므로 IKE 빠른 모드 SA라고도 함). IPsec SA는 응용 프로그램 트래픽을 보호합니다.
이 절은 다음 주요 IPsec 정책 개념에 대한 정보를 제공합니다.
IKE 협상 프로세스
IPsec 정책 필터
보안 방법
IPsec 프로토콜 유선 형식
IKE 인증
IKE 인증 방법 및 보안 방법 우선 순위
보안 협상 옵션
IPsec 정책 개념에 대한 자세한 내용은 Microsoft Windows Server™ 2003 도움말 및 지원 센터를 참조하십시오.
IPsec 정책 필터
필터는 IPsec 정책 중 가장 중요한 부분입니다. 클라이언트나 서버 정책에서 적합한 필터를 지정하지 않거나 정책의 필터가 업데이트되기 전에 IP 주소가 변경된 경우, 보안이 적용되지 않을 수 있습니다. IPsec 필터는 컴퓨터에 TCP/IP 네트워킹 프로토콜 스택의 IP 계층에 삽입되므로, 이 필터가 모든 인바운드 또는 아웃바운드 IP 패킷을 검사(필터링)할 수 있게 됩니다. 두 컴퓨터 간의 보안 관계를 협상하는 데 소요되는 짧은 지연을 제외하고, IPsec는 최종 사용자 응용 프로그램 및 운영 체제 서비스에 투명합니다. IPsec 정책의 보안 규칙이 필터를 해당하는 필터 작업과 연결합니다. Windows IPsec는 규칙에서 옵션으로 IPsec 터널 모드 및 IPsec 전송 모드를 모두 지원합니다. IPsec 터널 모드 규칙 구성은 IPsec 전송 모드 규칙 구성과 상당히 다릅니다.
IPsec 정책과 연결된 필터링 규칙은 방화벽 규칙과 유사합니다 보안 정책 관리 Microsoft 관리 콘솔(MMC) 스냅인에서 제공하는 그래픽 사용자 인터페이스(GUI)를 사용하여 ipsec이 원본 및 대상 주소 조합과 특정 프로토콜, 포트 등에 따라 특정 트래픽 유형을 허용 또는 차단하도록 구성할 수 있습니다.
참고: Windows IPsec는 완전한 기능을 제공하는 호스트 기반 방화벽이 아니며, 통신 흐름 방향을 제어하기 위해 TCP 핸드셰이크 중 수립된 비트 추적하는 것과 같은 동적 또는 고정 필터링 기능은 지원하지 않습니다.
IPsec 필터링의 이해
필터 목록은 알려진 서브넷 및 인프라 IP 주소의 간단한 목록입니다. 모든 규칙에 포함된 모든 필터가 어떻게 조합되어 필요한 인바운드 및 아웃바운드 액세스 제어를 제공하는가를 이해하는 것이 중요합니다. 이 절은 IPsec 필터가 어떻게 패킷 처리에 영향을 미치는가를 이해하는 데 가장 중요한 상세 정보를 제공합니다.
Windows Server 2003 IPsec 감시 MMC 스냅인은 IPsec 순서에 대하여 가장 상세한 보기를 제공합니다. IPsec 서비스가 IPsec 정책 규칙 집합을 처리할 때, 필터가 두 종류로 복제되어 IKE 협상의 두 단계에 대한 제어가 가능하도록 합니다.
IKE 기본 모드 필터. 이 필터는 IPsec 정책에 정의된 필터의 원본 및 대상 주소만을 사용하여 IKE 기본 모드를 제어합니다. IKE 기본 모드 특정 필터 각각은 다음을 정의하는 연결된 IKE 기본 모드 협상 정책을 갖습니다.
키 교환 설정에서 IPsec 정책에 대하여 정의된 IKE 기본 모드 보안 방법(예, Diffie Hellman 마스터 키 강도 및 암호화, IKE 협상 자체를 보호하는 데 사용할 무결성 알고리즘 등)
IKE 기본 모드 수명 및 같은 마스터 키로부터 생성되는 세션 키 수 제한
인증 방법
IKE 빠른 모드 필터. 이 필터는 주소, 프로토콜 및 포트에 대한 전체 필터 정보를 포함합니다. IKE 빠른 모드는 이 필터 정의를 협상하여 IPsec 연결 쌍 내부에서 보호될 트래픽 종류를 결정합니다. 각각의 특정 필터는 해당하는 가중치 및 다음을 정의하는 보안 방법 집합을 갖습니다.
전송 또는 터널 모드에서 AH나 ESP 캡슐화에 대한 옵션
암호화 및 무결성 알고리즘 목록
IPsec 보안 연결 수명(킬로바이트 및 초 단위)
전달 완전 보안(PFS) 설정
IKE 빠른 모드 특정 필터는 IPsec 드라이버에 할당된 적용할 필터 목록입니다. IPsec 드라이버는 가장 높은 가중치가 지정한 순서에 따라 이러한 필터에 대하여 모든 인바운드 및 아웃바운드 IP 트래픽을 대조합니다. IKE 협상 프로세스에 대한 다음 절에서 IKE가 이러한 정책 제어를 사용하여 IPsec 보안 연결을 협상 및 관리하는 방법을 설명합니다.
IPsec 정책에 정의된 필터는 정책이 적용될 때 IPsec 서비스에서 해석되어야 할 수도 있으므로 "일반" 필터로 간주됩니다. IPsec 서비스는 IPsec 정책(또는 변경 사항)이 컴퓨터에 적용되는 시점에 모든 일반 필터를 특정 필터로 해석합니다. 지정 필터는 가중치 또는 순서를 산출하는 기본 제공 알고리즘이며, 트래픽 선택 시 필터의 특정한 정도에서도 참조됩니다. 가중치 값이 높아지면 필터가 더욱 특정해집니다. 모든 특정 필터는 가중치에 따라 정렬됩니다. 필터의 가중치는 IP 주소에서 처음으로 평가된 다음 프로토콜을 거쳐, 필터 내에 정의될 수도 있는 포트에서 마지막으로 평가됩니다. 이러한 접근을 통해, 패킷 처리 중에 정책 내의 규칙 순서와 각각의 필터 목록에서의 필터 순서 매김이 IPsec 드라이버가 적용되는 필터링 동작에 영향을 미치지 않도록 합니다. 우선 가장 특정한 필터에 패킷을 대조하여 각각의 패킷을 전체 필터 집합에 대조하는 데 소요되는 시간을 최소화합니다. 패킷과 일치하는 가장 특정한 필터에 해당하는 필터 작업은 해당 패킷에 대해서만 수행됩니다. 정의할 수 있는 가장 일반적인 필터는 어떤 IP 주소, 모든 프로토콜 및 포트와 일치하는 것입니다. 그 예로 다음 4가지 필터 정의를 들 수 있습니다.
Any <-> Any, 모든 프로토콜
Any <-> 192.168.1.0/24, 모든 프로토콜
Any <-> 192.168.1.0/24, 모든 프로토콜
Any <-> 192.168.1.10/24, 모든 TCP 원본 포트, 대상 포트 25
Any to Any 필터가 정의할 수 있는 가장 일반적인 필터입니다. Windows Server 2003 및 Windows XP 서비스 팩 2(SP2)에서만 지원됩니다. 보통 이러한 필터는 차단 작업을 통해 사용되어 기본 작업인 "모두 거부"를 수행합니다. 이 필터가 모든 트래픽을 차단하는 데 사용될 경우, 이보다 특정한 나머지 필터를 최초 필터의 예외로 간주할 수 있습니다. 지원되는 Windows 2000에 대하여 가장 일반적인 필터는 서브넷을 사용할 경우 Any <-> subnet, any protocol 또는 Any <-> My IP address입니다.
이 모든 4가지 필터는 모든 IP 주소로부터 TCP 포트 25를 사용하여 192.168.1.10으로 가는 인바운드 트래픽과 이에 해당하는 포트 25로부터의 아웃바운드 응답을 대조합니다. 4번째 필터는 대상 IP 주소, 프로토콜 및 포트 번호를 지정하므로 가장 특정합니다. IPsec 드라이버가 모든 4가지 필터를 적용한 경우, TCP 포트 25로 가는 인바운드 패킷은 4번째의 가장 특정한 필터에 대해서만 대조됩니다. 원격 시스템이 25 이외의 포트를 통해 TCP 트래픽을 192.168.1.10으로 전송한 경우, 세 번째 필터가 대조됩니다. 마지막으로 트래픽이 192.168.1.10을 제외한 192.168.1.0 서브넷의 어떤 IP 주소로 전송된 경우, 해당 트래픽에 대한 가장 특정한 필터는 두 번째 필터가 됩니다.
잠재적인 필터 설계 문제
필터를 정의할 때 원본 및 대상 주소 옵션의 특정 조합은 사용할 수 없습니다. 위에서 설명한 바와 같이, Windows 2000을 실행하는 호스트에 대해서는 모든 IP 주소로부터 모든 IP 주소를 지정하는 필터를 사용하지 말아야 합니다.
일반적으로 정책에서 필터가 많아질수록 패킷 처리에 미치는 성능 영향이 커집니다. 이러한 성능 영향은 처리량 감소, 비 페이징 풀 커널 메모리 활용 증대, CPU 이용률 증대 등으로 나타납니다. 성능에 미치는 중대한 영향은 전체 트래픽 규모, 처리하는 IPsec 보안 트래픽 및 컴퓨터의 CPU 부하 등에 따라 달라지므로 추정이 어렵습니다. 그러므로 기획 단계에서 IPsec 정책 설계의 성능 테스트가 하나의 인자로 반영되어야 합니다. 몇 백 가지 필터의 영향은 처리량이 매우 큰 컴퓨터를 제외하고는 그다지 눈에 띄지 않습니다.
Windows 2000은 대규모의 필터 처리를 위해 최적화되지 않았습니다. IPsec 드라이버는 일치되는 내용을 찾기 위해 전체 필터 목록을 순차적으로 대조해야 합니다.
Windows XP 및 Windows Server 2003은 필터 처리 속도를 높이기 위해 여러 모로 최적화되었으므로, IPsec 정책에서 더 많은 필터를 사용할 수 있습니다. 프로토콜이나 포트와 상관없이 From <IP 주소> To <IP 주소> 형식의 필터는 매우 빠른 검색을 위해 일반 패킷 분류자(GPC)를 통해 최적화되었습니다. GPC는 처리량 성능 감소 없이 거의 모든 필터를 처리할 수 있습니다. 그러므로 My IP address to <특정 제외 IP 주소>를 사용한 대규모 제외 목록도 전체 필터 목록을 담기에 충분한 비 페이징 커널 메모리가 있다면 쉽게 지원할 수 있습니다. 원본 및 대상에 대한 특정 IP 주소가 없는 필터는 GPC를 통해 최적화할 수 없습니다. 즉 Any IP <-> 특정 IP(또는 서브넷) 필터는 순차적 검색을 요구합니다. 그렇지만 Windows 2000에서의 구현이 향상되었습니다.
My IP Address의 사용이 많은 경우에 도움이 되긴 하지만, 많은 가상 웹 사이트를 호스팅하는 웹 서버와 같이 IP 주소가 많은 호스트에서는 문제가 발생할 수 있습니다. 또한 상당히 많은 필터가 My IP Address를 사용하는 경우 IPsec 드라이버 패킷 필터링 가용성에 지연이 발생할 수 있습니다. IPsec 서비스는 서비스 시작 중 및 주소 변경 이벤트 발생 시에 이들을 처리합니다. 지연이 발생하면 보안상 취약해지거나 IPsec와 안전하게 연결하는 데 시간이 더 걸립니다. 위에서 설명한 대로, 성능 테스트를 통해 특정 정책 설계의 수용 가능한 영향을 확인해야 합니다.
My IP Address는 특정 포트 또는 프로토콜로의 트래픽을 허용 또는 전송할 경우에 사용하는 것이 가장 적절합니다. 예를 들어, Woodgrove 은행용 IPsec 정책 설계에서는 모든 컴퓨터 간에 완전 텍스트로 송수신되는 인터넷 제어 메시지 프로토콜(ICMP)을 허용하는 보다 특정한 필터를 만드는 데 My IP Address 필터를 사용했습니다.
기업 내의 모바일 클라이언트에 My IP Address <-> Any IP Address 규칙이 할당되고 이 클라이언트가 외부 네트워크에 배치된 경우, 모바일 클라이언트는 해당 환경에서 통신하지 못할 것입니다. 클라이언트의 비보안 상태로 복구가 허용된 경우, 각 대상에 연결할 때 클라이언트에 3초 이상의 지연이 발생합니다. 대상이 IKE 응답에 답할 경우, IKE가 도메인 트러스트(Kerberos)를 통해 인증할 수 없으므로 IKE 협상이 실패합니다. 즉 RFC 1918 개인 주소가 내부 네트워크 서브넷으로 사용된 경우, 모바일 클라이언트는 호텔, 가정용 네트워크 및 잠재적으로 다른 내부 네트워크에 연결할 때 영향을 받게 됩니다. 모바일 클라이언트에 연결 문제가 발생한 경우, 다른 네트워크에 연결된 IPsec 서비스를 중지하기 위해 로컬 관리자 권한이 필요할 수 있습니다. 결과적으로 내부 네트워크에 연결 시 IPsec 서비스의 실행 여부를 도메인 로그온 스크립트를 사용하여 확인해야 할 것입니다.
Windows 2000은 기본적으로 멀티캐스트 및 브로드캐스트를 사용하는 패킷 필터링을 수행하도록 설계되지 않았습니다. 이러한 트래픽은 IKE 협상을 통해 보안될 수 없기 때문입니다. 따라서 멀티캐스트 및 브로드캐스트 패킷 종류는 IPsec 필터를 건너 뛰는 기본 제외 사항에 해당합니다. 기본 제외의 보안 함축 정보에 대한 자세한 설명 및 일부를 기본적으로 제거하는 서비스 팩 3에 구현된 변경 사항은 Microsoft 기술 자료 기사 811832, "일부 시나리오에서 IPSec 기본 면제를 사용하여 IPSec 보호를 무시할 수 있다"(https://support.microsoft.com/default.aspx?scid=kb;ko;811832)를 참조하십시오. Windows XP 및 Windows Server 2003에서의 TCP/IP와 IPsec의 통합이 모든 유형의 IP 패킷을 필터링하도록 향상되었습니다. 그러나 IKE가 멀티캐스트 및 브로드캐스트에 대하여 보안을 협상할 수 없으므로 필터링에 대한 지원은 제한적입니다. 기본 제외 제거 및 멀티캐스트 및 브로드캐스트 트래픽에 대한 필터링 지원 정도는 기술 자료 기사 810207, "IPSec default exemptions are removed in Windows Server 2003"(https://support.microsoft.com/kb/810207)을 참조하십시오. Windows XP SP2는 Windows Server 2003과 같은 Any <-> Any 필터링 기능을 지원합니다.
IKE 협상 프로세스
IKE 프로토콜은 안전하게 각 컴퓨터 간의 트러스트 관계를 수립, 보안 옵션 협상, 공유 비밀 암호화 키 지정 자료의 동적 생성을 지원하도록 설계되었습니다. IKE는 성공적이고 안전한 통신을 보장하기 위해 1단계(기본 모드) 협상과 2단계(빠른 모드) 협상 등의 2단계 작업을 수행합니다. 보안 협상 중 두 컴퓨터가 동의한 암호화 및 인증 알고리즘을 사용함으로써 각 단계 동안 기밀성 및 인증을 보장할 수 있습니다.
기본 모드 협상
기본 모드 협상 중 두 컴퓨터는 안전하고 인증된 채널을 수립합니다. 우선 다음 IPsec 정책 매개 변수를 협상합니다: 암호화 알고리즘(DES 또는 3DES), 무결성 알고리즘(MD5 또는 SHA1), 기본 키 지정 자료에 사용될 Diffie-Hellman 그룹(그룹 1, 그룹 2, 또는 Windows Server 2003에서 그룹 2048), 인증 방법(Kerberos 버전 5 프로토콜, 공용 키 인증서 또는 미리 공유한 키). IPsec 정책 매개 변수 협상 후 공개 값의 Diffie-Hellman 교환이 완료됩니다. Diffie-Hellman 알고리즘은 컴퓨터 간의 공유 대칭 비밀 키를 생성하는 데 사용됩니다. Diffie-Hellman 교환이 완료된 후 각 컴퓨터의 IKE 서비스가 인증을 보호하는 데 도움이 되는 마스터 키를 생성합니다. 마스터 키는 협상 알고리즘 및 방법과 함께 ID를 인증하는 데 사용됩니다. 그러면 통신의 개시자가 잠재적인 SA에 대한 제안을 응답자에게 제시합니다. 응답자는 제안을 수용하는 응답이나 대안을 담음 응답을 전송합니다. 성공적인 IKE 기본 모드 협상의 결과는 기본 모드 SA입니다.
빠른 모드 협상
빠른 모드 협상 중에 IPsec SA 쌍이 수립되어 응용 프로그램 트래픽 보호를 돕는데, 이는 TCP, 사용자 데이터그램 프로토콜(UDP) 및 기타 프로토콜 등을 통해 전송된 패킷을 포함할 수 있습니다. 우선 다음 정책 매개 변수를 협상합니다: IPsec 프로토콜 유선 형식(AH 또는 ESP), 무결성 및 인증을 위한 해시 알고리즘(MD5 또는 SHA1), 암호화가 요청된 경우 암호화 알고리즘(DES 또는 3DES) 이 작업에서는 수립된 IPsec SA 쌍에서 다룰 IP 패킷 유형과 관련하여 상호 동의에 이르게 됩니다. IPsec 정책 매개 변수를 협상한 후, 세션 키 자료(각 알고리즘에 대한 암호 키 및 키 수명(초 및 킬로비트 단위))를 새로 고치거나 교환합니다.
각 IPsec SA는 보안 매개 변수 인덱스(SPI)로 식별하며, 전송된 각 패킷의 IPsec 헤더에 삽입됩니다. 한 SPI는 인바운드 IPsec SA를, 다른 SPI는 아웃바운드 IPsec SA를 식별합니다.
IKE 기본 모드 SA 및 IPsec SA
ipsec을 사용하여 트래픽을 보안할 때마다 하나의 IKE 기본 모드 SA 및 두 IPsec SA가 수립됩니다. IPsec로 보안된 통신이 CORPCLI와 CORPSRV 간에 발생하는 예제 시나리오에서, 다음 SA가 수립됩니다.
CORPCLI [IP1] <-------- IKE 기본 모드 SA [IP1, IP2] -----> [IP2] CORPSRV
CORPCLI [IP1] ---------- IPsec SA [SPI=x] ------------------> [IP2] CORPSRV
CORPCLI [IP1] ---------- IPsec SA [SPI=x] --------------- [IP2] CORPSRV
여기서 다음이 적용됩니다.
IP1은 CORPCLI의 IP 주소입니다.
IP2는 CORPSRV의 IP 주소입니다.
x는 CORPCLI로부터의 CORPSRV에 대한 인바운드 IPsec SA를 식별하는 SPI입니다.
x는 CORPCLI로 가는 CORPSRV에 대한 아웃바운드 IPsec SA를 식별하는 SPI입니다.
요약에서 볼 수 있듯이 CORPCLI와 CORPSRV 간의 IKE 기본 모드 SA는 양방향입니다. 두 컴퓨터 모두 IKE 기본 모드 SA가 제공하는 보호를 통해 빠른 모드 협상을 개시할 수 있습니다. IPsec SA는 상위 계층 프로토콜의 상태에 영향을 받지 않습니다. 예를 들어, IPsec SA가 지속되는 동안 TCP 연결이 수립 및 종료될 수 있으며 TCP 연결이 종료되기 전에도 IPsec SA가 만료될 수 있습니다. IKE는 연결이 중단되지 않도록 빠른 모드 협상을 통해 기존 IPsec SA 쌍의 수명이 만료되기 전에 두 개의 새로운 IPsec SA 쌍을 수립함으로써 재협상을 시도합니다. 이러한 프로세스를 보통 IPsec SA 키 재지정이라고 하나, 사실은 두 개의 새로운 IPsec SA가 수립되는 것입니다. IKE 기본 모드 SA의 수명은 시간 및 시도된 IPsec SA의 수를 통해서만 측정할 수 있습니다(IKE 프로토콜에서 전송된 데이터의 바이트 수로는 측정 안 됨). IKE 기본 모드 SA는 IPsec SA 쌍과 상관 없이 만료됩니다. 새 IPsec SA 쌍이 필요할 경우, 필요에 따라 IKE 기본 모드 SA가 자동 재협상됩니다(기본 모드 SA가 만료되었을 때). IETF(Internet Engineering Task Force) 설계에 따라 IKE는 기본 모드 SA 키 재지정과 양 방향 IKE 빠른 모드 협상이 가능해야 합니다. 그러므로 IKE 기본 모드 SA에 대하여 두 컴퓨터의 IPsec 정책에 구성된 인증 방법은, IKE 기본 모드 협상이 개시된 방향으로 인증이 성공할 수 있도록 허용해야 합니다. 마찬가지로 빠른 모드에 대한 필터 작업에서의 IPsec 정책 설정도 양방향 빠른 모드 협상이 성공하도록 허용해야 합니다.
보안 방법
보안 방법은 IKE 기본 모드 협상 중에 암호화 및 해싱 알고리즘, 기본 모드 SA를 만드는 데 사용할 Diffie-Hellman 그룹 등을 정의하고, IKE 협상 채널을 보안하는 데 사용됩니다. 보안 방법은 빠른 모드 협상 중에도 빠른 모드 인바운드 및 아웃바운드 SA를 만드는 데 사용할 캡슐화 모드(전송 또는 터널), IPsec 프로토콜 유선 형식(AH 또는 ESP), 암호화 및 해싱 알고리즘, 키 수명 등을 정의하는 데 사용됩니다.
IPsec 캡슐화 모델 및 프로토콜 무선 형식
IPsec는 IP 페이로드의 암호 보호를 통해 IP 패킷의 데이터를 보호합니다. 제공되는 보호는 IPsec이 사용되는 모드와 프로토콜 유선 형식에 따라 다릅니다. 전송 모드 또는 터널 모드에서 ipsec을 사용할 수 있습니다.
IPsec 캡슐화 모드
IPsec** 터널 모드는 인터넷을 통한 사이트 대 사이트 네트워킹과 같이 네트워크 사이의 사이트 간 트래픽(게이트웨이 간 또는 라우터 간이라고도 함)를 보안하는 데 가장 널리 사용됩니다. IPsec 터널 모드가 사용되면 게이트웨이 전송이 IPsec 프로토콜 유선 형식(AH 또는 ESP) 중 하나로 보호될 새로운 IP 패킷을 만들어 전체 원본 IP 패킷을 캡슐화합니다. 터널 모드에서의 IPsec에 대한 정보는 Windows Server 2003 Deployment Kit(https://go.microsoft.com/fwlink/?LinkId=8195)의 Deploying Network Services 부분의 "Deploying IPsec" 장을 참조하십시오.
IPsec 전송 모드는 호스트 대 호스트 통신 보안에 사용되며 Windows IPsec에 대한 기본 모드입니다. IPsec 전송 모드가 사용되면 IPsec는 IP 페이로드만 암호화하며 IP 헤더는 암호화되지 않습니다. Windows IPsec는 우선적으로 종단 간 통신(예, 클라이언트와 서버 간 통신)을 보호하는 데 사용됩니다.
IPsec 프로토콜 유선 형식
IPsec는 AH 또는 ESP 등, 두 가지 프로토콜 유선 형식을 지원합니다. IPsec 전송 모드는 원본 IP 페이로드와 IPsec 헤더를 함께 캡슐화합니다(AH 또는 ESP).
AH
AH는 전환에서 변경이 허용된 IP 헤더의 필드를 제외하고, 전체 패킷(패킷의 IP 헤더 및 데이터 페이로드 모두)에 대한 데이터 원본 인증, 데이터 무결성, 재생 방지 보호를 제공합니다. AH는 데이터 기밀성을 제공하지 않습니다. 즉 데이터를 암호화하지 않습니다. 데이터는 읽을 수는 있으나, 수정 또는 스푸핑으로부터는 보호됩니다. 다음 그림에서처럼 IP 헤더와 TCP 데이터 간의 AH 헤더 배치를 통해 무결성 및 인증이 제공됩니다.
.gif)
그림 A.1. 패킷의 인증 헤더
AH를 사용하려면 적절한 규칙에 대한 속성의 사용자 정의 보안 방법 설정 대화 상자에서 암호화 없이 데이터 및 주소 무결성(AH) 확인란을 선택하고 사용할 무결성 알고리즘을 지정하십시오.
ESP
ESP는 IP 페이로드에 대해서만 데이터 원본 인증, 데이터 무결성, 재생 방지 보호, 무결성 옵션을 제공합니다. 전송 모드의 ESP는 암호화 체크섬이 있는 전체 패킷을 보호하지 않습니다. IP 헤더는 보호되지 않습니다. 다음 그림에서와 같이 ESP 헤더는 TCP 데이터, ESP 트레일러, ESP 인증 트레일러 앞, TCP 데이터 뒤에 배치됩니다.
.gif)
그림 A.2 패킷의 ESP 데이터
ESP를 사용하려면 적절한 규칙에 대한 속성의 사용자 정의 보안 방법 설정 대화 상자에서 데이터 및 주소 무결성(ESP) 확인란을 선택하고 사용할 무결성 및 암호화 알고리즘을 지정하십시오.
IKE 인증
IKE는 컴퓨터 간의 상호 인증을 사용하여 트러스트된 통신을 수립하며, 다음 인증 방법 중 하나를 사용해야 합니다: Kerberos 버전 5 프로토콜, 컴퓨터 X.509 버전 3 공개 키 인프라(PKI) 인증서 키 또는 미리 공유한 키 두 통신 종단점은 적어도 하나의 공통된 인증 방법을 가져야 하며, 그렇지 않으면 통신이 실패합니다.
IKE 인증 프로세스
IKE 협상 중 IKE 개시자는 IKE 응답자에게 인증 방법 목록을 제안합니다. 응답자는 개시자의 원본 IP 주소를 사용하여 IKE 협상을 제어하는 필터를 식별합니다. 응답자의 IPsec 정책의 필터에 해당하는 인증 방법 목록을 사용하여 개시자의 목록에서 하나의 인증 방법을 선택합니다. 그러면 응답자는 동의한 인증 방법을 개시자에게 알립니다. 선택한 인증 방법이 실패할 경우, IKE는 다른 인증 방법의 시도를 위한 방법을 제공하지 않습니다. 인증에 성공하고 기본 모드 협상이 성공적으로 완료된 경우, 기본 모드 SA가 8시간 동안 지속됩니다. 8시간이 다 되어가는 시점에도 데이터를 계속 전송 중일 경우, 기본 모드 SA가 자동으로 재협상합니다.
IKE 인증 방법
IPsec 정책에 적합한 인증 방법을 선택하는 것이 중요합니다. IPsec 정책 규칙은 인증 방법 목록과 필터의 각 IP 주소를 연결하여 IKE가 각 IP 주소에서 사용할 인증 방법 목록을 결정할 수 있도록 합니다.
Kerberos 버전 5 프로토콜 인증
Kerberos 버전 5 프로토콜은 Windows 2000 및 Windows Server 2003 Active Directory 도메인의 기본 인증 표준입니다. 도메인 또는 트러스트된 도메인의 모든 컴퓨터는 이 인증 방법을 사용합니다.
Kerberos 인증을 사용할 경우, 기본 모드 협상 중에 각 IPsec 피어는 암호화되지 않은 형식으로 컴퓨터 ID를 다른 피어에 전송합니다. 기본 모드 협상의 인증 중에 전체 IP 페이로드의 암호화가 수행되어야 컴퓨터 ID가 암호화됩니다. 공격자가 응답하는 IPsec 피어가 컴퓨터 ID 및 도메인 구성원을 노출하도록 할 수 있는 IKE 패킷을 전송할 수 있습니다. 이 때문에, 인터넷에 연결하는 컴퓨터를 보안하기 위해 인증서 인증을 권장합니다.
기본적으로 Windows 2000(서비스 팩 3) 및 Windows XP에서는 Kerberos 프로토콜 트래픽은 IPsec 필터링에서 제외됩니다. Kerberos 프로토콜 제외를 제거하려면 레지스트리를 수정하여 이 트래픽을 보안할 적절한 IPsec 필터를 추가해야 합니다. Windows 2000 및 Windows Server 2003에서의 기본 제외에 대한 내용은, 아래 웹 사이트의 "Special IPsec considerations - Creating, modifying, and assigning IPSec (영문)policies"를 참조하십시오. www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag\_IPSECbpSpecial.asp.
공개 키 인증서 인증
Windows 2000 서버에서는 인증서 서비스를 사용하여 인증서 유효 기간 동안 IPsec에 대한 컴퓨터 인증서를 자동 관리할 수 있습니다. 인증서 서비스는 Active Directory 및 그룹 정책과 통합되며, 인증서 자동 등록 및 갱신을 활성화하고 IPsec와 호환되는 여러 기본 인증서 템플릿을 제공하여 인증서 배포를 간소화합니다. IKE 인증에 인증서를 사용하려면 사용할 특정 인증서가 아닌 사용할 수용 가능한 루트 인증서 기관(CA)의 정렬된 목록을 정의해야 합니다. 두 컴퓨터 모두 IPsec 정책 구성에 공통 루트 CA가 있어야 하며 클라이언트는 연결된 컴퓨터 인증서가 있어야 합니다.
인증서 선택 프로세스 동안 IKE는 일련의 검사 작업을 수행하여 컴퓨터 인증서에 대한 특정 요구 사항에 부합하도록 합니다. 예를 들어 컴퓨터 인증서가 길이 512 비트 이상의 공개 키를 가지고 디지털 서명 키를 사용해야 할 수도 있습니다.
참고:강력한 개인 키 보호에 대하여 설정된 고급 옵션이 있는 인증서 서비스로부터 가져 온 인증서는 IKE 인증에 적용되지 않습니다. 이는 사용자가 IKE 협상 중에 컴퓨터 인증서에 대한 개인 키에 액세스하기 위해 필요한 개인 식별 번호(PIN)를 입력할 수 있기 때문입니다.
미리 공유한 키
Kerberos 인증을 사용하지 않고 CA에 액세스 권한이 없는 경우, 미리 공유한 키를 사용할 수 있습니다. 예를 들어, 네트워크 상의 독립 실행형 컴퓨터는 일부 시나리오에서 Kerberos 인증(컴퓨터의 도메인 계정을 통한)이나 CA로부터의 인증서가 성공적인 IKE 인증을 활성화할 수 없으므로 미리 공유한 키를 사용해야 합니다.
중요: 미리 공유한 키는 쉽게 구현할 수 있으나 제대로 사용하지 않으면 손상될 수 있습니다. 키 값이 안전하게 저장되지 않아 비밀을 유지하기 어려우므로 Active Directory에서는 미리 공유한 키 인증을 사용하지 않는 것이 좋습니다. 미리 공유한 키는 IPsec 정책에 일반 텍스트로 저장됩니다. 로컬 관리자 그룹의 모든 구성원은 로컬 IPsec 정책을 확인할 수 있으며, 로컬 시스템 사용자 권한이 있는 모든 시스템 서비스에서 IPsec 정책을 읽을 수 있습니다. 기본적으로 도메인의 모든 인증된 사용자는 Active Directory 기반 IPsec에 저장된 미리 공유된 키를 확인할 수 있습니다. 또한 공격자가 IKE 협상 패킷을 수집할 수 있는 경우, 게시된 방법이 공격자가 미리 공유된 키를 발견하도록 할 수 있습니다. 자세한 내용은 "Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets"(https://go.microsoft.com/fwlink/?LinkId=18769)를 참조하십시오.
미리 공유한 키 인증은 RFC와의 상호 운용성 및 호환성 목적으로 제공됩니다. 미리 공유한 키 인증을 사용해야 할 경우, 25자 이상의 임의 키 값과, 각 IP 주소 쌍에 대해 각기 다른 미리 공유한 키를 사용하십시오. 그러면 각 대상에 대해 다른 보안 규칙을 적용하게 되어 손상된 미리 공유한 키가 키를 공유하는 해당 컴퓨터만 손상하도록 할 수 있습니다.
IPsec CRL 검사
인증서 기반 인증을 사용할 경우, IPsec 인증서 해지 목록(CRL) 검사도 활성화할 수 있습니다. 기본적으로 Windows 2000에서는 IKE 인증서 인증 동안 IPsec CRL이 자동 검사되지 않습니다.
IPsec CRL 검사를 활성화하려면 다음을 수행하십시오.
주의: 레지스트리를 잘못 편집하면 시스템에 심각한 손상을 줄 수 있습니다. 레지스트리를 변경하기 전에 컴퓨터의 중요 데이터를 백업해야 합니다.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\ **Services\PolicyAgent\**에서 새 Oakley 키, 이름이 StrongCrlCheck인 DWORD 항목을 추가합니다.
이 항목에 0에서 2 사이의 값을 할당합니다. 여기서 다음이 적용됩니다.
값 0은 CRL 검사를 비활성화합니다(Windows 2000 기본값).
값 1은 CRC 검사를 시도하여 인증서가 해지된 경우에만 인증서 유효성 검사가 실패합니다(Windows XP 및 Windows Server 2003 기본값). CRL 검사 중 발생하는 다른 실패(예, 접근 불가능한 해지 URL 등)는 인증서 유효성 검사 실패를 야기하지 않습니다.
값 2는 강력한 CRL 검사를 활성화합니다. 즉 CRL 검사가 필수적이며 CRL 처리 중 어떤 오류가 발생하면 인증서 유효성 검사가 실패합니다. 이 레지스트리 값을 확장 보안용으로 설정합니다.
다음 중 하나를 수행하십시오.
컴퓨터를 다시 시작합니다.
명령 프롬프트에서 net stop policyagent 및 net start policyagent 명령을 실행하여 IPsec 서비스를 중지 후 다시 시작합니다.
참고: IPsec CRL 검사는 인증서가 해지된 즉시 인증서 유효성 검사가 실패함을 보장하지는 않습니다. 해지된 인증서가 업데이트 및 게시된 CRL에 배치되는 시간과 IPsec CRL 검사를 수행하는 컴퓨터가 이 CRL을 검색하는 시간 사이에는 지연이 존재합니다. 컴퓨터는 현재 CRL이 만료되거나 다음 CRL이 게시되어야 새 CRL을 검색합니다. CRL은 메모리와, \Documents and Settings\UserName\Local Settings\Temporary Internet Files by CryptoAPI에 캐시됩니다. CRL은 컴퓨터를 다시 시작해도 지속되므로 CRL 캐시 문제가 발생한 경우 컴퓨터를 다시 시작해도 문제가 해결되지 않습니다.
IKE 인증 방법 및 보안 방법 우선 순위
IPsec 규칙을 구성하여 하나의 인증 방법이나 하나의 보안 방법을 지정할 수 있습니다. 또는 인증 및 보안 방법의 우선 순위 목록을 지정할 수도 있습니다. 우선 순위는 인증 방법 및 보안 방법에 적용되므로 가장 선호하는 방법에서부터 가장 선호하지 않는 방법까지 지정할 수 있습니다. 예를 들어 다음 그림에서와 같이, Kerberos 버전 5 프로토콜 및 공개 키 인증서 인증을 모두 인증 방법으로 제공하지만 Kerberos 프로토콜의 우선 순위가 더 높도록 지정할 수 있습니다.
.gif)
그림 A.3 인증 방법 우선 순위
클라이언트가 CORPSRV에 연결을 시도하나 인증에 공개 키 인증서만 수용할 경우, CORPSRV는 이 인증 방법을 사용하여 통신 수립을 계속합니다. IKE는 선택한 인증 방법을 사용하여 성공해야 하며 그렇지 않으면 통신이 차단됩니다. IKE는 협상이 실패할 경우 다른 인증 방법 사용을 시도하지 않습니다. 같은 원리가 보안 방법에 적용됩니다. 예를 들면 ESP를 AH보다 선호할 수 있습니다.
보안 협상 옵션
필터 작업 속성의 **보안 방법****탭에서 IPsec의 비보안 상태로 복구(보안되지 않은 통신으로 복구), 인바운드 통과, 세션 키 PFS 등의 허용 여부를 구성할 수 있습니다. 규칙에 대한 일반 속성의 키 교환 설정 대화 상자에서 마스터 키 PFS를 구성할 수 있습니다.
비보안 상태로 복구
비보안 상태로 복구를 허용하면 가능한 경우 ipsec이 트래픽을 보안하지만(연결의 다른 종단의 컴퓨터가 보완 필터 작업이 있는 IPsec와 정책의 필터를 지원하는 경우), 피어에 보안 협상에 대한 요청에 응답하기 위한 IPsec 정책이 없는 경우 보안되지 않은 상태로 트래픽이 전송될 수 있습니다. 피어가 3초 내에 보안 협상 요청에 응답하지 않을 경우, 일반 텍스트 트래픽용 SA(소프트 SA)가 만들어집니다. 소프트 SA는 IPsec 캡슐화가 발생하지 않는 보통의 TCP/IP 통신을 허용합니다. ipsec이 이러한 트래픽을 보안할 수는 없으나 다른 응용 프로그램이 이 트래픽을 보안할 수 있습니다(예, LDAP(Lightweight Directory Access Protocol) 암호화나 원격 프로시저 호출(RPC)이 트래픽을 보안할 수도 있음). 피어가 3초 내에 응답하지 않고 보안 협상이 실패한 경우, 해당하는 필터와 일치하는 통신이 차단됩니다.
비보안 상태로 복구는 다음 컴퓨터와의 상호 운용성을 제공합니다.
Windows 2000 이전 운영 체제를 실행하는 컴퓨터
IPsec 정책이 구성되지 않은 Windows 2000 이후 시스템을 실행하는 컴퓨터
ipsec을 지원하지 않는 비Microsoft 운영 체제를 실행하는 컴퓨터
비보안 상태로 복구를 활성화 또는 비활성화하려면, **보안 방법****탭의 필터 작업 속성에서 IPSec을 인식하지 않는 컴퓨터와 보안되지 않은 통신 허용 확인란을 선택 또는 선택 해제합니다.
클라이언트 정책에 대하여 이 옵션을 활성화 또는 비활성화할 수 있습니다. 이 옵션을 활성화하고 서버가 클라이언트의 보안 협상 요청에 응답하지 않는 경우, 클라이언트가 비보안 상태로 복구하도록 허용할 수 있습니다. 이 확인란의 선택을 해제하였고 서버가 클라이언트의 보안 협상 요청에 응답하지 않는 경우, 통신이 차단됩니다. 일부 경우 비보안 상태로 복구를 허용하는 것이 유용합니다. 그러나 IKE는 응답이 없는 경우에만 비보안 상태로 복구를 허용합니다. 보안 상의 이유로 Windows IPsec는 IKE 협상이 실패하거나, 인증 실패 또는 보안 매개 변수 합의 실패 등 IKE 협상 중 오류가 발생한 경우(응답 후) 보안되지 않은 통신을 허용하지 않습니다.
초기 배포에 대해서는 이 확인란을 선택하여 서버에서 ipsec이 실행 중지된 경우 클라이언트가 비보안 상태로 복구하여 초기 연결을 수립할 수 있도록 하는 것이 좋습니다.
인바운드 통과
인바운드 통과가 허용되면 보통의 인바운드 TCP/IP 트래픽(TCP SYN 패킷처럼 IPsec에 의해 보안되지 않는 트래픽)이 필터 작업과 연결된 인바운드 필터와 일치하는 경우 이를 수용할 수 있습니다. 상위 계층 프로토콜 응답 패킷(예, TCP SYN ACK 패킷)이 해당하는 아웃바운드 필터와 일치하고 보안 협상을 트리거합니다. 그러면 두 IPsec SA를 협상하고 트래픽이 ipsec을 통해 양 방향으로 보안됩니다. 인바운드 통과 옵션은 서버가 기본 응답을 사용하여 클라이언트로의 보안 협상을 개시할 수 있도록 합니다. 클라이언트 IPsec 정책에서 기본 응답 규칙을 활성화하면 클라이언트는 서버의 IP 주소를 포함하는 필터를 유지하지 않아도 됩니다. 클라이언트 IPsec 정책에서 기본 응답 규칙을 활성화하지 않은 경우, 서버 IPsec 정책에서 인바운드 통과 옵션을 활성화하지 않아도 됩니다. 또한 인터넷에 연결된 컴퓨터에서는 이 옵션을 활성화하지 않습니다.
인바운드 통과를 활성화 또는 비활성화하려면 **보안 방법****탭의 필터 작업 속성에서 보안되지 않은 통신을 허용하지만 항상 IPSec을 사용하여 응답 확인란을 선택 또는 선택 해제하십시오.
세션 키 및 마스터 키 PFS
PFS는 마스터 키에 대한 기존 키 지정 자료를 사용하여 새 세션을 도출할 수 있는지의 여부를 지정하는 메커니즘입니다. PFS는 단일 키 손상이 전체 통신이 아닌 PFS가 보호하는 데이터에만 액세스를 허용하도록 합니다. 이를 위해 PFS는 전송을 보호하는 데 사용되는 키가 추가 키를 생성하는 데 사용될 수 없도록 합니다. 세션 키 PFS는 재인증 없이 사용할 수 없으며 마스터 키 PFS보다 덜 자원 집중적입니다. 세션 키 PFS가 활성화되면 새로운 Diffie-Hellman 키 교환을 수행하여 새로운 마스터 키 키 작성 정보를 생성합니다.
서버 정책에서 세션 키 PFS를 활성화한 경우 클라이언트 정책에서도 활성화해야 합니다. 규칙 일반 속성에서 키 교환 설정 대화 상자의 세션 키 전달 완전 보안(PFS) 사용 확인란을 선택하여 세션 키 PDF를 활성화할 수 있습니다. 마스터 키 PFS는 재인증을 요구하며 자원 집중적입니다. 발생하는 빠른 모드 협상 마다 새로운 기본 모드 협상을 요구합니다. 세션 키 전달 완전 보안(PFS) 사용 확인란을 선택하여 마스터 키 PDF를 구성할 수 있습니다. 서버 정책에서 마스터 키 PFS를 활성화한 경우 클라이언트 정책에서 활성화하지 않아도 됩니다. 이 옵션을 활성화하면 상당한 오버헤드가 발생하므로, ipsec이 제공하는 강력한 암호 보호의 손상을 시도하는 정교한 공격자에게 IPsec 트래픽이 노출될 가능성이 있는 적대적인 환경에서만 세션 키 PFS나 마스터 키 PFS를 활성화하도록 하십시오.
전체 솔루션 다운로드