요약

  • ARIN의 현재 데이터베이스 안내문은 Resource Tech POC를 특정 자원에 연결하지만, RPKI와 IRR 인증 정보에 대한 책임은 조직의 Routing POC에 배정한다.
  • 8월 20일에 제출된 ACSP 건의 2026.10은 ARIN에 해당 Resource Tech POC가 연결된 자원의 RPKI와 IRR을 관리할 수 있도록 해달라고 요청한다.
  • 해당 페이지에는Confirmed만 표시되어 있다. ARIN의 공표된 절차에 따르면 이는 접수가 직원 평가 전에 확인되었음을 의미할 뿐, 승인·구현 약속·제공 일정을 뜻하지 않는다.
  • 안전한 대응은 정확한 프리픽스 집합에 대해 정확한 작업 권한을 만료·철회·승인 규칙과 불변 행위 로그를 갖춰 위임하는 것이다. 자원 운영자에게 조직 전체의 라우팅 보안 권한을 주면 요청된 경계가 사라진다.

하나의 프리픽스, 두 개의 권한 지도

ARIN의 공개 데이터베이스 안내문은 정밀한 구분을 그린다. 조직 기술 POC(Organizational Tech POC)는 Org ID와 그 자원을 관리할 수 있다. Resource Tech POC는 선택 사항이며 대신 할당, 주소 블록 또는 ASN에 직접 연결될 수 있다. ARIN에 따르면 이 자원 수준 연락처는 자원 이름과 공개 코멘트 같은 속성을 변경하고, 다른 자원 POC를 연결하며, 자원의 종류에 따라 네임서버나 DS 레코드를 지정할 수 있다.

Routing POC는 다르게 기술된다. 이 역할은 “조직 단위로” 인터넷 라우팅 레지스트리(IRR)와 RPKI 인증 정보에 대한 책임을 진다. 배치가 중요하다. 한 역할은 자원을 따라가고, 다른 역할은 조직 컨테이너를 따라간다.

ARIN의 운영 인터페이스는 두 번째 지도를 반영한다. 호스티드 RPKI 안내는 사용자에게 조직 단위로Manage RPKI를 선택하라고 말한다. ROA를 생성·삭제하는 REST 트랜잭션은/rest/rpki/ORGHANDLE로 향한다. 동일 트랜잭션은 여러 ROA 변경을 담을 수 있고 ASPA 변경과 원자적으로 결합될 수 있다. ARIN의 IRR API 역시 조직을 유지보수자로 기술하며 그 유지보수 조직의 Admin, Tech 또는 Routing POC를 나열한다.

이 자체가 결함은 아니다. 조직 수준 통제는 책임 소재를 명확히 하고, 좁게 연결된 연락처가 무관한 경로를 변경하는 것을 막으며, 직접 자원 보유자에게 하나의 일관된 보안 경계를 줄 수 있다. 그러나 조직이 자원 단위로 일상 업무를 위임할 때 두 지도는 일치하지 않는다.

그것이 ACSP 건의 2026.10이 지적한 간극이다.

ARIN이 실제로 확인한 것

이 건의는 2026년 8월 20일 Nathanael Jean-Francois가 제출했다. 연결된 자원에 대해 Resource Tech POC가 RPKI와 IRR을 관리할 수 있도록 ARIN에 요청한다. 제출자는 특정 자원에 가장 가까운 직원이 현재 조직 수준 Routing POC를 거치지 않고는 관련 ROA를 생성·삭제할 수 없다고 말한다. 제출문에서 이 추가 인계는 인시던트 복구와 신규 서비스 프로비저닝을 지연시키는 것으로 서술된다.

이 지연 주장은 요청의 일부이지 ARIN이 발표한 조사 결과가 아니다. 페이지에는 인시던트 사례, 소요 시간 분포, 영향받은 프리픽스 수, 독립 측정치가 없다. “추적 정보(Tracking Information)” 아래 직원 응답도 없다. 상태는 제출일에 갱신된Confirmed이며 처리 기한은 “미지정”이다.

ARIN의 협의·건의 절차(ACSP)는 이 구분이 왜 중요한지 설명한다. 직원은 유효한 건의의 접수를 즉시 확인한다. 그런 뒤 10영업일 내에 평가한다. 이후 응답에서 요청을 반려·종결하거나, 이사회 또는 자문위원회에 회부하거나, 구현 가능하다고 판단하거나, 협의를 열 수 있다. 따라서 이 확인만으로는 요청이 절차에 들어갔다는 사실만 증명된다. ARIN이 그 전제에 동의하거나, 권한 모델을 선택했거나, 기능을 만들 것이라는 증거는 아니다.

이것은 단순한 절차적 주의를 넘는다. 확인을 승인으로 다루면 대기열 상태가 정책처럼 작동하게 되고, 실제로 존재하지 않는 권한을 사용자가 가정하도록 부추길 수 있다.

위험한 지름길은 조직 전체 접근권이다

가장 명백한 구현이 가장 위험한 구현이다. 어떤 사람이 한 Org ID 아래 어디에서든 Resource Tech POC라면, 그 사람에게 조직의 Routing POC와 동일한 라우팅 보안 권한을 주는 것이다. 이는 인계를 줄이는 대신 영향 반경을 넓힌다.

또한 ARIN 기록에 이미 있는 정보를 버리게 된다. Resource Tech 연결은 특정 연락처가 특정 자원과 관계를 맺고 있음을 나타낸다. 그 연락처가 조직의 다른 모든 프리픽스에 대해 ROA를 만들거나 제거하고, 무관한 ASN의 ASPA를 바꾸고, IRR Auto-Manager 전역 설정을 변경하고, 같은 Org ID를 공유하는 모든 사업부를 대신할 수 있음을 나타내지는 않는다.

이 요청의 가치는 더 좁은 연결을 요구한다는 데 있다. 자원을 관리하는 직원이 그 자원에 대해 선별된 라우팅 보안 작업을 수행할 수 있어야 한다는 것이다. 시스템은 “선별된”과 “그 자원”을 계정 페이지의 문구가 아니라 강제 가능한 제약으로 유지해야 한다.

반대 방향의 지름길도 약하다. 모든 변경을 하나의 조직 역할로 강제하면 중앙 통제는 유지되지만, 레지스트리 연락처 그래프를 운영 병목으로 만들 수 있다. 부실한 Routing POC, 시간대 경계, 사업부 행정과 네트워크 운영의 분리가 지연을 더할 수 있다. 자료는 이 빈도를 측정하지 않지만 가능한 인계 구조는 보여준다.

권한은 조직보다 작아야 한다

ARIN은 이 건의를 권한 설계 문제로 평가할 수 있다. 유용한 공개 산출물은 어느 직원이 어느 프리픽스를 다루는지 목록이 아니라, 문서화된 권한 모델과 그 성능에 대한 개인정보에 안전한 집계 보고다.

각 위임 권한은 최소 여덟 필드를 묶을 수 있다:

  1. 적용 대상이 되는 정확한 NET 핸들 또는 프리픽스 범위;
  2. 허용되는 작업 유형, ROA·ASPA·IRR 작업별로 분리;
  3. 권한을 부여한 POC 또는 승인된 조직 역할;
  4. 유효 시각과 선택적 만료;
  5. 생성·수정·삭제가 독립 권한인지 여부;
  6. 고영향 작업 중 이중 승인이 필요한 항목;
  7. 철회와 긴급 동결 경로;
  8. 인증된 행위자, 권한 출처, 변경 전후 객체 핸들, 결과를 명시하는 불변 행위 기록.

ARIN은 이미 시각, 작업, 출처, 오리진 AS, 프리픽스, 최대 길이, 변경한 사용자를 담은 ROA 변경 로그를 노출한다. 자원 범위 모델에는 권한 경로가 추가되어야 한다. 누가 클릭했는지뿐 아니라, 어떤 유효한 위임이 그 정확한 자원에 대한 그 정확한 작업을 허용했는지가 기록되어야 한다.

이 모델은 경계 누출도 거부해야 한다. 위임받은 사용자는 하위 프리픽스가 범위에 있다는 이유만으로 상위 할당에 접근해서는 안 된다. Resource Tech 연결을 제거하면 파생 권한이 즉시 철회되어야 한다. 자원이 조직 간에 이동하면 기존 부여가 무효화되어야 한다. API 키는 생성한 계정 이상의 권한을 상속해서는 안 되며, 대량 트랜잭션은 요청된 객체가 허용 집합을 벗어나면 원자적으로 실패해야 한다.

이 요구사항들은 건의의 찬반 논거가 아니라, 구현이 최소 권한을 보존하는지 아는 데 필요한 근거를 설명한다.

기록이 뒷받침할 수 없는 것

현재 자료는 ARIN이 라우팅 인시던트를 일으켰거나, 유효한 출시를 막았거나, 알려진 잘못된 ROA를 방치했다는 것을 보여주지 않는다. Resource Tech POC 수, 영향받은 조직 수, 지연된 작업 수도 세지 않았다. 모든 자원 수준 연락처가 라우팅 보안 권한을 받아야 하며 모든 조직에서 단독 삭제가 적절하다는 것도 증명하지 않는다.

공개 POC 표기가 그 뒤에 있는 현재 인물이 인증된 권한을 갖고 있음을 증명하지도 않는다. ARIN Online 계정 연계, 조직 승인, 협약 적용 범위, RPKI 자격, 자원 인증서 상태가 여전히 중요하다. Whois/RDAP의 역할은 권한 그래프의 일부일 뿐 그래프 전체가 아니다.

뉴스의 범위는 더 좁다. ARIN은 자사 문서화된 모델의 실질적 불일치를 노출하는 요청을 기록했다. 자원별 기술 권한은 존재하지만 RPKI와 IRR 책임은 조직 수준으로 표현된다는 것이다. 다음으로 방어 가능한 상태는 응답 속도와 범위 통제를 모두 보존하는 평가이며, 운영자가 무엇이 희생되었는지 판단할 수 있도록 설계를 충분히 공개하는 것이다.

출처