[데일리시큐]과기정통부, “KT가 조사 고의로 방해했다”…경찰 수사의뢰

내용 요약

과학기술정보통신부가 KT의 소액결제 해킹 사건과 관련해 ‘조사 방해’ 의혹을 제기하며 경찰 수사를 의뢰했다. 이번 사건은 통신사 보안사고에 대해 정부가 최초로 공식 형사 수사를 요청한 사례로, 보안 및 법적 절차에 대한 깊은 이해가 필요하다.

핵심 포인트

• 소액결제 게이트웨이 보안 – 결제 데이터가 노출되는 취약점과 방어 전략
• 서버 폐기 및 데이터 소거 – 물리적, 논리적 삭제 절차와 검증 방법
• 디지털 증거 관리 – 증거 보존, 무결성 확보 및 법적 가용성

기술 세부 내용

1️⃣ Small Payment Gateway Security (소액결제 게이트웨이 보안)

1. 구조 개요
   • Front‑End: 모바일/웹 애플리케이션 → HTTPS
   • API Layer: RESTful / GraphQL → 토큰 기반 인증 (OAuth2/JWT)
   • Payment Processor: 외부 카드사/이코노미 결제 서비스
   • Database: 민감 데이터 (카드 번호, CVC, 개인 정보)를 암호화 저장 (AES‑256)
2. 주요 취약점
   • SQL Injection: 입력값 검증 미흡 시 데이터베이스 조작 가능
   • Cross‑Site Request Forgery (CSRF): 토큰이 없거나 검증이 부정확하면 부정 결제 발생
   • Weak Encryption: 암호화 키 관리 부실 → 데이터 노출
   • API Rate Limiting 미흡: Brute‑Force 공격 및 DoS 가능
3. 보안 강화 단계
   1. Input Validation – 정규식 및 허용값 범위 검사, OWASP Top‑10 가이드 적용
   2. Parameterized Queries – ORM 또는 Prepared Statements 사용
   3. Token Refresh & Rotation – JWT의 짧은 수명, Refresh 토큰 보안
   4. PCI‑DSS Compliance – 암호화, 접근 통제, 모니터링, 정기 감사
   5. Zero‑Trust Architecture – 최소 권한 원칙, MFA, 세션 세분화
   6. 침입 탐지 시스템 (IDS) – 실시간 트래픽 분석 및 알림
4. 사건 사례와 적용
   • KT 사건에서 ‘허위 자료 제출’이 언급된 것은 결제 로그, 트랜잭션 데이터, API 호출 기록을 왜곡했을 가능성이 있음
   • Forensic Readiness 를 미리 마련해 두면, 로그 및 거래 기록을 무결성 검증(해시, 타임스탬프)하여 수사 과정에서의 변조 방지

---

2️⃣ Server Disposal and Data Sanitization (서버 폐기 및 데이터 소거)

1. 폐기 단계 파악
   • Hardware decommission → 물리적 파괴 (정리)
   • Logical deletion → OS, 파티션, 파일 시스템에서 데이터 삭제
   • Media sanitization → 암호화된 데이터 영구 삭제
2. 표준 프로세스
   1. Asset Inventory – 서버 목록, 사양, 데이터 유형 기록
   2. Backup & Transfer – 중요 데이터 백업 → 별도 보안 저장소
   3. Secure Erase – OS가 제공하는 shred, sdelete, secure-delete 명령 사용
   4. Physical Destruction – HDD/SSD를 자른다, 재활용 전 파쇄
   5. Certification – 인증 기관(예: NIST SP 800‑88)에서 서명된 증명서 발급
3. 검증 기법
   • Hash Comparison – 데이터 삭제 전후 해시 비교
   • Data Recovery Test – 일정 기간 후 데이터 복구 시도
   • Audit Trail – 폐기 과정의 모든 단계에 로그 기록
4. 법적 요구사항
   • 개인정보 보호법 → 개인정보가 포함된 저장 매체는 최소 30일 이내 완전 삭제
   • 정보통신망 이용촉진 및 정보보호 등에 관한 법률 → 저장 매체 파기 시 사전 신고
5. KT 사건과의 연관성
   • “서버 폐기 시점 허위 보고”는 서버가 언제 물리적으로 파괴되었는지를 조작했음을 시사
   • 이는 증거 파괴와 직결되는 행위이며, 법적 책임을 가중시킨다.
   • 따라서, 문서화된 폐기 프로세스와 정기적인 감시가 필수

---

3️⃣ Digital Evidence Management and Forensic Readiness (디지털 증거 관리)

1. 증거 정의
   • 로그 파일 (시스템, 애플리케이션, 네트워크)
   • 트랜잭션 기록 (결제 데이터, API 호출)
   • 시스템 이미지 (디스크 플로어, 메모리 덤프)
2. 수집 단계
   1. Identify – 어떤 데이터가 증거가 될지 정의
   2. Preserve – 원본을 변경 없이 보존, Write‑Once 장치 사용
   3. Collect – FTK Imager, EnCase, Autopsy 같은 툴로 포렌식 이미지 생성
   4. Document – 수집 방법, 도구, 날짜/시간, 담당자 기록
3. 무결성 확보
   • Hashing – SHA‑256, SHA‑512 해시 계산 후, 별도 저장소에 기록
   • Chain of Custody – 증거 전달 경로를 문서화
   • Tamper‑Evident Seal – 물리적 봉인
4. 분석 단계
   • Timeline Analysis – 로그, 트랜잭션 타임스탬프 비교
   • Correlation – 다양한 소스(서버, 네트워크, 모바일) 데이터 연계
   • Data Recovery – 삭제된 파일 복구 시도
5. 법적 가용성
   • Evidence admissibility – 법정에서 증거로 인정받기 위한 기준 충족
   • Regulatory Reporting – 통신사 사고 신고 시 요구되는 문서 포맷
   • 보안 사고 통보 – 개인정보 보호법에 따라 기업은 사고 발생 후 72시간 이내에 통보
6. KT 사건에 적용
   • “허위 자료 제출”과 “핵심 증거 숨김”은 디지털 증거 관리가 실패했음을 의미
   • Forensic Readiness Plan을 수립해 두면, 사고 발생 시 즉시 증거를 체계적으로 수집·보존할 수 있다.
   • Notion 같은 협업 툴에서 증거 관리 프로세스를 문서화하고, 버전 컨트롤을 적용하면 투명성을 높일 수 있다.

---

4️⃣ Incident Response Integration (사고 대응 통합)

1. 사전 준비
   • Security Operations Center (SOC) 운영
   • Playbook 작성: 단계별 대응 절차, 연락망, 역할 분담
   • Training & Drills: 실제 공격 시나리오 기반 시뮬레이션
2. 사건 발생 시
   • Detection – IDS/IPS, SIEM에서 이상 탐지
   • Containment – 해당 서버 격리, 트래픽 차단
   • Eradication – 취약점 패치, 악성코드 제거
   • Recovery – 정상 운영 복구, 모니터링 강화
   • Lessons Learned – 사고 후 검토 회의, 프로세스 개선
3. 정부 수사와 협력
   • 공식 보고 – 사고 발생 즉시 과기정통부 신고
   • 데이터 공유 – 증거, 로그, 메타데이터를 신속 제공
   • 법적 절차 준수 – 서면 요청, 동의서, 비밀 유지 계약

---

마무리 요약

KT가 겪은 소액결제 해킹 사건은 단순 보안 사고를 넘어 서버 폐기 절차의 투명성과 디지털 증거 관리의 중요성을 재확인시켜 주는 사례다. 통신사들은 정밀한 결제 게이트웨이 보안, 철저한 서버 소거 정책, 체계적인 증거 관리 체계를 갖추어야 하며, 이는 정부 수사와의 협력에서도 핵심 역량이 된다.

---

 

출처: https://www.dailysecu.com/news/articleView.html?idxno=201302