본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
고객은 IP 주소 공간을 Cloudflare로 가져오려고 할 때 항상 계정 팀에 연락하여 요청해야 했습니다. 이 요청은 주소 지정 및 네트워크 엔지니어링 등 다양한 Cloudflare 엔지니어링 팀으로 전송되고, 접두사를 사용하려는 특정 서비스(예: CDN, Magic Transit, Spectrum, Egress)를 담당하는 팀으로 전송됩니다. 또한 여러 차례의 승인을 통해 기관장(LOA)을 발행하기 위해 IP 접두사에 대한 주요 소유권이 없는 경우 자체 법무팀 및 잠재적으로 다른 조직과 협력해야 했습니다. 이 프로세스는 복잡하고 수작업을 많이 해야 하며 모든 관련 당사자들에게 시간이 많이 소요되며, 여러 승인 절차에 따라 최대 4~6주가 소요되는 경우도 있습니다.
이제 더 이상은 아닙니다! 오늘 Cloudflare는 고객이 직접 온보딩하고 설정할 수 있는 셀프 서비스 BYOIP API를 출시하게 되어 기쁘게 생각합니다.
셀프 서비스를 통해, Cloudflare가 관료적 형식주의를 대신 처리해 드립니다. Cloudflare에서는 라우팅 보안의 가장 바람직한 표준인 리소스 공개 키 인프라(RPKI)를 사용하여 이 프로세스를 자동화했습니다. 그러는 동안에도 Cloudflare는 새로운 소유권 검증 프로세스의 보안 보장을 기반으로 고객을 대신하여 LOA를 생성함으로써 최고의 서비스 품질을 보장하기 위해 노력하고 있습니다. 따라서 인터넷의 모든 구석에서 고객 경로가 지속적으로 수용됩니다.
Cloudflare에서는 인터넷 전체의 보안과 안정성을 매우 중요하게 생각합니다. RPKI는 암호학적으로 강력한 인증 메커니즘으로, 사람이 스캔한 문서를 검토하는 것에 의존하는 일반적인 방식보다 훨씬 더 신뢰할 수 있다고 생각합니다. 하지만 AS 경로 인증(ASPA) 개체 등 RPKI 서명 아티팩트의 배포 및 가용성은 여전히 제한적입니다. 따라서, 당사에서는 Cloudflare의 자율 시스템 번호(ASN)에서 시작된 BYOIP 접두사로 셀프 서비스 온보딩의 초기 범위를 제한하고 있습니다. AS 13335. 이렇게 하면 널리 사용 가능한 라우팅 시작점 인증(ROA) 개체 게시에 의존하기만 하면 됩니다. 이러한 접근 방식은 인터넷에 안전하고 대부분의 BYOIP 고객의 요구 사항을 충족한다는 장점이 있습니다.
오늘 Cloudflare는 큰 진전을 이루며 고객에게 더욱 포괄적인 IP 주소 관리(IPAM) 플랫폼을 제공합니다. 최근 단일 BYOIP 접두사에서 여러 서비스를 사용할 수 있도록 하는 것과 Cloudflare API를 통해 셀프 서비스 온보딩을 할 수 있게 하는 이번 발전을 통해 고객이 Cloudflare 네트워크에서 자신의 IP를 직접 제어할 수 있기를 바랍니다.
우리는 Cloudflare가 인프라의 확장처럼 느껴지기를 원하며, 그래서 2020년에 BYOIP(Bring-Your-Own-IP)를 출시했습니다.
간단히 되새겨보자면, Bring-your-own-IP는 고객이 자체 IP 공간을 Cloudflare로 가져올 수 있는 기능의 이름을 따서 명명되었습니다. 고객이 BYOIP를 선택하는 이유는 여러 가지가 있지만, 그 주된 이유는 제어 능력과 구성 가능성입니다. IP 접두사는 IP 주소의 범위 또는 블록입니다. 라우터는 라우팅 테이블이라고 하는 연결 가능한 접두사 테이블을 생성하여 패킷이 인터넷을 통해 올바르게 전달되도록 합니다. 고객의 Cloudflare 서비스가 고객 자신의 주소를 사용하여 구성되어 Cloudflare에 BYOIP로 온보딩되면 해당 목적지 주소가 있는 패킷이 인터넷을 통해 Cloudflare의 글로벌 에지 네트워크로 라우팅되며, 여기에서 해당 패킷을 수신하고 처리합니다. BYOIP는 Cloudflare의 애플리케이션 계층 서비스, Spectrum 또는 Magic Transit과 함께 사용할 수 있습니다.
한 걸음 물러서서 지금 BYOIP 세계가 어떤 상황인지 살펴보겠습니다. 어떤 고객이 다양한 IP 주소에 대한 권한이 있는데 이 주소를 Cloudflare로 가져오고 싶다고 가정해 보겠습니다. Cloudflare는 고객은 승인서(LOA)를 제공하고 접두사 및 자율 시스템 번호와 일치하는 Internet Routing Registry(IRR) 레코드를 보유할 것을 요구합니다. 요청을 받으면 Cloudflare 엔지니어가 수동으로 검토해야 합니다. 이 프로세스에는 몇 가지 문제가 있습니다.
안전하지 않음: LOA는 종이 조각에 불과합니다. 이 방법의 보안은 전적으로 문서를 검토하는 엔지니어의 부지런함에 달려 있습니다. 검토 시 문서가 사기성이거나 부정확한지 감지할 수 없는 경우, 접두사 또는 자율 시스템 번호가 하이재킹될 수 있습니다.
시간 소모: 단일 LOA를 생성하는 것만으로는 항상 충분하지 않습니다. IP 공간을 임대하는 경우, 원래 주소가 귀하에게 할당되거나 할당된 과정을 명확하게 확인할 수 있도록 해당 관계를 확인하는 문서도 요청해야 합니다. 모든 종이 문서를 통해 소유권 체인을 확인하는 상황과 수동 검토를 기다려야 하는 상황까지, 접두사를 배포하는 데 몇 주나 기다려야 할 수도 있습니다!
신뢰 자동화: Cloudflare에서 BYOIP 접두사 소유권을 몇 분 만에 확인하는 방법
셀프 서비스 모델로 전환하면서 접두사 소유권 확인을 수행하는 방식을 재고할 수 있게 되었습니다. 우리는 다음과 같이 자문했습니다. 귀하가 IP 접두사를 사용할 권한이 있으며 Cloudflare를 통해 IP를 라우팅할 의사가 있음을 빠르고 안전하며 자동으로 증명할 수 있을까요?
우리는 RPKI ROA(의도 검증)와 IRR 또는 rDNS 레코드 수정(소유 확인)을 포함하는 2단계 프로세스 덕분에 한 번의 결정으로 새 두 마리를 죽이는 결과에 이르렀습니다. 셀프 서비스를 사용하면 사람의 개입 없이 접두사를 더 빠르게 온보딩할 수 있을 뿐만 아니라 간단한 스캔 문서보다 더 엄격한 소유권 확인을 수행할 수 있습니다. 100% 완벽하지는 않지만, 소유권이 확인되는 방식이 크게 개선되었습니다.
지역 인터넷 레지스트리(RIR)는 IP 주소와 같은 인터넷 번호 리소스의 배포 및 관리를 담당하는 조직입니다. 전 세계 각기 다른 지역에서 운영되는 5개의 각기 다른 주체(RIR)로 구성됩니다. 원래 인터넷 할당 번호 관리 기관(IANA)에서 주소 공간을 할당받았지만, 그들은 해당 IP 공간을 인터넷 서비스 공급자와 같은 로컬 인터넷 레지스트리(LIR)에 할당합니다.
이 프로세스는 일반적으로 법적 문서, 기존 데이터베이스/레지스트리 기록, 기술 연락처, BGP 정보 등을 검토하는 RIR 정책을 기반으로 합니다. 최종 사용자는 LIR에서 주소를 가져오거나 경우에 따라 RIR을 통해 직접 주소를 가져올 수 있습니다. IPv4 주소가 점점 부족해지면서 중개 서비스가 시작되어 원래 수취인으로부터 일정 기간 동안 주소를 임대할 수 있게 되었습니다.
Internet Routing Registry(IRR)는 주소 할당보다는 라우팅에 중점을 둔 별도의 시스템입니다. 많은 조직에서 IRR 인스턴스를 운영하며 5개 RIR을 모두 포함하여 라우팅 정보를 게시할 수 있도록 허용합니다. 대부분의 IRR 인스턴스는 라우팅 데이터를 게시할 때 장벽이 거의 생기지 않지만, RIR에서 운영하는 IRR 인스턴스는 라우팅 정보를 게시하는 기능을 해당 주소가 할당된 조직에 연결할 수 있습니다. 이러한 방식으로 보호되는 IRR 레코드를 수정할 수 있는 것은 사용자에게 접두사를 사용할 권한이 있다는 좋은 신호가 될 수 있다고 생각합니다.
유효성 검사 토큰이 포함된 경로 개체의 예(문서 전용 주소 192.0.2.0/24 사용):
% whois -h rr.arin.net 192.0.2.0/24
route: 192.0.2.0/24
origin: AS13335
descr: Example Company, Inc.
cf-validation: 9477b6c3-4344-4ceb-85c4-6463e7d2453f
admin-c: ADMIN2521-ARIN
tech-c: ADMIN2521-ARIN
tech-c: CLOUD146-ARIN
mnt-by: MNT-CLOUD14
created: 2025-07-29T10:52:27Z
last-modified: 2025-07-29T10:52:27Z
source: ARIN
IRR 기반 유효성 검사 프로세스를 원하지 않는 고객을 위해 또 다른 안전한 확인 방법으로 역방향 DNS(rDNS)가 제공됩니다. 접두사에 대한 rDNS를 관리하려면 PTR 레코드를 만들든 보안 TXT 레코드를 만들든 애초에 IP 차단을 할당한 주체(일반적으로 인터넷 서비스 공급자 또는 RIR)의 권한을 부여받아야 합니다.
이 권한은 다음 두 가지 방법 중 하나로 표시됩니다.
dig 명령을 사용하는 리버스 도메인 조회 예(문서 전용 주소 192.0.2.0/24 사용):
% dig cf-validation.2.0.192.in-addr.arpa TXT
; <<>> DiG 9.10.6 <<>> cf-validation.2.0.192.in-addr.arpa TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16686
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cf-validation.2.0.192.in-addr.arpa. IN TXT
;; ANSWER SECTION:
cf-validation.2.0.192.in-addr.arpa. 300 IN TXT "b2f8af96-d32d-4c46-a886-f97d925d7977"
;; Query time: 35 msec
;; SERVER: 127.0.2.2#53(127.0.2.2)
;; WHEN: Fri Oct 24 10:43:52 EDT 2025
;; MSG SIZE rcvd: 150
그렇다면 이러한 레코드를 정확히 어떻게 수정해야 할까요? 이때 유효성 검사 토큰이 필요합니다. IRR 또는 역방향 DNS 방법을 선택하면 Cloudflare에서 고유한 일회용 유효성 검사 토큰을 제공합니다. 이 토큰을 IRR 또는 DNS의 관련 레코드 내용에 추가해야 합니다. 그런 다음 Cloudflare 시스템은 요청된 내용을 수정할 권한을 가진 사람이 요청을 수행했다는 증거로 토큰이 있는지 찾습니다. 토큰이 있으면 인증이 완료된 것입니다!
소유권은 전쟁의 절반에 불과합니다. 또한, Cloudflare가 귀사의 접두사를 광고할 수 있도록 승인한다는 의사 확인도 필요합니다. 이를 위해 Cloudflare는 라우팅 보안의 황금 표준인 리소스 개인 키 인프라(RPKI), 특히 라우팅 시작점 인증(ROA) 개체를 사용합니다.
ROA는 암호로 서명된 문서로서, IP 접두사를 생성할 권한이 있는 자율 시스템 번호(ASN)를 지정합니다. ROA는 접두사 소유자가 계약을 인증하고, 서명하고, 공증한 것과 같은 디지털 방식으로 생각하면 됩니다.
신뢰 당사자는 RPKI를 사용하여 ROA의 서명을 검증할 수 있습니다. Cloudflare의 자율 시스템 번호(AS13335)를 승인된 작성자로 지정하는 ROA를 생성하고 서명을 주선하기만 하면 됩니다. 이를 위해 많은 고객이 RIR 포털을 통해 제공되는 호스팅된 RPKI 시스템을 사용했습니다. Cloudflare 시스템에서 이 서명된 인증을 감지하면 라우팅 의도가 즉시 확인됩니다.
BYOIP를 지원하는 많은 기업에서는 자체 서명 인증서를 만들고 RDAP(등록 데이터 액세스 프로토콜) 레코드를 수동으로 수정하는 복잡한 워크플로를 필요로 하며, 이는 관리 부담이 큽니다. Cloudflare에서는 IRR 개체 수정 및 역방향 DNS TXT 레코드 중 하나를 선택할 수 있으며 RPKI와 결합하여 기존 네트워크 운영자에게 훨씬 더 친숙하고 간단한 확인 프로세스를 제공합니다.
새로운 셀프 서비스 흐름으로 인해 LOA인 "공공의 잔존물"이 필요하지 않지만, 전 세계의 많은 네트워크 운영자가 다른 네트워크의 접두사를 수락하는 프로세스의 일부로는 여전히 이 서비스에 의존합니다.
전 세계의 인접한 네트워크에서 사용자의 접두사를 받아들일 수 있도록 Cloudflare는 LOA 대신 배포할 문서를 자동으로 생성합니다. 이 문서에서는 Cloudflare가 고객 접두사를 생성할 권한이 있음을 확인하기 위해 수행한 검사에 대한 정보를 제공하며, Cloudflare에서 고객 접두사를 생성할 수 있는 유효한 ROA가 있는지 확인합니다. 이렇게 하면 고객이 직접 LOA를 생성할 부담 없이 LOA를 사용하는 네트워크 운영자의 워크플로우를 지원할 수 있습니다.
셀프 서비스 API를 설계할 때 고객에게 유연성을 제공하는 동시에 일치하는 서비스 바인딩 없이는 IP 접두사가 광고되지 않도록 필요한 안전 장치를 구현하는 것 사이에서 타협을 해야 한다는 문제가 있습니다. 이런 일이 발생하면 Cloudflare는 트래픽을 수신할 때 우리가 무엇을 수행할지 알지 못한 채 접두사를 알리게 됩니다! 이를 "블랙홀링" 트래픽이라고 합니다. 이 문제를 처리하기 위해 Cloudflare는 기본 서비스 바인딩, 즉 온보딩된 IP 접두사의 전체 범위를 포괄하는 서비스 바인딩을 도입해야 했습니다.
고객은 나중에 기본 Spectrum 서비스 바인딩 위에 CDN을 배치하는 것과 같이 여러 서비스 바인딩을 통해 기본 서비스 바인딩 위에 다양한 서비스 바인딩을 계층화할 수 있습니다. 이렇게 하면 서비스 바인딩 없이는 접두사를 광고할 수 없으며 고객의 트래픽을 블랙홀링할 수 있습니다.
Cloudflare API를 통해 IP 접두사에 서비스를 온보딩하고, 홍보하며, 추가하는 방법에 대한 최신 문서 관련 개발자 문서 를 확인하세요. 온보딩은 복잡할 수 있습니다. 주저하지 말고 질문을 하거나 Cloudflare의 전문 서비스 팀에 문의해 주세요.
BYOIP 관리를 스크립팅해서 기존 워크플로우에 통합하는 기능은 최신 네트워크 운영의 판도를 바꾸어 놓았으며, 이는 이제 시작에 불과합니다. 앞으로 몇 달 동안 대시보드에서 셀프 서비스 BYOIP와 고객에게 더 많은 제어 능력을 제공할 셀프 서비스 BYOIP 오프보딩을 찾아보세요.
Cloudflare의 셀프 서비스 BYOIP API 온보딩은 IP 자산에 대한 전례 없는 제어 능력과 유연성을 고객에게 제공합니다. 온보딩을 자동화하는 이러한 조치는 수동으로 검토된 PDF에서 벗어나 RPKI 채택을 유도하여 보안 상태를 더 강력하게 만들어줍니다. 이러한 API 호출을 사용하여 조직은 복잡한 네트워크 작업을 자동화하고, 마이그레이션을 간소화하며, 더욱 복원력 있고 민첩한 네트워크 인프라를 구축할 수 있습니다.