보안을 논의하기 전에 결제 경로를 그리세요
상품 페이지부터 결제 폼과 복귀 화면까지 따라가며 누가 각 화면을 운영하고 민감한 정보를 어디서 입력하는지 확인하세요. 하나로 보이는 폼과 완전히 외부에 호스팅된 페이지는 기술적 경계가 다를 수 있습니다.
이 차이에 따라 보호하고 점검할 범위가 달라집니다. PCI SSC는 2017년 여러 구현 방식을 다룬 전자상거래 보안 지침을 공개했습니다. 모든 결제를 같은 시스템으로 생각하기보다 실제 구성을 이해하는 것이 출발점입니다.
필요하지 않은 정보는 수집하지 마세요
상품 판매에는 주문과 연락 정보가 필요하지만 카드번호를 직접 저장할 필요까지 있는 것은 아닙니다. 민감한 단계는 제공사가 처리하고 쇼핑몰에는 주문번호와 검증된 결과를 남기는 방법을 검토하세요.
폼이 불편하다는 이유로 고객에게 카드 정보를 이메일로 보내달라고 해서는 안 됩니다. 복사, 전달, 보관되는 장소를 늘리는 일이기 때문입니다. 입력 문제를 해결해야지 덜 통제되는 채널로 정보를 옮겨서는 안 됩니다.
쇼핑몰을 바꿀 수 있는 사람의 권한을 보호하세요
결제 페이지가 안전해도 관리자 계정이 보호되지 않으면 충분하지 않습니다. 확장 기능 설치, 결제 링크 변경, 주문 내보내기를 누가 할 수 있는지 확인하고 지원되는 범위에서 개인별 권한을 부여하세요.
소프트웨어와 확장 기능을 유지하고 사용하지 않는 요소는 제거하세요. 변경을 검토하는 담당자도 정해야 합니다. 허가되지 않은 사람이 결제 목적지를 바꿔도 팀이 알아차릴 수 있는지 생각해보세요.
제공사의 책임을 구체적으로 확인하세요
어떤 부분을 제공사가 운영하고 보안 설명을 뒷받침하는 근거가 무엇인지 물어보세요. 사업자의 의무는 구성에 따라 달라집니다. 배지나 영업 문구는 적용 범위의 설명을 대신하지 못합니다.
관련 제공사나 평가기관과 구조를 검토하세요. 호스팅 결제가 직접 다루는 정보를 줄여도 사이트 전체의 보안 작업이 없어진다는 약속은 아닙니다. 각자의 담당 범위를 기록해야 합니다.
결제 완료 메일만 보고 발송하지 마세요
결제가 완료됐다는 이메일이 왔다고 상품을 바로 발송해서는 안 됩니다. 가맹점 시스템에서 주문과 거래를 찾아 정해진 절차로 확인하세요. 고객이 보낸 화면 캡처는 문의를 이해하는 자료로 활용하되, 실제 결제 기록을 대신하게 두지 않는 것이 좋습니다.
정산 계좌 변경, 환불, 직원 접근 권한을 누가 승인하는지도 정하세요. 담당자가 퇴사하면 어떤 권한을 회수해야 하는지 확인해야 합니다. 이런 일상적인 통제가 있어야 보안 원칙이 현장에서 작동하고, 직원도 의심스러운 요청을 어디로 전달할지 알 수 있습니다.
의심스러운 변경에 대응할 절차를 준비하세요
결제 목적지나 동작이 달라지면 중단하고 조사할 방법이 있어야 합니다. 정상 설정과 확인 담당자를 기록하고 문의 직원이 낯선 결제 요청의 신고를 어디에 전달할지 알게 하세요.
고객이 예상과 다른 결제 화면을 보고했다고 가정해보세요. 대응 경로가 정해져 있으면 최초 개발자가 없을 때도 사업자가 기술적 보호 조치를 실제로 사용할 수 있습니다.
불필요한 결제 정보 처리는 줄이되 쇼핑몰 자체의 보안 책임은 명확하게 유지하세요.