月光愛靑狼

1. 개요

• 발생 일시: 2026년 9월 6일 (토)
• 발생 조직: 고진모터스 (아우디 공식 딜러, 국내 최대 규모)
• 사고 유형: 사내 일부 서버 대상 랜섬웨어 감염 및 외부 불법 접근
• 현재 상태: 해당 서버망 차단 후 정밀 조사 중, 피해 규모 및 범위는 미확정
• 아우디 코리아 입장: 고진모터스 자체 IT 환경 내 사고로 파악, 폭스바겐그룹코리아 시스템·네트워크 영향 정황은 현재까지 확인되지 않음

2. 피해범위

• 영향 받은 시스템: 사내 일부 서버 (정확한 서버 수·역할은 공개되지 않음)
• 고객 영향: 고위층 고객 데이터베이스 등 개인정보 유출 현황 조사 중
• 피해 확정 여부: 현재 단계에서는 개인정보가 외부로 탈취되거나 열람된 정황은 낮다고 판단하나, 유출 가능성은 배제하지 않고 조사 중
• 홈페이지·서비스 운영: 고진모터스 홈페이지는 정상 운영 중인 것으로 확인됨

3. 유출항목 (유출 의심 정보)

 - 고객에게 안내된 유출 의심 개인정보 항목은 다음과 같습니다.

• 성명
• 생년월일
• 주소
• 휴대폰 번호
• 이메일 주소
• 차량 및 계약 정보 등 서비스 이용 정보

 - 다만 이는 “유출 가능성 조사 대상”이며, 실제 외부 반출 여부는 조사 결과에 따라 확정될 예정입니다.

4. 원인

• 공개된 원인: 현재까지 공식적으로 확인된 침투 경로, 사용된 랜섬웨어 종류, 공격자의 내부 접근 수준 등은 구체적으로 밝혀지지 않았습니다.
• 조사 진행: 외부 사이버 보안 전문 업체의 지원을 받아 사고 원인과 영향을 조사 중이며, 조사 완료 전에 원인 단정은 어려운 상태입니다.

5. 대응

 - 고진모터스가 취한 주요 대응 조치는 다음과 같습니다.

• 사고 인지 즉시 해당 서버망 차단 및 보안 통제 강화
• 한국인터넷진흥원(KISA) 및 개인정보보호위원회에 사고 신고
• 고객 보호를 위한 전담 대응팀 구성·운영
• 피해 가능성이 있는 고객 대상 문자·홈페이지 공지를 통한 사고 사실 선제적 안내
• 외부 사이버 보안 전문 업체 지원을 통한 원인·영향 조사
• 개인정보 유출 사실이 확인될 경우 재연락 및 추가 조치 안내 예정

6. 문제점

• 현재 공개된 내용을 바탕으로 도출할 수 있는 보안·대응 측면의 쟁점은 다음과 같습니다.
• 원인 및 침투 경로 미공개: 공격 경로, 악용된 취약점, 랜섬웨어 종류 등 핵심 정보가 아직 공개되지 않아 재발 방지 대책의 구체성이 부족한 상태입니다.
• 유출 확정 전 단계의 불확실성: “유출 가능성 조사 중”이라는 설명으로 인해 실제 피해 규모·대상자 범위가 명확하지 않아, 고객이 추가 피싱·사칭 공격에 노출될 가능성이 있습니다.
• 딜러사별 보안 수준 차이: 아우디 코리아는 자사 시스템 영향이 없다고 밝혔으나, 딜러사 자체 IT 환경에서 중대 사고가 발생함으로써 브랜드 차원의 공급망·제휴사 보안 관리 필요성이 부각됩니다.
• 고객 알림의 실효성: 선제적 알림은 긍정적이지만, 유출 항목이 상세할수록 악용 위험이 높아지므로, 고객 대상 구체적인 보호 조치(예: 사칭 문자 주의, 공식 채널 확인 방법 등)가 충분히 전달되어야 합니다.

◎ 들어가기 전에

• Proxmox Datacenter Manager(PDM) 는 여러 Proxmox VE 클러스터와 Proxmox Backup Server 인스턴스를 단일 인터페이스에서 통합 관리하기 위해 설계된 오픈소스 중앙 관리 플랫폼입니다.
• 2025 년 12 월 1.0 안정 버전이 공식 출시되었으며, 대규모 분산 인프라 환경에서 운영 복잡성을 줄이고 일관된 관리 체계를 구축할 수 있는 핵심 도구로 주목받고 있습니다.
• 본 글에서는 PDM 의 배경과 개요, 주요 변경 사항, 상세 기능, 기술적 개선 포인트, 설치 및 사용 가이드, 그리고 도입 시 고려해야 할 기대효과와 주의사항을 해외 공식 문서와 릴리스 노트를 기반으로 정리합니다.

◎ 배경 및 개요

 - 왜 PDM 이 등장했는가

•   > Proxmox VE 는 단일 클러스터 환경에서 강력한 가상화 플랫폼으로 자리 잡았으나, 데이터센터가 여러 지역에 분산되거나 클러스터 수가 증가할 경우 다음과 같은 운영상 어려움이 발생합니다.
• 각 클러스터별 웹 UI 에 개별 접속해야 함
• 전역 리소스 사용량과 건강 상태 (health status) 를 한눈에 파악하기 어려움
• 클러스터 간 VM 마이그레이션, 업데이트 관리, 정책 적용이 수동으로 분산됨
• 감사 (audit) 와 규정 준수 (compliance) 를 위한 중앙 로그 및 접근 제어가 부재

  > PDM 은 이러한 "스케일 문제"를 해결하기 위해 Proxmox 생태계 내에서 Single Pane of Glass(단일 관리 창) 를 제공하는 전략적 솔루션으로 개발되었습니다.

 - PDM 의 위치와 아키텍처

• PDM 은 독립적인 데몬으로 동작하며, 물리 서버, VM, 또는 LXC 컨테이너 어디든 설치 가능합니다. 
• 관리 대상 (Proxmox VE 노드/클러스터, Proxmox Backup Server) 은 PDM 에 "Remote"로 등록되며, PDM 은 이들을 중앙에서 집계·표시·관리합니다.

◎ 주요 변경 사항 (1.0 안정 버전 기준)

• PDM 1.0 은 2025 년 12 월 4 일 공식 안정 버전으로 출시되었으며, 이전 알파/테스트 버전과 비교해 다음과 같은 주요 기능과 개선이 포함되었습니다.
•  - 기술 스택 및 베이스 시스템
  베이스 OS: Debian 13.2 "Trixie" 기반
• Linux 커널: 6.17 버전 (안정 기본 커널)
• ZFS: 2.3.4 포함
• 핵심 소프트웨어 스택: Rust 언어로 작성되었으며, 프론트엔드는 Rust/Yew 기반의 새로운 Proxmox UI 프레임워크를 사용해 성능과 사용자 경험을 개선

 - 핵심 기능 추가 및 강화

• 중앙 집계 대시보드: 여러 Remote 의 전역 건강 상태, CPU/RAM/스토리지 I/O 등 핵심 KPI 를 실시간으로 집계
• 동적·역할 기반 커스텀 뷰: Remote, 리소스 유형, 태그 등으로 필터링된 타겟 오버뷰 생성 및 RBAC 기반 접근 제어
• 멀티 클러스터 관리 및 크로스 클러스터 라이브 마이그레이션: 독립 클러스터 간 VM 라이브 마이그레이션 지원 (무중단 부하 분산 및 유지보수 가능)
• 중앙 SDN(EVPN): 여러 Remote 에 걸쳐 EVPN 존 및 VNet 을 단일 인터페이스에서 구성
• 중앙 업데이트 관리 패널: 전체 인프라의 이용 가능한 업데이트를 한눈에 확인하고 PDM 인터페이스에서 직접 배포 가능
• 고급 검색 기능: Elasticsearch/GitHub 스타일의 쿼리 언어를 모방한 강력한 검색으로 리소스 유형, 상태, 태그 기반 필터링
• 오픈소스 라이선스: GNU AGPLv3

◎ 상세 기능 설명

1. 중앙 코크핏 (Central Cockpit)

• PDM 은 모든 Proxmox VE 클러스터, 노드, Proxmox Backup Server 인스턴스를 단일 인터페이스에 연결하여 표시합니다. 
• 호스트, VM, 컨테이너, 데이터스토어를 위치와 데이터센터에 걸쳐 구조화된 통합 오버뷰로 제공하며, 대규모 환경에서도 강력한 검색으로 원하는 리소스를 빠르게 찾을 수 있습니다.

2. 멀티 클러스터 관리 및 라이브 마이그레이션

• 멀티 클러스터 관리: 독립적인 Proxmox 기반 클러스터와 스탠드얼론 노드를 원활하게 연결하고 관리
• 크로스 클러스터 라이브 마이그레이션: 서로 다른 클러스터 간 VM 을 무중단으로 마이그레이션하여 부하 분산, 계획된 유지보수, 고가용성 확보 가능
• VM/컨테이너 수명 주기 관리: 시작, 정지, 재부팅, 설정 변경 등 기본 관리 작업을 중앙 인터페이스에서 직접 수행

3. Proxmox Backup Server 통합

• Proxmox Backup Server(PBS) Remote 는 PDM 에서 Proxmox VE Remote 와 동일하게 관리됩니다. 
• 통합 대시보드 위젯에 PBS 데이터스토어 내용과 RRD 그래프 (이용률·성능) 가 직접 포함되어 백업 인프라의 상태도 중앙에서 모니터링할 수 있습니다.

4. 커스텀 뷰와 위임 제어

• 커스텀 뷰: 사용자가 원하는 레이아웃과 필터 (Remote, 리소스, 리소스 유형, 태그) 로 오버뷰를 생성
• RBAC 기반 접근 제어: 특정 뷰에 대한 접근만 허용하고 실제 호스트나 데이터스토어에 대한 직접 접근은 차단하여, 멀티 테넌트 환경에서도 안전하게 제어권을 위임할 수 있음

5. 메트릭 및 시각화

• 중앙 메트릭 수집: 효율적인 중앙 메트릭 수집 체계를 통해 사용량, 성능, 성장 추세를 심층적으로 분석
• RRD 그래프 및 대시보드: 병목 현상과 잠재 문제를 조기에 탐지하고, 리소스 할당 최적화 및 향후 용량 계획 수립 지원

6. 엔터프라이즈급 인증 및 API

• 인증 프로토콜: LDAP, Active Directory, OpenID Connect 지원으로 기존 Identity/SSO 환경과 쉽게 통합
• API 토큰: 외부 애플리케이션 및 자동화 파이프라인을 위한 세밀한 접근 제어 가능

7. 중앙 SDN(EVPN) 기능

• EVPN 존 및 VNet 구성: 여러 Remote 에 걸쳐 소프트웨어 정의 네트워크 (SDN) 를 단일 인터페이스에서 구성하여 대규모 환경의 네트워크 오버레이 및 일상 네트워크 관리를 단순화

8. 업데이트 관리

• 중앙 업데이트 관리 패널: 전체 Proxmox VE 및 PBS 인프라의 이용 가능한 업데이트를 즉시 확인하고 PDM 인터페이스에서 직접 패치 배포 가능
• 통합 쉘 액세스: 관리되는 모든 Remote 에 대한 보안 쉘 (secure shell) 을 단일 콘솔에서 제공

◎ 기획 의도 및 기술적 개선

 - 기획 의도

• PDM 은 Proxmox 생태계가 엔터프라이즈 및 대규모 분산 환경으로 확장됨에 따라 발생한 "관리 복잡성"을 해결하기 위해 설계되었습니다. 

  > 기존에는 각 클러스터를 개별적으로 관리해야 했으나, PDM 을 통해 다음과 같은 목표를 달성하고자 합니다.

• 운영 효율성 증대: 반복적이고 분산된 작업을 중앙에서 자동화
• 가시성 확보: 전역 리소스 사용량과 건강 상태를 실시간으로 파악
• 규정 준수 강화: RBAC, 감사 로그, 중앙 인증을 통해 책임 분리 (separation of duties) 와 최소 권한 원칙 enforced
• 비용 최적화: 실제 이용률을 기반으로 과잉 프로비저닝 방지 및 미사용 용량 감소

 - 기술적 개선

• Rust 기반 고성능 스택: 기존 Proxmox 제품군과 달리 핵심 로직과 UI 를 Rust 로 재작성하여 성능과 안정성을 대폭 향상
• 최신 커널 및 ZFS: Linux 6.17 커널과 ZFS 2.3.4 를 기본 포함하여 최신 하드웨어 지원 및 스토리지 기능 강화
• 오픈소스 투명성: 전체 소스 코드가 GNU AGPLv3 으로 공개되어 커뮤니티 기여와 감사 (audit) 가 용이

◎ 사용 방법 및 설치 가이드

 - 시스템 요구 사항

설치 미디어: PDM 1.0 은 ISO 이미지로 제공되며, 베어메탈 서버에 직접 설치하거나 VM/LXC 에서 실행 가능

라이선스: PDM 자체는 별도 구독 키가 필요하지 않으나, 관리 대상 Proxmox Remote 에 활성 엔터프라이즈 지원 구독이 있어야 PDM 업데이트 및 지원을 받을 수 있음

 - 설치 단계

  > ISO 다운로드: Proxmox 다운로드 페이지 에서 PDM 1.0 ISO 이미지 획득

  > 부팅 및 설치: ISO 로 부팅 후 설치 마법사 따라 진행 (네트워크 설정, 스토리지 선택, 관리자 계정 생성 등)

  > 웹 UI 접속: 설치 완료 후 https://:8006으로 웹 브라우저에서 접속

  > Remote 추가:

• PDM 웹 UI 에서 "Datacenter" → "Add Remote" 선택
• Proxmox VE 클러스터 또는 PBS 인스턴스의 IP/FQDN, 인증 정보 (API 토큰 또는 사용자 계정) 입력
• 연결 테스트 후 저장

  > 커스텀 뷰 생성:

• "Views" 탭에서 새 뷰 생성
• 필터 조건 (Remote, 리소스 유형, 태그 등) 설정
• RBAC 정책으로 특정 사용자/그룹에 뷰 접근 권한 할당

  > 중앙 업데이트 관리:

• "Updates" 패널에서 전체 Remote 의 이용 가능한 업데이트 확인
• 일괄 또는 선택적 배포 실행

  > 고급 설정 예시

• EVPN 존 구성: "SDN" 탭에서 EVPN 존 생성 후 여러 Remote 에 걸쳐 VNet 할당
• API 토큰 생성: "API Tokens" 에서 자동화 스크립트용 토큰 발급 및 권한 범위 설정
• 감사 로그 확인: "Audit Log" 에서 모든 관리자 작업 이력 조회 (누가, 언제, 무엇을 했는지)

◎ 기대효과

 - 운영 효율성

• 단일 인터페이스 관리: 여러 클러스터에 대한 반복 작업을 중앙에서 처리하여 운영 오버헤드 감소
• 신속한 문제 탐지: 중앙 대시보드와 RRD 그래프로 병목 현상과 잠재 문제를 조기에 식별

 - 비용 최적화

• 리소스 이용률 가시화: 실제 사용량을 기반으로 과잉 프로비저닝 방지 및 미사용 용량 감소
• 계획적 용량 확장: 성장 추세를 기반으로 필요한 시점에만 투자 결정

 - 규정 준수 및 보안

• RBAC 및 감사 로그: 책임 분리와 최소 권한 원칙을 enforced 하여 내부 통제 및 외부 감사 대응 용이
• 중앙 인증 통합: LDAP/AD/OpenID Connect 를 통해 기존 IAM 환경과 일관된 인증 체계 유지

 - 비즈니스 연속성

• 크로스 클러스터 라이브 마이그레이션: 무중단 부하 분산 및 유지보수로 SLA 준수 및 다운타임 리스크 최소화
• 재해 복구: 오프사이트 복제 및 중앙 백업 관리로 DC 장애 시 수동 복구 가능 (HA 는 아님)

◎ 주의사항 및 고려할 점

 - 안정성 및 성숙도

• PDM 1.0 은 2025 년 12 월 안정 버전으로 출시되었으나, 여전히 일부 기능 (예: 백업 작업, 알림 정책, HA 관리 등) 은 향후 릴리스에서 추가될 예정이므로 공식 로드맵을 확인해야 합니다.
• 프로덕션 환경 도입 전 테스트 환경에서 충분히 검증할 것을 권장합니다.

 - 라이선스 및 지원

• PDM 자체는 무료 오픈소스이나, 관리 대상 Proxmox Remote 에 활성 엔터프라이즈 지원 구독이 있어야 PDM 업데이트 및 공식 지원을 받을 수 있습니다.
• 구독이 없는 경우에도 PDM 은 사용 가능하나, 안정성 및 보안 업데이트를 직접 관리해야 합니다.

 - 아키텍처 제한

• 단일 인스턴스: 현재 PDM 은 활성 - 대기 (active-standby) 아키텍처를 지원하지 않아 단일 장애점 (SPOF) 이 존재합니다.
• 오프라인 가시성: Remote 가 오프라인일 경우 마지막으로 알려진 상태만 표시되므로 실시간 모니터링이 제한될 수 있습니다.

 - 네트워크 및 보안

• 방화벽 설정: PDM 과 Remote 간 통신을 위해 필요한 포트 (기본 8006, 22 등) 를 방화벽에서 허용해야 합니다.
• 인증 관리: LDAP/AD/OpenID Connect 통합 시 인증 서버의 가용성과 동기화 주기를 고려해야 합니다.

◎ 마치며

• Proxmox Datacenter Manager 는 멀티 클러스터·멀티 데이터센터 환경에서 Proxmox 기반 인프라를 운영할 때 발생하는 복잡성을 체계적으로 해결하는 중앙 관리 플랫폼입니다. 
• Rust 기반의 고성능 스택, 최신 커널 및 ZFS 통합, 엔터프라이즈급 인증·RBAC·감사 기능, 그리고 크로스 클러스터 라이브 마이그레이션 등 실용적인 기능을 통해 운영 효율성과 비즈니스 연속성을 동시에 확보할 수 있습니다.
• 다만, 아직 일부 기능이 로드맵 상에 남아 있고 단일 인스턴스 아키텍처로 인한 SPOF 문제가 있으므로, 프로덕션 도입 전 테스트 환경에서 충분히 검증하고 공식 문서 및 릴리스 노트를 꾸준히 확인하는 것이 중요합니다.
• Proxmox 생태계를 기반으로 대규모 가상화 인프라를 운영 중이거나 계획 중이라면, PDM 은 운영 체계를 단순화하고 확장성을 확보하는 데 핵심적인 역할을 할 수 있을 것입니다.

◎ 들어가기 전에

• ProxCenter는 Proxmox VE(및 PBS) 인프라를 엔터프라이즈 급으로 관리할 수 있는 모던 웹 플랫폼입니다.
• VMware 종속성을 줄이고자 하는 조직에게, 다중 클러스터 통합 관리·크로스 하이퍼바이저 마이그레이션·워크로드 밸런싱(DRS)·고급 보고 및 알림 기능을 단일 콘솔에서 제공하는 점이 핵심 가치입니다.
• 아래에서는 공식 사이트와 GitHub 저장소 내용을 기반으로, 배경 및 개요부터 주요 변경 사항, 상세 기능, 기획 의도/기술적 개선, 설치·사용 가이드, 기대효과 및 주의사항까지 기술 블로그 포스팅용으로 정리합니다.

◎ 배경 및 개요

• Proxmox는 오픈소스 가상화 플랫폼으로 널리 쓰이지만, 대규모·다중 사이트 환경에서는 클러스터 간 가시성과 운영 일관성을 확보하기 어렵습니다. 
• ProxCenter는 이러한 운영 복잡도를 해결하기 위해 “단일 창(single pane of glass)”에서 여러 Proxmox VE 클러스터와 Proxmox Backup Server(PBS) 인스턴스를 통합 관리하는 플랫폼으로 설계되었습니다.
• 특히 VMware 탈피(Vmware exit) 흐름에서 vCenter의 역할을 대체할 수 있는 실용적인 대안으로 주목받고 있으며, 한국 파트너사 피드백에 따르면 직관적인 UI와 다중 클러스터 관리 능력이 호평받고 있습니다.

◎ 주요 변경 사항 (최신 릴리스 기준)

• 최신 릴리스(v1.4.9, 2026-08-29)와 최근 커밋 이력을 보면, ProxCenter는 기능 완성도와 운영 안정성을 동시에 높이는 방향으로 빠르게 발전 중입니다.
• 보고서(reporting) 고도화: PDF 템플릿의 “Customization” 탭과 실시간 미리보기를 제공하여, 보고서 양식과 브랜딩을 유연하게 조정할 수 있게 되었습니다.
• 클라우드 이미지 카탈로그 자동화: 템플릿 기능에서 배포판별 클라우드 이미지를 자동 갱신하는 구조로 개선되어, VM 프로비저닝 속도와 일관성이 향상되었습니다.
• 설치·업그레이드 경험 개선: install-community/install-enterprise 스크립트 URL 체계 정립, .env 재실행 시 환경 변수 병합 및 라이선스·URL 유지, HA 환경에서 버전 일치 강제 등 운영 리스크를 줄이는 변경이 이어지고 있습니다.
• HA(High Availability) 제어플레인: 3노드 제어플레인 + Keepalived VIP + Patroni(PostgreSQL 복제) + HAProxy 라우팅을 통해 엔터프라이즈급 무중단 운영을 지원합니다.
• 보안·품질 파이프라인: CodeQL·Trivy·Dependabot 기반 자동 스캔과 명시적 보안 리포트 채널(security@proxcenter.io)을 운영 중입니다.

◎ 상세 기능 설명

1) 다중 클러스터 관리 (Multi-cluster management)

• 여러 Proxmox VE 클러스터와 PBS 인스턴스를 하나의 콘솔에서 등록·모니터링·운영할 수 있습니다. 
• 노드, 게스트 VM, 스토리지, 네트워크, Ceph CRUSH 트리까지 토폴로지 뷰로 직관적으로 파악할 수 있어, 대규모 인프라의 상태 파악과 일상 운영이 간소화됩니다.

2) 크로스 하이퍼바이저 마이그레이션 (Cross-hypervisor migration)

• VMware, Hyper-V, Nutanix, XCP-ng 등 타 하이퍼바이저에서 Proxmox로의 이주를 지원합니다. 
• CBT(Changed Block Tracking) 기반 웜 마이그레이션을 제공하여 다운타임을 최소화하면서 점진적 전환이 가능합니다. 
• VMware 탈퇴 프로젝트에서 실질적인 마이그레이션 공정을 플랫폼 차에서 지원하는 점이 강점입니다.

3) 인브라우저 콘솔 (noVNC/SPICE)

• QEMU 게스트에 대해 noVNC 및 SPICE 콘솔을 브라우저에서 바로 사용할 수 있어, 별도 클라이언트 설치 없이 운영팀의 접근성이 높아집니다.

4) 백업·복제 가시성 및 보고

• 클러스터·노드·게스트 단위로 백업 및 복제 상태를 집계하고, 엔터프라이즈 에디션에서는 이메일 요약, 심각도 라우팅, 정기 리포트 스케줄링까지 제공합니다. 
• 이는 운영 SLA와 감사 대응에 유용합니다.

5) RBAC 및 SSO

• 세밀한 역할(Role)과 스코프(Scope) 기반 접근 제어를 제공하며, SSO 연동을 통해 조직의 IAM 정책과 일관된 인증 체계를 구축할 수 있습니다.

6) DRS 워크로드 밸런싱 (Enterprise)

• Go 기반 오케스트레이터가 클러스터 부하를 분석해 VM 배치를 자동 조정합니다. 
• 리소스 편중을 줄이고 성능/안정성을 개선하는 자동화 레이어로, vCenter DRS와 유사한 가치를 Proxmox 환경에서 제공합니다.

7) 알림·보고·알림 채널 (Enterprise)

• 이메일 다이제스트, 심각도별 라우팅, 스케줄된 리포트를 통해 운영팀의 상황 인지 속도를 높입니다. 
• MSP 모드에서는 다중 테넌트 fleet 관리와 라이선스 스태킹을 지원합니다.

8) 고가용성 제어플레인 (Enterprise HA)

• 3노드 제어플레인에서 Keepalived VIP, Patroni를 통한 PostgreSQL 복제 및 리더 선출, HAProxy의 DB/리더 트래픽 라우팅으로 무중단 운영을 지향합니다. 
• HA 전환은 UI 위자드(Settings > High Availability)에서 유도되며, 사전 요건 문서가 별도로 존재합니다.

9) 아키텍처 특징

• 단일 노출 포트(3000): HTTP와 WebSocket을 단일 프로세스가 처리하며, TLS는 앞단에 Nginx 등을 둘 수 있습니다.
• PostgreSQL 단일 진실 공급원: 시작 시 스키마 마이그레이션 자동 실행.
• 엔터프라이즈 추가 구성요소: Go 오케스트레이터(DRS/작업/알림/리포트/플로우 텔레메트리)와 PDF 렌더링을 위한 WeasyPrint 사이드카는 내부 네트워크에 격리됩니다.
• 에이전트 없음: Proxmox VE(8006), PBS(8007) 및 마이그레이션 소스는 아웃바운드로 연결되며, 호스트에 별도 에이전트를 설치할 필요가 없습니다.

◎ 기획 의도 / 기술적 개선 포인트

 - ProxCenter의 기획 의도는 명확합니다. 

• “Proxmox 생태계에서 vCenter 수준의 운영 경험을 제공하되, 오픈소스 친화적이고 현대적인 아키텍처로 유지보수 부담을 낮추자”는 방향입니다.

 - 기술적으로 눈에 띄는 개선은 다음과 같습니다.

• 운영 복잡도 축소: 단일 포트(3000) 노출과 Docker Compose 기반 배포로 설치·업그레이드 경로를 단순화했습니다. 스키마 마이그레이션 자동화는 버전 업그레이드 시 인적 실수를 줄입니다.
• 데이터 일관성 강화: PostgreSQL을 유일한 진실 공급원으로 삼고, Patroni+etcd로 리더 선출을 명확히 함으로써 HA 환경에서도 쓰기 일관성을 확보합니다.
• 확장성과 격리: 오케스트레이터와 PDF 렌더러를 내부 네트워크에 두고, 외부 노출을 최소화하는 설계는 보안과 확장성을 동시에 고려한 선택입니다.
• 마이그레이션 공정 내재화: 타 하이퍼바이저에서 Proxmox로의 이주를 플랫폼 기능으로 포함함으로써, VMware 탈퇴 프로젝트의 리스크와 기간을 단축하는 데 기여합니다.
• 피드백 기반 현지화: 한국 파트너 피드백을 반영해 한국어 UI 및 KRW 관련 개선이 빠르게 반영된 점은 제품 운영의 민첩성을 보여줍니다.

◎ 사용방법 / 설치 및 운영 가이드

1) 시스템 요구사항

• 호스트: Docker Engine 24+ 및 Docker Compose v2가 설치된 Linux
• 최소 스펙: RAM 2GB, 디스크 10GB 이상(데이터베이스 성장에 따라 증설 권장)
• 포트: 인바운드 3000, 아웃바운드 Proxmox VE 8006 / PBS 8007
• Proxmox 버전: Proxmox VE 8.x 또는 9.x
• HA 추가 요건: 3노드 제어플레인, VIP 구성, 네트워크/쿼럼 요건 등 별도 문서 참고

2) Community Edition 설치 (무료)

curl -fsSL https://proxcenter.io/install/community | sudo bash

• 설치 스크립트는 Docker, Compose 스택, PostgreSQL, /opt/proxcenter 이하 영속 볼륨을 구성합니다. 
• 완료 후 http://your-server:3000으로 접속해 첫 관리자 계정을 생성합니다.

3) Enterprise Edition 설치

curl -fsSL https://proxcenter.io/install/enterprise | sudo bash -s -- --token YOUR_TOKEN

• 라이선스 토큰을 전달하면 엔터프라이즈 기능(DRS, 알림/리포트, MSP 모드, HA 등)이 활성화됩니다.

4) 리버스 프록시 뒤 운영 시

• TLS/도메인 종단 등을 위해 Nginx 등 리버스 프록시 뒤에 둘 경우, 연결 설정에서 “Behind reverse proxy” 토글을 켜야 합니다. 
• 이를 켜지 않으면 페일오버 시 내부 노드 IP로 전환될 수 있습니다.

5) 업그레이드 (Community)

cd /opt/proxcenter
docker compose pull
docker compose up -d

• 시작 시 스키마 마이그레이션이 자동 실행되며, Community는 추가 작업이 필요하지 않습니다.

6) 업그레이드 (Enterprise, 새 설정 추가된 릴리스)

• 엔터프라이즈는 새 릴리스에서 환경 변수가 추가될 수 있으므로, docker compose pull만으로는 컨테이너 환경에 반영되지 않을 수 있습니다. 
• 이때는 설치 스크립트를 재실행하여 Compose 파일을 갱신합니다.

curl -fsSL https://proxcenter.io/install/enterprise | sudo bash -s -- --token YOUR_TOKEN

• 이 과정은 기존 시크릿, NEXTAUTH_URL/APP_URL, 라이선스 키를 유지하며, 변경된 환경이 있는 컨테이너만 재생성합니다. 
• .env에서 버전을 고정했다면 --version을 함께 전달해야 합니다.

7) HA 환경 업그레이드

• 3노드가 동일한 Compose 파일을 사용하므로, 노드별로 위 두 명령을 순차 적용합니다. 
• 버전은 클러스터 전체에서 동일하게 유지해야 합니다.

8) v1.3.x 이하에서 전환 시 주의

• v1.4.0부터 SQLite 지원이 제거되었으며, PostgreSQL로의 인플레이스 마이그레이션은 제공되지 않습니다. 
• v1.4 전환 가이드에 따라 컷오버 절차를 따라야 합니다.

9) 상태 확인 및 문제 해결

cd /opt/proxcenter
docker compose ps        # 서비스 상태
docker compose logs -f   # 로그 실시간 확인
docker compose restart   # 스택 재시작 (필요 시)

◎ 기대효과

• 운영 일관성 확보: 다중 클러스터를 하나의 UI로 통합함으로써, 모니터링·백업·복제·알림·보고의 운영 프로세스를 표준화할 수 있습니다.
• VMware 탈퇴 가속: 크로스 하이퍼바이저 마이그레이션과 vCenter 유사 운영 경험을 통해 전환 기간과 리스크를 줄일 수 있습니다.
• 자동화를 통한 안정성: DRS 기반 워크로드 밸런싱과 정기 리포트/알림은 인적 개입을 줄이고 SLA 달성을 지원합니다.
• 감사·보고 대응: 엔터프라이즈 리포팅과 이메일 다이제스트는 운영 증적과 커뮤니케이션 비용을 절감합니다.
• 확장 가능한 아키텍처: HA 제어플레인과 내부 격리 구성요소로 대규모·고가용 환경으로의 확장이 용이합니다.

◎ 주의사항 및 운영 팁

• 버전 정합성: 엔터프라이즈 업그레이드 시 Compose 파일 갱신(설치 스크립트 재실행)을 잊지 마세요. 환경 변수 누락은 기능 동작 이상으로 이어질 수 있습니다.
• HA 구성 시 사전 요건: 3노드 쿼럼, VIP, 네트워크 분리, Patroni/etcd 동작 조건을 충분히 검토하고, UI 위자드 외 별도 문서를 함께 확인하세요.
• 리버스 프록시 설정: “Behind reverse proxy” 옵션 미활성화 시 페일오버 경로가 내부 IP로 우회할 수 있으므로 반드시 확인이 필요합니다.
• 데이터베이스 용량 계획: PostgreSQL이 유일한 진실 공급원이므로, 장기 운영 시 디스크 성장과 백업 전략을 미리 수립하는 것이 좋습니다.
• 보안 스캔 채널: CodeQL/Trivy/Dependabot 기반 자동 스캔이 적용되지만, 조직 내 보안 정책과 정합성을 검토하고 취약성은 security@proxcenter.io로 보고하는 프로세스를 마련하세요.
• SQLite → PostgreSQL 전환: v1.3.x 이하 사용 중이라면 인플레이스 마이그레이션이 없으므로, 전환 가이드에 따른 컷오버 일정을 별도로 잡아야 합니다.

◎ 마치며

• ProxCenter는 Proxmox 기반 인프라를 엔터프라이즈 수준으로 운영하려는 조직에게 실질적인 대안입니다. 
• 다중 클러스터 가시성, 마이그레이션 공정 내재화, DRS 기반 자동화, 그리고 HA 제어플레인까지 “운영의 일관성”과 “전환의 현실성”을 동시에 잡을 수 있는 설계가 인상적입니다. 
• VMware 탈퇴를 계획 중이거나, Proxmox 환경의 운영 성숙도를 높이고자 한다면 공식 문서와 GitHub 릴리스 노트를 함께 참고하여 PoC를 진행해 보시길 권합니다.

1. 개요

• 2026년 8월 말부터 9월 초 사이, 국내 전자지급결제대행(PG)업체인 코엠페이먼츠의 특정 결제 연동 시스템에 외부의 비정상적인 접근이 발생하여 결제 관련 정보가 유출되었을 가능성이 확인되었습니다. 
• 코엠페이먼츠는 2026년 9월 6일 홈페이지 공지를 통해 사고 사실을 공식적으로 인정하고, 개인정보보호위원회, 금융위원회, 금융감독원, 금융보안원 등 관계기관에 신고 및 협조를 진행 중이라고 밝혔습니다. 
• 금융감독원은 토스페이먼츠와 함께 코엠페이먼츠에 대한 현장점검을 진행하던 중 9월 9일부터 현장검사로 격상하여 침해 경로와 정보 유출 현황을 조사하고 있습니다.

2. 피해범위

• 사고 발생 기간: 2026년 8월 30일 08:13 ~ 9월 1일 05:34 (비정상 접근 시간대)
• 사고 인지 시점: 2026년 9월 2일 08:00경
• 피해 규모: 현재 정확한 유출 대상 거래 및 정보주체 특정 불가. 공격자가 취득한 개별 거래내역 및 카드정보를 회사가 보유하고 있지 않아 피해 건수는 미확인 상태입니다.
• 영향 범위: 코엠페이먼츠를 경유한 결제 연동 시스템 전체가 조사 대상이며, 2차 PG 시스템을 통한 추가 접근 가능성도 함께 확인 중입니다.
• 유출 규모 추정: 유출이 의심되는 정보는 카드사별로 수천 건씩, 총 수만 건에 달하며, 거의 모든 카드사의 고객 정보 일부가 해커에게 넘어간 것으로 파악됩니다.

3. 유출항목

 - 코엠페이먼츠는 침해된 시스템에서 처리되는 결제요청 전문의 구조상 다음 항목이 포함되었을 가능성을 공식적으로 밝혔습니다.

• 카드번호 (전체 또는 일부)
• 카드 유효기간
• 일부 결제방식의 경우 생년월 관련 정보
• 일부 결제방식의 경우 카드 비밀번호 앞 2자리

 - 해커가 취득한 자료에는 카드회원 이름, 카드번호, 유효기간, 비밀번호 앞 2자리 등 민감한 결제정보가 포함된 것으로 파악되고 있습니다.

 - 다만 실제 유출 여부와 정확한 항목은 관계기관 및 외부 보안전문기관과 함께 추가 조사 중이며, 현재로서는 가능성 수준으로만 안내되고 있습니다.

4. 원인

• 직접 원인: 특정 결제 연동 시스템에 대한 외부의 비정상적인 접근이 발생했으며, 이는 중국계로 추정되는 해커에 의한 PG사 대상 공격의 일환으로 파악되고 있습니다.
• 배경 요인: 금융당국과 PG사 일부는 해커의 제보 전까지 침해 사실을 인지하지 못했으며, 이는 탐지 체계의 공백과 보안 모니터링의 미흡이 원인으로 지목됩니다.
• 기술적 요인: 결제요청 전문 구조에 민감한 카드정보가 포함되어 있었으며, 접근 제어 및 이상접근 탐지 조치가 충분하지 않았을 가능성이 조사되고 있습니다.
• 공격자 국적 관련: 금감원 관계자는 "현재까지 IP 주소 등을 추적해 보니 중국계로 추정되지만, IP 우회 방법도 워낙 많아서 확정적으로 말하긴 어렵다"고 밝혔습니다.

5. 대응

• 긴급 조치: 사고 인지 후 관련 취약점에 대한 긴급 차단 및 추가 침입 방지조치를 실시했습니다.
• 보안점검: 침해 대상 시스템에 대한 보안점검과 원인분석을 외부 전문기관과 함께 진행 중입니다.
• 관계기관 신고: 개인정보보호위원회, 금융위원회, 금융감독원, 금융보안원에 사고를 신고하고 조사에 협조하고 있습니다.
• 금감원 검사: 금융감독원은 코엠페이먼츠와 토스페이먼츠에 대한 현장점검을 9월 9일부터 현장검사로 격상하여 조사를 진행 중입니다.
• 카드사 연계: 금융보안원은 확보된 카드정보를 해당 카드사에 전달하고 카드회원 보호조치를 요청했으며, 코엠페이먼츠도 카드사에 침해사고 사실을 통보하고 피해 예방조치에 협조 중입니다.
• 고객 안내: 홈페이지 공지를 통해 사고 사실과 주의사항을 안내하고, 고객센터(02-1522-5416) 및 이메일(dev@coam.co.kr)을 운영하여 문의를 받고 있습니다.
• 이상거래 감시: 금융당국과 업계는 이상금융거래탐지시스템(FDS)을 가동하여 의심 거래를 집중적으로 살피고 있습니다.

6. 문제점

• 탐지 지연: 비정상 접근이 8월 30일부터 9월 1일까지 발생했으나, 회사는 9월 2일에야 사고를 인지했습니다. 이는 실시간 이상접근 탐지 및 모니터링 체계의 미흡을 보여줍니다.
• 피해 특정 불가: 공격자가 취득한 개별 거래내역 및 카드정보를 회사가 보유하고 있지 않아, 실제 유출 대상과 피해 건수를 특정할 수 없는 상황입니다.
• 민감정보 포함 구조: 결제요청 전문에 카드번호, 유효기간, 생년월, 비밀번호 앞 2자리 등 민감정보가 포함되어 있어, 시스템 침해 시 대규모 유출 가능성이 높았습니다.
• 사전 인지 부재: 해커의 제보 전까지 회사가 침해 사실을 인지하지 못했으며, 이는 보안 관제 및 로그 분석 체계의 공백을 시사합니다.
• 2차 피해 우려: 카드번호와 유효기간, 비밀번호 일부가 유출되면서 해외 부정결제 등 2차 피해 가능성이 제기되고 있으며, 이에 대한 선제적 대응이 필요합니다.
• 공격자 추적 한계: IP 우회 방법이 다양하여 공격자 국적을 확정하기 어렵다는 점이 확인되며, 이는 사이버 범죄 수사 및 대응의 어려움을 보여줍니다.

1. 개요

• 화해는 2026년 9월 2일 오전 7시 10분경 외부 행위자가 일부 고객 개인정보에 비정상적으로 접근한 사실을 확인했다고 안내했습니다. 
• 회사는 9월 4일 관련 안내를 올렸고, 관계 기관에도 유출 사실을 신고했다고 밝혔습니다.
• 최초 비정상 접근이 확인된 시점은 8월 31일 오후 9시 11분입니다.

2. 피해범위

• 확인된 유출 규모는 이벤트 배송지 정보 14만 4,460건이며, 서비스 이용 과정에서 노출되는 계정 정보는 약 480만 건 수준으로 알려졌습니다. 
• 다만 이 수치는 조회·노출된 정보와 실제 유출된 정보가 함께 언급된 것이어서, 항목별 구분이 중요합니다.

3. 유출항목

• 화해가 확인했다고 밝힌 정보는 일부 회원의 이벤트 배송지 정보와 리뷰 게시글을 통해 공개된 회원 정보입니다. 
• 구체적으로 이벤트 배송지 정보에는 이름, 휴대폰 번호, 우편번호, 주소, 상세주소가 포함됐고, 공개된 회원 정보에는 닉네임, 성별, 출생연도, 피부 고민이 포함됐습니다. 
• 비밀번호, 결제·금융 정보, 주민등록번호는 피해 대상이 아니라고 설명했습니다.

4. 원인

• 화해는 외부 행위자의 비정상적인 접근을 확인했으며, 확인 즉시 접근 경로와 관련 IP를 차단했다고 밝혔습니다. 
• 다만 취약점 종류나 침투 방식까지는 구체적으로 확인되지 않았습니다.

5. 대응

• 회사는 사고 인지 직후 차단 조치를 완료했고, 관련 시스템 전반에 대한 점검과 보완을 진행하고 있다고 밝혔습니다. 
• 또한 법령과 절차에 따라 관계 기관에 신고했으며, 현재까지 추가 유출은 확인되지 않았다고 안내했습니다. 
• 개인정보 유출 신고는 통상 72시간 이내 절차가 적용됩니다.

6. 문제점

• 이번 건은 서비스 이용 과정에서 드러나는 정보와 이벤트 배송지 정보가 함께 노출될 수 있다는 점을 보여줍니다. 
• 특히 공개 게시글 기반 정보와 배송 관련 개인정보가 결합되면, 사용자 식별과 2차 악용 위험이 커질 수 있습니다. 
• 또한 외부 비정상 접근이 발생한 뒤 어느 지점에서 어떤 통제가 실패했는지에 대한 설명은 아직 충분하지 않습니다.

1. 개요

• 힐링페이퍼가 운영하는 미용의료 플랫폼 강남언니에서 개인정보 유출 사고가 발생했습니다. 
• 회사는 지난 4일 상담 내역 조회 연동 기능(API)에 대한 비정상 접근을 확인했고, 7일 이를 공지했습니다.

2. 피해범위

• 회사 집계 기준 유출 인원은 총 21만9,665명입니다. 
• 국가별로는 한국 약 16만명, 일본 약 4만8,000명, 대만 4,218명, 태국 1,591명, 중국 481명, 영어권 및 기타 국가 5,308명으로 알려졌습니다.

3. 유출항목

• 기본 식별정보인 이름, 전화번호, 이메일, 생년월일, 성별, 국가·거주 지역이 포함됐습니다.
• 이와 함께 소셜 로그인 ID, 접속 IP, 이용 단말 정보, 앱 버전 같은 서비스 이용 정보도 유출된 것으로 전해졌습니다.
• 상담 신청 항목, 상담 진행 상태, 예약 확정 시각, 등록 사진, 실제 시술 정보, 결제 정보 등 민감 정보도 포함됐습니다.

4. 원인

• 회사는 상담 내역을 조회하는 연동 기능(API)에 대한 비정상적인 접근이 발생했다고 설명했습니다. 
• 즉, 외부에서 해당 API를 통해 정상 범위를 벗어난 접근이 이뤄지면서 정보가 유출된 것으로 보입니다.

5. 대응

• 힐링페이퍼는 이상 징후를 실시간으로 포착한 뒤 해당 접근 경로를 차단했다고 밝혔습니다. 
• 또한 경찰에 수사를 의뢰했으며, 피해자 확인과 보안 강화 조치를 진행 중인 것으로 전해졌습니다.

6. 문제점

• 가장 큰 문제는 이름·연락처를 넘어 시술·상담·결제 정보까지 포함된 점입니다. 
• 이런 정보는 사칭 연락, 피싱, 협박성 접근 등 2차 피해로 이어질 가능성이 높습니다. 
• 또 민감정보가 포함된 API 연동 구간이 외부 접근에 노출됐다는 점에서 접근통제와 데이터 최소화, 이상징후 탐지 체계의 점검 필요성이 드러났습니다.

1. 개요

• 패션 플랫폼 무신사가 운영하는 29CM에서 지난달 고객 개인정보 약 16만 건이 유출된 데 이어, 무신사·29CM에 입점한 브랜드 관계자들의 개인정보까지 추가로 유출된 사실이 확인되었습니다. 
• 무신사는 고객 개인정보 유출 사고를 조사하던 중 9월 1일 입점 브랜드 관계자 개인정보의 추가 유출 사실을 파악했으며, 해당 사고는 입점 브랜드사 관계자들이 플랫폼을 관리·운영하기 위해 사용하는 전용 페이지에서 발생했습니다.

2. 피해 범위

• 무신사는 입점 브랜드 관계자 개인정보 유출의 정확한 피해 규모와 유출된 계정 수를 공개하지 않았습니다. 
• 대상자별로 유출된 항목이 달라 모든 피해자에게 동일한 정보가 유출된 것은 아닙니다. 
• 참고로 앞선 29CM 고객 개인정보 유출 규모는 이름 13만 8,841건, 이름·이메일 주소·휴대전화 번호·배송정보 2만 1,011건(총 15만 9천여 건)으로 공개되었습니다.

3. 유출 항목

 - 입점 브랜드 관계자 정보에서 유출된 항목은 아래와 같으며, 대상자별로 유출 범위가 다릅니다.

• 아이디
• 이름
• 이메일 주소
• 휴대전화 번호
• 부서
• 직책
  
  

4. 원인

• 공격자가 전용 페이지에 어떤 방식으로 접근했는지, 어떤 보안 취약점이 악용됐는지 등 구체적인 해킹 기법과 침투 경로는 아직 공개되지 않았습니다. 
• 무신사는 관계기관과 협력해 조사를 진행 중이며, 정확한 유출 규모와 세부 내용은 현 단계에서 밝히기 어렵다고 밝혔습니다. 
• 선행한 29CM 고객 정보 유출은 주문내역 조회 기능에 발생한 외부의 비정상적인 접근이 원인으로 파악되었습니다.

5. 대응

 - 무신사는 사고 인지 후 다음 조치를 취한 것으로 알려졌습니다.

• 유출 계정 초기화 및 공격자 접근 차단
• 입점사 대상 비밀번호 재설정 요청
• 입점사 대상 2차 인증(OTP) 재등록 요청
• 플랫폼 담당자 사칭을 통한 계약·결제 유도 연락 주의 안내
• 피해 대상자에게 유출 사실 안내
• 관계기관과 협력해 사고 조사 진행

6. 문제점

• 유출된 성명·부서·직책·연락처 등은 개인과 소속을 구체적으로 특정할 수 있는 정보로, 이를 악용한 스피어피싱, 정산 사기, 플랫폼 담당자 사칭을 통한 계약·결제 유도 등 2차 범죄가 우려됩니다. 
• 특히 무신사 입점 브랜드 중에는 직원 5명 미만의 영세사가 많아, 금융 사기나 보안 사고에 휘말릴 경우 피해 복구와 브랜드 운영에 큰 타격을 입을 수 있다는 지적이 나옵니다.
•  또한 무신사가 피해 규모와 유출 계정 수를 공개하지 않아 투명성과 신속한 피해자 보호 측면에서 한계가 있다는 평가가 있습니다.

1. 개요

• 위버스컴퍼니는 2026년 9월 3일 한국인터넷진흥원(KISA)으로부터 외부 정보보안 취약점 신고 내용을 접수한 직후 내부 점검을 시작했고, 그 결과 일부 고객의 개인정보가 유출된 사실을 확인했습니다.
• 유출 규모는 계정 ID 기준으로 총 422,584건이며, 회사는 9월 4일 KISA에 유출 신고를 완료하고 공식 사과와 함께 재발 방지 대책을 발표했습니다.

2. 피해범위

• 유출된 건수는 422,584건(계정 ID 기준)으로, 위버스 플랫폼 내 특정 결제·식별 관련 데이터가 포함된 일부 계정이 대상입니다.
• 회사는 “이름, 연락처 등 직접 식별 정보나 로그인 인증 수단(비밀번호 등)은 포함되지 않았다”는 입장을 밝혔습니다.

3. 유출항목

 - 유출 항목은 크게 두 부류로 정리됩니다.

• 개인식별성이 낮은 결제 관련 정보: 결제 수단, 결제 게이트웨이(PG)사명, 통화 종류, 구매 금액 및 시간, 환불 시간 등 시스템 내부 식별자: 회원가입 시 사용자 식별을 위해 시스템 내부에서 생성된 ‘내부 식별 정보(내부 고유 번호)’
• 위버스컴퍼니는 “내부 식별 정보는 이름·연락처처럼 개인을 직접 특정할 수 있는 정보가 아니며, 내부 시스템에서만 사용되는 식별자이므로 외부에서 단독으로 악용하기 어렵다”고 설명했습니다.

4. 원인

• 직접적인 기술적 원인은 외부 신고자가 발견한 서비스 보안 취약점을 통해 일부 데이터에 접근이 가능했던 것으로 보입니다.
• 회사는 “외부 노출 API에 대한 전면 재검토, 배포 프로세스 통제 강화, 보안 모니터링 민감도 제고” 등을 재발 방지 과제로 꼽아, API 접근 제어 및 배포·모니터링 과정에서의 취약점이 원인으로 작용했음을 시사했습니다.

5. 대응

• 위버스컴퍼니는 취약점 신고 접수 직후 내부 점검과 비상 대응을 진행했고, 결제 정보 처리 API에 대한 접근 제어를 즉시 강화했습니다.
• 내부 식별 정보 제거 등 보안 조치를 완료했으며, 9월 4일 KISA에 유출 신고를 마쳤습니다.
• 관련 법령에 따라 피해 이용자에게 별도 안내 절차를 진행 중이며, 비정상 접근을 통해 정보를 획득한 외부 행위자에 대해서는 정보 반환 요청 및 법적 책임 추적을 진행하겠다고 밝혔습니다.
• 재발 방지를 위해 외부 노출 API 전면 재검토, 배포 프로세스 통제 강화, 보안 모니터링 강화 등을 약속했습니다.

6. 문제점

• 외부 신고를 통해서야 취약점과 유출 사실이 확인된 점은 사내 탐지·모니터링 체계의 한계를 보여줍니다.
• 결제·식별 관련 API가 외부에 노출된 상태에서 접근 제어가 충분하지 않았을 가능성이 제기되며, 이는 API 보안과 배포 과정의 통제 미흡으로 해석됩니다.
• 유출 항목이 직접 식별 정보는 아니라고 하지만, 결제 패턴과 내부 식별자가 결합될 경우 프로파일링 등 2차 악용 우려가 완전히 배제되기 어렵다는 점에서 투명한 영향도 분석과 이용자 안내의 구체성이 요구됩니다.

과학기술정보통신부(부총리 겸 과학기술정보통신부 장관 배경훈, 이하 “과기정통부”)는 티빙 침해사고에 대한 민관합동조사단(이하 “조사단”)의 조사 결과를 9월 3일(목)에 발표하였다.

Ⅰ. 티빙 침해사고 개요

지난 5.30일 티빙 데이터베이스(DB) 서버의 작업량 과다로 인해 시스템 과부하 현상이 발생하였다.

티빙은 이상징후를 분석하는 과정에서, 비인가자가 내부 서버에 무단 접근하여 이용자 정보를 조회한 사실을 인지하고, 6.1일 한국인터넷진흥원(원장 이상중, 이하 “KISA”)에 침해사고를 신고하였다.

과기정통부는 6.2일 KISA와 함께 현장조사를 착수하여 사고현황을 파악하였다. 이어, 6.3일 침해사고 조사 심의위원회* 심의를 거쳐 민관합동조사단을 구성하고, 피해규모와 사고원인 등에 대한 조사를 진행하였다.

* 침해사고에 선제적 대응을 위해 신설될 법정 위원회(‘26.10.1)로, ‘26.5.19부터 사전 가동

Ⅱ. 조사 범위

조사단은 티빙 이용자 정보 데이터베이스(DB)에 대한 비정상 접근으로 정보가 유출된 사실을 확인하고, 티빙 내부 시스템 접근에 필요한 접속키 탈취 경위부터 공격자가 침투한 경로, 정보유출 규모 및 정보보호 관리체계 등으로 조사범위를 설정하였다.

먼저, 티빙 시스템 침투에 악용된 접속키 탈취경위를 파악하기 위해 개발자 단말기(총 9대, 노트북 8대, PC 1대)에 대해 포렌식 분석을 실시하고, 다양한 공격 시나리오를 정밀 분석하였다.

또한, 보안장비, 데이터베이스(DB) 및 티빙 시스템의 로그(접속기록)를 연계 분석하여 공격자가 침투한 경로를 조사하였다. 이를 통해 유출된 정보의 종류와 피해 규모를 확인하고, 그에 따른 피해 영향도를 분석하였다.

아울러, 정보통신망법에 따른 정보보호조치에 관한 지침, 정보보호 관리체계 인증(ISMS) 기준, 티빙 자체규정에 대한 준수여부 및 정보보호 노력 및 역량 등 전사 차원의 정보보호 관리체계를 점검하였다.

Ⅲ. 피해 규모

조사단은 공격자가 티빙 시스템 내부에 무단 침투하여, 소스코드가 포함된 개발 프로젝트와 이용자 정보를 유출한 것을 확인하였다.

< 기술자산 유출 >

조사단은 티빙 개발환경 보안로그를 분석한 결과, 개발자가 구축 또는 개발 중인 소스코드가 포함된 개발 프로젝트 361건(30.35GB 규모)이 유출되었음을 확인하였다.

개발 프로젝트에는 이용자 맞춤형 콘텐츠 추천 및 검색 알고리즘, 이용자 관리 및 인증체계, 결제 관리, 유료 서비스 운영 등 OTT 서비스 ‘티빙(TVING)’을 운영·관리하기 위한 기술 자산이 포함되어 있었다.

< 기술자산 유출에 따른 영향 >

< 이용자 정보 유출 >

조사단은 티빙 데이터베이스(DB) 및 관련 로그 분석을 통해, 로그인이 가능한 활성화 계정 2,206만 개, 비활성화 계정 1,737만 개(휴면 계정 850만 개, 탈퇴 계정 887만 개), 테스트 계정 11만 개 등 3,954만 개 계정(중복 포함)이 유출되었음을 확인하였다.

※ 세부 수치는 반올림한 값으로, 합계가 일부 차이가 있을 수 있음

< 계정 상태에 따른 구분 >

※ 활성화 계정 : 티빙 서비스 로그인이 가능한 상태의 계정

휴면 계정 : 1년 이상 미접속하여 비활성화된 계정 * ’23.10월 이전에 한해 적용

탈퇴 계정 : 회원탈퇴로 비활성화된 계정 * 전자상거래법 등 타 법에 따른 보관 의무 有

티빙의 3,954만 개 계정은 동일인이 다수의 계정을 보유할 수 있는 구조로 중복이 포함되어 있으며, 실제 한 명의 이용자가 최대 13개 계정을 보유한 사례를 확인하였다.

또한, 가입 방식을 기준으로, 티빙 자체가입 726만 개, CJ ONE 통합회원 863만 개, SNS 간편가입(네이버, 카카오, 페이스북, 애플, X(구 트위터) 등) 2,247만 개 등으로 확인되었다.

< 가입 방식에 따른 구분 >

조사단은 침해사고로 유출된 정보가 △ID, △비밀번호(일방향 암호화), △CJ ONE 통합ID, △성명, △휴대전화 번호, △이메일 주소, △생년월일, △연계정보(CI)* 등을 포함하여 20개 항목(70종)임을 확인하였다.

* 연계정보(CI) : 주민등록번호를 대체하여, 개인을 식별하기 위한 고유값으로, 티빙 서비스 유료결제, 성인인증 등을 위한 본인인증 과정에서 생성·수집

유출 항목 중 휴대전화 번호, 이메일 주소는 일부 암호화된 상태로 유출되었으나, 암호화키가 함께 유출되어 복호화가 가능함에 따라 평문으로 유출된 정보와 동일한 수준으로 판단하였다.

한편, 비밀번호는 일방향 암호화된 상태로 유출되었으며, 평문으로 복호화가 불가능한 상태임을 확인하였다.

< 유출 항목(20개 항목, 70종) >

※ DB 보유기간 : ‘11.03.01~’26.05.31 / 규모 : 데이터베이스 약 3.5TB 및 보안장비 로그 약 5TB

다만, 연계정보(CI) 보유·미보유 등 계정 특성에 따라 유출정보의 규모에 차이가 존재하였다. 연계정보(CI) 보유 계정의 경우 더 많은 정보가 유출된 것으로 나타났다.

유출정보를 분석한 결과, 연계정보(CI) 보유 계정 1,904만 개(중복 제거 시 1,324만 개 계정)는 평균 11.1개 항목(17.6종) 유출, 연계정보(CI) 미보유 계정 2,040만 개는 평균 4.6개 항목(5.9종) 유출을 확인하였다.

특히, 연계정보(CI) 미보유 계정은 본인인증 절차를 거치지 않은 만큼, 성명, 휴대전화 번호, 이메일주소 등 정보가 누락되었거나 유효하지 않은 부정확한 데이터인 경우도 다수 존재함을 확인하였다.

※ (예시) 성명 : 123456789 / 휴대전화 번호 : 017-234-5678 / 이메일 주소 : 미입력

성명 : ㅇㅅㅂ / 이메일 주소 : Honggildong@naver.com.com

구체적인 개인정보 유출 규모는 개인정보보호위원회에서 유출 항목에 대한 상세 분석을 진행한 이후에 발표할 예정이다.

< 이용자 정보 유출에 따른 영향 >

< 계정 특성별 평균 유출정보(예시) >

※ 계정 특성별 유출 건수가 많은 항목을 표기 / 계정별 유출 정보는 상이

Ⅳ. 사고원인 분석

조사단은 공격자가 티빙 개발자의 ‘개발환경 접속키’를 탈취하여, 시스템 내부(개발환경, 운영환경)에 침투한 것을 확인하였다.

조사단은 유출 경로를 ①개발환경 침투, ②운영환경 접근 및 관리권한이 부여된 ‘운영환경 접속키’ 탈취, ③운영환경 침투, ④1차 유출 시도, ⑤2차 유출 시도 및 대규모 정보유출 등 5단계로 구분하였다.

<< 티빙 개발환경 침투 : 5.29(금) 14:42 ~ 5.29(금) 22:12 >>

① 개발환경 침투 및 프로젝트 유출

공격자는 개발자가 보유하고 있는 ‘개발환경 접속키’를 사전 탈취하여, 티빙 개발환경에 무단 접속하였다.

그 이후, ‘개발환경 접속키’를 악용하여 개발환경에서 접근 가능한 개발 프로젝트 361건 전체를 유출하였다. 공격자는 1차 공격 당시 14개 개발 프로젝트를 유출하고, 2차 공격에서 361개 개발 프로젝트 전체를 유출한 것을 확인하였다.

한편, 조사단은 ‘개발환경 접속키’ 탈취경로 확인을 위해 악용된 ‘개발환경 접속키’를 사용하고 있는 개발자를 특정하여 단말기 포렌식 분석을 실시하였고,

△피싱, △악성코드, △공급망 공격, △‘개발환경 접속키’ 공유·오남용, △취약점 악용 등 다양한 공격 시나리오를 정밀 분석하였으나, 확인이 불가능했다. 다만, 그 과정에서 키 관리체계 부실, 로그 보관기관의 한계* 등 티빙 정보보호 관리체계 상 문제점을 확인하였다.

* 티빙 시스템(VPN) 접속기록 6일 저장, 티빙 개발환경 접속기록 90일 저장

< 조사단 조사내용 >

② 운영환경 접근 및 관리권한이 부여된 ‘운영환경 접속키’ 탈취

공격자는 유출한 개발 프로젝트 내 소스코드에 저장된 티빙 운영환경에 침투할 수 있는 ‘운영환경 접속키’를 확보하였다.

조사단은 당시 티빙이 보유한 개발 프로젝트 361건에 총 43개의 ‘운영환경 접속키’가 포함되어 있음을 확인하였다.

< 운영환경 침투가 가능했을 것이라 판단한 사유>

<< 티빙 운영환경(AWS) 침투 : 5.29(금) 15:15 ~ 5.31(일) 22:20 >>

③ 운영환경 침투 및 데이터베이스 접속정보 확보

공격자는 확보한 ‘운영환경 접속키’로 운영환경 내부에 접근하였다. 그 이후, 관리자 권한 보유 여부 등 키 권한 및 정보유출에 활용할 수 있는 내부 시스템 등을 탐색하였다.

< 운영환경 접속키 분석결과 >

이 과정에서 이용자 정보가 저장된 데이터베이스(DB)에 접근할 수 있는 접속정보(ID, PW)가 암호화되지 않고 평문으로 저장되어 있는 것을 확인하고, 이를 탈취하였다.

④ 1차 정보유출 시도 : 5.30(토) 09:22 ~ 5.30(토) 18:58

공격자는 확보한 ‘운영환경 접속키’와 데이터베이스(DB) 접속정보(ID, PW)를 활용하여 클라우드 저장소에 정보유출형 공격 도구(스크립트)*를 삽입하고, 해당 저장소와 연동된 데이터베이스(DB)에 접속하여 이용자 정보 조회 및 정보유출을 시도하였다.

* 공격자가 정보유출을 위해 자체 제작한 스크립트로 확인(20종)

다만, 유출 과정에서 데이터베이스(DB) 서버의 작업량 과다로 인해 서버 CPU 이용률이 100%로 급상승(‘26.5.30 18:00)함에 따라 이상징후 알림이 발생하였다.

티빙은 이상징후 알림을 확인하고, 해당 작업을 차단 조치하였다.

⑤ 2차 정보유출 시도 및 대규모 정보유출 : 5.31(일) 19:00 ~ 5.31(일) 22:20

공격자는 가상서버 생성권한이 있는 ‘운영환경 접속키’*를 이용하여, 운영환경 내부에 가상서버를 생성한 후, 이를 정보유출을 위한 통로로 악용하여 대규모 정보유출을 하였다.

※ 1차 정보유출 시도에 사용된 접속키와 별개의 키

데이터베이스(DB)에 있는 이용자 정보를 공격자가 생성한 가상서버로 일괄 저장(24GB 규모)하고, 외부에 있는 서버로 유출하였다. 그 이후에 관련 흔적을 없애기 위해 가상서버를 삭제하였다.

이 과정에서는 1차 시도와 달리, 데이터베이스(DB) 서버 작업량 과다로 인한 이상징후 알림이 발생하지 않았다.

< 이상징후 미발생 사유 >

Ⅴ. 문제점 및 재발방지 대책

조사단은 조사를 통해 티빙의 정보보호 체계에 문제점을 발견하고 재발방지 대책을 마련하였다.

< 키 관리체계 미비 >

티빙은 키 관리가 부실하여, 오남용 및 유출로 인해 공격에 악용될 수 있는 단초를 제공하였다. 티빙 개발자는 개발·운영환경에 접근할 수 있는 접속키를 소스코드 내부에 숨김없이 그대로 노출(하드코딩)하거나, 암호화 처리를 통한 숨김없이 평문으로 저장하였다. 또한, 사내 메신저 등을 통해 타인과 무분별하게 공유한 사실을 확인하였다.

< 조사단 확인내용 >

특히, 접근권한은 업무 목적에 따라 필요 최소한으로 부여하여야 함에도, 티빙은 모든 개발자에게 전체 개발 프로젝트에 접근할 수 있는 권한을 부여하였다. 이로 인해, 공격자가 단 한 개의 ‘개발환경 접속키’를 탈취한 경우에도 모든 개발 프로젝트에 접근할 수 있었다.

또한, 키 발급·사용·변경·폐기 및 정기점검 등을 위한 관리절차를 수립하여야 함에도, 관련 체계가 부재하였다.

⇒ (재발방지 대책) 티빙은 키 관리·통제·접근권한 체계를 구축하고, 운영관리 기준을 명확화해야 한다. 또한, 키 발급·사용 이력 관리를 위한 체계 구축 및 상시 점검을 실시하여야 한다.

< 비정상 행위 탐지·대응 및 모니터링 체계 부재 >

티빙은 공격자의 비정상 행위가 발생했음에도, 해당 공격행위를 탐지·대응하지 못했다. CPU 부하 등 단순 모니터링에만 의존하였으며, 네트워크 및 데이터 흐름 등을 실시간으로 탐지·차단할 수 있는 정보보호 체계가 부재하였다.

또한, 권한 없는 자의 비정상 접속을 통제하기 위한 네트워크 및 시스템 접근제어 정책이 부재하였다.

※(예시) 인가된 IP에 한해 접근 허용(IP ACL), 다중인증(MFA) 등 인증체계 강화

⇒ (재발방지 대책) 티빙은 비정상 행위 탐지 및 대량 데이터 조회 모니터링 체계를 강화하여야 한다. 그리고, 인가된 사용자 및 단말기(PC, 노트북 등)에 한해 시스템 내부에 접근할 수 있도록 접근제어 정책을 강화하여야 한다.

< 정보보호 거버넌스 미흡 >

티빙은 전체 임직원은 265명, 개발인력은 149명 규모임에 반해, 정보보호 전담인력은 4명 내외(외주인력 제외)로 구성되어 있었다. 조사단은 현 인력 수준으로는 상시 보안관제, 취약점 점검 및 비정상 행위 모니터링 등 다양한 정보보호 활동을 수행하는 데 한계가 있을 것이라 판단하였다.

이와 함께, 침해사고 발생 시 초동조치를 위한 부서 간 신속한 상황전파 및 협업체계가 미흡한 사실을 확인하였다. 실제 이상징후 발생 시점(5.30 18:00)으로부터 약 14시간이 지난 후에야 침해사고 대응을 총괄하는 정보보호 전담조직과 정보보호 최고책임자(CISO)에게 상황 공유가 되었다.

※티빙 자체규정「침해사고 및 보안사고 대응절차」

(정보보호 최고책임자(CISO) 주요 대응업무 : 보안사고 조사 및 대응 총괄)

⇒ (재발방지 대책) 티빙은 충분한 정보보호 전담인력·예산을 확보하고, 정보보호 전담부서 역할 및 부서 간 협업·대응체계를 재정립하여야 한다.

< 정보보호 활동 미흡 >

티빙은 ’24년 모의해킹 결과, ‘개발·운영환경 접속키’를 소스코드 내부에 숨김없이 그대로 노출(하드코딩)하는 취약점을 발견하였음에도, 개선 조치하지 않았다.

또한, 시스템 로그를 관리하고 있으나, 선별적 저장·관리로 인해 신규 장비(VPN)에는 로그관리 정책이 제대로 적용되지 않아 약 6일 간의 접속기록만 보관되고 있었다.

조사 과정에서, 업무용 PC 대상 백신 소프트웨어(SW) 설치 및 최신버전 관리 등 정기적 보안점검이 미흡한 사실도 확인하였다.

※티빙 자체규정「정보보호지침」 제24조(정보처리기기 관리 및 IoT 기기 관리)

⇒ (재발방지 대책) 티빙은 로그 저장관리 정책을 수립하고, 모의해킹 등 주기적 취약점 점검을 실시하고 발견된 취약점에 대한 조치체계를 강화하여야 한다. 아울러, 자체 보안규정 준수 여부를 정기적으로 점검하고, 미준수 사항을 즉각 개선할 수 있는 관리체계를 구축하여야 한다.

< 법 위반사항 : 침해사고 신고 지연>

티빙은 정보통신망법 제48조의3에 따라 침해사고를 인지한 후 24시간 이내에 과기정통부 또는 KISA에 신고하여야 한다. 그러나, 정보보안팀에 상황을 전파한 시점(‘26.5.31 10:10)으로부터 24시간이 지난 후 KISA에 신고(’26.6.1 15:08)하였다.

※ (침해사고 인지시점) 침해사고 발생을 알게 된 때는 정보보호 담당자, 정보보호 담당부서의 장, 정보보호 최고책임자, 기업 대표자 등이 정보통신망법 제2조에 정의된 침해사고의 발생을 알게 된 때를 말한다.(정보통신분야 침해사고 대응 안내서, ’25.8월)

⇒ (조치 사항) 정보통신망법에 따른 과태료를 부과할 예정이다.

※ 정보통신망법 제76조에 따라 3천만원 이하 과태료 부과 대상

Ⅵ. 향후 계획

< 티빙 침해사고 이행점검 >

과기정통부는 이번 조사단 조사결과를 토대로, 티빙에 재발방지 대책에 따른 이행계획을 제출(9월)토록 하고, 티빙의 이행(10~12월) 여부를 점검(‘27.1월~)할 계획이다. 이행점검 결과, 보완이 필요한 사항에 대해서는 정보통신망법 제48조의4에 따라 시정조치를 명령할 계획이다.

< 국가 전반의 정보보호 역량 강화를 위한 「정보보호 종합대책」 후속조치 >

한편 안보실 중심으로 과기정통부와 관계부처가 합동으로 수립한 ｢제1차 및 제2차 범부처 종합대책｣(’25.10월, ’26.1월)을 통해 전 국가적인 정보보호 역량 강화를 추진해 왔다.

과기정통부와 개인정보보호위원회(이하 ‘개인정보위’)는 각각 국민 생활과 밀접한 기업들과 통신 3사, 상조·금융 분야 및 고객센터·에듀테크·의료 분야 등에 대한 점검을 추진하였으며, 양 부처가 ｢정보보호 및 개인정보보호 관리체계* (ISMS·ISMS-P) 인증제 실효성 강화방안｣을 수립(’26.4월)하고 내년까지 순차적으로 인증 제도 전반을 개선해 나갈 예정이다. 이에 더해 과기정통부는 관계기관(국가정보원, 한국인터넷진흥원)과 함께 국내 최초로「보안 취약점 신고·조치·공개(CVD/VDP**) 제도」 시범 사업(’26.5월)을 추진하는 등 침해 사고에 대한 예방･대응 역량을 제고하는 정책을 추진하고 있다.

* ISMS·ISMS-P(Personal Information & Information Security Management System): 주요 정보자산 유출 및 피해 예방을 위해 기업 또는 기관이 구축․운영 중인 개인정보 및 정보보호 체계가 적합한지 인증(정보통신망법 제47조, 개인정보보호법 제32조의2에 근거)

** 화이트해커가 자사 취약점을 합법적으로 찾고 신고할 수 있도록 하는 ‘취약점 공개 정책’ (VDP : Vulnerability Disclosure Policy)과 ‘신고된 취약점을 조치한 이후에 공개하는 정책’ (CVD : Coordinated Vulnerability Disclosure)을 의미

정부는 관련 법적 제도를 완비하는 데에도 박차를 가하고 있으며, 올해 9월과 10월부터 주요 개정 법안이 시행될 예정이다.

먼저 이번 달 11일부터 개정된 개인정보보호법이 시행되어 개인정보 유출에 대해 엄정하게 제재하고 사전예방을 위한 투자를 촉진하게 된다. 반복적이거나 고의·중과실 등에 의한 대규모 개인정보 유출 발생 시 전체 매출액의 최대 10%까지 징벌적 과징금을 부과할 수 있도록 하고, 사전 예방적 개인정보 보호 투자와 연계한 과징금 감경제를 도입하며 개인정보처리자가 ‘유출 등의 가능성이 있음을 알게 되었을 때’에도 지체없이 정보 주체에게 통지하도록 하였다.

이어 10월 1월부터 개정된 정보통신망법이 시행됨에 따라 사이버 침해사고의 예방부터 대응에 이르는 제도 전반이 실효성 있게 운영된다. 주요 기업은 정보보호 인력, 예산을 확충해야 하며, 정부가 기업의 해킹사고 정황을 확보했을 경우 기업의 신고 전에도 조사에 착수할 수 있는 근거가 마련된다. 또한 재발방지 대책을 불성실하게 이행한 기업에 대한 이행강제금이 신설되는 등 기업의 책임성이 강화된다.

과기정통부와 개인정보위는 관련 법이 차질없이 시행될 수 있도록 만전을 기하고, 법 시행 이후에도 현장에서 잘 적용될 수 있도록 이행상황을 지속 점검할 계획이다.

https://www.msit.go.kr/bbs/view.do?sCode=user&mId=307&mPid=208&bbsSeqNo=94&nttSeqNo=3187739