GS SHOP·GS25 해킹으로 166만 명 정보유출…API 취약점 겨냥한 공격 수법 진화

핵심 요약

- 2026년 GS SHOP과 GS25에서 총 166만 명(GS SHOP 158만1025명, GS25 7만9128명)의 개인정보가 유출되는 대규모 침해사고 발생 - 해킹 수법이 단순 비밀번호 대입 공격에서 주문정보 API 취약점을 악용하는 방식으로 진화 - 유통 플랫폼의 내부 시스템과 데이터베이스를 직접 공격하는 정교한 공격 기법이 확산되고 있어 다층 방어체계 구축 필요

주요 내용

2026년 유통업계를 강타한 이번 GS SHOP·GS25 개인정보 유출 사고는 해커들의 공격 수법이 얼마나 정교하게 진화했는지를 보여주는 사례다. 과거 크리덴셜 스터핑(Credential Stuffing)이나 무차별 대입 공격(Brute Force Attack) 등 계정 탈취 중심의 공격에서 벗어나, 최근에는 주문정보 처리 API의 취약점을 직접 공격하는 방식으로 변화하고 있다.

API(Application Programming Interface)는 서로 다른 시스템 간 데이터를 주고받는 통로로, 특히 유통 플랫폼에서는 주문·결제·배송 등 핵심 비즈니스 프로세스를 처리하는 필수 인터페이스다. 공격자들은 이러한 API의 인증·인가 과정의 허점, 과도한 데이터 노출, 비정상적 요청에 대한 검증 부재 등을 악용해 대량의 개인정보에 접근했을 가능성이 크다. 이는 단순히 사용자 계정을 탈취하는 수준을 넘어 플랫폼의 핵심 시스템에 직접 침투하는 고도화된 공격이다.

GS SHOP 158만여 명, GS25 7만여 명 등 총 166만 명의 개인정보가 유출된 이번 사고는 통합 회원 관리 시스템을 운영하는 대형 유통 그룹의 특성상 피해 범위가 확대됐다. 이름을 포함한 개인식별정보가 유출되었으며, 추가적으로 어떤 정보가 노출되었는지에 따라 2차 피해 가능성도 배제할 수 없는 상황이다.

이번 사고는 디지털 전환을 가속화하는 유통업계 전반에 경종을 울리고 있다. 온라인과 오프라인을 연계한 옴니채널 전략이 확대될수록 API 기반 서비스 연동이 증가하는데, 이에 비례해 공격 표면(Attack Surface)도 넓어지고 있다. 따라서 API 보안은 더 이상 선택이 아닌 필수 보안 요소로 자리잡고 있다.

전문가 시각

ISMS-P 심사 현장에서 가장 우려스러운 부분은 많은 기업들이 웹 애플리케이션 방화벽(WAF)과 침입탐지시스템(IDS)은 구축해놓고도 정작 API 레벨의 보안 통제는 간과한다는 점이다. 특히 레거시 시스템과 신규 서비스를 연동하는 과정에서 급하게 개발된 API는 인증·인가 메커니즘이 취약하거나, 과도한 권한을 부여받은 채 운영되는 경우가 많다. 이번 GS 계열사 사고 역시 이러한 구조적 취약점이 복합적으로 작용했을 가능성이 높다.

기업들은 API 보안을 위해 OWASP API Security Top 10을 기준으로 설계 단계부터 보안을 내재화해야 한다. API 게이트웨이를 통한 중앙집중식 인증·인가 관리, API 호출 빈도 제한(Rate Limiting), 비정상 트래픽 탐지, 민감정보 최소화 원칙 적용 등이 필수적이다. 특히 주문·결제 등 개인정보를 대량으로 처리하는 API는 별도의 보안등급을 설정하고, 실시간 모니터링과 이상징후 탐지 체계를 갖춰야 한다. 또한 정기적인 모의해킹과 API 취약점 진단을 통해 지속적으로 보안 수준을 검증해야 한다.

ISMS-P 심사원 체크포인트

1. 인증 및 권한관리(2.8.2) - API 접근통제 적정성
API 엔드포인트별로 적절한 인증(Authentication)과 인가(Authorization) 메커니즘이 구현되어 있는지 점검한다. OAuth 2.0, JWT 등 표준 인증 프로토콜 적용 여부, API 키 관리 체계, 세션 타임아웃 설정, 권한별 접근 범위 제한 등을 확인한다. 특히 주문정보 조회 API처럼 개인정보를 반환하는 API는 사용자 본인 확인 절차와 최소권한 원칙이 적용되어야 한다. 개인정보보호법 제29조(안전조치의무)와 직결되는 사항이다.

2. 침해사고 예방 및 대응(2.9.1, 2.9.3) - API 모니터링 및 이상징후 탐지
API 호출 로그에 대한 실시간 모니터링 체계 구축 여부를 심사한다. 비정상적으로 많은 데이터 요청, 권한 없는 엔드포인트 접근 시도, 반복적인 인증 실패, 비정상 시간대 접근 등을 탐지할 수 있는 보안관제 체계가 있는지 확인한다. 특히 개인정보 대량 유출 가능성이 있는 API는 DLP(Data Loss Prevention) 솔루션 적용과 알림 체계 구축이 필수다.

3. 개인정보 수집·이용·제공(3.1.1~3.1.5) - API 응답 데이터 최소화
API 응답값에 불필요한 개인정보가 포함되어 과도하게 노출되는지 점검한다. 주문정보 API가 필요 이상의 개인정보(주민등록번호 전체, 상세 주소, 결제정보 등)를 반환하지 않도록 필드 레벨 접근통제와 마스킹 처리가 적용되어야 한다. 이는 개인정보보호법 제3조(개인정보 보호 원칙) 및 제16조(개인정보의 수집 제한)의 최소수집 원칙과 연결된다.

CPPG·ISMS-P 연계 포인트

API 보안 3대 원칙 (AAA: Authentication, Authorization, Audit)
- 인증(Authentication): API를 호출하는 주체가 정당한 사용자인지 확인하는 절차. API 키, OAuth 토큰, JWT 등을 활용하며, 강력한 인증 메커니즘 적용이 필수
- 인가(Authorization): 인증된 사용자가 특정 리소스에 접근할 권한이 있는지 검증. RBAC(Role-Based Access Control) 또는 ABAC(Attribute-Based Access Control)을 통해 세밀한 권한 제어 구현
- 감사(Audit): 모든 API 호출을 로깅하고 모니터링하여 이상 행위 탐지 및 사고 발생 시 추적 가능하도록 기록 보존

공격 표면 관리(Attack Surface Management)
디지털 전환과 클라우드 확산으로 기업의 공격 표면이 급격히 확대되고 있다. 특히 API, 마이크로서비스, 써드파티 연동 등이 증가하면서 외부에 노출된 자산과 잠재적 취약점을 지속적으로 식별·관리하는 것이 중요하다. API 인벤토리 관리, 섀도우 API(문서화되지 않은 API) 탐지, 외부 노출 API에 대한 정기적 취약점 진단, 불필요한 엔드포인트 비활성화 등을 통해 공격 표면을 최소화해야 한다.