요약

  • SNMPv3에서contextEngineID와contextName은 관리 정보의 집합을 찾아가는 역할을 하고,securityName은 주체(principal)를 나타내며, VACM은 별도로 그 주체가 어떤 객체를 읽거나 쓰거나 알림으로 노출할 수 있는지 결정한다.
  • 방어 가능한 관리 기록은 프로토콜 신원, 컨텍스트, 접근 뷰와 응답을 외부의 변경 승인 주체 기록, 그리고 의도한 운영 상태가 실제로 이어졌다는 증거와 결합해야 한다.

두 장치가 동일한 객체 식별자를 노출할 수 있다. 하나의 물리적 장치가 여러 관리 컨텍스트에서 같은 객체를 노출할 수도 있다. 프록시는 실제로 다른 곳에 있는 정보에 대한 요청을 받아들일 수 있다. 대시보드가 이 세 가지 경우를 모두 “SNMP 대상”으로 축소하면, 유효한 응답이 잘못된 자산에 귀속될 수 있고, 인증된 요청이 특정 운영자의 승인을 증명하는 것으로 오해될 수 있다.

RFC 3411은 2002년 12월 STD 62의 일부로 Standards Track에 발표되었다. David Harrington이 Randy Presuhn, Bert Wijnen과 함께 집필했다. 이 공통 아키텍처는 그 모호성에 규율 있는 답을 제공한다. 엔진, 주체, 컨텍스트, 보안 처리, 접근 제어에 서로 다른 이름을 붙인 이유는 그들이 서로 다른 주장을 하기 때문이다.

엔진은 주체가 아니다

SNMP 엔진은 메시지를 주고받고, 프로토콜 버전을 처리하고, 보안을 적용하고, 접근 제어를 호출한다. 하나의 관리 도메인 안에서snmpEngineID는 그 엔진과 연관된 SNMP 엔티티를 고유하게 식별한다. 범위가 중요하다. 같은 값이 서로 다른 관리 도메인에 존재할 수 있으므로, 이 식별자는 장치 소유권이나 조직 신원의 전역 인증서가 아니다.

주체(principal)는 서비스가 제공되는 대상이 되는 엔티티다. RFC 3411은 그 주체를securityName으로 표현하며, 이는 특정 보안 모델과 독립적인 사람이 읽을 수 있는 문자열이다. 보안 모델은 자신의 식별자—사용자 이름이거나 모델 고유의 다른 값일 수 있다—를 그 공유 이름으로 변환한다. “사람이 읽을 수 있다”는 것이 “사람”이라는 뜻은 아니다. 서비스 계정, 역할, 공유 관리 신원이 그 필드를 차지할 수 있고, 프로토콜은 누가 키보드 앞에 있었는지 증명하지 않는다.

이것이 첫 번째 증거 경계다.snmpEngineID는 도메인 내에서 어느 프로토콜 엔진이 개입했는지 답한다.securityName은 보안 모델이 어떤 주체를 제시했는지 답한다. 어느 필드도, 둘을 합쳐도, 고용 기록이나 변경 티켓, 경영진의 위임, 어떤 사람의 동시적 의도에 대한 증거를 제공하지 않는다.

컨텍스트는 관리 정보의 이름이다

SNMP 컨텍스트는 SNMP 엔티티를 통해 접근 가능한 관리 정보의 집합이다. RFC 3411은 컨텍스트가 여러 장치를 포괄하거나, 하나의 장치의 일부이거나, 여러 장치의 일부를 포괄할 수 있도록 허용하면서도 이를 하나의 SNMP 엔티티의 부분집합으로 정의한다. 특정 정보 항목을 식별하려면 아키텍처는 네 가지 좌표가 필요하다.contextEngineID,contextName, 객체 유형, 객체 인스턴스다.

contextEngineID와contextName의 쌍은 관리 도메인 안에서 컨텍스트를 모호하지 않게 식별한다. 그러나 표준은 여러 개의 그런 쌍이 동일한 컨텍스트를 식별하는 것도 허용한다. 따라서 컨텍스트 명명에는 별칭이 존재할 수 있다. 컨텍스트 이름은 관리 정보 집합을 위한 프로토콜 위치 지정자이지, 보편적인 자산 일련 번호도, 그 자산의 책임자 신원도 아니다.

이 구분은scopedPDU에 직접 나타난다.scopedPDU는 컨텍스트 엔진 식별자, 컨텍스트 이름, PDU를 담는다. 이 스코프는 수신 아키텍처에 요청된 정보가 어디에 속하는지 알려 준다. 별도의 보안 입력은 그 작업이 누구 명의로 도착했는지 알려 준다. 컨텍스트를 운영자 신원으로 취급하면 인가가 실행되기도 전에 “어디서”가 “누가”로 붕괴된다.

인증은 뷰 결정 이전에서 멈춘다

RFC 3414는 SNMPv3의 사용자 기반 보안 모델(User-based Security Model)을 정의한다. 이는 메시지 인증, 기밀성, 시효성 및 제한된 재전송 방지를 다룬다. 이 속성들은 중요하다. 너무 오래되었거나, 전송 중 변경되었거나, 회선상 노출된 인증된 메시지는 새로 보호된 요청과 동등하지 않다.

그러나 보안 처리는 관리 뷰를 선택하지 않는다. 보안 처리는 아키텍처의 나머지 부분이 사용할 수 있는 보안 모델, 주체 표현, 달성된 보안 수준을 산출할 뿐이다. 성공한 인증은 구성된 키 하에서 유한한 메시지 속성을 증명할 뿐, 그 주체가 이 컨텍스트에서 이 객체에 대해 이 작업을 수행할 수 있다는 말은 하지 않는다.

RFC 3415는 그 이후의 질문을 뷰 기반 접근 제어 모델(View-based Access Control Model)에 맡긴다. VACM은securityModel과securityName의 쌍을 그룹에 매핑한다. VACM은 보안 이름이 이미 필요한 만큼 인증되었다고 명시적으로 가정하며, 자체적으로 추가 인증을 수행하지 않는다. 인증은 결정의 입력이지 결정 자체가 아니다.

VACM은 이어서 보안 수준, 컨텍스트, 뷰 유형을 고려한다. 읽기, 쓰기, 알림(notify) 뷰는 서로 다르다. 인터페이스 카운터를 관찰할 수 있는 주체가 곧 인터페이스 상태를 변경할 수 있는 것은 아니고, 한 서브트리에 쓰기가 허용된 주체가 모든 알림을 받을 자격을 얻는 것도 아니다. 객체 식별자는 접근 검사의 일부로 남는다.

isAccessAllowed서비스가 이 수신을 구체화한다. 그 입력에는securityModel,securityName,securityLevel,viewType,contextName,variableName이 포함된다. 그 결과는 접근 허용과noSuchContext나notInView같은 조건을 구분한다. “인증됨”만 기록하면, 겉보기에 유효한 주체가 거부된 이유를 설명하는 바로 그 필드들이 지워진다.

프록시는 체인을 길게 한다

RFC 3413은 SNMP 애플리케이션을 정의하며, 그중 선택적 프록시 포워더(Proxy Forwarder)가 있다. 프록시는 특정contextEngineID와contextName쌍에 대한 요청이나 알림을 다른 SNMP 엔티티로 전달할 수 있다. 전송 연결을 받는 엔진이 관리 정보가 실제로 존재하는 곳일 필요는 없다.

이 간접 계층은 유용하지만 출처(provenance)를 추가한다. 유용한 기록은 들어오는 전송 피어, 변환된 보안 주체, 들어오는 컨텍스트 쌍, 매칭된 프록시 규칙, 아웃바운드 목적지와 컨텍스트 매핑, 응답 상관관계, 어느 쪽 다리에서든 반환된 오류를 식별한다. 프록시로부터의 응답은 이름 없는 어떤 사람이 다운스트림 장치를 직접 조작했다는 증거가 아니다.

프록시는 또한 컨텍스트가 자산 소유권을 대신할 수 없는 이유를 보여 준다. 프록시의 임무는 프로토콜 스코프를 매핑하고 전달하는 것이다. 프록시를 운영하는 조직, 관리 대상 장치의 소유자, 그 변경 권한을 가진 팀, 이 요청을 시작한 개인은 모두 다른 당사자일 수 있다.

디스커버리는 소유자가 아니라 식별자를 찾는다

RFC 5343은 적절한 컨텍스트 엔진 식별자를 찾아내는 메커니즘으로 아키텍처를 갱신한다. 잘 알려진 로컬 값을 도입하고, 아직 알려지지 않은 경우 애플리케이션이 스코프드 요청에 넣을 엔진 식별자를 학습할 수 있는 절차를 제공한다.

디스커버리 결과는 운영적으로 가치가 있다. 프로토콜 주소 지정 문제를 해결한다. 그러나 이는 발견된 엔진이 사람이 의도한 자산을 나타낸다는 것, 그 자산이 주장된 조직에 속한다는 것, 요청 주체가 그 결과 컨텍스트를 사용할 자격이 있다는 것을 확립하지 않는다. 디스커버리와 인가는 별개의 영수증으로 남는다.

이 분리는 흔한 분석 오류도 막는다. 엔진 식별자의 변화는 재구성, 교체, 상태 복원 또는 다른 경로를 나타낼 수 있으며, 그것이 자동적으로 적대적 탈취의 증거는 아니다. 반대로 식별자가 변하지 않았다고 해서 소유권, 소프트웨어, 정책, 접근을 통제하는 사람들이 그대로였다는 증거도 되지 않는다.

성공한 응답은 최종 상태가 아니다

읽기의 경우, SNMP 응답은 특정 시점에 명명된 컨텍스트의 객체에 대해 에이전트가 어떤 값을 반환했는지 확립할 수 있다. 그러나 추가 증거 없이는 원본 센서가 얼마나 최신인지, 그 값이 물리적 현실과 일치하는지 확립하지 않는다. 쓰기의 경우, 성공한 응답은 프로토콜 수용을 확립할 수 있다. 액추에이터가 움직였는지, 설정이 유지되었는지, 의존 시스템이 수렴했는지, 이후 프로세스가 변경을 되돌리지 않았는지는 증명하지 않는다.

따라서 완전한 영수증은 두 시스템에 걸친다. SNMP 쪽은 엔드포인트, 메시지 처리 모델, 보안 모델, 원래 보안 식별자,securityName, 달성된 보안 수준, 컨텍스트 쌍, 객체와 인스턴스, 요청된 읽기/쓰기/알림 뷰, VACM 그룹과 뷰 매칭, 프록시 매핑, 응답을 기록한다. 거버넌스 쪽은 누가 변경을 승인했는지, 허용된 시간 창, 의도된 결과, 롤백 조건, 이후 관찰된 상태의 증거를 기록한다.

David Harrington의 아키텍처적 기여는 이런 기록이 모든 배포에 이미 존재한다는 약속이 아니다. 그것은 한 필드가 다른 필드를 사칭하지 못하게 하는 어휘다. 컨텍스트는 정보를 찾아간다. 보안 이름은 주체를 나타낸다. 뷰는 프로토콜 접근을 결정한다. 사람의 권한과 운영상 결과는 여전히 자체적인 증거를 필요로 한다.

출처