PART 04 12 - lily.mmu.ac.krlily.mmu.ac.kr/lecture/16is/P4-CHAPTER12.pdf · chapter 12 snmp를사용해오고있다. snmp를널리사용하면서새로운요구사항을수용할 수있는새로운기능이필요하게되었다

12네트워크 관리 보안

12.1 SNMP의 기본개념

12.2 SNMPv1 공동체 서비스

12.3 SNMPv3

12.4 추천 자료와 웹 사이트

12.5 주요 용어, 복습문제와 연습문제

Net

wor

k S

ecur

ity E

ssen

tials

CHAPTER

PART04 네트워크 관리 보안, 법과 윤리

규모 군 를 통솔하는 것은 몇 명을 통솔하는 것과 같다. 오직 그 수를 어떻게 나누느냐가

문제일 뿐이다.

—《손자병법(The Art of War)》, 손자(Sun Tzu)

기업, 정부, 그리고 다른 기관에 있어서 네트워크와 분산 처리 시스템은 보안적

인 위험에 노출되어 있고 그 중요성이 부각되고 있다. 한 기관 내에서 네트워크는

점점 커져가고, 보다 많은 응용 프로그램과 더 많은 사용자를 지원해야 하는 복잡

한 네트워크로 변하고 있다. 이런 네트워크가 점점 커지면서 안타깝게도 두 가지

문제점이 드러났다.

●기관은 네트워크, 네트워크와 연관된 자원, 분산된 응용 프로그램에 절 불가결

하게 의존하게 되었다.

●이것보다 상황이 더 좋지 못할 수도 있는데 이것은 네트워크 전체 혹은 일부가

마비되거나 수용할 수 없을 정도로 성능이 저하되기도 한다는 것이다.

규모 네트워크는 사람의 노력만 가지고 구성하거나 관리할 수 없다. 이런 시스

템의 복잡성 때문에 자동화된 네트워크 관리 도구를 사용할 수밖에 없다. 네트워크

에 사용하는 장치가 여러 벤더에 의해 만들어진 것이라면 이런 자동화된 도구가 더

필요하게 될 것이고 이런 도구를 마련하는 것 또한 어려워질 것이다. 이런 필요성

에 부응하여 서비스, 프로토콜, 그리고 관리정보베이스를 포함하는 네트워크 관리

문제를 다룰 표준을 개발하 다. 지금까지 가장 널리 사용되는 표준으로는 단순 네

트워크 관리 프로토콜(SNMP: Simple Network Management Protocol)이 있다.

1988년 발표된 이래, 네트워크 수의 증가와 갈수록 복잡해지는 환경에서

568

네트워크 관리 보안12CHAPTER

Network Security Essentials

CHAPTER 12

SNMP를 사용해오고 있다. SNMP를 널리 사용하면서 새로운 요구사항을 수용할

수 있는 새로운 기능이 필요하게 되었다. 또한 네트워크 관리의 일부로 보안기능

이 중요한 문제점으로 떠올랐다. 강화된 기능을 제공하기 위해 SNMP 버전 21)를

정의하 고 그 후 보안을 강화해서 SNMPv3를 발표하 다.

이 장에서는 SNMPv1에서 사용할 수 있는 기초적인 보안기능과 SNMPv3가 제

공하는 훨씬 광범위한 보안기능에 해 설명하기로 한다.

이 절에서는 SNMP의 기본적인 프레임워크에 한 개요를 살펴보기로 한다.

네트워크 관리 구조

네트워크 관리 시스템이란 다음과 같은 관점으로 집약할 수 있는 네트워크 모니터

링과 제어를 위한 도구 집합체를 말한다.

● 부분의 혹은 모든 네트워크 관리 작업 수행을 목적으로 강력하지만 사용자-

친화적(user-friendly)인 명령어 집합을 구비한 단일 운용자 인터페이스.

●최소량의 독립 장치. 즉, 네트워크 관리에 필요한 부분의 하드웨어와 소프트웨

어는 기존의 사용자 장치에 들어 있다.

네트워크 관리 시스템은 기존 네트워크 구성요소 사이에 구현될 하드웨어와 소

프트웨어를 추가하여 구성한다. 네트워크 관리 작업을 수행하는 데 필요한 소프트

웨어는 호스트 컴퓨터와 통신 프로세서 안에 있다(예를 들면 전단처리기2)(front-

end processor), 클러스터 제어기3)(cluster controller)). 네트워크 관리 시스템은

569

네트워크 관리 보안

12.1 SNMP의 기본개념

1) 버전 2는 SNMPv2로 표시한다. 원래 버전을 다른 새 버전과 구별하기 위해서 원래 버전을 이제는 보통

SNMPv1이라고 쓴다.

2) 형 컴퓨터의 회선 제어를 담당하는 소형 컴퓨터. 단순한 회선 제어뿐만 아니라 보통 형 처리기가 해

야 하는 오류 탐지, 사용자 검색, 문자 반향 등과 같은 일도 한다. 1비트 완충 방식과 회선 탐색법이 있

다. — 역자 주

각 포인트에 부여된 주소와 레이블, 각 요소의 특정 속성 그리고 시스템에 알려진

링크를 갖춘 네트워크 전체를 하나의 통합된 구조로 보도록 설계되었다. 네트워크

의 활성화된 요소는 규칙적으로 상태정보를 네트워크 제어 센터로 피드백

한다.

SNMP에 사용되는 네트워크 관리 모델은 다음 주요 요소를 포함한다.

●관리지국(Management station)

●관리에이전트(Management agent)

●관리정보베이스(Management information base)

●네트워크 관리 프로토콜(Network management protocol)

관리지국은 일반적으로 따로 떨어진 독립 장치지만 공유 시스템의 경우에 그 기

능을 나누어서 구현할 수도 있다. 두 경우 모두에, 관리지국은 네트워크 관리자(사

람)를 네트워크 관리 시스템에 연결해주는 인터페이스 역할을 한다. 관리지국은

적어도 다음 요소를 갖추어야만 한다.

●데이터 분석이나 장애 복구 등을 위한 관리 응용 프로그램의 집합

●네트워크 관리자가 네트워크를 모니터하고 제어할 수 있는 인터페이스

●네트워크 관리자의 요구사항을 네트워크상의 원격 요소에 한 실제적 모니터링

과 제어로 변환할 수 있는 능력

●네트워크에 있는 모든 개체의 관리정보베이스로부터 추출한 정보 데이터베이스

앞에 언급한 것 중 오직 마지막 두 사항만이 SNMP 표준의 주제이다.

네트워크 관리 시스템에서 그 외에 활동하는 요소로는 관리에이전트가 있다. 호

스트, 브리지, 라우터 그리고 허브 같은 주요한 플랫폼은 SNMP 장치를 갖추고 있

기 때문에 관리지국이 이를 관리할 수 있다. 관리에이전트는 관리지국의 정보요청

에 응답하고, 동작요청에도 반응하고, 그리고 비동기적으로 관리지국이 요청하지

않았지만 중요한 정보를 자발적으로 관리지국에 제공한다.

네트워크의 자원을 관리하기 위해, 각 자원을 하나의 객체(object)로 표현한다.

570

Network SecurityEssentials 네트워크 관리 보안, 법과 윤리PART04

3) 서로 근접한 위치 또는 같은 위치에 있는 복수의 입출력 장치나 단말장치 등을 하나의 집단(cluster)으로

집중 제어하여, 이들 장치 상호 간에 통신할 수 있게 하고 단일통신채널을 공유하여 주 컴퓨터와 통신할

수 있게 하는 중간 제어장치. — 역자 주

한 객체는 근본적으로 관리되는 에이전트에 한 한 관점을 표현하는 데이터 변수

인데 이런 객체의 집합을 관리정보베이스라고 한다. MIB는 관리국이 에이전트에 접

근하는 접근점 집합체 역할을 한다. 이 객체는 특정 시스템의 클래스 전반에 걸쳐

표준화되어 있다(예를 들면 모든 브리지는 동일한 관리 객체를 지원한다). 관리지

국은 MIB 객체 값을 검색하여 모니터링 기능을 수행한다. 관리지국은 에이전트

동작을 유발시킬 수 있거나 특정 객체 값을 수정하여 에이전트 설정을 조정할 수

있다.

관리지국과 에이전트는 네트워크 관리 프로토콜에 의해 연결되어 있다. TCP/IP

네트워크 관리를 위해 사용하는 프로토콜은 SNMP이다. 이 프로토콜은 다음 주요

기능을 가지고 있다.

●Get: 관리지국이 에이전트 객체 값을 검색할 수 있게 한다.

●Set: 관리지국이 에이전트 객체 값을 설정할 수 있게 한다.

●Notify: 에이전트가 중요한 사건을 관리지국에 통지할 수 있게 한다.

네트워크 관리 프로토콜 구조

1988년 SNMP에 한 명세를 발표하 고 이것은 순식간에 주도적인 네트워크 관

리 표준이 되었다. 많은 벤더가 SNMP를 기반으로 한 독자적이고 독립된 네트워

크 관리 워크스테이션을 내놓았고, 브리지, 라우터, 워크스테이션 그리고 개인 컴

퓨터를 생산하는 벤더는 SNMP 관리지국이 그들의 제품을 관리할 수 있는 SNMP

에이전트 패키지를 출시하 다.

이름에서 알 수 있듯이, SNMP는 단순한 네트워크 관리 도구이다. 이것은 제한

적이고 쉽게 구현되는 스칼라 변수와 2-차원 표로 구성된 관리 정보 데이터베이스

(MIB)를 정의한다. 그리고 관리자가 MIB 변수를 가져오거나 설정할 수 있도록 하

고 에이전트가 트랩(trap)이라는 자발적 통지를 할 수 있도록 하는 일렬로 늘어선

(streamlined) 프로토콜을 정의한다. 이처럼 단순성이 SNMP의 강점이다.

SNMP는 쉽게 구현할 수 있고 프로세서나 네트워크 자원을 별로 많이 차지하지

않는다. 또한 프로토콜과 MIB 구조는 아주 단순해서 관리지국과 다양한 벤더가

제공한 에이전트 소프트웨어 사이의 상호 동작을 구현하는 데 별로 어려움이 없다.

3가지 기본 명세는 다음과 같다.

571

12CHAPTER네트워크 관리 보안

●TCP/IP-기반 네트워크에 한 관리 정보의 구조와 식별(RFC 1155): MIB 안에

포함되는 관리 객체가 어떻게 정의되는지를 설명한다.

●TCP/IP-기반 인터넷에 한 네트워크 관리를 위한 관리 정보: MIB-II(RFC 1213):

MIB 안에 포함되는 관리 객체를 설명한다.

●SNMP(RFC 1157): 이 객체를 관리하는 데 사용하는 프로토콜을 정의한다.

SNMP를 설계할 때 TCP/IP 프로토콜 중의 하나인 응용-계층 프로토콜이 되도

록 설계했다. UDP 위에서 작동하도록 설계를 했고 그 내용을 RFC 768에 정의하

다. 개별 관리지국에 해서 관리자 프로세스는 관리지국에 있는 중앙 MIB에

접근을 제어하고 네트워크 관리자에게 인터페이스를 제공한다. 관리자 프로세스

는 UDP, IP, 네트워크-종속된 다른 프로토콜(예를 들면 Ethernet, FDDI, X.25)

위에서 구현되는 SNMP를 이용해서 네트워크를 관리한다.

각 에이전트는 또한 SNMP, UDP 그리고 IP를 구현해야만 한다. 추가로 SNMP

메시지를 번역하고 에이전트의 MIB를 제어하는 에이전트 프로세스가 있다. FTP

같은 다른 응용을 지원하는 에이전트 장치를 위해서 UDP뿐만 아니라 TCP도 필요

하다.

그림 12.1은 SNMP의 프로토콜 환경을 나타내고 있다. 관리지국은 관리 응용 프

572


[그림 12.1]

SNMP 역할

UDP

Get

Req

uest

Get

Nex

tReq

uest

SetR

eque

st

Get

Res

pons

e

Tra

p

Get

Req

uest

Get

Nex

tReq

uest

SetR

eque

st

Get

Res

pons

e

Tra

p

UDP

SNMP 관리자 SNMP 메시지

응용프로그램이

객체를�관리

SNMP 에이전트

IP IP

네트워크�종속�프로토콜� 네트워크�종속�프로토콜�

SNMP�관리지국

관리�응용프로그램

네트워크나�인터넷

SNMP�에이전트

관리된�자원

SNMP 관리된�객체

로그램을 위해 3가지 유형의 SNMP 메시지를 보낸다. 이 세 메시지는 GetRequest,

GetNextRequest와 SetRequest이다. 처음 두 개는 get 함수의 변형된 두 가지

형태이다. 이 세 메시지 모두는 에이전트가 GetResponse 메시지의 형태로 응답

하는 것을 통해 확인된다. 이 메시지는 관리 응용 프로그램까지 전달된다. 추가로

에이전트는 MIB와 자신이 관리하는 자원에 향을 끼치는 사건에 한 응답으로

트랩 메시지를 관리국에 보낼 수 있다.

SNMP는 비연결형 프로토콜인 UDP에 의존하기 때문에 SNMP 자체도 비연결

형이다. 관리지국과 에이전트 사이에는 어떠한 지속적인 연결도 유지하고 있지 않

는다. 신에 각 교환은 관리지국과 에이전트 사이의 개별적인 트랜잭션을 통해

이뤄진다.

프록시

SNMPv1에서는 관리지국뿐만 아니라 모든 에이전트도 UDP와 IP를 지원해야

만 한다. 그래서 TCP/IP 프로토콜의 어떠한 부분도 지원하지 않는 브리지와 모뎀

같은 장치는 직접 관리할 수 없고 관리에서 배제시켜야만 한다. 더구나, 자신의 응

용 프로그램을 지원하기 위해 TCP/IP를 구현하는 여러 가지 소규모 시스템(개인

용 컴퓨터, 워크스테이션, 프로그래머블 컨트롤러)이 있을 수 있다. 그러나 이런

소규모 시스템에게 SNMP, 에이전트 로직4), 그리고 MIB 유지∙관리 같은 추가적

인 부담을 주는 것은 바람직하지 않다.

그래서 SNMP를 구현하지 못하는 장치를 수용하기 위해 프록시(proxy) 개념이

개발되었다. 이 구조에서 한 SNMP 에이전트는 한 개 혹은 여러 개의 다른 장치를

위해 프록시5)로 행동한다. 즉, 그 SNMP 에이전트는 프록시되는 장치를 위해 에

이전트처럼 행동한다.

그림 12.2는 자주 쓰이는 프로토콜 구조의 유형을 나타내고 있다. 관리지국은

프록시 에이전트로 한 장치에 한 질의를 보낸다. 프록시 에이전트는 각 질의를

장치가 사용하는 관리 프로토콜로 전한다. 에이전트가 질의에 한 응답을 받으

573


4) 에이전트가 관리지국과 정보교환을 위해 가지고 있는 알고리즘이나 프로그램을 의미한다. — 역자 주

5) 원래 인터넷 보안을 위해 침입차단시스템(firewall)에서 사용되었으나 웹 브라우저에서 프록시 서버를

접근하는 방법으로 사용되는 것. 웹 브라우저에서 프록시를 지정하면 웹 클라이언트에서 요청되는 URL

이 해당 서버에 연결되어 요청되는 것이 아니라 프록시 서버에 요청한다. 프록시 요청을 받은 프록시 서

버는 URL의 해당 서버와 접속하여 요청을 보내고 클라이언트 신 응답을 받아 이를 클라이언트에 넘

겨주는 역할을 한다. — 역자 주

574


[그림

12.2]

프록시

구성

SNM

P

관리�프

로세스

관리�프

로세스

프록시된�장

치관리지국

매핑�함

수

프록시�에

이전트

프록시된

장치가�사

용하는

프로토콜�아

키텍처

프록시된

장치가�사

용하는

프로토콜�아

키텍처

UD

P

IP

SNM

P

에이전트�프

로세스

UD

P

IP

네트워크-종속

프로토콜�

네트워크-종속

프로토콜�

네트워크-종속

프로토콜�

네트워크-종속

프로토콜�

면, 에이전트는 그 응답을 관리지국으로 전달해준다. 비슷하게, 만약 그 장치로부

터 어떤 사건 통지가 프록시로 전송되면, 프록시는 트랩 메시지의 형태로 그것을

관리지국에 보낸다.

SNMPv2에서는 TCP/IP 프로토콜뿐만 아니라 다른 프로토콜도 사용할 수 있

다. 특히 SNMPv2를 설계할 때 OSI 프로토콜 위에서 작동하도록 만들었다. 그래

서 SNMPv2는 훨씬 다양하게 구성된 네트워크를 관리하는 데 사용할 수 있다. 프

록시와 연관지어 말하면 SNMPv2를 구현하지 않는 모든 장치는 프록시 방법을 이

용해서만 관리할 수 있다. 여기에는 SNMPv1 장치까지도 해당된다. 즉, 만일 한

장치가 SNMPv1에서만 동작하는 에이전트 소프트웨어를 구현한다면, 관리자가

이 장치에 접근하는 방법은 SNMPv2 에이전트를 구현하는 프록시 장치와

SNMPv1 관리자 소프트웨어를 이용하는 방법뿐이다.

앞 절에서 설명한 경우를 SNMPv2에서는 외래(foreign) 프록시 관계라고 한다.

거기에 더해서, SNMPv2는 토착(native) 프록시 관계도 지원하는데 토착 프록시

란 프록시되는 장치가 SNMPv2를 지원하는 경우를 말한다. 이 경우에 SNMPv2

관리자는 에이전트로 행동하는 SNMPv2 노드와 통신한다. 이 노드는 이때 관리자

로 행동하여 SNMPv2 에이전트로 행동하는 프록시된 장치에 접근한다. 이런 간접

적인 형태를 지원하기 때문에 사용자는 계층형 분산 네트워크 관리 시스템을 구성

할 수 있다. 이에 해서는 뒤에서 다시 설명하기로 한다.

SNMPv2

SNMP의 강점은 단순성이다. SNMP는 기본적인 네트워크 관리 도구를 구현하기

쉽고 구성하기 쉬운 패키지 형태로 제공한다. 그러나 계속 늘어나는 작업 처리를

감당하려고 계속 확장되는 네트워크를 관리하기 위해 사용자는 점점 더 SNMP에

의존하게 되었다. 의존도가 높아짐에 따라서 SNMP의 부족한 면이 하나둘씩 드러

나게 되었다. 이 부족한 점은 다음 3가지로 분류할 수 있다.

●분산 네트워크 관리에 한 지원의 부족함

●기능적 결함

●보안 결함

575


앞의 두 부류의 결점에 해서는 1993년에 발행된 SNMPv2에서 논의하 고,

1996년 수정된 버전이 발행되었다(현재는 RFC 1901, 1904에서 1908, 2578과

2579까지). SNMPv2는 급속한 지지를 얻게 되었고 표준이 나온 뒤 수개월이 채

안 되어서 많은 벤더가 제품을 내놓았다. 보안 결함에 해서는 SNMPv3에서 중

점적으로 다루고 있다.

이 부절의 나머지 부분에서 SNMPv2에 의해 제공된 새 기능을 간단히 요약한

다. SNMPv2와 SNMPv3의 보안 기능은 12.2절과 12.3절에서 각각 자세하게 검

토할 것이다.

분산 네트워크 관리

전통적인 중앙집중식 네트워크 관리 구조에서는 구성체에 속한 한 호스트가 네트

워크 관리지국의 역할을 맡는다. 지원 역할을 위해서 한두 개의 다른 관리지국을

둘 수도 있다. 네트워크의 다른 나머지 장치는 에이전트 소프트웨어와 MIB를 포

함한다. 그래서 관리지국은 에이전트를 모니터링하고 제어할 수 있다. 네트워크의

크기가 커지고 트래픽 양이 증가하면서 이런 중앙집중식 시스템은 제 로 기능을

발휘하지 못하게 되었다. 관리지국에 너무 큰 부하가 집중되었고 트래픽이 너무

많아지게 되었다. 이유는 모든 에이전트가 보내는 트래픽이 전체 네트워크를 통과

해서 중앙 관리지국으로 가야만 하기 때문에 발생되는 것이다. 이런 환경에서는

탈중심적인 분산 방법이 더 효율적이다(예를 들면 그림 12.3). 분산 네트워크 관리

시스템에서는 관리 서버라고 알려진 다수의 상위 관리지국이 있을 수 있다. 이런

각각의 서버는 에이전트 전체 중 일부를 직접 관리할 수도 있다. 그러나 다수의 에

이전트를 위해서 관리 서버는 중간 관리자에게 책임을 부여한다. 중간 관리자는

자신의 책임하에 있는 에이전트를 모니터링하고 제어하는 관리자 역할을 한다. 중

간관리자는 또한 상위 관리 서버에 의해 제어되고 서버에게 정보를 제공하는 에이

전트 역할도 한다. 이런 유형의 구조를 통해 처리 부담을 나누고 총 네트워크 트래

픽 양도 줄일 수 있다.

SNMPv2는 고도로 중앙 집중화된 네트워크 관리 방법과 분산관리방법 모두를

지원한다. 후자의 경우에 몇 개의 시스템은 관리자 역할과 에이전트 역할 두 가지

를 모두 수행한다. 에이전트 역할로 보면 이런 시스템은 상위 관리 시스템으로부

터 명령을 받는다. 이런 명령 중의 몇 가지는 에이전트에 속한 지역 MIB에 관련된

것이다. 이 경우 프록시 에이전트는 원격 에이전트에 있는 정보에 접근할 때는 관

576


577


[그림

12.3]

분산

네트워크

관리

구성의

예

이더넷

이더넷

스위치

이더넷

인터넷

이더넷

라우터

에이전트

라우터

에이전트

라우터

에이전트

라우터

에이전트

라우터

에이전트

라우터

에이전트

에이전트

에이전트

에이전트

에이전트

에이전트

에이전트

에이전트

에이전트

에이전트

에이전트

에이전트

에이전트

중간�관

리자

(관리자/에

이전트)

중앙�사

이트

관리�서

버(관

리자)

리자 역할을 하고, 그 뒤에 에이전트 역할을 하여 그 정보를 상위 관리자에게 전

한다.

기능적 강화

표 12.1은 SNMPv2에 기능적으로 보강된 것을 보여주고 있다. 두 프로토콜은 프

로토콜 데이터 단위(PDU: protocol data unit)로 통신되는 명령 집합으로 정의된

다. SNMPv1의 경우에는 5개의 명령이 있다. 관리자는 MIB에 있는 객체 값을 검

색하기 위해 Get 명령을 에이전트에 보낸다. GetNext 명령은 MIB 안의 객체가

트리 구조로 정리되어 있다는 특성을 활용한다. 한 객체가 GetNext 명령 안에서

불렸다면, 에이전트는 트리에서 다음(next) 객체를 찾고 그 값을 반환한다.

GetNext는 매우 유용하게 사용된다. 해당 에이전트가 지원하는 객체 집합이 어떤

것인지를 GetNext가 정확히 알지 못할 때, GetNext를 이용하면 관리자는 에이전

트에 있는 트리를 훑어 내려갈(“walk”)6) 수 있다. Set 명령을 이용해서 관리자는

에이전트에 있는 값을 갱신할 수 있다. 이 명령은 또한 테이블의 행(rows)을 생성

하고 삭제할 수도 있다. 에이전트는 GetResponse 명령을 사용하여 관리자 명령

에 응답한다. 마지막으로 트랩(Trap) 명령은 에이전트가 관리자의 관리 요청을 기

다리지 않고 자발적으로 관리자에게 정보를 보낼 때 사용한다. 예를 들면, 링크가

고장났거나 트래픽 양이 한계를 넘어섰을 경우에 에이전트가 트랩을 보내도록 에

이전트를 구성할 수 있다.

SNMPv2는 SNMPv1에 있는 모든 명령을 다 갖고 있으며 추가적으로 두 개의

새로운 명령을 더 갖고 있다. 이들 중 가장 중요한 것은 정보(Information) 명령이

다. 이 명령은 한 관리지국이 다른 관리지국으로 보낼 때 사용하며, 트랩 명령처럼

송신 측의 상태나 사건에 한 정보를 포함하고 있다. 이 명령의 장점은 규모 네

트워크에서 관리책임을 나누기 위해 여러 관리자끼리 협조체제를 구성하는 데 사

용할 수 있다는 것이다.

다른 새 명령은 GetBulk인데 이것은 관리자가 한 번에 커다란 블록 데이터를

가져올 수 있게 한다. 특히 GetBulk 명령은 한 번의 명령으로 테이블 전체를 전송

할 목적으로 설계되었다.

또 다른 차이점은 SNMPv1의 경우에 Get 명령이 아주 제한적이지만 SNMPv2

578


6) 관리자가 변수값을 읽기 위해 테이블의 객체 ID를 정의하고 이를 이용하여 다음 항목 값을 얻을 수 있다.

이런 방법으로 계속하게 되는데 이를 은유적으로“walk”라는 말로 표현했다. — 역자 주

에서는 그렇지 않다는 것이다. SNMPv1의 Get 명령으로 한 목록을 가져오려 한다

고 하자. 이때 요청된 값을 가진 객체로 된 그 목록 안에 이 에이전트가 가지고 있

지 않은 객체가 한 개라도 있으면, 해당 전체 명령은 에이전트에 의해 거부된다.

그러나 SNMPv2에서는 에이전트가 부분적인 결과를 반환한다. 그래서 제한적이

지 않은(융통성 있는) Get 명령으로 인해 관리자가 네트워크 성능을 더 효율적으

로 사용할 수 있다.

RFC 1157에 정의된 SNMPv1은 공동체 개념(concept of community)을 토 로

한 기본적인 보안기능만 제공한다. 이 기능으로 어느 정도의 보안 레벨을 제공할

수 있지만 다양한 공격에 노출될 수밖에 없다[CERT02, JIAN02].

공동체와 공동체 이름

다른 분산 응용처럼 네트워크 관리는 응용 프로토콜이 지원하는 많은 응용 개체와

상호교류를 통해 이뤄진다. SNMP 네트워크 관리의 경우에 응용 개체에 해당되는

579


<표 12.1>

SNMPv1과 SNMPv2프로토콜 데이터 단위(PDU) 비교

SNMPv1 PDU SNMPv2 PDU 방향(Direction) 설명

GetRequest GetRequest 관리자에서 에이전트로 각 객체 목록 값 요청

GetNextRequest GetNextRequest 관리자에서 에이전트로 각 객체 목록의 다음 값 요청

--- GetBulkRequest 관리자에서 에이전트로 다중 값 요청

SetRequest SetRequest 관리자에서 에이전트로 각 객체 목록 값 설정

--- InformRequest 관리자에서 에이전트로 요구되지 않은 정보 전송

GetResponse Response

에이전트에서 관리자로

혹은

관리자에서 에이전트로

(SNMPv2)

관리자 요청에 한 응답

Trap SNMPv2-Trap 에이전트에서 관리자로 요구되지 않은 정보 전송

12.2 SNMPv1 공동체 서비스

것으로는 SNMP를 사용하는 관리 응용 프로그램과 에이전트 응용 프로그램이

있다.

SNMP 네트워크 관리는 다른 모든 분산 응용이 갖고 있지 못한 여러 특징을 갖

고 있다. 이 응용 프로그램은 한 관리자와 에이전트 한 집단을 응시키는 일- -

다수의 관계이다. 관리자는 에이전트에 속한 객체를 가져오거나 설정할 수 있고

에이전트로부터 트랩을 수신할 수도 있다. 그래서 운용적인 면이나 제어 관점에서

보면 관리자는 많은 수의 에이전트를“관리(manage)”한다고 볼 수 있다. 다수의

관리자가 있을 수 있고, 각각의 관리자는 구성체 안의 에이전트 전체를 관리할 수

도 있고 부분집합인 일부분만 관리할 수도 있다. 이 집합은 서로 겹칠 수도 있다.

또한 SNMP 네트워크 관리를 다른 시각에서 볼 수도 있다. 한 에이전트에 다수

의 관리자를 응시키는 일- -다수의 관계로 보는 것이다. 각 에이전트는 자신

의 지역 MIB를 관리하고 이것을 다수의 관리자가 사용할 수 있도록 제어할 수 있

어야만 한다. 이런 제어를 3가지 관점에서 볼 수 있다.

●인증 서비스(Authentication service): 에이전트는 적법한 관리자만 MIB에 접근

하도록 제한하기를 원한다.

●접근 정책(Access policy): 관리자마다 다른 범위의 접근 권한을 가지고 에이전

트에 접근하기를 원한다.

●프록시 서비스(Proxy service): 에이전트는 다른 에이전트를 위해 프록시 역할을

한다. 그래서 다른 에이전트를 위해서 프록시 시스템에 인증 서비스와 접근 정책

을 구현한다.

이 3가지 관점은 모두 보안과 관련된 것이다. 다수의 관리 개체가 있어서 네트

워크 구성요소에 한 책임을 나누어가지고 있는 환경이라면, 에이전트는 부적절

하거나 원치 않는 접근으로부터 자신과 자신의 MIB를 보호할 필요가 있다. RFC

1157에 정의되었듯이 SNMP는 보안에 해서는 초보적이고 제한적인 기능만 제

공한다. 말하자면 이것은 공동체 개념이다.

하나의 SNMP 공동체(community)란 한 에이전트와 한 무리의 SNMP 관리자로

이루어진 집합 사이의 관계를 말하는데, 이 관계는 인증과 접근제어와 프록시 특

성을 포함하고 있어야 한다. 공동체 개념은 에이전트에 국한되어 정의되는 지역적

인 것이다. 에이전트는 인증, 접근제어, 프록시 특성을 원하는 로 적절하게 조합

하여 한 공동체를 구성한다. 각 공동체는 고유의 공동체 이름을 갖고(해당 에이전

580


트 안에서만 구별되는) 이 공동체에 속한 관리자에게 이 이름을 제공한다. 정보를

얻고(get) 설정(set)하는 동작에서 이 공동체이름을 꼭 이용해야만 한다. 에이전트

는 다수의 공동체를 구성할 수 있다. 이때 어떤 관리자는 한 개 이상의 공동체에

한 관리권한을 가질 수도 있다.

공동체는 에이전트에서 지역적으로 정의되는 것이기 때문에 에이전트가 다를

경우 그 안에서 유일하기만 하다면 다른 에이전트에서 사용하고 있는 이름이라도

사용할 수 있다. 이름을 식별하는 것은 의미가 없고 정의된 공동체 사이의 어떠한

유사성을 나타내지도 않는다. 그래서 관리자는 공동체 이름(community name)이

나 관리자가 접근하고자 하는 에이전트와 연관된 공동체 이름에 한 정보를 지속

적으로 알아야만 한다.

인증 서비스

한 SNMPv1 메시지를 수신했을 때 이것이 정말로 보냈다고 주장하는 곳에서 송신

됐다는 사실을 수신자에게 확신시켜 주는 것이 SNMPv1 인증 서비스 목적이다.

SNMPv1은 오직 간단한 인증 구조만을 제공한다. 관리자가 에이전트에게 보내는

각 메시지(get이나 put 요청)에는 공동체 이름을 포함시킨다. 이 이름은 패스워드

기능을 하고 송신하는 사람이 패스워드를 알고 있다면 그 메시지는 인증된 것으로

간주된다.

이런 제한적으로 사용되는 인증으로 인해 많은 네트워크 관리자는 네트워크 모

니터링을 제외한 get이나 trap 같은 다른 명령을 허용하려고 하지 않는 경향이 있

다. set 명령을 이용하는 네트워크 제어는 분명 더 민감한 분야이다. 초기적 패스

워드-검사 장치로 공동체이름을 사용하며 이 공동체 이름을 가지고 인증을 시작

할 수 있다. 인증 절차는 암호화/복호화를 이용하여 좀 더 안전한 인증기능을 수행

하게 된다. 이 내용을 RFC 1157에서는 다루지 않는다.

접근 정책

공동체를 정의하게 되면 에이전트는 선택된 관리자에게만 자신의 MIB에 접근할

수 있도록 허용할 수 있다. 한 개 이상의 공동체를 사용하여, 에이전트는 여러 관

리자에게 다른 종류의 MIB 접근권한을 제공할 수 있다. 접근제어 관점은 두 가지

가 있는데 다음과 같다.

581


●SNMP MIB 뷰(view): 이것은 객체를 원소로 가지는 MIB의 한 부분집합을 말한

다. 각 공동체마다 다른 MIB 뷰(view)를 정의할 수 있다. 한 뷰 안의 객체 집합

이 꼭 한 개의 MIB 서브-트리에만 속할 필요는 없다.

●SNMP 접근 모드: 이것은 두 모드로 된 집합 { READ-ONLY, READ-WRITE }

의 둘 중의 한 원소를 말한다. 접근 모드는 각 공동체마다 따로 정의된다.

한 MIB 뷰와 한 접근모드로 된 조합을 SNMP 공동체 프로파일(SNMP

community profile)이라고 한다. 그래서 공동체 프로파일은 에이전트에 속한

MIB의 정의된 한 부분집합과 이 객체에 한 접근모드로 구성된다. SNMP 접근

모드는 MIB 뷰 안의 모든 객체에 동일하게 적용된다. 그래서 만일 접근모드로

READ-ONLY가 선택되었다면, 뷰에 있는 모든 객체에 이 모드가 적용되고 관리

자가 이 뷰에 접근할 때 읽기만 허가된다.

공동체 프로파일은 에이전트에 의해 정의된 각 공동체와 연관성이 있다. SNMP

공동체와 SNMP 공동체 프로파일로 된 조합을 SNMP 접근 정책(SNMP access

policy)이라고 한다. 그림 12.4는 지금까지 설명한 여러 개념을 그림으로 나타낸

것이다.

프록시 서비스

공동체 개념은 프록시 서비스를 지원하는 데 매우 유용하다. 우리는 프록시가 다

른 장치를 신하는 SNMP 에이전트라는 것을 알고 있다. 전형적으로 다른 장치

라 하면 TCP/IP와 SNMP를 지원하지 않는다는 의미에서 외부장치를 말한다. 어

582


[그림 12.4]

SNMPv1 관리 개념

SNMP에이전트

SNMP관리자�집합

SNMP 공동체(공동체�이름)

SNMP공동체�프로파일

SNMPMIB�뷰

SNMP접근�모드

SNMP접근�정책

떤 경우에는 프록시되는 시스템이 SNMP 를 지원할지도 모르지만 프록시되는 장

치와 네트워크 관리 시스템 사이의 상호교환을 최소화하기 위해 프록시를 사용

한다.

프록시 시스템이 리 역할을 해주는 각 장치에 해, 프록시는 SNMP 접근 정

책을 유지한다. 그래서 프록시는 어떤 MIB 객체를 이용해야 프록시되는 시스템

(MIB 뷰)을 관리할 수 있는지와 그것에 한 접근모드를 알 수 있다.

1998년에 IETF SNMPv3 작업그룹은 현재 RFC 2570에서 2576까지에 해당되는

프로토콜 인터넷 표준을 발표하 다. 이 문서는 SNMPv1이나 SNMPv2 기능을

포함하는 전체적인 기능 안에 보안기능을 포함시키기 위한 프레임워크를 정의했

다. 거기에 더해서 이 문서는 네트워크 보안과 접근제어를 위한 기능을 정의하고

있다.

SNMPv3가 SNMPv1과 SNMPv2를 체하는 독립된 것이 아니라는 것을 알아

야 한다. SNMPv3는 SNMPv1나 SNMPv2(더 선호되는)와 병행해서 사용하는 보

안 기능을 정의한다. 추가로 RFC 2571은 모든 현재와 미래의 SNMP 버전에 적합

한 구조를 설명하고 있다. RFC 2575는 SNMPv3 핵심기능과는 독립적으로 작동

하도록 설계된 접근제어 기능에 해 설명하고 있다. 이 절에서는 SNMPv3를 넓

은 의미에서 살펴보고 RFC 2570부터 2576에 정의된 기능에 해 살펴보기로

한다.

그림 12.5는 형식측면에서 버전이 다른 SNMP의 관계를 나타내고 있다. 관리자

와 에이전트 사이에서는 SNMP 메시지 형태로 정보를 교환한다. 보안 관련 처리

는 메시지 레벨에서 해결한다. 예를 들면, SNMPv3는 메시지 헤더 필드를 사용하

는 사용자 보안 모델(USM: User Security Model)을 지정한다. SNMP 메시지 페

이로드는 SNMPv1이나 SNMPv2 프로토콜 데이터 단위(PDU: protocol data

unit)이다. PDU는 관리행위의 유형(예를 들면 관리되는 객체를 가져오거나 설정

한다)과 그 행위에 관계되는 변수이름 목록을 나타낸다.

RFC 2570부터 2576은 전체적인 구조와 특정 메시지 구조와 보안 기능에 해

583


12.3 SNMPv3

서는 설명하고 있지만 새로운 SNMP PDU 형식을 정의하지는 않는다. 그래서 새

구조에서 기존의 SNMPv1이나 SNMPv2 PDU 형식을 사용해야만 한다.

SNMPv3라고 알려진 구현은 RFC 2570부터 2576에 정의된 보안과 구조적 기능,

SNMPv2 문서에 정의된 PDU 형식으로 구성된다. 이것을 RFC 2570에 다음과 같

이 표현하 다. “SNMPv3는 보안과 관리 기능을 추가한 SNMPv2라고 생각할 수

있다.”

이 절의 나머지 부분은 다음과 같이 구성된다. 첫째, RFC 2571에 정의된 기초

적 SNMP 구조에 해서 간단한 소개를 한다. 다음에 기 성을 설명하고

SNMPv3 사용자 보안 모델(USM)에 의해 제공되는 인증 기능을 설명한다. 끝으

로, 접근제어와 뷰에 기초한 접근제어모델(VACM: view-based access control

model)에 해 논의한다.

SNMP 구조

RFC 2571에서 정의한 것처럼, SNMP 구조는 상호 작용하는 SNMP 개체의 분산

된 집단으로 구성된다. 각 개체는 SNMP 기능 일부를 수행하고, 에이전트 노드로

행동하거나 관리자 노드로 행동하거나 혹은 이 두개의 조합으로 행동하기도 한다.

각 SNMP 개체는 서비스제공을 위해 상호 작용하는 모듈 집단으로 구성된다. 이

상호작용은 추상적인 원시함수와 매개변수 집합으로 모델화될 수 있다.

584


[그림 12.5]

SNMP 프로토콜 구조SNMP PDU

SNMP PDU

SNMP PDU

SNMP PDU

V3-MH

UDP-H

UDP-HIP-H

V3-MH

V3-MH

PDU 처리(SNMPv1 or SNMPv2)

메시지�처리(SNMPv3 USM)

UDP

IP

IP-H =�IP�헤더UDP-H =�UDP�헤더V3-MH =�SNMPv3�메시지�헤더PDU=�프로토콜�데이터�단위

RFC 2571 구조는 SNMPv3를 위해 중요한 설계요구 사항을 반 하고 있다. 즉,

다음을 만족하는 모듈화된 구조를 설계한다. (1) 광범위하게 운용되는 환경에서 구

현되어야 한다. 이런 환경 중 어떤 것은 최소의 저비용 기능을 필요로 하고, 어떤

것은 규모 네트워크를 관리할 목적으로 추가적인 기능을 지원할 수도 있다. (2)

모든 면에서 의견 일치가 완벽히 이루어지지 않았다 하더라도 구조의 일부를 표준

화 과정으로 진행시킬 수 있어야 한다. (3) 체 보안 모델을 수용해야 한다.

SNMP 개체

각 SNMP 개체는 단 하나의 SNMP 엔진을 포함한다. SNMP 엔진은 메시지의 송

수신, 메시지의 인증과 암호화/복호화, 관리되는 객체에 한 접근제어를 위한 기

능을 구현한다. SNMP 엔진에 맞게 구성되는 하나 혹은 여러 응용에 이 기능을 서

비스로 제공하여 SNMP 개체를 형성한다.

SNMP 엔진도 개별적인 모듈 집단으로 정의되고 엔진이 지원하는 응용도 개별

적인 모듈 집단으로 정의된다. 이 구조는 여러 가지 장점을 갖고 있다. 첫째,

SNMP 개체 역할이 그 개체 안에서 구현되는 모듈에 의해 결정된다. 어떤 모듈 모

음은 SNMP 에이전트를 위해 필요하고, 어떤 다른 모듈 모음은 SNMP 관리자를

위해서 필요하다. 둘째, 명세 모듈 구조는 자체적 구조를 이용해서 각 모듈의 다른

버전을 정의할 수 있게 한다. 이로 인해 다음이 가능하다. (1) 전체적으로 새로운

버전의 표준안(예를 들면 SNMPv4)을 만들 필요 없이 SNMP의 특정 부분에 한

체기능이나 강화된 기능을 정의할 수 있다. 그리고 (2) 다른 SNMP 버전과 공존

할 수 있도록 하고 또 어떻게 변화해 갈 것인지를 명확하게 구체화할 수 있다(RFC

2576).

각 모듈의 역할과 다른 모듈과의 관계를 더 잘 이해하기 위해서 이 모듈이 전통

적인 SNMP 관리자와 에이전트 안에서 어떻게 사용되었는지를 살펴보자. 여기서

순수한(pure)이란 말과 동일한 의미로 사용되는 용어 전통적(traditional)이란 말

을 사용한 이유는 다음 사실을 강조하기 위해서이다. 주어진 구현은 순수한 관리

자나 순수한 에이전트일 필요는 없지만 개체로 하여금 관리업무와 에이전트 업무

모두를 수행하도록 하는 모듈을 가질 수도 있다.

그림 12.6은 RFC 2571의 그림을 근거로 한 전통적 SNMP 관리자(traditional

SNMP manager)의 블록 다이어그램이다. 전통적 SNMP 관리자는 SNMP 에이

전트와 명령(get, set)을 보내고 트랩(trap) 메시지를 받으면서 상호작용한다. 관리

585


자는 다른 관리자에게 경고를 주고받는 과정으로 정보 요청 PDU(Information

Request PDU)를 보내고, 정보요청의 수신을 확인하는 정보응답 PDU를 받는 상

호협조를 한다. SNMPv3 용어로 말해서 전통적 SNMP 관리자는 3부류의 응용을

포함한다. 먼저, 명령 생성자 응용(Command Generator Application)은 원격 에

이전트에 속한 데이터를 모니터링하고 다룬다. 이 응용은 Get, GetNext,

GetBulk 그리고 Set을 포함하는 SNMPv1과 SNMPv2 PDU를 사용한다. 통지 발

신자 응용(Notification Originator Application)은 비동기 메시지 전달을 개시한

다. 전통적인 관리자의 경우 정보요청(InformRequest) PDU를 이 응용에서 사용

한다. 통지 수신자 응용(Notification Receiver Application)은 수신되는 비동기

메시지를 처리한다. 이 메시지에는 정보요청, SNMPv2-트랩 그리고 SNMPv1 트

랩 PDU가 포함된다. 수신되는 정보요청 PDU의 경우에는 통지수신응용이 응답

(Response) PDU로 응답할 것이다.

지금까지 설명한 모든 응용은 SNMP 엔진이 이 개체를 위해 제공하는 서비스를

586


[그림 12.6]

전통적 SNMP 관리자

SNMP 개체

SNMP 응용

SNMP 엔진

UDP IPX Other

v1MP

v2cMP

v3MP

otherMP

명령생성응용자

통신발신자응용

통신수신자응용

PDU 전달자

전달자

메시지�전달자

메시지�처리서브시스템

보안서브시스템

사용자-기반보안�모델

기타보안�모델

네트워크

전송�매핑(예:�RFC 1906)

이용한다. SNMP 엔진은 크게 다음 두 가지 기능을 수행한다.

●SNMP 응용으로부터 나가는 PDU를 받는다. 인증코드와 암호화를 포함하는 필

요한 처리를 하고 그 PDU를 전송하기 위해 캡슐화된 메시지로 만든다.

●전송층에서 들어오는 SNMP 메시지를 받는다. 인증과 복호화를 포함하는 필요

한 처리를 하고 메시지에서 PDU를 추출해내고 해당되는 SNMP 응용에 이것을

전달한다.

전통적인 관리자의 경우 SNMP 엔진은 전달자(Dispatcher), 메시지 처리 서브

시스템(Message Processing Subsystem)과 보안 서브시스템(Security

Subsystem)을 포함한다. 전달자는 단순한 트래픽 관리자이다. 나가는 PDU에

해 전달자는 응용으로부터 PDU를 받아서 다음 기능을 수행한다. 각 PDU에 해

서 요구되는 메시지 처리유형(예를 들면 SNMPv1, SNMPv2c(SNMPv1 공동체 기

능을 갖는 SNMPv2), SNMPv3)을 결정하고 메시지 처리 서브시스템 안의 메시지

처리 모듈로 그 PDU를 전달한다. 이어서 메시지처리서브시스템은 그 PDU와 적

절한 메시지 헤더를 포함하는 메시지를 반환한다. 전달자는 전송하기 위해 이 메

시지를 전송층으로 전달한다.

메시지 처리 서브시스템은 전달자로부터 나가는 PDU를 받고 전송하기 위해 적

절한 메시지 헤더 안에 캡슐화를 하고 이것을 다시 전달자에게 반환한다. 메시지

처리 서브시스템은 또한 전달자로부터 메시지를 받고 각 메시지 헤더를 처리하고

동봉된 PDU를 전달자에게 반환한다. 메시지 처리 서브시스템의 구현은 단일

SNMP 버전(SNMPv1, SNMPv2c, SNMPv3)에 응하는 단일 메시지 유형을 지

원할 수도 있고, 모듈 각각이 다른 SNMP 버전을 지원하는 여러 개의 모듈을 포함

할 수도 있다.

보안 서브시스템은 인증과 암호화 기능을 수행한다. 각각의 나가는 메시지는 메

시지 처리 서브시스템으로부터 보안 서브시스템으로 전달된다. 요구되는 서비스

에 따라 보안서브시스템은 동봉된 PDU를 암호화하고 때로는 메시지 헤더에 포함

된 몇 개의 필드까지 암호화하기도 한다. 그리고 암호 서브시스템은 인증 코드를

생성하고 메시지 헤더에 이를 삽입하기도 한다. 처리된 메시지는 메시지 처리 서

브시스템으로 반환한다. 비슷한 방법으로 들어오는 각 메시지는 메시지 처리 서브

시스템으로부터 보안 서브시스템으로 전달된다. 만일 필요하다면 보안 서브시스

템은 인증 코드를 검사하고 복호화를 수행한다. 그리고 처리된 메시지를 메시지

587


처리 서브시스템으로 전달한다. 보안 서브시스템 구현은 한 개 혹은 여러 개의 다

른 보안 모듈을 지원할 수 있다. 현재까지 유일하게 정의된 보안 모듈은 RFC

2574에 있는 SNMPv3에 한 사용자-기반 보안 모델(USM: User-Based

Security Model)이다.

그림 12.7은 RFC 2571을 기초로 해서 만든 전통적 SNMP 에이전트(traditional

SNMP agent)의 블록 다이어그램이다. 전통적 에이전트는 3가지 유형의 응용을

포함할 수 있다. 명령 응답 응용(Command Respond Application)은 관리 데이터

에 한 접속을 제공한다. 이 응용은 들어오는 요청에 관리되는 객체를 가져오거

나 설정하고 응답(Response) PDU를 보내어 반응한다. 통지 발신자 응용

(Notification Originator Application)은 비동기 메시지를 개시한다. 전통적인

에이전트의 경우 SNMPv2-트랩이나 SNMPv1 트랩 PDU를 이 응용에 사용한다.

프록시 전달 응용(Proxy Forwarder Application)은 개체 사이의 메시지를 전달

한다.

전통적 에이전트를 위한 SNMP 엔진은 전통적 관리자를 위한 SNMP 엔진에 있

는 모든 요소를 다 포함하고 있고 추가로 접근 제어 서브시스템(Access Control

588


[그림 12.7]

전통적 SNMP 에이전트

SNMP 개체

SNMP 응용

SNMP엔진

UDP IPX Other

v1MP

v2cMP

v3MP

otherMP

통신발신자응용

명령응답자응용

프록시전달자응용

전달자

메시지�처리서브시스템

보안서브시스템

사용자-기반보안�모델

기타보안�모델

접근�제어서브시스템

뷰-기반접근�제어�모델

기타접근�제어�모델

PDU 전달자

MIB 편성

메시지�전달자

전송�매핑(예:�RFC 1906)

Subsystem)을 가지고 있다. 이 서브시스템은 관리 객체를 읽고 설정하기 위해

MIB에 한 접근제어허가 서비스를 제공한다. 이 서비스는 PDU의 내용을 기초로

해서 수행된다. 보안서브시스템 구현은 한 개 혹은 여러 개의 다른 접근 제어 모델

을 지원할 수도 있다. 지금까지 유일하게 정의된 보안 모델은 RFC 2575에 정의된

뷰-기반 접근제어모델(VACM: View-Based Access Control Model) 하나뿐이다.

보안관련 기능은 두 개의 독립된 서브시스템으로 구성되었다는 것에 주목하기

바란다. 이 두 가지 서브시스템은 보안과 접근제어인데 이 두 개의 서브시스템은

아주 서로 다른 기능을 수행한다. 그래서 이 두 분야의 표준화를 따로따로 할 수

있고 그런 면에서 이 모듈화된 설계는 매우 훌륭하다고 할 수 있다. 보안 서브시스

템은 기 성과 인증을 처리하고 SNMP 메시지 위에서 작동한다. 접근제어 서브시

스템은 관리 정보에 한 접근허가를 다루고 SNMP PDU 위에서 작동한다.

용어

표 12.2에서는 RFC 2571에 소개된 일부 용어를 간단히 정의하 다. 각각의

SNMP 개체와 연관되는 것은 유일한 snmpEngineID이다. 접근제어를 위해, 각

SNMP 개체는 많은 관리정보의 컨텍스트(context)를 관리하도록 되어 있고 관리

할 정보 컨텍스트는 각각 해당 개체 안에서는 유일한 contextName을 가지고 있

다. 한 개체 안에는 단 한 개의 컨텍스트 관리자가 있다는 것을 강조하기 위해 각

개체는 그 컨텍스트와 연관된 유일한 contextEngineID를 가지고 있다. 이 개체

안에서 컨텍스트 엔진과 SNMP 엔진 사이에는 일- -일 응관계가 있기 때문에

contextEngineID와 snmpEngineID는 같은 값을 가지고 있다. 접근제어는 접근

하고자 하는 특정 컨텍스트와 접근요청을 하는 사용자 신원에 의해 통제된다.여기

서 사용되는 사용자 신원은 주체로 표현되는 데 주체가 될 수 있는 상으로는 개

인이나 응용, 혹은 개인의 집단이나 응용 집단이다.

중요한다른용어는메시지처리와관련된것이다. snmpMessageProcessingModel

은 메시지 형식과 메시지 처리용 SNMP 버전을 결정한다. snmpSecurityModel

은 어떤 보안 모델을 사용할 것인지를 결정한다. snmpSecurityLevel은 어떤 보안

서비스가 이 특정 작업에 요구되는지를 결정한다. 사용자는 인증이나, 인증과 기

성(암호화)을 요청할 수 있고 둘 다 하지 않을 수도 있다.

589


SNMPv3 응용

SNMP 개체 안의 모듈 사이의 서비스는 RFC에서 원시함수와 매개변수에 의해 정

의된다. 원시함수란 수행될 함수를 말하고 매개변수는 데이터를 전하고 정보를 제

어하는 데 사용된다. 이 원시함수와 매개변수를 SNMP 서비스를 정의하는 형식적

인 방법이라고 생각할 수 있다. 실제적인 원시함수의 형태는 매 구현마다 다르다.

한 예는 프로시저 호출이다. 다음의 논의에서는 어떻게 이 모든 원시함수가 잘 맞

아 돌아가는지를 보기로 한다. 아마 RFC 2571에 기초한 그림 12.8을 참조하는 것

이 도움이 될 것이다. 그림 12.8(a)에서는 명령 생성자 응용이나 통지 발신자 응용

590


snmpEngineID

엔진에 응되는 SNMP 개체뿐만 아니라 SNMP 엔진을 유일하고 분명하게 나타내는 식별자. 이

것은 옥텟열의 구문을 이용한 문서규정에 의해 정의한다.

contextEngineID

특정 contextName으로 컨텍스트 사건을 실현할 수도 있는 SNMP 개체를 유일하게 식별한다.

contextName

SNMP 엔진 안의 특정 컨텍스트를 식별한다. 전달자(Dispatcher)와 접근제어 서브시스템

(Access Control Subsystem)에 매개변수로 전달한다.

scopedPDU

contextEngineID, contextName 그리고 SNMP PDU로 구성된 데이터 블록. 보안 서브시스템

에 매개변수로 전달하거나 보안 서브시스템으로부터 매개변수로 받는다.

snmpMessageProcessingModel

메시지 처리 서브시스템의 메시지 처리 모델의 유일한 식별자. 여기에 들어갈 수 있는 값으로는

SNMPv1, SNMPv2c와 SNMPv3이다. 이것은 정수 구문을 이용한 문서규정에 의해 정의한다.

snmpSecurityModel

보안 서브시스템의 보안 모델의 유일한 식별자. 여기에 들어갈 수 있는 값으로는 SNMPv1,

SNMPv2c, 그리고 USM이 있다. 이것은 정수 구문을 이용한 문서규정에 의해 정의한다.

snmpSecurityLevel

SNMP 메시지를 보낼 수 있거나 동작이 처리될 수 있는 보안 레벨이다. 인증과 기 성이 제공되

는지 안 되는지에 의해 표현된다. 다른 값으로는 noAuthnoPriv, authNoPriv와 authPriv가 있

다. 이것은 정수 구문을 이용한 문서규정에 의해 정의한다.

principal

서비스를 제공받거나 처리가 이뤄지는 개체이다. 주체(principal)를 이루는 것으로는 특정 역할을 하

는 개인, 특정 역할을 하는 개인의 집합, 응용 그리고 이들의 임의의 조합이 될 수 있다.

securityName

주체를 나타내는 사람이 읽을 수 있는 열(string)이다. SNMP 기본요소(전달자, 메시지 처리, 보

안 접근제어) 모두에 매개변수로 전달한다.

<표 12.2>

SNMPv3 용어

591


[그림

12.8]

SNMPv3 흐

름도

전달자

(a)�명령�생

성자�및

�통지�발

신자

(b)�명령�응

답자

명령

생성자

send

Pdu

proc

essR

espo

nseP

du

prep

areO

utgo

ingM

sg

prep

areD

ataE

lem

ents

gene

rate

Req

uest

Msg

proc

essI

ncom

ingM

sg

negi

ster

Con

text

Eng

ineI

D

prep

areD

ataE

lem

ents

proc

essI

ncom

ingM

sg

proc

essP

du

retu

rnR

espo

nseP

du

prep

areR

espo

nseM

sg

gene

rate

Res

pons

eMsg

메시지�처

리모델

보안

모델

명령

응답자

전달자 네트워크로부터

SNM

P�응답

메시지�수

신

네트워크로

SNM

P�요청

메시지�전

송

네트워크로부터

SNM

P�응답

메시지�수

신

네트워크로

SNM

P�요청

메시지�전

송

메시지�처

리모델

보안

모델

(Notification Originator application)이 PDU를 보내라고 요청하고, 이어서 어

떻게 거기에 한 반응을 해당 응용으로 반환하는지 그 사건의 순서를 보여주고

있다. 이 사건은 관리자 측에서 일어난다. 그림 12.8(b)는 에이전트에서 일어나는

응되는 사건을 보여주고 있다. 그림은 들어오는 메시지가 응용에 동봉된 PDU를

어떻게 전달하고 그 응용의 응답이 나가는 메시지에 어떻게 향을 미치는지를 보

여주고 있다. 다이어그램의 어떤 화살표에는 원시함수 이름이 붙어 있는데 이것은

호출을 나타내는 것이다. 레이블이 없는 화살표는 호출에서 반환되는 것을 나타내

고 그림자는 호출과 반환이 연관되었다는 것을 나타낸다.

RFC 2573은 전송할 PDU 생성과 수신한 PDU 처리를 할 때 응용 유형에 따르

는 절차를 일반적으로 정의한다. 모든 경우에 절차는 전달자와 전달자 원시함수를

통한 상호작용에 의해서 정의된다.

명령 생성자 응용(command generator application)은 sendPdu와

processResponsePdu 전달자 원시함수를 이용한다. sendPdu는 전달자에게 목

적지, 보안 매개변수 그리고 보낼 실제적 PDU에 한 정보를 제공한다. 전달자는

메시지를 준비하기 위해 메시지 처리모델(Message Processing Model)을 요청한

다. 뒤이어서 보안 모델(Security Model)을 요청한다. 전달자는 전송을 위해 준비

된 메시지를 전송층(예를 들면 UDP)에 전한다. 만일 메시지 준비가 안 되면 전달

자에 의해서 설정되는 sendPdu의 원시함수 값을 반환하는 것으로 오류를 나타낸

다. 만일 메시지 준비가 되면 전달자는 이 PDU에 sendPduHandle 식별자를 붙이

고 그 값을 명령 생성자로 반환한다. 명령 생성자는 sendPduHandle을 저장하여

뒤이은 응답 PDU를 원래 요청과 연결 지을 수 있다.

전달자는 processResponsePdu 원시함수를 이용해서 들어오는 각각의 응답

PDU를 해당되는 명령 생성자 응용에 전달한다.

명령 응답자 응용(command responder application)은 4개의 전달자 원시함수

(registerContextEngineID, unregisterContextEngineID, processPdu,

returnResponsePdu)와 하나의 접근제어 서브시스템 원시함수(isAccess

Allowed)를 이용한다.

원시함수 registerContextEngineID는 명령 응답자 응용으로 하여금 컨텍스트

엔진의 특정 PDU 유형을 처리하게 할 목적으로 명령 응답자 응용을 SNMP 엔진

에 연관 지을 수 있게 한다. 일단 명령 응답자가 등록하면 contextEngineID와 지

원되는 pduType의 등록된 조합을 포함하는 비동기적으로 수신된 메시지를 명령

응답자로 보내어 그 조합을 지원한다. 명령 응답자는 원시함수 unregister

592


ContextEngineID를 이용해서 SNMP 엔진으로부터 연결을 끊을 수 있다.

전달자는 들어오는 각 요청 PDU를 processPdu 원시함수를 이용해서 해당 명

령 응답자 응용에 전달한다. 그러면 명령 응답자는 다음 단계를 수행한다.

1.명령 응답자는 요청 PDU의 내용을 검사한다. 동작 유형은 이 응용에 의해 사

전에 등록된 유형 중의 하나와 일치해야만 한다.

2.명령 응답자는 이 PDU가 요청한 관리 동작 수행을 위한 접근을 허락할 것인

지를 결정한다. 이를 위해 원시함수 isAccessAllowed를 호출한다.

securityModel 매개변수는 접근제어 서브시스템이 이 호출에 한 응답에

어떤 보안 모델을 사용할 것인지를 나타내고 있다. 접근제어 서브시스템은

이 보안 레벨(securityLevel)을 요청하는 주체(securityName)가 이 컨텍스

트(contextName) 안의 관리객체(variableName)에 한 관리동작을 요청

할 권한이 있는지를 결정한다.

3.접근이 허락되면 명령 응답자는 관리 동작을 수행하고 응답 PDU를 준비한

다. 만일 접근에 실패하면 명령 응답자는 실패를 나타내는 적절한 응답 PDU

를 준비한다.

4.명령 응답자는 응답 PDU를 보내기 위해서 returnResponsePdu로 전달자

를 호출한다.

통지 생성자 응용(notification generator application)은 명령 생성자 응용에 사

용되는 동일한 일반적인 절차를 따른다. 만일 정보요청(InformRequest) PDU를

보내야 한다면, 명령 생성자 응용에서 사용한 방법과 동일하게 sendPdu와 원시함

수 processResponsePdu를 이용한다. 만일 트랩 PDU를 보내야 한다면, 오직

sendPdu 원시함수만 사용한다.

통지 수신자 응용(notification receiver application)은 명령 응답자 응용에 사용

되는 일반적인 절차 일부분을 따른다. 통지 수신자는 Inform PDU와 트랩 PDU를

수신하기 위해서 우선 등록을 해야만 한다. 두 PDU 유형은 원시함수 processPdu

에 의해서 수신된다. Inform PDU에 해서는 응답에 원시함수 returnResponse

Pdu를 사용한다.

프록시 전달자 응용(proxy forwarder application)은 전달자 원시함수를 이용해

서 SNMP 메시지를 전달한다. 프록시 전달자는 4가지 기본 메시지유형을 처리

한다.

593


●명령 생성자 응용의 PDU 유형을 포함하는 메시지. 프록시 전달자는 목표

SNMP 엔진이나 아래쪽에서 목표에 가까운 SNMP 엔진을 선정하고 적절한 요

청 PDU를 보낸다.

●통지 발신자 응용의 PDU 유형을 포함하는 메시지. 프록시 전달자는 통지를 어

떤 SNMP 엔진이 받아야만 되는지를 결정하고 적절한 한 개의 통지 PDU나 여

러 개의 PDU를 보낸다.

●응답 PDU 유형을 포함하는 메시지. 프록시 전달자는 만약 사전에 전달한 요청

이나 통지가 있다면 어떤 것이 이 응답과 일치하는지를 판단하고 적절한 응답

PDU를 보낸다.

●보고 표시를 포함하는 메시지. 보고(Report) PDU는 SNMPv3 엔진- -엔진

통신이다. 프록시 전달자는 사전에 전달한 요청이나 통지가 있다면 어떤 것이 이

보고 표시와 일치하는지를 판단하고 이 보고 표시를 요청이나 통지를 보내온 쪽

에 되돌려 보낸다.

메시지 처리와 사용자 보안 모델

메시지 처리에는 일반 목적 메시지 처리 모델과 특정 보안 메시지 처리 모델이 있

다. 이것의 관계가 그림 12.8에 나와 있다.

메시지 처리 모델

RFC 2572는 일반 목적 메시지 처리 모델을 정의한다. 이 모델은 전달자로부터

PDU를 받아들이고, 메시지로 캡슐화하고, 그리고 보안관련 매개변수를 메시지 헤

더에 삽입할 것을 요청하는 책임을 진다. 메시지 처리 모델은 또한 들어오는 메시

지를 받고 보안관련 매개변수를 메시지 헤더에 삽입할 것을 요청하고, 그리고 캡

슐화된 PDU를 전달자에게 전한다.

그림 12.9는 메시지 구조를 보여주고 있다. 나가는 메시지에 해서는 메시지

처리 모델이 처음 다섯 필드를 생성하고, 들어오는 메시지에 해서는 메시지 처

리 모델이 처음 다섯 필드를 처리한다. 다음 여섯 필드는 USM(user security

model)이 사용하는 보안 매개변수를 나타낸다. 끝으로 PDU는 contextEngineID

와 contextName과 함께 PDU 처리에 확 된 PDU를 만든다.

594


처음 5 필드는 다음과 같다.

●msgVersion: snmpv3(3)으로 설정한다.

●msgID: 요청과 응답 메시지를 연결하기 위해 두 SNMP 개체 사이에 사용되는

유일한 식별자이다. 구조 안의 다른 시스템 모델에 의한 메시지 처리를 연결하기

위해서 메시지 처리기가 이 식별자를 사용한다.

●msgMaxSize: 메시지 송신자에 의해 지원되는 옥텟 단위의 최 메시지 크기를

나타낸다. 범위는 484에서 231-1이다. 이것은 송신자가 다른 SNMP 엔진으로부

터 받을 수 있는 최 단편크기이다(응답 혹은 다른 메시지 유형). 이 세 플래그

는 reportableFlag, privFlag, authFlag이다. 만일 reportableFlag1이면, 보고

(Report) PDU는 보고 PDU를 생성시키는 다음 조건하에 송신자에게 반환해야

만 한다. 플래그가 0이면, 보고 PDU를 보내지 않는다. 요청(Get, Set)이나 정보

(Inform)를 포함하는 모든 메시지 안에 reportableFlag 이 송신자에 의해 1로

설정되고, Response, 트랩 혹은 보고 PDU를 포함하는 메시지에 해서는 송신

595


[그림 12.9]

SNMPv3 USM 메시지 유형

msgIDmsgVersion

msgFlags

msgMaxSize

msgAuthoritativeEngineID

msgSecurityModel

msgAuthoritativeEngineTimemsgAuthoritativeEngineBoots

msgUserName

msgPrivacyParametersmsgAuthenticationParameters

contextNamecontextEngineID

PDU

인증�범

위

암호화�범

위

처리된�PDU(평문�또는�암호화)된

사용자�보안�모델(USM)로생성/처리함

메시지�처리�모델로생성/처리함

자가 0으로 설정한다. reportableFlag은 보고(Report)를 보내야 할 때를 정하

는 데 부가적인 도움을 준다. 이것은 메시지의 PDU 부분이 풀리지 않을 때에만

사용된다(예를 들면 키가 정확하지 않아서 복호화가 되지 않을 때). privFlag과

authFlag은 송신자가 메시지에 적용할 보안 레벨을 나타낼 때 사용한다.

privFlag1이면 암호화를 적용하고, privFlag0이면 인증을 적용한다.

(privFlag1 AND authFlag0)인 경우만 제외하고 모든 가능한 조합을 적용할 수

있다. 즉, 인증없는암호화는허락되지않는다.

●msgFlags: 최소 유효 3비트 안에 3플래그를 포함하는 하나의 옥텟열(octet

string)이다.

●msgSecurityModel: 이 메시지를 준비하기 위해 어떤 보안 모델을 송신자가 사

용할지를 표시하는 식별자로 범위 0부터 231 - 1까지의 수이다. 그래서 수신자

가 이 메시지를 처리하기 위해 어떤 보안 모델을 사용해야만 하는지를 알려준다.

나중 사용을 위해 예약된 값은 SNMPv1을 위한 값이 1이고, SNMPv2c(SNMPv1

공동체 기능을 갖는 SNMPv2)를 위한 값은 2이고, 그리고 SNMPv3를 위한 값

은 3이다.

사용자 보안 모델

RFC 2574는 사용자 보안 모델(USM: User Security Model)을 정의한다. USM

은 SNMP에 인증과 기 성 서비스를 제공한다. 구체적으로 USM은 다음 주요한

위협에 한 안전을 위해 설계되었다.

●정보 수정(Modification of information): 한 개체는 적법한 개체가 생성한 전송

중인 메시지를 수정해서 불법적 관리 동작을 실행할 수 있다. 여기에 해당되는

것으로는 객체 값을 설정하는 것이 있다. 이 위협의 핵심은 불법적인 개체가 구

성, 동작, 그리고 요금 계산 기능7)을 포함하는 모든 관리 매개변수를 변경할 수

도 있다는 것이다.

●신분 위장(Masquerade): 적법한 개체 신분으로 위장한 다른 개체가 권한 없는

관리 동작을 시도할 수 있다.

596


7) 사용자가 어떤 종류의 컴퓨터 자원을 얼마나 사용했는지를 기록 보관하는 것. 시스템 사용료 청구나 단

순히 시스템 사용 통계를 수집 보관하는 수가 있다. 이러한 사용 통계는 사용자에게 서비스를 개선하기

위한 시스템 구성 시 귀중한 자료가 된다. — 역자 주

●메시지 스트림 수정(Message stream modification): SNMP는 비연결형 전송

프로토콜을 이용해서 작동되도록 설계되었다. SNMP 메시지 순서를 바꾸거나,

전송을 지연시키거나 혹은 재전송(복제해서)하여 불법적 관리 동작을 수행하는

위협이 있다. 예를 들면, 장치를 재시작하게 하는 메시지를 복사해 두었다가 후

에 재전송하는 공격을 할 수 있다.

●노출(Disclosure): 한 개체가 관리자와 에이전트 사이의 통신을 관찰할 수 있고

관리되는 객체 값을 알아내고, 통지해야할 사건을 알아낸다. 예를 들면, 패스워

드를 변경하는 설정 명령을 관찰하여 새 패드워드를 알아내는 것이다.

USM을 만들 때 다음 두 위협에 한 안전을 생각하지 않았다.

●서비스 거부(Denial of service): 공격자가 관리자와 에이전트 사이의 교환을 못

하도록 막는다.

●트래픽 분석(Traffic analysis): 공격자가 관리자와 에이전트 사이의 일반적 트래

픽 패턴을 관찰한다.

서비스 거부 위협에 한 방어를 할 수 없다는 것을 두 가지 근거에 준해 말할

수 있다. 첫째, 서비스 거부 공격은 많은 경우에 네트워크 고장 유형과 구별이 잘

되지 않는다. 네트워크가 고장이 날 경우에는 당연히 사용할 수 있는 모든 네트워

크 관리 응용을 동원해서 해결해야만 한다. 둘째, 서비스 거부 공격은 모든 교환

유형을 방해하는 경향이 있고 전반적인 보안 장치에 한 문제이지 네트워크 관리

프로토콜 안에서만 발생되는 문제가 아니다. 트래픽 분석에서도 많은 네트워크 관

리 트래픽 패턴은 예측이 가능해서(예를 들면 개체는 하나 혹은 여러 관리지국에서

규칙적으로 발급하는 SNMP 명령에 의해 관리된다) 이런 트래픽 패턴을 관찰하는

것을 막을 만한 특별한 기능이 없다.

암호적 기능

USM을 위해 두 가지 암호적 기능이 정의되었는데 이는 인증과 암호화이다. 이 기

능을 지원하기 위해 SNMP 엔진은 두 값을 필요로 하는데 그것은 기 키

(privKey)와 인증키(authKey)이다. 별개의 이 두 개의 키는 다음 사용자를 위해

유지한다.

597


●지역 사용자(Local users): 관리 동작이 허가된 이 SNMP 엔진의 모든 주체.

●원격 사용자(Remote users): 통신하고자 하는 원격 엔진의 모든 주체.

이 값은 각 사용자를 위해 저장해 놓은 사용자 속성이다. privKey와 authKey

는 SNMP를 통해서 접근할 수 없다.

USM은 다음 두 인증 프로토콜 중 하나를 사용하도록 허락하는데 이 인증 프로

토콜은 HMAC-MD5-96과 HMAC-SHA-96이다. 3장에서 설명했던 HMAC는

안전한 해시함수와 비 키를 사용해서 메시지 인증 코드를 생성한다. HMAC-

MD5-96에서 HMAC는 기본 해시함수로 MD5를 사용한다. 16-옥텟(128-비트)

authKey가 HMAC 알고리즘의 입력으로 사용된다. 이 알고리즘은 128-비트 출력

을 생성하고 이 출력의 일부를 잘라버리고 나머지를 12옥텟(96 비트)으로 만든다.

HMAC-SHA-96에서 기본 해시함수는 SHA-1이다. authKey는 20옥텟 길이를

가진다. 알고리즘은 20-옥텟 출력을 생성하고 이것을 잘라내어 일부를 버리고 12

옥텟으로 만든다.

USM은 암호화를 위해 DES(Date Encryption Standard)의 CBC 모드를 이용

한다. 16-옥텟 privKey를 암호화 프로토콜 입력으로 사용한다. 이 privKey의 처

음 8옥텟(64비트)을 DES 키로 사용한다. DES는 오직 56-비트 키를 필요로 하기

때문에, 각 옥텟의 최소유효 비트는 무시한다. CBC 모드에서 64-비트 초기화 벡

터(IV)가 필요하다. privKey의 마지막 8옥텟은 이 IV를 생성하는 데 사용될 값을

포함한다.

주도와 비주도 엔진

메시지 전송에 있어, 송신자나 수신자 두 개체 중의 하나는 다음 규칙에 따라서 주

도(authoritative) SNMP 엔진으로 지정된다.

●SNMP 메시지가 응답을 기 하는 페이로드(예를 들면 Get, GetNext,

GetBulk, Set, 혹은 Inform PDU)를 포함하고 있을 때는, 이 메시지의 수신자

가 주도적이다.

●SNMP 메시지가 응답을 기 하지 않는 페이로드(예를 들면 SNMPv2-Trap,

Response, 혹은 Report PDU)를 포함하고 있을 때는, 이 메시지의 송신자가 주

도적이다.

598


그래서 명령 생성자를 신해서 보낸 메시지와 통지발신자가 보낸 Inform 메시

지에 해서는 수신자가 주도적이다. 명령응답자를 신해서 보낸 메시지와 통지

발신자가 보낸 Trap 메시지에 해서는 송신자가 주도적이다. 이렇게 지정하는 이

유는 다음 두 가지 목적 때문이다.

●주도적 엔진이 관리하는 클록에 따라서 메시지의 시간성(timeliness)8)을 판단한

다. 주도적 엔진이 메시지(Trap, Response, Report)를 보낼 때, 메시지는 자신

의 클록의 현재 값을 포함시켜서 보내고 비주도적 수신자는 그 클록에 맞춰 동기

화를 할 수 있다. 만일 비주도적 엔진이 메시지(Get, GetNext, GetBulk, Set,

Inform)를 보낸다면 메시지는 목적지에서 메시지의 시간성을 검사할 수 있도록

목적지의 시간 값을 추측해서 포함시킨다.

●뒤에 설명할 키 지역화(key localization) 처리를 하게 되면 단 하나의 주체가 다

수의 엔진에 저장된 키를 소유할 수 있다. 이 키는 주도적 엔진에 지역화된다. 이

렇게 되면 주체는 한 개의 키에 해서만 책임지면 되고 같은 키의 여러 복사본

을 분산된 네트워크에 저장할 경우 생기는 보안상 위험성을 없앨 수 있다.

명령 생성자(Command Generator) PDU와 Inform PDU의 수신자를 주도적

엔진으로 지정하는 것은 의미가 있다. 그래서 주도적 엔진은 메시지 시간성을 검

사에 한 책임이 있다. 만일 한 응답이나 트랩이 지연되거나 재전송되면 피해가

거의 없게 된다. 그러나 명령 생성자 PDU와 Inform PDU는 어느 정도 MIB 객체

를 읽거나 설정하는 관리 동작을 유발한다. 그래서 이런 PDU가 지연되거나 재전

송되지 않도록 보장하는 것이 중요하다. 왜냐하면 지연이나 재전송으로 인해 원치

않는 효과가 유발되기 때문이다.

USM 메시지 매개변수

메시지 프로세서가 나가는 메시지를 USM에 전달할 때, USM은 메시지 헤더에 보

안관련 매개변수를 채워 넣는다. 메시지 프로세서가 들어오는 메시지를 USM에

전달할 때, USM은 이런 필드에 들어 있는 값을 처리한다. 보안관련 매개변수는

다음과 같다.

599


8) 예상된 시간에 정확히 도착하는 것을 의미한다. — 역자 주

●msgAuthoritativeEngineID: 이 메시지의 교환에 관여되는 주도적 SNMP 엔진

의 snmpEngineID이다. 그래서 이 값은 Trap, Response 혹은 Report를 위해

발신지에 제공되고 Get, GetNext, GetBulk, Set 혹은 Inform을 위해 목적지

에 제공된다.

●msgAuthoritativeEngineBoots: 이 메시지의 교환에 관여되는 주도적 SNMP

엔진의 snmpEngineBoots 값이다. 객체 snmpEngineBoots는 범위 0부터

231 - 1 사이의 정수이다. 이 정수값은 이 SNMP 엔진이 초기화하거나 자신의

초기 구성 이후 자신을 재초기화한 회수를 나타낸다.

●msgAuthoritativeEngineTime: 이 메시지의 교환에 관여되는 주도적 SNMP 엔

진의 snmpEngineTime 값이다. 객체 snmpEngineTime은 범위 0부터 231-1

사이의 정수이다. 이 정수값은 이 주도적 SNMP 엔진이 마지막으로 snmp

EngineBoots 객체를 증가시킨 이후 경과된 초(second) 수를 나타낸다. 각 주도

적 SNMP 엔진은 일초에 자신의 snmpEngineTime 값을 한 번씩 증가시킬 책

임을 지고 있다. 비주도적 엔진은 자신이 통신을 하고 있는 각 원격 주도적 엔진

을 위해 자신의 snmpEngineTime에 한 추측(notion)을 증가시킬 책임을 가

지고 있다.

●msgUserName: 사용자(주체)로서 그 사용자를 위해서 메시지가 교환된다.

●msgAuthenticationParameters: 이 교환에 인증을 사용하지 않으면 이 값은 비

어있다. 그렇지 않으면, 이것은 인증 매개변수이다. 현재의 USM 정의에서 인증

매개변수는 HMAC 메시지 인증 코드이다.

●msgPrivacyParameters: 이 교환에서 기 성을 사용하지 않는다면 이 값은 비

어있다. 그렇지 않으면, 이것은 기 성 매개변수이다. 현재의 USM 정의에서 기

성 매개변수는 DES CBC 알고리즘에서 초깃값(IV)을 구성하는 데 사용되는

값이다.

그림 12.10에 USM의 동작을 요약해 놓았다. 메시지 전송에서 필요하다면 암호

화를 우선 수행한다. 표시(scoped) PDU를 암호화하고 메시지 페이로드에 적재하

고 msgPrivacyParameters 값이 초깃값 IV를 생성하는 데 필요한 값을 설정한

다. 그 뒤에 필요하다면 인증을 수행한다. 확 된 PDU를 포함하는 전체 메시지는

HMAC에 입력되고 결과로 얻은 인증코드가 msgAuthenticationParameters 안

에 적재된다. 들어오는 메시지에 해서 필요하다면 인증을 먼저 수행한다. USM

은 먼저 자신이 계산한 MAC와 들어오는 MAC를 비교하여 검사한다. 만일 두 값

600


601


[그림

12.10]

USM 메

시지

처리

Yes

YesY

esY

es

No

No

No

No

사용자

정보�검

색메시지

파라미터�검

색

인증

필요성?

프라이버시

필요성?

msg

Priv

acyP

aram

eter

s�

Nul

l str

ing

scop

ePdu

를�암

호화

msg

Priv

acyP

aram

eter

s�설정

(a) 메시지�전

송

(b) 메시지�수

신

컴퓨터� M

AC;

msg

Aut

hent

icat

ionP

aram

eter

s와�비

교

메시지가�윈

도우즈�안

에있는지�없

는지를�결

정

scop

edPd

u복호화

인증

필요성?

msg

Aut

hent

icat

ionP

aram

eter

s�

Nul

l str

ing

msg

Aut

hent

icat

ionP

aram

eter

s설정

프라이버시의

필요성?

이 일치하면, 그 메시지가 인증된 것으로 간주한다(주장되는 곳에서 메시지가 왔

고 전송 도중에 수정되지 않았다). USM은 이 메시지가 허용되는 시간 윈도우

(within the time window) 안에 왔는지를 검사한다. 이것에 해서는 뒤에 설명

하기로 한다. 만일 메시지가 제 시간에 도착하지 않았다면, 인증되지 않은 것으로

간주해서 버려버린다. 끝으로 만일 표시(scoped) PDU가 암호화되었다면, USM은

복호화를 수행하고 평문을 반환한다.

USM 적시성 메커니즘

USM은 메시지 지연과 재전송을 막기 위한 시간성 메커니즘을 포함하고 있다. 주

도적 엔진의 능력 안에서 동작할 수 있는 각 SNMP 엔진은 반드시 자신의 지역시

간을 참조하는 두 개의 객체를 갖고 있어야 한다. 그 2개는 snmpEngineBoots와

snmpEngineTime이다. SNMP 엔진을 처음 설치할 때, 이 2개의 객체 값을 0으

로 설정한다. 그 후에 snmpEngineTime은 1초에 한 번씩 값이 증가한다. 만일

snmpEngineTime 값이 최댓값 231- 1에 도달하면, 마치 시스템이 재부팅되듯이

snmpEngineBoots은 증가되고 snmpEngineTime은 0으로 설정되고 다시 증가

하기 시작한다. 동기화 메커니즘을 사용하려면, 비주도 엔진은 자신이 통신을 하

고 있는 각 주도적 엔진의 추측되는 시간을 유지한다. 이 추측된 값을 밖으로 나가

는 각 메시지 안에 집어넣어 수신하는 주도적 엔진이 들어오는 메시지가 시간성을

갖고 있는지 아닌지를 판단하도록 한다.

동기화 메커니즘은 다음과 같이 작동한다. 비주도적 엔진은 자신이 알고 있는

각 주도적 SNMP 엔진의 다음과 같은 3 변수에 해서 복사본을 가지고 있다.

●snmpEngineBoots: 원격 주도적 엔진에 한 snmpEngineBoots의 가장 최신

의 값.

●snmpEngineTime: 원격 주도적 엔진에 한 이 엔진의 snmpEngineTime 추

측(notion)이다. 이 값은 나중에 설명할 동기화 처리에 의해 원격 주도적 엔진과

동기화된다. 동기화 사건 사이에 이 값은 원격 주도적 엔진과 느슨한 동기화

(loose synchronization)를 유지하기 위해 논리적으로 1 초에 한 번씩 증가된다.

● latestReceivedEngineTime: 원격 주도적 엔진으로부터 이 엔진이 받은

msgAuthoritativeEngineTime의 가장 큰 값, msgAuthoritativeEngineTime

값이 큰 것이 수신될 때마다 이 값은 갱신된다. 이 변수의 목적은 재전송 메시지

602


공격을 막기 위한 것이다. 이 재전송 공격은 비주도적 SNMP 엔진의

snmpEngineTime 추측(notion)이 증가하지 못하게 막을 수도 있다.

이 세 값으로 된 집합을 이 엔진이 알고 있는 각각의 원격 주도적 엔진에 해

유지한다. 논리적으로 이 값을 각 원격 주도적 엔진의 유일한 snmpEngineID로

목록화시킨 일종의 캐시에 저장한다.

비주도적 엔진이 시간 동기화를 유지하기 위해서 각 주도적 엔진은 자신의

snmpEngineID 값뿐만 아니라 자신의 현재 부트(boot)와 시간 값을 내보내는

Response 메시지, Report 메시지 혹은 Trap 메시지에 끼워 넣는다. 여기서 이 메

시지는 필드 msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime,

그리고 msgAuthoritativeEngineID 안에 있는 것이다. 만일 메시지가 인증되었

고 메시지가 허용되는 시간 윈도우(within the time window) 안에 도착했다면,

수신하는 비주도적 엔진은 원격 엔진을 위해서 다음 규칙에 따라서 자신의 지역변

수(snmpEngineBoots, snmpEngineTime 및 latestReceivedEngineTime)을

갱신한다.

1. 만일 다음 두 조건 중 적어도 하나가 참이면 갱신을 한다.

�(msgAuthoritativeEngineBoots ＞ snmpEngineBoots) OR

�[(msgAuthoritativeEngineBoots = snmpEngineBoots) AND

(msgAuthoritativeEngineTime ＞ latestReceivedEngineTime)]

첫 번째 조건은 만약 주도적 엔진에서 온 boot 값이 최종 갱신을 한 이후에 증가

되었다면 갱신을 필히 해야 한다는 것을 말한다. 두 번째 조건은 만일 boot 값이

증가되지 않았다면, 들어오는 엔진시간이 가장 최근에 수신한 엔진시간보다 클 때

갱신을 필히 해야 한다는 것을 말한다. 만약 두 개의 들어오는 메시지 순서가 바뀌

어서 도착하거나(이런 경우가 있다) 혹은 재전송 공격을 당하고 있다면 들어오는

엔진시간은 가장 최근에 수신한 엔진시간보다 작다. 이런 두 경우에 수신하는 엔

진은 갱신을 수행하지 않을 것이다.

2.만일 갱신이 요청되면, 다음과 같은 변화가 생긴다.

�snmpEngineBoots의 값을 msgAuthoritativeEngineBoots 값으로 설정

한다.

603


�snmpEngineTime의 값을 msgAuthoritativeEngineTime 값으로 설정

한다.

�latestReceivedEngineTime의 값을 msgAuthoritativeEngineTime 값

으로 설정한다.

만일 논리를 뒤집어보면 만일 msgAuthoritativeEngineBoots

snmpEngineBoots라면 갱신은 이뤄지지 않는다는 것을 알 수 있다. 이런 메시지

는 인증되지 않는 것으로 간주되고 무시되어야만 한다. 만일 msgAuthoritative

EngineBoots ＜ snmpEngineBoots이지만 msgAuthoritativeEngineTime

latestReceivedEngineTime이라면 역시 갱신은 이루어지지 않는다. 이 경우에 메

시지는 인증될 수 있지만 순서가 틀릴 수 있다. 이런 경우에 snmpEngineTime의

갱신은 보장되지 않는다.

이 메시지에 해 인증 서비스를 사용할 때만 동기화를 사용하고 메시지에 한

인증은 HMAC를 이용해서 결정한다. 이런 제약을 필히 두어야 하는 이유는 인증

범위가 msgAuthoritativeEngineID, msgAuthoritativeEngineBoots 그리고

msgAuthoritativeEngineTime을 포함하고 그래서 이 값이 확실하다는 것을 확

신시켜주기 때문이다.

SNMPv3에서 지연이나 재전송 공격을 막기 위해 메시지는 합리적인 시간 윈도

우 안에 수신되어야만 한다고 명시하 다. 사용하는 클록의 정확성, 왕복 통신지

연, 클록이 동기화되는 주파수가 주어진 경우 시간 윈도우는 가능하면 최 로 작

게 선택해야만 한다. 만약 시간 윈도우가 너무 작으면, 인증될 메시지가 인증되지

못하고 거절될 것이다. 반면에 시간 윈도우가 크면 악성 메시지 지연에 취약해질

것이다.

더 중요한 주도적 수신자의 경우를 생각해보자. 비주도적 수신자에 의한 시간성

시험은 약간 다르다. 인증되고 메시지의 msgAuthoritativeEngineID가 이 엔진

의 snmpEngineID 값하고 동일한 들어오는 메시지 모두에 해서, 엔진은 들어오

는 메시지로부터 나온 msgAuthoritativeEngineBoots와 msgAuthoritative

EngineTime의값을이엔진자신이사용하기위해가지고있는snmpEngineBoots

와 snmpEngineTime를 비교한다. 들어오는 메시지가 만일 다음 조건 중의 어느

하나라도 참이면 시간 윈도우 밖에 있는 것으로 간주한다.

604


●snmpEngineBoots = 231 - 1 OR

●msgAuthoritativeEngineBoots ≠ snmpEngineBoots OR

●msgAuthoritativeEngineTime의 값이 snmpEngineTime의 값과 ±150 초

이상 차이가 난다.

첫째 조건은 만일 snmpEngineBoots가 그것의 최댓값에 도달하면 어떤 수신

되는 메시지도 인증되지 않은 것으로 간주한다는 것을 말한다. 둘째 조건은 메시

지가 반드시 지역 엔진의 부팅시간과 같은 부팅시간을 가져야만 한다는 것을 말한

다. 예를 들면, 만일 지역 엔진이 재부팅되었고 원격 엔진은 재부팅 때문에 지역

엔진하고 동기화되지 않았다면, 원격 엔진에서 온 메시지를 인증되지 못한 것으로

간주한다. 마지막 조건은 수신되는 메시지상의 시간이 반드시 지역시간에서 150초

를 뺀 것보다 커야 하고 지역시간에다 150초를 더한 것보다 작아야 한다는 것을 말

한다.

만일 한 메시지가 시간 윈도우 밖에 있다면 그 메시지는 인증되지 않은 것으로

간주되고 오류 표시(notInTimeWindow)를 호출한 모듈로 반환한다.

앞에서와 마찬가지로, 동기화처럼 시간성 검사는 인증 서비스를 사용하면서 메

시지가 인증될 때만 비로소 완료되고 메시지 헤더 필드에 한 인증을 확인할 수

있는 것이다.

키 지역화

비주도적 엔진의 주체와 주도적 엔진의 원격 엔진 사이에 통신을 할 경우,

SNMPv3에서 인증과 기 성 서비스를 이용하기 위해서는 비 인증키와 비 기

키를 필히 공유하고 있어야 한다. 이 키를 이용해서 비주도적 엔진(전형적으로

관리 시스템)의 사용자는 자신이 관리하는 원격 인증 시스템(전형적으로 에이전트

시스템)과의 통신에 인증과 기 성을 제공할 수 있다. 이 키에 한 생성, 갱신 그

리고 관리에 한 지침이 RFC 2574에 나와 있다.

주체 측의 관리 부담을 단순화하기 위해 각 주체는 한 개의 인증키와 한 개의 기

키를 갖고 있으면 된다. 이 키를 MIB에 저장하지 않기 때문에 SNMP를 통해서

접근할 수도 없다. 이 부절에서는 우선 패스워드를 이용하여 이 키를 생성하는 기

술에 해서 살펴보기로 한다. 그 다음 키 지역화 개념에 해서 알아본다. 키를

지역화하면 주체는 각 원격 엔진과 유일한 인증키와 암호키를 공유하고 단 한 개

605


의 인증키와 암호키를 지역적으로 보관하고 있으면 된다. 이 두 기술은

[BLUM97a]에서 처음으로 제안되었다.

사용자는 16-옥텟 기 키와 길이가 16이나 20옥텟인 인증키를 필요로 한다. 사

용자가 사람인 경우에 키는 비트열로 된 키보다는 사람이 읽을 수 있는 패스워드

형태로 가지고 있는 것이 바람직하다. 따라서 사용자 패스워드에 16이나 20옥텟

키를 응시키는 알고리즘이 RFC 2574에 정의되어 있다. USM에서는 패스워드

에 한 특별한 제약을 하고 있지 않지만 지역 관리정책으로 사용자 패스워드는

쉽게 추측할 수 없는 것을 사용하도록 한다.

패스워드를 키로 바꾸는 과정은 다음과 같다.

●사용자 패스워드를 입력으로 사용하여 필요한 회수만큼 패스워드 값을 반복하

고, 필요하다면 끝을 잘라내고 열(string) digest09)을 만들어서 길이가 220옥텟

인 비트열을 만든다. 예를 들면, 8-문자 패스워드(23옥텟)를 217번 이어 붙여서

digest0을 만든다.

●만일 16-옥텟 키가 필요하다면, digest0에 MD5 해시를 적용해서 digest1을 만

든다. 만약 20-옥텟 키가 필요하다면, digest0에 SHA-1 해시를 적용해서

digest1을 만든다. 출력된 것이 사용자 키이다.

이 기술을 이용하면 전수공격 속도를 아주 느리게 할 수 있는 장점이 있다. 공격

자가 전수공격을 할 경우 다양한 가능성 있는 패스워드를 시도하여 그 패스워드로

부터 키를 생성하고 결과로 나온 키가 자신이 사용할 수 있는 인증데이터나 암호

데이터에 적용되는지 검사하기 때문에 속도가 느려진다. 예를 들면, 한 공격자가

인증 메시지 하나를 가로챘다고 하자. 그는 여러 가지 가능한 사용자 키를 가지고

HMAC 값을 생성하려고 시도할 것이다. 만약 일치하는 것을 하나 발견하면, 공격

자는 패스워드를 발견한 것으로 간주되는 것이다. 방금 전에 설명했던 두 단계 절

차를 취하면 이런 공격을 하는 데 걸리는 시간이 상당히 늘어나게 된다.

이 기술의 또 다른 장점으로는 사용자 키를 특정 네트워크 관리 시스템(NMS:

network management system)으로부터 분리할 수 있다는 것이다. 어떤 NMS도

사용자 키를 저장할 필요가 없다. 신에 필요할 경우에는 사용자 패스워드로부터

생성하면 된다. [BLUM97b]에 언급된 다음과 같은 관점에서 NMS를 패스워드와

606


9) 그냥 다이제스트를 구별하기 위해 사용한 명칭이다. — 역자 주

독립되도록 해야 하겠다는 생각을 하게 되었다.

●만약 키를 패스워드로부터 생성하는 신 저장을 하기로 한다면 중앙 집중화된

비 키 저장소를 만드는 것을 고려해볼 수 있다. 그러나 이것은 전반적인 신뢰성

에 향을 미치게 되고 만약 필요한 때에 저장소에 접근을 할 수 없게 된다면 문

제해결이 불가능해진다.

●한편, 만일 저장소를 여러 곳에 만들어 동일한 키를 보관한다면 침입자에게 공격

할 상을 더 많이 제공하게 되어 전체적인 보안을 위협하게 된다.

●만약 중앙 집중화된 저장소를 이용하거나 혹은 여러 복제 저장소를 설치 운용한

다면, 이 장소는 안전한 곳이어야만 한다. 이렇게 되면 비유적으로 말해서 화재

진압 중에“전진캠프(forward camp)”를 설치할 기회가 줄어든다. 즉, 예상치 못

한 네트워크 일부 구간이 예측 불가능한 기간 동안 작동이 되지 않거나 접근할

수 없을 때 수리하는 동안 임시방편을 구하기가 어렵다.

인증과 암호 두 가지 모두에 사용할 한 개의 키를 생성하는 데 한 패스워드를 사

용할 수 있다. 두 개의 패스워드를 사용하면 더 안전한 방법이 되는데 하나는 인증

키를 생성하고 다른 하나는 또 다른 암호키를 생성하는 데 사용하는 것이다.

지역화된 키는 사용자와 한 주도적 SNMP 엔진 사이에 공유하는 비 키라고

RFC 2574에 정의하 다. 키를 지역화하는 이유는 사용자가 오직 한 개의 키(만약

인증과 기 성이 요구된다면 두 개의 키)만 관리하면 되고 그래서 오직 한 패스워

드(혹은 두 개)만 기억하면 되기 때문이다. 특정 사용자와 각 주도적 SNMP 엔진

사이에 공유하는 실제적 비 은 모두 다르다. 한 사용자 키를 여러 개의 유일한 키

(각 원격 SNMP 엔진당 한 개씩)로 바꾸는 처리를 키 지역화(key localization)라

고 한다. 이렇게 하는 이유가 [BLUM97a]에 나와 있는데 그것을 여기에 요약하기

로 한다.

키 관리를 위해 다음 목적을 정의한다.

●분산 네트워크의 모든 SNMP 에이전트 시스템은 키를 관리할 권한을 가지는 각

사용자별로 유일한 자신(에이전트)의 키를 가진다. 만약 다수의 사용자가 관리자

로서 권한을 가지고 있다면, 에이전트는 각 사용자에 한 유일한 인증키와 유일

한 암호키를 가진다. 그래서 만일 한 사용자에 한 키가 침해당했다면, 다른 사

용자를 위한 키는 침해와 관계없이 사용할 수 있다.

607


●다른 에이전트가 가지고 있는 한 사용자에 한 키는 다 다르다. 그래서 만일 한

에이전트가 침해를 당했다면, 오직 해당 에이전트에 한 사용자 키만 침해를 당

한 것이기 때문에 침해당하지 않은 에이전트를 위해 사용하던 사용자 키는 문제

없이 사용할 수 있다.

●사전 구성된 네트워크 관리 시스템(NMS)을 사용할 수 있냐 없냐에 무관하게 네

트워크의 어느 지점에서도 네트워크 관리를 수행할 수 있다. 그래서 사용자는 아

무 관리국에서나 관리 기능을 수행할 수 있다. 앞에서 설명한 패스워드를 키로

전환하는(password-to-key) 알고리즘을 이용하면 이것이 가능하다.

피해야 할 사항을 다음과 같이 정의할 수 있다.

●사용자가 많은 수의 키를 기억(혹은 관리)해야 하는 상황. 즉, 새롭게 관리될 에

이전트가 추가되면 키의 수가 늘어나야 되는 상황.

●한 에이전트에 한 키를 알고 있는 공격자가 모든 사용자에게 다른 에이전트로

위장할 수 있는 상황이나 모든 에이전트에게 다른 사용자로 위장을 할 수 있는

상황.

앞에 나타낸 목적과 고려사항에 중점을 두기 위해서 단일 사용자 키는 역 계산

이 불가능한 일방향 함수를 이용해서 인증 엔진(다른 에이전트)마다 다른 지역화된

키를 매핑해야 한다. 이 절차는 다음과 같다.

●digest1(앞에서 설명했음)과 주도적 엔진의 snmpEngineID 값과 digest1을 이

어 붙여서 열(string) digest2를 만든다.

●만약 16-옥텟 키가필요하면, digest2에MD5 해시를적용하고, 20-옥텟 키가 필

요하면SHA-1 해시를적용하여얻어진결과를사용자의지역화키로사용한다.

여기서 구한 지역화 키는 안전한 형태로 에이전트 시스템 안에 구성할 수 있다.

MD5와 SHA-1의 일방향 특성 때문에 공격자가 설사 지역화 키를 알아냈다 할지

라도 사용자 키를 알아낸다는 것은 불가능하다.

키 지역화 과정이 그림 12.11에 요약되어 있다.

608


뷰-기반 접근 제어

접근제어는 PDU 레벨에서 수행되는 보안 기능이다. 접근기능 문서에는 지역 MIB

에 속하는 관리되는 객체에 해 원격 주체가 접근하는 것을 허락해야 하는지를

결정하는 메커니즘을 정의해놓았다. 생각해볼 수 있는 것으로 다중 접근 제어

(multiple access control) 메커니즘을 정의할 수 있다. SNMPv3 문서에는

VACM(view-based access control model)을 정의해놓았다. VACM 자체는 이

에이전트에 한 접근 제어 정책을 정의하고 원격 구성을 할 수 있도록 MIB를 사

용한다.

VACM의 두 가지 중요한 특성은 다음과 같다.

●VACM은 지역 MIB에 속하는 관리되는 객체에 해 원격 주체가 접근하는 것을

허락해야 하는지를 결정한다.

●VACM은 다음을 제공하는 MIB를 사용한다.

●이 에이전트를 위한 접근 제어 정책을 정의한다.

●사용하게 될 원격 구성을 가능하게 한다.

VACM 모델 요소

RFC 2575에는 VACM을 구성하는 다섯 가지 요소를 정의하 는데 그것은 그룹

609


[그림 12.11]

키 지역화

확장된�패스워드스트링에�해시

취하기

사용자�키와원격�EngineID에

해시�취하기


해시�취하기


해시�취하기지역화된

키

지역화된키

지역화된키

사용자키

사용자패스워드

(group), 보안 레벨(security level), 컨텍스트(context), MIB 뷰(MIB view) 그리

고 접근정책(access policy)이다.

그룹(group)은 여러 개의 <securityModel, securityName> 쌍으로 이뤄진 집

합으로 정의되거나 이런 쌍을 하나도 갖지 않는 집합으로 정의된다. 여기서 이 쌍

은 그룹을 위해 SNMP 관리 객체에 접근할 수 있다. securityName은 주체를 나

타내고 주어진 그룹 안의 모든 주체는 동일한 접근 권한을 가진다. 각 그룹에 해

유일한 groupName을 지정한다. 그룹 개념을 이용하면 접근권한에 한 관리자

를 분류하기가 쉬워진다. 예를 들면, 상위계층 관리자는 한 범위의 접근권한(a set

of access rights)10)을 가지게 되는 반면 중간계층 관리자는 또 다른 범위의 접근

권한을 가지게 된다.

임의의 주어진 securityModel과 securityName의 조합은 많아야 한 개의 그룹

에 속할 수 있다. 즉, 이 에이전트에 해서 주어진 securityModel에 의해 통신이

보호되는 한 주체는 오직 한 그룹에만 속할 수 있다.

그룹의 접근권한은 요청을 포함하는 메시지의 보안 레벨(security level)에 따라

달라진다. 예를 들면, 한 에이전트는 인증되지 않는 통신을 통한 요청에 해 읽기

만 허락할 수도 있고 쓰기 접근에 해서는 인증을 요구할 수 있다. 더구나 어떤

민감한 객체에 해서 에이전트는 요청과 응답을 할 때 기 서비스를 사용하는

통신을 통해서 하도록 요구할 수 있다.

MIB 컨텍스트란 지역 MIB에 속하는 객체 인스턴스(instance)를 원소로 갖는 명

명된 하나의 부분집합이다. 컨텍스트를 이용하면 객체를 모아서 상이한 접근정책

을 갖고 있는 모음을 만들기가 쉽다.

컨텍스트는 접근제어와 관련된 개념이다. 한 관리지국이 에이전트에 속한 관리

정보에 접근하기 위해 한 에이전트와 상호교환을 한다면 그 교환은 관리 주체와

에이전트의 SNMP 엔진 사이에서 이루어진다. 이때 이 주체와 이 컨텍스트에 적

용하는 MIB 뷰 안에 접근제어 권한을 표시한다. 컨텍스트는 다음과 같은 핵심적

특성을 갖고 있다.

●contextEngineID에 의해 유일하게 식별되는 SNMP 개체는 한 개 이상의 컨텍

스트를 가지고 있을 수 있다.

610


10) 한 개의 접근권한을 원소로 보아서 접근권한 전체 모음을 한 집합으로 볼 수 있고 그 집합의 한 부분집

합을“한 범위의 접근권한”으로 번역하 다. — 역자 주

●한 객체나 객체 인스턴스는 한 개 이상의 컨텍스트에 나타날 수 있다.

●여러 개의 컨텍스트가 있을 때 개별적 객체 인스턴스를 구별하려면 그것의 객체

유형과 인스턴스 이외에 contextName과 contextEngineID를 반드시 식별해

야만 한다.

자주 일어나는 경우로 한 에이전트 안의 관리되는 객체의 한 부분집합에 해

한 특정 그룹이 접근하는 것을 제한하고 싶을 때가 생긴다. 이를 달성하려면 컨텍

스트에 접근할 때 관리되는 객체(옵션으로 특정 객체 인스턴스)의 특정 집합을 정

의하는 MIB 뷰(view)를 이용하면 된다. VACM은 뷰 서브트리(view subtree)와 뷰

집단(view families)을 기반으로 하는 강력하고 융통성 있는 기술을 이용해서

MIB 뷰를 정의한다. MIB 뷰는 서브트리 집단이나 모음으로 정의된다. 이때 각 서

브트리는 뷰에 포함되기도 하고 제외되기도 한다.

지역 데이터베이스 안의 관리되는 객체는 객체 식별자를 기반으로 해서 계층적

으로 혹은 트리형태로 정리되어 있다. 이 지역 데이터베이스는 인터넷-표준 관리

정보구조(SMI: Structure of Management Information)에 준해 정의된 모든 객

체 유형의 부분집합으로 이루어졌고 (객체 인스턴스의)식별자가 SMI 명세를 준수

하는 객체 인스턴스를 포함한다.

SNMPv3은 서브트리 개념을 포함하고 있다. 서브트리는 단순히 MIB 명명

(naming) 계층의 한 노드와 그 노드에 부속된 요소로 구성된다. 더 형식적으로 말

하면, 서브트리란 자신(객체 혹은 객체 인스턴스)의 이름 앞에 붙는 ASN.1

OBJECT IDENTIFIER가 동일한 모든 객체와 객체 인스턴스를 원소로 갖는 집합

이다. 모든 서브트리 인스턴스의 이름 중 앞부분의 가장 긴 공통 접두어가 바로 이

서브트리 부모노드(parent node)의 객체 식별자이다.

vacmAccessTable 안의 각 개체와 연관된 것은 읽기접근, 쓰기접근, 통지접근

을 위한 세 가지 MIB 뷰이다. 각 MIB 뷰는 서브트리의 한 집합으로 구성된다.

MIB 뷰 안의 각 뷰 서브트리는 포함되는 것과 제외되는 것으로 표시된다. 즉,

MIB 뷰는 그 서브트리에 속한 모든 객체 인스턴스를 포함하거나 제외시킨다. 추

가로 세 한 접근제어(예를 들면 객체 인스턴스 레벨의 접근제어)가 필요할 때 요

구되는 구성정보 양을 줄이기 위해서 뷰 마스크(view mask)를 정의한다.

VACM을 이용하면 특정한 접근권한의 범위를 가지고 접근제어를 할 수 있도록

SNMP 엔진을 구성할 수 있다. 이렇게 구성된 특정 접근권한의 범위를 접근정책

(access policy)이라고 한다. 접근 결정은 다음 요소에 따라서 달라진다.

611


●접근 요청을 하는 주체(principal). VACM에서는 에이전트가 다른 사용자에게

다른 접근 권한을 부여할 수 있다. 예를 들면, 네트워크까지의 구성을 책임지는

관리자 시스템은 지역 MIB 안의 항목을 변경할 넓은 권한을 가지고 있을 수 있

고 모니터링 책임을 지는 중간 레벨 관리자는 읽기만이 허락되는 접근권한을 갖

고 있을 수 있고 더 나아가서 오직 지역 MIB의 한 부분집합으로만 접근이 제한

될 수도 있다. 앞에서 논의 되었던 것처럼, 그룹에 주체가 지정되고 접근정책이

그룹에 지정된다.

●보안 레벨(security level)에 따라 요청을 SNMP 메시지 안에 실어서 통신한다.

전형적으로, 한 에이전트는 설정 요청(쓰기 동작)을 포함하는 메시지에 해 인

증을 사용할 것을 요구한다.

●요청된 메시지를 처리하는 데 사용하는 보안 모델(security model). 한 에이전트

안에 여러 보안 모델을 구현하고 있다면, 에이전트는 다른 보안 모델이 처리한

메시지에 의해 통신된 요청에 한 다른 접근 레벨을 제공할 수 있도록 구성을

해야 한다. 예를 들면, 요청 메시지가 USM을 통해 왔다면 어떤 항목은 접근이

가능하지만 만일 보안 모델이 SNMPv1이면 접근이 불가능하다.

●요청에 한MIB 컨텍스트(MIB context).

●접근 요청된 특정 객체 인스턴스(object instance). 어떤 객체는 다른 것보다 더

중요하고 민감한 정보를 갖고 있어서 접근정책은 요청되는 특정 객체 인스턴스

에 따라서 달라져야만 한다.

●요청된접근 유형(type of access)(읽기, 쓰기, 통지). 읽기, 쓰기, 그리고 통지는 다

른관리동작이다. 각각의이동작에각기다른접근제어정책을적용할수있다.

접근 제어 처리

SNMP 응용은 isAccessAllowed 원시함수를 통해서 VACM의 도움을 요청한다.

이때 원시함수의 입력 매개변수는 securityModel, securityName,

securityLevel, viewType, contextName 그리고 variableName이다. 이 매개변

수 모두는 접근제어 결정을 하는 데 이용된다. 다른 말로 하면, 접근 제어 서브시

스템(Access Control Subsystem)을 정의할 때는 에이전트의 접근제어 구성에 매

우 유연한 도구를 제공하는 방향으로 정의해야 한다. 이를 위해서 접근제어 결정

요소를 여섯 가지 독립된 변수로 쪼개야 한다.

RFC 2575에 있는 그림을 인용한 그림 12.12는 입력변수를 보는 관점을 보여주

고 있고, VACM MIB 안의 다양한 표가 접근제어 결정을 하는 데 어떻게 작용하는

612


지를 보여주고 있다.

●누가(who): securityModel과 securityName의 조합이 이 동작의 주체(who)를

정의한다. 이것은 자신(주체)의 통신이 주어진 securityModel에 의해 보호되는

주체를 식별한다. 이 조합은 이 SNMP 엔진 안에서 많아야 한 개의 그룹에 속한

다. securityModel과 securityName이 주어진 상태에서 vacmSecurity

ToGroupTable은 groupName을 제공한다.

●어디에서(where): contextName은 어디(where)에서 원하는 관리 객체를 찾을

수 있는지를 나타낸다. vacmContextTable은 인식되는 contextNames의 목록

을 포함하고 있다.

●어떻게(how): securityModel과 securityLevel의 조합은 어떻게(how) 들어오는

요청이나 Inform PDU가 보호되는지를 정의한다. who와 where와 how를 조합

한 것은 vacmAccessTable 안에 항목이 없는 것을 식별하거나 한 개의 항목을

식별해낸다.

●왜(why): viewType는 왜(why) 접근이 요청되었는지를 나타낸다. 즉, 읽기 위한

것인지, 쓰기 위한 것인지 혹은 통지하기 위한 것인지를 나타낸다.

vacmAccessTable에서 선택된 항목은 각 이 세 가지 유형의 동작에 한 한 개

613


[그림 12.12]

VACM 논리

Who Where How

securityModel

vacmSecurityToGroupTable

vacmContextTable

vacmAccessTable

vacmViewTreeFamilyTable

Yes/no 결정

securityName

groupName variableName(OID)

securityModel

viewName

securityLevel object-type object-instance

contextName

Why

viewType(read/write/notify)

What Which

의 MIB viewName을 포함하고 있고, viewType은 특정 viewName을 선택하

기 위해 사용한다. 이 viewName은 vacmViewTreeFamilyTable에서 적절한

MIB view를 선택한다.

●무슨(what): variableName은 객체 식별자인데 이것의 접두부분은 특정 객체유

형을 식별하고 접미부분은 특정 객체 인스턴스를 식별한다. 객체유형은 무슨

(what) 유형의 관리정보가 요청되었는지를 나타낸다.

●어떤(which): 객체 인스턴스는 어떤(which) 특정 정보 항목이 요청되었는지를

나타낸다.

끝으로 variableName은 검색해서 가져온 MIB 뷰와 비교된다. 만일

variableName이 MIB 뷰에 속하는 한 요소와 일치하면 접근을 허락한다.

동기

VACM을 형성하는 개념은 보다 복잡한 접근제어의 정의를 만들어내는 것처럼 보

인다. 이런 개념을 소개하는 동기는 관리정보에 접근하는 것과 연관된 관계를 명

확하게 하고, 에이전트에서 저장해야 하는 것과 처리해야 할 요구를 최소화하기

위해서이다. 이런 동기를 이해하기 위해 다음을 고려해보자. SNMPv1에서 다음과

같은 보안관련 정보를 표시하기 위해 공동체 개념(community concept)을 사용하

다.

●요청하는 개체의 신원(관리지국)

●수행하는 개체의 신원(자신을 위해 혹은 프록시 되는 개체를 위해 동작하는 에이

전트)

●접근될 관리정보의 위치에 한 신원(에이전트나 프록시되는 개체)

●인증 정보

●접근제어 정보(요구되는 동작을 수행할 권한)

●MIB 뷰 정보

이 모든 개념을 단 하나의 변수에 집약시키게 되면 유연성과 기능성이 떨어진

다. VACM은 각 항목에 해 다른 변수를 사용하여 동일한 보안관련 정보 집합을

제공한다. 이것은 SNMPv1을 상당히 많이 개량한 것이다. 이것은 여러 가지 개념

을 분리해서 값을 별도로 지정할 수 있게 만든 것이다.

614


[STAL99]는 SNMP, SNMPv2, 와 SNMPv3에 한 종합적이고 자세한 검토를

하 다. 이 책은 또한 네트워크 관리 기술에 한 개요도 제공한다.

STAL99 Stallings, W., SNMP, SNMPv2, SNMPv3, and RMON 1 and 2,

Reading, MA: Addison-Wesley, 1999.

●SNMPv3 Web site: Technical University of Braunschweig에서 운 하는 사

이트이다. RFC와 인터넷 드래프트에 한 링크, 작업 그룹에 의해 제공된 분류

와 제안된 변경, 그리고 SNMPv3 구현을 하는 벤더에 한 링크를 제공한다.

●The Simple Web site: 이 그룹에서 생성하는 모든 문서를 포함하고 있다.

추천 웹 사이트

615


12.4 추천 자료와 웹 사이트

12.5 주요 용어, 복습문제와 연습문제

주요

용어 공동체(community)

공동체 이름(community name)

관리정보베이스(management information

base(MIB))

관리지국(management station)

네트워크 관리 프로토콜(network manage-

ment Protocol)

단순 네트워크 관리 프로토콜(Simple Network

Management Protocol(SNMP))

메시지처리모델(message processing model)

뷰-기반 접근제어모델(view-based access

control model(VACM))

사용자 보안 모델(user security model(USM))

에이전트(agent)

접근정책(access policy)

키 지역화(key localization)

프록시(proxy)

12.1 어떤 의미에서 네트워크 관리 구조가 통합되었다고 간주되는가?

12.2 SNMP 모델의 핵심 요소는 무엇인가?

12.3 MIB는 무엇인가?

12.4 SNMPv1에서 제공되는 기본 기능과 명령은 무엇인가?

12.5 SNMP 프록시의 기능은 무엇인가?

12.6 SNMPv1 공동체 개념을 간단히 설명하라.

12.7 SNMPv1, SNMPv2c, 그리고 SNMPv3 사이의 관계는 무엇인가?

12.8 어떤 위협에 응하기 위해 USM이 설계되었나?

12.9 주도적 엔진과 비주도적 엔진의 차이점은 무엇인가?

12.10키 지역화는 무엇인가?

12.11VACM에 포함되는 요소를 나열하고 간단히 설명하라.

12.1 SNMPv1은 게이지(gauge)라고 불리는 데이터 유형을 정의하고 이 유형의

의미에 한 다음과 같은 설명을 포함한다.

이 응용에 적용되는 유형은 음이 아닌 정수를 나타낸다. 이 정수는 증가하거

나 감소한다. 그러나 최댓값에서“latch”된다. 이 표준은 게이지에 해서

232 - 1(4294967295) 가 최댓값임을 나타낸다.

불행하게도 단어“latch”가 정의되지 않았고, 그래서 두 가지 해석이 가능하

게 되었다. SNMPv2 표준에서는 애매모호하지 않도록 다음과 같이 정의하

다.

게이지 값은 모델화되는 정보가 최댓값과 같거나 최댓값보다 크게 될 때마다

최댓값을 가진다. 만일 모델화되는 정보가 최댓값보다 상당히 작아지면 게이

지는 또한 감소한다.

a.또 다른 해석은 무엇인가?

연습문제

복습문제

616


b.이 두 가지 해석에 한 찬성과 반 에 해서 토론하라.

12.2 SNMPv1에서 MIB 안의 모든 객체는 MIB Access Category를 가지도록 정

의된다. 이곳에는 다음 중 하나의 값이 지정된다. read-only, read-write,

write-only, and not-accessible. read는 get이나 trap 동작으로 수행되

고, write는 set 동작으로 수행된다. write-only에 해서 객체가 get과

trap 동작에 이용될 수도 있지만 이것은 구현마다 다르다. MIB Access

Category는 객체에게 최 한 접근을 허락하는 것을 나타낸다. 그러나

SNMPv1 공동체 서비스에서는 Access Mode가 주어진 공동체 프로파일에

해 이 접근을 더 제한할 수도 있다. 다음 표에서 허락되는 접근을 나타내도

록 빈칸을 채워 넣으라.

12.3 다음 문제에 답하라.

a.RFC 2574는 비주도적 엔진에 해서 나가는 메시지 헤더 안의

msgAuthoritativeEngineBoots와 msgAuthoritativeEngineTime의

값이 설정되는 때는 오직 그 메시지가 주도적 수신자에 의해 인증될 경우

뿐이라고 하 다. 이렇게 제한을 하는 것이 타당한 이유는 무엇인가?

b.그러나 주도적 엔진으로부터 들어온 Response 메시지에 해서는 나가

는 메시지 헤더 안의 msgAuthoritativeEngineBoots와 msgAuthori

tativeEngineTime 값이 항상 설정된다. 왜 이것은 그렇게 되는가?

12.4 RFC 2574는 클록 동기화(들어오는 값을 기초로 해서 지역 클록을 갱신하는

것)가 시간 윈도우 확인(들어오는 메시지가 시간성을 가졌는지 검사하는 것)

이전에 이루어진다고 하 다. 이것이 의미하는 것은 설사 메시지가 시간 윈

도우 안에 있지 않더라도 비주도적 엔진은 수신된 메시지가 인증만 되면 자

신의 주도적 엔진 클록 notion을 갱신한다는 것이다. RFC가 출판된 이래로,

617


MIB Accesss

Category

SNMP Access Mode

READ-ONLY READ-WRITE

read-only

read-write

write-only

not-accessible

이 문제에 해서 SNMPv3 메일링 목록에 논란이 되고 있다. 그러나 이 책

을 쓰는 시점에서, 표준에 있는 내용은 고쳐질 것 같아 보이지 않는다. 이것

이 의미하는 바를 살펴보는 것은 유익하다. 다음 정의가 주어졌다.

MAEB = msgAuthoritativeEngineBoots

MAET = msgAuthoritativeEngineTime

SEB = 원격 주도적 엔진의 local notion of snmpEngineBoots

SET = 원격 주도적 엔진의 local notion of snmpEngineTime

LRET = latestReceivedEngineTime

이때 비주도적 엔진이 한 메시지를 수신했다고 가정하자. 그래서

(MAEB = SEB) = AND [LRET ＜ MAET ＜ (SET-150)]

다음에 조건이 클록 갱신을 하기에 올바르다. 그래서 다음이 수행된다.

SET := MAET; LRET := MAET

이제, 시간 윈도우를 검사할 때가 되었고 우리는 다음을 수행한다.

(MAEB = SEB) = AND (MAET = SET)

그래서 메시지는 시간성이 있다고 선언한다. 그러나 우리가 시간 윈도우를

먼저 검사했다고 가정하자. 이 경우에 메시지가 시간성이 있다고 선언할 수

있을지 시간성이 없다고 선언해야 할지 말해보라.

12.5 클록 동기화와 시간 윈도우 검사 절차를 다룬 원래 출판된 USM 명세에는

(RFC 2274) 다음과 같은 사항을 언급하고 있다. “이 절차는 만약 주도적

SNMP 엔진이 비주도적 SNMP 엔진보다 150초 이상 늦어서 비주도적

SNMP 엔진이 진짜로 동기화를 할 수 없는(out-of-sync) 상황이라면 자동

적 시간 동기화를 허락하지 않는다는 데 주의하라.”이 문구는 항상 사실이

아니라는 것을 저자가 작업그룹에게 지적한 뒤에 수정된 버전(RFC 2574)에

서 빠졌다. 문제 12.4의 예를 이용하여 이 문구가 항상 사실은 아니라는 것을

보이라.

12.6 SNMPv3는 인증된(에이전트) 시스템에 지역화된 키를 전달하는 안전한 방

법이 있다는 것을 전제로 하고 있다. 안전한 전달 문제는 SNMPv3에서 다룰

문제는 아니다. 전달은 직접 하거나 안전한 프로토콜을 이용해서 할 수 있다.

618


일단 초기 키(인증과 기 성을 위할 경우는 두 개의 키)가 에이전트에게 전달

되면, SNMPv3는 안전하게 키를 갱신하는 메커니즘을 제공한다. 보안을 강

화시키기 위해 키를 자주 바꾸는 것이 바람직하다. 사용자가 먼저 스스로 키

교환 처리를 시작할 수 있다. 그 방법은 새 패스워드를 요청하고 제공하는 식

으로 처리한다. 다른 방법으로는 네트워크 관리 시스템(NMS)에 의해 새 패

스워드를 요청하면서 시작될 수 있다. 두 경우에 NMS에 있는 사용자 키가

갱신된다. 그러면 NMS는 각 통신 에이전트를 위한 지역화 키를 계산할 수

있다. 다음에 NMS는 에이전트에게 자신의 지역화 키를 갱신하라고 안전하

게 통신을 해야만 한다. 분명히 NMS는 단순히 네트워크상으로 평문형태의

키를 보낼 수는 없다. 두 가지 옵션을 제시한다.

●이전 키를 암호화키로 사용하여 새 키를 암호화한다.

●이전 키에 일방향 함수 같은 것을 사용하여 값을 구한다. 이 값을 새 키와

XOR한 다음 그 결과를 에이전트에게 보낸다. 에이전트는 수신된 결과에

다 이전 키에 같은 일방향 함수를 적용해서 생긴 값을 XOR하여 새 키를

생성한다.

SNMPv3는 두 번째 방법의 변형된 방법을 사용한다. 첫 번째 방법보다 이

방법이 나은 점이 무엇인가?

12.7 SNMPv3 방법에서는 목표 시스템의 MIB에 속하는 KeyChange 객체를 사

용한다. 원격 주체 혹은 NMS는 이 객체를 설정하고 설정된 것은 자동적으

로 에이전트가 응되는 키를 갱신하는 데 사용된다. 알고리즘은 두 군데에

서 역할을 한다. 하나는 신청자 측 엔진에서 일어나는 것이고 다른 하나는 원

격 에이전트 엔진에서 일어난다.

신청자가 기존의 키인 keyOld를 새 키 keyNew로 갱신하고 싶을 때 이 처리

를 한다. 신청자는 다음 단계를 수행한다.

1.의사랜덤넘버 생성기나 랜덤넘버 생성기를 이용해서 한 값 random을 생

성한다.

2.다음을 계산한다.

digest = Hash(keyOld ‖ random)

여기서 Hash는 MD5나 SHA-1이고, 원하는 키가 16-옥텟 키냐 아니면

20-옥텟 키냐에 따라서 선택된다. 기호 ‖는 이어붙이기를 의미한다.

619


3.다음을 계산한다.

delta = digest � keyNew

protocolKeyChange = (random ‖ delta)

여기서 �은 XOR 연산이다.

4.값 protocolKeyChange를 Set 명령 안에 포함시켜 에이전트에게 보내고,

에이전트는 자신의 MIB 안의 객체 인스턴스 KeyChange를 갱신한다.

에이전트는 이 수신되는 값을 가지고 키를 갱신하기 위해서 무엇을 해야

만 하는가?

12.8 앞 문제에서 설명했던 방법보다 더 간단한 방법으로는 keyOld를 keyNew와

XOR한 뒤에 그 값을 전송하는 것이다. 수신자는 받은 값에 keyOld를 XOR

하여 keyNew를 생성한다. 공격자는 keyOld를 모르고 있기 때문에

keyNew를 구할 수 없다. 이 방법과 비교해서 문제 12.7의 랜덤넘버와 안전

한 일방향 해시함수를 사용하는 방법의 장점은 무엇인가?

620


Documents

PART 04 12 - lily.mmu.ac.krlily.mmu.ac.kr/lecture/16is/P4-CHAPTER12.pdf · chapter 12 snmp를사용해오고있다. snmp를널리사용하면서새로운요구사항을수용할 수있는새로운기능이필요하게되었다