프록시 공급업체에 어떤 질문지 양식을 보내야 하나요?

회사에서 이미 공급업체용으로 사용 중인 표준, 보통 Shared Assessments SIG나 Cloud Security Alliance CAIQ에서 시작한 다음, IP 소싱과 동의, 공급업체가 로깅하는 항목, 남용 처리에 관한 짧은 프록시 전용 섹션을 추가하세요. 일반적인 질문지는 이런 질문을 하지 않습니다.

SOC 2 보고서만으로 프록시 제공업체를 승인하기에 충분한가요?

좋은 출발점이기는 하지만 답의 전부는 아닙니다. 일정 운영 기간을 다루는 Type 2 보고서인지, 어떤 서비스와 시스템이 범위에 포함되는지, 작성된 지 얼마나 되었는지 확인하세요. SOC 2 보고서는 레지덴셜 IP가 어떻게 소싱되었는지에 대해서는 전혀 언급하지 않으므로 이는 별도로 질문해야 합니다.

레지덴셜 프록시 공급업체에는 왜 추가 질문이 필요한가요?

출구 IP가 다른 사람들의 기기에 속해 있기 때문입니다. 이러한 기기가 실제 동의 없이 등록되었다면, 귀하의 트래픽은 차단되거나 범죄 활동과 연관될 수 있는 네트워크를 통과하게 됩니다. 법 집행기관은 감염된 기기로 구축된 레지덴셜 프록시 봇넷을 해체한 사례가 있으므로, 소싱은 실질적인 위험 질문입니다.

프록시 공급업체는 우리 트래픽의 무엇을 볼 수 있나요?

HTTPS의 경우 공급업체는 귀하가 연결하는 목적지 호스트, 타이밍, 데이터 양을 볼 수 있지만 암호화된 내용은 볼 수 없습니다. 일반 HTTP의 경우에는 모든 것을 볼 수 있습니다. 무엇이 로깅되는지, 얼마나 오래 보관되는지, 누가 접근할 수 있는지 질문하세요.

InfoSec 팀이 프록시 벤더에게 보낼 보안 질의서

프록시 공급업체는 여러분의 트래픽 경로 상에 위치합니다. 스크레이퍼, 모니터링 작업, 테스트 스위트가 자격 증명을 첨부한 채로 해당 네트워크를 통해 요청을 보내는 경우가 많기 때문에, 레지덴셜 프록시 플랜이 승인되기 전에 보안 팀은 서면으로 된 답변을 원할 것입니다.

대부분의 기업은 Shared Assessments SIG나 Cloud Security Alliance의 CAIQ(Cloud Controls Matrix에 매핑된 예/아니오 질문 세트) 같은 표준 설문지에서 시작합니다. 이런 설문지는 모든 공급업체에 해당하는 기본 사항을 다룹니다. 프록시 네트워크는 이런 설문지가 묻지 않는 몇 가지 추가 질문, 주로 IP가 어디서 왔는지와 공급업체가 무엇을 볼 수 있는지를 제기합니다. 이 체크리스트는 두 가지 모두를 섹션별로 다루며, 좋은 답변이 어떤 모습인지도 제시합니다.

이는 일반적인 정보이며 법률이나 감사 자문이 아닙니다.

프록시 공급업체가 별도의 검토를 받는 이유

프록시 공급업체를 일반적인 SaaS 공급업체와 구별하는 세 가지가 있습니다.

트래픽을 볼 수 있습니다. HTTPS 요청의 경우 공급업체는 여러분이 연결하는 호스트, 시간, 용량을 볼 수 있습니다. 일반 HTTP의 경우 내용까지 볼 수 있습니다.
돈을 쓸 수 있는 자격 증명을 보유합니다. 유출된 프록시 비밀번호가 있으면 다른 누군가가 여러분의 계정으로 트래픽을 실행할 수 있습니다.
출구 IP는 다른 사람의 소유입니다. 레지덴셜 IP와 모바일 IP는 실제 사람들의 기기에서 나옵니다. 이런 기기가 어떻게 네트워크에 합류했는지는 공급업체뿐 아니라 여러분에게도 법적, 평판적 문제입니다.

마지막 항목은 단순한 이론이 아닙니다. 2024년 5월 미국 법무부는 VPN 프로그램과 번들 설치 프로그램을 통해 악성코드를 퍼뜨려 구축된, 1,900만 개 이상의 고유 IP 주소와 연관된 레지덴셜 프록시 서비스인 911 S5 봇넷을 해체했다고 발표했습니다. 2025년 5월 FBI는 범죄형 프록시 서비스가 수명이 다한 가정용 라우터에 프록시를 설치하고 있다고 경고했습니다. 2026년 1월 Google의 Threat Intelligence Group은 IPIDEA 네트워크를 와해시킨 사례를 설명하며, 해당 네트워크의 출구 노드가 550개 이상의 위협 그룹에 의해 사용되는 것을 관찰했다고 밝혔고, 윤리적 소싱에 대한 주장은 “투명하고 감사 가능한 사용자 동의 증거로 뒷받침되어야 한다”고 결론지었습니다.

섹션 1: IP 소싱과 동의

레지덴셜 및 모바일 IP는 어떻게 확보됩니까: 파트너 앱 내 SDK, 대역폭 공유 앱, ISP 계약 중 어느 것입니까?
기기 소유자가 보는 동의 화면을 보여줄 수 있습니까, 그리고 어떻게 철회합니까?
SDK를 탑재한 파트너 앱을 감사합니까, 규칙을 위반한 경우 어떻게 됩니까?
다른 네트워크로부터 IP를 구매하거나 재판매합니까?

좋은 답변: 구체적으로 명시된 소싱 모델, 확인 가능한 동의 흐름, 감사 프로세스. 위험 신호: 아무런 근거 없이 “저희 IP는 윤리적으로 소싱됩니다”라는 답변. 공급업체가 레지덴셜 IP를 소싱하는 방법에 대한 가이드에서 모델과 기대해야 할 증거를 설명합니다.

섹션 2: 공급업체가 보고 기록하는 것

어떤 요청 데이터를 기록합니까: 출발지 IP, 목적지 호스트, 타임스탬프, 바이트, 전체 URL?
각 로그는 얼마나 오래 보관되며, 회사 내 누가 접근할 수 있습니까?
트래픽을 검사하거나 수정합니까, 예를 들어 TLS를 가로채는 방식으로?
제3자에게 로그를 공개할 것입니까, 어떤 법적 절차 하에서입니까?

좋은 답변: 필드별 목록과 보관 기간, TLS 가로채기 없음. 위험 신호: 대역폭과 목적지로 요금을 청구하는 공급업체가 무언가는 집계해야 함에도 “저희는 아무것도 기록하지 않습니다”라고 답하는 경우. 레지덴셜 프록시가 안전한지에 관한 저희 글에서 프록시가 볼 수 있는 것과 볼 수 없는 것을 다룹니다.

섹션 3: 접근 제어와 자격 증명

어떤 인증 방법을 지원합니까: 사용자 이름과 비밀번호, IP 허용목록, 둘 다?
팀, 프로젝트, 환경별로 별도의 자격 증명을 만들고, 나머지에 영향을 주지 않고 하나만 취소할 수 있습니까?
대시보드가 싱글 사인온과 다중 요소 인증을 역할과 함께 지원합니까?
계정 변경과 자격 증명 재설정에 대한 감사 로그가 있습니까?

좋은 답변: 프로젝트별 자격 증명이 각자의 한도를 가지며, 대시보드에 MFA가 적용됨. 팀이나 클라이언트별로 분리된 서브유저는 어떤 작업이 무엇을 사용했는지 확인할 수 있게 해줍니다.

섹션 4: 전송 중 암호화

대시보드, API, 프록시 엔드포인트는 어떤 TLS 버전을 허용합니까?
클라이언트에서 프록시 자체로의 연결을 암호화할 수 있습니까?

좋은 답변: TLS 1.2 이상이며 TLS 1.3을 지원함. 미국 연방 시스템을 위한 NIST 지침(SP 800-52 Rev. 2)이 이 기준을 설정하며, 이는 어떤 공급업체에게도 합리적인 기준입니다.

섹션 5: 감사와 인증

SOC 2 보고서를 보유하고 있습니까? Type 1인지 Type 2인지, 어느 기간인지, 어떤 Trust Services 범주(보안, 가용성, 처리 무결성, 기밀성, 프라이버시)입니까?
ISO/IEC 27001:2022 인증을 받았습니까, 범위는 무엇입니까?
가장 최근의 독립 침투 테스트는 언제였으며, 요약본을 볼 수 있습니까?

좋은 답변: 범위에 청구 웹사이트뿐 아니라 프록시 인프라까지 포함하는 최근의 Type 2 보고서. Type 1 보고서는 특정 시점에 통제가 적절히 설계되었다는 것만 말해주며, Type 2는 일정 기간 동안 효과적으로 운영되었는지에 대한 의견을 추가합니다. 위험 신호: 범위가 여러분이 사용할 시스템을 제외하는 인증서.

섹션 6: 데이터 보호와 하위 처리자

데이터 처리 계약(DPA)에 서명할 것입니까? GDPR 제28조에 따르면, 처리자는 문서화된 지시에 따라서만 행동해야 하며 다른 처리자를 참여시키기 전에 컨트롤러의 사전 서면 승인이 필요합니다.
어떤 하위 처리자를 사용합니까(호스팅, 로깅, 결제), 어느 국가에서입니까?
제30조가 처리자에게 요구하는 처리 활동 기록을 보관합니까?

좋은 답변: 표준 DPA, 공개된 하위 처리자 목록, 변경 시 통지 기간. 더 넓은 GDPR 관련 내용은 레지덴셜 프록시와 GDPR 준수에 관한 저희 가이드를 참고하세요.

섹션 7: 사고와 악용

저희 계정이나 데이터에 영향을 미치는 보안 사고에 대해 어떻게, 얼마나 빨리 알려줄 것입니까? GDPR 제33조는 처리자가 “부당한 지체 없이” 컨트롤러에게 통지하도록 요구하며, 컨트롤러는 가능한 경우 72시간 이내에 당국에 통지해야 합니다.
귀사의 네트워크에서 발생한 트래픽에 대한 악용 신고를 어떻게 처리합니까?
어떤 대상과 용도를 차단합니까, 고객을 검증합니까?

좋은 답변: 지정된 연락처, 계약상의 통지 의무, 시행되는 서면 수용 가능 사용 정책. 악용 통제는 여러분도 보호합니다. 모든 고객은 동일한 IP의 평판을 공유합니다.

섹션 8: 지속성과 종료

어떤 가동 시간을 약속합니까, 어떻게 측정됩니까, 미달 시 구제책은 무엇입니까?
서비스를 중단할 경우 저희는 데이터를 어떻게 받고 자격 증명을 어떻게 종료합니까?

한 페이지로 보는 설문지

섹션	요청할 것	위험 신호
소싱	동의 흐름, 소싱 모델, 파트너 감사	증거 없는 “윤리적으로 소싱됨”
로깅	로그별 필드 목록과 보관 기간	”저희는 아무것도 기록하지 않습니다”
접근	프로젝트별 자격 증명, MFA, 감사 로그	회사당 공유 비밀번호 하나
암호화	TLS 1.2+, 1.3 지원	평문 대시보드 또는 API
감사	프록시 범위를 포함한 SOC 2 Type 2 또는 ISO 27001	네트워크를 제외하는 범위
데이터 보호	DPA, 하위 처리자 목록	EU 고객용 DPA 없음
사고	계약상 통지, 악용 정책	지정된 보안 연락처 없음

결론

프록시 공급업체는 여러분의 트래픽에 닿는 다른 모든 공급업체와 동일한 검토를 받을 자격이 있으며, 여기에 프록시 네트워크만이 제기하는 몇 가지 질문이 추가됩니다. 표준 설문지를 보내고, 위의 소싱, 로깅, 악용 관련 섹션을 추가하며, 진술이 아니라 증거를 요구하세요. 이 답변들은 가격 페이지보다 네트워크에 대해 더 많은 것을 알려줄 것입니다.

출처 및 참고 자료

미국 법무부, 911 S5 봇넷 해체 (2024년 5월 29일): justice.gov
Google Threat Intelligence Group, 최대 규모 레지덴셜 프록시 네트워크 와해 (2026년 1월): cloud.google.com
FBI, 수명이 다한 라우터를 악용하는 사이버 범죄 프록시 서비스 (2025년 5월): ic3.gov
Cloud Security Alliance, Cloud Controls Matrix 및 CAIQ: cloudsecurityalliance.org
Shared Assessments, SIG 설문지: sharedassessments.org
AICPA, SOC 2 보고: aicpa-cima.com
ISO/IEC 27001:2022: iso.org
GDPR, 제28조, 제30조, 제33조: eur-lex.europa.eu
NIST SP 800-52 Rev. 2: csrc.nist.gov