PNA의 역할 및 의의

거의 불필요하다는 설명으로 시작할까요?

💼 역할

PNA(Private Network Access) 정책은 브라우저가 ‘비인가된 공개(public) 웹 사이트에서 사용자의 비공개 네트워크(사설망) 주소로 접근할 수 없도록’ 제한하는, CORS 정책의 새로운 부가 옵션입니다.
(^{사전 지식:} CORS 설정 및 Preflight 요청)

예를 들어, 외부 사이트 https://blog.example.com에 접속해 사설망 http://192.168.0.10/api에 요청을 보내려 하면, 브라우저가 서버와 협력해 차단합니다. CORS 설정일 뿐이므로 전통적인 네트워크 접근 제어·보안 규칙을 대신하지는 않죠.

비공개 네트워크임을 알 수 있는 아이피의 패턴이 몇 가지 있는데, 접속한 사이트가 외부망 서비스이면서, 요청 대상 서비스의 IP가 비공개 네트워크의 패턴에 해당하면 브라우저가 서버에 사전 요청으로 CORS 정책을 확인할 때 PNA 조건을 포함하죠.^[1]

❓ 그렇다면 왜 이런 PNA 설정을 ‘거의 불필요했다’고 설명할까요? 살펴 봅시다!

🐢 늦은 도입

구글은 2022년 PNA(Private Network Access) 사양을 발표했죠. 당시 크롬에 이미 PNA 사양 중 일부를 포함하긴 했지만(2021 말), 웹 표준에 도입한 시기가 굉장히 늦다고 볼 수 있습니다.

Chrome은 비공개 네트워크 접근(PNA) 사양의 일환으로 ‘퍼블릭한 웹사이트에서 비공개 네트워크 엔드포인트에 대한 직접 액세스’를 지원 중단합니다. (2022)

그런데 PNA를 늦게 도입한 배경은, 이미 현대 사회의 일반 환경에서 PNA 유무가 생각보다 치명적이지 않았기 때문이기도 합니다. ⬇️

🎯 누가 PNA 제어가 필요한 대상일까요? (1: 악성 사이트 이용자 입장)

“CSRF 방어가 약하던 시절, 여러 사람의 공유기가 악성 사이트에 의해 오염되곤 했습니다. 그때라면 PNA 정책이 아주 큰 효과를 거두었을 겁니다.”

옛날 일부 공유기는 CSRF 방어가 약하거나 없었기 때문에, 악성 사이트에서 사용자의 브라우저를 통해 공유기에 제어 요청을 보낼 수 있었는데요. 이를 통해 방화벽을 무력화하거나 관리자 권한을 획득하는 등 일부 장비에 강력한 공격이 가능했습니다.

이런 이유로 PNA는 인터넷 보급 초창기 또는 IT 산업이 발전하던 시기에 도입하였다면 좋았을 정책이죠. 그 무렵 많은 사용자가 여전히 인터넷 익스플로러 애호가였다는 사실을 빼고 본다면요.

현대적인 장비는 이러한 방어 체계를 이미 갖추고 있기 때문에, 작금에 이르러 거의 필요하지 않은 정책이 되었습니다. 물론 레거시 장비나 값싸고 인증받지 않은 라우터를 사용 중이라면 여전히 위험할 수 있었고, 이때는PNA 정책이 보안 강화 요인으로 유효할 수 있습니다.

🎯 누가 PNA 제어가 필요한 대상일까요? (2: 서비스 제공자 입장)

우선 ‘일반적인 환경’을 갖춘 조건에서는 PNA 제어가 그렇게 중요하지 않습니다.

💪 CORS 설정이 충분히 잘되어 있다면? → ✅ PNA 제어의 중요성이 낮습니다.
🤝 서로 믿을 수 있는 사이트만 교류한다면? → ✅ PNA 제어의 중요성이 낮습니다.
🌐 외부망/내부망을 혼용하지 않는다면? (정상적인 망 분리) → ✅ PNA 제어의 중요성이 낮습니다.

앞서, PNA는 CORS 설정일 뿐이므로 전통적인 네트워크 접근 제어나 보안 규칙을 대신하지는 않는다고 설명했는데요. 오히려 사이트 이용자는 우리 사무실 등 이미 사설망 이용 가능 환경에 있을 확률이 높죠. 아니 정확히는 사설망에 이미 접속해 있어야 ‘사설망’에 요청하는 게 우리 서버에 닿을 수 있으니, 사설망 이용 환경임은 분명합니다.

🔍 이 점에서 PNA 정책이 ‘일반 사용자’보다 ‘내부 직원’의 사용에 관련이 있다고 유추할 수 있는 겁니다.

그래서 우리가 신뢰할 수 있는 모든 조건을 갖추었을 때는 추가로 브라우저와 PNA 관련 도움을 주고받을 필요가 없었던 거죠. 그만큼 표준 도입이 늦어도 논란이 적었습니다.

시나리오

그렇다면 어떨 때 PNA 제어가 의미가 있고, 어떤 설명들이 단지 오해에서 비롯되었는지 뜯어 봅시다!

PNA 시나리오(PNA-Dependent Scenarios)

PNA 정책을 도입함으로써 보안을 보조적으로 강화할 수 있는 보안 케이스입니다.

😈 악성 사이트 이용자 입장

나중에 쓸래요.

🔧 서비스 제공자 입장

💡

내부 직원이 외부 서비스에 접속한 상태로 내부망에 접근? (매우 관련 있음)

한 대의 컴퓨터가 내·외부망을 혼용한다는 전제여야 합니다. 하지만 이는 일반적이지 않습니다.
일반적으로 내부망과 외부망의 혼용은 권장하지 않으며, 오히려 뚜렷한 구분을 중요시합니다.
(물리적 망 분리, 논리적 망 분리)

이 항목은 PNA 설정과 관련이 매우 깊지만 이는 일반적인 설정이 아닙니다.

직원이 외부망 서비스 https://example.com에 접속합니다.
해당 사이트의 스크립트가 (악의 또는 실수로) 내부망 http://192.168.0.10/api에 요청합니다.
신기하게도 그게 하필 또 우리 서버의 유효한 API 엔드포인트라고 전제합니다.
우리 서버가 평소 https://example.com 사용자를 신뢰하여 CORS를 허용했다고 전제합니다.
Data 전달: 우리 서버 → 직원 브라우저
신기하게도 그 사이트는 응답을 받아서 본인들의 서버로 전송합니다.
Data 전달: 직원 브라우저 → example.com 소유자와 관련되거나 무관한 외부 서버

원래라면 내부망으로 격리되어 있었을 우리 서버의 데이터가, ‘신뢰한 사이트’에 접속한 내부 직원을 통해 외부 서버로 유출되는 시나리오입니다.

이때 ‘내부 직원’이 악의적인 프록시 서버 등이 아닌 정상적인 브라우저를 사용했지만, 데이터가 유출되는 경로가 되었습니다. CORS 정책의 대상이 보안에서 직접 유효한 케이스는 이처럼 ‘정상적인 브라우저를 통해 발생하는 공격 유형’일 때입니다.

이 시나리오에서는 ‘외부망 서비스에서 요청한 대상 서버가 내부망일 때 거부’하는 정책을 적용하면 매우 효과적이겠죠. 그것이 바로 ‘PNA’입니다.

💡

CORS 허용 대상을 동적으로 등록하는 등, 반드시 신뢰하는 대상만 등록하지는 않는다면?

이때도 위 시나리오와 동일한 상황이 발생할 수 있습니다.

신뢰할 수 없는 서비스도 존재하기 때문에 이때 위 시나리오와 같은 실수 또는 악의적 행동이 증가할 수도 있습니다.

PNA와 무관한 시나리오(PNA-Independent Scenarios)

PNA 정책 도입 전부터 원래 안전했거나 무관한 시나리오입니다.

💡

Private → Public 요청? (무관)

PNA 정책에서 다루는 요청과 정반대인 요청입니다. Private → public 요청은 원래 CORS 정책에서 origin 허용 정책에 더욱 밀접합니다.

💡

신뢰할 수 없는 사이트에서 우리 내부망에 요청? (일부 연관)

허용 출처(origin) 목록에 신뢰할 수 있는 주소 목록만 작성했다면, 신뢰할 수 없는 사이트가 내부 직원을 통해 우리 내부망에 직접 액세스할 수 없습니다.^[2]

일반적인 서비스는 신뢰하는 주소 목록만 등록하므로 대체로 PNA와 무관합니다.

💡

외부망의 프론트엔드 개발자가 로컬호스트로 접속하여 개발 서버에 요청? (무관)

잘 보면, 앞서 작성한 ‘private to public’ 요청 사례 중 하나입니다. 접속망은 외부망이지만 주소창에는 로컬호스트를 입력했습니다. 또한 외부망에서 외부망으로 접근하므로 ‘to public’ 요청입니다.
(사설망, 가상사설망 미이용 시)

ℹ️ 부가 정보 및 참조

[1] PNA 정책에서 내부 네트워크로 인식하는 주소

크롬 등 대표적인 브라우저는 이하 목록을 내부 네트워크로 인식합니다. DNS 조회로 얻은 결과 아이피를 바탕으로 식별하므로, 도메인 네임을 입력했다고 해서 외부 서비스로 인식하지는 않습니다.

이하 목록에서 * 기호는 임의의 값이 올 수 있음을 전달합니다.
실제로는 0을 입력하여 마스크를 표현합니다.

사설 IPv4 (RFC1918)

10.*.*.*/8 → A 클래스

172.16.*.*/12 → B 클래스 (172.16.*.* .. 172.31.*.*)^[3]

192.168.*.*/16 → C 클래스
루프백 IPv4 (Loopback)

127.*.*.*/8
링크 로컬 IPv4 (Link-Local)

169.254.*.*/16
IPv6 내부 주소
- ::1/128 (루프백)
- fe80::/10 (링크 로컬: fe80:: .. febf:*:*:*:*:*:*:*)
- fc00::/7 (사설)

[2] 외부 서비스의 내부망 접근 가능성

이 참조의 역참조에 있는 설명은 PNA 정책의 영향에 한정한 설명입니다.

이미 내·외부망을 혼용하는 상황을 전제로 하는 설명이므로, 망 분리가 완전하지 않아 내부망 침투 경로가 존재합니다.

[3] 아이피의 CIDR 표기: 172.16.0.0/12 등

\역참조: 부가 정보 및 참조 [1]*

서브넷 마스크 표기에 자주 등장하는 CIDR 표기 방식은 /12 등 ‘같은 네트워크(수퍼넷)’
(CIDR: Classless Inter-Domain Routing)

🤔

읽기 편한 글을 위해 노력하고 있습니다! 자유로운 피드백과 반응 부탁드립니다.

CORS 설정: PNA(Private Network Access) 정책 제어 <시나리오>

PNA의 역할 및 의의

거의 불필요하다는 설명으로 시작할까요?