“레지덴셜 프록시는 안전한가”라는 질문은 사실 하나의 외투를 입은 두 개의 질문이다. 첫 번째는 여러분의 트래픽이 여러분이 통제하지 않는 인프라와 연결을 거치는 상황에서, 그것이 여러분에게 안전한가 하는 것이다. 두 번째는 윤리적인 의미에서 안전한가 하는 것으로, 풀을 구성하는 가정용 회선의 소유자들이 그곳에 포함되는 것에 동의했는가 하는 문제다. 두 질문 모두 정직한 답변을 받을 자격이 있으며, 솔직히 말하면 위험은 실재하지만 특정한 지점에 집중되어 있고, 그 지점을 알고 나면 대체로 관리 가능하다.
프록시가 볼 수 있는 것과 볼 수 없는 것
작동 원리부터 시작하자. 이 부분에 대한 불안 대부분은 과장되었거나 엉뚱한 대상을 향해 있기 때문이다.
프록시를 통해 HTTPS 페이지를 요청하면, 클라이언트는 목적지까지 암호화된 터널을 열고 프록시는 암호화된 바이트를 전달만 한다. 암호화가 프록시가 아니라 목적지에서 종료되기 때문에, 프록시는 페이지 내용도, 양식 입력값도, 터널 내부의 그 무엇도 읽을 수 없다. 이는 공용 Wi-Fi에서 여러분을 보호하는 것과 동일한 속성이다.
프록시가 볼 수 있는 것은 메타데이터다. 어떤 호스트네임에 연결했는지, 언제, 얼마나 자주, 얼마나 많은 데이터가 이동했는지, 그리고 어느 출구 IP를 통했는지다. 이것이 사소하다고 할 수는 없다. 관행이 부실한 프로바이더라면 여러분이 무엇을, 어디서 수집하는지에 대한 그림을 그릴 수 있으며, 경쟁 정보 수집 작업에서는 페이지 내용이 노출된 적이 없더라도 이는 상업적으로 민감한 문제가 된다.
이 상황이 완전히 달라지는 것은 평문 HTTP의 경우다. TLS가 없으면 중간자는 모든 것을 보고 변경할 수도 있다. 그렇기 때문에 가장 중요한 단 하나의 규칙은, 프록시를 거치든 거치지 않든 민감한 것은 반드시 HTTPS로 전송되어야 한다는 것이다.
진짜 위험이 있는 곳
위험은 고르게 분포되어 있지 않으며, 한 범주가 대부분의 피해를 차지한다.
무료 및 검증되지 않은 프록시가 진짜 위험 요소다. 무료 프록시는 어떤 방식으로든 비용을 회수해야 하며, 보통은 트래픽 데이터를 로깅하고 판매하거나, 광고를 삽입하거나 교체하거나, 클라이언트가 허용하는 경우 TLS를 벗겨내거나, 암호화되지 않은 상태로 전송된 것에서 자격 증명을 수집하는 방식이다. 오픈 프록시 목록은 더 나쁘다. 누가 운영하는지 전혀 알 수 없기 때문이다. 무료 프록시와 유료 프록시에 대한 논의는 보통 신뢰성 중심으로 다뤄지지만, 보안 측면의 논거가 더 강력하다. 상업적 프로바이더를 이용하면 계약이 있고, 식별 가능한 상대방이 있으며, 상대측에도 잃을 것이 있다.
불투명한 소싱이 두 번째 문제다. 프로바이더가 자신의 주소가 어디서 오는지 설명하지 못한다면, 이는 두 가지 측면에서 문제가 된다. 윤리적으로는, 자신의 회선이 사용되는 사람들이 그 사실을 모를 수 있다. 실무적으로는, 정보 제공 동의 없이 구성된 풀은 더 심하게 차단 표시되는 경향이 있으므로, 법무팀을 걱정하게 만들 만한 그 불투명함이 곧 더 나쁜 성능을 예고한다. 이것이 윤리적 소싱이 도덕적 문제인 만큼이나 상업적 문제인 이유다.
여러분 쪽에서의 자격 증명 관리가 세 번째 요소이며, 이는 여러분이 완전히 통제할 수 있는 영역이다. 프록시 자격 증명은 유료 대역폭에 대한 접근을 부여하는 비밀 정보다. 저장소에 커밋되거나, 컨테이너 이미지에 굳어지거나, 채팅으로 공유되면 그것은 여러분의 비용으로 다른 누군가의 자원이 되며, 대개는 경고가 아니라 설명되지 않는 사용량 증가로 드러난다.
윤리 문제, 있는 그대로 말하자면
레지덴셜 프록시가 작동하는 이유는 실제 사람의 가정용 회선이 여러분의 요청을 실어 나르기 때문이다. 이것이 받아들일 만한지는 전적으로 그들이 알고서 동의했는지에 달려 있다.
정당한 네트워크는 공개된 방식을 통해 주소를 확보한다. 대개는 앱이나 SDK를 통해 참여자에게 자신의 회선이 공유될 것임을 알리고, 그 대가로 무언가를 제공하며, 탈퇴할 수 있게 한다. 부정당한 네트워크는 사람들이 자신이 설치하는지도 몰랐던 번들 소프트웨어를 통해, 혹은 더 나쁘게는 악성코드를 통해 이를 확보한다. 이 차이는 사양서에는 보이지 않지만 프로바이더가 이 질문에 어떻게 답하는지에서는 드러난다. 그러니 직접 물어보고, 모호한 답변 자체를 하나의 답으로 취급하라.
여러분에게도 하위 결과가 있다. 여러분의 수집 작업이 소유자가 결코 동의한 적 없는 회선을 통해 이루어진다면, 이는 여러분의 공급망에 관한 사실이며, 공급업체를 감사하거나 데이터 출처에 대한 질문에 답해야 하는 종류의 조직이라면 중요한 문제다. 수집하는 데이터 자체에 적용되는 GDPR 고려사항도 함께 봐야 한다.
여러분 자신의 위험 줄이기
여섯 가지 관행이 대부분을 커버한다.
모든 것에 HTTPS를 사용하라. 프록시에 국한된 조언은 아니지만, 이것이 메타데이터 문제를 유일한 문제로 만들어주는 통제 장치다. 자격 증명, 토큰, 개인 데이터는 어떤 중개자를 거치든 평문 HTTP로 절대 보내지 마라.
라우팅할 필요 없는 것은 라우팅하지 마라. 프록시는 다른 출처가 필요한 대상에 도달하기 위한 것이다. 내부 서비스, 자체 API, 지리적 위치와 무관한 인증된 세션은 직접 연결해야 하며, 이는 노출과 비용을 동시에 줄여준다.
프록시 자격 증명을 비밀 정보로 취급하라. 시크릿 매니저, 런타임 환경 변수, 가능하다면 환경별 분리된 값, 그리고 이전 값을 무효화하기 전에 클라이언트를 먼저 업데이트하는 순환 절차가 필요하다. 이전 비밀번호를 갖고 있는 모든 클라이언트는 값이 바뀌는 순간 실패하기 시작하기 때문이며, 이것이 407 시나리오다.
게이트웨이에 접근할 수 있는 시스템을 제한하라. 레지덴셜 상품은 출발지 IP가 아니라 자격 증명으로 인증하므로, 통제는 여러분 쪽에 있다. 아웃바운드 접근 규칙이나 네트워크 정책으로 어떤 워크로드가 외부와 통신할 수 있는지 제한하면, 유출된 자격 증명의 다른 곳에서의 활용도가 낮아진다. 이 트레이드오프는 화이트리스팅과 접근 제어에서 다룬다.
사용량을 감시하라. 설명되지 않는 대역폭 사용은 자격 증명이 유출되었다는 가장 명확한 신호이며, 기준선이 있어야만 이를 알아챌 수 있다. 이는 프록시 KPI에서처럼 프로젝트별로 사용량을 추적해야 하는 또 다른 이유다.
프로바이더를 검증하라. 주소를 어떻게 소싱하는지, 참여자가 동의하고 탈퇴할 수 있는지 물어라. 무엇이 얼마나 오래 로깅되는지 물어라. 어떤 관할권이 적용되는지 물어라. SLA와 가동시간에 따라 공개된 상태 페이지와 사고 이력이 있는지 물어라. 서면으로 기꺼이 답하는 프로바이더라면, 그 답변 내용과 별개로 유용한 것을 알려주고 있는 셈이다.
프록시가 여러분을 보호해주지 않는 것들
명확히 짚어야 한다. 이 부분은 양쪽 방향 모두에서 오해되기 때문이다.
프록시는 요청의 겉보기 출처를 바꾼다. 이후 로그인을 하거나, 식별 가능한 쿠키를 유지하거나, 독특한 핑거프린트를 노출한다면 프록시는 여러분을 익명화해주지 않는다. 이런 것들은 주소와 무관하게 여러분을 식별하기 때문이다. 프록시 자체가 무언가를 암호화하지도 않는다. 그것은 TLS의 역할이다. 프록시는 VPN이 아니다. 기기의 나머지 트래픽을 보호하지 않는다는 점에서 그러하며, 이것이 레지덴셜 프록시와 레지덴셜 VPN의 차이다.
그리고 프록시는 여러분에게 허용된 행위를 바꾸지 않는다. 사이트 이용약관 범위 내에서 공개 데이터를 수집하는 것은 일반적인 비즈니스 활동이다. 프록시가 금지된 행위를 허용된 것으로 만들어주지 않으며, 그 결과로부터 여러분을 보호해주지도 않는다. 이것이 웹 스크래핑은 합법인가에서 다루는 관점이다.
보안 검토를 위한 짧은 체크리스트
프록시를 거치는 모든 트래픽이 HTTPS인가. 자격 증명이 순환 절차를 갖춘 시크릿 매니저에 있는가. 프록시 사용이 필요한 워크로드로 범위가 한정되어 있고, 나머지는 아웃바운드 제어로 제한되는가. 사용량이 기준선 대비 모니터링되고 있는가. 프로바이더가 자신의 소싱 및 동의 모델, 로깅과 보존 정책, 관할권을 설명할 수 있는가. 공개된 사고 이력이 있는가. 그리고 어떻게 도달하는지와 무관하게, 여러분이 수집하는 것이 해당 규정 하에서 적절한가.
결론
레지덴셜 프록시는 여러분이 선택한 프로바이더와 여러분이 적용하는 위생 수준만큼 안전하다. HTTPS는 프로바이더가 여러분의 콘텐츠가 아니라 목적지를 본다는 것을 의미하므로, 메타데이터 문제는 실재하지만 한정적이며, 심각한 위험은 여러분의 트래픽으로 무언가를 하는 것이 비즈니스 모델인 무료 및 검증되지 않은 서비스에 있다. 소싱은 가장 중요한 질문이자 사양서가 답해주지 않는 질문이므로, 직접 물어보고 회피를 실격 사유로 취급하되, 불투명한 풀은 성능도 나쁘다는 점을 기억하라. 여러분 쪽에서는 자격 증명을 시크릿 매니저에 보관하고, 이를 사용할 수 있는 시스템을 제한하고, 사용량을 모니터링하고, 라우팅이 필요한 것만 라우팅하라. 그런 다음 프록시가 아닌 것을 기억하라. 암호화가 아니고, 익명성이 아니며, 허가가 아니다.
특정 네트워크에 대해 이 체크리스트를 적용해보고 싶다면, 레지덴셜 프록시가 해당 상품이며, GB당 가격과 문서화된 게이트웨이를 제공한다. 위에서 언급한 검증 질문들은 구매하기 전에 어떤 프로바이더에게든 던져볼 만한 바로 그 질문들이다.