[Threat Analysis] [중소벤처기업부/창업진흥원 모두의 창업] 개인정보 유출 사고 분석과 실무적 시사점

최근 정부 유관 기관 및 대규모 공공 프로젝트를 타깃으로 한 공급망(Supply Chain) 기반의 위협과 API 취약점 악용 사례가 고도화되고 있습니다. 특히 중소벤처기업부와 창업진흥원이 추진한 대국민 창업 프로그램인 '모두의 창업' 플랫폼에서 발생한 데이터 유출 사고는 외부 조직에 의한 전통적인 침해 공격이 아닌, 내부 프로젝트 참여 수탁 업체(파트너사)에 의한 비정상적 API 호출 및 데이터 크롤링을 통해 발생했다는 점에서 강력한 기술적·관리적 시사점을 던져줍니다.

타사 침해 사례의 사후 분석(Post-Mortem)을 통해 서비스 Front-End 단계의 통제에만 의존하는 아키텍처의 한계를 짚어보고, 실무자가 자사 인프라에 즉시 반영해야 할 방어 체계와 컴플라이언스 통제 포인트를 도출하고자 합니다.

---

1. Incident Summary (사고 개요 및 규제 현황)

• 사고경위:

  일시 (2026년)	사건 내용	비고
  6월 15일 09:00	1차 합격자 프로필 공개 후, 프로젝트 참여 AI 솔루션 업체가 비정상적 API 호출 및 크롤링 시작	침해 발생 시점
  6월 15일 16:00	취약점이 노출된 서버 API 인가 차단 및 자동 수집 기능 방어 조치 적용	1차 긴급 조치
  6월 18일 전후	정보주체 통지(문자 발송) 및 국가사이버안보센터 등 외부 전문기관 합동 조사 착수	지연 통지 논란 제기

• 침해 유형 및 자산:
  • 침해 유형: API 접근 통제 우회(BOLA/BFLA), 내부 인가 업체에 의한 무단 웹 크롤링 및 데이터 마이닝.
  • 자산 영역: 플랫폼 웹/앱 API 서버 영역(도전자 프로필, 심사평, 아이디어 관리 컴포넌트).
  • 유출 데이터 항목: 화면상 비공개 설정된 참가자 개인 이메일 주소, 심사평, 창업 아이디어 요약본, 자기소개 등. (단, 실명 및 휴대전화 번호 등의 타 고유식별정보 유출은 현재까지 미확인)

• 피해 Scale: '모두의 창업' 1기 합격자 및 선정자 전원인 5,000명의 정보주체 데이터 유출.
• 법적 행정처분:
  • 현재 국가사이버안보센터 등 전문기관과 협력하여 기술 침해 사고 조사가 진행 중이며, 개인정보보호위원회의 정식 조사가 불가피할 것으로 전망됩니다.
  • 안전성 확보조치 미비(보안 취약점 방치, 접근통제 실패) 및 인지 후 지체 없는 유출 통지 위반 여부에 따라 위반 행위별 과태료 처분 및 정밀 시정명령 조치가 내려질 것으로 분석됩니다.

---

2. Root Cause Analysis (공격 벡터 및 기술적 결함 분석)

• TTPs (공격 기법):
  이번 사고의 주 공격 벡터(Threat Vector)는 외부 해킹 툴을 이용한 침투가 아니라, Insecure API Endpoints와 BOLA(Broken Object Level Authorization) 취약점의 결합입니다. 플랫폼 아키텍처상 Front-End(웹 UI) 화면에서는 사용자가 설정한 '비공개' 옵션에 따라 해당 데이터가 보이지 않도록 필터링 기능을 구현하였으나, 정작 Back-End API 서버 단에서는 적절한 접근 권한 검증(Authorization) 없이 해당 Object 데이터를 JSON 등의 페이로드(Payload)에 그대로 담아 리턴하는 구조적 결함이 있었습니다. 공격 주체(참여 AI 솔루션 업체)는 도전자 프로필 및 심사평을 호출하는 특정 API의 식별자 매개변수를 순차적으로 변조(Parameter Tampering) 및 호출하는 자동화 봇 기반의 웹 크롤링을 수행하여 대량의 비공개 데이터를 수집했습니다.
• Technical Vulnerabilities (취약점):
  • 접근통제 아키텍처 결함 및 데이터 과도 노출 (Excessive Data Exposure): Front-End 단에서의 화면 차단(UI-level hiding)에만 의존하고, 실제 Back-End API 레벨에서 요청자의 권한에 따른 필드 단위 데이터 마스킹 및 스코프(Scope) 격리 통제를 누락했습니다.
  • Rate Limiting 및 자동화 봇 탐지 미비: 단시간 내에 5,000명에 달하는 대규모 합격자 데이터 API를 순차적·연속적으로 호출하는 비정상 트래픽 패턴이 발생했음에도 불구하고, 임계치 설정 오류 또는 API Rate Limiting 통제가 작동하지 않아 대량의 크롤링 행위를 사전에 차단하지 못했습니다.
  • 공급망 위협 관리 및 SIEM 연동 공백: 내부 파트너사(수탁사) 계정 및 연동 인프라로부터 유입되는 내부 트래픽을 신뢰 대상으로만 오인하여, 이상 행위 프로파일링(Anomaly Detection) 및 실시간 SIEM(보안 정보 및 이벤트 관리) 경보(Alert) 시스템의 공백이 존재했던 것으로 유추됩니다.

---

3. Compliance Gap Analysis (법적·인증 기준 매칭)

• 규제 법령 위반 (개인정보 보호법 기준):
  • 제29조 (안전성 확보조치): 개인정보처리자는 개인정보가 분실·도난·유출·위조·변조 또는 훼손되지 아니하도록 대통령령으로 정하는 바에 따라 안전성 확보에 필요한 기술적·관리적 및 물리적 조치를 하여야 합니다. 서버 API 단의 취약점을 방치하여 비공개 정보가 무단 크롤링되도록 허용한 점은 안전성 확보조치 위반(고시 제4조 접근통제 중심)에 매칭됩니다.
  • 제34조 (개인정보 유출 통지 등): 유출을 오전에 인지했음에도 대외 통지 및 관계기관 신고 과정에서 수십 시간의 Gap이 발생했다면, "지체 없이(24시간 이내)" 통지해야 하는 법적 타임라인 준수 여부에 대해 Compliance 위반 지적을 받을 소지가 매우 높습니다.

• ISMS-P 인증 통제 항목 Gap 분석:
  • 2.6.2 (접근통제): "정보시스템과 개인정보처리스템에 접근할 수 있는 권한을 최소한으로 부여하고... 권한 없는 접근을 통제해야 한다." 화면상 비공개된 데이터가 API 다이렉트 호출로 평문 획득이 가능했다는 점은 명백한 결함 사항(지적 사항)입니다.
  • 2.10.1 (침해사고 예방 및 대응): "외부 위협뿐만 아니라 내부 위협, 웹 크롤링 등의 이상 징후를 모니터링할 수 있는 체계를 수립·운영해야 한다." 인가된 협력 업체의 대량 API API 마이닝 행위를 실시간 탐지·차단하지 못한 통제 공백이 존재합니다.
  • 2.1.3 (수탁자 관리): "개인정보 처리업무를 위탁하는 경우 수탁자를 감독하고 교육해야 한다." 사업 참여 AI 솔루션 업체의 무단 정보 수집 행위는 협력업체/수탁자 보안 관리 체계의 치명적인 Gap을 방증합니다.

---

4. Mitigation Strategies (실무자를 위한 아키텍처 보완 대책)

이와 같은 공급망 기반 API 우회 유출 사고를 원천 예방하기 위해, 실무자는 운영 중인 시스템 아키텍처에 아래의 기술적 보안 통제를 즉시 검토 및 반영해야 합니다.

[1] Zero Trust 기반 API Gateway 권한 검증 (BOLA 방어)

• Front-End의 숨김 처리에 의존하지 말고, API Gateway 및 Back-End 라우터 단에서 요청자의 세션 토큰(JWT 등) 내 사용자 권한 스코프를 조회 대상 Object ID와 상호 매핑 검증하는 로직을 필수로 구현해야 합니다.
• API 응답 데이터 세트(Response Payload) 구성 시, 필요 최소한의 데이터 필드만 선택적으로 직렬화(Serialization)하여 반환하는 화이트리스트 기반 Data 이그레스(Egress) 필터링을 적용합니다.

[2] 인프라 전반의 적응형 Rate Limiting & 쓰로틀링(Throttling) 정책 적용

• 특정 IP, 특정 API 토큰, 혹은 동일 서브넷으로부터 인입되는 API 요청에 대해 초당/분당 최대 요청 임계치(예: 분당 최대 60회 제한)를 설정하는 Rate Limiting을 필수 적용합니다.
• 특히 프로필 조회, 자산 내려받기 등 대량의 개인정보 결합이 가능한 Endpoint에는 가중치를 높게 부여하여 누적 요청 발생 시 세션을 즉시 차단(Drop) 또는 챌린지(CAPTCHA 등) 페이지로 리다이렉트 시킵니다.

[3] 수탁사 및 서드파티 연동 파트너 대상 '최소 권한(Least Privilege)' 적용

• 프로젝트에 참여하는 협력업체나 AI 솔루션 연동용 API Key는 일반 사용자 API와 인프라 단에서 물리적·논리적으로 격리(Network Segmentation)해야 합니다.
• 수탁사 전용 API Endpoints를 별도 개설하고, 해당 파트너사가 비즈니스 목적상 접근해야 하는 데이터 격리 스코프 외의 데이터(예: 이메일, 심사평 전체 데이터셋 등)에 접근을 시도할 경우 즉시 HTTP 403 Forbidden을 반환하도록 아키텍처를 세분화합니다.

[4] AI 기반 봇/크롤링 탐지 및 WAF 행동 프로파일링 활성화

• 웹 애플리케이션 방화벽(WAF) 및 웹 안티봇(Anti-Bot) 솔루션을 연동하여 헤더 정보 변조, Payload 구조 분석, 요청 주기 간격 등을 실시간 분석합니다.
• 정상적인 브라우저 접근이 아닌 스크립트 기반(Python, Node.js, 웹 크롤러 등) 유입 트래픽 패턴을 탐지하여 API 스캐닝 공격 벡터를 실시간 방어합니다.

---

5. Conclusion & Takeaway

이번 중기부 '모두의 창업' 개인정보 유출 사고는 우리에게 매우 무거운 예방적 교훈을 줍니다. 보안 가시성(Visibility)과 회복 탄력성(Resilience)은 단순히 외부 악성 해커의 방화벽 차단에 그치지 않고, "인가된 파트너사와 내부 연동 모듈조차 완전히 신뢰하지 않는다"는 제로 트러스트(Zero Trust) 거버넌스의 확립에서 시작됩니다.

특히 대외 서비스를 개발할 때 Front-End 디자인의 보안성에만 치중하고 Back-End API의 엄격한 데이터 필터링을 간과한다면, 서비스 오픈과 동시에 모든 자산이 크롤링 위협에 노출될 수 있습니다. 공급망 보안과 API 시큐리티 코딩, 그리고 이상 징후 실시간 모니터링 체계가 유기적으로 맞물려야만 진정한 Compliance 컴플라이언스를 달성할 수 있음을 명심해야 합니다.

---

자료 출처

• 아이뉴스24 - "'모두의 창업' 개인정보 유출, 프로젝트 참여업체 소행"
• 뉴스1 - "'모두의 창업' 정보 유출, 해킹 주체는 프로젝트 참여 기업"
• 연합뉴스 - "6만명 몰린 정부 초대 창업 프로젝트…개인정보 유출로 '오점'"