요약

  • 10월 27일자 IETF 개인 초안은 영역, 소유자, 작성자, 언어, 정책 본문을 배포 객체의 필수 항목으로 둔다. 수신 측이 그 소유자에게 해당 영역의 규칙을 바꿀 권한이 있는지 확인하는 절차에는 MAY를 쓴다.
  • 서명 확인은 물건의 출처를 가린다. 다른 관리 주체의 네트워크에 규칙을 설치할 권한은 수신 기관의 위임 기록으로 판단해야 하며, 그 판단은 설치한 정확한 판본과 함께 남아야 한다.

소포의 봉인은 진짜다. 출입증은 누가 발급했나

서로 다른 관리 영역을 지나 정책 하나가 도착한다. YANG 형식은 맞고 서명도 통과했다. owner 칸에는 그럴듯한 기관의 URI가 들어 있다. 자동화 시스템은 실행 엔진에 넘기기만 하면 된다고 말할 것이다. 그러나 수신 네트워크가 물어야 할 질문은 포장 상태가 아니다. 그 기관이 이 영역의 규칙을 정하도록 누가 허락했는가.

분산 정책 공유 모델이라는 10월 27일자 개인 초안은 이동 중인 단일 정책 객체를 위한 YANG 틀을 제안한다. area, language, policy-content, owner, author는 필수다. 예시 모델에서 origin과 출처 서명은 선택 항목이다. 규칙 내용은 이 틀에서 불투명하게 취급된다. Rego 정책과 네트워크 보안 정책이 같은 운송 형식을 쓸 수 있어도, 각각의 실행 의미는 목적지 환경이 결정한다.

이 구조는 언어가 다른 정책을 한 경로로 보낼 수 있게 한다. 동시에 owner라는 입력값을 권한으로 착각하기 쉬운 화면을 만든다. 소유자와 작성자 이름을 적은 쪽은 발송인이다. 수신 측의 위임을 적은 쪽이 아니다. YANG 데이터 출처에 관한 별도 초안이 제안하는 서명은 검증된 키와 내용의 무결성을 연결할 수 있다. 그 키가 수신 영역의 정책을 고칠 수 있는지는 수신 기관의 권한표에서 다시 찾아야 한다.

그림 속 검문소와 본문 속 선택권

초안 6.1절은 정책 관리 지점 PAP에 형식 검사와 수명주기 관리를 맡긴다. PAP는 정책을 받아들이거나 배포하기 전에 정책 결정 지점 PDP에 질의해, 선언된 소유자 또는 제출자가 대상 영역의 정책을 만들거나 바꿀 권한이 있는지 확인할 수 있다. 원문의 동사는 MAY다. 그런데 6.2절 그림에는 ‘Governance Authorization Check’가 PAP 한가운데 뚜렷이 자리한다. 그림만 보면 검문소가 항상 열려 있는 듯하다. 운영 규칙으로 만들지 않으면 그림은 안내판일 뿐이다.

누가 그 검문소를 운영할지는 지역 위임 체계에 달려 있다. 수신 기관은 영역별로 권한을 준 주체, 위임받은 사람이나 시스템, 유효 기간, 갱신과 철회 절차를 정해야 한다. 정책을 실행하는 PDP가 나중에 요청을 정확히 평가해도, 최초 설치 결정을 대신 설명해 주지는 못한다. 기술적으로 올바르게 작동한 규칙이 제도적으로 잘못 들어올 수 있다.

초안 작성자는 NMOP 메일링리스트에서 다음 해커톤에 계획한 양쪽 도메인 시연을 설명했다. 한쪽은 OPA 기반 PDP에서 Rego를 평가하고, 다른 쪽은 RFC 9061을 바탕으로 특정 노드 사이에 IPsec 터널을 만들 정책을 받는다. 두 체계가 모두 명령을 이해하면 이질적 정책의 배포는 보일 것이다. 각 관리자가 설치를 승인한 근거, 승인 취소 뒤의 동작은 별도의 증거가 필요하다. 메일에는 계획이 있으며 완료된 시연 결과는 없다.

IETF Datatracker는 이를 I-D Exists 상태의 활성 개인 초안으로 표시한다. 초안이 직접 짚는 위험은 구체적이다. 여러 관리 영역에서 발신처를 알아도, 그 발신처가 수신 영역의 정책을 정할 자격을 가졌는지는 모를 수 있다.

접수 대장에 빠지면 안 되는 한 줄

초안은 특정 배포 프로토콜을 강제하지 않는다. PAP가 옛 판본을 외부 버전 관리에 남기거나 생성·수정·활성화·되돌리기·삭제 이력을 추가식 장부에 적는 것도 MAY다. 수신자가 실질적인 기록을 원한다면 정확한 판본의 해시, 서명 키, 선언된 소유자, 현지에서 인정한 위임, 대상 area, 승인 또는 거절 결정, 설치 대상, 철회 명령을 한 사건으로 묶어야 한다. 소포 도착 시간만 적은 장부는 왜 문을 열었는지 말해 주지 못한다.

RFC 2904는 권한 부여 기능을 나누어 보는 토대를 제공한다. 그 토대 위에서 자신의 네트워크에 실제로 서명할 사람을 정하는 책임은 수신 기관에 남는다. 발송인이 작성한 소유자 칸을 그 기관의 위임장으로 받아들일 수는 없다.

출처