|
|
cygni 2008/12/01 09:00
IE8 Beta2가 나오고 바로 다운로드 해서 사용을 해보았는데요. ^^ 테스트 목적으로 사용해보는 것은 좋지만, 호환성 문제로 인터넷 뱅킹 등에 사용하기에는 문제가 많이 있었습니다. ㅠㅠ
아마도 저와 비슷한 이유로 IE7로 다운그레이드를 하려고 시도하시는 경우가 많은 것 같아서, 간단하게 IE8 Beta2를 제거하는 방법에 대해서 정리해보았습니다.
아주 간단한 팁이지만, Windows VISTA 사용 시 IE8 Beta2를 제거 하는 방법을 알려드립니다.
more.. IE8 Beta2를 제거 하기 위해서 Windows Update를 이용합니다.
Windows Update에서 업데이트 기록 보기를 선택하신 후
설치된 업데이트로 이동 해줍니다.
제거하고자 하는 IE8 Beta2를 선택 합니다.
해당 업데이트를 제거 하면, 간단하게 IE8 Beta2를 제거 하실 수 있습니다.
제거 후에 컴퓨터를 재시작 해주시면 이전의 IE7 버전으로 돌아 갑니다.
간단한 팁이지만, 전 IE8 Beta2 제거에 꽤 애를 먹어서.. ㅠ.ㅠ 정리해보았습니다.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/144
cygni 2008/11/24 09:00
Windows Server 2008과 Forefront Client Security를 결합한 호스팅 상품을 준비하면서, 예전에 ForeFront Client Security 제품에 대해 포스팅 했던 것이 생각이나 다시 한 번 간단하게 정리를 해 보았습니다. 아직까지는 국내에서 많이 사용되고 있지는 않은 것 같지만, 아래의 내용을 살펴 보시면,
보안 인프라 구축에 많은 도움이 되실 수 있을 것 같습니다. 그리고, 출시 예정인 ForeFront 차기 버전에 대한 포스팅도 준비 할 수 있도록 하겠습니다.
펼쳐보기... ☜ 클릭
우선 Forefront Client Security 라고 하면,
아~ 클라이언트에 설치되는 클라이언트 PC용 바이러스 엔진인가보다 라고
간단하게 생각하기가 쉬운 것 같습니다.. ^^
저 역시도 처음 Forefront 제품이 출시가 된다고 했을 때,
그렇게 착각을 했었던 적이 있었고요.. ^^
Forefront Client Security 제품 줄여서 FCS는
기존에 우리가 잘 알고 있는 방식으로
클라이언트에 설치가 되는 바이러스 엔진의 형태는 아닙니다.
Forefront Client Security의 동작 원리
FCS 제품에 대한 이해를 돕기 위해서 그림 한 장을 추가 하였는데요.
이 그림을 통해서 FCS의 동작 원리를 간략하게 설명을 드리면,
FCS가 기존의 클라이언트용 바이러스 엔진 제품과
어떤 차별성이 있는지를 아실 수 있을 듯하네요.. ^^
FCS의 구동 방식을 간략하게 말씀을 드리면,
FCS를 Management 하는 서버에서 Anti Malware, Anti Virus에 대한
검사 정책을 적용 받도록 Active Directory의 그룹정책을 이용하여
AD에 조인이 되어 있는 클라이언트들에게 정책을 배포 할 수가 있습니다.
물론 AD를 사용하지 않는 경우의 시나리오도 있으나, AD 환경을 기준으로하여...
(그림 중 Setting이라고 되어 있는 파란색 화살표)
그렇게, 배포된 그룹 정책을 따라서 클라이언트들은
Windows Update Site 또는, WSUS를 통해서 보안위협 요소에 대한
Forefront Client Security에 대한 서명을 업데이트를 받고,
그룹정책을 통해 설정 된 FCS 정책에 따라 바이러스 검사를 수행하게 됩니다.
(그림 중 Definitions라고 되어 있는 녹색 화살표)
클라이언트들은 FCS 서명 업데이트 내용 및 보안 위협 요소들에 대한 감시 결과
그리고, 자신의 보안 상태에 대한 보고를 Microsoft Operation Management 서버인
MOM 서버에 전달을 하게 됩니다.
(그림 중 Event라고 되어 있는 보라색 화살표)
클라이어트로 부터 보고된 각종 상태 데이타들은 MOM 서버에서 사용하는
SQL 서버 DB에 저장이 됩니다.
SQL 서버에 저장된 클라이언트의 상태 데이타들은 다시 FCS를 Management하는
서버의 FCS Managemet Console을 통해서, 클라이언트에 대한 정책 적용 결과, 보안 위협 요소, 서명 업데이트 내역 등의 데이타들을 리포트 형식으로 볼 수 있으며,
즉시 위협 요소에 대한 보안 설정 등의 작업 역시도 중앙의 FCS Management Console에서 가능 합니다. .
(그림 중 Report라고 되어 있는 보라색 화살표)
즉, Anti Malware, Anti Virus에 대비한 보안 인프라가 구축이 된다고 할 수 있습니다.
'전산 인프라가 구축이 되었다.'라고 하는 것이,
그저 서버나 클라이언트가 물리적으로만 존재하고 있는 상황을
전산 인프라가 구축이 되었다고 말하기는 조금 힘들 것 같다는 생각이 듭니다.
물리적인 요소들인 서버나 클라이언트들이 배포되어 있는 형태에서,
서버와 클라이언트들을 위한 운영 계획을 수립하고,
그에 따른 정책을 입안하고, 배포하고, 구성하고, 모니티링 하여 결과를 분석하고,
다시 계획하는 일련의 연속성 있는 운영이 지속될 수 있는 구조를
정확하게 인프라가 구축이 되었다고 볼 수 있지 않을까? 라는 생각을 하며,
그러한 관점에서 본다고 하면, Forefront Client Security 제품은
Anti Malware와 Anti Virus를 위한 각각의 롤을 가진 서버들의 역할을 통해서
Anti Malware와 Anti Virus에 대한 계획, 정책, 배포, 구성, 모니터링, 결과 분석 등의
일련의 연속성을 가진 보안 운영의 틀을 만들어 주는,
보안 인프라를 구성하고 있다고 말씀을 드릴 수 있을 것 같습니다.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/140
cygni 2008/11/17 09:00
서버를 관리하고 운영하는 관리자의 입장에서 사내의 서버를 언제 어디서든 연결 할 수 있다는 것은, 운영을 좀 더 편리하게 해주고, 관리와 운영에 효율성을 증대해주는 일임에도 불구하고, 보안상의 취약점으로 인해 외부에서의 연결을 자제해오거나, 아니며 보안 위협을 무시한체 외부에서의 연결을 허용하고 있는 것이 전산 시스템을 운영하고 있는 많은 기업들이 안고 있는 문제인 것 같습니다.
아래의 글은 John Morello라는 Microsoft의 어디서나 액세스 할 수 있는 기술을 담당하고 있는 수석 컨설턴트가 쓴 칼럼으로 Microsoft의 터미널 서비스와 NAP 기술을 이용하여 어디서나 안전하고 편리하게 액세스 할 수 있는 방법에 대한 글 입니다. 상세하고 읽기 쉽게 기술이 되어 있네요.. ^^ 가볍게 한 번 읽어 보시고, 편리하고 효율적인 전산 운영에 도움이 될 수 있었으면 좋겠습니다.
계속 보기... ☜ 클릭
네트워크에 연결된 모바일 사용자의 증가는 오늘날 기술 분야에 있어서 확실히 나타나는 추세 중 하나입니다. 대부분의 기업에는 원거리 지사 근무 또는 재택 근무를 하거나 고객 방문을 위한 출장이 잦은 직원이 있습니다. 생산성을 높이려면 이러한 사용자가 위치에 관계없이 응용 프로그램과 데이터에 쉽게 액세스할 수 있도록 해야 합니다.
그러나 최근까지도 원격으로 안전하게 액세스하려면 클라이언트 소프트웨어를 설치하고 복잡한 명령을 입력해야 하며 연결 시간도 많이 걸리는 경우가 많았습니다.
지난 몇 년 사이에 원격 액세스를 보다 간단하고 이용하기 쉬운 기술로 만들기 위한 다양한 방식이 등장했습니다. 예를 들어 Outlook® Web Access(OWA)는 사용자가 복잡한 계층 3 VPN(가상 사설망) 없이도 단일 브라우저를 통해 전자 메일, 일정 및 연락처에 간단하게 액세스할 수 있도록 합니다. OWA와 같은 기술은 "어디서든 액세스 가능한" 솔루션에 있어 중요한 부분을 차지하지만 대부분의 조직에서는 이러한 통합 브라우저 환경을 허용하지 않는 핵심 응용 프로그램을 많이 사용하고 있습니다. 이러한 경우 터미널 서비스와 같은 솔루션이 사용자가 어디서든 응용 프로그램에 액세스할 수 있는 효과적인 방법이 될 수 있습니다.
Microsoft는 Windows Server® 2008에서 터미널 서비스의 기본 기능 집합을 크게 개선했습니다. 그 결과 이제 터미널 서비스에는 완벽한 창, RemoteApp라는 응용 프로그램별 게시 기능, EasyPrint의 범용 인쇄 드라이버 기능, TS Web Access라는 브라우저 기반 포털 등이 추가되었습니다. 또한 Windows Server 2008에는 어디서든 액세스 가능한 솔루션의 핵심이 되는 TS 게이트웨이 구성 요소도 포함되었습니다. 이 구성 요소는 RDP(원격 데스크톱 프로토콜)에 대해 SSL 캡슐화를 제공하여 방화벽과 NAT(Network Address Translation) 장치를 쉽고 안전하게 통과할 수 있도록 합니다. TS 게이트웨이 기능은 NAP(네트워크 액세스 보호)라는 Windows Server 2008의 새로운 기술과 통합되어 끝점 클라이언트 상태 검사 기능도 제공합니다. 조직에서 이 모든 구성 요소를 결합하면 어디서든 쉽고 안전하게 응용 프로그램과 데이터에 액세스할 수 있는 솔루션을 구축할 수 있습니다.
이 칼럼에서는 터미널 서비스 구성 요소의 관리에 대한 자세한 내용보다는 어디서든 액세스 가능한 솔루션의 네트워크 및 보안 설계 측면에 중점을 두고, Windows Server 2008에 포함된 기술을 기반으로 이러한 솔루션을 작성하는 방법과 최상의 방법을 설명합니다.
계층 3 가상 사설망의 문제점
새 기술에 대해 생각해 볼 때는 현재 사용 중인 방식과 비교하여 어떤 이점이 있는지를 파악하여 새 모델의 가치를 정확히 평가하는 것이 중요합니다. 기존 계층 3 VPN에는 일반적으로 보안과 사용의 용이성과 관련하여 해결해야 할 두 가지 중대한 문제가 있습니다.
최신 계층 3 기반 VPN에서 보안이 문제가 된다는 사실이 다소 의아하게 들릴 수 있습니다. VPN의 궁극적인 목적이 바로 인터넷을 통해 안전한 터널을 제공하는 것이니까요. 이를 이해하기 위해 일반적으로 VPN 위협 요소가 될 수 있는 사항을 종합적으로 살펴보겠습니다. 그렇다고 VPN을 통해 전달하는 데이터가 가로채기나 변조의 위험에 노출된다는 의미는 아닙니다. 대부분의 최신 계층 3 VPN은 뛰어난 데이터 스트림 암호화 기능을 제공합니다. 그보다는 조직 네트워크에 "모든 포트, 모든 프로토콜"을 통해 액세스할 수 있는 모든 권한이 부여된 원격 컴퓨터로 인해 발생하는 위협을 생각해 볼 수 있습니다. 문제는 계층 3 VPN에서 암호화되어 네트워크를 통해 전달되는 데이터 스트림이 아니라 이러한 터널을 통한 원격 클라이언트 연결에 있습니다. 이러한 연결은 내부 네트워크의 위험성을 높입니다. Slammer나 Blaster와 같은 맬웨어로 피해를 입은 대부분의 조직이 내부 네트워크의 컴퓨터나 방화벽을 통과한 해커에 의해 손상을 입은 것이 아니었다는 점을 기억해 보십시오. 그보다는 오히려 감염된 컴퓨터에서 VPN을 통해 네트워크에 연결하는 원격 사용자를 통해 이러한 피해가 발생한 것입니다. 이러한 VPN에서 완전히 라우팅된 계층 3 기반 연결을 만들면 원격 컴퓨터가 데이터센터에 설치된 컴퓨터와 마찬가지로 내부 리소스에 대한 액세스 권한을 가지게 됩니다. 이러한 액세스 권한은 좋은 의도로 사용될 수도 있지만 악용될 소지도 있습니다.
게다가 계층 3 VPN을 위해서는 조직의 IT 부서에서 관리하지 않는 컴퓨터에 소프트웨어를 설치하고 구성해야 하므로 운영 비용이 높아질 수 있습니다. 예를 들어 사용자의 가정용 컴퓨터에 VPN 클라이언트를 설치하려면 사용자 지정 설치 패키지를 만들고, 사용자가 따라야 하는 자세한 설치 지침을 작성하고, 사용자의 컴퓨터에 설치된 응용 프로그램과의 충돌 문제를 해결해야 합니다. 뿐만 아니라, 새로운 버전의 클라이언트를 배포해야 하거나 새 VPN 끝점을 추가하는 경우와 같이 구성 데이터가 변경되는 경우 막대한 관리 비용이 소요될 수 있습니다. 사용자의 입장에서는 이 VPN을 통한 작업이 직관적이지 않게 느껴지는 경우가 많습니다. 계층 3 연결밖에 제공되지 않으므로 사용자의 업무용 응용 프로그램과 데이터를 쉽게 액세스하여 확인할 수 없습니다.
터미널 서비스를 통한 문제 해결
터미널 서비스와 계층 7 또는 응용 프로그램 계층 VPN이라는 다른 기술에서는 사용자가 액세스할 수 있는 리소스 및 프로토콜에 대한 효과적인 제어 기술을 제공하고 최종 사용자 환경을 이전보다 간단하고 직관적으로 만들어 이 두 가지 문제를 해결합니다.
보안의 관점에서 보면 계층 3 VPN 방식과 터미널 서비스 및 TS 게이트웨이를 사용하는 다른 방식 사이의 가장 중요한 기능 차이점은 내부 네트워크에 대한 연결이 완전히 개방된 파이프라인이 아니라는 점입니다. 특히 계층 3 방식에서는 내부 네트워크에 대한 모든 라우팅 기능을 가진 가상 인터페이스를 로컬 컴퓨터에 만드는 반면, TS 게이트웨이 방식에서는 RDP 기반 패킷만 내부 네트워크에 전달되도록 허용합니다. 따라서 전반적인 공격 노출 영역이 크게 줄고 RDP 내에서 보다 세부적으로 제어할 수 있습니다. 예를 들어 RDP는 드라이브 리디렉션에 대한 기본 지원을 제공하지만 조직에서 TS 게이트웨이를 NAP와 통합하여 원격 컴퓨터가 최신 바이러스 백신 소프트웨어가 설치되어 있음을 증명하는 경우에만 이 기능을 허용하도록 구성할 수 있습니다.
최종 사용자의 관점에서 계층 3 VPN과 터미널 서비스 기반 방식 간의 가장 명백한 차이는 설치가 훨씬 간단하다는 점(설치가 전혀 필요하지 않은 경우도 많음)과 응용 프로그램 및 데이터에 훨씬 쉽고 직관적으로 액세스할 수 있다는 점입니다. 원격 데스크톱 연결 클라이언트가 Windows에서 기본 제공되고 Windows® Update와 같은 일반 서비스 기술을 통해 최신으로 유지되므로 대개 별도로 설치할 클라이언트 소프트웨어가 없습니다. 또한 TS 웹 액세스를 활용함으로써 사용자가 단일 URL에서 모든 응용 프로그램과 데이터를 찾을 수 있습니다. 응용 프로그램을 간단히 클릭하면 TS 게이트웨이에서 인터넷을 통한 연결을 안전하게 터널링하여 해당 응용 프로그램이 사용자의 데스크톱에 완벽하게 전달됩니다. 다시 말해 복사하여 붙여넣기 기능이 지원되고 작업 표시줄에 최소화되는 등 응용 프로그램이 로컬로 설치된 것처럼 보이고 동작합니다. 터미널 서버 기반의 원격 액세스 방식은 응용 프로그램과 데이터를 검색하기 용이하게 하고 설치가 즉각적으로 이루어지게 함으로써 성공적으로 사용자 만족도를 높이고 지원 비용을 절감해 줍니다.
네트워크 아키텍처 선택
인터넷을 통해 TS 게이트웨이 서버를 사용할 수 있도록 하는 데에는 두 가지 기본 네트워크 설계 방식을 이용할 수 있습니다. 첫째는 TS 게이트웨이를 경계 네트워크의 계층 3/4 방화벽 사이에 배치하는 방식이고, 둘째는 TS 게이트웨이를 내부 네트워크에 배치하고 Microsoft® ISA Server, Microsoft Intelligent Application Gateway, 기타 다양한 타사 솔루션과 같은 응용 프로그램 계층 방화벽을 경계 네트워크에 배치하여 인바운드 HTTPS 프레임을 검사하는 방식입니다. 여기서는 이러한 인바운드 세션이 분석된 후에만 패킷이 내부 TS 게이트웨이 서버로 전달됩니다.
조직에 기본 상태 기반 패킷 검사만 실행하는 계층 3/4 방화벽밖에 없으면 그림 1과 같이 TS 게이트웨이 장치를 경계 네트워크에 직접 배치할 수 있습니다. 이 설계에서는 인터넷 쪽 방화벽이 인터넷을 통해 HTTPS 트래픽만 전달되도록 TS 게이트웨이에 대한 연결을 제한합니다. 그러나 방화벽은 응용 프로그램 계층에서는 이 트래픽에 대한 검사를 수행하지 않고 TS 게이트웨이로 전달하기만 합니다. 그러면 TS 게이트웨이 서버가 HTTPS 패킷에서 RDP 프레임을 추출하여 해당 백 엔드 서버로 전달합니다. 이러한 백 엔드 서버는 대체로 TS 게이트웨이에서 전달된 RDP 프레임이 해당 내부 서버에 전달되도록 허용하는 다른 방화벽에 의해 경계 네트워크와 분리됩니다.
그림 1 계층 3/4 방화벽을 사용하는 경우 경계 네트워크에 배치된 TS 게이트웨이 (더 크게 보려면 이미지를 클릭하십시오.)
이러한 시나리오는 완벽하게 지원되고 많은 조직에서 유용할 수도 있지만 두 가지 중대한 단점이 있습니다. 첫째, TS 게이트웨이가 인터넷에서 직접 트래픽을 수신하기 때문에 외부의 악의적인 공격자에게 더 많이 노출되는 위험이 있습니다. 이러한 악의적인 공격자는 SSL 세션을 통해 게이트웨이에 대한 공격을 시도할 수 있을 뿐만 아니라 프런트 엔드 방화벽이 헤더만 검사하고 페이로드는 검사하지 않기 때문에 이러한 세션이 게이트웨이까지 도달할 수 있습니다. 그렇다고 TS 게이트웨이가 취약한 구성 요소라는 뜻은 아닙니다. 사실 TS 게이트웨이는 다른 Windows Server 2008 제품과 마찬가지로 엄격한 보안 설계와 테스트를 거쳤습니다. 그러나 이 시나리오에서만큼은 인터넷에서 직접 수신된 필터링되지 않은 트래픽을 처리할 수도 있기 때문에 위험 수준이 상대적으로 높습니다. 두 번째 중대한 단점은 게이트웨이와 백 엔드 방화벽 간에 허용되어야 하는 트래픽의 양이 증가한다는 점입니다. 사용자를 인증하기 위해 TS 게이트웨이는 Active Directory®와 통신해야 합니다. 이러한 통신을 가능하게 하려면 백 엔드 방화벽에서 HTTPS보다 훨씬 광범위한 포트와 프로토콜에 대해 예외를 적용해야 합니다. 이렇게 허용되는 통신이 증가함에 따라 또 다시 설계적인 측면에서의 상대적 위험 수준이 높아지게 됩니다.
TS 게이트웨이를 인터넷에 노출하기 위해서는 인바운드 HTTPS 세션이 게이트웨이에 도달하기 전에 응용 프로그램 계층(계층 7) 방화벽을 사용하여 처리하는 방식이 더 효과적입니다(그림 2 참조). 이 설계에서도 기존 계층 3/4 방화벽이 경계 네트워크를 구성할 수 있습니다. 그러나 TS 게이트웨이 대신 계층 7 방화벽이 경계에 배치됩니다. 트래픽이 외부와 접한 방화벽에 도달하면 방화벽에서 HTTPS 프레임을 제외한 모든 데이터를 필터링하여 계층 7 방화벽에 HTTPS 프레임만 전달합니다. 이때 계층 7 방화벽은 SSL 세션을 종료하고, 스트림에서 암호화되지 않은 콘텐츠를 검사하고, 악의적인 트래픽을 차단한 다음 백 엔드 방화벽을 통해 RDP 프레임을 TS 게이트웨이로 전송합니다. 원하는 경우 계층 7 방화벽에서 프레임을 TS 게이트웨이로 보내기 전에 다시 암호화할 수도 있습니다. 이 방식은 조직의 전용 네트워크에는 그다지 필요하지 않지만 호스팅되는 데이터 센터나 공유 네트워크에는 매우 유용할 수 있습니다.
그림 2 TS 게이트웨이 장치와 응용 프로그램 계층 방화벽 사용 (더 크게 보려면 이미지를 클릭하십시오.)
이 설계를 통해 이전 솔루션의 단점을 모두 해결할 수 있습니다. TS 게이트웨이 서버가 계층 7 방화벽에서 검사된 트래픽만 수신하므로 인터넷을 통한 공격이 차단되지 않을 위험성이 낮아집니다. 계층 7 방화벽이 이러한 공격을 필터링하고 검사를 통과한 정상 트래픽만 게이트웨이로 보내기 때문입니다.
이 솔루션의 다른 주요 장점으로, 내부 네트워크에 따라 게이트웨이가 배치된다는 점을 들 수 있습니다. 인터넷에서 수신되는 트래픽이 게이트웨이에 도달하기 전에 계층 7 방화벽에서 검사되므로 게이트웨이를 내부 네트워크에 배치하여 사용자 세션의 인증과 RDP 호스트를 위해 도메인 컨트롤러에 직접 액세스하도록 할 수 있습니다. 게다가 백 엔드 방화벽에 훨씬 엄격한 정책을 적용할 수도 있습니다. RDP 및 디렉터리 인증 트래픽을 모두 허용하는 대신 계층 7 방화벽에서 전달된 RDP 세션만 TS 게이트웨이에 도달하도록 허용해야 합니다. 계층 7 방화벽을 기반으로 TS 게이트웨이 배포를 진행하면 기존 경계 네트워크를 다시 설계하지 않고도 관리가 용이하고 보다 안전한 솔루션을 제공할 수 있습니다.
NAP 통합
뛰어난 경계 설계가 어디서든 액세스 가능한 솔루션의 핵심 요소이기는 하지만 규정을 준수하고 끝점 장치의 보안을 유지하는 것도 중요합니다. RDP는 RDP 세션 및 프린터와 같은 다양한 유형의 장치 리디렉션을 허용하는 기능이 풍부한 프로토콜이므로 솔루션에 연결하는 클라이언트가 조직의 보안 정책을 따르도록 하는 것이 중요합니다. 예를 들어 앞서 살펴본 것과 같은 최상의 방법에 따른 안전한 네트워크 토폴로지를 사용하더라도 안전하지 않은 컴퓨터에서 터미널 서버에 연결하는 최종 사용자가 기밀 데이터를 잃거나 악의적인 파일을 터미널 서버로 가져올 수 있습니다. 사용자가 계층 3 VPN을 통해 연결하는 경우보다는 연결할 수 있는 경우와 피해를 입을 수 있는 가능성이 매우 적지만 데이터 손실의 위험성을 관리하고 IT 정책을 준수하도록 하는 것은 여전히 중요합니다.
NAP(네트워크 액세스 보호)는 네트워크에 연결할 수 있는 사용자뿐만 아니라 이러한 사용자가 연결에 사용할 수 있는 시스템의 종류까지 제어할 수 있는 Windows Server 2008의 새로운 기술입니다. 예를 들어 NAP를 사용하면 방화벽을 실행 중이고 최신 바이러스 백신 소프트웨어가 설치된 컴퓨터만 네트워크에 연결하도록 제한할 수 있습니다. 또한 NAP는 조직의 내부 네트워크는 물론, 계층 3 VPN을 통해 연결하는 사용자와 TS 게이트웨이를 통해 연결하는 사용자를 비롯한 원격 사용자까지 제어하도록 확장할 수 있는 솔루션입니다. NAP를 TS 게이트웨이 설계에 통합하면 보안 정책에 부합하는 시스템만 연결하도록 할 수 있습니다. NAP에 대한 자세한 내용은 2007년 5월호 TechNet Magazine에서 필자의 Security Watch 칼럼(technetmagazine.com/issues/2007/05/SecurityWatch)을 참조하십시오.
NAP는 설계에 서비스 하나만 추가하는 간단한 방식으로 TS 게이트웨이 배포에 통합할 수 있습니다. 이 서비스는 NPS(네트워크 정책 서버)로 TS 게이트웨이 서버 자체에 설치하거나 별도의 운영 체제 인스턴스에 설치할 수 있습니다. 그런 다음 TS 게이트웨이 MMC를 사용하여 특정 상태에서 허용할 RDP 기능을 정의하는 CAP(연결 권한 부여 정책)를 만듭니다. TS 게이트웨이 서버는 새 연결이 시도될 때마다 NPS로 검사하고 해당 연결에 대한 SoH(상태 설명)를 NPS로 전달하도록 구성됩니다. 그러면 네트워크 정책 서버가 SoH를 정책과 비교하여 클라이언트 상태에 따라 연결을 허용해야 할지 여부를 TS 게이트웨이에 알립니다.
그림 3에서 보듯이 조직의 보안 정책에서 자동 업데이트 사용을 요구하나 시스템이 Windows Update를 사용하지 않도록 구성되어 정책에 부합하지 않는 경우 사용자가 TS 게이트웨이에 연결을 시도하면 컴퓨터에서 SoH를 생성하여 전달합니다. 이 SoH의 내용은 "방화벽을 사용 중이며 바이러스 백신이 최신이지만 자동 업데이트를 사용하지 않습니다."와 같습니다. 이 경우 TS 게이트웨이에는 SoH를 디코딩하는 자체 논리가 없으므로 TS 게이트웨이는 이 SoH를 NPS에 전달하고 NPS에서 SoH를 관리자가 정의한 정책과 비교합니다. 자동 업데이트를 사용하지 않으므로 NPS는 연결이 "비준수" 정책에 해당하는 것으로 판단하여 TS 게이트웨이에 연결을 허용하지 않도록 지시합니다. 그러면 TS 게이트웨이가 연결을 끊고 사용자에게 컴퓨터가 조직의 보안 정책에 부합하지 않음을 알립니다. 사용자는 필요한 조치(이 경우 자동 업데이트 설정)를 취하고 연결을 다시 시도할 수 있습니다. 그 결과 새 SoH가 생성되고 NPS는 컴퓨터가 정책을 준수하는 것으로 판단하므로 TS 게이트웨이가 연결을 허용하게 됩니다.
그림 3 정책을 준수하는 시스템만 연결 가능 (더 크게 보려면 이미지를 클릭하십시오.)
결론
Windows Server 2008에는 안전하면서 어디서든 액세스 가능한 솔루션의 핵심이 되는 기초 구성 요소가 포함되어 있습니다. TS 게이트웨이는 인터넷을 통해 원격 데스크톱 세션을 안전하게 터널링하는 방법을 제공하며 조직에서 이 게이트웨이를 기존 네트워크에 통합할 수 있는 여러 옵션을 제공합니다. 선택할 수 있는 옵션으로는 TS 게이트웨이를 경계 네트워크에 직접 배치하거나, TS 게이트웨이의 전면에 ISA Server 또는 Intelligent Application Gateway와 같은 계층 7 방화벽을 사용하는 방식이 있습니다.
NAP를 TS 게이트웨이와 결합하면 솔루션에 끝점 상태 검사 기능을 추가할 수 있습니다. 조직에서는 끝점 검사를 통해 유효한 사용자가 원격 연결을 했는지 여부뿐만 아니라 해당 연결이 IT 보안 정책을 준수하는 컴퓨터에서 이루어졌는지도 확인할 수 있습니다. 이 두 기술을 함께 사용하는 경우 보다 안전하고 효율적으로 작동하며 최종 사용자에게 보다 나은 환경을 제공하는 원격 액세스 기능의 구현이 가능합니다. "터미널 서비스 리소스" 추가 기사에 나열된 사이트에서 더 많은 정보를 얻을 수 있습니다.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/138
cygni 2008/11/10 09:00
Microsoft Exchange 서버는 OWA, Outlook RPC over Http, 모바일 기기에서 사용 할 수 있는 ActiveSync 등 외부 사용자들이 Exchange 서버에 접근 할 수 있는 다양한 웹 클라이언트들을 가지고 있습니다.
하지만, 외부에서 사내의 Exchange 서버에 접근하여 메시지를 보거나 일정, 연락처 등을 작업 할 수 있는 것은 효율과 편리함이 강조되는 만큼 보안상 약점들 역시 노출하게 됩니다.
외부에서 접근하는 클라이언트의 편리성과 효율성을 증대하며 반대 급부인 보안상의 취약점을 줄이기 위해 최근 ISA 서버의 Exchange Server 게시 규칙을 이용하는 사례들이 많이 늘고 있는데요.
더보기
ISA서버의 Exchange 게시 기능을 이용하여, 외부 웹클라이언트 접근 시, OWA, Outlook Rpc over Http 연결을 제외하고 ActiveSync만 연결 가능하도록 하는 설정에 대해서 살짝 알아 보도록 하겠습니다.
외부에서 OWA나 RPC over Http 연결등을 허용해서 사용하는 경우가 많지만, 보안 상의 이유로 외부 웹클라이언트의 접속을 막고 있는 기업들도 상당 수가 있습니다. 이러한 환경에서 특정한 사용자들만 외부 웹클라이언트로 모바일 ActiveSync를 사용해야 하는 경우가 많이 있는데요. 보통 Exchange의 웹클라이언트는 80, 또는 433 포트를 통한 웹접속을 시도하고 되고, 해당 포트를 오픈하게 되면, ActiveSync뿐만 아니라 OWA나 Rpc over Http 연결도 가능하게 됩니다.
이러한 환경에서 ISA서버의 Exchange 게시 기능을 이용하면, 외부 웹클라이언트 접근 시, OWA, Outlook Rpc over Http 연결을 제외하고 ActiveSync만 연결 가능하도록 하는 설정 할 수 있습니다. 아래의 그림을 통해 살짝 알아 보도록 하겠습니다.
ISA서버는 그림과 같이 다양한 게시 규칙들이 제공이 됩니다 . 그중 Exchange 게시 규칙을 선택 합니다.
마법사를 통해서 작업이 가능하며, 간단한 게시 규칙 이름을 넣어 줍니다.
ISA 서버는 Exchange 전 버전을 지원하고 있습니다. 해당하는 Exchange 서버의 버전을 선택한 후 다양한 웹클라이언트 접속 중 Exchange ActiveSync만 선택하여 줍니다. 이렇게 설정하면, OWA나 Rpc over Http 접속은 차단이 되며, Exchange ActiveSync만 접속이 가능하도록 설정 할 수 있습니다.
An optimist is one who makes the best out of the worst of all~ 낙천주의자란 나쁜 것으로 최고의 것을 만드는 사람이다. cygni.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/130
cygni 2008/11/03 09:00
안녕하세요. 그동안 블로그 포스팅이 너무 뜸습니다. 정말 죄송하게 생각하고요. 또 함께 팀블로그를 운영하고 있는 다른 친구들에게도 너무 미안한 마음 입니다. 올 한 해도 이제 2달 남짓 남겨 놓고 있는데, 유종의 미를 거둔 다는 마음으로 열심히 한 번 달려 보겠습니다.
오늘은 ISA서버의 서버 사이징에 대한 간단한 방법을 포스팅 해보도록 하겠습니다. 바로 Capacity Planner라는 Microsoft ISA Server Home Page에서 제공해주고 있는 툴을 이용하는 방법인데요. ISA 서버가 아직까지는 국내에서 많이 사용되고 있는 제품이 아니다 보니, 도입 시 사이징에 대한 부분이 큰 골치거리 중의 하나였습니다. 아래의 Capacity Planner를 이용한 방법으로 ISA 서버 사이징에 조금이라도 도움이 되었으면 하는 바램 입니다.
더보기 [Capacity Planner를 이용한 결과]
아래의 링크에서 다음과 같은 정보를 입력 (계산기 아이콘: Capacity Planner)
http://www.microsoft.com/isaserver/default.mspx <- 영문 Site!!
1. 아래의 상황을 가정하여 입력하였습니다. (Network Traffic 1GB로 재세팅하여 결과치를 확인해보셔도 됩니다.)
1) ISA Reverse Proxy Mode concurrent user : 10,000
2) Network traffic per second : 400 Mbps
3) Reverse Hosting Web Site : 600
2. 실제 입력 값
1) Link capacity: 400000 Kbps
2) Concurrent users: 10000
3) CPU Speed: 3 GHz
4) Traffic: 100% HTTP (no HTTPS, OWA, RPC over HTTP, or VPN)
5) Bandwidth per user: 40 Kbps
6) Array type: NLB
Bandwidth per user를 구하기 위해 maximum network utilization (400Mbps)을 동시접속자수 number of concurrent users (10000)로 나누었습니다.
결과적으로 다음의 서버 개수와 1 GB RAM과 5 GB 하드 디스크가 필요한 것으로 나타났습니다.
Processor type: Nodes required
2-proc: 6
2-proc/dual-core: 3
[캐싱에 있어서 추가적인 고려 사항]
우선 ISA 서버 disk cache 성능에 가장 크게 좌우 되는 것은 disk seek time, (IOs/sec)이 되겠습니다. 10,000 RPM disk 가 버틸 수 있는 IOs/sec는 ~100로, 만약 이 한계를 넘어가게 되면 각 IO에 대한 평균 지연 시간이 상당히 증가되게 됩니다. 그러므로 캐싱을 위한 가장 중요한 요인 중 하나는 충분한 physical disks를 갖는 것이라고 할 수 있겠습니다. IOs/sec는 \PyisicalDisks(<disk>)\Disk Transfers/sec에 의해 바로 측정이 가능합니다. ISA에서는 모든 캐시가 IO를 유발시키며 모든 10-20여개의 cacheable misses (여기서 말하는 cacheable miss는 나중에 서비스 될 수 있는 오브젝트를 말하는 것)는 단일 IO로 디스크에 입력하게 됩니다. 이것은 대략 다음과 같은 공식을 이용하실 수 있습니다. IOs/sec = hits/sec + cacheable-misses/sec / 10. 예를 들어, 전체 cache hit ratio가 20%이고 50%의 misses가 모두 cacheable하다면, 1000 requests/sec에서의 IOs/sec = 200 + (500 / 10) = 250 가 되며 이것은 곧 최소한 3개의 physical disks가 필요하게 된다는 것을 예측할 수 있습니다.
경험상, 좋은 캐시 사이즈는 physical disk당 20-40 GB정도 입니다.
[CPU 성능에 대한 일반적인 사항]
Outbound f/w 테스트 결과에 의하면, 단일 펜티엄4 2.4GHZ에서는 25Mbps를 75%의 CPU utilization으로 나타납니다. 이것은 각 T1 인터넷 링크 (1.5 Mbps)에서 Microsoft f/w 서비스는 4.5%만이 CPU 리소스를 사용하게 됩니다. Dual Xeon 2.4-GHz 프로세서는 75%의 CPU utilization으로 대략 45 Mbps (T3)을 나타냅니다. (T1에서는 2.5% utilization이 나옵니다)
|
Internet link bandwidth |
Up to 5 T1 |
Up to 25 Mbps |
Up to T3 |
Up to 90 Mbps |
|
Processors/Cores |
1 |
1 |
2 |
2/2 |
|
Processor type |
Pentium III 750(MHz) or higher |
Pentium 4 3.0–4.0 (GHz) |
Xeon3.0–4.0 GHz |
Xeon Dual Core
AMD Dual Core
2.0–3.0 GHz |
|
Memory |
512 megabytes(MB) |
512 MB |
1 gigabyte (GB) |
2 GB |
|
Disk space |
150 MB |
2.5 GB |
5 GB |
10 GB |
|
Network adapters |
10/100 Mbps |
10/100 Mbps |
100/1000 Mbps |
100/1000 Mbps |
|
Concurrent virtual private network (VPN) remoteaccess connections |
150 |
700 |
850 |
2000 |
[결과]
종합적으로 볼 때 단일 ISA Server로 caching을 사용하는 것은 높은 트래픽량으로 (3GB에서 F5를 거쳐 들어오더라도 여전히 높은 1GB) 무리가 있을 것처럼 보입니다. 듀얼 코어로 최소한 2대에서 3대까지 서버당 1GB의 메모리와 20GB의 하드디스크는 필요로 할 듯 합니다.
[관련 링크]
더 자세한 사항은 다음 링크를 참고하시면 되겠습니다. http://www.microsoft.com/technet/isa/2006/perf_bp.mspx
또한 캐싱에 관련된 FAQ 사이트는 아래와 같습니다. http://www.microsoft.com/technet/isa/2004/plan/faq-caching.mspx

An optimist is one who makes the best out of the worst of all~ 낙천주의자란 나쁜 것으로 최고의 것을 만드는 사람이다. cygni.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/126
cygni 2008/09/08 09:00
Windows Server 2008 Cluster에 대한 간단한 데모 동영상을 만들어 봤습니다. File Server 리소스를
Cluster 위에 설치해서 Cluster Node 중 하나의 서버에 장애가 발생하여도, 파일서버를 사용하는데 아무런 문제가 없다는 아주
기본적인 Cluster 관련 동영상 데모 입니다. 추후에 구성 방법에 대한 것도 동영상으로 만들어 보겠습니다..
^^
Windows Server 2008 Cluster에 대해서 간단하게 알아 보신다는 마음으로 보시면 좋을 것 같네요..
more..
An optimist is one who makes the best out of the worst of all~ 낙천주의자란 나쁜 것으로 최고의 것을 만드는 사람이다. cygni.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/107
cygni 2008/09/01 09:00
Windows Server 2008 터미널 서비스를 이용한 프리젠테이션 가상화 데모를 동영상으로 만들어 보았습니다.. ^^; 간단히 살펴 보시면서, Windows Server 2008 터미널 서비스의 달라진 모습들을 확인하세요. ^^
more.. 원격지에서 응용 프로그램을 사용 할 수 있도록, TS RemoteAPP와 TS Gateway, TS WebAccess를 이용하여 구성했습니다.
An optimist is one who makes the best out of the worst of all~ 낙천주의자란 나쁜 것으로 최고의 것을 만드는 사람이다. cygni.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/103
cygni 2008/08/25 09:00
안녕하세요. 오랜만에 뵙습니다. ㅠ.ㅠ;; Windows Server 2008과 관련된 동영상을 제작하다가, 블로그에도 동영상 포스팅을 올려 보면 어떨까 하는 생각에 Windows Server 2008 Active Directory 그룹정책 중 그룹정책 기본설정에 대해서 간단하게 보여드리는 동영상을 만들어 보았습니다.. ^^ 스샷을 찍는다던가 하는 것 보다 훨씬 편해서 자주 애용해야지 하고 있습니다. ^^;;
more..
Windows Server 2008부터 그룹정책을 적용 할 때, 기존의 텍스트 기반의 정책과 더불어 GUI를 사용하여 그룹정책을 생성 할 수 있는 그룹정책 기본설정을 지원합니다. ^^ GUI.. 기존의 텍스트 기반 그룹정책들이 목록도 너무 많기도 했고, 또 말도 어려워서 대체 어디다가 어떻게 써야 하는지 잘 몰랐던 경우가 많았는데요. GUI기반의 그룹정책 기본설정 덕분에 그룹정책 적용이 조금은 쉬워지지 않았나 하는 생각을 해봅니다.
하지만, 그룹정책 기본설정은 기존의 그룹정책과 몇 가지 다른 제약 사항들을 가지고 있는데요.
해당 내용은 아래의 표를 참고 하시고, 자세한 내용은 꼬알라님의 포스팅을 통해서 확인 하세요. (표) 꼬알라의 하얀집 - 고급 그룹 정책 관리(3)
그럼 시범으로 만들어 본 동영상 화면 입니다. ^^;;
An optimist is one who makes the best out of the worst of all~ 낙천주의자란 나쁜 것으로 최고의 것을 만드는 사람이다. cygni.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/99
cygni 2008/08/04 09:00
지난 주, Windows Server 2008과 Exchange 2007 sp1 기반의 메시징 호스팅 환경을 테스트하다가 재미있는 구성을 해보게 되었습니다. Windows Server 2008 Failover Cluster와 Exchange 2007의 고가용성 시나리오인 CCR의 만남이었는데요.. ^^
가장 인상 깊게 다가왔던 것은 바로~!! Shared Storage가 필요 없는 고가용성의 구성이라는데 있었습니다.
more.. 기존의 Exchange 서버를 이용한 고가용성 구축 시에 가장 큰 문제는 Storage를 별도로 구매해야 한다는 비용 부담 측면이 강했었는데요 .
이 시나리오를 사용하다면 공유 스토리지가 없이도 구축이 가능하여 스토리지를 구매하는 비용을 절감 할 수 있다는 장점이 있습니다 .
이 시나리오를 구성하기 위해서는 Windows Server 2008과 Exchange 2007 sp1이 필요합니다.
엘도라도님께서 앞으로 Exchange 고가용성 포스팅을 통해서 좀 더 자세하게 설명을 해주실 거라 여기서는 Exchange Server 2007의 CCR 시나리오에 대한 설명은 피하기로 하고요. ^^;
구성의 기반이 되는 플랫폼 수준의 클러스터링을 위해서는 Windows Servrer Failover Cluster의 쿼럼 리소스 할당 방식을 Node and File Share Majority 방식이 사용 됩니다.
Node and File Share Majority란 Windows Server 2008의 클러스터 시나리오 중의 하나로 기존의 공유 스토리지에 쿼럼 리소스를 할당하는 방식이 아닌 각각의 노드의 로컬과 또 노드들이 공유하고 있는 파일 서버에 클러스터 정보를 저장하는 방식을 이야기 합니다. 이 클러스터 시나리오의 경우 클러스터 정보를 하나의 공유된 스토리지에 저장하는 것이 아니므로, 클러스터를 구성 할 때 각각의 노드들의 위치나 장소에 대한 제한을 받지 않습니다.
위의 그림은 Windows Server 2008의 Failover Cluster의 쿼럼을 구성하는 화면입니다. 마법사를 통해 원하는 클러스터시나리오에 따라 쉽게 쿼럼을 구성하여 다양한 시나리오를 구축 할 수 있습니다. Windows Server 2003까지 클러스터가 까다롭고 조금 어려운 작업에 속했다면, Windows Server 2008의 클러스터는 다양한 시나리오 제공 뿐만 아니라 쉽고 간단하게 구축이 가능하며, 관리 역시도 직관적인 관리 인터페이스를 통해 이전 버전에 비해 크게 향상되었습니다.
Windows Server 2003에서 Windows Server 2008로 넘어 오며 많은 부분이 바뀌고 향상이 되었으며, 클러스터 역시도 이전 버전에 비해 큰 기능 향상과 다양한 시나리오를 통해 기존의 MSCS가 가지고 있던 한계를 뛰어 넘어 발전해가고 있다는 느낌 입니다.

An optimist is one who makes the best out of the worst of all~ 낙천주의자란 나쁜 것으로 최고의 것을 만드는 사람이다. cygni.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/91
cygni 2008/07/28 09:00
안녕하세요. Cygni 입니다. 제 끝없는 게으름 탓에 오랜만에 포스팅을 올리게 되었네요.^^;; 좀 더 성실한 모습 보여드리도록 하겠습니다. 오늘은 이미지 검색의 달인 piclens를 소개 하려고 합니다. Piclens는 브라우저에 Add-On 형식으로 설치가 되어 이미지 검색 시 비주얼을 이용한 검색 방식을 제공 합니다. 아직 사용해보시지 않은 분들이라면 꼭 한 번 설치해서 사용해보세요.. ^^
http://www.piclens.com/를 통해서 다운로드 하실 수 있으며, IE와 FireFox를 지원하고 있습니다.
more..
Piclens를 실행하기 위해서는 아래 그림에서 보시는 바와 같이 브라우저 우측 상단의 아이콘을 클릭 하시면 실행이 되기도 하고, 또는 piclens를 지원하고 있는 검색엔진을 통해 검색어를 입력 후 검색이 되는 이미지를 클릭하여 piclens를 실행 할 수 있습니다.
브라우저에 Add-On 되어 있는 아이콘을 클릭하여 실행 시킨 모습 입니다. Piclens 검색창에서 원하는 이미지를 검색 할 검색포탈을 선택한 후 이미지 검색을 실행 합니다. 현재 piclens를 지원하고 있는 포탈은 Amazon, Flickr, Google, Yahoo, YouTube, DeviantArt, SmugMug, Photobucket 등이 있습니다. 아직까지는 국내 검색 포탈은 포함이 되지 않았네요.. ^^;
검색 포탈을 Google로 지정한 후 김태희 라는 검색어를 입력해보았습니다. 아래와 같이 검색된 이미지들이 piclens 상에 비주얼하게 브라우징 된 것을 확인 하실 수 있습니다. 보통 piclens를 설치 한 후 검색된 결과를 보면 우와~~ 하는 감탄사가 나오게 되죠.. .^^ 하지만, 아직까지는 감탄하기엔 조금 이릅니다. ^^;; 가벼운 마우스의 움직임을 통해서 횡으로 자동 스크롤되어 브라우징이 가능해.. 검색된 이미지들 중에서 쉽게 원하는 이미지를 찾을 수 있습니다. 원하는 이미지를 찾았을 때는 해당 이미지를 클릭하여 확대된 이미지를 볼 수 있습니다. ^^ 그리고, 이미지 아래에 원본 이미지의 위치가 표시 되어 해당 이미지를 포함하고 있는 웹사이트나, 블로그 등으로 연결이 가능 합니다. ^^
아래 그림과 같이 piclens를 통해 검색한 이미지의 원본 경로로 이동이 가능 합니다. 아직까지는 많은 검색 포탈들을 지원하고 있지 않고(국내 검색 포탈이 없어서... ㅠ.ㅠ) 또 IE와 Firefox 두 브라우저만을 지원하고 있어 사용 상 약간의 한계가 있지만, 그래도... 이미지 검색이 필요한 경우 활용하기에 따라서는 상당히 유용한 도구가 되어 주는 것 같습니다. 그리고, 훌륭한 비주얼 효과 덕분에 사용하는 재미도 쏠쏠하구요.. ^^ 기회가 되신 다면 꼭 한 번 설치해서 사용해보세요.. ^^
그럼 간단하게 piclens에 대해서 알아 보았고요.. 블로깅에 협조해주신 김태희 양에게도 고마움을..^^

An optimist is one who makes the best out of the worst of all~ 낙천주의자란 나쁜 것으로 최고의 것을 만드는 사람이다. cygni.
Trackback 0
:
Trackback Address :: http://www.hanulrang.com/trackback/87
|