오늘은 발표자료를 준비하면서 갑자기 엑셀에 있는 파일에 참고할 내용이 있게 되었습니다. 예전에 시트로 링크를 걸었는데 어찌했는지 기억이 가물가물 하드라구요. 하이퍼링크로는 파일단위로 걸 수 있는데 시트는 어떻게 연결해야 하는지 .. 그래서 이번에 잊어먹더라도 정리해 보았습니다. 아주 간단해서 올리는데 뻘쭘하네요.^^ (Powepoint 2007기준 설명, 2003도 내용은 동일합니다.)
우선 엑셀과 연결할 파워포인트 파일을 하나 엽니다. 여기선 간단하게 새로 생성해 보겠습니다.
연결할 Excel파일의 시트명을 확인합니다.
여기서는 예제로 파일명은 2008년보고서, 시트명은 2사분기를 링크를 걸어보겠습니다. 파워포인트 파일에 링크를 연결할 내용을 선택하여 [삽입] - [하이퍼링크] 를 선택합니다. 그리고 연결할 파일을 선택합니다.
일반적으로 위의 작업까지만 진행이 되는데요. 이제 원하는 시트는 직접 입력하여 아래와 같이 넣어 주시면 됩니다. 파일명.xlsx#'시트명'!셀주소
이와 같이 작업 후 하이퍼링크 테스트시 정상적으로 원하는 시트의 셀 주소에 위치함을 알 수 있습니다.
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에 대한 계획,정책,배포,구성,모니터링,결과 분석 등의 일련의 연속성을 가진 보안 운영의 틀을 만들어 주는, 보안 인프라를 구성하고 있다고 말씀을 드릴 수 있을 것 같습니다.
MDT2008(LTI) 계속 포스팅 되고있습니다 !! 이번 시간에는 MDT2008을 구성할 떄 꼭 필요한 툴을 알아보겠습니다 처음 시간에 말씀드렸듯이 windows2003에는 .net과 xml이 필요합니다 또 공통적인 부분은 DHCP(지난시간에 포스팅), MDT, WAIK가 필요합니다
어떤 툴이 필요한지 알아볼까요~?
Windows 2003에서 필요하는 툴
공통적으로 설치해야 하는 기능 툴
배포도구 설치 부분
Windows2008에서 배포도구는 기능추가 – 원격 서버 관리도구 – 역할관리도구 부분에 있습니다
설치만 다해도 MDT2008(LTI)의 절반은 했다 할 수 있습니다…(나만의 생각??)
다음시간부터는 설정법에 대해서 알아보도록 할께요~!
보이세요?? 나는 지금도 여전히 도전하고 있습니다!! Always Smile ^___________^
현재 이 글을 읽고 계신분들은 어느정도 Hyper-V가 어떤거고 설치도 좀 해보신 분들이지 않을까라고 생각이 듭니다.
Hyper-V가 이전 가상화 프로그램 중 하나인 Virtual Server 2005에 비해서 하드웨어 사용 성능이 많이 좋아진건 사실입니다. 이제는 어느정도 서버로서 사용해도 될 정도의 성능을 보이고 있습니다.
성능이 좋아진건 어느정도 기쁜소식인데, 이에 반해 원격관리가 상당히 불편하다는 단점이 있습니다.
기본적인 설정으로 Virtual Server 2005는 VMRC포트인 5900번만 게시해주면 외부 어디서나 접근이 가능했죠. 그런데 Hyper-V는 그렇게 할 수 없어서 서버를 원격데스크탑으로 연결해서 사용하거나 각각의 Virtual OS에 Real IP를 부여해서 각각 원격데스크탑으로 연결해야하는 등 한눈에 전체 Virtual OS를 관리하기가 많이 불편했었습니다. 가끔은 성능이냐, 편리성이냐의 사이를 왔다갔다 할 때가 많았죠.
그럼, Hypver-V 원격관리를 아예 할 수 없느냐 그건 아닙니다.
클라이언트가 Windows Vista With SP1 이상이거나 Windows Server 2008이라면 가능은합니다.
Windows Vista with SP1이나 Windows Server 2008 without Hyper-V에서 Windows Server 2008에 설치된 Hyper-V를 관리하기 위해선 추가적으로 Hyper-V Management를 설치해야합니다.
같은 도메인 환경이라면 Menagement Console을 설치하면 간단하게 원격 관리가 가능하겠지만 그런경우가 아닌 서버 또는 클라이언트가 Workgroup라면 어떻게 해야할까요? 그리고 클라이언트가 외부에 있고 서버가 사내에 있을 경우는 어떻게 해야할 까요?
이 문제를 해결하기 위해 전 이 방법을 생각해봤습니다.
외부에서 사내에 VPN연결을 한 후 VPN Client에서 Hyper-V Management Console을 이용해서 원격에 있는 Hyper-V를 관리한다.
설치는 아래 코알라님께서 너무 자세하게 설명해 놓으셔서 따로 제가 포스팅 할 건 없구요
대부분 위 방법대로 진행하시면 서버편은 아무 이상없이 잘 진행이 되는데
원격 클라이언트에서 로그인 한 계정과 실제 Hyper-V관리자 계정이 다를 경우 로그인이 안되서 당황하시는 분들이 있습니다.
읽어보시면 코알라님께서 설명을 잘 해 놓으셨습니다.
인증 순서가 만약 네트워크 암호 관리에 저장된 설정이 있다면 그 정보를 가지고 인증하고, 없다면 현재 로그인한 계정과 비번으로 인증을 시도합니다.
따라서 로그온한 계정과 Hypver-V관리자 계정과 비번을 맞춰주거나, 사용자 계정에서 네트워크 암호 관리를 아래와 같이 추가해 주시거나 입니다.
네트워크 암호 관리에 추가하는 방법은 아래와 같이 간단하게 명령어로 입력해 설정할 수 있습니다..
진짜 진짜 주의하실 점은아래 빨간색 굵은 글씨입니다. 서버 IP아닙니다. 서버이름입니다. 꼭 지켜주세요. ^^
cmdkey /add Hyper-V서버 이름 /user:Hyper-V서버이름\계정 /Pass
입니다.
위 설정이 정상적으로 됐다면 원격에서 아래와같이 Hyper-V를 관리하실 수 있습니다.
집에 연결된 케이블 망이 느린지 상당히 느립니다. ㅜㅜ
서버를 관리하고 운영하는 관리자의 입장에서 사내의 서버를 언제 어디서든 연결 할 수 있다는 것은, 운영을 좀 더 편리하게 해주고, 관리와 운영에 효율성을 증대해주는 일임에도 불구하고, 보안상의 취약점으로 인해 외부에서의 연결을 자제해오거나, 아니며 보안 위협을 무시한체 외부에서의 연결을 허용하고 있는 것이 전산 시스템을 운영하고 있는 많은 기업들이 안고 있는 문제인 것 같습니다.
아래의 글은 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 보안 정책을 준수하는 컴퓨터에서 이루어졌는지도 확인할 수 있습니다. 이 두 기술을 함께 사용하는 경우 보다 안전하고 효율적으로 작동하며 최종 사용자에게 보다 나은 환경을 제공하는 원격 액세스 기능의 구현이 가능합니다. "터미널 서비스 리소스" 추가 기사에 나열된 사이트에서 더 많은 정보를 얻을 수 있습니다.
아직도 Exchange Server 2007 제품의 대하여 전혀 모르는 분들이 많은 듯 하여 웹캐스트 링크를 정리 하였습니다.
대부분 영문으로 진행되는 웹캐스트이지만, 이번에 소개하는 웹캐스트는 한글로 진행 된 "Exchange Server 2007" 세미나를 모아 보았습니다.
Exchange Server 2007을 공부하고, 이해 하시는데 많은 도움이 되었으면 합니다.
MOSS 2007(Microsoft Office SharePoint Server)를 사용하다 보면, 업무상 각 해외 지사에서도 사용할 수 있도록 다국언어를 지원해야 하는 경우가 있게 됩니다. 이때 각 사이트별로 다른 언어를 지원해 준다면 참으로 좋겠죠? 물론 사이트 생성시 언어팩을 설치가 되어있으면 이 환경이 가능케 됩니다. 그럼 어서 아래로...
아래 각각 필요한 설치언어 파일을 다운받아 설치하시기 바랍니다.
KOR
SharePoint Server 2007, Forms Server 2007, Project Server 2007 및 SharePoint Server 2007 for Search용 2007 Office system 언어 팩
Microsoft 소프트웨어 사용권 조항 보기 페이지에서 내용을 검토하고 동의함 확인란을 선택한 다음 계속을 클릭합니다.
설치 유형 페이지에서 기본을 클릭합니다.
설치 마법사가 실행되고 언어 팩이 설치됩니다.
기본 설정을 사용하여 SharePoint 제품 및 기술 구성 마법사를 다시 실행합니다.
참고: 언어 팩을 설치한 후 SharePoint 제품 및 기술 구성 마법사를 실행하지 않으면 언어 팩이 제대로 설치되지 않습니다.
SharePoint 제품 및 기술 구성 마법사를 다시 실행하는 방법
시작을 클릭하고 모든 프로그램과 관리 도구를 차례로 가리킨 다음 SharePoint 제품 및 기술 구성 마법사를 클릭합니다.
SharePoint 제품 및 기술 페이지에서 다음을 클릭합니다.
구성하는 동안 일부 서비스를 다시 시작해야 할 수도 있다는 대화 상자가 나타나면 예를 클릭합니다.
서버 팜 설정 수정 페이지에서 이 서버 팜과 연결 끊지 않기를 클릭한 후 다음을 클릭합니다.
SharePoint 중앙 관리 웹 관리 설정 수정 페이지가 나타나면 기본 설정을 아무 것도 수정하지 않고 다음을 클릭합니다.
SharePoint 제품 및 기술 구성 마법사 완료 페이지에서 다음을 클릭합니다.
구성 완료 페이지에서 마침을 클릭합니다.
사용 방법
특정 언어 관련 사이트 서식 파일은 \Program Files\Common Files\Microsoft Shared\web server extensions\12\template\number 디렉터리에 설치되며, 여기에서 number는 설치하는 언어의 언어 ID입니다. 예를 들어 영어(미국) 언어 팩은 \Program Files \Common Files\Microsoft Shared\web server extensions\12\template\1033 디렉터리에 설치됩니다. 언어 팩을 설치한 후 사이트 소유자 및 사이트 모음 관리자는 SharePoint 사이트나 사이트 모음을 새로 만들 경우 언어를 지정하면 특정 언어 관련 사이트 서식 파일을 기반으로 사이트 및 사이트 모음을 만들 수 있습니다.
MUI를 설치합니다.
설치파일 완료
IIS, Sharepoint Administration Service, Sharepoint Timer Service 를 잠시 중지하고 설치를 계속 진행하게 됩니다.
구성요소 설치과정 Step을 거친 후 구성완료가 나오면 정상적으로 설치를 완료하게 된 것입니다.
설치 완료 후 중앙관리사이트 - 응용프로그램 관리 - 사이트 만들기에서 적용된 Templete 확인해 보시면 언어를 선택할 수 있습니다. 언어선택에 설치된 언어가 나온다면 성공~! ㅊㅋㅊㅋ