방화벽은 있었지만 막지 못했다: 쇼핑몰 11만 명 유출과 과징금 판결

아프로·2026년 11월 5일

방화벽은 있었지만 막지 못했다 표지

11만 9,856명. 건강기능식품을 만들어 파는 A사의 온라인 쇼핑몰에서 2022년 9월 해킹으로 유출된 고객 수입니다. A사에는 방화벽과 침입방지시스템이 있었습니다. 개인정보보호위원회는 과징금 4억 6,457만 원을 부과했고, A사는 "업종과 규모에 맞는 주의를 다했다"며 소송을 냈습니다. 서울행정법원은 2024년 4월 A사 패소로 판결했습니다.

사고 원인: 보안 장비는 있었지만 암호화된 트래픽 안을 보지 못했고, 해커가 쇼핑몰 관리용 도메인에 접속한 것도 탐지하지 못했습니다. 법원은 장비가 접근 제한과 유출 탐지 기능을 제대로 하지 못했다고 봤습니다.

이번 편부터 「중소기업편」입니다. 통신사나 대형 플랫폼이 아닌 회사에서 일어난 사고와 제재를 다룹니다. 회사 이름은 판결 보도처럼 A사로 적습니다. 판결 내용은 2024년 6월 10일 머니투데이와 법률신문 보도 기준이며, 해커가 쓴 기법은 보도에 없어 다루지 않습니다.

한눈에 보기

항목내용
회사A사. 건강기능식품 제조·판매, B 온라인 쇼핑몰 운영
사고2022년 9월경 해킹으로 고객 개인정보 유출
규모11만 9,856명(머니투데이), 11만 9,000여 명(법률신문)
통지·신고유출 회원에게 6차례 통지, 개인정보위에 신고(법률신문)
처분개인정보위가 약 4개월 조사 뒤 2023년 3월 과징금 4억 6,457만 원
판결2024년 4월 18일 서울행정법원 행정2부, A사 패소
이후A사는 2024년 4월 항소(머니투데이, 2024년 6월 보도 기준)

무슨 일이 있었나

  • 2022년 9월경: B 쇼핑몰이 해커의 공격을 받아 고객 개인정보가 유출됩니다.
  • 그 뒤: A사는 유출된 회원들에게 6차례에 걸쳐 유출 사실을 알리고 개인정보위에 신고합니다.
  • 약 4개월: 개인정보위가 A사의 개인정보 취급·운영 실태와 법 위반 여부를 조사합니다.
  • 2023년 3월: 개인정보위가 기술적·관리적 보호조치 기준 위반을 인정하고 과징금 4억 6,457만 원을 부과합니다.
  • 2024년 4월 18일: 서울행정법원 행정2부가 A사의 과징금 부과처분 취소 청구를 받아들이지 않습니다. 법률신문은 사건번호를 2022구합66443으로 적었습니다.
  • 2024년 4월: A사가 항소합니다.

쇼핑몰 유출 경로: 관리용 도메인 접속과 암호화된 트래픽이 보안 장비를 지나 개인정보 유출로 이어진 흐름, 그리고 막을 수 있었던 세 지점

판결 보도에 나온 사실만으로 그린 원리 수준의 흐름입니다.

  1. 관리용 도메인. 해커는 쇼핑몰의 관리용 도메인에 접속했습니다. A사는 이 도메인을 다른 회사가 관리했다고 주장했습니다.
  2. 암호화된 트래픽. 침입방지시스템(IPS, 오가는 트래픽에서 공격 모양을 찾아 막는 장비)에는 암호화된 트래픽을 탐지·차단할 수 있는 인증서가 설치돼 있지 않았습니다. 그래서 암호화된 채 오가는 유해 트래픽을 볼 수 없었습니다.
  3. 탐지되지 않은 유출. 관리용 도메인 접속은 탐지되지 않았고, 법원은 장비의 유출 탐지 기능도 제대로 작동하지 않았다고 봤습니다.

왜 뚫렸나

장비는 있었고, 기능이 비어 있었다 (법원 판단)

머니투데이는 법원이 "A사가 운영한 방화벽과 침입방지시스템이 접근제한과 유출탐지 기능을 제대로 하지 못해" 해킹이 일어난 것으로 봤다고 전했습니다. 법률신문은 그 근거를 두 가지로 적었습니다.

  • IPS에 인증서가 없었습니다. 요즘 웹 트래픽은 대부분 TLS(전송 구간 암호화)로 오갑니다. 장비가 그 안을 검사하려면 복호화에 쓸 인증서가 있어야 합니다. 인증서가 없으니 장비는 암호화된 유해 트래픽을 탐지할 수 없었습니다.
  • 관리용 도메인 접속이 탐지되지 않았습니다. 쇼핑몰 운영자가 쓰는 관리 경로에 해커가 들어왔지만 장비는 이 접속을 잡아내지 못했습니다.

법원은 이를 근거로 A사가 "사회 통념상 합리적으로 기대할 수 있는 수준의 보호조치"를 다했다고 볼 수 없다고 판단했습니다(법률신문).

"다른 회사가 관리하는 도메인"이라는 주장

A사는 유출이 생긴 곳이 다른 주식회사가 관리하는 쇼핑몰 관리용 도메인이고, 자사가 직접 관리하는 대표 도메인은 아니었다고 주장했습니다. 법원은 판단 이유에서 해커의 관리용 도메인 접속이 탐지되지 않은 점을 보호조치 부족의 근거로 들었습니다(법률신문). A사의 주장은 받아들여지지 않았습니다.

과징금이 과하다는 주장

A사는 처분이 지나치게 과하다고도 주장했습니다. 법원은 A사의 재무상태표에 적힌 현금, 예금, 당좌자산 등을 보면 과징금을 낼 능력이 현저히 부족하다고 보기 어렵다고 했습니다. 비례 원칙이나 평등 원칙에 어긋나거나 재량권을 넘어 쓴 처분도 아니라고 봤습니다(머니투데이).

개발자 시점: 내 서비스였다면

사고 회사의 코드가 아니라 같은 실수를 보여 주는 일반 예시입니다. 값은 모두 가짜입니다. 장비가 암호화된 트래픽을 보지 못해도, 애플리케이션과 웹 서버는 복호화된 요청을 직접 받습니다. 그 자리에서 할 수 있는 두 가지를 봅니다.

관리 경로: 누구나 열 수 있는 관리용 도메인

위험한 모양

# 관리용 도메인 (일반 예시)
server {
    listen 443 ssl;
    server_name admin.example.com;
    location / {
        proxy_pass http://shop-admin:8080;
    }
}
# 인터넷 어디서나 접속 가능
# 접속 기록은 공통 로그에 섞여 아무도 보지 않음

관리 화면의 로그인 창이 인터넷 전체에 열려 있습니다. 비밀번호 하나만 맞히면 고객 목록까지 닿고, 그 접속은 다른 요청과 구분되지 않습니다.

고친 모양

server {
    listen 443 ssl;
    server_name admin.example.com;
    allow 192.0.2.0/24;   # 사무실·VPN 대역만
    deny  all;            # 나머지는 403
    access_log /var/log/nginx/admin-access.log;
    location / {
        proxy_pass http://shop-admin:8080;
    }
}
  • 접속 대역 제한. 관리용 도메인은 정해 둔 사무실·VPN 대역에서만 열립니다. 외부 관리 업체가 있다면 그 업체의 고정 대역도 계약서에 적고 같은 목록으로 관리합니다.
  • 관리 접속 기록 분리. 관리 경로 기록을 따로 쌓으면 허용 목록 밖의 시도와 처음 보는 IP를 골라 경보를 걸기 쉽습니다.

유출 탐지: 몇 건을 가져갔는지 세지 않는 조회

위험한 모양

// 관리자 회원 목록 (일반 예시)
@GetMapping("/admin/members")
public Page<Member> list(Pageable p) {
    return members.findAll(p); // size=100000도 통과
}
// 누가, 어디서, 몇 건을 봤는지 세지 않음

한 번에 10만 건을 달라는 요청도 그대로 처리합니다. 고객 전체가 몇 번의 요청으로 빠져나가도 서비스는 평소와 같은 응답을 보냈을 뿐입니다.

고친 모양

@GetMapping("/admin/members")
public Page<Member> list(Pageable p, Principal who,
                         HttpServletRequest http) {
    int size = Math.min(p.getPageSize(), 50); // 상한
    Page<Member> page = members.findAll(
        PageRequest.of(p.getPageNumber(), size));
    long total = readMeter.add(who.getName(),
        page.getNumberOfElements(), Duration.ofMinutes(10));
    if (total > 500) {                // 10분에 500건 초과
        alerts.send("security@example.com",
            "대량 조회 " + total + "건: " + who.getName()
            + " / " + http.getRemoteAddr()); // 192.0.2.10
    }
    return page;
}
  • 한 번에 가져가는 양의 상한. 페이지 크기를 50건으로 묶어 한 요청으로 전체를 받지 못하게 합니다.
  • 계정별 조회량 집계. 계정마다 10분 동안 본 개인정보 건수를 셉니다. 기준값 500은 예시이며, 평소 업무량을 보고 정합니다.
  • 사람이 받는 경보. 기준을 넘으면 계정과 IP를 담아 보안 담당 주소로 알립니다. 경보를 받을 사람과 받은 뒤 할 일을 함께 정해 둡니다.

요청 수를 세는 속도 제한은 GS리테일·티머니·알바몬: 비밀번호가 맞아도 막아야 했던 로그인(07편)에서, 외부 제보로 침입을 안 사례는 더존비즈온 해킹: 제보 메일로 안 침입과 백업 서버의 암호화 데이터(11편)에서 다뤘습니다.

막을 수 있었던 세 지점

  1. 관리용 도메인을 정해 둔 대역에서만 열었다면 외부인이 관리 경로에 닿기 어려웠습니다. 관리를 다른 회사에 맡겼다면 그 회사의 접속 범위까지 계약과 설정으로 정해 둡니다. 관리자 계정 관리는 지우지 않은 관리자 계정 하나: 발란 162만 건 유출(14편)에서 이어집니다.
  2. 암호화가 풀리는 지점에서 검사했다면 장비가 보지 못한 트래픽도 확인할 수 있었습니다. IPS에 인증서를 설치하거나, 웹 서버·애플리케이션 단에서 요청을 기록하고 검사하는 방법이 있습니다.
  3. 대량 조회와 대량 전송에 경보를 걸었다면 개인정보가 빠져나가는 동안 알아챌 수 있었습니다.

방화벽과 IPS는 설치로 끝나는 장비가 아니라, 무엇을 막고 무엇을 알릴지 규칙을 채워야 제대로 작동하는 장비입니다. 이번 판결에서 법원이 본 것도 장비가 있었는지보다 그 기능이 실제로 작동했는지였습니다.

같은 사고를 막는 점검 5줄

  • 관리용 도메인·관리자 페이지를 사무실·VPN 대역에서만 열고, 외부 관리 업체의 접속 범위도 문서로 정한다.
  • 침입방지시스템이 암호화된 트래픽을 검사하는지 확인하고, 못 한다면 복호화 뒤 단계에서 기록·검사한다.
  • 개인정보 목록 API에 페이지 크기 상한을 두고, 계정별 조회 건수를 집계한다.
  • 대량 조회·대량 전송·처음 보는 IP의 관리 접속에 경보를 걸고, 받는 사람을 정한다.
  • 보안 장비는 탐지 규칙이 켜져 있는지, 경보가 실제로 사람에게 가는지 정기적으로 확인한다.

제재와 비용

  • 개인정보위(2023년 3월): 기술적·관리적 보호조치 기준 위반으로 과징금 4억 6,457만 원.
  • 서울행정법원(2024년 4월 18일): 처분이 정당하다며 A사 패소. 납부 능력, 비례·평등 원칙, 재량권 문제도 받아들이지 않았습니다.
  • 항소: A사는 2024년 4월 항소했습니다. 이 글이 참고한 보도 이후의 결과는 확인하지 못해 적지 않습니다.

판결 보도에는 과징금의 근거 조문과 세부 산정 기준이 나오지 않습니다. 중소기업에 부과되는 과징금이 어떻게 늘고 있는지, 2026년 9월 시행된 개정 개인정보 보호법이 무엇을 바꿨는지는 다음 편에서 정리합니다. 이 글은 법률 자문이 아닙니다.

정리

  • A사에는 방화벽과 침입방지시스템이 있었지만, 암호화된 트래픽 안과 관리용 도메인 접속을 보지 못했습니다.
  • 법원은 장비가 접근 제한과 유출 탐지 기능을 제대로 하지 못했다며 과징금 4억 6,457만 원이 정당하다고 판결했습니다.
  • 관리 경로 접속 제한, 조회량 상한과 집계, 사람이 받는 경보가 같은 빈틈을 메웁니다.

더 깊게

  • 인프런 「백엔드 개발자를 위한 서버 보안 실무」
    • 6-2 탐지하고 자동으로 막기: 서버와 애플리케이션 이상 징후
    • 4-4 Rate limiting과 멱등성 키 설계
    • 5-5 정보유출을 막는 네 가지: 이그레스 통제와 DLP
    • 0-4 공격자처럼 생각하기: 위협 모델링과 공격 표면 지도

보안을 더 알고 싶다면

오늘 본 사고의 원인은 대부분 서버와 코드의 기본기에서 막을 수 있는 것들이었습니다. 직접 손으로 막아 보고 싶다면 이런 강의도 있습니다.

백엔드 개발자를 위한 서버 보안 실무: 해킹 방어부터 정보유출 방지까지

  • 서버를 공격하는 흐름을 로그로 보고, 내 서버와 Spring·Express 코드에서 직접 막아 봅니다.
  • SSH 하드닝, 인젝션, 인증·인가, 시크릿과 개인정보 보호, 침해사고 첫 한 시간까지 8개 섹션 54개 수업입니다.
  • 이 글과 이어지는 수업: 6-2 탐지하고 자동으로 막기: 서버와 애플리케이션 이상 징후, 4-4 Rate limiting과 멱등성 키 설계, 5-5 정보유출을 막는 네 가지: 이그레스 통제와 DLP

출처와 확인 날짜

판결 내용은 2024년 6월 10일 보도 기준이며, 2026년 11월 5일에 다시 확인했습니다. 항소심 결과에 따라 바뀔 수 있고, 이 글은 법률 자문이 아닙니다.


이전 글 지우지 않은 관리자 계정 하나: 발란 162만 건 유출
다음 글 중소기업 과징금 1년 새 27배: 매출 10% 개정법과 첫 72시간
시리즈 전체 목록 해킹 사고 해부 전체 목록

profile
고인물 개발자(OG)

0개의 댓글