이 장에서는 서버 및 도메인 격리 솔루션을 계획하고 배포하는 데 필요한 정보를 얻는 방법에 대한 정보를 제공합니다. 성공적으로 배포하려면 정보 기술(IT) 인프라의 정확한 최신 정보가 필요합니다. 이 장을 읽고 나면 서버 및 도메인 격리 솔루션의 설계를 완료하는 데 필요한 정보를 잘 이해하게 됩니다.
이 장의 마지막 부분에서는 식별된 컴퓨터가 솔루션 내의 "신뢰할 수 있는" 컴퓨터로 작동할 수 있는지 이해하고 문서화하는 과정을 설명합니다. 설계 팀이 솔루션 계획을 수립할 때 이 정보가 필요합니다.
이 장의 정보를 사용하기 전에 여러분과 조직은 다음 전제 조건을 충족해야 합니다. 이 장에서 제공하는 지침은 이러한 전제 조건과 밀접하게 일치하는 조직의 요구를 충족시키도록 특별히 조정된 것입니다. 모든 전제 조건을 충족시키지 못하면 프로젝트에 반드시 부정적인 영향을 미치는 것은 아니지만, 충족할 경우에는 이 지침의 가치가 극대화될 것입니다.
지식 전제 조건
IPsec의 개념에 익숙해야 하며 다음 사항에 대해서도 깊이 이해하고 있어야 합니다.
Microsoft® Windows® 인증(특히, Kerberos 버전 5 인증 프로토콜)
Active Directory® 디렉터리 서비스 개념(Active Directory 구조와 도구를 포함하여 사용자, 그룹, 기타 Active Directory 개체 조작 및 그룹 정책의 사용)
Windows 시스템 보안(사용자, 그룹, 감사 및 ACL(액세스 제어 목록) 같은 보안 개념 포함)
조직의 시스템 명명 규칙
조직의 물리적 및 논리적 위치
조직에서 사용하는 위험 관리 실행
방화벽을 사용한 포트 필터링을 포함한 핵심 네트워킹 개념
이 장을 계속하기 전에 이 가이드의 앞 장을 읽고 솔루션의 구조와 설계 개념도 완벽하게 이해해야 합니다.
조직 전제 조건
조직의 격리 그룹을 계획하는 것은 대개 여러 사람들이 참여하는 작업입니다. 정확한 요구 사항을 결정하는 데 필요한 정보는 조직 전체의 많은 출처에서 오는 경우가 많습니다. 다음과 같은 사람들을 포함하여 이러한 그룹에 참여할 필요가 있는 조직의 구성원들로부터 의견을 경청해야 합니다.
임원진
보안 및 감사 담당자
Active Directory 엔지니어링, 관리 및 운영 담당자
DNS(Domain Name System), 웹 서버 및 응용 프로그램 소유자
네트워크 관리 및 운영 담당자
내부 교육 및 헬프 데스크 담당자
참고: IT 조직의 구조에 따라 이러한 역할은 여러 사람들로 채워지거나, 몇 명이 여러 역할을 겸할 수도 있습니다.
나열된 팀으로부터 정보를 요구하는 것 말고도 IPsec을 환경에 도입하면서 현재 운영 방법을 업데이트해야 하는지 이해하는 것이 중요합니다. 또한 네트워크 장치용 BIOS 및 펌웨어 버전 같이 소프트웨어와 하드웨어를 업데이트해야 할 수도 있습니다. 마지막으로 IPsec 환경을 지원하고 문제 해결하기 위해 추가 네트워크 도구가 필요할 수 있습니다.
IT 인프라 전제 조건
이 장에서는 다음 IT 인프라가 있다고 가정합니다.
혼합 모드 또는 기본 모드에서 실행되는 Microsoft Windows Server™ 2003 Active Directory 도메인. 이 솔루션은 그룹 정책 개체(GPO) 응용 프로그램에 유니버설 그룹을 사용합니다. 조직이 혼합 모드 또는 기본 모드를 실행하고 있지 않은 경우 표준 글로벌 및 로컬 그룹 구성을 사용하여 GPO를 적용할 수도 있습니다. 단, 이러한 옵션이 너무 복잡하여 관리할 수 없기 때문에 이 솔루션이 이 옵션을 사용하지 않습니다.
이 장은 솔루션 설계자와 디자이너가 사용할 IT 인프라 인벤토리를 만드는 일을 담당하는 IT 전문가를 위해 디자인되었습니다. 이들 IT 전문가는 대개 조직의 지원 또는 운영 부서의 직원입니다. 이 장에서 큰 효과를 거두려면 정보 수집 프로세스에 사용되는 도구와 기술 및 조직의 현재 인프라에 대한 기술적 이해 수준이 높아야 합니다.
조직의 컴퓨터, 소프트웨어 및 네트워크 장치의 신뢰성 있는 레코드를 얻고 유지 관리하는 프로세스는 일반적인 IT 과제입니다. 프로젝트의 성공 여부는 이러한 프로세스에서 얻는 정보에 달려 있습니다. 서버 및 도메인 격리 프로젝트를 위한 계획 프로세스를 시작하기 전에 조직에 이미 배포된 컴퓨터, 네트워크 및 디렉터리 서비스에 대한 최신 정보를 수집하고 분석해야 합니다. 이 정보를 사용하면 기존 인프라의 가능한 모든 요소를 고려하는 설계를 만들 수 있습니다. 수집된 정보가 정확하지 않을 경우 계획 단계 동안 고려하지 않은 장치와 컴퓨터가 구현하는 동안 나타나면 문제가 발생할 수 있습니다. 다음 절에서는 각 영역에 필요한 정보를 설명하고 Woodgrove 은행 서버 및 도메인 격리 솔루션을 위해 수집한 정보 예제를 제공합니다.
네트워크 검색
IPsec은 인터넷 프로토콜 자체에 계층화되어 있기 때문에 서버 및 도메인 격리를 계획할 때 가장 중요한 측면은 아마도 네트워크 구조일 것입니다. 네트워크에 대해 완전하지 않거나 정확하지 않게 이해하고 있으면 격리 솔루션이 성공하지 못할 것입니다. 서브넷 레이아웃, IP 주소 지정 구성표 및 트래픽 패턴을 이해하는 것이 이러한 노력의 하나이지만, 이 프로젝트의 계획 단계를 완료하는 데 다음 두 가지 구성 요소가 중요합니다.
네트워크 분할 설명서
현재 네트워크 트래픽 모델 설명서
목적은 물리적 위치 이외에 네트워크 위치별로 자산을 식별하는 데 충분한 정보를 확보하는 것입니다.
충분히 심사 숙고하고, 쉽게 식별할 수 있는 주소 범위를 가지며, 가능하면 중복이나 불연속 범위가 적은 네트워크 아키텍처로 시작하는 것이 좋습니다. "효율적인" 네트워크에 허용되지 않는 특정 비즈니스 요구 사항이나 상황(예: 합병 및 인수 활동)이 있을 수 있지만, 현재 상태를 문서화하고 이해하는 경우 네트워크 및 관리되는 자산을 확인하는 작업은 더 간단합니다. 복잡하고 제대로 문서화되지 않은 네트워크에는 식별되지 않은 영역이 너무 많아 구현하는 동안 문제를 일으킬 수 있으므로 이러한 네트워크를 설계의 시작점으로 사용하지 마십시오.
이 지침을 사용하면 TCP/IP 주소 지정과 가변 길이 서브넷 마스킹, VLAN(Virtual Local Area Network) 분할 또는 기타 네트워크 최적화 방법과 기술 등 서버 및 도메인 격리 계획과 관련된 대부분의 정보를 얻을 수 있습니다. 얻어진 정보는 서버 및 도메인 격리 솔루션의 구현과 운영 구성 요소를 체계화하는 데 사용됩니다.
네트워크 분할 설명서
조직이 현재 네트워크 아키텍처를 문서화하지 않았고 참조할 수 없는 경우 솔루션을 계속하기 전에 이러한 설명서를 가능한 빨리 구해야 합니다. 문서화된 정보가 최신이 아니거나 최근에 유효성을 검증하지 않은 경우 두 가지 기본 옵션이 있습니다.
정보가 프로젝트에 큰 위험을 초래할 수 있음을 받아들입니다.
현재 네트워크 토폴로지를 문서화하는 데 필요한 정보를 제공할 수 있는 수동 프로세스를 통해 또는 네트워크 분석 도구를 사용하여 검색 프로젝트를 시작합니다.
필요한 정보는 여러 가지 방법으로 제공할 수 있지만 일련의 체계적인 다이어그램이 종종 현재 네트워크 구성을 표현하고 이해하는 데 가장 효과적인 방법입니다. 네트워크 다이어그램을 만들 때는 너무 많은 정보를 적지 않도록 하십시오. 필요할 경우 여러 계층의 세부 사항을 보여주는 다이어그램을 여러 개 사용하십시오.
예를 들어, Woodgrove 은행 시나리오에서 팀은 기존 WAN(Wide Area Network)과 사이트 환경을 자세히 보여주기 위해 다음과 같은 다이어그램을 만들었습니다.
그림 3.1 Woodgrove 은행 WAN 및 사이트 네트워크 다이어그램
팀은 이 다이어그램을 만든 후에 각 사이트에 대한 세부 다이어그램, 즉 각 사이트 내에 각 서브넷을 추가로 만들었습니다.
네트워크를 문서화하는 동안 IPsec과 호환되지 않는 일부 네트워크 응용 프로그램과 서비스를 발견할 수 있습니다. 이러한 비호환성의 최신 예는 다음과 같습니다.
라우터의 Cisco NetFlow는 프로토콜이나 포트를 기반으로 IPsec 구성원 간의 패킷을 분석할 수 없습니다.
라우터 기반 QoS(Quality of Service)는 포트나 프로토콜을 사용하여 트래픽 우선 순위를 지정할 수 없습니다. 그러나 특정 IP 주소를 사용하여 트래픽 우선 순위를 지정하는 것은 영향을 받지 않습니다. 예를 들어, "포트 80을 사용하여 누구에게서 누구에게로 우선 순위를 지정"한다는 규칙은 작동하지 않지만 "누구에게서 10.0.1.10으로 우선 순위를 지정"한다는 규칙은 영향을 받지 않습니다.
ESP(보안 페이로드 캡슐화)가 사용하는 포트인 IP 프로토콜 50을 지원하지 않는 장치.
가중치 공정 대기열 및 기타 흐름 기반 라우터 트래픽 우선 순위 지정 방법은 실패할 수 있습니다.
네트워크 모니터가 암호화되지 않은 ESP 패킷을 구문 분석하지 못할 수 있습니다(ESP-Null).
장치가 ESP를 구문 분석할 수 없는 경우 포트나 프로토콜 규칙을 지정하는 ACL이 ESP 패킷에서 처리되지 않습니다.
장치에 ESP 파서가 있고 암호화를 사용하는 경우 포트나 프로토콜 규칙을 지정하는 ACL이 ESP 패킷에서 처리되지 않습니다.
포트와 프로토콜을 사용하면 IPsec은 네트워크 기반 우선 순위 지정 및 포트/프로토콜 기반 트래픽 관리로 나뉩니다. 불행히도, 암호화된 패킷에 대한 해결 방법은 없습니다. 트래픽 관리나 우선 순위 지정을 포트 또는 프로토콜을 기반으로 해야 하는 경우 호스트 자체가 트래픽 관리나 우선 순위 지정 기능을 수행할 수 있어야 합니다.
다음에, 네트워크의 다양한 장치에 대해 어떤 정보가 필요한지를 정확히 기록하는 것이 중요합니다.
네트워크 인프라 장치
네트워크 인프라(라우터, 스위치, 로드 균형 조절기 및 방화벽)를 구성하는 장치는 솔루션을 구현한 후에 IPsec을 사용하여 통신합니다. 이런 이유로, 네트워크에 있는 이러한 장치의 다음 특성을 검토하여 설계의 기술적 및 물리적 요구 사항을 처리할 수 있도록 하는 것이 중요합니다.
제조업체/모델. 이 정보를 사용하여 장치가 지원하는 기능을 확인할 수 있습니다. 또한 장치에서 실행되는 BIOS 또는 소프트웨어를 검사하여 IPsec을 지원하는지 확인해야 합니다.
RAM 크기. 이 정보는 용량 또는 장치에 대한 IPsec의 영향을 확인할 때 유용할 수 있습니다.
트래픽 분석. 이 정보(최고 사용 및 매일 장치의 사용을 보여주는 매일/매주 추세)를 준비하는 것도 도움이 됩니다. IPsec과 관련한 정보는 장치의 스냅샷 및 일정 기간 동안 어떻게 사용되는지를 보여줍니다. IPsec을 구현한 후에 문제가 발생하는 경우 이 정보를 통해 원인이 장치를 많이 사용한 것과 관련이 있는지 여부를 확인할 수 있습니다.
IPsec에 직접 영향을 미치는 ACL. ACL은 특정 프로토콜이 작동하는 기능에 직접 영향을 줍니다. 예를 들어, Kerberos 프로토콜(UDP[User Datagram Protocol] 및 TCP 포트 88), 또는 IP 프로토콜(포트가 아니라 프로토콜) 50이나 51을 허용하지 않으면 IPsec이 작동하지 않습니다. NAT-T(Network Address Translation Traversal)를 사용하는 경우 장치는 IKE(인터넷 키 교환) 트래픽(UDP 500 및 4500)이 통과하도록 구성해야 합니다.
장치 인터페이스에 연결된 네트워크/서브넷. 이 정보는 내부 네트워크 상태에 대해 가능한 최상의 분석을 제공할 수 있습니다. 주소 범위를 기반으로 네트워크 경계를 정의하는 것은 매우 간단하며 다른 주소가 관리되지 않거나 내부 네트워크(예: 인터넷 주소)와 무관한지 식별할 수 있습니다. 이 정보는 이 가이드의 다음 장에서 IPsec 정책을 결정할 때 필요합니다.
장치가 NAT(Network Address Translation)를 수행하는지 여부. 네트워크 주소 변환은 전체 주소 범위를 네트워크 또는 인터넷에 연결된 단일 IP로 제공하는 데 주로 사용됩니다. 솔루션 계획자는 이 프로세스가 네트워크의 어느 곳에서 발생하고 있는지 알고 있어야 합니다.
VLAN 분할. VLAN이 현재 네트워크에 어떻게 구현되었는지 확인하면 현재 존재하는 트래픽 패턴이나 보안 요구 사항을 이해할 수 있을 뿐 아니라 IPsec이 이러한 요구 사항을 강화하는지 또는 충돌하는지 확인할 수 있습니다.
장치가 연결되는 링크. 이 정보는 장치가 어느 네트워크와 연결을 유지하고 있는지 보여줄 수 있습니다. 또한 특정 인터페이스에 있는 다양한 위치의 논리적 네트워크 및 연결을 식별할 수도 있습니다.
장치 인터페이스의 MTU(최대 전송 단위) 크기. MTU는 더 작은 전송 단위로 나누지 않고도 특정 인터페이스에서 전송할 수 있는 최대 데이터그램을 정의합니다. 이렇게 작은 전송 단위로 나누는 프로세스를 "조각화"라고도 합니다. IPsec 통신에서 MTU는 조각화가 발생할 영역을 확인해야 합니다. 라우터의 ISAKMP(Internet Security Association and Key Management Protocol)를 위해 패킷 조각화를 추적해야 합니다. IPsec은 세션의 MTU 크기를 사용되는 통신 경로를 따라 최소 검색된 MTU로 구성하고 DF 비트(단편화 안 함 비트)를 1로 설정합니다.
참고: 경로 PMTU(경로 MTU) 검색이 활성화되고 제대로 작동하는 경우 장치 인터페이스에서 MTU 크기를 수집할 필요가 없습니다. Windows Server 2003 강화 가이드 같은 일부 설명서는 PMTU 검색을 사용하지 않을 것을 권장합니다. 그러나 IPsec이 제대로 작동하려면 PMTU 검색을 사용해야 합니다.
또한 패킷 내부의 데이터를 해석하는 데 특정 파서가 필요하기 때문에 IPsec이 IDS(침입 탐지 시스템)에 영향을 줄 수 있음을 유의하십시오. IDS에 파서가 없을 경우 이러한 패킷에 있는 데이터를 검사하여 특정 세션이 위협 가능성이 있는지 확인할 수 없습니다. 이 경우 IPsec을 사용하기로 결정한다는 것은 조직에 IDS보다는 IPsec이 더 필요하다는 것을 나타냅니다.
이 절에서 제공하는 정보는 IPsec을 사용하도록 장치를 구성하거나, IPsec 트래픽을 통과하도록 이미 구성된 경우 추가 부담을 주기 전에 네트워크 인프라의 현재 구성과 "상태"를 이해하는 데 도움이 되기 때문에 프로젝트 성공에 중요합니다. 최고 사용 정보를 연구함으로써 장치가 현재 상태에서 IPsec을 사용할 수 있는지 또는 예상 로드를 지원하기 위해 메모리나 펌웨어를 업그레이드해야 할지 결정할 수 있습니다. 제조업체와 모델 정보는 필요할 경우 장치를 업그레이드하기 위해 하드웨어를 구입할 때 유용합니다. 해당 제조업체 및 모델과 관련된 기타 구성 매개 변수나 기능에 대한 정보도 도움이 될 수 있습니다. 장치에 구성된 ACL 수는 IPsec을 지원하도록 장치를 구성하는 데 필요한 노력을 예상할 수 있습니다. 네트워크에 IPsec 트래픽을 허용하도록 구성된 장치가 없고 네트워크에 라우터가 많이 있는 경우 장치를 구성하는 데 많은 노력이 필요할 수 있습니다.
이 정보를 얻은 후에 프로젝트의 요구 사항을 지원하도록 장치를 업그레이드할 필요가 있는지 신속하게 결정하고, ACL을 변경하거나, 다른 조치를 취하여 장치가 예상될 로드를 처리할 수 있을지 확인할 수 있습니다.
현재 네트워크 트래픽 모델 분석
주소 지정과 네트워크 인프라 정보를 수집한 후에 다음 논리적 단계는 통신 흐름을 신중하게 검토하는 것입니다. 예를 들어, HR(인사) 부서가 여러 건물에 걸쳐 있고 IPsec을 사용하여 해당 부서의 정보를 암호화하는 경우 연결에 사용할 "트러스트" 수준을 결정하려면 이러한 건물이 어떻게 연결되어 있는지 알아야 합니다. 매우 안전한 건물이 보호되어 있지 않은 다른 건물에 구리 케이블로 연결된 경우 도청이나 정보 재생 공격으로 손상될 수 있습니다. 이러한 공격이 위협이 되었다면 IPsec은 강력한 상호 인증과 트래픽 암호화를 제공하여 신뢰할 수 있는 호스트를 지원할 수 있습니다. 그러나 솔루션은 신뢰할 수 있는 호스트를 물리적으로 보안하지 않으면 계속 위협이 된다는 사실을 고려할 수 없습니다.
트래픽 흐름을 검토할 때 Windows 2000 SP4 이전 버전의 Windows 이외에 Linux, UNIX 및 Mac 같은 비Windows 기반 장치를 포함하여 관리되는 및 관리되지 않는 모든 장치가 어떻게 상호 작용하는지 면밀히 관찰하십시오. 스스로에게 다음과 같은 질문을 하십시오. 특정 통신이 포트/프로토콜 수준에서 발생하거나, 다양한 프로토콜에 걸쳐 같은 호스트 간에 많은 세션이 있는가? 서버와 클라이언트가 서로 어떻게 통신하는가? 구현되었거나 계획된 현재 보안 장치나 프로젝트가 격리 프로젝트에 영향을 미칠 수 있는가? 예를 들어, Windows XP SP2 및 Windows 방화벽을 사용하여 UDP 500 같은 특정 포트를 "잠그면" IKE 협상이 실패할 수 있습니다.
2장 "서버 및 도메인 격리 이해"에서 수행한 위협 모델링 프로세스를 사용하여 다른 종류의 네트워크 트래픽을 검토하면 신뢰할 수 없거나 관리되지 않는 장치로부터 보호해야 하는 트래픽을 생성하는 이러한 프로토콜과 응용 프로그램을 쉽게 찾을 수 있습니다. 몇 가지 더 일반적인 응용 프로그램과 프로토콜은 다음과 같습니다.
NetBT(NetBIOS over TCP/IP) 및 SMB(서버 메시지 블록). LAN에서는 NetBT에 대해 포트 137, 138 및 139가 활성화되고 SMB에 대해 포트 445가 활성화되는 것이 일반적입니다. 이러한 포트는 다른 기능 외에도 NetBIOS 이름 확인 서비스를 제공합니다. 불행히도, 널 세션으로 알려진 세션을 만드는 기능도 제공합니다. 널 세션은 알려진 사용자 또는 엔터티의 보안 컨텍스트를 사용하지 않는 호스트에 설정되는 세션입니다. 흔히 이러한 세션은 익명입니다.
RPC(원격 프로시저 호출). 일반적으로 RPC는 응용 프로그램에 수신 대기 포트(끝점 매퍼, TCP 포트 135라고도 함)를 제공하여 작동한 다음 "호출자"(종종 다른 응용 프로그램)가 수명이 짧은 범위의 다른 포트에서 통신을 시작하도록 알려줍니다. 방화벽으로 분리된 네트워크에서 이 RPC 통신은 RPC 수신기 포트와 1024 위의 모든 포트를 여는 것을 의미하기 때문에 구성 문제가 발생합니다. 너무 많은 포트를 열면 전체 네트워크의 공격 허점이 늘어나고 방화벽 효율성이 떨어집니다. 그러나 RPC의 장점은 개발자가 배포된 응용 프로그램을 위해 네트워크에 낮은 수준의 호출을 제공할 필요가 없도록 사용하는 응용 프로그램에 대한 OSI(Open Systems Interconnection) 모델의 1-4 계층에서 기능의 추상화를 제공한다는 것입니다. 많은 응용 프로그램이 기본 기능에 대해 RPC를 사용하기 때문에 RPC용 계정에 IPsec 정책이 필요합니다. IPsec 정책을 만드는 방법에 대한 자세한 내용은 5장 "격리 그룹을 위한 격리 정책 만들기"를 참조하십시오.
기타 트래픽. IPsec은 포함하고 있는 데이터 암호화 이외에 패킷 인증을 제공하여 호스트 간의 전송을 보호할 수 있습니다. 수행할 중요한 사항은 보호해야 하고 완화해야 하는 위협이 무엇인지 식별하는 것입니다. 보호해야 하는 기타 트래픽이나 트래픽 유형을 검토하고 그에 따라 모델링해야 합니다. 예를 들어, 일부 클라이언트만 액세스를 허용하는 특수 목적의 데이터베이스 또는 HR 관리자만 사용하는 HR 팀을 위한 특별한 응용 프로그램입니다.
물리적 및 논리적 네트워크를 문서화한 후에 다음 단계는 현재 트래픽 패턴을 검토하고 다음 질문에 답변하는 것입니다.
현재 특정 유형의 트래픽(예: Mac 워크스테이션과 UNIX 워크스테이션 또는 메인프레임과 터미널 연결)에 전용으로 사용되는 서브넷이 있습니까?
다른 유형의 트래픽 또는 위치 간의 트래픽을 구분해야 합니까?
Active Directory
정보 수집에서 네트워크 다음으로 가장 중요한 항목이 Active Directory입니다. 도메인 레이아웃, OU(조직 구성 단위) 구조 및 사이트 토폴로지를 포함하여 포리스트 구조를 이해해야 합니다. 이 정보를 통해 현재 컴퓨터가 있는 위치, 해당 구성 및 IPsec 구현 결과에 따라 Active Directory를 변경할 때의 영향을 알 수 있습니다. 다음 목록은 이러한 검색 노력을 완료하는 데 필요한 정보를 설명합니다.
포리스트 개수. 포리스트는 Active Directory 구현의 보안 경계에 있기 때문에 어떤 호스트를 격리해야 하며 해당 격리를 수행하는 방법을 결정하려면 현재 Active Directory 아키텍처를 이해하고 있어야 합니다.
도메인 이름 및 개수. IPsec 인증은 IKE 협상 프로세스의 결과로 발생합니다. 이 솔루션에서 인증 방법은 Kerberos 프로토콜입니다. 이 프로토콜은 컴퓨터가 도메인에 가입되었으며 운영 체제 버전 전제 조건(Windows 2000, Windows XP 또는 Windows Server 2003)을 충족시킨다고 가정합니다.
트러스트 개수 및 유형. 트러스트는 격리의 논리적 경계에 영향을 주고 솔루션에서 IKE 인증이 발생할 수 있거나 발생하는 방법도 정의하기 때문에 트러스트 개수 및 유형을 캡처하는 것이 중요합니다.
사이트 이름 및 개수. 사이트 아키텍처는 대개 네트워크 토폴로지에 맞게 조정됩니다. Active Directory에서 사이트를 정의하는 방법을 이해하면 복제 및 다른 세부 사항에 대해서도 알 수 있습니다. 이 솔루션의 경우 사이트 아키텍처를 보면 현재 존재하는 Active Directory 구현을 충분히 이해할 수 있습니다.
OU 구조. OU 구조를 만들 때 적은 계획으로 상당한 운용 효율을 얻을 수 있습니다. OU는 논리적 구조이므로 다른 많은 요구 사항과 목적에 맞게 만들 수 있습니다. OU 구조는 현재 그룹 정책이 어떻게 사용되며 OU가 어떻게 배치되는지 검토하는 이상적인 방법입니다. 이 솔루션의 4장과 5장에서는 OU 아키텍처를 설명하고 이 아키텍처를 사용하여 IPsec 정책을 적용하는 방법을 자세히 설명합니다.
기존 IPsec 정책 사용. 이 프로젝트는 IPsec 정책 구현에 누적되므로 네트워크가 현재 IPsec을 어떻게 사용하는지 이해하는 것이 매우 중요합니다. 간단한 IPsec 필터(예: 강화 가이드에서 지정된 필터)를 사용하거나 전체 정책을 구현하거나 간에 현재 사용과 요구 사항을 이해하면 이 솔루션과 원활하게 통합됩니다.
Woodgrove 은행 시나리오는 5가 사이트에 퍼져 있는 4개의 도메인이 포함된 단일 포리스트(corp.woodgrovebank.com)를 사용합니다. 각 사이트는 다음 표에 나타난 것처럼 도메인 컨트롤러(DC), 주 도메인 컨트롤러(PDC) 또는 글로벌 카탈로그(GC) 서버를 포함할 수 있습니다.
Woodgrove 은행 Active Directory 설계는 포리스트에 의해 자동으로 만들어진 양방향 트러스트 관계를 사용했습니다. 추가 교차 포리스트나 외부 트러스트는 없었습니다.
다음 그림은 Woodgrove 은행이 사용한 상위 수준 OU 구조의 예를 보여줍니다. 이 구조는 *미주*, *유럽* 및 *아시아*의 세 기본 지역 도메인에서 일관성 있게 사용되었습니다
[.gif)](https://technet.microsoft.com/ko-kr/dd547886.sgfg0302_big(ko-kr,technet.10).gif)
**그림 3.2 Woodgrove 은행 OU 구조 예**
서버와 도메인 격리 프로젝트는 Woodgrove 은행의 첫 번째 IPsec 구현이었기 때문에 기존의 활성 IPsec 정책은 없었습니다.
#### 호스트 검색
자산 검색 프로젝트를 수행하는 가장 중요한 이점은 네트워크에서 호스트(워크스테이션 및 서버)에 대해 얻는 다량의 데이터입니다. 4장 "격리 그룹 설계 및 계획"에서는 모든 호스트가 설계의 IPsec 통신에 참가할 수 있도록 모든 호스트 상태에 대한 정확한 정보가 요구되는 결정을 내리게 됩니다.
##### 호스트 데이터 요구 사항
이 절에서는 필요한 호스트 정보를 설명하고 이 정보를 물리적으로 논리적으로 표현하는 방법을 설명합니다.
- **컴퓨터 이름**. 이 이름은 네트워크에서 컴퓨터를 식별하는 컴퓨터의 NetBIOS 또는 DNS 이름입니다. 컴퓨터는 MAC(미디어 액세스 제어) 및/또는 IP 주소를 둘 이상 가질 수 있기 때문에 컴퓨터 이름은 네트워크에서 고유성을 확인하는 데 사용할 수 있는 기준의 하나입니다. 일부 상황에서는 컴퓨터 이름이 중복될 수 있으므로 고유성을 절대적으로 간주해서는 안 됩니다.
- **각 NIC(네트워크 인터페이스 카드)용 IP 주소**. IP 주소는 네트워크에서 호스트를 식별하기 위해 서브넷 마스크에 사용되는 주소입니다. IP 주소는 자주 변경되기 때문에 자산을 식별하는 효과적인 방법이 아니라는 것에 유의해야 합니다.
- **각 NIC용 MAC 주소**. MAC 주소는 네트워크 인터페이스를 식별하는 데 사용되는 고유한 48비트 주소입니다. 같은 장치에서 여러 네트워크 인터페이스를 구분하는 데 사용할 수 있습니다.
- **운영 체제, 서비스 팩 및 핫픽스 버전**. 운영 체제 버전은 IPsec과 통신하는 호스트의 기능을 확인하는 중요한 요소입니다. 또한 설치된 서비스 팩과 핫픽스의 현재 상태는 최소 보안 표준이 충족되었는지 확인하는 데 사용되므로 이를 추적하는 것도 중요합니다.
- **도메인 구성원**. 이 정보는 컴퓨터가 Active Directory로부터 IPsec 정책을 얻을 수 있는지 여부 또는 로컬 IPsec 정책을 사용해야 하는지 여부를 결정하는 데 사용됩니다.
- **물리적 위치**. 이 정보는 단순히 조직에서 장치의 위치를 나타냅니다. 정기적으로 통신하는 장치의 위치를 기반으로 장치가 특정 격리 그룹에 참가해야 하는지 여부를 결정하는 데 사용할 수 있습니다.
- **하드웨어 종류/역할**. 자동화된 프로세스로는 이 정보를 수집하지 못할 수 있습니다. 호스트 검색을 수행하는 일부 도구는 하드웨어 정보를 쿼리하고 응용 프로그램을 실행하여 서버, 워크스테이션 또는 Tablet PC 같은 종류를 확인함으로써 이 정보를 제공할 수 있습니다. 이 정보를 사용하여 격리에 참가할 특정 컴퓨터의 자격 및 어떤 격리 그룹을 컴퓨터에 배치할지 결정할 수 있습니다.
**참고:** 하드웨어 종류 정보는 데이터 삽입 또는 쿼리를 수행하여 이 정보를 제공하는 소프트웨어 제품에서 얻어집니다. 예를 들어, HP Evo n800이 이동 컴퓨터라는 것은 잘 알려져 있으며 하드웨어 수준에 쿼리할 수 있거나 이것을 식별하는 자산 태그가 있는 경우 장치에 할당할 적절한 IPsec 정책을 쉽게 결정할 수 있습니다.
이 모든 정보를 수집하고 데이터베이스에 통합한 후에는 정기적인 간격으로 검색 노력을 수행하여 정보를 최신 상태로 유지하십시오. 조직의 요구 사항에 맞는 설계를 만들려면 네트워크에서 가장 완벽한 최신의 관리되는 호스트가 필요합니다.
다양한 방법을 사용하여 네트워크의 호스트에서 데이터를 수집할 수 있습니다. 이러한 방법은 고급의 완벽하게 자동화된 시스템부터 완전 수동 데이터 수집까지 다양합니다. 일반적으로 수동 방법보다는 자동화된 방법을 사용하여 데이터를 수집하는 것이 속도와 정확성 측면에서 좋습니다. 그러나 어떤 방법을 사용하든 필요한 정보는 동일하며 정보를 얻는 데 소비되는 시간만이 다릅니다. 수동 프로세스에 발생하는 일반적인 문제는 정보가 중복되고, 노력의 범위가 정확한지 확인하고(예: 모든 네트워크를 검색하고 호스트 정보를 캡처했는지 여부 또는 클라이언트 서브넷), 프로젝트에 유용한 방식으로 시기 적절하게 정보를 얻어야 한다는 것입니다. 전체 IT 시스템 감사의 모든 요소에 대한 설명은 이 프로젝트의 범위를 벗어 납니다. 그러나 이 솔루션의 요구를 벗어나 여러 가지 이유로 이 감사 정보를 조직이 사용할 수 있어야 한다는 것을 이해하는 것이 중요합니다. 자산 추적과 보안 위험 관리는 정확한 최신 시스템 인벤토리를 필요로 하는 프로세서의 두 가지 중요한 예입니다.
##### 자동화된 검색
SMS 같은 자동화된 감사 네트워크 관리 시스템을 사용하면 IT 인프라의 최신 상태에 대해 훨씬 유용한 정보를 얻을 수 있습니다. 그러나 자동화된 시스템의 한 가지 문제는 오프라인이거나, 플러그가 뽑혀 있거나, 정보 쿼리에 물리적으로(또는 논리적으로) 쿼리에 응답할 수 없는 호스트는 최종 데이터베이스에 나타나지 않는다는 것입니다. 대부분의 자동화된 시스템조차 호스트가 올바르게 액세스하고 고려할 수 있도록 하려면 수동 관리 요소가 필요합니다.
다양한 공급업체의 많은 제품과 도구를 사용할 수 있습니다. 일부 방법은 중앙 검색 메커니즘을 사용하며 일부는 클라이언트 컴퓨터에 설치된 에이전트를 사용합니다. 제품을 비교하거나 구입할 제품을 추천하는 것은 이 가이드의 범위를 벗어나지만 솔루션은 이 장에서 강조한 검색 데이터를 4장과 5장에서 설명하는 설계 고려 사항에 대해 제공할 것을 요구합니다.
SMS 2003이 자산 관리를 수행하거나 이 프로젝트가 요구하는 정보를 수집하는 방법에 대한 자세한 내용은 [SMS 2003 자산 관리](https://www.microsoft.com/korea/smserver/evaluation/capabilities/asset.asp) 페이지(www.microsoft.com/korea/smserver/evaluation/
capabilities/asset.asp)의 데모와 자산 관리를 참조하십시오.
##### 수동 검색
수동 검색 방법과 자동 방법 사이의 가장 큰 차이점은 시간입니다. 이 프로젝트에 필요한 정보를 수동으로 수집하려면 여러 명이 작업하여 몇 일에서 몇 주가 걸릴 수 있으며 기업 크기가 클 수록 더 오래 걸립니다. 수동 방법을 사용하여 인프라의 현재 상태를 감사하는 계획을 수립하는 경우 얻어진 정보를 스프레드시트나 데이터베이스 같은 전자적 형식으로 사용할 수 있도록 하는 것이 중요합니다. 필요한 정보를 반환하는 특정 쿼리를 신속하고 정확하게 생성할 수 없는 경우 생성할 수 있는 데이터 양이 많으면 필터링과 분석 프로세스가 매우 어려워질 수 있습니다. 또한 로컬 IT 관리자를 사용하여 정보를 얻거나 이전에 수집한 정보의 유효성을 검증할 수 있습니다.
조직에 자동화된 감사 도구가 없을 경우에도 Windows 플랫폼에 사용할 수 있는 표준 원격 관리 및 스크립팅 인터페이스를 사용하여 얻을 수 있는 자동화 요소도 있습니다. 이러한 도구를 사용할 때의 주요 문제점은 관리 도구나 스크립트와 호환되지 않기 때문에 클라이언트가 빠지지 않도록 보장하는 것입니다.
Windows Scripting Host(WSH), Microsoft Visual Basic® Scripting Edition(VBScript) 및 Windows Management Instrumentation(WMI)를 사용하여 시스템 구성 정보를 수집할 수 있는 스크립트 파일을 만들 수 있습니다. 다음 표는 플랫폼별로 VBScript 및 WMI의 가용성을 보여줍니다.
**표 3.2: 플랫폼별 VBScript 및 WMI 가용성**
플랫폼
VBScript
WMI
Windows 95
WSH 5.6 설치
WMI CORE 1.5 설치
Windows 98
기본 제공
WMI CORE 1.5 설치
Windows Millennium
기본 제공
기본 제공
Microsoft Windows NT® 버전 4.0
WSH 5.6 설치
WMI CORE 1.5 설치
Windows 2000
기본 제공
기본 제공
Windows XP
기본 제공
기본 제공
Windows Server 2003
기본 제공
기본 제공
**참고:** Microsoft Windows Script 5.6 업데이트는 [Microsoft Windows Script Downloads](https://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp) 페이지(https://msdn.microsoft.com/library/default.asp?url=/
downloads/list/webdev.asp)에서 다운로드할 수 있습니다.
Microsoft 다운로드 센터(www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875&DisplayLang=en)에서 [Windows Management Instrumentation(WMI) CORE 1.5](https://www.microsoft.com/download/details.aspx?familyid=afe41f46-e213-4cbf-9c5b-fbf236e0e875&displaylang=ko) 설치 파일을 다운로드할 수 있습니다.
**Discovery.vbs**라고 하는 예제 VBScript는 이 솔루션의 Tools and Templates 폴더에 제공됩니다. 이 스크립트는 WMI를 사용하여 역할과 물리적 위치를 제외하고 이 장의 "호스트 데이터 요구 사항" 절에 나열한 모든 정보를 검색합니다. 정보는 로컬 컴퓨터의 텍스트 파일 **C:\\Discovery\\<*systemname*>\_info.txt**에 수집됩니다. 스크립트를 수정하여 추가 정보를 수집하거나 원격 파일 공유에 수집된 정보를 저장할 수 있습니다.
WMI 또는 VBScript를 호스트 컴퓨터에서 사용할 수 없는 경우 배치 스크립트와 외부 도구를 사용하여 일부 정보를 수집할 수 있습니다. 문제는 배치 언어의 기능이 매우 제한적이며 이전 버전 Windows의 명령줄에서는 구성 정보를 얻기 힘들다는 점입니다.
호스트 검색을 수행하려면 호스트를 쿼리하고 이러한 쿼리 결과를 저장할 위치를 제공해야 합니다.
정보 수집에 자동, 수동 또는 혼합 옵션을 사용하는지 여부에 관계 없이 설계에 문제를 일으킬 수 있는 가장 큰 문제점 중 하나는 원본 인벤토리 검색과 구현을 시작할 지점 사이의 변경을 캡처하는 것입니다. 첫 번째 검색을 완료한 후에 모든 추가 변경을 기록하고 인벤토리에 업데이트를 기록해야 한다는 것을 지원 직원이 알 수 있도록 해야 합니다.
다음 장에서 설명할 IPsec 정책 계획과 구현에 이 인벤토리는 중요합니다.
[](#mainsection)[페이지 위쪽](#mainsection)
### 용량 고려 사항
정보 수집을 완료한 후 몇 가지 용량 계획을 포함한 IPsec의 영향이 중점을 둘 다음 영역입니다. 이 절에서는 사용자 환경에서 IPsec을 적절히 계획하는 데 필요한 몇 가지 사항을 설명합니다.
#### IPsec의 영향
IPsec은 다양한 암호화 기술을 사용하기 때문에 컴퓨터에 상당한 오버헤드를 줄 수 있습니다. 보다 세밀한 분석을 요구하는 시나리오는 암호화를 요구하는 시나리오입니다. 예를 들어, 3DES(Triple Data Encryption Standard) 및 SHA-1(Secure Hash Algorithm 1)을 사용하여 가장 강력한 암호화와 키 교환 보호를 요구하는 환경에서 무결성을 검사할 수 있습니다. 또 다른 시나리오는 보안 연결(SA) 협상을 포함합니다. 주 모드 SA에 대해 더 짧은 수명(예: 3시간)을 사용할 수 있지만 여러 보안 고려 사항에서와 마찬가지로 타협점이 있습니다. 각 주 모드 SA는 약 5KB RAM을 차지합니다. 서버가 수 많은 동시 연결을 차단하는 것을 기대하는 상황은 서버에 큰 부담을 줄 수 있습니다. 다른 요소로는 네트워크 인프라 서버에서 CPU 활용, IPsec을 실행하는 서버 및 워크스테이션에서 오버헤드 증가(대개의 경우 서버는 클라이언트보다 더 많은 주 모드 SA를 포함하고 있기 때문에 특히 서버) 및 IPsec 협상의 결과로 증가된 네트워크 대기 시간 등이 있습니다.
**참고:** Microsoft이 이 솔루션을 자체 배포한 결과 IPsec 사용의 직접적인 결과로 네트워크 이용이 1~3% 증가하는 것으로 밝혀졌습니다.
또 다른 주요한 관심사는 이들 사이의 NAT 장치와 연결된 네트워크입니다. 문제는 NAT는 AH가 헤더를 포함하여 변경되지 않은 패킷의 인증을 제공하도록 설계되었다는 원칙을 위반하기 때문에 NAT가 호스트 사이에서 AH(Authentication Header) 대화를 허용하지 않는다는 점입니다. NAT 장치가 내부 네트워크에 존재하는 경우 AH 대신 ESP를 선택해야 합니다. ESP는 데이터를 암호화하는 기능을 제공하지만 암호화를 요구하지는 않습니다. 이 요소는 암호화가 프로젝트의 계획 및 설계 단계에서 고려해야 하는 오버헤드를 갖고 있기 때문에 용량 고려 사항의 관점에서 중요합니다. 또한 ESP는 NAT와의 통신을 차단하지 않고 가능한 가장 강력한 IPsec 피어-투-피어 통신을 제공하는 널 암호화를 사용하여 구현할 수도 있습니다. 그리고 암호화를 사용하지 않기 때문에 암호화를 사용하는 ESP보다는 영향이 줄어듭니다.
#### 정책의 영향
IPsec 정책 및 그룹 정책은 컴퓨터 시작 시간 뿐만 아니라 사용자가 로그온할 때 걸리는 시간에 모두 영향을 줍니다. 정보 수집 단계에 있는 동안 솔루션을 구현하기 전에 컴퓨터 시작 시간과 사용자의 로그온 시간을 기록해 두는 것이 유용합니다. 여기에서 이러한 시간을 기록해 두면 시험 단계 동안 테스트 시스템을 비교하여 사용자가 로그온하는 데 걸릴 전체 시간에 미치는 영향을 확인할 수 있는 기준을 제공할 것입니다.
[](#mainsection)[페이지 위쪽](#mainsection)
### 배포 전 관심사
앞 절에서는 성공적인 격리 노력에 도움을 주는 네트워크, Active Directory 및 호스트에서 수집해야 하는 정보를 설명했습니다. 이 절은 IPsec을 배포하기 전에 면밀하게 조사해야 하는 관심 영역을 나열합니다.
#### 네트워크 인프라
정보 수집을 통해 네트워크에서 IPsec 격리를 위한 계획을 수립할 수 있습니다. 이 정보를 수립한 후에 데이터를 신중하게 분석하면 시험 및 배포 동안 발생할 문제 대부분이 드러날 것입니다. 다음 항목은 포괄적인 목록에 포함되지는 않지만 테스트와 배포 전에 수집된 정보 분석을 시작할 때 고려하는 것이 중요합니다.
##### 남용되는 장치
사용량이 75%를 초과하는 스위치 또는 라우터는 장치에 증가된 트래픽을 허용하고 많은 트래픽에 대해 몇 가지 추가 활용도 제공하도록 업그레이드하거나 다시 구성해야 할 수 있습니다. IPsec 구현을 위한 적절한 용량 계획에서는 테스트에 대한 자세한 내용과 정확한 계산보다 예상하는 트래픽 로드를 고려합니다. 두 고객의 시나리오, 트래픽 패턴, 사용자 집중 및 응용 프로그램이 정확하게 일치할 가능성은 거의 없기 때문에 네트워크 장치가 어떤 영향을 미칠지에 대해 적절히 계획하고 고려하는 것은 필수적입니다. 예를 들어, IPsec의 특정 측면은 완벽하게 예측할 수 있습니다. ESP와 함께 IPsec을 사용하는 각 패킷은 IPsec을 사용하지 않는 같은 패킷보다 정확히 36바이트 큽니다. 단일의 주 모드 SA를 설정하는 데 필요한 메시지가 6개 있기 때문에 특정 장치에서 사용이 어떤 영향을 미치는지 고려하는 것이 더욱 쉽습니다. [Quallaby](https://www.quallaby.com/)(www.quallaby.com)의 PROVISO 응용 프로그램 같은 도구나 다른 네트워크 분석기 솔루션을 사용하여 IT 환경에서 IPsec을 위한 용량 계획을 지원할 수 있습니다.
##### 호환되지 않는 장치
IPsec과 호환되지 않는 장치는 IPsec 통신에 참가할 수 없습니다. 이런 장치가 관리되는 장치와 통신해야 하는 경우 IPsec 예외 목록에 두어야 합니다. 한 가지 대안은 IPsec을 지원하도록 장치 하드웨어나 소프트웨어를 업그레이드하는 것입니다. 또 다른 대안은 아웃바운드 통신에 대해 선택 취소할 때 관리되지 않는 장치가 경계 컴퓨터와 통신하도록 허용하는 것입니다.
##### 잘못 구성된 장치
잘못 구성된 장치는 장치에서 통신 실패와 로드 증가 가능성을 높일 수 있으며 장치를 손상시킬 수도 있습니다. 장치 구성, 관리 및 보안을 위한 최적의 방법을 따르면 이 문제를 완화할 수 있습니다.
##### IP 주소 지정
IP £££££¼소는 IPsec 솔루션의 기본 구성 요소이기 때문에 가능한 "정리"되도록 주소 지정하는 것이 중요합니다. 겹치는 주소 공간, 중복 주소, 잘못된 서브넷 마스크 및 기타 문제와 같은 사항은 정상적인 네트워크 작업을 복잡하게 만들 수 있습니다. 이런 네트워크에 IPsec을 추가하면 문제 해결만 복잡하게 하고 사람들이 IPsec을 문제의 원인으로 의심하게 됩니다. 조직 성장, 합병과 인수 및 기타 요소는 빨리 오래되고 네트워크의 IP 주소 지정이 정확하지 않을 수 있습니다. IPsec의 가장 큰 문제를 제거하려면 네트워크가 겹쳐지지 않는 서브넷으로 나뉘는지, 경로 테이블이 잘 요약되는지, 주소 집계가 쉽게 결정되는지 확인하십시오.
#### Active Directory 정보
현재 Active Directory 구현이 제대로 작동하는 경우(예: 이름 확인, DHCP\[Dynamic Host Configuration Protocol\], 그룹 정책의 응용 프로그램, 트러스트 관계 등), IPsec에는 아무런 영향이 없습니다. 호환성 문제가 발생하지 않도록 Active Directory를 검토할 때와 격리 프로젝트를 시작할 때 사이의 변경 내용을 조사해야 합니다.
#### 호스트 정보
앞 절?€ 네트워?¬의 호스트에 대한 충분한 정보 수집에 도움을 주었습니다. IPsec을 사용할 수 있는 클라이언트와 서버를 확인한 후에 어떻게 격리해야 하며 격리 솔루션이 미칠 수 있는 영향을 세밀하게 검사해야 하는 응용 프로그램은 어떤 것인지 적어 두십시오.
##### 클라이언트/서버 참여 결정
호스트에 대한 정보를 수집한 후에는 어떤 호스트를 격리 솔루션에 통합할 수 있는지 확인하는 것이 비교적 간단합니다. 예를 들어, Windows 2000, Windows Server 2003 및 Windows XP 기반 컴퓨터는 IPsec과 통신할 수 있습니다. 그러나 참가할 수 있는 모든 클라이언트가 이렇게 해야 하는 것은 아닙니다. 설계 프로세스의 중요한 부분은 이 장에서 수집한 정보를 바탕으로 어떤 컴퓨터와 장치를 솔루션에 포함할 것이며 어떤 그룹을 상주시킬 것인지 결정하는 것입니다.
##### 격리해야 하는 서비스 결정
서버와 도메인 격리 프로젝트의 컨텍스트에서 서비스는 네트워크의 클라이언트에 서비스를 제공하는 Microsoft Exchange Server, Microsoft SQL Server™ 또는 Internet Information Services(IIS) 같은 응용 프로그램입니다. 이러한 서비스를 평가하여 서버 및 도메인 격리의 후보자인지 확인해야 합니다. 이러한 서비스를 솔루션에 포함시켜야 하는 이유는 조직 정책, 정부 규정 또는 다른 비즈니스 요구 사항 등 많습니다. 예를 들어, 메일 서버 사이의 모든 통신을 IPsec을 사용하여 보호해야 하지만 클라이언트와 서버 사이의 통신은 이 방식으로 보호할 필요가 없다는 것을 명시하는 조직 정책이 있을 수 있습니다. 4장 "격리 그룹 설계 및 계획"에서는 격리 프로세스를 자세히 설명합니다. 서비스 격리를 시도할 때 웹 서비스와 FTP(파일 전송 프로토콜)를 제공하는 파일 서버 같은 여러 서비스를 운영하고 메일 서비이기도 한 이러한 서버를 신중히 고려하십시오.
##### 네트워크 로드 균형 조정 및 클러스터링
서버와 도메인 격리를 사용하는 조직은 NLB(네트워크 로드 균형 조정) 및 클러스터링을 사용하는 컴퓨터를 제외하도록 선택할 수 있습니다. IPsec이 다른 컴퓨터가 같은 클라이언트 연결을 사용하지 못하도록 하기 때문에 IPsec은 "유사성 없는" 모드에서는 NLB와 호환되지 않습니다. 이 비호환성으로 인해 "유사성 없는" 모드에서는 IPsec과 함께 NLB를 사용해서는 안 됩니다.
##### 예외 관리
예외 관리는 IPsec 계획의 중요한 부분입니다. 신뢰할 수 없는 호스트의 액세스를 허용할 컴퓨터를 사용하는 곳을 결정하고 관리되는 컴퓨터와 관리되지 않는 컴퓨터 사이의 액세스를 제어하는 것은 격리의 중요한 요소입니다. 이것은 예외 수를 가능한 최소한으로 유지하는 최선의 방법으로 간주되고 있습니다. 기술적 요구는 도메인 컨트롤러와 DHCP, DNS 및 WINS 서버 같은 일부 컴퓨터나 서비스가 IPsec으로부터 면제된다고 명시할 수 있습니다. 이러한 컴퓨터는 계속 관리해야 하기 때문에 관리되지 않는 컴퓨터를 관리되고 신뢰하는 컴퓨터와 통신하도록 허용하는 것보다 잠재 위험이 줄어듭니다.
##### 비 Windows 기반 장치
대부분의 기업 네트워크는 동일하지 않습니다. IPsec 배포를 계획할 때는 운영 체제, 네트워크 인프라 및 하드웨어 플랫폼 같은 요소의 다양성을 고려해야만 합니다. 조직에 비 Windows 기반 컴퓨터가 있는 경우 Windows 영역 외부에서 IPsec 정책을 사용하는 것이 현재 가능하지 않다는 것을 이해해야 합니다. 조직은 일부 플랫폼을 신뢰할 수 있는 것으로 취급하여 이 제한을 해결하기로 결정할 수 있지만 이러한 플랫폼은 IPsec 정책을 사용할 수 없기 때문에 서버와 도메인 격리 솔루션은 이를 보호하지 못합니다. 다음 절에서는 트러스트를 확인하는 방법을 설명합니다.
##### 장치 관리 및 모니터링
초기 계획 동안 종종 간과되는 IPsec의 한 가지 측면은 네트워크의 트래픽 관리와 모니터링에 대한 영향입니다. IPsec은 인증을 요구하며 암호화를 허용할 수 있기 때문에 일부 장치는 IPsec을 사용하는 컴퓨터를 더 이상 모니터링하거나 관리할 수 없게 됩니다. 암호화가 요구되는 경우 조직은 네트워크에서 전송되는 데이터를 모니터링하는 데 필요한 작업보다 보안이 더 중요하다는 것을 주장하는 것입니다. 다른 경우에는 응용 프로그램이나 장치가 IPsec을 모니터링(예: ESP 트래픽을 확인할 수 있는 ESP 파서)하도록 변경할 수 있는지 평가해야 합니다. 모니터링이나 관리 장치가 IPsec을 지원하도록 업그레이드할 수 없는 경우 이 정보를 기록하는 것이 중요합니다. 솔루션 설계자 또는 아키텍처 팀은 4장 "격리 그룹 설계 및 계획"에서 이 정보를 사용해야 합니다
[](#mainsection)[페이지 위쪽](#mainsection)
### 트러스트 확인
현재 IT 인프라의 일부인 호스트 장치에 대한 정보를 얻은 후에 솔루션에 참가하는 호스트의 기능에 직접 영향을 미치는지 기본적으로 확인해야 합니다. 이 확인은 호스트가 어떤 점에서 신뢰되는 것으로 간주할 수 있는지 결정하는 것입니다. *신뢰*라는 용어는 사람마다 다른 의미가 될 수 있으므로 프로젝트의 모든 관계자와 논의하여 확실한 정의를 내리는 것이 중요합니다. 이렇게 하지 않으면 전체 보안이 신뢰할 수 있는 상태를 달성하도록 허용된 최소 보안 클라이언트에 의해 설정된 보안 수준을 초과할 수 없기 때문에 신뢰할 수 있는 환경 보안에 문제가 발생할 수 있습니다.
이 개념을 이해하려면 일반적인 IT 인프라에서 호스트에 적용되는 4가지 기본 상태를 고려하십시오. 가장 낮은 위험 먼저, 위험순으로 나열하면 이러한 상태는 다음과 같습니다.
1. 신뢰할 수 있음
2. 신뢰할만 함
3. 알려져 있음, 신뢰할 수 없음
4. 알려져 있지 않음, 신뢰할 수 없음
이 섹션의 나머지 부분은 이러한 상태 및 조직의 어떤 호스트가 어떤 상태에 속하는지 결정하는 방법을 정의합니다.
#### 신뢰할 수 있는 상태
호스트를가 신뢰할 수 있는 호스트로 분류되었다고 호스트가 완벽하게 안전하거나 취약하지 않다는 것을 의미하지는 않습니다. 기본적으로 신뢰할 수 있다는 것은 호스트의 보안 위험이 관리되는 것을 의미합니다. 이 관리되는 상태의 책임은 호스트의 구성을 담당하는 IT 관리자와 사용자에게 있습니다. 신뢰할 수 있는 호스트를 적절히 관리하지 않으면 전체 솔루션의 취약점이 될 가능성이 있습니다.
호스트가 신뢰할 수 있는 것으로 간주되면 다른 신뢰할 수 있는 호스트는 호스트가 악의적인 동작을 시작하지 않을 것이라고 가정할 수 있습니다. 예를 들어, 모든 신뢰할 수 있는 호스트는 바이러스 위협을 완화하는 메커니즘(예: 바이러스 백신 소프트웨어)을 사용하도록 요구하기 때문에 신뢰할 수 있는 호스트는 다른 신뢰할 수 있는 호스트가 자신을 공격하는 바이러스를 실행하지 않을 것으로 기대합니다.
네트워크 인프라가 신뢰할 수 있는 호스트 사이의 통신을 방해해서는 안 됩니다. 예를 들어, 신뢰할 수 있는 호스트는 다른 신뢰할 수 있는 호스트에 악의적인 의도가 없다고 가정할 수 있기 때문에 일반적으로 다른 신뢰할 수 있는 호스트의 액세스를 제한하기 위해 IP 수준 패킷을 차단할 필요는 없습니다. IPsec을 사용하지 않고 컴퓨터 자체의 호스트 기반 방화벽을 사용하여 포트 또는 프로토콜별로 호스트 통신을 제어하는 데 필요한 제한을 구현해야 합니다.
Woodgrove 은행 시나리오에서 보안 팀은 호스트가 신뢰할 수 있는 상태를 얻는 데 필요한 기술을 계획하는 데 사용한 다음과 같은 5가지 주요 목표를 정의했습니다.
- 컴퓨터 또는 사용자 ID가 손상되지 않았습니다.
- 관리되는 환경의 어느 위치에 있는지 관계 없이 필요한 리소스가 안전하고 사용 가능합니다.
- *안전*한 것으로 지정된 리소스는 무단 변경되지 않고, 바이러스가 없으며 무단 액세스가 방지됩니다.
- *사용 가능*으로 지정된 리소스는 약속된 수준의 작동 시간을 충족하거나 초과하며 보안 취약점이 없습니다.
- *관리됨*으로 지정된 환경에는 Windows 2000 SP4 이상을 실행하고 있고 적절히 구성되고 패치가 적용된 컴퓨터가 있습니다.
- 데이터와 통신은 개인적이므로 의도한 받는 사람만 정보를 읽고 사용합니다.
- 장치 소유자/운영자는 환경이 신뢰하는 수준을 유지하기 위한 정책과 절차를 이해하고 준수합니다.
- 위험과 위협에 시기 적절하게 대응합니다.
Woodgrove 은행의 지원 팀은 호스트가 신뢰할 수 있는 호스트로 간주될 수 있는지 확인하기 위한 기술적 요구 사항 집합을 정의하는 데 이러한 목표를 사용했습니다.
신뢰할 수 있는 상태를 정의할 때 자산 소유자는 특정 자산의 업무 요구를 충족시키기 위해 추가 보안 요구 사항을 부과하지 않도록 합니다. 예를 들어, HR 부서는 특정 서버에 대해 추가 생체인식 로그온 메커니즘을 요구할 수 있습니다. 이 요구 사항은 이 솔루션의 컨텍스트에서 신뢰받는 서버의 기능과는 관계가 없습니다. 그러나 특정 자산의 요구 사항은 신뢰할 수 있는 상태의 요구 사항과 충돌하지 않도록 주의해야 합니다.
조직은 호스트의 최소 구성이 신뢰할 수 있는 상태를 얻는 데 적절한지 고려하는 목표 및 기술 요구 사항을 정의할 시간을 할애하십시오.
예를 들어, 설계 팀은 Woodgrove 은행 시나리오에서 기술 요구 사항의 다음 목록을 사용했습니다.
- **운영 체제**. 신뢰할 수 있는 호스트는 Windows XP SP2 or Windows Server 2003 또는 최소한 Windows 2000 SP4를 실행해야 합니다.
- **도메인 구성원**. 신뢰할 수 있는 호스트는 관리되는 도메인에 속합니다. 즉 IT 부서는 보안 관리 권한이 필요합니다.
- **관리 클라이언트**. 모든 신뢰할 수 있는 호스트는 보안 정책, 구성 및 소프트웨어의 중앙 관리와 제어에 사용되는 특정 네트워크 관리 클라이언트를 실행해야 합니다.
- **바이러스 백신 소프트웨어**. 모든 신뢰할 수 있는 클라이언트는 매일 최신 바이러스 서명 파일을 검사하고 자동으로 업데이트하도록 구성된 바이러스 백신 소프트웨어를 실행합니다.
- **파일 시스템**. 모든 신뢰할 수 있는 호스트는 NTFS 파일 시스템으로 구성됩니다.
- **BIOS 설정**. 모든 신뢰할 수 있는 이동 컴퓨터는 IT 지원 팀의 관리하에 있는 BIOS 수준 암호로 구성됩니다.
- **암호 요구 사항**. 신뢰할 수 있는 클라이언트는 강력한 암호를 사용해야 합니다.
신뢰할 수 있는 상태는 일정하지 않아, 이러한 표준에 따라 보안 표준과 준수가 변경되기 쉬운 전이적 상태라는 것을 이해하는 것이 중요합니다. 새로운 위협과 새로운 방어가 꾸준히 나타나고 있습니다. 이런 이유로 조직의 관리 시스템이 신뢰할 수 있는 호스트를 계속 점검하여 지속적인 준수를 보장하는 것이 필수적입니다. 또한 이러한 시스템은 신뢰할 수 있는 상태를 유지하는 데 필요한 경우 업데이트 또는 구성 변경을 실행할 수 있어야 합니다.
모든 보안 요구 사항을 계속 충족시키는 호스트는 신뢰할 수 있는 호스트로 간주할 수 있습니다. 그러나 이 장 앞부분에서 설명한 검색 프로세스에서 식별된 대부분의 호스트 컴퓨터가 현재 이러한 요구 사항을 충족시키지 못할 가능성이 매우 높습니다. 따라서 신뢰할 수 있는 호스트와 신뢰할 수 없는 호스트를 식별하여 해당 호스트는 신뢰할 수 없는 것으로 간주해야 합니다. 이 프로세스를 위해 중간의 신뢰할만한 상태를 정의할 수 있습니다. 이 절의 나머지 부분에서는 여러 가지 상태와 그 영향을 설명합니다.
#### 신뢰할만한 상태
필요할 경우 현재 인프라에서 신뢰할 수 있는 상태가 될 수 있는 이러한 호스트는 가능한 빨리 식별하는 것이 유용합니다. 필요한 소프트웨어와 구성 변경을 사용하여 현재 호스트가 물리적으로 신뢰할 수 있는 상태가 될 수 있다는 것을 나타내기 위해 신뢰할만한 상태를 할당할 수 있습니다.
신뢰할만한 상태가 할당된 각 컴퓨터에 대해 구성 메모를 동봉하여 호스트가 신뢰할 수 있는 상태가 되는 데 필요한 사항을 기록해야 합니다. 이 정보는 프로젝트 설계 팀(호스트를 솔루션에 추가하는 비용 추정)과 지원 직원(필요한 구성을 적용할 수 있도록 함)에게 특히 중요합니다. 일반적으로 신뢰할만한 호스트는 다음 두 그룹 중 하나에 속하게 됩니다.
- **필요한 구성**. 현재 하드웨어, 운영 체제 및 소프트웨어를 사용하면 호스트가 신뢰할만한 상태가 될 수 있습니다. 그러나 사전 보안 수준을 달성하려면 추가 구성 변경이 필요합니다. 예를 들어, 호스트가 신뢰할 수 있는 호스트로 간주되려면 조직이 안전한 파일 시스템을 요구하는 경우 FAT32 형식의 하드 디스크를 가진 호스트는 이 요구 사항을 충족시키지 못합니다.
- **필요한 업그레이드**. 신뢰할 수 있는 것으로 간주되려면 이 컴퓨터 그룹은 시스템을 업그레이드해야 합니다. 다음 목록은 이 그룹의 컴퓨터가 요구할 수 있는 업그레이드 종류에 대한 몇 가지 예입니다.
- 운영 체제 업그레이드가 필요합니다. 호스트의 현재 운영 체제가 조직의 보안 요구를 지원하지 못하는 경우 호스트가 신뢰할 수 있는 상태가 되려면 업그레이드해야 합니다.
- 필요한 소프트웨어. 바이러스 백신 스캐너나 관리 클라이언트 같이 필요한 보안 응용 프로그램이 없는 호스트는 이러한 응용 프로그램을 설치하고 활성화할 때까지 신뢰할 수 있는 호스트로 간주될 수 없습니다.
- 필요한 하드웨어 업그레이드. 경우에 따라 신뢰할 수 있는 상태가 되려면 호스트에 특정 하드웨어 업그레이드가 필요할 수 있습니다. 이런 종류의 호스트는 대개 강제로 하드웨어 업그레이드를 요구하는 운영 체제 업그레이드나 추가 소프트웨어가 필요합니다. 예를 들어, 컴퓨터에 추가 저장 공간이 필요한 보안 소프트웨어는 더 많은 하드 디스크 공간을 요구할 수 있습니다.
- 필요한 컴퓨터 교체. 이 범주는 하드웨어가 허용되는 최소 구성을 지원할 수 없기 때문에 솔루션의 보안 요구 사항을 지원할 수 없는 호스트를 위해 예약된 것입니다. 예를 들어, 구형 프로세서(예: 100MHz x86 기반 컴퓨터)를 갖고 있기 때문에 안전한 운영 체제를 실행할 수 없는 컴퓨터.
이러한 그룹을 사용하여 업그레이드가 필요한 컴퓨터에 솔루션을 구현하기 위한 비용을 할당합니다.
#### 알려진, 신뢰할 수 없는 상태
조직의 호스트를 범주화하는 과정 동안 잘 알려져 있고 잘 정의된 이유로 신뢰할 수 있는 상태가 될 수 없는 일부 호스트를 식별합니다. 이러한 이유는 다음 종류를 포함할 수 있습니다.
- **재정적**. 이 호스트를 위한 하드웨어나 소프트웨어를 업그레이드할 자금이 없습니다.
- **정치적**. 조직의 최소 보안 요구 사항을 준수할 수 없는 정치적 또는 비즈니스 상황의 결과로 신뢰할 수 없는 상태를 유지해야 할 수 있습니다. 호스트의 비즈니스 소유자와 ISV(독립 소프트웨어 공급업체)에게 서버와 도메인 격리의 추가된 가치를 설명하는 것이 좋습니다.
- **기능적**. 호스트를 안전하지 않은 운영 체제에서 실행해야 하거나 역할을 수행하려면 안전하지 않은 방식으로 운영해야 합니다. 예를 들어, 특정 업무용 응용 프로그램이 오래된 운영 체제에서만 작동하기 때문에 호스트를 이런 운영 체제에서 실행해야 할 수 있습니다.
알려진 신뢰할 수 없는 상태로 호스트를 유지하는 기능적 이유는 많이 있을 수 있습니다. 다음 목록은 이 상태로 분류될 수 있는 몇 가지 기능적 이유를 포함하고 있습니다.
- **Windows 9 *x* 또는 Windows Millennium Edition**을 실행하는 컴퓨터. 이러한 특정 Windows 운영 체제 버전을 실행하는 컴퓨터는 이러한 운영 체제가 기본 보안 인프라를 지원하지 않기 때문에 신뢰할만한 컴퓨터로 분류될 수 없습니다. 사실 이러한 운영 체제에는 디자인상 보안 인프라가 없습니다. 또한 이러한 운영 체제에는 시스템 정책과 사용자 로그온 스크립트를 통해 사용자 관련 컴퓨터 구성을 할 수 있는 기초적인 중앙 관리 기능만 있습니다. 마지막으로 이러한 운영 체제는 필수 보안 관리 기능을 전혀 제공하지 않습니다.
- **Windows NT를 실행하는 컴퓨터**. Windows NT를 실행하는 컴퓨터는 이 운영 체제가 기본 보안 인프라를 완벽하게 지원하지 않기 때문에 서버 및 도메인 격리의 컨텍스트에서 신뢰할만한 컴퓨터로 분류할 수 없습니다. 예를 들어, Windows NT는 사용자 구성의 제한된 중앙 관리를 지원하기는 하지만 네트워크 통신의 기밀성과 무결성, 강력한 인증을 위한 스마트 카드 또는 컴퓨터 구성의 중앙 관리를 보장하는 방법인 로컬 리소스에 대한 "거부" ACL을 지원하지 않습니다. Windows NT는 데이터의 기밀성을 보호하고 무결성을 보장하는 방식(예: Windows 2000 암호화 파일 시스템)도 제공하지 않습니다.
또한 Windows NT는 필요한 모든 보안 기능을 지원하지 않습니다. 예를 들어, 그룹 정책 또는 IPsec 정책을 지원하지 않거나 필요할 경우 로컬 관리자 수준 액세스를 얻을 수 있는 메커니즘도 제공하지 않습니다. 또한 효력을 유지하기 위해 정기적으로 보안 구성을 다시 적용하지 않습니다.
**참고:** Windows NT가 신뢰할만하지 않다는 설명은 전적으로 서버 및 도메인 격리의 구현에만 해당하는 것이며 일반적인 운영 체제로서의 용도에 관한 것은 아닙니다. 이 프로젝트의 서버의 경우 Windows Server 2003 플랫폼으로 업그레이드하는 것이 가장 안전하고 관리 가능한 솔루션입니다.
- **독립 실행형 컴퓨터**. 독립 실행형 컴퓨터 또는 작업 그룹의 구성원으로 구성된 Windows 버전을 실행하는 컴퓨터는 대개 신뢰할만한 상태를 얻을 수 없습니다. 이러한 운영 체제가 필요한 최소 기본 보안 인프라를 완벽하게 지원할 수 있지만 컴퓨터가 신뢰할 수 있는 도메인의 일부가 아니면 필수 보안 관리 기능을 얻지 못할 수 있습니다.
- **신뢰할 수 없는 도메인에 있는 컴퓨터**. 조직의 IT 부서가 신뢰하지 않는 도메인의 구성원인 컴퓨터는 신뢰할 수 있는 컴퓨터로 분류될 수 없습니다. 신뢰할 수 없는 도메인은 해당 구성원에 필요한 보안 기능을 제공할 수 없는 도메인입니다. 이 신뢰할 수 없는 도메인의 구성원인 컴퓨터의 운영 체제가 필요한 최소 기본 보안 인프라를 완벽하게 지원할 수 있지만 컴퓨터가 신뢰할 수 있는 도메인에 있지 않으면 필수 보안 관리 기능을 완전히 보장할 수 없습니다. 예를 들어, 신뢰할 수 없는 도메인에서는 필요할 경우 신뢰할 수 있는 사용자가 로컬 관리자 수준 액세스를 얻을 수 있도록 하는 메커니즘이 없습니다. 신뢰할 수 없는 도메인의 관리자가 보안 구성(중앙에서 관리할 수 있는 보안 구성 포함)을 간단히 무시할 수도 있습니다. 또한 보안 구성, 소프트웨어 정책 및 표준 준수를 보장할 수 없으며 준수 여부를 효과적으로 모니터링하는 방법도 사용할 수 없습니다.
- **Windows NT 도메인의 컴퓨터**. Windows NT를 기반으로 하는 도메인의 구성원인 컴퓨터는 신뢰할 수 있는 컴퓨터로 분류될 수 없습니다. 운영 체제가 필요한 최소 기본 보안 인프라를 완벽하게 지원할 수 있지만 컴퓨터가 Windows NT 도메인에 있으면 필수 보안 관리 기능이 완벽하게 지원되지 않습니다.
그러나 호스트가 조직에 필요한 역할을 제공하기 때문에 설계 시 호스트를 고려해야 하는 경우 알려진 신뢰할 수 없는 상태를 할당해야 합니다. 이것은 위험이 솔루션으로 완화할 수 없는 것으로 식별되었음을 의미합니다. 다른 기술을 사용하여 이 알려진 위협을 완화해야 합니다. 이 범주에 속하는 호스트의 다양한 특성 때문에 이러한 기술의 특정 지침은 제공할 수 없습니다. 그러나 이러한 완화 기술의 목표는 이 호스트로 인해 발생하는 위험을 최소화하는 것이어야 합니다.
#### 알려지지 않은, 신뢰할 수 없는 상태
알려지지 않은, 신뢰할 수 없는 상태는 모든 호스트의 기본 상태로 간주해야 합니다. 이 상태의 호스트는 알려지지 않은 구성을 갖고 있기 때문에 트러스트를 할당할 수 없습니다. 이 상태의 호스트에 대한 모든 계획은 호스트가 손상되었거나 손상 가능성이 있다고 가정해야 하며, 따라서 조직에 허용할 수 없는 위험입니다. 솔루션 디자이너는 이 상태의 컴퓨터가 조직에 미칠 수 있는 영향을 최소화하기 위해 노력해야 합니다.
[](#mainsection)[페이지 위쪽](#mainsection)
### 현재 호스트에 대한 업그레이드 비용 파악
이 장의 최종 단계는 솔루션에 참가할 수 있는 지점으로 컴퓨터를 업그레이드하는 대략적인 비용을 기록하는 프로세스입니다. 프로젝트 설계 단계 동안 다음 질문에 대답해야 하는 여러 가지 중요한 결정을 내려야 합니다.
- 컴퓨터가 격리에 필요한 최소 하드웨어 요구 사항을 충족합니까?
- 컴퓨터가 격리에 필요한 최소 소프트웨어 요구 사항을 충족합니까?
- 이 컴퓨터를 격리 솔루션에 통합하려면 어떤 구성 변경이 필요합니까?
- 컴퓨터가 신뢰할 수 있는 상태를 얻을 수 있도록 제안된 변경을 수행하는 예상 비용 또는 영향은 무엇입니까?
이러한 질문에 답변함으로써 특정 호스트 또는 호스트 그룹을 프로젝트 범위에 편입시키는 노력의 수준과 대략적인 비용을 신속하게 결정할 수 있습니다. 한 사람 또는 한 역할 내의 여러 사람이 모든 데이터를 수집할 수는 없습니다. 일부 데이터는 헬프 데스크나 현장 서비스 기술자가 수집할 수 있는 반면, 다른 데이터는 설계자나 회사 임원진 수준의 입력이 필요할 것입니다. 컴퓨터 상태는 전이적이며 나열된 개선 조치를 수행함으로써 신뢰할 수 없는 컴퓨터 상태를 신뢰할 수 있는 컴퓨터로 변경할 수 있다는 점을 기억하는 것이 중요합니다. 컴퓨터를 신뢰할 수 있는 상태로 만들지 여부를 결정하게 되면 이 가이드의 4장 "격리 그룹 설계 및 계획"에서 설명하는 격리 그룹의 계획과 설계를 시작할 준비가 된 것입니다.
다음 표는 호스트의 현재 상태와 호스트가 신뢰할 수 있는 상태가 되는 데 필요한 것이 무엇인지 파악하는 데 사용할 수 있는 데이터 시트의 예입니다.
**표 3.3: 예제 호스트 수집 데이터**
호스트 이름
하드웨어 요구 충족
소트웨어 요구 충족
구성. 필요.
세부 정보
예상 비용
HOST-NYC-001
필요 없음
필요 없음
하드웨어 및 소프트웨어 업그레이드.
현재 운영 체제는 Windows NT 4.0입니다. 기존 하드웨어는 Windows XP SP2와 호환되지 않습니다.
$XXX.
SERVER-LON-001
필요함
필요 없음
신뢰할 수 있는 도메인에 참가하고 Windows NT 4.0에서 Windows 2000 SP4 이상으로 업그레이드합니다.
바이러스 백신 소프트웨어 없음.
$XXX.
다음 목록은 표 3.3의 각 열을 설명합니다.
**호스트 이름**. 네트워크에 있는 호스트 장치 이름.
- **하드웨어 요구 충족**. 컴퓨터가 솔루션에 참가하는 최소 하드웨어 요구 사항을 충족하는지 여부를 나타냅니다.
- **소프트웨어 요구 충족**. 컴퓨터가 솔루션에 참가하는 최소 소프트웨어 요구 사항을 충족하는지 여부를 나타냅니다. Woodgrove 은행에서 최소 요구 사항은 Windows 2000 SP4, Windows XP SP2 또는 Windows Server 2003 뿐 아니라 각 운영 체제에 대한 모든 중요 보안 패치였습니다. 또한 컴퓨터는 신뢰할 수 있는 도메인(예: Woodgrove 은행 IT 직원이 중앙에서 관리하는 도메인)에 있어야 하며 특히 IT 관리자에게 컴퓨터에 액세스할 수 있는 권한을 제공해야 합니다.
- **필요한 구성**. 컴퓨터가 신뢰할 수 있는 상태가 되는 데 취해야 하는 조치.
- **세부 정보**. 컴퓨터가 현재 신뢰할 수 있는 상태에 있지 않은 이유를 설명합니다.
- **예상 비용**. 장치가 신뢰할 수 있는 상태가 되는 데 필요한 예상 비용을 나타냅니다. 이 비용은 소프트웨어, 하드웨어, 생산성 손실 및 지원의 예상 비용을 포함합니다. 이 정보는 특정 컴퓨터를 신뢰할 수 있는 컴퓨터로 솔루션에 추가하는 것이 비즈니스 관점에서 실용적이거나 그 만한 가치가 있는지 여부를 확인하는 데 도움을 줍니다.
앞의 표에서 호스트 HOST-NYC-001은 현재 "알려진, 신뢰할 수 없는" 호스트입니다. 그러나 필요한 업그레이드가 가능할 경우 신뢰할만한 호스트로 간주할 수 있습니다. 하지만 많은 컴퓨터를 동일한 수준으로 업그레이드해야 할 경우 솔루션의 전체 비용은 상당히 높아질 것입니다.
호스트 SERVER-LON-001은 하드웨어 요구 사항을 충족하지만 IPsec 정책을 사용할 수 있고 도메인에 참가하는 운영 체제로 업그레이드해야 합니다. 바이러스 백신 소프트웨어도 필요합니다. 예상 비용은 운영 체제를 업그레이드하고 바이러스 백신 소프트웨어를 설치하는 데 필요한 노력과 운영 체제와 바이러스 백신 소프트웨어 라이센스 비용을 포함한 비용입니다.
표 3.3에서 설명하는 정보를 얻은 후에 설계자나 설계 팀이 사용할 수 있도록 이 장에서 수집한 다른 정보와 함께 보관하십시오. 이 정보는 격리 그룹의 설계를 중점적으로 다루는 4장에서 수행하는 노력의 기초가 됩니다.
이 절에서 식별된 비용은 호스트 업그레이드의 예상 비용일 뿐이라는 사실에 유의해야 합니다. 프로젝트와 관련된 추가 설계, 지원 테스트 및 교육 비용이 많이 있습니다. 정확한 프로젝트 비용을 알아보려는 경우 전체 프로젝트 계획에서 이러한 추가 비용을 고려해야 합니다.
[](#mainsection)[페이지 위쪽](#mainsection)
### 요약
이 장에서는 영향 고려 사항을 포함하여 서버 및 도메인 격리 프로젝트를 수행하는 데 필요한 정보의 개요를 제공했습니다. 이 장의 지침을 사용하여 다음 작업을 수행할 수 있습니다.
- 네트워크의 자산 식별
- 네트워크 정보 수집
- 호스트 정보 수집
- 현재 트래픽 정보 확인
- 현재 Active Directory 아키텍처 검토 및 관련 정보 수집
- IPsec 용량 고려 사항 검토
- IPsec을 위한 사전 배포 고려 사항 보기
- 신뢰할만한 장치와 신뢰하지 못할만한 장치가 무엇이며 Woodgrove 은행 시나리오에서 어떻게 분류되었는지 설명
이러한 작업을 수행하면 다음 장에서 격리 그룹 설계를 시작하는 데 필요한 모든 정보가 수집됩니다.
#### 추가 정보
이 절에서는 이 솔루션 구현에 도움이 되는 추가 정보에 대한 링크를 제공합니다.
- Windows Server 2003용 IPsec 지원을 위한 방화벽 구성에 대한 자세한 내용은 Windows Server 2003 설명서의 [방화벽 구성](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/6e268195-6750-494a-8f19-25d07911926f.mspx) (영문) 페이지(www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/>dnsbj\_ips\_schx.asp.
- [Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0)](https://www.microsoft.com/download/details.aspx?familyid=afe41f46-e213-4cbf-9c5b-fbf236e0e875&displaylang=ko) 설치 패키지는 Microsoft 다운로드 센터(www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875&DisplayLang=en)에서 다운로드할 수 있습니다.
- WMI에 대한 자세한 내용은 MSDN®에서 [Windows Management Instrumentation](https://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_start_page.asp) 설명서(https://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi\_start\_page.asp.
- [Windows 2000 and XP용 Microsoft Windows Script 5.6](https://www.microsoft.com/download/details.aspx?familyid=c717d943-7e4b-4622-86eb-95a22b832caa&displaylang=ko)은 Microsoft 다운로드 센터(www.microsoft.com/downloads/details.aspx?FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en.
- [Windows 98, Windows Millennium Edition 및 Windows NT 4.0용 Microsoft Windows Script 5.6](https://www.microsoft.com/download/details.aspx?familyid=0a8a18f6-249c-4a72-bfcf-fc6af26dc390&displaylang=ko)는 Microsoft 다운로드 센터(www.microsoft.com/downloads/details.aspx?FamilyId=0A8A18F6-249C-4A72-BFCF-FC6AF26DC390&displaylang=en.
- [Windows Script 5.6 설명서](https://www.microsoft.com/download/details.aspx?familyid=01592c48-207d-4be1-8a76-1c4099d7bbb9&displaylang=en) (영문)는 Microsoft 다운로드 센터(www.microsoft.com/downloads/details.aspx?FamilyId=01592C48-207D-4BE1-8A76-1C4099D7BBB9&displaylang=en)에서 다운로드할 수 있습니다.
[](#mainsection)[페이지 위쪽](#mainsection)
.gif)