인도 ‘국민 약국’에서 벌어진 일
인도에서 2,300개 넘는 매장을 운영하는 대형 체인 DavaIndia Pharmacy 온라인 시스템에서 심각한 보안 취약점이 발견됐어.
인증 절차 없이 누구나 슈퍼 관리자 계정을 만들 수 있었고, 사실상 플랫폼 전체를 장악할 수 있는 수준이었어.
이 권한으로 가능했던 일은 단순 정보 조회를 넘어서 서비스 핵심 로직 조작이야. 고객 주문, 약품 규제 설정, 가격 정책까지 직접 변경 가능했어. 즉 “데이터 유출 사고”가 아니라
서비스 신뢰 + 환자 안전 + 비즈니스 운영을 동시에 흔드는 구조적 사고였던 셈이지.
어떤 데이터가 어떻게 노출됐나
보안 연구자 Eaton Zveare가 관리자 API가 인증 없이 열려 있다는 사실을 발견했어. API 호출만으로 슈퍼 관리자 생성 → 내부 대시보드 접근까지 바로 이어지는 구조였어. 이론적으로 가능한 영향 범위는 꽤 넓어.
- 고객 주문 정보 조회: 이름, 연락처, 주소, 결제 정보, 구매 약품 목록까지 확인 가능
- 약품 가격 정책 변경: 특정 약품 가격 조작 → 시장 왜곡 가능
- 쿠폰·프로모션 생성: 무제한 할인 발행 → 매출·마진 직접 타격
- 처방 필요 여부 수정: 처방 필수 약을 일반 판매로 변경 가능
- 웹 콘텐츠 조작: 피싱 링크 삽입, 사이트 훼손 가능
취약점은 2024년 말부터 열려 있었던 것으로 추정되고 약 1만7천 건 주문 데이터와 883개 매장 관리자 기능이 노출된 상태였어.
실제 악용 흔적은 확인되지 않았지만 헬스케어 데이터 특성상 “가능성”만으로도 리스크는 충분히 치명적이야.
약국 데이터가 특히 위험한 이유
일반 쇼핑몰 주문 정보와 완전히 다른 레벨의 민감도를 가짐.
- 약 이름만으로 질환 추정 가능
- 반복 구매 패턴으로 생활 정보 노출
- 개인 연락처 + 건강 정보 결합
이 데이터는 단순 개인정보가 아니라 사생활 + 건강 상태 + 사회적 리스크까지 연결되는 정보야.
마케팅 악용, 보험 차별, 직장 내 불이익, 협박 시나리오까지 현실적인 위협이 될 수 있어.
서비스 기획 관점 핵심 실패 포인트
이 사건을 개발 실수로만 보면 절반만 본 거야. 제품 설계 레벨에서 구조적인 실패가 보임.
권한 체계 설계 실패
슈퍼 관리자 생성이 API 단에서 통제되지 않았어. 최상위 권한은 반드시 다중 승인 + 2FA + 감사 로그가 기본이어야 해. 권한 모델 설계는 기능이 아니라 보안 아키텍처 영역임.
관리자 도구를 내부 시스템으로 착각
웹 기반 관리자 도구는 이미 외부 서비스야. 특히 프랜차이즈 구조에서는 더더욱. 백오피스 = 제품의 또 다른 인터페이스라고 봐야 함.
확장 중심 KPI 구조
매장 확장, GMV 성장, 출점 속도!! 이 KPI 구조에서는 보안이 항상 후순위가 됨. 보안 수준이 KPI로 측정되지 않으면 결국 일정 압박에 밀림.
도메인 감수성 부족
약국 서비스 데이터는 의료 데이터에 준함. CRM이 아니라 의료 정보 거버넌스로 접근해야 했어. 도메인 특성 반영 없는 보안 설계는 거의 필패 패턴이야.
제품 조직이 반드시 가져야 할 설계 원칙
이 사건은 헬스케어뿐 아니라 모든 민감 데이터 서비스에 적용되는 교훈을 줘.
관리자 도구도 고객 서비스로 설계 권한은 최소 권한 원칙 + 생성 자체를 통제 보안 요구사항을 기능 정의 단계에 포함해. 도메인 민감도 기반 데이터 등급 체계 운영이 필요하고 확장 속도보다 신뢰를 우선하는 KPI 구조! 결국 핵심은 하나야. 보안은 기능이 아니라 제품 신뢰 아키텍처임.
서비스 기획자 관점 한줄 정리
빠르게 확장하는 서비스일수록가장 먼저 확장되는 건 취약점임.