IO 기능: 보안 및 네트워킹 - 표준화 -> 합리화

  • 아티클
이 페이지의 내용

소개 소개
요구 사항: 서버 및 데스크톱 방화벽 정책 관리 요구 사항: 서버 및 데스크톱 방화벽 정책 관리
요구 사항: 내부 리소스 및 LOB 응용 프로그램에 대한 보안 원격 액세스 요구 사항: 내부 리소스 및 LOB 응용 프로그램에 대한 보안 원격 액세스
요구 사항: 서버 간에 보장된 보안 통신 확인 요구 사항: 서버 간에 보장된 보안 통신 확인
요구 사항: 서버의 서비스 수준 계약 모니터링 및 보고 요구 사항: 서버의 서비스 수준 계약 모니터링 및 보고
요구 사항: 상태 정보의 보안 통신 메커니즘 요구 사항: 상태 정보의 보안 통신 메커니즘
요구 사항: 무선 네트워크 인증 및 권한 부여용 Active Directory 및 IAS/RADIUS 요구 사항: 무선 네트워크 인증 및 권한 부여용 Active Directory 및 IAS/RADIUS
요구 사항: 중앙 관리식 인증서 서비스 요구 사항: 중앙 관리식 인증서 서비스
요구 사항: 지사 대역폭 예방적 관리 요구 사항: 지사 대역폭 예방적 관리

소개

보안 및 네트워킹이 세 번째 핵심 인프라 최적화 기능입니다. 다음 표에는 보안 및 네트워킹의 합리화 수준으로 이동함에 따른 상위 과제, 해당 솔루션 및 이점이 나열되어 있습니다.

과제

솔루션

이점

업무상 과제

다층 보안 모델이 경계에서 방화벽, 서버, 데스크톱 및 응용 프로그램 수준을 거쳐 네트워크를 통해 배포되지 않음

방화벽이 데스크톱의 표준 구성 요소가 아님

공용 네트워크에서 제공하는 라우팅 인프라를 통한 리소스에 대한 보안 액세스가 모바일 사용자에게 없음

IT 과제

서버가 모든 호스트에서 들어오는 인바운드 트래픽을 받아들여서 공격에 대한 취약점이 증가함

무선 클라이언트의 인증이 약함

무선 LAN의 암호화와 데이터 무결성이 약함

프로젝트

서버에 정책으로 관리되는 방화벽 배포 내부 리소스 및 LOB 응용 프로그램에 대한 원격 액세스 보안

서버 간에 보장된 보안 통신 확인 제공

서버의 SLA 모니터링 및 보고 구현

상태 정보의 보안 통신 메커니즘 구현

무선 네트워크 인증 및 권한 부여용 Active Directory 및 IAS/RADIUS 배포

중앙 관리식 인증서 서비스 구현

지사 대역폭 예방적 관리 시작

업무상 이점

사용자가 위치에 관계없이 리소스에 대한 보안 액세스를 가짐

예방적 보안, 구성 및 관리 정책과 프로세스를 통해 안정성이 향상됨

IT 이점

데스크톱 하드웨어와 소프트웨어의 자산 관리가 개선됨

IPsec 정책과 필터를 배포하기 위한 그룹 정책이 중앙 집중화되어 PC의 보안 수준이 높아짐

IPsec 정책을 통해 인바운드 트래픽을 트러스트된 호스트로 제한하여 네트워크 환경의 보안이 강화됨

IT 부서에서 위기를 관리하는 데 들이는 시간은 줄어들고 새 업무용 서비스를 전달하는 데 들이는 시간은 늘어남

인프라 최적화 모델의 합리화 수준에서는 네트워킹 및 보안 구성 요소의 주요 영역을 다룹니다. 로컬 방화벽, IP 보안, 가용성 모니터링, 무선 인프라 보안, 인증서 관리, WAN 관리 등이 여기에 포함됩니다.

요구 사항: 서버 및 데스크톱 방화벽 정책 관리

대상

정책으로 관리되는 방화벽이 서버와 데스크톱 중 80% 이상에 마련되어 있지 않으면 이 절을 읽어야 합니다.

개요

구현자용 핵심 인프라 최적화 리소스 가이드: 기초 -> 표준화에서  중앙 집중식 경계 방화벽을 통한 네트워크 컴퓨터 보호에 대해 알아보았습니다. 표준화 수준에서 합리화 수준으로 이동하려면 등급 1 호스트 기반 방화벽을 통해 서버 및 데스크톱에 정책을 설정하고 적용하여 네트워크의 방화벽 보호를 보완해야 합니다. Microsoft와 다른 소프트웨어 공급업체에서 정책이나 규칙 집합을 기반으로 보호를 구성하는 데 사용되는 방화벽 소프트웨어를 제공합니다. 이 요구 사항은 합리화 수준의 중앙 집중식 디렉터리 기반 구성 및 보안에 대한 요구 사항과도 밀접하게 연결되어 있습니다.

대부분의 등급 1 방화벽은 최소 수준에서 매우 제한적인 수준에 이르는 다양한 보호 수준용으로 구성할 수 있습니다. 사용자가 직접 자신의 컴퓨터에 보호 수준을 설정하도록 허용할 경우 전체 네트워크를 보호하는 수준이 선택된다고 보장할 수 없습니다. 정책으로 관리되는 방화벽을 사용하여 네트워크 요구를 충족하는 보안 수준을 판단할 수 있습니다.

1단계: 평가

평가 단계에서는 해당 환경에 있는 컴퓨터 중 정책 관리 기능과 함께 일부 형태의 호스트 기반 방화벽을 이미 가지고 있는 것이 무엇인지를 다시 평가합니다. 합리화 수준에서는 데스크톱 PC 중 80% 이상에서 Windows XP SP2 또는 Windows Vista(요구 사항: 데스크톱을 위한 2가지 최신 OS 버전 및 서비스 팩 참조)를 실행해야 합니다. 합리화 수준에는 서버에서 2가지 최신 운영 체제를 실행해야 한다는 요구 사항이 없습니다. 이것이 중요한 이유는 조직에서 2가지 최신 데스크톱 운영 체제 버전을 배포했다고 가정할 경우 데스크톱에서 사용할 수 있는 호스트 기반 방화벽 기능이 있어야 한다는 요구 사항이 이미 충족된 것이므로 그저 그룹 정책을 통해 구성 적용 요구 사항을 통합하여 Windows 방화벽이 원하는 구성으로 실행되도록 하면 되기 때입니다. Windows Server 제품의 호스트 기반 방화벽은 Windows Server 2003 SP1 릴리스부터 시작되었으므로 조직의 서버 인프라 중 80% 이상에서 Windows Server 2003 SP1 이상을 실행하고 있지 않으면 인벤토리를 조사하여 호스트 기반 방화벽이 없는 해당 시스템을 식별해야 합니다. 서버 인프라에 대한 운영 체제 및 응용 프로그램 정보를 자동화하려면 SMS 2003 하드웨어 인벤토리를 사용하는 것이 좋습니다.

2단계: 식별

이전 단계에서 생성된 서버 인벤토리를 사용하여 식별 단계에서는 호스트 기반 방화벽이 필요한 서버 인프라를 격리합니다. 평가 및 계획 단계에서 호스트 기반 방화벽을 사용하는 데 적합한 완화 전략을 판단하고 그룹 정책을 사용하여 적용할 적합한 방화벽 구성을 판단하게 됩니다.

3단계: 평가 및 계획

평가 및 계획 단계에서는 호스트 기반 방화벽 기술을 검토하고 조직의 데스크톱과 서버 중 90% 이상에 호스트 기반 방화벽이 있도록 하는 데 적합한 작업 과정을 판단하게 됩니다. 호스트 기반 방화벽을 대부분의 데스크톱과 서버에 적용하기 위한 전략을 판단한 후에는 그룹 정책을 사용하여 호스트 기반 방화벽의 사용법과 구성을 적용할 수 있는 방법을 판단해야 합니다. 이 단계는 테스트 환경에서 호스트 기반 방화벽 배포를 평가하고 계획하는 경우에만 신뢰할 수 있습니다. 다음 절에서는 Windows 방화벽에 중점을 두지만 Internet Security Systems의 BlackICE나 Zone Labs의 Zone Alarm과 같은 유사한 기술을 선택해서 사용할 수 있습니다.

Windows 방화벽

Windows 방화벽은 기본 제공된 상태 저장 호스트 기반 방화벽이며 Windows XP 서비스 팩 2, Windows Server 2003 서비스 팩 1, Windows Vista 및 Windows Server 코드 이름 "Longhorn"(현재 베타 테스트 중임)에 포함되어 있습니다. Windows 방화벽은 컴퓨터의 요청에 대한 응답으로 전송된 트래픽(요청된 트래픽) 또는 허용하도록 지정되었으나 요청되지 않은 트래픽(예외 트래픽) 중 어디에도 해당되지 않는 수신 트래픽을 삭제합니다.

Windows 방화벽은 호스트 방화벽으로서, 각 서버와 클라이언트에서 실행되며 트로이 목마 공격, 웜 또는 요청되지 않은 수신 트래픽을 통해 배포된 다른 유형의 악성 프로그램과 같이 조직 내에서 시작되거나 경계 네트워크를 통과하는 네트워크 공격에 대한 보호 기능을 제공합니다.

Windows 방화벽에 대한 자세한 리소스를 보려면 https://www.microsoft.com/technet/network/wf/default.mspx를 방문하십시오.

데스크톱 중 80% 이상에 Windows 방화벽이나 유사한 호스트 기반 방화벽 기능이 있어야 합니다. 앞서 설명한 대로 평가할 수 있는 다른 호스트 기반 방화벽 제품은 Internet Security Systems의 BlackICE와 Zone Labs의 Zone Alarm입니다.

데스크톱 및 서버의 호스트 기반 방화벽 받기

데스크톱과 서버에 사용할 기본 방화벽 기술을 선택하고 방화벽 기능이 필요한 호스트를 대상으로 지정한 후에 수행할 다음 작업은 해당 방화벽 응용 프로그램을 테스트하고 구성하여 테스트 인프라에 배포하는 것입니다. 이러한 단계는 서버 패치 관리, 소프트웨어 배포의 호환성 테스트 및 인증 및 데스크톱 하드웨어 및 소프트웨어의 자동화된 추적에서 설명한 대로 본 가이드에 있는 최적의 패치 관리, 응용 프로그램 호환성 테스트 및 응용 프로그램 배포 방법과 일치합니다. Windows 방화벽을 Windows Server 2003 SP1 이전 서버의 단일 기본 기술로 선택한 경우에는 대상 서버를 Windows Server 2003 SP1 이상으로 업데이트해야 합니다.

방화벽의 정책 관리

호스트 기반 방화벽의 정책 관리는 핵심 인프라 최적화에 있어 합리화 수준의 일부로도 필요합니다. Windows 방화벽 사용자의 경우 방화벽 서비스가 사용되도록 하는 것이 요점입니다. 이 간단한 프로세스는 그룹 정책을 사용하여 다음 단계를 통해 수행됩니다.

그룹 정책 설정인 Windows 방화벽: 사용자의 도메인 네트워크에서 인터넷 연결 방화벽의 사용을 금지가 사용되지 않거나 구성되지 않았는지 확인합니다.

이 설정을 사용하면 관리자를 포함한 모든 사용자가 Windows 방화벽을 사용하거나 구성하지 못하게 됩니다. 이 정책 설정을 변경하려면 그룹 정책 개체 편집기를 사용하여 조직에서 Windows 방화벽 설정을 관리하는 데 사용되는 그룹 정책 개체(GPO)를 편집하십시오.

사용자의 도메인 네트워크에서 인터넷 연결 방화벽의 사용을 금지 설정을 수정하려면

  1. 그룹 정책 개체 편집기를 열어 조직에서 Windows 방화벽 설정을 관리하는 데 사용되는 GPO를 편집합니다.

  2. 컴퓨터 구성, 관리 템플릿, 네트워크, 네트워크 연결을 차례로 클릭합니다.

  3. 세부 정보 창에서 Windows 방화벽: 사용자의 도메인 네트워크에서 인터넷 연결 방화벽의 사용을 금지 정책 설정을 두 번 클릭합니다.

  4. 사용 안 함 또는 구성되지 않음 확인란을 선택합니다.

Windows 방화벽을 사용하고 있지 않으면 선택한 호스트 기반 방화벽에 해당하는 설정을 찾아 이와 상응하는 절차를 수행하십시오. 관리되는 클라이언트와 서버 중 80% 이상에 대해 완료했으면 이 서버 및 데스크톱 방화벽 정책 관리에 대한 요구 사항 특성이 완료된 것입니다. 그룹 정책은 본 가이드에 나와 있는 중앙 집중식 디렉터리 기반 구성 및 보안에 설명되어 있습니다.

고급 Windows 방화벽 설정에 대한 자세한 내용은 최적의 Windows 방화벽 관리 방법을 참조하십시오.

4단계: 배포

이전 세 단계의 결과로, 선택한 호스트 기반 방화벽 기술을 배포하고 정책 관리를 사용할 준비가 되었습니다. 다시 말해서 배포 프로세스는 서버 패치 관리, 소프트웨어 배포의 호환성 테스트 및 인증 및 데스크톱 하드웨어 및 소프트웨어의 자동화된 추적에서 설명한 대로 해당하는 최적의 패치 관리, 응용 프로그램 호환성 테스트 및 응용 프로그램 배포 방법 권장 사항을 포함합니다. 계획 및 배포 프로세스에 대한 자세한 내용은 이러한 요구 사항을 참조하십시오.

추가 정보

방화벽에 대한 자세한 내용을 보려면 Microsoft TechNet을 방문하여 "Windows Firewall"을 검색하십시오.

Microsoft가 방화벽을 네트워크 경계 보안에 통합하는 방법을 보려면 https://www.microsoft.com/technet/itshowcase/content/secnetwkperim.mspx를 방문하십시오.

체크포인트: 서버 및 데스크톱 방화벽 정책 관리

요구 사항

 

현재 호스트 기반 방화벽 기술이 있는 하드웨어를 확인하기 위해 데스크톱과 서버 컴퓨터의 인벤토리를 조사했습니다.

 

호스트 기반 방화벽 기술을 방화벽 기능이 없는 하드웨어에 배포하거나 서버를 Windows Server 2003 SP1 이상으로 업데이트했습니다.

 

호스트 기반 방화벽이 항상 사용되고 해당 기능을 해제할 수 없도록 하는 정책 적용을 설정했습니다.

위에서 설명한 단계를 완료했다면 인프라 최적화 모델에서 서버 및 데스크톱 방화벽 정책 관리 기능에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다. 본 가이드와 최적의 Windows 방화벽 관리 방법에서 호스트 기반 방화벽 정책 관리에 대한 추가 최적의 방법 리소스 지침을 따르도록 권장합니다.

다음 자체 평가 질문으로 이동하십시오.

요구 사항: 내부 리소스 및 LOB 응용 프로그램에 대한 보안 원격 액세스

대상

전자 메일을 넘어서 가상 사설망(VPN)이나 Microsoft 터미널 서비스와 같은 내부 리소스 및 LOB 응용 프로그램에 대한 보안 원격 액세스를 직원에게 제공하고 있지 않으면 이 절을 읽어야 합니다.

개요

현재 비즈니스 환경에서 조직은 비용을 절감하고 효율성을 높이며 기존 인프라의 성능을 극대화해야 한다는 압박을 받고 있습니다. 새로운 글로벌 비즈니스 기회와 함께 인터넷의 발전으로 인해 반드시 전 세계의 직원과 위치에 보안 네트워크 액세스를 연중 무휴로 제공해야 합니다. 대개 원격 액세스를 사용하는 2가지 시나리오는 다음과 같습니다.

  • 원격 클라이언트 액세스. 원격 클라이언트는 일반적으로 집에서 또는 이동 중에 일을 하면서 기업용 리소스에 액세스해야 하는 직원의 가정용 컴퓨터나 랩톱과 같은 단일 컴퓨터입니다.

  • 사이트 간 액세스. 사이트 간 액세스는 여러 논리적 및 물리적 위치에 있는 리소스와 데이터에 액세스하기 위해 조직의 중앙 설비와 지사 간에 사용됩니다.

기업 조직의 이러한 두 주요 원격 액세스 요구 사항은 모두 VPN을 사용하여 제공할 수 있습니다. 이 두 솔루션 모두 전화 접속 연결이나 인터넷(공유) 임대 회선 연결의 기본 상태 정보가 필요합니다. 본 가이드에서는 VPN에 중점을 두고 요구 사항을 이행하기 위한 터미널 서비스를 소개합니다. 지침은 WSSRA(Windows Server System Reference Architecture) 원격 액세스 서비스를 기반으로 합니다.

Windows Server 2003 VPN에 대한 자세한 기술 리소스를 보려면 Microsoft TechNet의 가상 사설망 웹 사이트를 방문하십시오.

1단계: 평가

평가 단계가 진행되는 동안 현재 사용자 기반이 원격 위치에서 작업을 수행하고 있는 방식을 식별해야 합니다. 조직에서 Microsoft Office OWA(Outlook® Web Access)나 웹 지원 기간 업무 응용 프로그램과 같은 서비스를 통해서만 전자 메일에 대한 서비스를 제공하는 경우가 있습니다. 이 경우 최종 사용자는 사실상 현지에 있는 사용자와 비교되는 기능 하위 집합을 가집니다. 평가 단계에서는 인트라넷이나 공동 작업 서비스와 같이 사용자가 현지에서 사용할 수 있는 서비스와 웹 기반 전자 메일이나 LOB 응용 프로그램과 같이 현지에서 떨어져 있거나 지사에 있는 사용자가 사용할 수 있는 서비스의 상위 목록을 판단해야 합니다.

2단계: 식별

현지에 있는 사용자와 현지에서 떨어져 있거나 지사에 있는 사용자의 서비스 목록이 마련되었으므로 식별 단계에서 원격 액세스를 통해 현지에서 떨어져 있는 사용자에게 안전하게 전달할 경우 사용자 생산성과 효율성을 높이는 현지 제공 서비스를 판단하면 됩니다. 대기 조직의 주요 원격 액세스 요구 사항, 즉 원격 클라이언트 액세스와 사이트 간 액세스는 VPN을 사용하여 제공할 수 있습니다. 이 두 솔루션 모두 인터넷 연결이나 임대 회선 연결이 필요합니다.

3단계: 평가 및 계획

평가 및 계획 단계에서는 보안을 유지 관리하는 데 사용되는 컨트롤과 함께 선택한 원격 액세스 서비스를 전달하는 방법을 검토합니다. 대다수 조직의 경우 비용이 너무 많이 들어 모든 도시에 사무실을 개설하거나 모든 직원의 가정에 개인 회로를 제공할 수 없어서 기업용 네트워크에 대한 보안 연결을 보장할 수 없습니다. VPN을 사용하면 비즈니스 파트너와 직원이 일반적으로 더욱 저렴한 비용으로 인터넷을 사용하여 암호화된 보안 연결을 설정할 수 있습니다.

가상 사설망

가상 사설망(VPN)은 인터넷과 같은 공유 연결을 통해 종점 간에 설정되어 기업용 네트워크의 확장으로 사용되는 암호화된 보안 연결입니다. VPN을 사용하면 조직에서 사무실이나 사용자를 인터넷 서비스 공급자(ISP)에 연결하는 것만으로 기존 글로벌 인터넷 인프라를 사용할 수 있습니다. 또한 VPN은 확장 가능한 기술입니다. 예를 들어 VoIP(Voice over IP)를 구현하면 원격 사용자는 해당 기능이 당시에 작동하고 있을 때마다 자신의 사무실 전화 내선 번호(모든 메시징 기능 포함)를 사용할 수 있습니다.

VPN 연결을 사용하면 집에서 또는 이동 중에 일을 하는 사용자가 인터넷과 같은 공용 인터네트워크로 제공된 인프라를 사용하여 조직 서버에 대한 원격 액세스 연결을 얻을 수 있습니다. 사용자 입장에서 볼 때 VPN은 컴퓨터, VPN 클라이언트 및 조직 서버(VPN 서버) 사이의 지점 간 연결입니다. 공유 또는 공용 네트워크의 정확한 인프라는 데이터가 전용 개인 링크를 통해 전송되는 것처럼 나타나기 때문에 관계없습니다.

또한 VPN 연결을 사용하면 조직에서 지리적으로 떨어져 있는 사무실의 보안 통신을 유지 관리하면서 공용 인터네트워크를 통해 다른 조직과의 라우팅된 연결을 가질 수 있습니다. 인터넷을 통해 라우팅된 VPN 연결은 논리적 측면에서 전용 광역 네트워크(WAN) 링크로 작동합니다.

다음 다이어그램은 VPN을 사용하는 원격 액세스 서비스의 아키텍처 설계를 보여 줍니다.  

그림 7. VPN을 통한 원격 액세스 서비스의 아키텍처 설계

그림 7. VPN을 통한 원격 액세스 서비스의 아키텍처 설계

VPN 설계 고려 사항

VPN 솔루션을 설계할 때는 보안, 비용, 통합, 향후 요구 사항 및 관리를 포함한 많은 문제를 고려해야 합니다. 적합한 VPN 기술을 결정하기 전에 VPN 솔루션의 설계 목표를 판단하는 것이 중요합니다. 이러한 목표는 클라이언트 원격 액세스에 사용할 솔루션인지 사이트 간 액세스에 사용할 솔루션인지 둘 다에 사용할 솔루션인지에 따라 다릅니다. VPN 설계 옵션에 대한 자세한 내용은 WSSRA 원격 액세스 서비스 상세 계획을 참조하십시오.

원격 액세스 서비스 계획

원격 액세스 설계는 비즈니스 및 기술 요구 사항을 판단하는 과정에서 수집한 정보를 기반으로 합니다. 대개 원격 액세스 솔루션은 집에서 또는 이동하면서 일을 하는 직원과 같은 원격 클라이언트와 비즈니스 등급의 사이트 간 연결이 있으면서 여러 사용자를 둔 지사 사이트에 필요합니다.

원격 클라이언트에 대한 원격 액세스 서비스 계획에 대한 자세한 내용은 CDC(Corporate Data Center) 시나리오의 WSSRA 원격 액세스 서비스 계획 가이드를 참조하십시오.

지사에 대한 원격 액세스 서비스 계획에 대한 자세한 내용은 다음을 참조하십시오.

터미널 서비스

Microsoft Windows Server 2003의 터미널 서비스 구성 요소를 사용하면 Windows 기반 응용 프로그램이나 Windows 데스크톱 자체를 사실상 모든 컴퓨팅 장치(Windows를 실행할 수 없는 컴퓨팅 장치 포함)에 전달할 수 있습니다.

Windows Server 2003의 터미널 서비스는 원격 액세스 보안 측면에서 중요한 다음 3가지 이점을 제공합니다.

  • 응용 프로그램의 신속한 중앙 배포

  • 저대역폭으로 데이터에 액세스

  • 원하는 곳 어디서나 Windows 사용

터미널 서비스에 대한 자세한 내용을 보려면 http://technet2,microsoft.com/windowsserver/en/technologies/featured/termserv/default.mspx를 방문하십시오.

4단계: 배포

원격 액세스 서비스에 대한 옵션을 평가하고 원격 클라이언트와 지사에 적합한 서비스를 제공하는 데 필요한 사항을 계획한 후에는 배포 단계에서 설계 구현이 발생합니다. WSSRA 원격 액세스 서비스 구축 가이드에서는 VPN 서비스를 테스트하여 원격 클라이언트(CDC 시나리오의 경우)와 지사(SBO 시나리오의 경우)에 배포하기 위한 구현 단계를 제공합니다.

추가 정보

Microsoft가 VPN과 터미널 서비스를 구현하는 방법을 보려면 다음 웹 사이트를 방문하십시오.

체크포인트: 내부 리소스 및 LOB 응용 프로그램에 대한 보안 원격 액세스

요구 사항

 

원격 클라이언트와 지사의 원격 액세스 요구 사항을 평가했습니다.

 

보안 가상 사설망이나 유사한 서비스를 설계하여 원격 클라이언트와 지사에 구현했습니다.

위에서 설명한 단계를 완료했다면 인프라 최적화 모델에서 내부 리소스 및 LOB 응용 프로그램에 대한 보안 원격 액세스 기능에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다. Microsoft TechNet의 가상 사설망 웹 사이트에서 VPN에 대한 추가 최적의 방법 리소스 지침을 따르도록 권장합니다.

다음 자체 평가 질문으로 이동하십시오.

요구 사항: 서버 간에 보장된 보안 통신 확인

대상

도메인 컨트롤러 및 전자 메일 서버와 같은 중요한 서버 간의 통신을 확인할 수 있는 보장된 보안 방법이 마련되어 있지 않으면 이 절을 읽어야 합니다.

개요

조직 네트워크의 경계를 보안할 때 직면하는 문제가 증가하고 있습니다. 조직이 커지고 비즈니스 관계가 바뀌며 고객, 공급업체 및 컨설턴트가 비즈니스 차원의 유효한 원인으로 인해 모바일 장치를 해당 조직 네트워크에 연결해야 함에 따라 네트워크에 대한 물리적 액세스 제어가 불가능해질 수 있습니다. 무선 네트워크와 무선 연결 기술의 출현으로 네트워크 연결이 이전보다 훨씬 쉬워졌습니다. 이러한 강화된 연결성은 곧 내부 네트워크의 도메인 구성원이 주변 보안의 위반뿐 아니라 내부 네트워크의 다른 컴퓨터의 상당한 위험에 대한 노출 가능성이 높아져 가고 있다는 것을 의미합니다.

본 가이드에서 제공하는 논리적 격리의 개념은 2가지 솔루션, 즉 서버가 트러스트된 도메인 구성원이나 특정 도메인 구성원 그룹의 네트워크 연결만 받아들이도록 하는 서버 격리 솔루션과 도메인 구성원을 트러스트되지 않은 연결로부터 격리하는 도메인 격리 솔루션을 구체화합니다. 이러한 솔루션은 전반적인 논리적 격리 솔루션의 일부분으로 별도 또는 함께 사용될 수 있습니다.

서버와 도메인 격리를 통해 IT 관리자가 트러스트된 컴퓨터인 도메인 구성원의 TCP/IP 통신을 제한할 수 있다는 것이 핵심입니다. 이러한 트러스트된 컴퓨터는 다른 트러스트된 컴퓨터 또는 특정한 트러스트된 컴퓨터 그룹의 들어오는 연결만을 허용하도록 구성할 수 있습니다. 그룹 정책은 네트워크 로그온 권한을 제어하는 액세스 컨트롤을 중앙에서 관리합니다. 거의 모든 TCP/IP 네트워크 연결은 IPsec(인터넷 프로토콜 보안)가 응용 프로그램 계층 아래의 네트워크 계층에서 작동하여 컴퓨터 종단 간 인증과 패킷 단위 보안을 제공하기 때문에 응용 프로그램 변경 없이도 보안이 유지될 수 있습니다. 네트워크 트래픽은 사용자가 지정할 수 있는 다양한 시나리오로 인증되거나 인증되어 암호화될 수 있습니다. 본 가이드에서는 Microsoft TechNet의 IPsec와 그룹 정책을 사용하여 서버 및 도메인 격리 가이드에 있는 지침과 권장 사항을 따릅니다.

1단계: 평가

본 가이드에 나와 있는 다른 요구 사항과 일치하도록 수행하는 첫 번째 단계는 조직의 현재 상태 평가에 대한 것입니다. 조직의 컴퓨터, 소프트웨어 및 네트워크 장치의 신뢰성 있는 레코드를 얻고 유지 관리하는 프로세스는 일반적인 IT 과제입니다. 현재 상태를 정의하려면 다음 항목에 대한 정보가 있어야 합니다.

  • 네트워크 검색

  • 네트워크 분할 설명서

  • 네트워크 인프라 장치

  • 현재 네트워크 트래픽 모델 분석

  • Active Directory

  • 호스트 검색

  • 호스트 데이터 요구 사항

이 정보를 수집하는 방법은 IPsec와 그룹 정책을 사용하여 서버 및 도메인 격리 가이드의 3장: IT 인프라의 현재 상태 확인을 참조하십시오. 본 가이드에서는 각 항목에 대한 요구 사항, SMS 2003이나 유사한 제품을 사용하여 자동화된 검색을 통해 정보를 수집하는 방법, 수동 검색 옵션 등을 설명합니다.

2단계: 식별

식별 단계는 조직의 요구에 적합한 전략 판단에 대한 것입니다. 직원들이 가장 민첩하고 생산적인 방식으로 작업할 수 있는 환경을 제공해 주는 동시에 최신 IT 인프라를 공격자의 위험으로부터 방어하는 것은 그리 쉬운 일이 아닙니다. 단순히 환경을 보호할 수 있는 광범위한 기술을 이해하는 것은 대부분의 사람들에게는 어려울 뿐입니다. 이 가이드는 해당 솔루션이 일반적인 IT 인프라에 적합한 분야와 기존 네트워크 방어 계층을 보완하도록 설계되는 방법을 정확하게 확인하는 데 도움이 될 수 있습니다.

다양한 네트워크 방어 계층으로 이루어져 있는 일반 네트워크 인프라를 보여 주는 다음 그림은 일반 환경에서 논리적 격리가 적합한 부분을 제시하고 있습니다.

그림 8. 일반 네트워크 인프라

그림 8. 일반 네트워크 인프라

식별 단계의 결과는 서버 및 도메인 격리 설계에 대한 상위 요구 사항을 판단하는 것입니다. 평가 및 계획 단계에서 자세한 요구 사항과 실행 계획을 설정하게 됩니다. 자세한 내용은 IPsec와 그룹 정책을 사용하여 서버 및 도메인 격리 가이드의 4장: 격리 그룹 설계 및 계획을 참조하십시오.

3단계: 평가 및 계획

평가 및 계획 단계의 목표는 서버 간에 확인된 통신을 보안하고 보장하기 위한 옵션이 모두 고려되었는지 확인하는 것입니다. 이 경우 이 작업을 수행하기 위한 메커니즘으로서 IPsec에 중점을 두고 있습니다. 핵심 인프라 최적화 모델의 합리화 수준에는 중앙 관리식 인증서 서비스에 대한 추가 관련 요구 사항이 있습니다.

배포 단계에 사용할 실행 계획을 생성하기 위해 서버 및 도메인 격리 설계 구현을 위한 지침이 제공됩니다.

인터넷 프로토콜 보안 평가

IPsec는 대개 두 서버 간의 통신 채널을 보호하고 서로 통신할 수 있는 컴퓨터를 제한하는 데 사용됩니다. 예를 들어 응용 프로그램 서버나 웹 서버와 같은 트러스트된 클라이언트 컴퓨터의 요청만 허용하는 정책을 설정하면 데이터베이스 서버를 보호하는 데 도움이 됩니다. 통신을 특정 프로토콜과 TCP/UDP 포트로 제한할 수도 있습니다.

서버 팜에 대한 네트워킹 요구 사항과 권장 사항을 따르면 다음과 같은 이유로 IPsec가 좋은 옵션이 됩니다.

  • 모든 서버가 IPsec 성능 개선을 위해 하나의 물리적 LAN에 포함됩니다.

  • 서버에 고정 IP 주소가 할당됩니다.

트러스트된 Windows Server 2003이나 Microsoft Windows 2000 Server 도메인 간에 IPsec를 사용할 수도 있습니다. 예를 들어 IPsec를 사용하여 내부 네트워크에서 Microsoft SQL Server를 실행 중인 컴퓨터에 연결하는 경계 네트워크에 있는 웹 서버나 응용 프로그램 서버의 통신을 보안할 수 있습니다. 자세한 내용은 Windows Server 2003 배포 가이드의 IPsec 인증 방법 선택을 참조하십시오.

IPsec용으로 권장되는 환경에 대한 자세한 내용은 Windows Server 2003 배포 가이드의 IPsec 필요성 결정을 참조하십시오.

서버 및 도메인 격리 계획

식별 단계가 진행되는 동안 상위 요구 사항을 만들었습니다. 다음 단계는 IPsec와 그룹 정책을 사용하여 서버 및 도메인 격리 가이드의 4장: 격리 그룹 설계 및 계획을 참조하여 구현 계획을 만드는 것입니다. 계획을 만들고 자세한 요구 사항을 정의한 후에는 다음 요소를 결합하여 해당 요구 사항이 구현됩니다.

격리 도메인과 격리 그룹을 위한 인바운드 및 아웃바운드 액세스 요구 사항:

  • 인바운드 및 아웃바운드 연결을 위한 IPsec IKE(인터넷 키 교환) 협상을 요구하는 격리 그룹을 위해 특별히 설계된 IPsec(인터넷 프로토콜 보안) 정책

  • IPsec로 보호되는 트래픽을 사용할 때 네트워크 액세스를 허용하거나 거부하는 네트워크 액세스 그룹이라고 하는 도메인 기반 보안 그룹  

격리 도메인 및 격리 그룹을 위한 네트워크 트래픽 보호 요구 사항:

  • 어떤 트래픽을 보호해야 하는지 적절히 식별하도록 설계된 IPsec 정책 필터

  • 필터가 식별하는 트래픽을 위해 필요한 인증 및 암호화 수준을 협상하는 IPsec 필터 동작

  • 트러스트된 호스트가 아웃바운드 연결을 시작할 때 일반 텍스트 통신을 허용할지를 제어하는 IPsec 필터 동작 설정

IPsec와 그룹 정책을 사용하여 서버 및 도메인 격리 가이드의 5장: 격리 그룹을 위한 IPsec 정책 만들기에서는 Windows Server 2003을 사용하여 그룹 정책과 Active Directory의 IPsec 정책을 통해 솔루션을 준비하는 과정과 Windows Server 2003 및 Microsoft Windows XP를 사용하여 도메인 구성원을 구성하는 과정을 설명합니다.

4단계: 배포

배포 단계의 목표는 이전 세 단계의 결과로 계획된 사항을 구현하는 것입니다. 이 단계에서는 필터 목록, 필터 동작, 격리 그룹을 구현하기 위한 IPsec 정책 등을 포함한 Active Directory의 IPsec 정책을 만듭니다. 다음 그림은 IPsec 정책의 다양한 구성 요소 및 서로 연결되는 방법을 보여 줍니다.

그림 9. IPsec 정책 구성 요소

그림 9. IPsec 정책 구성 요소

IPsec 정책의 자세한 구현 지침은 IPsec와 그룹 정책을 사용하여 서버 및 도메인 격리 가이드의 5장: 격리 그룹을 위한 IPsec 정책 만들기를 참조하십시오.

추가 정보

IPsec에 대한 자세한 내용을 보려면 Microsoft TechNet을 방문하여 "IPsec"를 검색하십시오.

Microsoft가 서버 간 통신을 보호하는 방법을 보려면 https://www.microsoft.com/technet/itshowcase/content/ipsecdomisolwp.mspx를 방문하십시오.

체크포인트: 서버 간에 보장된 보안 통신 확인

요구 사항

 

IPsec(Internet Protocol security)의 영향을 받는 네트워크 인프라의 현재 상태를 평가했습니다.

 

규정 및 준수에 따른 영향을 포함하여 서버 간에 보장된 보안 통신이 이루어지도록 하기 위한 조직 요구 사항을 식별했습니다.

 

IPsec를 사용하여 정의된 요구 사항을 충족하기 위한 계획을 개발하여 조직에 구현했습니다.

위에서 설명한 단계를 완료했다면 인프라 최적화 모델에서 서버 간에 보장된 보안 통신 확인 기능에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다. 서버 간 통신에 대한 추가 최적의 방법 리소스 지침을 따르도록 권장합니다.

다음 자체 평가 질문으로 이동하십시오.

요구 사항: 서버의 서비스 수준 계약 모니터링 및 보고

대상

모니터링 및 서비스 수준 보고를 위한 서비스 수준 계약(SLA)이 서버 중 80% 이상에 마련되어 있지 않으면 이 절을 읽어야 합니다.

개요

서비스 관리 접근 방식을 통한 IT 관리가 오늘날의 IT 산업에서 더욱 널리 퍼지고 있습니다. 조직에서 경쟁력을 유지하고 내부와 외부 소비자의 요구를 충족하기 위한 작업을 할 때 IT 인프라를 광역 네트워크(WAN)를 통해 연결되어 응용 프로그램을 실행하고 있는 서버 모음 이상으로 볼 필요가 있음을 알게 됩니다. 조직과 해당 직원은 이러한 리소스를 수익을 생성하고 소비자를 위한 기능을 제공하는 서비스로 보아야 합니다. 이 접근 방식을 따를 때는 서비스를 이루고 있는 모든 구성 요소와 각 구성 요소가 서비스의 가용성 수준에 미치는 영향을 이해해야 합니다. 또한 시간 경과에 따른 서비스 전달을 성공적으로 평가해야 시스템에서 제공하고 있는 서비스 품질을 명확히 이해할 수 있습니다.

구현자용 핵심 인프라 최적화 리소스 가이드: 기초 -> 표준화 가이드에서 중요한 서버를 모니터링하는 자동화된 방법이 표준화 수준의 조직에 있어야 한다는 요구 사항을 설명했습니다. 합리화 수준에서는 이 요구 사항을 조직의 모든 서버로 확장하고 모니터링 요구 사항의 일부로 서비스 수준 관리 요구 사항을 추가하고 있을 뿐입니다. 합리화 수준에는 가용성의 최소 한도가 필요 없습니다. 이 한도는 조직에서 각 IT 서비스에 적합한 것으로 결정됩니다.

1단계: 평가

표준화 수준과 마찬가지로 평가 단계에서는 조직의 인프라에 있는 모든 서버의 인벤토리를 조사해야 합니다. 서버와 사양을 수동으로 식별하거나 Systems Management Server(SMS) 2003 인벤토리 수집 기능과 같은 도구를 사용하여 인벤토리 프로세스를 자동화할 수 있습니다.

합리화 수준으로 이동하기 위해 추가로 실행할 수 있는 작업은 다음과 같습니다.

  • 조직의 기본 IT 서비스 판단(서비스 카탈로그)

  • 해당 서비스를 전달하는 데 필요한 인프라 구성 요소 할당

  • 기준이 되는 현재 서비스 수준을 판단하기 위한 정보 수집

서비스 수준 기준선 설정

기준선은 시간 단위로 그려진 선으로, 상황을 보여 주는 "스냅샷"을 찍습니다. 이 경우 기준선은 조직 내의 서비스 수준 관리를 보여 주는 사진입니다. 기준선은 특정 시점에 전달되고 있는 서비스를 보여 주는 사진을 제공하고 서비스 수준 관리에서 향후 목표를 달성하기 위한 계획을 제공합니다. IT 성능을 최적화하려면 목표뿐 아니라 프로세스가 시작될 현재 기준선도 분명히 파악해야 합니다.

서비스 수준 기준선 평가에 대한 자세한 지침은 MOF(Microsoft Operations Framework) 서비스 수준 관리 지침을 참조하십시오.

2단계: 식별

모든 서버의 인벤토리를 조사한 후에 수행하는 합리화 수준의 식별 단계는 기준선과 비교해서 적합한 서비스 수준을 정의하는 프로세스입니다. 서비스 수준 관리의 주요 목표는 장기적으로 비즈니스에 사용할 수 있는 서비스를 개선하고 현재 존재하는 서비스 공급 문제를 해결하는 것입니다.

IT 부서에 주어지는 많은 이점 중에는 서비스 개선 외에도 비즈니스 예상치에 대한 지식 증가, 비용 관리 향상 등이 있습니다. 서비스 수준 관리는 IT 부서에서 비즈니스 예상치를 충족할 수 있게 해 주며 해당 예상치를 확인하기 위한 대화 상자를 엽니다. 예를 들어 100%, 99.999% 또는 심지어 70%의 가용성으로 서비스를 전달하고자 하는 IT 부서에서 이 수치에 도달한 방법을 설명하지 못할 수 있습니다. 이 예상치를 문서화하고 서비스 수준 관리 프로세스의 조기 단계에서 동의한 경우가 아니면 IT 부서에서 실질적인 업무상 이점이 거의 없이 업무상 중요하지 않은 서비스(예: 담당자 개발, 하드웨어 및 소프트웨어 투자, 기타 비용이 많이 드는 작업)에 주력하는 사태가 발생할 수 있습니다.

서비스 수준 목표

서비스 수준 목표를 설정할 때 비즈니스가 요구하고 있는 사항을 평가하십시오. 여기에 프로세스 평가(예: 고객 만족도 등급 매기기, 응답 전화 통화, 쿼리에 대한 응답)가 포함될 수 있는 경우가 있습니다. 조직 내의 기존 기술을 사용하여 이러한 평가를 지원하는 방법이 있을 수 있습니다. 예를 들어 콜 센터 기술을 사용하여 개인별로 나가는 호출을 등록하는 서비스 데스크에 기록된 호출과 대조해 보는 보고서를 실행할 수 있습니다.

서비스 전달을 초래하는 복합 구성 요소 체인이 있는 경우가 있습니다. 그러나 종단 간 구성 요소 체인을 통해 이 목표의 서비스 전달을 평가할 수 있기만 하면 서비스의 최종 목표에 동의하는 것이 가능합니다.

서비스 수준 목표의 일반 평가 척도

평가 척도

예

가용성

서비스를 사용할 수 있는 기간(일 및 시간) 또는 이를 기반으로 하는 수치(%)

응답성 및 성능

서비스 속도 및 볼륨(처리량 또는 작업 부하 평가 척도), 데이터 취득 시간, 데이터 전송 속도 및 응답 시간, 기술 및 사용자 응답 속도

보안

서비스 보안

서비스 수준 목표의 평가 척도는 다음 기준을 사용하여 신중하게 고려해야 합니다.

  • 비즈니스 목표를 지원합니까?

  • 구체적입니까?

  • 평가할 수 있습니까?

  • IT 측에 상당한 노력이 요구될지라도 달성 가능합니까?

  • 비즈니스에 가져올 이점과 관련해서 현실적입니까?

3단계: 평가 및 계획

모든 서비스가 서비스 카탈로그에 정의되어 있고 원하는 서비스 수준이 정의되어 있으면 평가 및 계획 단계에서 IT 서비스에 있는 구성 요소의 모니터링을 자동화하는 기술을 평가하게 됩니다.

모니터링 소프트웨어

이 절에서는 소프트웨어를 사용하여 중요한 서버의 가용성을 모니터링하는 방법을 보여 줍니다. 이 예에서는 MOM(Microsoft Operations Manager)이 모니터링 역할에 사용됩니다. MOM을 사용하든 사용하지 않든 서버의 가용성 모니터링이나 다른 서비스 수준 평가에 사용할 소프트웨어에는 다음 기능이 있어야 합니다.

  • 서버 특성 정보를 수집하고 해당 특성을 기반으로 특정 모니터링 규칙을 적용하는 기능

  • 특정 규칙에서 정의한 대로 이벤트 로그 및 기타 공급업체로부터 데이터를 가져오는 기능

  • 성능 카운터를 기반으로 성능 데이터를 수집하는 기능

  • 규칙에서 지정한 기준을 기반으로 경고를 생성하는 기능

조직의 서비스 수준 계약에서 정의한 평가 척도에 따라 MOM을 유일한 데이터 수집 기술로 사용할 수 있습니다. 대부분의 경우 MOM 데이터는 다른 서비스에서 얻은 데이터로 보완해야 합니다. 예를 들어 변경 및 릴리스 관리의 일부로 서비스 수준을 정의한 경우에는 Systems Management Server 2003 보고와 같은 다른 메커니즘에서 얻은 상태 보고서를 사용해야 합니다.  

본 가이드를 게시할 당시 릴리스 프로세스가 진행 중인 System Center Operations Manager 2007은 Microsoft에서 제공하는 운영 관리 솔루션의 다음 버전으로, 서비스 지향 상태 모니터링, 클라이언트 모니터링 및 도메인 서비스 모니터링 기능을 추가합니다.   

MOM 가용성 관리 팩

MOM 가용성 관리 팩을 사용하면 서버의 이벤트 로그에서 데이터를 수집하여 분석하고 구성 가능한 보고서를 생성하여 살펴본 다음 해당 조직의 요구에 맞게 사용자 지정할 수 있습니다. 이러한 보고서를 사용하여 계획되거나 계획되지 않은 가동 중지 시간의 원인을 식별하고 향후 가동 중지 시간을 줄이기 위한 사전 조치를 취할 수 있습니다.

가용성 보고서를 사용하여 수행할 수 있는 작업은 다음과 같습니다.

  • 서버의 가용성 및 안정성 목표 충족 여부 판단

  • 몇 달이나 몇 년과 같은 특정 기간 동안 수집된 정보를 확인하여 동향을 추적하기 위한 보고서 필터링

  • 특정 영역에 대한 성능이 가장 좋은 컴퓨터와 가장 나쁜 컴퓨터 식별

  • 응답이 멈춘 특정 응용 프로그램이나 운영 체제 버전과 같은 문제 영역 식별

  • 시스템 종료 이벤트 추적기를 사용하여 수집된 정보 보기 및 분석

MOM 가용성 관리 팩은 서비스 수준 관리의 주요 모니터링 평가를 용이하게 하고 합리화 수준으로 이동하는 데 사용할 수 있는 중요한 도구가 될 수 있습니다. MOM 가용성 관리 팩에 대한 자세한 내용을 보려면 https://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/3e1dfa65-84a5-4e3e-9403-3ef9b47c6b68.mspx?mfr=true를 방문하십시오.

Microsoft Operations Manager 배포 계획

Microsoft Operations Manager를 서버 모니터링 기술로 선택했지만 아직 환경에 배포하지 않은 경우에는 Microsoft TechNet Operations Manager TechCenter의 일부로 MOM 2005 배포 계획 가이드를 참조하십시오.

System Center Operations Manager 2007

System Center Operations Manager 2007에서 제공하는 서비스 지향 모니터링 접근 방식을 사용하면 종단 간 정보 기술 서비스를 모니터링하고 대규모 환경과 조직에서 모니터링 규모를 조정하며 Microsoft 응용 프로그램 및 운영 체제 지식으로 운영 문제를 해결할 수 있습니다. 다음은 Operations Manager 2007에서 제공하는 다양한 기능 중 일부입니다.

서비스 지향 모니터링

환경의 상태를 보여 주는 통합 Operations Console을 사용하여 경고를 처리할 수 있습니다. Operations Console에 대한 자세한 내용은 Operations Manager 2007의 Operations Console을 참조하십시오.

보고서를 사용하여 여러 가지 방법으로 환경의 상태를 볼 수 있습니다. 보고에 대한 자세한 내용은 Operations Manager 2007의 보고를 참조하십시오.

기본 제공 관리 팩

복잡한 절차 없이 바로 쓸 수 있는 관리 팩은 많은 Microsoft 응용 프로그램에 모니터링 정보를 제공합니다. 또한 사용자 고유의 관리 팩을 만들어 사용자 지정 응용 프로그램을 모니터링할 수 있습니다. 관리 팩에 대한 자세한 내용은 Operations Manager 2007의 관리 팩을 참조하십시오.

대부분의 Microsoft 관리 팩에는 일반 응용 프로그램 문제를 해결하는 방법에 대한 정보가 포함되어 있습니다.

클라이언트 모니터링

클라이언트 모니터링을 사용하여 운영 체제와 응용 프로그램의 오류 보고서를 Microsoft에 전달하고 해당 오류 해결책을 받아볼 수 있습니다. 자세한 내용은 Operations Manager 2007의 클라이언트 모니터링을 참조하십시오.

Active Directory 도메인 서비스

Active Directory 도메인 서비스 통합은 에이전트 관리 컴퓨터를 관리 그룹에 할당하도록 허용하여 이전 투자를 사용합니다. Active Directory 도메인 서비스에 대한 자세한 내용은 Operations Manager 2007의 Active Directory 도메인 서비스 통합을 참조하십시오.

보안 모니터링 환경

환경의 일부가 보안 영역을 벗어나 있을 때조차 보안 기능을 사용하여 정보 기술 서비스와 응용 프로그램의 상태를 모니터링할 수 있습니다. 보안 기능에 대한 자세한 내용은 Operations Manager 2007의 보안 고려 사항 및 Operations Manager 2007 게이트웨이 서버를 참조하십시오.

역할 기반 권한 부여를 사용하여 운영자와 관리자가 취할 수 있는 조치를 조정할 수 있습니다. 역할에 대한 자세한 내용은 Operations Manager 2007의 사용자 역할 정보를 참조하십시오.

감사 모음은 관리되는 컴퓨터에서 보안 이벤트를 효율적으로 수집하고 분석에 사용할 보고서를 제공합니다. 감사 모음에 대한 자세한 내용은 ACS(Audit Collection Services)를 참조하십시오.

추가 정보

System Center Operations Manager 2007에 대한 자세한 내용을 보려면 http:/www.microsoft.com/technet/opsmgr/opsmgr2007_default.mspx를 방문하십시오.

4단계: 배포

서비스 카탈로그에 IT 서비스를 정의하고 기준선 또는 현재 서비스 수준을 판단하며 조직에 적합한 서비스 수준을 정의하고 서비스 수준 모니터링을 자동화하기 위한 계획을 판단한 후에는 가용성 모니터링 솔루션을 구현해야 합니다.

조직에서 Microsoft Operations Manager를 시스템의 가용성 모니터링을 수행할 기술로 선택한 경우 Microsoft TechNet의 MOM 2005 배포 가이드 및 System Center Operations Manager 2007 배포 가이드에서 자세한 배포 지침을 확인할 수 있습니다.  

추가 정보

자세한 내용을 보려면 Microsoft TechNet을 방문하여 "SLA"를 검색하십시오.

체크포인트: 서버의 서비스 수준 계약 모니터링 및 보고

요구 사항

 

서비스 카탈로그에 조직의 IT 서비스를 정의했습니다.

 

정의된 서비스의 기본 서비스 수준이나 현재 서비스 수준을 판단했습니다.

 

조직에 적합한 서비스 수준을 정의했으며 서비스 수준 모니터링을 자동화하기 위한 계획을 판단했습니다.

 

자동화된 가용성 모니터링 솔루션을 구현했습니다.

위에서 설명한 단계를 완료했다면 핵심 인프라 최적화 모델에서 서버의 서비스 수준 계약 모니터링 및 보고 기능에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다. Microsoft Operations Framework에서 서버 SLA 설정 및 모니터링에 대한 추가 최적의 방법 리소스 지침을 따르도록 권장합니다.

다음 자체 평가 질문으로 이동하십시오.

요구 사항: 상태 정보의 보안 통신 메커니즘

대상

SIP(Session Initiation Protocol)와 같은 상태 정보의 보안 통신 메커니즘을 제공하고 있지 않으면 이 절을 읽어야 합니다.

개요

상태 정보는 특정 사용자의 위치와 통신 가용성을 설명하는 실시간 정보입니다. 기업 전체의 상태 정보를 설정하면 생산성이 상당히 증가할 수 있습니다. 작업자 간의 공동 작업과 통신은 추적 시간이 줄었을 때 더욱 효율적입니다.

온라인 상태 정보를 사용하면 해당 시간에 온라인 상태이면서 통신할 수 있는 사람이 누구인지 식별할 수 있습니다. 온라인 상태 정보를 사용하고 필요한 소프트웨어를 설치하면 사이트 모음에 개인 이름이 나타날 때마다 해당 이름 옆에 온라인 상태 표시기가 추가됩니다. 온라인 상태 표시기는 개인이 오프라인 또는 온라인 상태이면서 인스턴트 메시징 클라이언트를 통해 쿼리에 응답할 수 있는지를 보여 줍니다. 개인이 온라인 상태일 때는 온라인 상태 표시기를 클릭하여 인스턴트 메시지를 보낼 수 있습니다. 지식이 있는 원본에 대한 이 직접 액세스는 팀 구성원의 작업 효과와 효율성을 높이는 데 도움이 됩니다.

상태 정보 보안 통신을 제공하기 위한 조치를 취할 수 있습니다. 인스턴트 메시징 시스템은 디렉터리에 있는 사용자 개체 간의 보안 통신을 제공할 수 있습니다. 상태 정보 통신에 SIP(Session Initiation Protocol)와 같은 기술을 제공하여 표준화 수준에서 합리화 수준으로 이동할 수 있습니다. 합리화 수준에서는 SIP를 통한 통신도 보안해야 합니다. 즉, 통신이 보관되고 디렉터리 서비스를 통해 운영되며 인증서가 사용됩니다.

상태 정보의 비즈니스 가치에 대해 자세히 알려면 Live Communications Server 2005 문서: 상태 정보의 비즈니스 가치 문서를 다운로드하십시오.

1단계: 평가

평가 단계에서는 조직의 사용자가 현재 다른 사용자의 상태 정보를 어떻게 식별하고 있는지 검토합니다. 많은 조직에서 인터넷 서비스 공급자가 제공한 인스턴트 메시징 기술을 사용합니다. 온라인 상태 정보 사용은 공동 작업이 중요한 많은 환경에서 유익하지만 그룹 구성원 간 공동 작업 증가의 이점과 보안 및 준수에 대한 요구 사항(특히 인스턴트 메시징 클라이언트 배포와 관련된 요구 사항) 간의 균형을 맞추는 것이 중요합니다. 상태 정보 계획에는 인스턴트 메시징 클라이언트로 들어오거나 인스턴스 메시징 클라이언트에서 나가는 내부 통신과 외부 통신이 둘 다 규제 지침 및 비즈니스 관례와 함께 회사 전체의 보안 및 준수 정책과 일치하도록 보장하는 것이 포함되어야 합니다. 많은 조직에서 전자 통신에 대한 기록 보관 요구 사항에 따라 인스턴트 메시징 대화 내용을 보관해야 합니다. 예를 들어 사베인스-옥슬리 규정이 적용되는 조직에서는 기록 보관 요구 사항의 일부로 인스턴트 메시징 대화 내용을 보관해야 합니다.

평가 단계의 기본 결과물은 조직에서 현재 사용하는 소프트웨어 응용 프로그램의 인벤토리를 조사하여 상태 정보와 인스턴트 메시징을 사용하는 것입니다. 고도로 잠긴 환경에서는 정책으로 인해 사용자가 응용 프로그램을 설치하지 못하게 될 수 있지만 그래도 여전히 모든 시스템의 인벤토리를 조사하는 것이 좋습니다. Systems Management Server 2003이나 응용 프로그램 호환성 도구 키트(ACT)와 같은 도구로 환경의 인벤토리를 중앙에서 조사할 수 있습니다.

2단계: 식별

식별 단계에서는 규정이나 조직 정책에 따른 상태 정보 사용에 대한 상위 요구 사항을 모으기 시작합니다. 앞서 설명한 대로 많은 조직의 경우 반드시 인스턴트 메시징 대화 내용을 조직 내에 보관해야 합니다. 또한 상태 정보 표시기가 전자 메일 및 공동 작업 소프트웨어와 같은 다른 생산성 응용 프로그램에 통합되는 정도를 조사해야 합니다. 식별 단계의 결과로 얻은 요구 사항 명세는 다음 단계에서 상태 정보를 평가하고 계획할 때 사용됩니다.

상태 정보를 Microsoft Office SharePoint® Server에 사용하는 방법을 보려면 http://technet2,microsoft.com/Office/en-us/library/3f53f3d3-85b8-42e5-8213-afb5eec7e8651033.mspx를 방문하십시오.

상태 정보 기능과 Microsoft Office Outlook의 통합에 대한 정보를 보려면 http://technet2,microsoft.com/Office/en-us/library/53c024e4-db55-4858-9ef6-5cba97c1afbd1033.mspx를 방문하십시오.

3단계: 평가 및 계획

평가 및 계획 단계에서는 해당 환경에서의 상태 정보 사용에 적용되는 특정 기술을 검토합니다. 다음 절에서는 프로토콜에 중점을 두고 상태 정보 사용에 적용할 수 있는 Microsoft 기술을 나열합니다.

SIP(Session Initiation Protocol)

HTTP(HyperText Transfer Protocol)와 유사한 SIP(Session Initiation Protocol)는 텍스트 기반 응용 프로그램 계층 신호 및 호출 제어 프로토콜입니다. SIP는 SIP 세션을 만들고 수정하며 종료하는 데 사용됩니다. 유니캐스트 통신과 멀티캐스트 통신이 모두 지원됩니다. SIP가 텍스트 기반이기 때문에 구현, 개발 및 디버깅이 H.323을 사용할 경우보다 더욱 쉽습니다. SIP를 사용하여 한 사용자가 대화 또는 멀티미디어 세션에 참가하도록 다른 사용자를 명시적으로 초대할 수 있습니다. 두 번째 사용자가 초대를 받아들이면 SIP 세션이 시작됩니다. SIP는 이미 설정된 세션에 대한 추가 사용자 초대도 지원합니다.

실시간 통신 프로토콜에 대한 자세한 내용을 보려면 https://www.microsoft.com/technet/prodtechnol/winxppro/plan/rtcprot.mspx를 방문하십시오.

Live Communications Server

Live Communications Server 2005는 향상된 보안, 다른 Microsoft 제품과의 긴밀한 통합, 확장 가능한 산업 표준 개발 플랫폼 등을 제공하는 확장 가능한 엔터프라이즈급 솔루션의 일부로 인스턴트 메시징(IM) 및 상태 정보를 전달합니다. Microsoft Office Live Communications Server 2005는 SIP를 상태 정보에 활용하는 다음 보안 통신 및 공동 작업 도구와 기능을 제공할 수 있습니다.

  • 인스턴트 메시징

  • 오디오 및 비디오 통신

  • 데이터 공동 작업

Microsoft Office Live Communications Server의 계획, 배포 및 운영 정보를 알아보려면 Microsoft Office Live Communications Server TechCenter를 방문하십시오.

Office Communicator 2005 및 Office Communicator 2007

Office Communicator 2005와 Office Communicator 2007은 통합 인스턴스 메시징을 위해 인스턴트 메시징과 전화 통신을 통합하는 기업용 보안 메시징 클라이언트입니다. Office Communicator 2007은 Microsoft Word, Excel®, PowerPoint, OneNote, Groove 및 SharePoint Server를 포함한 2007 Microsoft Office System에서 프로그램과의 통합 기능을 제공합니다.

Office Communicator 2005에 대한 자세한 내용은 Office Communicator 2005 Resource Center를 참조하십시오.

Office Communicator 2007에 대한 자세한 내용은 Microsoft Office Communicator 2007 제품 개요를 참조하십시오.

Office Outlook 2007

조직에서 Microsoft Office Outlook 2007을 사용하고 있으면 전체 주소 목록에 있는 사용자의 자세한 연락처 정보의 일부로 상태 정보를 사용할 수 있습니다. 구성된 상태 정보는 수신된 전자 메일 메시지에도 표시됩니다. Office Outlook 2007은 Office Communicator 2005나 Office Communicator 2007과 통합할 수 있습니다.

상태 정보를 사용하도록 Office Outlook 2007 구성에 대한 자세한 내용을 보려면 http://technet2,microsoft.com/Office/en-us/library/53c024e4-db55-4858-9ef6-5cba97c1afbd1033.mspx를 방문하십시오.

Office SharePoint Server 2007

조직에서 Microsoft Office SharePoint Server 2007을 사용하고 있으면 SharePoint 사이트에 액세스하여 온라인 상태인 다른 참가자가 누구인지를 확인하고 해당 참가자에게 인스턴트 메시지를 보낼 수 있는 개인에 대해 온라인 상태 정보를 사용할 수 있습니다. 온라인 상태 정보는 사이트 구성원이 질문에 대답할 수 있는 사람을 빠르게 찾는 데 도움이 되는 강력한 공동 작업 도구가 될 수 있습니다.

Office SharePoint Server 2007의 상태 정보 통합 계획에 대한 자세한 내용은 ** Office SharePoint Server 2007 계획 및 아키텍처 가이드를 참조하십시오.

상태 정보 및 관리되는 인스턴트 메시징 인프라 계획

상태 정보를 조직 내에서 사용하기 위해 기술을 평가한 후에 수행할 다음 작업은 선택한 인프라를 계획하고 구성하는 것입니다. 대개 통합된 상태 정보를 조직 내에서 사용하는 데 필요한 사항은 다음과 같습니다.

  • 디렉터리 서비스

  • 글로벌 카탈로그

  • 배포되어 정확하게 구성된 DNS

  • 공용 키(PKI) 및 인증 기관(CA) 인프라

  • 백엔드 데이터베이스

합리화 수준에 도달하면 대개 이러한 구성 요소 요구 사항이 이미 조직에 마련되어 있습니다. 다음 다이어그램은 Live Communications Server 2005 Enterprise Edition 인프라의 샘플 아키텍처를 제공합니다.

그림 10. Live Communications Server Enterprise Edition 인프라

그림 10. Live Communications Server Enterprise Edition 인프라

평가 및 계획 단계의 최종 결과물은 선택한 상태 정보 인프라의 배포 계획과 아키텍처 설계입니다. Microsoft 기술을 통한 상태 정보 계획에 대한 자세한 내용은 Microsoft Office Live Communications Server 2005 서비스 팩 1 계획 가이드를 참조하십시오.

4단계: 배포

지금쯤은 벌써 이전 단계를 통해 현재 인스턴트 메시징 및 상태 정보 사용 방법의 인벤토리, 상태 정보와 관리되는 인스턴트 메시징을 구현하기 위한 상위 요구 사항 지정, 상태 정보와 인스턴트 메시징 기술의 평가, 선택한 솔루션의 배포 계획 등이 파생되었을 것입니다. 배포 단계에서는 선택한 상태 정보 솔루션을 구현합니다. 또한 새로운 기술의 배포에 부수적으로 기존 또는 관리되지 않은 인스턴트 메시징을 관리하는 데 사용되는 정책을 검토해야 합니다. 여기에는 파일 송수신을 위한 정책 제한 사항 구현, 새로운 응용 프로그램의 설치 차단, 조직에 적합한 정의된 정책 지침을 충족하지 않는 관리되지 않은 응용 프로그램 제거 등이 포함될 수 있습니다.

Live Communications Server 2005를 선택한 경우 Microsoft TechNet의 Microsoft Office Live Communications Server 2005 서비스 팩 1 계획 가이드에서 자세한 배포 계획 및 실행 정보를 찾을 수 있습니다.  

추가 정보

자세한 내용을 보려면 Microsoft TechNet을 방문하여 "presence"를 검색하십시오.

Microsoft가 Microsoft Office Live Communications Server 2005를 사용하는 방법을 보려면 https://www.microsoft.com/technet/itshowcase/content/lcs2005twp.mspx를 방문하십시오.

체크포인트: 상태 정보의 보안 통신 메커니즘

요구 사항

 

상태 정보 및 인스턴트 통신에 사용되는 현재 관리되지 않는 방법을 평가했습니다.

 

산업 또는 지역별 규정 및 정책을 준수하여 상태 정보 및 인스턴트 메시징의 요구 사항 명세를 만들었습니다.

 

상태 정보 및 인스턴트 기술을 평가했으며 선택한 솔루션을 구현하기 위한 계획을 만들었습니다.

 

관리되는 인스턴스 메시징을 통해 최저한도로 상태 정보를 구현했으며 공동 작업 및 전자 메일 인프라를 통해 선택적으로 상태 정보를 구현했습니다.

위에서 설명한 단계를 완료했다면 인프라 최적화 모델에서 상태 정보의 보안 통신 메커니즘 기능에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다.  

다음 자체 평가 질문으로 이동하십시오.

요구 사항: 무선 네트워크 인증 및 권한 부여용 Active Directory 및 IAS/RADIUS

대상

Active Directory와 IAS/RADIUS를 인증 및 권한 부여에 사용하는 보안 무선 네트워크를 배포하지 않았으면 이 절을 읽어야 합니다.

개요

무선 기술은 우리를 구리선에서 해방시킵니다. 사용자에게 노트북 컴퓨터, PDA, Pocket PC, Tablet PC 또는 휴대폰이 있으면 무선 신호를 사용할 수 있는 곳 어디서든지 온라인 상태를 유지할 수 있습니다. 무선 기술 이면의 기본 원리는 신호 수신기에 전송될 전자기파로 신호를 전달할 수 있다는 것입니다. 그러나 두 무선 장치가 서로 이해하게 만들려면 통신용 프로토콜이 필요합니다. RADIUS(Remote Authentication Dial-In User Service)는 RADIUS 클라이언트가 인증과 계정 요청을 RADIUS 서버에 보내는 클라이언트/서버 프로토콜입니다. RADIUS 서버는 사용자 계정의 원격 액세스 인증 자격 증명을 검사하고 원격 액세스 계정 이벤트를 기록합니다.

Windows Server 2003의 IAS(Internet Authentication Service)나 Windows Server 코드 이름 "Longhorn"과 함께 향후에 제공될 NPS(Network Policy Server)는 RADIUS 서버와 프록시의 Microsoft 구현입니다. RADIUS 서버로서 IAS는 무선, 인증 스위치, 원격 액세스 전화 접속 및 가상 사설망(VPN) 연결을 포함한 많은 유형의 네트워크 액세스에 대해 중앙 집중식 연결 인증, 권한 부여 및 계정 작업을 수행합니다. RADIUS 프록시로서는 다른 RADIUS 서버에 인증 및 계정 메시지를 전달합니다. RADIUS는 IETF(Internet Engineering Task Force) 표준입니다.

1단계: 평가

본 가이드의 이전 절과 구현자용 핵심 인프라 최적화 리소스 가이드: 기초 -> 표준화에서 IT 환경 액세스를 위한 사용자 인증의 중요성에 대해 알아보았습니다. 합리화 수준으로 이동하려면 네트워크 액세스 방법과 무관하게 인증 및 권한 부여를 사용자로 확장하여 다음 단계를 수행해야 합니다.

평가 단계에서는 조직에 마련되어 있는 기존 무선 인프라의 인벤토리를 다시 조사합니다. 이미 많은 조직에 무선 네트워킹 기능이 마련되어 있으며 무선 네트워킹 기술의 일반 유형에는 다음 3가지가 있습니다.

  • 무선 LAN(WLAN)

  • 무선 개인 영역 네트워크(WPAN)

  • 무선 광역 네트워크(WWAN)

다음 절에서는 이러한 네트워크 유형과 사용 가능한 무선 기술을 각각 설명합니다. 핵심 인프라 최적화 모델에서는 조직에서 사용자나 개체 인증을 적극적으로 제어할 수 있는 유일한 무선 네트워크 유형으로서 WLAN에 중점을 둡니다.

무선 LAN(WLAN)

WLAN 기술을 사용하면 회사 사무실이나 건물과 같은 개인 영역 내에서 또는 공항이나 상점과 같은 공용 영역 내에서 무선 네트워크 연결을 사용할 수 있습니다. WLAN은 일반적으로 기존 유선 LAN 환경을 보완하는 데 사용되며 대개 네트워크 속도와 연결 안정성을 희생하여 WLAN 사용자에게 더 높은 유연성을 제공합니다.

무선 개인 영역 네트워크(WPAN)

WPAN 기술을 사용하면 사용자가 PDA, 휴대폰 또는 랩톱과 같은 개인용 장치 간의 무선 통신을 필요에 따라 설정할 수 있습니다. 일반적으로 이러한 장치는 POS(Personal Operating Space)라고 하는 영역인 몇 미터 이내 거리에서 통신하도록 설계되었습니다.

무선 광역 네트워크(WWAN)

WWAN 기술을 사용하면 도시나 국가와 같은 넓은 지역에 분산되어 있는 공용 또는 개인 네트워크를 통해 무선 통신을 사용할 수 있습니다.

평가 단계의 결과는 조직에서 사용 중인 기존 WLAN 토폴로지의 문서화입니다. 이 토폴로지는 보안 사용자 인증을 최적화하는 방법을 계획하는 동안 평가 및 계획 단계에서 사용됩니다.

2단계: 식별

식별 단계에서는 유선 LAN 인프라에 사용된 보안 수준을 반영하고자 하는 노력의 일환으로 WLAN으로 연결된 장치를 인증하는 보안 수단 식별에 중점을 둡니다. 이 절에서는 보안 무선 네트워킹 인프라를 제공하는 데 사용되는 다음 기술과 토폴로지를 소개합니다.

  • IEEE 802.11을 통한 무선 인증

  • RADIUS(Remote Authentication Dial–in User Service)

  • EAP(확장할 수 있는 인증 프로토콜)

  • IAS(인터넷 인증 서비스)

  • 인증서

무선 프로토콜과 인증에 대한 자세한 기술 지침은 무선 배포 기술 및 구성 요소 개요를 참조하십시오.

IEEE 802.11을 통한 무선 인증

IEEE(Institute of Electrical and Electronics Engineers, Inc.) 802.11은 무선 통신용 물리적 계층과 미디어 액세스 제어(MAC) 하위 계층을 정의하는 공유 액세스 WLAN의 산업 표준입니다. 원래의 IEEE 802.11 표준에서는 다음 절에서 설명할 아래와 같은 유형의 인증을 정의했습니다.

개방형 시스템 인증

개방형 시스템 인증은 무선 어댑터의 MAC 주소를 통한 식별만 제공하고 인증은 제공하지 않습니다. 개방형 시스템 인증은 인증이 필요 없을 때 사용됩니다. 개방형 시스템 인증은 다음 프로세스를 사용하는 기본 인증 알고리즘입니다.

  1. 인증을 시작하는 무선 클라이언트가 해당 ID를 포함하는 IEEE 802.11 인증 관리 프레임을 보냅니다.

  2. 수신하는 무선 노드가 시작하는 스테이션의 ID를 확인하고 인증 확인 프레임을 다시 보냅니다.

일부 무선 AP를 통해 MAC 필터링으로 알려진 기능을 사용하여 허용된 무선 클라이언트의 MAC 주소를 구성할 수 있습니다. 그러나 무선 클라이언트의 MAC 주소를 손쉽게 판단하여 스푸핑할 수 있기 때문에 MAC 필터링은 보안을 제공하지 않습니다.

공유 키 인증

공유 키 인증에서는 인증을 시작하는 스테이션이 공유 암호를 알고 있는지 확인합니다. 원래의 802.11 표준에 따라 공유 암호는 IEEE 802.11과 무관한 보안 채널을 통해 참가하는 무선 클라이언트에 전달됩니다. 실제로 공유 암호는 무선 AP와 무선 클라이언트에 수동으로 구성됩니다.

공유 키 인증에서는 다음 프로세스를 사용합니다.

  1. 인증을 시작하는 무선 클라이언트가 ID 어설션과 인증 요청으로 이루어져 있는 프레임을 보냅니다.

  2. 인증하는 무선 노드가 인증을 시작하는 무선 노드에 챌린지 텍스트로 응답합니다.

  3. 인증을 시작하는 무선 노드가 인증하는 무선 노드에 WEP를 사용하여 암호화된 챌린지 텍스트와 공유 키 인증 암호에서 파생된 암호화 키로 회신합니다.

  4. 인증하는 무선 노드가 해독된 챌린지 텍스트가 두 번째 프레임에서 원래 보낸 챌린지 텍스트와 일치하는지 확인하면 인증 결과가 긍정적입니다. 인증하는 무선 노드가 인증 결과를 보냅니다.

공유 키 인증 암호를 수동으로 배포하고 입력해야 하기 때문에 큰 인프라 네트워크 모드(회사 구내 및 공공 장소)에서는 이 인증 방법의 규모가 적절히 조정되지 않습니다.

RADIUS(Remote Authentication Dial–in User Service)

RADIUS는 널리 배포된 프로토콜로, 네트워크 액세스를 위한 중앙 집중식 인증, 권한 부여 및 계정 작업을 수행할 수 있게 해 줍니다. 원래 전화 접속 원격 액세스용으로 개발된 RADIUS는 이제 무선 AP, 인증 이더넷 스위치, 가상 사설망(VPN) 서버, 디지털 가입자 회선(DSL) 액세스 서버 및 기타 네트워크 액세스 서버에서 지원합니다.

EAP(확장할 수 있는 인증 프로토콜)

EAP(확장할 수 있는 인증 프로토콜)는 원래 임의의 네트워크 액세스 인증 방법을 개발할 수 있게 해 주는 지점 간 프로토콜(PPP)의 확장으로 생성되었습니다. Challenge-Handshake 인증 프로토콜(CHAP)과 같은 PPP 인증 프로토콜을 사용하면 특정 인증 메커니즘이 링크 설정 단계 중에 선택됩니다. 연결 인증 단계가 진행되는 동안 조정된 인증 프로토콜이 연결의 유효성 검사에 사용됩니다. 인증 프로토콜 자체는 특정 순서로 전송되는 고정된 일련의 메시지입니다. EAP를 사용하면 특정 인증 메커니즘이 PPP 연결의 링크 설정 단계 중에 선택되지 않습니다. 대신에 각각의 PPP 피어가 연결 인증 단계 중에 EAP를 수행하도록 조정됩니다. 연결 인증 단계에 도달하면 피어가 EAP 유형으로 알려진 특정 EAP 인증 구성표의 사용을 조정합니다.

IAS(인터넷 인증 서비스)

IAS는 RADIUS 서버의 Microsoft 구현(Windows Server 2003 및 Windows 2000 Server의 경우)이자 RADIUS 프록시의 Microsoft 구현(Windows Server 2003의 경우)입니다. IAS는 무선, 인증 스위치, 전화 접속 및 가상 사설망(VPN) 원격 액세스, 라우터 간 연결을 포함한 많은 유형의 네트워크 액세스에 대해 중앙 집중식 연결 인증, 권한 부여 및 계정 작업을 수행합니다. IAS는 기종이 다른 무선, 스위치, 원격 액세스 또는 VPN 장비 집합을 사용할 수 있게 해 주며 Windows Server 2003이나 Windows 2000 Server의 라우팅 및 원격 액세스 서비스와 함께 사용할 수 있습니다.

IAS 서버가 Active Directory 기반 도메인의 구성원인 경우 IAS는 Active Directory를 해당 사용자 계정 데이터베이스로 사용하며 Single Sign-On 솔루션에 속합니다. 같은 자격 증명 집합이 네트워크 액세스 제어(네트워크 액세스 인증 및 권한 부여)와 Active Directory 기반 도메인에 대한 로그온에 사용됩니다.

인증서

인증서는 무선 액세스 지점으로 무선 클라이언트를 인증하는 데 사용됩니다. Windows Vista, Windows XP, Windows Server 2003, Windows Server "Longhorn" 및 Windows 2000 Server를 실행하는 무선 클라이언트는 인증서를 사용하여 컴퓨터를 인증할 수 있습니다.

식별 단계 요약

이 요구 사항의 식별 단계는 무선 네트워킹에 대한 기술 옵션을 평가하는 데 사용되는 요소를 많이 포함한다는 점에서 다른 단계와 다릅니다. 대개 거의 모든 무선 네트워킹 기술에 사용된 프로토콜과 표준이 일치하기 때문입니다. 보안 무선 인증을 위해 원하는 결과나 요구 사항 명세를 식별하려면 표준과 프로토콜을 이해해야 합니다. 자세한 내용은 Microsoft TechNet의 무선 배포 기술 및 구성 요소 개요 및 무선 네트워킹 보안 가이드를 참조하십시오.

3단계: 평가 및 계획

무선 네트워크 보안에 필요한 기술과 프로토콜을 식별하고 상위 요구 사항 명세를 개발했으므로 평가 및 계획 단계에서 무선 네트워크 배포 프로젝트 계획 및 구현에 사용할 수 있는 기술을 평가하게 됩니다.

합리화 수준의 다른 요구 사항이 이행되었다고 가정하면 Windows XP SP2 이상의 클라이언트 컴퓨터와 Windows 2000 Server 이상의 서버를 포함하여 보안 무선 인프라 구현에 필요한 많은 구성 요소가 아마도 마련되어 있을 것입니다.

Windows Server IAS

Windows Server IAS는 보안 네트워크 액세스가 필요한 조직에 다음 솔루션을 제공합니다.

  • RFC 2865, 2866 및 2869에서 설명한 IEEE 사양을 충족하는 공급업체의 RADIUS 서버 및 클라이언트와의 호환성.

  • Active Directory 디렉터리 서비스와의 통합. IAS를 사용하면 Active Directory를 사용자 인증, 권한 부여 및 클라이언트 구성에 활용할 수 있으므로 관리 비용이 절감됩니다.

  • 표준 기반의 강력한 인증 방법을 네트워크 액세스에 사용.

  • ISP에 외부 발주된 네트워크 액세스 관리. IAS를 사용하면 조직과 ISP 간에 ISP가 로밍 사용자의 부서에 해당 직원의 네트워크 사용 요금을 청구할 수 있는 계약을 체결할 수 있습니다. 이렇게 하면 각 직원마다 경비 내역서를 제출하거나 회사 네트워크에 원격으로 연결하기 위해 로밍 계정을 만들지 않아도 됩니다.

  • 네트워크 보안 강화 수단으로 무선 액세스 지점의 동적 키 관리.

Windows 2000 Server와 Windows Server 2003 운영 체제의 인터넷 인증 서비스(IAS) 구성 요소를 실행하는 서버는 전화 접속, 가상 사설망(VPN), 무선 및 802.1x 인증 스위치 액세스를 포함한 많은 유형의 네트워크 액세스에 대해 중앙 집중식 인증, 권한 부여, 감사 및 계정 작업을 수행합니다. IAS는 RADIUS(Remote Authentication Dial-In User Service) 프로토콜의 Microsoft 구현입니다.

자세한 내용은 Windows Server 2003 보안 가이드를 참조하십시오.

Active Directory

Active Directory 도메인의 구성원으로 구현한 IAS는 Active Directory 디렉터리 서비스를 해당 사용자 계정 데이터베이스로 사용하며 Single Sign-On 솔루션에 속합니다. Single Sign-On을 통해 사용자는 인증 및 권한 부여 프로세스가 진행되는 동안 계정 자격 증명(사용자 이름과 암호 또는 인증서)을 한 번만 제공합니다. 그런 다음 이러한 자격 증명은 Active Directory 도메인에 대한 로그온과 네트워크 액세스 제어(네트워크 액세스 인증 및 권한 부여)에 사용됩니다.

보안 무선 네트워크 계획

Microsoft 기술을 사용하는 기본 무선 보안 아키텍처에는 2가지가 있습니다. 첫 번째 방법에서는 IPsec VPN을, 두 번째 방법에서는 802.1x EAP(확장할 수 있는 인증 프로토콜)를 사용합니다. 두 방법 모두 사용자 인증과 권한 부여를 보장하고 데이터 기밀성과 무결성을 보호하는 것이 목적입니다.

IPsec VPN 인증

IPsec VPN의 기본 구조에서는 무선 클라이언트가 개방형 무선 액세스 지점(AP)에 연결한 다음 IPsec VPN으로 조직의 보호된 인트라넷에 액세스하기 위한 인증을 받습니다.

EAP를 통한 802.1x 인증

EAP-TLS 및 컴퓨터 인증서를 통한 802.1x 인증을 사용하여 무선 클라이언트와 서버를 모두 인증할 수 있습니다. 또한 정기적으로 새 키를 자동으로 보내어 WEP 키를 관리하므로 알려진 WEP 키 취약점 중 일부를 피할 수 있습니다. 데이터 기밀성은 이러한 동적 WEP 키로 보호됩니다.

구현 계획을 만들 때 두 방법 중 아무거나 사용할 수 있습니다. 자세한 내용은 Microsoft TechNet의 무선 네트워킹 보안 가이드를 참조하십시오.

Microsoft TechNet의 PEAP와 암호로 무선 LAN 보안 및 인증서 서비스로 무선 LAN 보안 가이드도 참조하십시오.

4단계: 배포

이 프로세스의 최종 단계는 조직에서 보호된 무선 액세스를 배포하는 것입니다. Windows 기술을 통한 802.1x 인증 방법을 선택한 경우 Microsoft Windows를 통한 보호된 802.11 네트워크 배포 가이드에서 자세한 단계별 배포 지침을 확인할 수 있습니다.

추가 정보

Active Directory와 IAS/RADIUS에 대한 자세한 내용을 보려면 다음 웹 사이트를 방문하십시오.

Microsoft TechNet을 방문하여 "IAS"나 "RADIUS"를 검색할 수도 있습니다.

Microsoft가 IAS를 사용하는 방법을 보려면 https://www.microsoft.com/technet/itshowcase/content/secnetwkperim.mspx를 방문하십시오.

체크포인트: 무선 네트워크 인증 및 권한 부여용 Active Directory 및 IAS/RADIUS

요구 사항

 

현재 무선 액세스 및 관련 토폴로지를 확인했습니다.

 

무선 기술, 프로토콜 및 표준을 평가했습니다.

 

보안 무선 인증 인프라를 위한 계획을 개발하여 구현했습니다.

위에서 설명한 단계를 완료했다면 핵심 인프라 최적화 모델에서 무선 네트워크 인증 및 권한 부여용 Active Directory 및 IAS/RADIUS 기능에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다. Microsoft TechNet의 Windows XP용 무선 리소스에서 추가 최적의 방법 리소스 지침을 따르도록 권장합니다.

다음 자체 평가 질문으로 이동하십시오.

요구 사항: 중앙 관리식 인증서 서비스

대상

중앙 관리식 인증서 서비스 공용 키 구조(PKI)가 마련되어 있지 않으면 이 절을 읽어야 합니다.

개요

컴퓨터 네트워크는 사용자의 단순한 상태 정보가 ID를 입증하는 충분한 증거 역할을 할 수 있는 폐쇄된 시스템이 더 이상 아닙니다. 오늘날의 정보 상호 연결 시대에서 조직 네트워크는 인트라넷, 인터넷 사이트 및 엑스트라넷으로 이루어져 있을 수 있으며 이 모든 것은 악의를 지닌 채 전자 메일 메시지에서 e-Commerce 트랜잭션에 이르는 다양한 데이터 파일을 찾아 다니는 개인의 침입에 취약합니다. 이 취약점으로 인한 위험을 완화하려면 사용자 ID를 설정하고 유지하기 위한 메커니즘이 필요합니다. 사용자의 중앙 관리식 전자 ID는 다음을 제공할 수 있습니다.

  • 정보의 액세스 가능성. 정보 자산은 권한이 있는 사용자가 액세스할 수 있어야 하고 무단 액세스나 수정으로부터 보호해야 합니다. 암호가 도움이 될 수 있지만 보안 시스템마다 다른 암호를 사용하여 액세스하는 사용자가 기억하기 쉽고 그에 따라 해독하기도 쉬운 암호를 선택할 수 있습니다.

  • ID 부인 방지. 정보는 합법적인 사람이 보낸 것이라는 확신이 있는 상태로 사용자 간에 보내야 합니다. 정보가 도중에 변경되지 않았다는 합당한 확신을 제공하는 것도 필요합니다.

  • 개인 정보 보호. 사용자는 타인이 액세스하거나 사용할 수 없다는 확신이 있는 상태로 다른 사용자에게 정보를 보내거나 컴퓨터 시스템에 액세스할 수 있어야 합니다. 사용자나 시스템이 정보에 액세스할 수 있는 사람을 정의할 수 있습니다. 개인 정보 보호는 정보가 공용 인터넷을 통해 전송될 때 특히 중요합니다.

이러한 요구 사항에서는 전자 정보 자산을 다루며 대부분의 조직에 직접적인 영향을 미칩니다. 이러한 요구 사항을 다루기 위해 구현되는 메커니즘은 관리 효율성과 보안이 모두 우수해야 합니다. 공용 키 구조(PKI)는 디지털 인증서의 사용과 함께 이러한 요구 사항을 이행하는 데 적합한 기술입니다. PKI를 사용하면 인증된 엔터티와 트러스트된 리소스 간에 디지털 인증서를 교환할 수 있습니다. PKI의 인증서는 조직 내부와 외부에서 데이터를 보안하고 리소스의 ID 자격 증명을 관리하는 데 사용됩니다. 분명한 점은 PKI 자체가 신뢰할 수 있어야 하므로 자격을 미리 갖춘 조직이나 그와 같은 조직의 일부에 의해 관리된다는 것입니다. 그와 같은 조직을 인증 기관(CA)이라고 할 수 있지만 대개는 인증서 소프트웨어를 실행하는 컴퓨터만 CA라고 합니다. 조직을 가리키든 인증을 지원하는 소프트웨어를 가리키든 CA는 인증서 보유자의 ID를 설정하고 보증해야 할 책임이 있습니다. 더 이상 유효한 것으로 간주되지 않는 인증서를 취소하고 인증서의 확인자가 해당 유효성을 판단하는 데 사용할 수 있도록 인증서 해지 목록(CRL)을 게시할 수도 있습니다.

본 가이드에서는 Windows Server System Reference Architecture 인증서 서비스가이드에 문서화된 추가 최적의 방법을 사용합니다.

1단계: 평가

평가 단계에서는 네트워크 환경의 현재 상태를 살펴봅니다. 이 평가 단계는 합리화 수준에서 서버 간에 보장된 보안 통신 확인에 대한 요구 사항의 평가 단계와 같습니다. 조직의 컴퓨터, 소프트웨어 및 네트워크 장치의 신뢰성 있는 레코드를 얻고 유지 관리하는 프로세스는 일반적인 IT 과제입니다. 현재 상태를 정의하려면 다음 항목에 대한 정보가 있어야 합니다.

  • 네트워크 검색

  • 네트워크 분할 설명서

  • 네트워크 인프라 장치

  • 현재 네트워크 트래픽 모델 분석

  • Active Directory

  • 호스트 검색

  • 호스트 데이터 요구 사항

이 정보를 수집하는 방법은 IPsec와 그룹 정책을 사용하여 서버 및 도메인 격리 가이드의 3장: IT 인프라의 현재 상태 확인을 참조하십시오. 본 가이드에서는 각 항목에 대한 요구 사항, SMS 2003이나 유사한 제품을 사용하여 자동화된 검색을 통해 정보를 수집하는 방법, 수동 검색 옵션 등을 설명합니다.

2단계: 식별

식별 단계에서는 중앙 집중식 공용 키 구조 설정에 대한 상위 요구 사항을 정의합니다. 조직에서 PKI를 구현하도록 결정하면 설계 단계가 시작되기 전에 비즈니스 문제를 식별해야 합니다. 설계 단계는 작업자, 프로세스 및 기술에 대한 고려 사항을 식별하는 것으로 시작합니다. PKI 서비스 요구 사항을 추진하는 질문에는 다음이 포함됩니다.

작업자 관련 질문:

  • 작업자가 자신의 인증서를 처리하는 방법은?

  • 인증서를 관리할 사람은?

  • PKI가 사용자의 작업 환경에 미치는 영향은?

  • 조직의 규모는?

프로세스 관련 질문:

  • PKI가 조직의 IT 인프라에 속해야 합니까? 아니면 인증서를 외부에서 가져와야 합니까?

  • 인증서가 외부 트랜잭션에도 사용됩니까?

  • 인증서 등록에 적용되는 프로세스는?

  • 조직과 관련 엔터티 간에 트러스트를 설정하고 확인하는 방법은?

  • 트러스트를 확인해야 하는 간격은?

  • 인증서 유효성에 영향을 미치는 제약 조건은?

  • 트러스트 취소 후 연결된 인증서를 해지해야 하는 긴급성의 정도는?

기술 관련 질문:

  • 인증서가 필요한 엔터티의 유형과 용도는?

  • 디렉터리 서비스의 유익한 용도는?

  • 인증서의 일부로 포함해야 하는 정보는?

  • PKI를 지원하는 응용 프로그램은?

  • 공용/개인 키의 복잡도는 얼마나 되고 PKI를 지원하는 응용 프로그램에서 이 복잡도를 지원할 수 있습니까?

조직에 첫 번째 CA 서버를 설치하기 전에 작업자, 프로세스 및 기술을 다루는 전체 PKI 서비스 설계 학습이 존재해야 합니다. 장기적으로 볼 때 서툴게 구현된 PKI를 확장하는 것은 확장 가능한 PKI를 계획하는 데 시간을 미리 들이는 것보다 더욱 어렵고 비용도 더 많이 듭니다. PKI의 상위 요구 사항 식별에 대한 자세한 내용은 기업 인증서 서비스 설계를 위한 WSSRA 상세 계획을 참조하십시오.

3단계: 평가 및 계획

평가 및 계획 단계에서는 PKI를 검토하고 인프라 배포에 필요한 단계를 계획합니다.

PKI란?

보안 네트워크를 구현하는 데 필요한 많은 기술에는 인증된 엔터티와 트러스트된 리소스 간에 디지털 인증서를 교환할 수 있게 해 주는 PKI가 필요합니다. PKI의 인증서는 조직 내부와 외부에서 데이터를 보안하고 리소스의 ID 자격 증명을 관리하는 데 사용됩니다. PKI가 마련되어 있으면 허용된 주체는 CA가 관리하는 인증서 등록 서비스에서 인증서를 요청할 수 있습니다. CA는 요청에 대한 응답으로 인증서 요청자의 유효성을 판단하여 유효한 인증서를 발급합니다. 인증서 보유자는 만료되거나 해지될 때까지 인증서를 사용할 수 있습니다. 인증서의 신뢰성은 인증서 요청자와 발급하는 CA 간에 존재하는 트러스트의 품질에 따라 다릅니다. 두 CA에서 발급된 두 사용자 인증서 서로 간에는 기본적으로 트러스트된 상태가 없습니다. 발급하는 CA 간에 공통된 트러스트가 있어야 인증서를 수동으로 트러스트할 수 있습니다.

PKI를 지원하는 클라이언트는 인증서를 사용하여 주어진 리소스의 트러스트 수준을 판단합니다. 이렇게 하려면 인증서의 유효성을 검사하는 확인 메커니즘이 PKI에 필요합니다. Windows Server 2003 PKI에서는 확인 메커니즘으로 CRL을 제공하며 클라이언트가 기술적으로 많은 프로토콜을 통해 CRL을 검색할 수 있습니다. 클라이언트 기능과 네트워크 인프라에 따라 한 프로토콜을 사용하는 것이 다른 프로토콜을 사용하는 것보다 나을 수 있습니다. 그와 같은 프로토콜의 예에는 다음이 포함됩니다.

  • HTTP 및 HTTPS(Secure HTTP). HTTP와 HTTPS는 CRL이 웹 서버에 게시되어 있을 때 사용됩니다. 이러한 프로토콜은 CRL을 조직 네트워크 외부의 엔터티가 액세스할 수 있도록 만들 때 가장 일반적으로 사용됩니다.

  • LDAP. LDAP가 기본적으로 인증을 요구하기 때문에 디렉터리 서비스에서 LDAP를 통해 CRL에 액세스하려면 HTTP를 통해 같은 CRL을 검색할 경우보다 더 많은 대역폭이 필요합니다. 익명 액세스를 사용하여 CRL을 검색해도 LDAP는 익명 인증 헤더를 보냅니다. 내부와 외부 모두에서 CRL을 사용할 수 있어야 하는 경우에는 LDAP를 통해 모든 클라이언트에 디렉터리 액세스를 제공하는 것이 어려울 수 있습니다.

PKI 아키텍처

PKI 아키텍처에는 인증서 발급, 유효성 검사, 갱신 및 해지가 가능하도록 상호 종속된 다양한 기술과 프로세스를 구현하는 것이 포함됩니다. 이러한 기술에는 다음이 포함됩니다.

  • 인증서 등록, 해지 및 기타 인증서 관리 서비스를 제공하는 인증서 서비스를 실행하는 한 대 이상의 서버

  • Active Directory 디렉터리 서비스나 계정 관리, 정책 배포 및 인증서 게시 서비스를 제공하는 다른 디렉터리 서비스

  • 인증서 요청 시 최종 사용자와 컴퓨터를 인증할 수 있는 도메인 컨트롤러

  • 특정 용도로 인증서를 요청, 수신 및 사용하는 도메인 클라이언트 컴퓨터와 사용자 서비스나 도메인 클라이언트가 아닌 클라이언트가 인증서를 사용할 수도 있지만 대부분의 Windows PKI 환경에서는 도메인 사용자와 컴퓨터가 인증서의 기본 수신자 및 사용자입니다. 어떤 경우 도메인 클라이언트는 자체 인증서 발급 권한을 부여하는 인증서를 요청하고 수신하는 하위 CA가 될 수 있습니다.

다음 그림은 PKI 기술 아키텍처를 보여 줍니다.

그림 11. PKI 기술 아키텍처

그림 11. PKI 기술 아키텍처

이 유형으로 PKI를 구현하면 인증서 서비스를 중앙에서 제어할 수 있습니다.

CA 인프라 및 PKI 구현 계획

CA 인프라 옵션은 조직의 보안 및 인증서 요구 사항, PKI의 용도, 응용 프로그램, 사용자 및 컴퓨터의 요구 사항 등에 따라 다릅니다.

앞서 설명한 대로 인증서 요구 사항은 PKI 설계에 직접적인 영향을 미칩니다. PKI의 논리 설계는 PKI 서비스가 정의된 후에 수행할 수 있습니다. 조직의 공용 키 구조 계획에 대한 자세한 기술 지침은 기업 인증서 서비스 설계를 위한 WSSRA 상세 계획을 참조하십시오.

4단계: 배포

랩 테스트와 파일럿 프로그램으로 공용 키 설계의 유효성을 검사하고 공용 키 설계를 구체화한 후에는 PKI를 실제 업무 환경에 배포할 수 있습니다. 사용 중인 응용 프로그램의 보안을 설정하려면 PKI 배포에 대한 조직적인 접근 방식이 필요합니다. 다음 그림은 상위 CA 인프라 및 PKI 배포 프로세스를 보여 줍니다.

그림 12. 상위 CA 인프라 및 PKI 배포 프로세스

그림 12. 상위 CA 인프라 및 PKI 배포 프로세스

CA 인프라 및 PKI 배포에 대한 자세한 기술 정보는 다음을 참조하십시오.

추가 정보

자세한 내용을 보려면 Microsoft TechNet을 방문하여 "PKI"를 검색하십시오.

Microsoft가 PKI를 배포하는 방법을 보려면 https://www.microsoft.com/technet/itshowcase/content/deppkiin.mspx를 방문하십시오.

체크포인트: 중앙 관리식 인증서 서비스

요구 사항

 

모든 구성 요소의 인벤토리를 조사하기 위한 네트워크 검색을 수행했습니다.

 

인증 기관과 공용 키 구조에 대한 작업자, 프로세스 및 기술 설계 고려 사항을 식별했습니다.

 

PKI를 사용하기 위한 세부 배포 계획을 만들었습니다.

 

PKI 배포 계획을 구현했습니다.

위에서 설명한 단계를 완료했다면 핵심 인프라 최적화 모델에서 중앙 관리식 인증서 서비스 기능에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다. 인증서 서비스에 대한 추가 최적의 방법 리소스 지침을 따르도록 권장합니다.

다음 자체 평가 질문으로 이동하십시오.

요구 사항: 지사 대역폭 예방적 관리

대상

지사 대역폭을 예방적으로 관리하고 있지 않으면 이 절을 읽어야 합니다.

개요

본사와 지사 간에 안전하고 효율적인 보안 통신을 제공해야 할 때 광역 네트워크(WAN)를 통한 제한된 대역폭의 문제에 직면하게 됩니다. 대역폭을 가장 효율적으로 사용하기 위해 수행할 수 있는 작업에는 여러 가지가 있습니다. 물리적 네트워크 인프라의 설계는 지사 및 허브 사이트 인프라에 있는 다른 서비스와 구성 요소에 상당한 영향을 미칩니다. 네트워크 성능과 가용성은 서비스가 WAN을 통한 서비스 액세스에 대한 사용자 요구 사항을 적절히 지원할 수 있는지를 결정합니다.

본 가이드는 BOIS R2(Branch Office Infrastructure Solution for Microsoft Windows Server 2003 Release 2)에 게시된 지침을 기반으로 합니다.

1단계: 평가

다음 절에서는 평가 단계 중에 수행해야 하는 작업을 설명합니다.

네트워크 설계 문서화

조직의 WAN 대역폭을 최적화하는 방법을 판단하는 첫 번째 단계는 조직의 현재 지사 네트워크 설계를 문서화하는 것입니다. 기본 지사 네트워크 설계에는 2가지, 즉 단일 허브와 다중 허브가 있습니다.

단일 허브 네트워크

단일 허브 네트워크에서는 허브 사이트가 여러 원격 사이트에 직접 연결됩니다. 이 구조는 비즈니스 기능이 거의 같으면서 한 국가나 보다 작은 지역의 경계 내에서 운영되는 여러 지사를 둔 조직에 공통된 WAN 구조입니다. 다음 그림은 단일 허브 사이트가 있는 샘플 네트워크 구조를 보여 줍니다.

그림 13. 단일 허브 네트워크

그림 13. 단일 허브 네트워크

다중 허브 네트워크

다중 허브 네트워크는 일반적으로 셋 이상의 네트워크 연결 계층을 제공합니다. 이 구조는 비즈니스 기능이 다양한 많은 지사를 둔 대규모 조직이나 국제 조직에 공통된 구조입니다. 이 WAN 구조에서는 일반적으로 기업 본사에 중앙 허브 사이트가 있고 지역당 하나의 허브 사이트가 있습니다. 다음 그림은 중앙 허브 사이트 1개와 지역 허브 사이트 2개가 있는 샘플 네트워크 구조를 보여 줍니다.

그림 14. 다중 허브 네트워크

그림 14. 다중 허브 네트워크

다중 허브 네트워크는 지사가 다른 지사에 연결되는 경우에 추가로 확장할 수 있습니다. 이 경우 두 번째 계층 사이트에서 사용할 수 있는 서비스를 판단하는 것이 중요합니다. 두 번째 계층 사이트에 대한 옵션에는 다음이 포함됩니다.

  • 첫 번째 계층 지사와 같은 서비스 집합을 로컬로 사용할 수 있도록 합니다.

  • 보다 많은 서비스를 로컬로 사용할 수 있도록 합니다(네트워크 가용성, 용량 또는 성능이 부족하기 때문임).

  • 보다 적은 서비스를 로컬로 사용할 수 있도록 하고 허브 사이트에서 제공하는 서비스에 의존합니다.

평가의 첫 번째 단계는 조직의 지사 및 허브 인프라 네트워크 설계를 문서화하는 것입니다.

WAN 링크 문서화

평가의 다음 단계는 모든 사이트 간의 WAN 링크를 문서화하는 것입니다. 지사를 허브 사이트에 연결하는 네트워크 링크는 WAN의 중요한 구성 요소입니다. WAN 링크는 WAN을 통한 액세스가 필요한 모든 서비스의 가용성에 상당한 영향을 미칠 수 있습니다. 검색 프로세스의 일부로 다음 정보를 판단해야 합니다.

  • 링크 유형. 네트워크 속도, 네트워크 부하 지원 및 네트워크 가용성의 기본 결정 요소입니다. 링크 유형에는 연결이 임대 회선과 같이 지속적인지 전화 접속 및 ISDN과 같이 요구 시 연결되는지 여부뿐 아니라 해당 연결에 사용되는 프로토콜(예: 가상 사설망 또는 VPN, 프레임 릴레이 또는 위성)도 포함됩니다.

  • 링크 대역폭. 이론상의 최대 링크 속도이지만 실제 속도는 네트워크 대기 시간으로 제한됩니다.

  • 링크 대기 시간. 네트워크 패킷이 한 장소에서 다른 장소로 이동하는 데 걸리는 시간으로, 트랜잭션(왕복 이동)에 필요한 최소 시간(지연 시간)을 한정합니다.

  • 링크 용량. 네트워크 링크를 통해 푸시할 수 있는 이론상의 집계 데이터 양입니다. 링크 속도와 밀접한 관련이 있습니다.

  • 링크 활용률. 총 링크 용량의 백분율로 표현됩니다. 활용률에는 네트워크와 서비스 모니터링 및 관리에 필요한 백그라운드 트랜잭션, 네트워크를 사용하는 다른 개별 서비스와 응용 프로그램, 네트워크에 종속된 특정 기능(예: 보안 카메라/시스템 및 VoIP) 등을 비롯한 모든 네트워크 트래픽이 포함됩니다.

지사의 네트워크 세그먼트화

마지막 단계는 지사의 네트워크 세그먼트화와 새 솔루션에서 서비스를 가장 적절히 지원하는 데 필요한 사항을 평가하는 것입니다.

지사의 내부 네트워크에는 일반적으로 플랫 네트워크라고도 하는 단일 세그먼트 네트워크가 있습니다. 이 유형의 네트워크는 단순 IP 계획으로 비용이 많이 들지 않는 단순 인프라를 제공합니다. 조직의 지사에 통합되는 단일 또는 다중 세그먼트 네트워크는 평가의 일부로 문서화해야 합니다.

기타 네트워크 설계 고려 사항

네트워크 링크 외에도 각 지사마다 해당 지사의 모든 사용자와 내부 연결성 요구 사항을 지원하는 네트워크 인프라가 필요합니다. 지사 인프라와 다른 네트워크 구성 요소에 관련된 추가 설계 고려 사항에는 다음이 포함됩니다.

  • 중앙 서비스의 위치

  • 로컬 인터넷 액세스

  • 보안에 미치는 영향

  • 라우팅 제한 사항

  • NAT(Network Address Translation)

평가 요약

이 모든 항목과 첫 번째 단계에서 문서화한 네트워크 설계의 상관 관계를 보여 주는 자세한 스프레드시트 또는 토폴로지 다이어그램이 이 단계의 결과로 생성됩니다. 자세한 내용과 기타 평가 고려 사항은 BOIS R2의 물리적 설계 가이드를 참조하십시오.

2단계: 식별

식별 단계의 목표는 조직 요구에 적합한 성능 수준을 판단하는 것입니다. 대부분의 경우 성능이 높아지면 비용이 증가합니다. 이 단계에서 각 성능 수준의 비용과 이점을 비교 검토하는 것이 중요합니다.

WAN의 다양한 유형과 특성으로 인해 조직에 가장 적합한 WAN 연결에 대한 특정 권장 사항을 제공하는 것이 불가능합니다. 그러나 다양한 그룹에서 수집한 고객 데이터를 기반으로 3가지 네트워크 링크 시나리오, 즉 높은 성능, 보통 성능 및 낮은 성능을 일반화할 수 있습니다. 다음 목록에서는 이러한 성능 시나리오 각각의 특성과 잠재적 응용 프로그램을 설명합니다.

  • 높은 성능. 위성 지사에는 대개 높은 성능의 링크(1.544Mbps 또는 2Mbps 이상, 위치에 따라 다름), 낮은 대기 시간 및 고가용성이 필요합니다. 이들은 대개 북미와 많은 서부 유럽 국가 및 기타 국가의 국경 내에서 발견됩니다. 이 유형의 네트워크 링크를 사용하여 조직에서 다른 시나리오보다 더욱 많은 서비스를 허브 사이트에 중앙 집중화할 수 있는데, 이는 중앙에서 서비스를 이동하여 절감되는 관리 비용이 충분한 가용성을 제공하는 데 드는 비용을 능가할 수 있기 때문입니다. 또한 용량과 대기 시간이 최종 사용자의 생산성을 저하시키지 않을 정도로 충분히 좋을 수 있습니다. 어떤 경우 응용 프로그램 때문에 생산성이 실제로 개선될 수 있습니다. 예를 들어 허브 사이트의 백 엔드 저장소(예: 데이터베이스 또는 메인프레임 컴퓨터)에 액세스하는 응용 프로그램을 중앙 사이트의 응용 프로그램 팜으로 이동하고 터미널 서비스를 통해 해당 응용 프로그램에 액세스하면 유익할 수 있습니다. 그 이유는 가장 사용량이 많은 트랜잭션이 WAN을 통해 발생하지 않아도 되고 용량이 높은 WAN이 사용자의 응용 프로그램 액세스에 필요한 성능 수준을 지원하기 때문입니다.

  • 보통 성능. 가속 지사에서는 대개 보통 성능의 링크(128–512Kbps), 보통 대기 시간 및 만족할 만한 가용성을 사용할 수 있습니다. 이러한 시나리오는 대개 고급 텔레커뮤니케이션 인프라가 없는 지역이나 상당한 지리적 경계가 교차해야 하는 상황에서 발견됩니다. 링크는 구성이나 중앙 집중화를 막는 다른 제한 사항이 없는 경우 낮은 대역폭 요구 사항을 가진 서비스(예: DNS 및 Active Directory)의 중앙 집중화를 지원할 수 있습니다. 그러나 네트워크 링크의 가용성이 부족해서 지사에 남겨진 서비스(예: 파일 및 인쇄 서비스)가 이름 확인, 인증 및 권한 부여를 위해 종속된 중앙 서비스에 액세스하지 못할 수도 있습니다. 또한 터미널 서비스를 사용하여 중앙 응용 프로그램에 액세스할 때 이 링크의 대기 시간이 만족스러운 사용자 환경을 제공하지 않을 수 있습니다.

  • 낮은 성능. 자치 지사는 일반적으로 더욱 낮은 성능의 링크(예: 128Kbps 미만)와 높은 대기 시간으로 작동할 수 있으며 링크 불안정성을 견디는 능력이 더 강합니다. 이 시나리오는 대개 텔레커뮤니케이션 산업이 상당히 낙후된 지역이나 더욱 높은 성능과 가용성을 갖춘 네트워크 링크를 실제로 얻는 데 드는 비용이 엄청나게 비싼 지역(예: 매우 멀리 떨어진 위치에서 단일 지사를 연결할 때)에서 발견됩니다. 이 유형의 링크를 사용해도 서비스 중앙 집중화에 도움이 되지는 않습니다. 그러나 업무상 중요한 지사 기능과 해당 기능이 종속된 서비스를 지원하는 서비스가 모두 지사에 로컬로 위치해야 하기 때문에 지사 설계가 단순화됩니다.

식별 단계의 결과는 각 연결의 원하는 성능 결과에 대한 자세한 분석과 권장 사항이며 이를 통해 각 지사의 분류 방법, 즉 위성 지사인지 가속 지사인지 자치 지사인지를 판단할 수 있습니다.

3단계: 평가 및 계획

지금까지 네트워크 토폴로지와 지사 인프라에 대해 원하는 성능 요구를 문서화해오고 있습니다. 평가 및 계획 단계에서는 서비스 중앙 집중화와 지역화의 영향을 비교해서 평가하고 성능 요구 사항을 충족하기 위한 WAN 링크 관리 계획을 만듭니다.

물리적 서버 설계 평가

지사 인프라 설계에서는 일반적으로 최대한 많은 서비스를 중앙 집중화하는 데 중점을 둡니다. 모든 서비스를 중앙 집중화하는 것을 장기 목표로 삼을 수 있지만 단기 솔루션의 경우에는 이러한 목표를 거의 실행할 수 없습니다. 그 이유는 지사의 클라이언트 컴퓨터와 허브 사이트의 서비스 간에 적합한 가용성, 용량 및 대기 시간을 갖춘 연결을 제공하는 비용이 엄청나게 비쌀 수 있기 때문입니다. 현재 기술 상태가 특정 서비스의 중앙 집중화를 지원하지 않는 경우 지사 능률화는 일반적으로 지사에 남아 있는 서비스를 모두 단일 서버에 통합하기 위한 것입니다. 이것은 까다로울 수도 있지만 특정 상황에서 달성이 가능합니다.

단일 서비스에 특정하지 않고 모든 서비스에 적용해야 하는 설계 고려 사항의 유형에는 다음이 포함됩니다.

  • 지사 인프라 능률화에 사용할 수 있는 설계 옵션

  • 지사 서비스 배치 고려 사항(작업자, 프로세스 및 비즈니스 자체의 서비스 배치에 대한 일반 암시 사항 포함)

  • 서비스 배치에 특정하지 않은 기타 설계 고려 사항(특히, 사용자와 비즈니스 기능에 관련된 고려 사항)

지사 인프라 설계 옵션

지사 인프라를 정의하려면 중앙에서 그리고 로컬로 서비스를 배포하기 위한 옵션과 해당 암시 사항을 분석해야 합니다. 각 지사마다 내려야 하는 2가지 기본 결정 사항에는 많은 설계 옵션의 평가가 필요합니다.

서비스 중앙 집중화 옵션

서비스 중앙 집중화에 사용할 수 있는 기본 옵션에는 다음과 같은 서비스 실행이 포함됩니다.

  • 지사에서만 실행(장애 조치 없음)

  • 지사에서 실행(복제 기능이 있는 허브 사이트로의 장애 조치 포함)

  • 허브 사이트에서만 실행

지사 서버 설계 옵션

하나 이상의 지사 서버에서 서비스 통합으로 중앙 집중화할 수 없는 서비스를 여전히 능률화할 수 있습니다. 지사 서버 설계에서는 각 지사의 하드웨어, 소프트웨어 및 지원 사용(개인 리소스의 사용 포함)을 최적화하는 방법에 중점을 두어야 합니다.

Solution Accelerator for Consolidating and Migrating LOB Applications 및 혼합 작업 통합 가이드에서는 통합할 수 있는 응용 프로그램의 자세한 판단 지침을 제공합니다. Solution Accelerator for Consolidating and Migrating LOB Applications에서는 통합의 좋은 후보가 아닌 응용 프로그램에 적합한 솔루션을 식별하기 위한 지침도 제공합니다.

다음 목록에서는 지사 사이트의 응용 프로그램을 실행하기 위한 기본 옵션을 요약합니다.

  • 단일 서버 통합

  • 서비스 통합

  • 가상화된 통합

  • 전용 서버

각 서버용으로 선택한 옵션에 따라 필요한 지사 서버 수가 결정됩니다.

지사 서비스 배치 고려 사항

각 조직마다 가장 중요한 요구 사항과 지사 인프라 솔루션 설계에 가장 큰 영향을 미치는 요구 사항을 정하는 우선 순위가 있습니다. 프로젝트 구상 단계 중에 수행된 조기 분석 작업의 일환으로 서비스 배치에 영향을 미치는 기술, 비즈니스 및 기타 요구 사항과 제한 사항을 식별했을 것입니다.

이 정보가 있어야 각 지사 서비스에 대한 옵션과 해당 장단점을 효과적으로 평가할 수 있으며 여기에는 다음 목록에서 개략적으로 설명하는 일반 설계 고려 사항과 서비스별 설계 고려 사항이 모두 포함됩니다.

  • IT 조직

  • 정치적 고려 사항

  • 법적 및 규정 고려 사항

  • 보안

  • 다음을 포함한 가용성 및 안정성

    • 서비스의 중앙 집중화

    • 지사 서버에서의 통합 및 공동 호스팅 서비스

    • 지사에서 중복되지 않는 서버

    • 지사 서비스 중복

    • 로컬 서비스용 단일 서버(로컬 중복 및 서비스용 Windows 클러스터링 포함)  

  • 백업 및 복구

  • 성능 및 용량

  • 확장성

  • 비용

지사 서비스 계획

BOIS R2에서는 지사용이든 다른 IT 서비스용이든 조직의 인프라 서비스 설계에 대해 반복 가능한 공통 접근 방식을 제공하는 데 사용할 수 있는 새로운 설계 기법을 도입했습니다. 이 기법에서는 서비스 설계 참조(SDR) 다이어그램과 3가지 기본 설계 요소를 사용하여 각 서비스의 설계 프로세스를 설명합니다. 이러한 요소는 다음과 같습니다.

  • 설계 단계

  • 설계 고려 사항

  • 설계 옵션

다음 그림은 이 설계 접근 방식의 요소를 설명하는 데 사용되는 서비스 설계 참조의 일반 버전을 보여 줍니다.

그림 15. 서비스 설계 참조의 일반 버전

그림 15. 서비스 설계 참조의 일반 버전

각 설계 단계마다 고려 사항과 옵션을 사용하여 입력된 설계가 새로운 설계의 요구 사항을 충족할지와 필요에 따라 새로운 요구 사항과 일치하도록 모델을 수정할 수 있는지를 판단해야 합니다.

자세한 핵심 지사 서비스 계획이 있어야 WAN 대역폭 사용이 최적화됩니다. 이러한 서비스는 지사 환경에 기본 인프라를 제공하기 때문에 핵심 서비스라고 하며 이 경우 기본 인프라는 나중에 솔루션의 기능을 높이도록 향상하거나 확장할 수 있습니다. 이러한 핵심 서비스는 다음과 같습니다.

  • 디렉터리 서비스

  • 네트워크 주소 지정 및 이름 확인 서비스

  • 파일 서비스

  • 인쇄 서비스

  • 핵심 클라이언트 서비스

  • 핵심 관리 서비스

지사 핵심 서비스 설계에 대한 자세한 내용은 BOIS R2의 핵심 지사 서비스 설계를 참조하십시오.

분산 파일 시스템

Windows Server 2003 R2의 분산 파일 시스템(DFS) 기술은 WAN 방식 복제와 지리적으로 떨어져 있는 파일에 대한 단순화된 결함 허용 액세스를 제공합니다. DFS의 2가지 기술은 다음과 같습니다.

  • DFS 복제. WAN 환경용으로 최적화된 새로운 상태 기반 멀티마스터 복제 엔진입니다. DFS 복제는 복제 예약, 대역폭 제한, 원격 차등 압축(RDC)으로 알려진 새로운 바이트 수준 압축 알고리즘 등을 지원합니다.

  • DFS 네임스페이스. 관리자가 여러 서버에 있는 공유 폴더를 그룹화하여 사용자에게 네임스페이스로 알려진 가상 폴더 트리로 제공하는 데 도움이 되는 기술입니다. 이전에 Windows 2000 Server와 Windows Server 2003에서는 DFS 네임스페이스를 분산 파일 시스템이라고 했습니다.

평가 및 계획 요약

모든 조직의 WAN 대역폭을 최적화하기 위한 단일 단계나 권장 사항은 없습니다. 각 조직마다 WAN 관리 시 고려해야 할 사항이 고유합니다. 평가 및 계획 단계의 목표는 서비스를 통합할 기회가 있는 곳을 식별하고 WAN 대역폭을 예방적으로 관리할 수 있도록 현재 네트워크 토폴로지를 보다 잘 이해하는 것입니다.

4단계: 배포

적합한 아키텍처를 식별하고 지사에서 WAN 링크 제약 조건을 최적화하기 위해 중앙 집중화된 서비스와 지역화된 서비스를 비교 검토했으면 배포 단계에서 지사 계획 및 아키텍처의 결과로 얻은 권장 사항을 구현하게 됩니다. 권장 사항에 따라 배포 단계가 서비스의 추가 중앙 집중화 등으로 이어질 수 있으며 WAN 링크는 해당 변경 사항으로 적절히 조정됩니다. 배포 프로세스의 일환으로 이를 표준 정책으로 기록하여 WAN 링크 요구 사항과 지사 인프라를 적합한 간격으로 다시 검토할 수도 있고 미리 설정한 데이터, 성능 또는 담당자 임계값을 준용할 수도 있습니다.   

추가 정보

자세한 내용을 보려면 Microsoft TechNet을 방문하여 "bandwidth management"를 검색하십시오.

Microsoft가 WAN 대역폭을 관리하는 방법을 보려면 https://www.microsoft.com/technet/itshowcase/content/optbwcs.mspx를 방문하십시오.

체크포인트: 지사 대역폭 예방적 관리

요구 사항

 

지사 토폴로지를 확인하여 문서화했습니다.

 

모든 지사 유형의 요구를 기반으로 요구 사항 명세를 만들었습니다.

 

지사 서비스 통합을 위한 계획과 아키텍처를 만들었으며 지사 WAN 요구 사항을 다시 평가하기 위한 성능 임계값을 확인했습니다.

 

WAN의 연결 한계를 극복하고 지사 서비스를 최적화하기 위한 계획을 구현했습니다.

위에서 설명한 단계를 완료했다면 인프라 최적화 모델에서 지사 대역폭 예방적 관리 기능에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다. 대역폭 관리에 대한 추가 최적의 방법 리소스 지침을 따르도록 권장합니다.

다음 자체 평가 질문으로 이동하십시오.