프록시 로그 기록과 개인정보 보호

HTTPS 웹사이트에 연결할 때 프록시가 볼 수 있는 정보

설명용 경매를 예로 들면 애플리케이션이 https://bid.example/lot/218/bids에 €180의 입찰을 제출합니다. 일반 프록시 터널에서 HTTPS는 TLS 보안 프로토콜로 애플리케이션과 웹사이트의 통신을 보호합니다. 제공업체는 연결한 클라이언트 IP, 목적지 bid.example:443, 연결 시간을 볼 수 있고 전송량도 측정할 수 있습니다. 전체 URL, 선택한 경매 물품, 고객 동작, 입찰 금액, 쿠키, 경매 응답은 HTTPS 안에 남습니다. 올바른 인증서 검증과 가로채기 없는 연결이라면 제공업체는 이를 읽을 수 없습니다.

암호화된 통신이 시작되기 전에 도메인이 드러날 수 있습니다. HTTP CONNECT는 보통 목적지 호스트와 포트를 명시합니다. SOCKS5는 도메인 이름이나 IP 주소를 받을 수 있으며 애플리케이션이 도메인 이름으로 접속을 요청하면 프록시는 그 이름을 알게 됩니다. 여러 사이트가 하나의 목적지 IP를 공유할 수 있으므로 IP만으로 특정 웹사이트를 식별할 수 있는 것은 아닙니다.

평문 HTTP는 다릅니다. 헤더, 페이지 경로, 콘텐츠를 요청을 전달하는 프록시가 볼 수 있습니다. SOCKS5는 암호화되지 않은 애플리케이션 통신에 암호화를 추가하지 않습니다. SOCKS5를 통한 HTTPS는 HTTPS 보호를 유지하고, SOCKS5를 통한 HTTP는 읽을 수 있는 상태로 남습니다.

웹사이트 자체는 복호화된 요청을 받습니다. 전송한 로그인 정보, 쿠키, 양식 필드를 읽고 프록시 IP 변경 후에도 기존 계정을 알아볼 수 있습니다. HTTPS는 전송 중 데이터를 보호하며 의도한 수신자에게 데이터를 숨기지는 않습니다.

일부 제공업체가 인증서 설치를 요구하는 이유

일부 제공업체는 HTTPS 트래픽을 검사하는 특정 서비스에서 고객에게 자체 루트 인증서를 신뢰하도록 요구합니다. 방문한 웹사이트가 아닌 제공업체의 요구이며 모든 프록시에 적용되지는 않습니다. ProxyCompass는 고객에게 자체 루트 인증서 설치를 요구하지 않습니다.

일반 HTTPS 터널에서는 프록시가 요청과 응답 내용을 읽을 수 없습니다. 서비스가 제출 데이터를 확인하거나 규칙을 적용하거나 웹사이트 응답을 분석해야 한다면 그 내용에 접근해야 합니다. HTTPS 검사는 이 접근을 제공합니다. 서비스가 통과하는 트래픽을 복호화합니다.

루트 인증서는 애플리케이션이 다른 인증서를 신뢰하는 기준으로 사용하는 디지털 문서입니다. 제공업체 인증서를 신뢰 목록에 추가하면 애플리케이션은 그 제공업체가 발급한 웹사이트 인증서를 받아들일 수 있습니다. 검사 모드에서는 프록시가 웹사이트 원래 인증서 대신 이런 인증서를 제시합니다. 해당 신뢰가 없으면 일반 인증서 검증은 실패합니다.

프록시는 애플리케이션과 하나, 웹사이트와 하나, 별도의 암호화 연결 두 개를 설정합니다. 그 사이에서 요청과 응답을 읽을 수 있습니다. 설명용 경매에서는 전체 주소 https://bid.example/lot/218/bids, 물품 번호, 제출한 €180 입찰, 쿠키, 입찰 수락 응답이 드러납니다. 제공업체는 고객이 웹사이트에서 실제로 하는 일을 볼 수 있습니다.

이 요구는 특정 상품, 모드, 접속 방식에 달려 있습니다. 웹사이트 접속을 자동화하는 서비스나 프록시 관리자의 트래픽 분석을 켠 경우에 나타날 수 있습니다. “주거용”이나 “데이터센터”라는 표시만으로 적용 여부를 알 수 없습니다. 때로는 스크립트 하나에 인증서를 제공하기만 하면 되며 시스템 전체 설치는 필요하지 않습니다.

인증서를 설치하는 것만으로 모든 트래픽이 제공업체로 향하지는 않습니다. 여기서 설명하는 접근은 요청이 검사 기능이 켜진 서비스를 통과할 때 발생합니다. 프록시 자체의 HTTPS 주소를 검증하는 데만 쓰는 인증서도 대상 웹사이트 연결 내용이 복호화된다는 뜻은 아닙니다.

데이터를 읽을 수 있는 것과 로그에 저장하는 것은 별개입니다. 인증서는 연결 내용에 누가 접근할 수 있는지 설명하지만 보관 기간이나 직원 접근 권한은 알려 주지 않습니다. 인증서 검증을 꺼도 복호화하는 서비스에 데이터를 숨길 수는 없습니다.

스크레이핑 API와 원격 브라우저는 콘텐츠를 받음

스크레이핑 API에서는 서비스에 이 URL을 열고 페이지나 추출 데이터를 돌려달라는 작업을 전달합니다. 서비스가 자체적으로 웹사이트에 연결하고 읽을 수 있는 응답을 받습니다. 페이지를 가져오는 클라이언트이므로 사용자에게 인증서 설치를 요구하지 않아도 가능합니다.

제공업체가 호스팅하는 브라우저는 제공업체의 장비에서 실행됩니다. 제어 연결이 암호화되어 있어도 페이지, 쿠키, 브라우저 세션은 그곳에서 처리됩니다. 상품에 따라 작업에 전체 URL, 사용자 지정 헤더, 쿠키, 양식 데이터, 페이지 상호작용 지시가 포함될 수 있습니다.

작업 수행에 필요한 접근입니다. 모든 페이지가 보관되거나 직원이 일상적으로 고객 결과를 읽는다는 뜻은 아닙니다. 다만 작업과 결과 처리 규칙이 중요하다는 뜻입니다. 일반 프록시 터널에 관한 약속이 API나 호스팅 브라우저까지 적용되지는 않을 수 있습니다.

기업에는 모니터링 제품 목록, 검색 순서, 조사 대상 집합이 민감할 수 있습니다. 출처 페이지가 모두 공개되어 있어도 수집 내용과 활용 방식이 상업 프로젝트를 드러낼 수 있습니다.

프록시 로그에 포함될 수 있는 정보

제공업체는 여러 종류의 기록을 유지할 수 있습니다. 한곳에 저장할 필요는 없습니다. 연결에는 계정 번호를 연결하고 이메일 주소, 주문, 결제는 다른 시스템에 둘 수 있습니다.

가능한 범주이며 모든 제공업체가 반드시 수집하는 목록은 아닙니다. 서비스는 연결을 열기 위해 값을 처리하되 보관하지 않을 수 있습니다. 모든 목적지를 영구 기록하지 않고 전체 대역폭 사용량 카운터만 유지할 수도 있습니다.

로그의 클라이언트 IP는 프록시에 직접 연결한 기기나 중계자의 주소입니다. 직접 연결이면 보통 고객의 공인 IP이며, 앞에 다른 중계자가 있으면 그 중계자의 주소일 수 있습니다.

노로그 약속이 실제로 포함하는 범위

“트래픽 내용은 저장하지 않습니다”라는 설명과 목적지 도메인, 연결 시간, 사용량 기록은 양립할 수 있습니다. “사용량 합계만 보관합니다”는 다른 구성입니다. 짧은 노로그 표시는 이 중 어느 약속인지 알려 주지 않습니다.

명시된 데이터와 상품을 기준으로 읽으세요. 페이지 내용, 개별 연결 기록, 목적지 이력 또는 세 가지 모두를 제외하나요? 정상 운영만 해당하나요, 진단 로그도 해당하나요? 계정, 결제, 지원, 악용 대응 시스템에는 무엇이 남나요?

RAM 전용이라는 설명은 저장 방식을 나타냅니다. 메모리가 지워지기 전에 다른 시스템으로 전송되는지는 알려 주지 않습니다. 마찬가지로 암호화 저장은 특정 무단 접근으로부터 기록을 보호하지만 제공업체도 읽을 수 없다는 뜻은 아닙니다.

프라이빗, 전용, Elite 같은 표시는 이런 질문에 답하지 않습니다. 프록시의 다른 속성을 설명합니다. IP 확인 웹사이트는 자신에게 도착한 요청을 검사할 수 있지만 제공업체 내부의 로그 관행을 검증할 수는 없습니다.

장애, 과금, 악용 신고에 로그가 도움이 되는 방식

연결 기록은 인증 실패와 응답하지 않은 목적지를 구분하는 데 도움이 됩니다. 사용량 합계는 트래픽 허용량 소진을 설명합니다. 연결 패턴의 급격한 변화는 고장 난 스크립트나 예상치 못한 계정 사용을 드러낼 수도 있습니다.

프록시 연결 성공과 웹사이트 요청 성공을 구분하면 유용합니다. 성공한 CONNECT 응답은 터널이 열렸음을 확인합니다. 그 안에서 사이트는 여전히 CAPTCHA나 HTTP 403을 반환할 수 있습니다. 일반 터널은 암호화된 응답을 읽지 않으므로 프록시 연결 결과와 애플리케이션의 웹사이트 결과가 다를 수 있습니다.

대상 웹사이트는 다른 관점을 가집니다. 비밀번호 추측 시도를 받았다면 요청, 프록시 IP, 시간, 기타 연결 정보를 신고할 수 있습니다. 제공업체에 충분한 대응 기록이 있다면 해당 연결에 사용된 고객 계정과 신고를 연결할 수 있습니다. 웹사이트 신고에서 요청 경로를 알게 되었다고 원래 HTTPS 트래픽을 복호화했다는 뜻은 아닙니다.

공유 프록시 IP도 이런 대응을 막지 않습니다. 상세 기록은 인증된 고객 연결과 웹사이트로 나간 연결을 연결할 수 있습니다. 기록된 경우 밀리초를 포함한 정확한 시간, 포트, 목적지는 동시 연결을 구별하는 데 도움이 됩니다. 순환 IP도 같은 계정에 연결되어 있을 수 있습니다. 주소를 바꾸거나 공유해도 제공업체의 기록은 지워지지 않습니다.

기록 보관 기간

연결 로그, 청구서, 지원 티켓, 스크레이핑 결과의 보관 기간은 다를 수 있습니다. 유용한 정책은 범주별 기간이나 각 범주가 필요한 기간을 정하는 조건을 설명합니다.

대시보드에 보이는 이력이 전체 보관 기간과 같지는 않을 수 있습니다. 화면에 최근 활동만 보이면 그곳에서 볼 수 있는 범위를 알려 주는 것입니다. 내부 기록, 사고 파일, 백업의 삭제 시점을 입증하지 않습니다.

계정을 닫아도 관련 기록이 모두 삭제되는 것은 아닙니다. 적법한 보관 사유가 있으면 청구나 사고 기록이 남을 수 있습니다. 운영 시스템에서의 삭제와 백업 사본의 만료도 다른 일정으로 진행될 수 있습니다.

고객 이름을 계정 ID로 바꾸어도 회사가 ID와 고객의 연결 정보를 유지한다면 익명 기록이 되지 않습니다. 남은 정보를 계정이나 개인과 계속 연결할 수 있는지가 중요합니다.

정보에 접근할 수 있는 사람

로그 존재와 읽을 권한은 별개입니다. 지원팀은 연결 오류가, 재무팀은 결제 기록이, 보안팀은 사고 정보가 필요할 수 있습니다. 개인정보 처리방침은 접근과 공유를 설명해야 하고, 보안 통제는 필요한 사람만 접근하도록 제한해야 합니다.

재판매자와 프록시 네트워크 운영 회사는 서로 다른 기록 부분을 보유할 수 있습니다. 결제 처리업체, 호스팅 회사, 지원 플랫폼도 특정 데이터를 처리할 수 있습니다. 어떤 회사가 관여하고 어떤 정보를 받는지 확인하세요.

프록시 IP 국가만으로 고객 기록의 저장 장소나 제공업체에 적용되는 법률이 결정되지는 않습니다. 계약 회사, 처리 방식, 적용 법률도 중요합니다. 구속력 있는 법적 요구에 따라 제공업체가 보관 정보를 당국에 공개해야 할 수 있습니다. 적용 조건은 정책에서 읽어야 하며 모든 프록시 서비스에 공통인 단일 세계 규칙은 없습니다.

작업에 맞는 개인정보 조건 선택

페이지 내용을 자체 애플리케이션 안에만 보관해야 하는 프로젝트에서는 일반 HTTPS 터널과 관리형 수집 서비스의 구분이 중요합니다. 터널은 연결 메타데이터를 노출하면서도 중계자가 내용을 읽지 못하게 할 수 있습니다. 관리형 API는 직접 개발할 작업을 줄이지만 작업과 결과를 받습니다.

목적지 메타데이터도 중요할 수 있습니다. 도메인 목록, 방문 시간과 양은 팀이 조사하는 기업이나 시장을 드러낼 수 있습니다. 콘텐츠 암호화만으로 프로젝트 보호가 충분하다고 판단하기 전에 이런 정보가 민감한지 결정하세요.

마지막으로 지원팀에 직접 보내는 정보도 고려하세요. 설정 파일이나 네트워크 캡처에는 제공업체 트래픽 로그에 없던 프록시 비밀번호, 접근 토큰, 쿠키, 요청 본문이 포함될 수 있습니다. 진단 자료 공유 전 관련 없는 비밀 정보를 제거하세요.

작업 시작 전 선택한 상품이 읽을 수 있는 정보, 보관하는 정보, 삭제 시점, 수신 가능한 주체를 확인하세요. 이런 세부 내용이 있어야 개인정보 처리방침이 실제 작업에 유용합니다.