프록시를 사용해본 적이 있다면 IP 화이트리스팅이 익숙할 것입니다. 서버 주소를 제공업체에 등록하면, 해당 주소에서 오는 모든 연결이 자격 증명 없이 허용되는 방식입니다. 흔히 쓰이는 방식이라, 다른 제품을 쓰다 넘어온 사람들이 이 설정을 찾곤 합니다.
레지덴셜 게이트웨이에 대한 직접적인 답은, IP 화이트리스트가 없다는 것입니다. 모든 요청에서 인증은 사용자 이름과 비밀번호로 이루어지며, 자격 증명이 유일한 인증 방식입니다. 이는 기능이 빠진 것이 아니라 의도적인 설계 선택이며, 왜 그런지 이해할 필요가 있습니다. 그 이유에 따라 접근을 안전하게 관리하는 방식이 달라지기 때문입니다. 화이트리스팅은 제품군의 다른 곳, 즉 ISP 프록시와 레거시 포트 기반 요금제에는 존재하며, 이 글에서는 그곳에서 어떻게 설정하는지도 다룹니다.
레지덴셜 게이트웨이가 자격 증명 방식을 쓰는 이유
레지덴셜 제품은 p.shifter.io:443이라는 단일 엔드포인트를 사용하며, 모든 타겟팅 정보는 사용자 이름 안에 담깁니다. 스티키 세션을 사용한 미국 출구 요청과 로테이팅 독일 출구 요청은 동일한 호스트와 포트를 사용하며, 오직 사용자 이름 문자열만 다릅니다. 이러한 설계는 인증 방식에도 영향을 미칩니다. 자격 증명이 이미 요청별 정보를 담고 있으므로, 어차피 모든 요청에 포함되어야 합니다.
또한 자격 증명 인증은 훨씬 더 이식성이 좋으며, 이는 처음 보이는 것보다 더 중요한 의미를 가집니다. 화이트리스팅은 고정된 송신(egress) 주소에 접근을 묶어두는데, 오늘날의 많은 인프라는 그런 고정 주소를 갖고 있지 않습니다. 컨테이너는 재스케줄될 때마다 새 주소를 받고, 오토스케일링 그룹은 노드를 추가하거나 제거하며, 서버리스 함수는 예고 없이 바뀌는 공유 주소 대역을 통해 송신하고, CI 러너는 일시적이며, 노트북이나 가정용 회선을 쓰는 개발자는 밤새 바뀔 수 있는 동적 주소를 가지고 있습니다. 화이트리스팅 하에서는 이 모든 경우가 지원 티켓으로 이어집니다. 반면 시크릿 저장소에 담긴 자격 증명이라면, 노트북, 컨테이너, CI 작업, 프로덕션 클러스터 어디서든 아무것도 등록할 필요 없이 동일한 설정이 그대로 작동합니다.
따라서 레지덴셜 프록시에서 화이트리스트 설정을 찾고 있었다면, 대신 설정해야 할 것은 자격 증명 관리이며, 아래에서 다룹니다.
화이트리스팅이 적용되는 곳
두 제품은 소스 IP 인증을 사용하며, 화이트리스팅이 꼭 필요한 요구 사항이라면 이 두 제품을 살펴보아야 합니다.
ISP 프록시는 두 가지 인증 모드를 지원하며, 패널에서 요금제별로 하나를 선택합니다. 승인된 소스 IP 모드에서는 서버 주소를 등록한 뒤 자격 증명 없이 고정된 IP로 1337 포트에 접속합니다. 사용자 이름과 비밀번호 모드에서는 자격 증명을 사용해 어디서든 접속할 수 있으며, IP당 한 줄씩 설정합니다. 트레이드오프는 위에서 설명한 것과 동일합니다. 화이트리스팅은 코드에서 자격 증명을 완전히 배제하는 대신, 등록된 주소에서만 작동한다는 대가를 치릅니다. ISP 프록시는 로테이팅 레지덴셜과는 다른 제품으로, 로테이팅 풀이 아니라 고정된 정적 주소를 사용합니다. 둘 사이에서 선택 중이라면 ISP와 레지덴셜 프록시 비교와 고정 레지덴셜 프록시란 무엇인가를 참고하십시오.
레거시 포트 목록 요금제는 소스 IP로만 인증합니다. 할당된 각 포트는 고유한 서브도메인을 가지며, 패널에서 서버 주소를 화이트리스트에 등록하거나 레거시 관리 API를 통해 목록을 관리한 뒤, 목록에 있는 어떤 포트로든 접속할 수 있습니다. 이 요금제를 사용 중이라면 화이트리스팅은 선택 사항이 아니라 유일한 인증 방식입니다. 업계가 왜 이 모델에서 벗어났는지에 대한 배경은 포트 단위 시대는 끝났다에 있습니다.
ISP 프록시에서 화이트리스트 설정하기
작동 방식은 단순하지만, 두 가지 세부 사항이 대부분의 오류를 일으킵니다.
첫째, 로컬 주소가 아니라 송신(egress) 주소를 등록해야 합니다. 중요한 것은 트래픽이 실제로 나가는 공인 주소이며, 이는 LAN 주소도, 컨테이너 내부 주소도, ifconfig가 해당 머신에서 출력하는 주소도 아닙니다. 실제로 요청을 보낼 머신에서 확인하십시오.
# run this ON the server that will connect to the proxies
curl -s https://ipinfo.io/ip인프라가 NAT 게이트웨이나 로드 밸런서를 통해 송신한다면, 등록해야 할 것은 그 공유 주소이며, 동적으로 할당되는 것이 아니라 고정되어 있는지 확인하는 것이 좋습니다.
둘째, ISP Proxies 패널에서 인증 모드를 신중하게 선택하십시오. 두 모드는 계층적으로 함께 적용되는 것이 아니라 서로 대안 관계이기 때문입니다. 승인된 소스 IP 모드에 들어가면 자격 증명 없이 접속합니다.
# authorized source IP mode: no username or password
curl -x 185.199.108.153:1337 https://ipinfo.io/json주소가 등록되어 있는 것이 확실한데도 오류가 반환된다면, 흔한 원인은 송신 주소가 바뀌었거나, IPv4 주소를 등록했는데 실제 트래픽은 IPv6로 나가고 있거나 그 반대인 경우, 혹은 테스트했던 노드와 다른 노드에서 요청이 오고 있는 경우입니다.
트레이드오프를 명확히 정리하면
화이트리스팅은 코드와 설정에서 비밀 정보를 없애준다는 점에서 실질적인 가치가 있습니다. 저장소에서 유출될 것도 없고, 순환시킬 것도 없으며, 로그에 남을 것도 없습니다. 약점은 송신 주소가 바뀌는 순간 바로 실패하며, 고정 주소가 없는 곳에서는 접근을 지원할 수 없다는 것입니다.
자격 증명 인증은 이식성이 좋고 어떤 환경에서든 작동하지만, 자격 증명 자체가 이제 여러분이 관리해야 할 비밀 정보가 되며, 소스 코드가 아니라 시크릿 관리자에 두어야 하고, 순환 계획도 필요합니다.
어느 쪽도 본질적으로 더 안전한 것은 아닙니다. 실패하는 방식이 다를 뿐이며, 올바른 선택은 여러분의 인프라가 안정적인 송신 주소를 가지고 있는지에 달려 있습니다.
화이트리스트가 없는 상황에서 레지덴셜 자격 증명 보호하기
레지덴셜 게이트웨이를 사용하고 있다면, 이 섹션이 여러분에게 화이트리스팅을 대체하는 부분입니다.
자격 증명을 소스 관리와 컨테이너 이미지 밖에 두고, 시크릿 관리자로 뒷받침되는 환경 변수에서 불러오십시오. 가능하다면 환경별로 별도의 자격 증명을 사용해서, 유출된 개발 환경 값이 프로덕션을 노출시키지 않도록 하십시오. 순환 작업은 패널 클릭이 아니라 배포로 취급하십시오. 시크릿 저장소를 먼저 업데이트하고, 클라이언트를 순차적으로 갱신한 뒤 이전 값을 순환시켜야 합니다. 이전 비밀번호를 여전히 가지고 있는 모든 클라이언트는 값이 바뀌는 순간 407을 반환하기 시작하며, 이는 407 및 자격 증명 오류 해결하기에서 다루는 가장 흔한 자초형 문제입니다.
그 다음에는 반대편도 통제하십시오. 제공업체 측 화이트리스트가 없더라도, 일반적인 송신 규칙, 네트워크 정책, 또는 보안 그룹을 사용해 여러분의 어떤 시스템이 게이트웨이에 접근할 수 있는지 제한할 수 있으며, 이렇게 하면 유출된 자격 증명이 인프라 외부에서 쓸모없어집니다. 그리고 대역폭 사용량을 모니터링하십시오. 설명할 수 없는 사용량은 자격 증명이 유출되었다는 신호이며, 여러분 자신의 파이프라인 모니터링에서 기준선을 가지고 있다면 이를 더 쉽게 알아챌 수 있습니다.
흔한 실수들
10.x나 192.168.x 같은 사설 주소를 등록하는 것은 절대 일치할 수 없습니다. 제공업체에 보이는 것은 오직 공인 송신 주소뿐이기 때문입니다. 노트북이나 가정용 회선을 화이트리스트에 등록해두었다가 라우터 재부팅으로 주소가 재할당된 뒤 작동이 멈춰서 당황하는 경우도 있습니다. 오토스케일링이 서로 다른 주소를 가진 노드를 추가한다는 사실을 잊는 경우도 있습니다. 실제 트래픽은 IPv6로 나가는데 IPv4를 등록하는 경우도 있습니다. 그리고 한 제품의 화이트리스트 항목이 다른 제품도 포함한다고 가정하는 경우도 있습니다. ISP 프록시 화이트리스트는 레지덴셜 게이트웨이에는 아무 영향이 없으며, 여전히 자격 증명이 필요합니다.
결론
레지덴셜 게이트웨이에는 IP 화이트리스트가 없으며, 이는 의도된 설계입니다. 타겟팅 정보가 사용자 이름 안에 담겨 있으므로 자격 증명은 어차피 모든 요청에 포함되어야 하고, 자격 증명 인증은 화이트리스트가 깨질 만한 컨테이너, 오토스케일링, CI, 동적 연결 환경에서도 계속 작동합니다. 소스 IP 인증이 특별히 필요하다면, ISP 프록시는 선택 가능한 두 모드 중 하나로 이를 제공하며 레거시 포트 목록 요금제는 이를 유일한 방식으로 사용합니다. 두 경우 모두 등록해야 할 것은 로컬 주소가 아니라 여러분의 공인 송신 주소입니다. 레지덴셜에서는 화이트리스팅 대신 체계적인 자격 증명 관리로 대체하십시오. 시크릿 관리자, 환경별 값, 이전 비밀번호를 무효화하기 전에 클라이언트를 먼저 업데이트하는 순환 절차, 그리고 여러분 측의 송신 통제와 사용량 모니터링이 그것입니다.
모든 제품에 대한 전체 인증 참고 자료는 인증 문서에 있으며, 게이트웨이 세부 사항은 게이트웨이 및 인증에 있습니다. 제품 자체는 레지덴셜 프록시이며, 모든 국가와 세션 모드에 걸쳐 하나의 엔드포인트와 하나의 자격 증명 쌍을 사용하고, GB당 가격으로 제공됩니다.