분명 바람직한 것임에도 불구하고, 그리고 그 필요가 절실함에도 불구하고, DNS(Domain Name System)를 위한 보안 익스텐션은 아직 널리 사용될 준비가 되지 못했다. 그러나 앞으로 툴들이 나오고, 보다 폭넓은 채택이 이루어지는 때가 오면 상황은 달라질 수 있을 것이다.
WWW.yahoo.com 같은 호스트 네임을 입력할 때 응답하는 IP 어드레스가 실제로 불량이 아닌 야후 서버 가운데 하나로 향하는지 어떻게 알 수 있을까? 한 마디로 답하자면, 알 수 없다.
지난 해 시만텍의 딥사이트(DeepSignt) 시스템은 다양한 DNS 서버와 리졸버(resolver)에 대해 25가지 취약성을 보고한 바 있다. 사실 DNS가 위조 정보를 제공하도록 파괴될 수 있는 방법들은 수없이 많다.
공격자는 DNS 서버로 액세스를 확보해 기록을 바꿀 수도 있고, 혹은 공개적으로 사용 가능한 많은 툴들 가운데 하나를 이용해 응답을 위조할 수도 있다. 공격자는 우리가 수많은 웜이나 트로이언에서 보는 것처럼 DNS 캐시로 위조 정보를 삽입할 수도 있으며, 혹은 컴퓨터의 호스트네임 테이블에 가짜 정보를 추가할 수도 있다.
이러한 공격들 가운데 상당수는 성공하기 힘든 것들이며, 수명이 짧고 비교적 탐지와 수정이 간편한 경우도 많다. 예를 들어 사용자가 웹 사이트에 액세스할 수 없다고 불평하기 시작할 때가 그러하다. 하지만 이들이 살아 있는 동안에는 손해가 발생할 수 있다.
작동 방식
IETF의 DNS 익스텐션 워킹 그룹은 10년 가까이 DNS 보안에 주력해 왔으며, 기본적인 프로토콜 변화들을 만들어 냈다. 지금은 RFC 4033, 4034 및 4035가 코멘트용의 핵심 DNS 보안 요청을 구성하고 있다. DNSSec의 주목표는 DNS 클라이언트에 의해 검증될 수 있는 공중키 암호를 이용해 질의에 인증받은 DNS 응답을 제공한다는 것이다.
DNS는 크긴 하지만 간편한 영역(zone)의 계급(herarchy)이며, 왼쪽에서 오른쪽으로 호스트네임을 읽음으로써 DNS 나무를 걸어갈 수 있다. 예를 들어 www.exa mple.com이란 도메인 이름에서 www는 example이란 영역의 호스트 네임이다. example은 com에 있는 영역이며, com은 루트 영역 아래 있는 TLD(Top Level Domain)다.
DNSSec가 사용될 경우에는 DNSSec 인지 클라이언트가 인증 고리를 걸어 올라가 공중키 암호를 이용해 각각의 DNS 응답을 권위가 있는 것으로 검증할 수 있다. 비밀키가 모든 영역 관리자들에 의해 보안으로 처리될 경우 www.example.com을 구성하는 DNSSec 서명 응답은 검증된 응답이 될 것이다. 공격자가 위조된 응답을 스푸핑하려 한다면 그 위조는 탐지될 것이다.
정상적으로 볼 때 컴퓨터에 있는 DNS 클라이언트, 즉 스터브 리졸버(stub resolver)는 호스트네임을 IP 어드레스로 해석하는 작업을 하고, 선택적으로 응답을 캐싱하며, 그런 다음 스터브 리졸버에게 대답을 보내는 순환 DNS 서버에 DNS 질의 프로세스를 넘긴다. IETF의 계획에 따르면 DNSSec를 사용하는 스터브 리졸버는 순환 리졸버에게 DNS 검증을 오프로딩할 수 있지만, 스터브와 순환 리졸버간 통신은 어떤 식으로든 보안이 돼야 한다.
DNS 클라이언트와 서버간에 IPSec 프로토콜의 AH (Authentication Header)를 사용하는 것도 한 가지 방법이다. 혹은 스터브 리졸버가 DNSSec를 인지할 경우 이것은 모든 DNSSec 기록을 요청하고 그 자신의 검증을 수행할 수 있다. DNSSec는 후방 호환이 가능해야 하기 때문에 두 가지 옵션이 모두 지원된다.
앞서 언급한 예에서 트러스트가 시작되는 곳인 트러스트 앵커(trust anchor)는 루트 영역이며, 고리에서 연이어 서명된 각각의 영역으로 흘러 내려간다. 트러스트 앵커를 제외하고 DNSSec에 있는 모든 공중 키는 DNS를 통해 배포될 수 있다. 이 예에서는 영역이 트러스트 섬이 될 수 있는 곳에서 DNSSec가 사용될 수 있는데, 여기서 영역은 한 쌍의 키를 만들고 그 자신의 공중 키에 서명을 한다.
닭과 달걀의 문제
글로벌 DNSSec 배치에 있어 가장 큰 장애물은 닭과 달걀 문제다. 글로벌 DNSSec 환경을 위해서는 루트 영역이 서명돼야 할 필요가 있다. 모든 .com, .net, .info, .bix, .uk 같은 모든 TLD들도 또한 서명이 돼야 한다. 그리고 이들 아래에 있는 모든 도메인들도 DNSSec를 활용하고 싶으면 역시 서명이 돼야 한다.
DNS 영역 매니저는 이제 암호 키 관리에 포함되기 시작했다. 게다가 베리사인이나 고대디 같이 도메인 이름 등록을 처리하는 등록 기관들도 DNSSec와 보안 등록 프로세스를 지원해야 할 것이다. 그리고 이것은 단지 DNS Sec가 배치되는 데 필요한 것들이다.
클라이언트 쪽을 보면, 회사와 ISP에 의해 사용되는 모든 순환 DNS 서버들은 DNSSec를 인지할 수 있어야 하는데, 그 이유는 아무도 사용할 수 없다면 DNSSec를 배치할 이유가 없기 때문이다. 데스크톱과 서버에서 사용되는 스터브 리졸버는 DNSSec 인지가 돼야 하지만, 마이크로소프트는 이 시점에서 윈도에 DNSSec 인지 스토브 리졸버를 구축할 계획이 전혀 없다. 마지막으로 DNSSec, 키 관리 및 배포 프로토콜을 관리하기 위해서는 프로세스와 제품이 개발 및 배치돼야 한다.
이것은 변화가 심한 부분들이며, 보다 낮은 레벨의 모든 구성요소들이 갖춰지지 않는다면 TLD 사업자들이 DNSSec를 배치하는 경비를 굳이 감당할 이유가 없다. 영역 파일 크기가 7~10배가 늘어난다고 가정하면 대역폭에 그 영향이 미칠 것이다. 게다가 베리사인의 CSO이자 DNSSec 개발에 적극 참여하고 있는 켄 실바가 지적한 것처럼, 서버 가용성, 영역 데이터의 무결성, 그리고 DNS 서버 소프트웨어 및 OS 보안 등과 같이 DNS를 둘러싼 다른 더 심각한 보안 문제들도 있다. 이 모든 것들은 단기적으로 DNSSec가 미치게 될 것보다 훨씬 큰 영향을 DNS에 미칠 수 있다.
성능 시험장
하지만 푸에르트리코나 스웨덴 같이 보다 작은 TLD 운영자들의 DNSSec 배치와 파일로트 프로젝트를 계속 주시할 필요가 있는데, 그 이유는 이들은 DNSSec와 필요한 관리 프랙티스의 시험장이 되고 있기 때문이다.
미 상무성에 속해 있는 NIST(National Institute of Standards Technology)도 또한 .gov 도메인을 위한 DNSSec 파일럿 프로젝트를 적극 추진하고 있으며 FISMA(Federal Information Security Management Act) 필요조건의 하나로 밀고 있다. 보안 등급이 높거나 중간인 컴퓨팅 시스템용의 특정 보안 제어에서는 DNSSec가 중요한 역할을 하게 될 안전하고 권한이 있는 DNS를 필요로 한다.
DNSSec는 분명 바람직한 것이긴 하지만 조직 내에서 트러스트의 섬을 배치하는 데 드는 수고와 윈도 플랫폼에서 DNSSec를 활용할 수 있는 스터브 리졸버의 부재, 그리고 글로벌 DNSSec 전략의 부재 등으로 인해 지금 현재 굳이 이것을 추구해야 할 이유를 찾기가 힘들다. 툴들이 나오고 보다 폭넓은 채택이 이뤄지는 때가 오면 물론 이야기는 달라질 것이다.
요점 정리
약속 타인에 의해 검증될 수 있는 암호 서명(cryptographic signatures)을 사용함으로써, DNSSec는 호스트네임 어드레스 룩업이 합법적이고 허가받은 응답이 되도록 보장해 준다.
참여 기관 IETF에서는 DNSSec 표준을 개발했으며, BIND와 마이크로소프트 개발 단체인 인터넷 시스템 컨소시엄(Internet Systems Consortium)에서 오늘날 사용되고 있는 DNS 서버 부분을 만들었다. 그리고 DNSSec 가이드라인의 선전은 NIST와 DoD에서 담당하고 있다. 그 외에도 .com이나 .net을 위해서는 베리사인 같은 TLD(Top-Level Domain) 사업자들이 있으며, 인터넷 인프라스트럭처 파운데이션(Internet Infrastructure Foundation)에서는 .se 도메인을 운영하고 있다. 스웨덴에서는 TLD가 활동 중이며, nic.pr은 푸에르토리코의 .pr TLD를 관리하고 있다.
전망 지원의 부재와 확실한 주동자가 없다는 것이 배치 일정에 걸림돌이 될 것이다. 하지만 미 정부의 2002년 FISMA(Fedreal Information Security Management Act)를 지적하는 사람들도 많은데, 그 이유는 FISMA가 일부 정부 기관에만 적용되며 DNSSec의 사용을 요구하고 있지 않기 때문이다.
훨씬 저렴하게, 하지만 훨씬 높게
‘성능·확장성·가격’ 3박자 완벽 … 확장성 우수한 APM 제공
본지에서 연속으로 실시하고 있는 진행 중 APM(Aplication Performance Management) 소프트웨어 리뷰의 다섯 번째 주자는 바로 님소프트(Nimsoft)의 님부스(Nimbus)다. 님소프트는 가장 가까운 경쟁자보다 훨씬 낮은 가격으로 확장성 있는 APM을 제공함으로써 보다 규모가 큰 기업용 소프트웨어 업체들과 곧잘 동등한 대접을 받고 있는 곳이다.
님부스는 실시간 시스템 모니터링과 보고 기능, 서비스 수준 협정 정의, 모니터링 및 보고, 그리고 종단간 응답시간 측정 등에 초점을 두고 있다. 이러한 모든 통계들은 구성 가능하고 맞춤화가 가능한 비즈니스 서비스 및 작동 성능 대시보드를 통해 제시된다.
애플리케이션 환경으로부터 데이터를 수집하기 위해 님부스는 다양한 대행자(agent)와 폴링(polling) 방안에 의존하지만, 이전 리뷰에서 보여진 것처럼 네트워크 트래픽 모니터링을 사용하지는 않는다.
마이크로소프트 익스체인지, IIS 및 액티브 디렉토리 등 인기 있는 애플리케이션들이 아웃오브더박스(out-of-the-box)로 님부스 에이전트를 통해, 혹은 님소프트 식으로 말하자면 ‘프로브(probe)’들에 의해 모니터링된다. 웹스피어, 시트릭스 및 SAP용으로 추가 프로브 또한 사용 가능하다. 게다가 님소프트는 일반적인 모든 데이터베이스뿐만 아니라 윈도, 유닉스, 리눅스 시스템에만 있는 다양한 기능들을 추적하며, 네트워크 작동을 모니터링한다.
간편한 구성
님부스는 우리 환경에서 쉽게 셋업 및 구성할 수 있었으며, 현재까지 리뷰한 제품들 가운데 유일하게 웹 기반 대시보드를 자동으로 구축하고 수집된 성능 데이터를 보고했다.
님부스에는 또한 유연하고 강력한 SLA 보고 엔진이 있다. 이것은 우리가 모니터링되는 컴포넌트 그룹을 포괄적인 서비스 구도 속에 통합시킴으로써 애플리케이션 SLA를 수동으로 만들 수 있게 해주었다.
우리는 지정된 업무 시간 동안 SLA 성능을 보고하고, 유지보수 창과 같은 특정 시간대를 제외시킬 수 있었다. 님부스는 또한 SLA 아래서 작동하는 엘리먼트(element) 그룹 안에서 특정 시간 동안 특정 컴포넌트를 제외시킬 수 있다. 이러한 정밀성은 IT 조직에서 SLA 범주 밖으로 떨어지는 고객이 발생시킨 고장 때문에 잘못된 애플리케이션 컴포넌트를 제외시키고자 할 때 유용하다. 이러한 일은 너무나 빈번하게 발생하고 있음에도 불구하고 많은 APM 툴들이 이런 상황을 제대로 해결하지 못하고 있다.
네트워크 컴포넌트나 서버, 혹은 애플리케이션에서 변화가 탐지가 되면 서비스 뷰가 수동으로 업데이트돼야 한다. 서비스 모델이 구성 데이터베이스에 저장된 정보로부터 자동으로 구축될 수 있게 해주는 CMDB로의 통합이 없다는 사실은 님부스에서 다소 실망스러웠다. 님부스 내에서 이런 서비스 뷰를 수동으로 만들기는 비교적 간편하긴 했지만, 그래도 관리자는 다중계층으로 구성된 애플리케이션의 모든 컴포넌트를 제대로 알고 이해해야 할 필요가 있다.
저렴한 가격
이번 테스트에서 기반 시스템 성능(CPU, 메모리, 디스크, 핵심 프로세스들)을 모니터링하는 개별적인 프로브들뿐만 아니라, IIS나 MS SQL 같은 보다 전문적인 프로브들도 이용했다. 우리는 또한 ICMP 핑 등 몇 가지 데이터 수집 방안을 이용해 애플리케이션의 가용성을 모니터링하도록 님부스를 구성했으며, 특정 웹 페이지의 가용성을 테스트하며, 복잡한 합성 트랜잭션을 돌렸다. 이 모든 것들은 아무런 문제없이 잘 수행됐다.
이러한 별개의 데이터 수집 방식들로부터 모인 정보는 우리가 종단간 애플리케이션 성능뿐만 아니라 세부적인 애플리케이션 성능까지도 볼 수 있게 해주었다. 여기에 님부스 SLA 엔진이 힘을 합쳐 우리는 비즈니스 크리티컬 시스템이 어떻게 수행됐는지에 대한 큰 그림을 얻을 수 있었다.
아웃오브더박스 기능을 보자면 프로브에는 쉽게 맞춤화가 가능한 모니터링된 값과 미리 구성된 스레숄드가 함께 따라왔다. 님부스 아키텍처에는 데이터 통신용으로 퍼블리시/섭스크라이브(publish/subscribe) 모델 이용이 포함돼 있다.
님부스 도메인 안에 있는 애플리케이션에 공유해야 할 새 데이터가 있으면, 메시징 버스와 모든 가업자가 일단 수신하고 난 후 이것은 자동으로 퍼블리싱된다. 이러한 기능은 님부스 컴포넌트와의 통신에서 부하를 덜어주며, 현재까지 테스트한 APM 제품들 가운데 유일한 것이기도 하다. 우리는 또한 하나의 단일 님소프트 관리 콘솔이나 웹 지원 인터페이스를 통해 모든 퍼블리케이션과 섭스크립션을 구성할 수 있었다.
처음 우리가 이 제품의 가격을 보았을 때는 님소프트가 동그라미를 몇 개 빠뜨린 줄 알았다. 하지만 님부스의 테스트 구성 가격은 실제로 약 2만달러였으며, 그것도 기본 애플리케이션; 합성 트랜잭션, 그리고 IIS, MS-SQL, 윈도 서버 및 네트워크 장비 모니터링용 프로브가 포함된 가격이었다.
요점 정리
주장 님소프트 님부스는 첫 구매 및 이행 비용면에서, 그리고 진행 중 관리 면에서 시중에 나와 있는 다른 관리 제품에 비해 훨씬 저렴하면서 동시에 보다 뛰어난 확장성을 제공한다. 덕분에 기업 전체 애플리케이션 인프라의 신속한 배치와 종단간 서비스 수준 관리가 가능하다.
상황 조직들은 보통 대형 업체들이 내놓는 값비싼 기업 등급의 소프트웨어를 선택할 것인지, 아니면 경쟁적인 기능들을 제공하지만 기업이 성장할 때 확장성이 제한을 받는 작은 소프트웨어 업체들과 함께 할 것인지를 결정해야 한다.
신뢰성 님부스는 우리가 지금까지 보아온 제품들 가운데 최저 가격으로 애플리케이션 성능 관리를 위한 확장성을 기업에 제공할 수 있는 최초의 제품이다. 이 제품은 설치하고 맞춤화하는 데 노련한 소프트웨어 엔지니어의 시간을 얼마간 필요로 하지만, 계속해서 신경을 쓰고 피딩할 필요는 없다.
