와이즈스톤 와이즈스톤

기술인사이트

기술리포트

롯데카드 사태와 보안 테스트의 중요성
  • 작성자
    와이즈스톤 김홍기 이사
  • 작성일
    2025-09-24
1. 사건 개요
롯데카드에서 발생한 개인정보 유출 사건은 약 297만 명 규모의 고객 정보가 외부로 유출된 사건으로 알려졌다.
처음에는 소규모 데이터 유출로 보고되었으나 조사 결과 약 200GB에 달하는 대량의 데이터가 외부로 유출된 사실이 확인되었고, 이로 인해 고객들의 불안과 분노가 확산되었다.
​
특히 유출된 데이터에는 카드번호와 유효기간, CVC, 카드 비밀번호와 같이 결제 과정에서 직접 사용되는 민감 정보가 포함된 사례가 다수 보고되었는데,
이 점은 단순한 개인정보 유출을 넘어 실제 금융 범죄로 이어질 수 있는 심각한 위험을 내포하고 있다.
​
회사는 초기 대응으로 악성코드 제거와 일부 취약점 보완 조치를 시행했다고 밝혔지만,
그 과정에서 탐지와 공지 사이에 시차가 있었다는 지적이 제기되었고 정밀 조사를 통해 유출 규모와 민감 정보 포함 사실이 드러나면서 사태의 심각성이 확산되었다.


사건의 시간표를 추적해 보면, 최초 침해가 발생한 시점부터 외부로 데이터가 유출되기까지 여러 단계가 존재했을 가능성이 높다.
공격자는 먼저 외부에서 접근 가능한 웹 애플리케이션 또는 서비스의 취약점을 탐지하고 이를 통해 웹셸을 업로드하거나 원격 명령을 실행할 수 있는 권한을 확보했을 것이다.

그 다음으로 확보한 권한을 바탕으로 내부 네트워크로 이동하거나 데이터베이스에 접근하여 민감 정보를 검색하고 추출했을 가능성이 높다.
이렇게 추출된 데이터는 압축되거나 암호화되지 않은 상태로 외부 전송 경로를 통해 유출되었을 수 있는데,
이 과정에서 로그나 모니터링 체계가 적시에 이상 행동을 탐지하지 못했기 때문에 유출이 장기간 진행되었을 수 있다.
​
이 사건은 단순히 기술적 취약점 하나가 문제가 된 것이 아니라 조직 전반의 보안 검증 체계, 즉 보안테스트의 부재나 미비가 결합되어 피해를 증폭시킨 전형적인 사례로 볼 수 있다.
​
애플리케이션의 코드 수준 결함을 사전에 발견하지 못했고, 운영환경에서의 구성 오류나 백업·로그 관리의 미흡함을 검증하지 않았으며,
침해 탐지와 사고 대응 절차를 실제로 점검·훈련하지 않았기 때문에 공격자는 비교적 자유롭게 데이터를 수집하고 외부로 전송할 수 있었다.
​
2. 기술적 원인 분석
먼저 공격 벡터 관점에서 분석해 보면, 공격자는 웹 애플리케이션의 파일 업로드 취약점이나 원격 코드 실행 취약점을 이용해 웹셸을 심었을 가능성이 크다.
웹셸이 설치되면 공격자는 서버 내 권한을 상승시키거나 추가 악성코드를 설치하여 지속적인 내부 접근권을 확보할 수 있다.
​
이와 같은 공격 흐름은 개발 단계에서의 입력 검증 부족, 파일 업로드 처리 로직의 안전성 미 검증, 권한 분리 미흡 등 단순한 소프트웨어 결함에서 출발하는 경우가 많다.
따라서 개발 과정에서 정적 분석과 동적 분석을 통한 검증이 이루어졌다면 웹셸 업로드 가능성을 줄였을 것이다.
​
두 번째로 데이터 흐름과 저장 경로를 보면, 민감정보는 단일 지점에만 저장되는 것이 아니라 데이터베이스 테이블, 로그 파일, 백업 파일, 데이터 아카이브 등 다양한 장소에 분산되어 존재한다.
공격자는 상대적으로 보안 통제가 약한 지점을 찾아 침투하는 경향이 있다.
​
예를 들어 백업 파일이 별도 암호화 없이 보관되어 있거나 로그가 평문으로 남아 있다면 공격자는 이 경로를 이용해 대량의 데이터를 손쉽게 확보할 수 있다.
따라서 민감 정보의 저장·전송·백업 경로 전체에 대한 점검이 이루어지지 않았다면 이러한 경로를 통해 대규모 유출이 발생할 수 있다.
​
세 번째로 권한 관리와 접근 통제의 실패가 중요한 원인으로 작용했을 것이다.
운영자 계정이나 서비스 계정에 과도한 권한이 부여되어 있거나 비밀번호와 자격 증명이 장기간 교체되지 않았을 경우, 공격자는 단일 계정의 탈취만으로도 데이터베이스에 접근해 대량의 데이터를 추출할 수 있다.
또한 암호화 키나 인증 토큰이 소스코드에 하드코딩되어 있거나 접근 통제가 느슨한 저장소에 저장되어 있었다면, 암호화 자체가 적용되어 있더라도 키가 노출되어 원문을 복원 당할 가능성이 있다.
​
네 번째로 탐지·모니터링 체계의 한계가 사건을 키웠다.
비정상적인 대량 쿼리 발생, 관리자 계정의 이례적인 사용 기록, 대용량 파일 압축 및 전송 행위 등은 통상적으로 이상 징후로 분류되어야 한다.
그러나 SIEM(보안정보 및 이벤트 관리)이나 EDR(엔드포인트 탐지·대응) 시스템의 룰이 적절히 설정되어 있지 않거나, 알람 임계치가 비현실적으로 높아진 상태라면 이러한 징후를 즉시 탐지하지 못할 수 있다.
이 경우 초기 침해를 늦게 인지하게 되어 골든 타임을 놓치고 피해가 확대될 위험이 있다.
​
다섯째로 구성 및 패치 관리의 실패도 배제할 수 없다.
알려진 취약점들이 제때 패치 되지 않으면 자동화된 스캔이나 봇에 의해 쉽게 노출된다.
운영 시스템의 기본 설정과 디폴트 계정, 불필요한 서비스가 남아 있는 경우 공격자는 이들 취약점을 통해 내부로 진입할 수 있다.
따라서 정기적인 패치 적용과 구성 점검이 없었다면 취약점이 장기간 방치되어 공격에 악용되었을 가능성이 크다.
​
마지막으로 로그와 증적의 관리 문제이다.
공격자는 자신의 흔적을 지우기 위해 접근 로그를 삭제하거나 변조하려고 시도할 수 있다.
이런 상황에서 로그가 중앙집중형으로 수집·보관되어 있지 않거나, 로그 자체의 무결성이 보장되지 않는다면 포렌식 조사에서 침해의 최초 진입점을 파악하기 어렵게 된다.
이는 사고의 원인 규명과 재발 방지 조치 수립을 더 어렵게 만드는 요인이 된다.
​
3. 테스트 중심의 문제 진단과 해결 방향
보안 테스트는 단순히 취약점을 발견하는 활동을 넘어 조직의 방어선이 실제로 작동하는지를 검증하는 핵심 수단이다.
사전 검증, 운영 중 검증, 사고대응 검증이 모두 포함되어야 하며 이 세 가지 축이 유기적으로 결합될 때만 실질적인 보호 효과를 얻을 수 있다.


먼저 사전 검증의 영역에서는 코드 레벨의 정적 분석이 필수적이다.
개발 단계에서 입력 값 검증 누락, 인증 로직 오류, 암호화 API의 오용, 키 하드 코딩과 같은 문제를 정적 분석 도구로 자동 검사하면 배포 전에 많은 취약점을 제거할 수 있다.

정적 분석과 더불어 개발자가 사용하는 오픈소스 라이브러리의 취약점을 자동으로 스캔하는 체계를 도입하면 알려진 취약점으로 인한 침해 위험을 줄일 수 있다.
​
운영 중 검증은 런타임 환경에서 발생할 수 있는 취약점을 점검하는 활동을 의미한다.
동적 분석을 통해 파일 업로드 처리, 세션 관리, 인증 우회와 같은 런타임 취약점을 탐지하고 모의 공격을 통해 서비스가 실제로 어떤 방식으로 악용될 수 있는지를 확인해야 한다.
또한 백업, 로그, 데이터 아카이브와 같이 평상시에는 눈에 잘 띄지 않는 데이터 경로에 대해서도 모의 추출 테스트를 수행해 실제로 민감 정보가 유출 가능한지 점검해야 한다.
​
침투테스트는 공격자의 관점에서 시스템을 평가하는 가장 현실적인 검증 방법이다.
외부에서부터 내부로 이어지는 공격 시나리오를 구성해 인증 우회, 권한 상승, 데이터베이스 덤프, 압축 및 외부 전송에 이르는 전체 흐름을 재현해 보면 어느 지점에서 탐지가 실패하고 어떤 통제 장치가 우회되는지를 명확히 확인할 수 있다.
침투테스트의 결과는 단순한 취약점 목록이 아니라, 실질적인 위협 시나리오와 그에 대한 개선 우선순위를 제시해야 한다.
​
레드팀과 블루팀의 연습도 중요하다.
레드팀은 실제 공격자처럼 목표 달성을 위해 장기적이고 은밀한 공격을 수행하며 조직의 탐지·대응 능력을 시험한다.
블루팀은 이 공격을 탐지하고 차단하며 포렌식을 수행하는 팀으로, 레드팀 활동을 통해 SIEM 룰과 EDR 정책을 개선하고 대응 프로세스를 보완할 수 있다.
이러한 상호 훈련은 이론적 정책이 실제로 작동하는지를 검증하는 데 핵심적이다.
​
마지막으로 테스트 결과의 처리 절차가 중요하다.
취약점이 발견되면 이를 심각도 별로 분류하고, 명확한 기한과 책임자를 정해 패치 하거나 설정을 변경해야 한다.
수정이 완료된 후에는 반드시 재 검증을 수행해 취약점이 실제로 해소 되었는지를 확인해야 한다.
이 일련의 과정이 반복적으로 이루어질 때만 시스템의 보안 수준은 실질적으로 향상된다.
​
4. 보안 테스트 방법론
효과적인 보안테스트를 위해서는 다양한 도구와 방법을 조합하여 단계별로 실행하는 것이 필요하다.
개발 단계에서는 정적 분석 도구를 CI/CD 파이프라인에 통합하여 풀리퀘스트나 빌드 시 자동으로 코드취약점을 검사하도록 해야 한다.
정적 분석 도구는 입력 값 검증 누락, 경로 탐색 취약점, 민감 정보 하드 코딩 여부 등을 자동 탐지할 수 있으므로 개발자들이 보안 결함을 조기에 수정할 수 있게 돕는다.
​
운영 전·운영 중에는 동적 분석 도구와 자동화된 웹 취약점 스캐너를 사용해 실제 서비스 동작 환경에서의 취약점을 점검해야 한다.
이때 스캐닝 대상에는 관리자 포털, API 엔드포인트, 공개된 웹 페이지뿐 아니라 내부에서만 접근 가능한 백업 인터페이스나 로그 조회 경로도 포함되어야 한다.
스캐닝 후에는 탐지된 취약점의 실제 악용 가능성을 검증하기 위한 수동 점검과 모의 공격을 수행해야 한다.
​
침투테스트는 외부 기관과 협업해 주기적으로 수행하는 것이 바람직하다.
침투테스트는 외부에서 접근 가능한 자산에 대한 공격 시나리오뿐 아니라, 내부 직원 권한을 획득했을 때 데이터에 접근하는 내부 침투 시나리오도 포함해야 한다.

예를 들어 공격자가 관리자 계정의 자격증명을 확보했을 때 어떤 데이터베이스 테이블에 접근할 수 있는지, 백업 파일을 어떻게 생성하고 접근할 수 있는지, 생성된 파일을 압축해 외부로 전송하는 과정이 탐지되는지를 확인해 보아야 한다.
​
레드팀 활동을 통해서는 장기간에 걸친 은밀한 공격 시나리오를 시험해 볼 수 있다.
레드팀은 단발성 취약점 공격이 아니라, 여러 기술을 조합해 방어의 사각지대를 찾아내고 실제 데이터 획득 가능성을 입증한다.
레드팀의 활동 결과는 블루팀과 공유되어 SIEM과 EDR의 룰을 개선하고 탐지 임계 치를 조정하는 데 사용되어야 한다.
​
테스트 산출물은 단순한 보고서로 끝나서는 안 된다.
테스트 리포트는 구체적인 재현 절차(Proof of Concept), 영향 범위, 권고 조치, 우선순위 및 예상 난이도를 포함해야 하며,
이를 바탕으로 취약점 처리 계획을 수립하고 진행 상황을 추적해야 한다.
또한 모든 테스트 결과와 취약점 처리 결과는 감사 가능한 형태로 보관되어야 한다.
​
5. 데이터 암호화와 키 관리 점검
데이터 암호화는 민감 정보를 유출된 경우에도 원문 노출을 막는 핵심 방어 수단이다.
그러나 암호화 기술을 도입하는 것만으로 충분하지 않으며, 암호화가 실제로 효과를 발휘하려면 암호화 적용 범위, 키관리, 복호화 경로의 통제 등이 함께 검증되어야 한다.
​
먼저 암호화의 적용 범위를 점검해야 한다.
카드번호와 같은 결제 정보는 가능한 한 토큰화 방식으로 저장하는 것이 바람직하며, 토큰화를 적용하기 어려운 경우에는 강력한 대칭키 암호화를 적용해야 한다.
또한 데이터베이스에 저장되는 본문뿐 아니라 로그, 백업, 스냅샷, 데이터 아카이브 등 모든 저장 지점에서 암호화가 적용되어 있는지 확인해야 한다.
로그 파일이나 백업이 평문으로 남아 있다면, 메인 데이터베이스가 암호화되어 있어도 유출 시 원문이 그대로 노출될 위험이 있다.
​
전송 중인 데이터의 암호화도 놓쳐서는 안 된다.
내부 네트워크에서만 통신한다고 해서 전송 경로에 대한 암호화를 소홀히 하면 안 된다.
서비스 간 통신에서도 기본적인 TLS 적용 외에 상호 TLS(mTLS)를 적용해 서비스 인증과 통신 무결성을 보장하는 것이 바람직하다.
특히 외부로 데이터를 전송하는 과정에서는 전송 채널이 안전한지, 중간에 프록시나 로그 장치가 평문을 기록하지는 않는지 점검해야 한다.
​
키 관리는 암호화 효과를 좌우하는 핵심 요소다.
암호화 키가 안전하게 보관되고 접근이 엄격하게 통제되어야 한다. 키는 전용 키관리시스템이나 하드웨어 보안 모듈(HSM)에 저장해야 하며,
키 접근은 최소 권한 원칙에 따라 통제되고 모든 키 사용은 감사 로그에 남겨야 한다.
또한 키의 주기적 교체, 비상 시 키 폐기 및 재발급 절차, 키의 백업·복구 절차가 문서화되고 주기적으로 테스트되어야 한다.
​
토큰화 시스템을 사용할 경우 토큰 발급 및 복원(Detokenization) 절차 역시 엄격히 통제되어야 한다.
토큰을 본문으로 복원하는 권한은 매우 제한적으로 부여되어야 하며, 복원 요청이 발생할 때마다 그 행위는 감사 로그에 기록되어야 한다.
토큰 매핑 테이블 자체도 별도의 접근 통제와 암호화가 적용되어야 하며, 토큰 매핑 DB가 노출되면 토큰화의 효과가 무력화될 수 있다.
​
암호화 적용 여부를 점검하는 자동화 도구를 도입하면 데이터베이스 스키마 별로 민감 필드가 암호화 되었는지, 로그와 백업의 암호화 상태는 어떤지를 주기적으로 검사할 수 있다.

또한 복호화 경로가 불필요하게 열려 있지 않은지, 관리자 화면에서 평문이 노출되지 않는지, 테스트나 개발 환경에서 민감 정보가 마스킹 되지 않고 그대로 남아 있지 않은지 등을 점검하는 것도 중요하다.
​
마지막으로 키 탈취 시나리오에 대한 모의 검증도 필요하다.
키 관리 시스템의 콘솔 접근 계정이나 API 키가 탈취 되었을 때 어떤 영향이 발생하는지, 복호화 요청이 남용될 우려가 있는지를 실제로 검증해 보고, 그 결과에 따라 다중 승인·작업 분리 등 추가 통제 수단을 도입해야 한다.
​
6. 탐지·사고 대응 및 포렌식 준비
탐지 역량을 강화하기 위해서는 이상 징후를 빠르게 포착할 수 있는 알람과 룰을 마련해야 한다.
예를 들어 평상시보다 훨씬 많은 양의 데이터베이스 쿼리가 발생하거나, 관리자 계정이 평소와 다른 시간대 또는 다른 지역의 IP에서 접속하면 경고가 울리도록 설정해야 한다.
​
대량의 파일 압축이나 비정상적인 파일 확장자 생성, 외부로의 다수의 SFTP 연결 시도 등도 탐지 규칙에 포함해야 하며, 이 모든 이벤트는 SIEM으로 중앙 수집되어 상관분석을 통해 경보를 생성해야 한다.
​
로그의 무결성을 확보하는 것도 매우 중요하다.
공격자가 접근 로그를 삭제하거나 변조하려고 시도할 수 있기 때문에 로그는 중앙 집중형 수집 시스템에 실시간으로 전송되고, 가능한 경우 쓰기 금지(WORM) 스토리지에 보관하여 훼손 가능성을 최소화해야 한다.
또한 주요 시스템의 순간 이미지와 메모리 덤프를 확보할 수 있는 절차를 마련해 포렌식 분석에 필요한 증적을 보존할 수 있도록 해야 한다.
​
사고 대응 프로세스는 사전 준비와 훈련이 핵심이다.
사고 발생 시 조직은 우선적으로 의심 자산을 격리하고, 확산을 막기 위한 긴급 조치를 수행해야 한다.
동시에 포렌식 팀은 증적 수집을 시작하여 침해의 범위와 경로를 분석해야 하며, 법적 절차와 규제기관 통보를 고려해 증적의 무결성을 유지하며 조사를 진행해야 한다.
​
고객 통지와 PR, 법무 대응, 규제기관 보고 등 외부 커뮤니케이션 절차도 사전에 템플릿화하고 역할과 책임을 명확히 하여 실제 사고 시 혼선을 줄여야 한다.
​
훈련 측면에서는 테이블탑 연습과 풀 스케일 모의훈련을 병행해야 한다.
테이블탑 연습에서는 경영진부터 실무자까지 참여해 사고 발생 시 의사결정과 커뮤니케이션 경로를 점검한다.
풀 스케일 모의훈련에서는 실제 시스템(샌드박스 환경 등)을 활용해 봉쇄·증적수집·분석·통보·복구 절차를 시간 기반으로 수행해보고 문제점을 도출해 개선해야 한다.
​
7. 조직적·제도적 개선
보안은 기술적 조치뿐 아니라 조직 구조와 의사결정 체계의 문제이기도 하다.
보안 투자와 보안 우선순위는 경영진의 인식과 정책적 지원이 있어야 실질적인 변화를 만들 수 있다.
따라서 CISO 역할의 명확화와 권한 강화가 필요하고, 보안 관련 의사결정이 신속히 이루어질 수 있는 보고 구조를 구축해야 한다.
​
경영진은 정기적으로 보안 상태와 테스트 결과를 보고받고, 발견된 고위험 취약점에 대해서는 우선순위를 직접 지정하여 자원을 신속히 배정해야 한다.

또한 보안 관련 예산을 단기 비용이 아닌 핵심 리스크 관리 비용으로 인식하도록 조직 문화를 전환해야 한다.
보안테스트와 모의훈련, 암호화 및 키 관리 시스템 도입 등은 초기에 비용이 들지만, 장기적으로는 대규모 유출로 인한 손해와 신뢰 손실을 예방하는 데 가장 비용효율적인 투자다.
이를 위해 보안 KPI를 수립하고, 취약점 해결율, 재검증 완료율, 모의훈련 수행률 등 구체적 지표로 보안 성과를 관리해야 한다.
​
사내 교육과 인식 개선도 빼놓을 수 없다.
개발자에게는 보안 코딩 교육을 정기적으로 실시하고, 운영·운영지원팀에는 민감 데이터 취급 시 주의사항과 암호화·키관리 절차에 대한 교육을 제공해야 한다.
일반 직원 대상의 피싱 대응 교육과 모의 피싱 테스트도 정기적으로 실시하여 사회공학적 공격에 대한 조직 차원의 저항력을 키워야 한다.
​
내부 감사와 외부 감사 체계도 강화되어야 한다.
정기적인 내부 보안감사에서 테스트 결과와 취약점 처리 현황을 점검하고, 필요 시 외부 전문기관에 의한 독립적인 보안 점검을 수행하여 내부 편향을 보완해야 한다.
또한 규제기관의 요구사항에 대해 투명하게 대응하고, 사고 발생 시 신속하고 정확한 정보 제공을 통해 신뢰 회복에 주력해야 한다.
​
8. 실행 로드맵
우선적으로 수행해야 할 단기 조치는 민감데이터에 대한 긴급 접근 제한과 의심 자산의 격리이다.
초기 대응팀은 즉시 의심되는 관리자 계정의 비밀번호를 변경하고 세션을 만료 시켜 추가적인 접근을 차단해야 한다.
동시에 백업이나 로그 등으로의 추가 데이터 유출 가능성을 차단하기 위해 관련 저장소의 접근 권한을 제한하고 네트워크 경로를 차단해야 한다.
이러한 단기 조치는 피해를 더 이상 확대시키지 않기 위한 응급 처방이다.
​
중기적으로는 DevSecOps 체계 도입과 CI/CD 파이프라인에 정적 분석과 동적 분석 스캐너를 통합하는 작업을 추진해야 한다.
이를 통해 코드가 변경될 때마다 자동으로 보안 검증이 수행되며, 취약점이 발견되면 배포를 차단하거나 즉시 수정하도록 워크플로우를 구성할 수 있다.

중기 조치에는 또한 암호화 적용 범위의 전수 점검과 토큰화 도입 계획 수립, 전용 키 관리 시스템 도입 검토도 포함되어야 하며, 이들 기술적 조치는 보안테스트와 함께 병행되어야 실효를 거둘 수 있다.
​
장기적으로는 조직문화와 거버넌스의 변화를 추진해야 한다.
CISO의 권한을 강화하고 보안 관련 결정이 경영진의 우선순위에 포함되도록 보장해야 한다.
또한 정기적인 침투테스트와 레드팀 활동을 제도화하여 사실상 연속적인 테스트 체계를 운영해야 한다.
테스트는 일회성이 아니라 지속적으로 반복되어야 하며, 각 테스트에서 도출된 개선 사항은 체계적으로 반영되어야 한다. 이를 통해 조직은 점진적으로 보안 성숙도를 높일 수 있다.
​
9. 결론
롯데카드의 개인정보 유출 사건은 조직의 보안 검증 체계가 얼마나 중요한지 여실히 보여주는 사례이다.
이 사건은 단일 취약점의 존재보다도, 취약점이 발견되고 수정되어야 하는 과정과 탐지·대응 체계가 제대로 작동하지 않았을 때 어떤 결과가 초래되는지 적나라하게 드러낸다.
​
보안테스트는 취약점을 찾아내는 도구이자 탐지 체계와 대응 능력이 실제로 작동하는지 검증하는 최종 안전장치이다.
따라서 모든 데이터 보유 조직은 개발 단계·운영 단계·사고대응 단계에 이르기까지 전 주기에 걸쳐 지속적이고 자동화된 보안 테스트 체계를 구축해야 하며, 데이터 암호화와 키 관리는 테스트 항목으로 항상 포함하여 실효성을 검증해야 한다.

이러한 노력이 없다면 유사한 사고는 언제든 반복될 수 있으며, 그 피해는 기업과 고객 모두에게 막대하게 돌아갈 것이다.
​
와이즈스톤에서는 이러한 보안 사고를 사전에 예방하고 보안 품질을 강화하기 위하여 취약점 진단 서비스를 제공하고 있으며 EN 18031기반의 CE RED 사이버보안 시험도 활발하게 진행하고 있다.

제품 또는 서비스의 보안 약점이 고민 된다면 이러한 서비스를 통하여 단기간에 보안 품질을 확보하고 시장에서의 경쟁력을 강화하는 것이 최선의 방법이라고 단언한다.