정부 '모두의창업' 개인정보 무단접근 사고...ISMS-P 접근통제 점검 필요

핵심 요약

- 2026년 정부 창업 프로젝트 '모두의창업'에서 합격자 개인정보 무단접근 사고 발생 - 합격자 공개 프로필 게시 후 비공개 정보에 대한 접근권한 통제 실패 - 대국민 서비스에서의 접근통제 및 권한관리 미흡 사례로 ISMS-P 인증기준 위반 소지

주요 내용

2026년 6월, 정부가 주도하는 대표적인 창업 지원 프로젝트 '모두의창업'에서 참가자 개인정보 유출 사고가 발생하며 정부 주도 사업의 보안 관리 체계에 대한 우려가 커지고 있다. 이번 사고는 합격자 명단 및 공개 프로필이 정상적으로 게시된 이후, 비공개로 분류되어야 할 개인 상세정보에 무단으로 접근할 수 있는 취약점이 발견되면서 발생했다.

문제가 된 것은 접근권한 설정의 불완전성이다. 공개용 프로필과 내부 관리용 개인정보가 동일한 시스템 내에서 관리되면서도, 접근 권한이 제대로 분리되지 않아 일반 사용자도 URL 조작이나 간단한 파라미터 변경만으로 민감 정보에 접근할 수 있었던 것으로 파악된다. 이는 전형적인 수평적 권한 상승(Horizontal Privilege Escalation) 취약점으로, 웹 애플리케이션 개발 단계에서 반드시 점검해야 할 기본적인 보안 항목이다.

정부 주도 대국민 서비스는 그 특성상 다수의 국민이 참여하고 민감한 개인정보를 수집하는 경우가 많아, 일반 민간 서비스보다 더 엄격한 보안 기준이 적용되어야 한다. 특히 창업 프로젝트의 경우 사업계획서, 아이디어, 개인 재무정보 등 고도의 민감정보가 포함될 수 있어 유출 시 2차 피해(아이디어 도용, 금융사기 등)로 이어질 위험이 크다.

이번 사고는 최근 증가하고 있는 랜섬웨어 공격이나 공급망 공격과는 다른 양상이지만, 기본적인 접근통제 실패라는 점에서 더욱 심각하다. 고도의 공격 기법이 아닌 기본 보안 원칙의 미준수로 인한 사고이기 때문이다.

전문가 시각

ISMS-P 심사 현장에서 가장 자주 발견되는 부적합 사항 중 하나가 바로 '접근권한 관리 미흡'이다. 특히 웹 기반 서비스의 경우 프론트엔드에서 메뉴를 숨기거나 버튼을 비활성화하는 것만으로 접근통제가 완료되었다고 오해하는 경우가 많다. 그러나 실제로는 서버 측(Back-end)에서 사용자의 권한을 검증하고, 세션 정보와 요청된 리소스에 대한 접근 권한을 매 요청마다 확인해야 한다. 이번 '모두의창업' 사고 역시 이러한 서버 측 검증 로직의 부재 또는 미흡으로 발생했을 가능성이 높다.

정부 및 공공기관이 운영하는 개인정보 처리 시스템은 개인정보보호법 제29조(안전조치의무)에 따라 기술적·관리적·물리적 안전조치를 의무적으로 이행해야 하며, ISMS-P 인증을 통해 이를 객관적으로 입증해야 하는 경우가 많다. 특히 10만 명 이상의 정보주체 정보를 처리하거나 전년도 매출액이 일정 규모 이상인 정보통신서비스 제공자는 의무 인증 대상이다. 대국민 창업 프로젝트라면 당연히 이에 해당할 것으로 보이며, 이번 사고는 인증 유지 심사 시 중대 부적합 사항으로 분류될 수 있다. 향후 유사 사업 추진 시에는 개발 단계부터 시큐어 코딩 가이드 적용, 모의해킹을 포함한 취약점 점검, 그리고 운영 전 제3자 보안성 검토를 필수 절차로 포함해야 한다.

ISMS-P 심사원 체크포인트

1. 인증기준 2.8.2 (접근권한 관리) 개인정보 및 개인정보처리시스템에 대한 접근권한은 업무 역할에 따라 최소한으로 부여하고, 주기적으로 검토·조정해야 한다. 이번 사고의 핵심은 '공개 정보 열람 권한'과 '비공개 상세정보 접근 권한'이 명확히 분리되지 않은 점이다. 심사 시에는 ①역할 기반 접근통제(RBAC) 정책 수립 여부 ②사용자별 권한 부여 내역 및 승인 기록 ③분기별 접근권한 재검토 이력을 확인한다. 또한 웹 애플리케이션의 경우 URL 직접 접근, 파라미터 조작 시도 시 서버 측 권한 검증이 작동하는지 기술 테스트를 수행한다.

2. 인증기준 2.5.3 (시스템 개발 보안) 정보시스템 개발 시 보안 취약점을 최소화하기 위해 시큐어 코딩 기준을 수립·적용하고, 보안 약점을 제거해야 한다. 개인정보보호법 시행령 제30조(개인정보의 안전성 확보 조치 기준) 제3호는 개인정보처리시스템에 대한 불법적인 접근 차단을 명시하고 있다. 심사 시에는 ①시큐어 코딩 가이드 보유 및 개발자 교육 실시 여부 ②소스코드 보안 약점 점검 도구 활용 여부 ③운영 전 모의해킹 또는 취약점 진단 수행 여부를 점검한다. OWASP Top 10 중 특히 Broken Access Control(취약한 접근 통제)는 2021년 이후 1위를 차지한 취약점으로, 이번 사고와 직접 연관된다.

3. 인증기준 2.10.4 (개인정보 유출사고 대응) 개인정보 유출사고 발생 시 관련 법령에 따라 신고, 통지 등 후속조치를 이행해야 한다. 개인정보보호법 제34조에 따라 1,000명 이상 유출 시 개인정보보호위원회 및 한국인터넷진흥원(KISA)에 신고해야 하며, 정보주체에게도 지체 없이 통지해야 한다. 심사 시에는 ①유출사고 대응 절차 수립 여부 ②모의훈련 실시 이력 ③실제 유출 시 법정 기한 내 신고·통지 이행 여부를 확인한다.

CPPG·ISMS-P 연계 포인트

접근통제(Access Control) 3요소 접근통제는 식별(Identification) → 인증(Authentication) → 인가(Authorization)의 3단계로 구성된다. 이번 사고는 인증은 통과했으나 인가 단계에서 실패한 전형적인 사례다. 사용자가 로그인(인증)했다고 해서 모든 정보에 접근할 수 있는 것이 아니라, 요청한 리소스에 대한 접근 권한(인가)을 매번 확인해야 한다. CPPG 시험에서는 MAC(강제적), DAC(임의적), RBAC(역할 기반) 등 접근통제 모델의 차이와 적용 사례를 묻는 문제가 자주 출제된다.

최소권한 원칙(Principle of Least Privilege) 개인정보보호의 핵심 원칙 중 하나로, 업무 수행에 필요한 최소한의 권한만 부여해야 한다는 개념이다. 이번 사고에서는 일반 사용자에게 비공개 정보까지 접근 가능한 과도한 권한이 부여된 것으로 보인다. ISMS-P 인증기준 2.8.2와 개인정보보호법 시행령 제30조 제2호(접근 통제)의 법적 근거가 되며, 심사 및 시험에서 반복적으로 강조되는 개념이다. 실무에서는 Default Deny(기본 거부) 정책을 적용하여, 명시적으로 허용된 경우에만 접근을 허용하는 방식으로 구현한다.