Cloudflare PQ GeoKey 분석: 키의 지역 제한과 데이터 위치는 어떻게 다를까

“키는 유럽에 있다” 다음에 물어야 할 것

기업 문서 검토 서비스를 운영한다고 하자. 고객 파일은 EU 저장소에 두고, 해외 사용자도 접속할 수 있게 CDN을 사용한다. 이제 공급자가 지역을 제한하는 양자내성 키 관리 기능을 발표했다. 이를 도입하면 고객에게 “문서는 EU 밖에서 처리되지 않는다”고 말해도 될까?

그 답을 얻으려면 파일 저장소만 볼 수 없다. TLS가 풀리는 곳, 애플리케이션이 문서를 읽는 곳, 분석 API로 보내는 경로, 운영 로그의 보관 위치까지 이어 봐야 한다. 키 위치에 관한 증거는 데이터 경로 전체에 관한 증거의 한 부분이다.

Cloudflare는 2026년 10월 23일 PQ GeoKey Manager를 비공개 베타로 발표했다. 정식 제공 목표는 2027년 1분기이며, 기존 CDN 인증서 기능에 새 PQ 설계를 연결하는 작업은 별도 개발 중이다. 발표와 현재 CDN 도입 가능 상태를 구분해야 한다. 공식 발표

이 글은 10월 24일 확인한 문서에 기반한 도입 분석이다. 아래 문서 서비스와 장애 상황은 가상 사례이고, 그림은 자체 설명도다. 베타 이용·암호 구현·성능 측정은 하지 않았다. 특정 국가의 법적 적합성을 판단하는 글도 아니다.

암호화된 키는 널리 복제해도, 푸는 능력은 따로 둘 수 있다

키 관리에서 래핑(wrapping)은 다른 키를 암호화해 보관·전달하는 것을 말한다. 예를 들어 서비스의 개인키를 암호화한 꾸러미로 만들면, 꾸러미를 받았다는 사실과 그 안의 개인키를 꺼낼 수 있다는 사실이 분리된다. 원래 개인키가 자료라면, 래핑을 푸는 키는 그 자료에 접근할 수단이다.

공급자 설명에서 새 설계는 지역별 루트 비밀로부터 서비스별 키 쌍을 파생한다. 암호화된 고객 키와 메타데이터는 전역으로 배포하지만 루트 키는 승인된 지역 서버에 공급한다. 메타데이터에는 서비스·지역·키 세대(epoch)가 붙는다. 지역 판정에는 TPM 하드웨어 신원과 서버 위치 목록도 쓰인다. 키 계층과 배포 설명

이 구조를 이해할 때 지도를 암호 알고리즘 안에 넣었다고 생각하면 곤란하다. “이 서버는 어느 지역에 속하는가”라는 운영 정보와 키를 받을 권한이 연결돼 있다. 따라서 검토자는 알고리즘 이름뿐 아니라 서버 등록·이동·폐기 때 지역 소속을 누가 갱신하는지도 물어야 한다. 이것은 설계에서 도출한 검토 질문이며 해당 운영 절차를 감사했다는 뜻은 아니다.

꾸러미를 전 세계에 복제하는 장점은 필요한 곳에 자료를 미리 보내 둘 수 있다는 것이다. 반면 복호화 수단까지 함께 모든 곳에 보내면 지역별 통제가 사라진다. 독자가 다른 키 관리 제품을 볼 때도 “암호문은 어디에 복제되는가”와 “그 암호문을 누가 풀 수 있는가”를 따로 질문하면 구조를 비교하기 쉽다.

양자내성은 무엇을 보호하는가

NIST FIPS 203이 정의하는 ML-KEM은 공개 통신 경로에서 두 쪽이 공유 비밀을 정하는 데 사용하는 키 캡슐화 메커니즘이다. 그 비밀은 이후 대칭키 암호 등에 쓰일 수 있다. 문서 본문 전체를 ML-KEM으로 직접 암호화하는 방식으로 이해하면 역할이 뒤섞인다. 표준은 ML-KEM-512·768·1024를 정의하며, 현재 알려진 분석에서 양자 컴퓨터를 가진 공격자에도 안전할 것으로 여겨진다고 설명한다. 모든 구현과 운영이 무조건 안전하다는 인증은 아니다.

또 하나의 혼동은 hybrid라는 말이다. RFC 9180의 HPKE는 KEM, 키 파생 함수(KDF), 인증된 암호화(AEAD)를 결합하는 구조다. HPKE를 쓴다는 사실만으로 양자내성이 확인되지는 않는다. 실제로 선택한 알고리즘을 봐야 한다.

이번 Cloudflare One 경로의 설명은 ML-KEM-768과 X25519를 결합한 KEM, HKDF-SHA-256, AES-256-GCM을 명시한다. 즉 HPKE의 구성 방식과, 그 안에서 양자내성·기존 알고리즘을 결합한 선택을 구분해 읽어야 한다. 암호 설계 설명

검토 문서에는 “PQC 지원” 한 칸 대신 다음처럼 보호 대상과 구간을 적는 편이 유용하다.

검토할 대상	확보할 근거	그 근거만으로 답할 수 없는 것
보관·배포되는 암호화 키	래핑 알고리즘과 키 접근 주체	사용자와 서버 사이의 실제 TLS 협상
사용자 연결	해당 연결의 프로토콜·협상 결과	저장된 파일·백업의 암호화 방식
파일과 백업	저장 암호화·복구 키·보관 정책	외부 API로 보내진 사본의 처리 위치

이 표는 자체 도입 분석이다. 어느 한 행의 전환 완료를 나머지 행의 완료로 복사하지 않도록 만드는 기록 방식이며, 제품의 지원 목록을 대신하지 않는다.

처리 위치와 로그 위치는 다른 문서에서 답을 찾아야 한다

Regional Services 문서는 지정 지역 안에서 TLS를 종료하고 복호화된 트래픽을 처리하는 기능을 설명한다. 해외에서 접속한 요청을 암호화된 상태로 지정 지역까지 전달하는 경로가 가능하다. 따라서 “해외 접속점이 있었다”와 “해외에서 본문을 읽었다”도 같은 관측이 아니다.

같은 문서는 공유 진입 IP의 외부 지리정보가 설정 지역과 다르게 표시될 수 있다고 설명한다. IP 위치 검색 결과 하나로 실제 복호화 위치를 판정하면 안 된다. 반대로 계정 화면에 지역 이름이 보인다는 이유만으로 모든 호스트와 제품 경로가 그 설정을 따른다고 가정하지도 않는다. 적용 대상과 제외 조건이 있는 설정 증거를 요청해야 한다.

Customer Metadata Boundary 문서는 요청 URL·시간·방화벽 이벤트 같은 Customer Logs를 다룬다. 현재 지원 지역은 EU와 미국이며 Regional Services와 별도 지역 설정을 쓴다. 지역 밖 접근 허용 옵션을 켜면 보관 지역을 유지하면서도 권한 있는 사용자의 지역 밖 접근을 허용할 수 있다. 저장 위치와 열람 가능 위치까지 나누어 볼 이유다.

이로부터 문서 검토 서비스의 설계 질문을 다음처럼 만들 수 있다. EU를 고른 것은 사례의 가정이며, 아래 전체 구성이 지원되거나 법적 요구를 충족한다고 확인한 것이 아니다.

데이터 흐름	운영팀이 채울 항목	다음 판단
사용자 → 서비스 입구	대상 호스트, TLS 종료·검사 위치	설정이 없는 별도 업로드 호스트가 있는가
서비스 → 원본 저장소	읽기·쓰기·복제 위치	파일 보관 정책과 요청 처리 정책이 같은 범위인가
서비스 → 외부 문서 분석 API	전송 내용, 처리 지역, 보관 조건	외부 호출을 유지할지 범위를 줄일지 결정
서비스 → 로그·관측 도구	본문·URL·식별자 포함 여부, 보관·열람 위치	본문이 제외돼도 민감한 경로명이 남는가
운영자 → 백업 복원	복원할 지역, 사용 가능한 키, 담당자	장애 중에도 같은 경계를 유지할 수 있는가

가령 원본 파일과 웹 요청을 EU에서 처리해도, 앱이 문단 전체를 별도 지역의 분석 API로 보내면 그 호출은 독립된 검토 대상이다. 지역 키 관리가 이 API 호출의 목적지와 보관 정책을 대신 결정하지 않는다. 외부 호출을 빼는 선택은 기능을 줄일 수 있고, 지역 내 대안을 찾는 선택은 비용·품질·운영 부담을 바꿀 수 있다. 이때 필요한 결정은 “더 안전한 상품 이름”보다 허용할 데이터 흐름이다.

지역 장애에서 지켜야 할 것과 복구할 것을 나눈다

공식 설계는 필요한 지역 키가 없거나 서비스·지역·세대 확인이 실패하면 요청을 거절하는 fail-closed 방식을 설명한다. 초기화에 필요한 키가 없거나 잘못돼도 키 서비스가 시작하지 않는다. 이는 공급자의 설계 설명이며 직접 장애 시험 결과는 아니다. 보안·가용성 조건

여기서 운영팀이 정해야 할 것은 “장애가 나면 아무 지역에서나 살린다”는 일반 복구 원칙을 그대로 적용할지다. 허용 지역을 지키는 중단과 허용 지역을 벗어난 성공 응답은 다른 결과다. 다만 요청 거부 하나만으로 지역 통제가 원인이라고 결론 내릴 수도 없다. 인증·라우팅·키 배포·앱 오류의 근거가 필요하다.

다음은 앞의 문서 서비스에 대한 미실행 인수 시험 설계다. 실제 고객 데이터나 운영 키를 옮기며 시험하라는 안내가 아니다. 허가된 시험 환경과 합성 문서로 관측할 항목을 정한다.

가정한 실패	받아들일 결과의 조건	실패로 볼 상태
허용 지역의 노드 하나 사용 불가	같은 허용 범위의 대체 노드에서 처리, 또는 명시적 오류	다른 지역으로 옮겼는지 모르는 상태에서 성공만 집계
키 배포가 끝나지 않은 새 노드	준비되지 않은 노드가 요청을 처리하지 않음	화면의 정상 표시만 보고 키 준비까지 완료로 판단
허용 지역 전체 사용 불가	사전에 정한 중단·재시도·안내 정책 적용	승인 없이 지역을 넓혀 문서를 처리
키 교체 후 옛 암호문을 읽어야 함	허용한 전환 기간과 복구 경로의 근거 확보	새 키 생성만 확인하고 옛 데이터의 접근 조건은 미확인

가용성과 지역 통제는 모두 기록해야 한다. 예를 들어 합성 업로드가 거절됐다면 사용자는 업무를 못 마친다. 동시에 지역 경계가 유지됐을 가능성은 있지만, 그 판단에는 별도 증거가 필요하다. “안전하니 정상” 또는 “오류니 보안 실패”라는 하나의 상태로 합치면 대응 책임이 흐려진다.

지역 내 대체 경로가 충분하다면 중단을 줄일 수 있다. 반대로 업무가 중단을 전혀 허용하지 않는데 사용 가능한 지역이 하나뿐이라면, 상품 설정 이전에 그 요구 조합이 가능한지부터 협의해야 한다. 이것은 특정 제품의 장애율 예측이 아니라 서비스 요구의 충돌을 드러내는 방법이다.

지금 결정할 수 있는 도입 범위

기존 CDN Geo Key Manager 문서는 custom certificate와 API를 통한 이용 조건을 설명한다. 이 문서의 설정 경로를 새 PQ 베타의 활성화 명령으로 옮겨 적어서는 안 된다. 기존 기능, 새 설계, 내 계정에서 사용할 수 있는 기능을 각각 확인해야 한다.

이번 검토에서 당장 만들 수 있는 산출물은 대상 서비스 하나의 경계 기록이다. 다음 양식은 공급자 API나 완료 인증서가 아닌 자체 작성용 기록이다. 빈 양식 내려받기로 팀 검토에 사용할 수 있다.

대상 서비스·호스트 / 문서 확인 날짜:
검토 기능·제공 상태 / 실제 계정 이용 가능 여부:
보호 대상: 키 래핑 / 전송 연결 / 파일·백업
허용 범위: 키 사용 / 본문 처리 / 로그 저장 / 로그 열람
외부 호출: 목적지 / 전송할 내용 / 별도 보관 조건
장애 정책: 지역 내 대체 / 중단 / 재개 판단자
키 교체: 옛 자료 접근 기간 / 회수 완료의 확인 근거
근거 상태: 문서 확인 / 시험 계획 / 관측 완료 / 미확인
남은 질문 / 담당자 / 다음 확인일:

개인키·토큰·실제 문서 내용은 넣지 않는다. 표를 채운 뒤에도 미확인 경로가 남으면 전체 도입 완료로 표시하지 않고, 확인된 서비스·호스트까지만 범위를 좁힌다. 장기 기밀성과 지역 통제를 함께 요구하는 팀이라면 이 기록으로 베타 평가 질문을 구체화할 수 있다. 당장 CDN 적용이 필요한 팀이라면 이용 가능한 기존 기능과 향후 PQ 통합 일정을 분리해 계획해야 한다.

키의 역할을 더 이해하려면 패스키에서 키·복구·세션을 구분하는 글을, 기술 도입 뒤 담당자와 복구 책임을 정하는 방법은 Void의 운영 인계 분석을 이어 읽을 수 있다. 다음 공급자 검토 때 양식을 다시 쓰려면 이 글을 저장해 두고, 관련 주제는 보안 허브에서 찾을 수 있다.