하나의 서명키가 만든 초대형 보안 사고
2025년 11월, 대한민국을 충격에 빠뜨린 보안 사고가 발생했습니다. 국내 최대 이커머스 플랫폼에서 약 3,370만 명에 달하는 회원의 개인정보가 유출된 것입니다. 국민 4명 중 3명의 정보가 노출된 이 사건의 핵심 원인은 놀랍게도 단순했습니다. 퇴직자가 가지고 있던 인증 토큰 생성용 서명키가 제대로 관리되지 않았고, 이것이 5개월 동안 무단 접근을 가능하게 했습니다.
더 충격적인 사실은 2024년 기준 861억 원을 정보 보호에 투자한 기업에서 이런 일이 벌어졌다는 점 입니다. 국회는 이를 "단순 보안 사고가 아니라 보안 거버넌스 전반의 붕괴"라고 평가했습니다. 막대한 보안 예산에도 불구하고 기본적인 시크릿 관리가 작동하지 않았던 것입니다.
이 사고는 명확한 메시지를 전달합니다. 바로 "현대 소프트웨어 보안의 가장 큰 위협은 잘못 관리된 시크릿이다" 죠. API 키, 인증 토큰, 데이터베이스 자격증명, 서명키 - 이 모든 것이 제대로 관리되지 않으면 조직 전체를 무너뜨릴 수 있는 단일 실패 지점이 됩니다.
시크릿 관리의 세 가지 치명적 실패 패턴
1. 하드코딩된 시크릿: 가장 흔하고 가장 위험한 실수
개발자들은 종종 편의를 위해 API 키나 데이터베이스 비밀번호를 코드에 직접 작성합니다. 특히 AI 코딩 어시스턴트의 등장으로 이 문제는 더욱 심각해졌습니다. 개발자들이 AI가 생성한 코드를 깊이 검증하지 않고 사용하는 "vibecoding" 현상은 두 가지 위험을 만듭니다:
- 경험 많은 개발자의 착각: AI가 자신과 동일한 수준의 보안 검증을 수행할 것이라 가정하고 코드 리뷰를 건너뛴다
- 주니어 개발자의 과신: AI의 도움으로 자신의 실력을 넘어서는 복잡한 통합을 구축하지만, 보안 문제를 식별할 기초 지식이 부족하다
실제 사례를 살펴보겠습니다. 주니어 개발자가 Claude에게 MCP 날씨 서버 코드를 생성하도록 요청합니다. 자신의 API 자격증명으로 테스트하고 작동하는 것을 확인한 후 커밋합니다. 문제는? 개발자가 Claude가 생성한 내용을 검토하지 않아서 .env 파일에 하드코딩된 API 키를 GitHub에 그대로 커밋했다는 것입니다.
2. 장기 지속 자격증명: 시한폭탄 같은 존재
이번 대형 유출 사고의 핵심 원인이 바로 이것입니다. 퇴직자의 손에 남아 있던 서명키는 몇 달, 어쩌면 몇 년간 유효했을 가능성이 큽니다. 장기 지속 자격증명(long-lived credentials)의 문제점은 명확합니다:
- 회전(rotation) 부재: 정기적으로 갱신되지 않는 자격증명은 유출되어도 즉시 발견되지 않는다
- 권한 누적: 시간이 지나면서 필요 이상의 권한을 축적한다
- 추적 불가: 누가, 언제, 왜 해당 자격증명을 사용했는지 추적이 어렵다
통계는 충격적입니다. 비인간 신원(NHI)은 인간 신원보다 50배 많고, 그 중 97%가 과도한 권한을 가지고 있습니다. 이들 대부분이 장기 지속 자격증명을 사용하고 있습니다.
3. 시크릿 스프롤(Secret Sprawl): 보이지 않는 위협
시크릿은 더 이상 코드 저장소에만 존재하지 않습니다. 현대 개발 환경에서 시크릿은 다음과 같은 곳곳에 흩어져 있습니다:
- Slack 대화 스레드
- Confluence 문서
- 개발자 로컬 머신
- CI/CD 파이프라인 설정
- 컨테이너 이미지
- 환경 변수
- 설정 파일
코드가 수초 만에 생성되고, 글로벌 팀이 24시간 협업하며, 수십 개의 디지털 채널을 통해 정보가 공유되는 환경에서, 시크릿은 우리가 의식하지 못하는 사이에 수많은 곳에 복제되고 있습니다. 이렇게 흩어진 시크릿을 추적하고 관리하는 것은 거의 불가능에 가깝습니다.
AI 시대의 새로운 위협: 공급망 공격과 시크릿
AI 어시스턴트가 개발 워크플로우의 중심이 된 지금, 공급망 공격은 새로운 차원으로 진화하고 있습니다. 다음 시나리오를 살펴보죠:
Phase 0 - 문서 위조 공격자가 Python의 "requests" 라이브러리와 유사한 "reqEUst"(대문자에 주목)라는 typosquatting 변종을 만들고, 온라인 문서를 조작해 자신의 변종을 참조하도록 합니다.
Phase 1 - AI 생성 코드 개발자가 AI 어시스턴트에게 MCP 날씨 서버를 만들어달라고 요청하고 조작된 문서로 학습된 AI는 "requests" 대신 "reqEUst"를 import하는 코드를 생성합니다.
Phase 2 - 배포 악성 라이브러리가 활성화되고 패킷 스니퍼를 작동시킵니다. 겉보기엔 정상 라이브러리와 동일하게 작동합니다.
Phase 3 - 자격증명 탈취 도구들이 데이터베이스에 인증할 때, 스니퍼가 평문 자격증명을 캡처하고 외부로 유출합니다.
이 공격이 성공한 이유는 다음과 같은 여러 보안 실패가 겹쳤기 때문입니다:
- TLS 암호화 미사용
- 적절한 attribution 부재
- 장기 지속 자격증명 사용
- 과도하게 허용적인 액세스 제어
시크릿 관리의 새로운 패러다임: Shift-Left와 Zero Trust
Strategy 1: IDE에서 시작하는 시크릿 보안
전통적인 시크릿 스캔은 커밋 시점에 수행됩니다. 그러나 이는 너무 늦은 스캔입니다. 현대적 접근은 개발자가 코드를 작성하는 바로 그 순간부터 시작되어야 합니다.
시나리오 비교: 타이밍이 모든 것을 바꾼다
기존 방식
- 개발자가 하드코딩된 시크릿을 포함한 코드를 커밋
- CI/CD 파이프라인이 보안 위반을 감지하고 즉시 중단
- 팀 전체가 대기하며 일정 지연
- 개발자는 문제 해결을 위해 씨름
- 보안이 다시 한번 "병목"이 됨
현대적 방식
- 개발자가 IDE에서 코드 작성 중 잠재적 시크릿 감지
- 즉시 알림과 함께 수정 가이드 제공
- 개발자가 바로 수정하고 작업 계속
- 워크플로우 중단 없음
- 보안이 "지원자"가 됨
HashiCorp의 HCP Vault Radar는 VSCode와 같은 IDE에 직접 통합되어, 개발자가 실수로 시크릿을 코드에 포함시키려 할 때 실시간으로 경고합니다. 이는 단순한 경고를 넘어, 올바른 시크릿 관리 방법으로 즉시 안내하는 것입니다.
Pre-commit Hook의 마지막 방어선 IDE 레벨 스캔을 통과했더라도, pre-commit hook은 마지막 방어선 역할을 합니다. 코드가 리포지토리에 들어가기 전에 한 번 더 검증하여, 실수로 커밋될 수 있는 시크릿을 차단합니다.
Strategy 2: 에코시스템 전반의 지속적 모니터링
IDE와 pre-commit hook이 일차 방어선이라면, 지속적 모니터링은 이미 존재하는 시크릿을 찾아내는 역할을 합니다.
HCP Vault Radar는 다음과 같은 광범위한 데이터 소스를 스캔합니다:
- Git 리포지토리 (전체 히스토리 포함)
- Slack, Teams 등 협업 플랫폼
- Confluence, Notion 등 문서 시스템
- CI/CD 파이프라인 설정
- 컨테이너 이미지와 레지스트리
- 클라우드 스토리지
발견된 시크릿은 즉시 위험도가 평가되고, 실행 가능한 수정 가이드가 제공됩니다. 중요한 것은 단순히 "발견"에서 끝나는 것이 아니라, 발견된 시크릿을 중앙화된 Vault로 마이그레이션하는 전체 프로세스를 안내한다는 점입니다.
Strategy 3: 중앙화된 Secrets Management
시크릿 관리의 궁극적 해법은 모든 시크릿을 중앙에서 통합 관리하는 것입니다. HashiCorp Vault가 제공하는 핵심 기능들은 다음과 같습니다:
1. 동적 시크릿 생성: 장기 지속 자격증명의 종말
이번 대형 유출 사고의 근본 원인이었던 장기 지속 자격증명 문제를 해결하는 가장 효과적인 방법은 동적 시크릿입니다.
Vault는 오래 지속되는 정적 credentials를 관리하는 대신, 애플리케이션과 서비스가 하이브리드 환경에서 사용할 secrets를 just-in-time으로 생성할 수 있게 합니다. 정책 기반 생성 및 강제와 함께 데이터베이스, 클라우드 제공자, LDAP 디렉토리에서 사용할 짧은 TTL을 할당할 수 있습니다.
설령 credentials가 유출되더라도 악용 가능한 시간은 몇 달이 아니라 몇 분으로 줄어듭니다.
2. 신원 기반 액세스 제어
Vault의 통합 신원 시스템은 클라우드와 신원 제공자를 넘나들며 작동하여, 기반 인프라에 관계없이 일관된 신원 레이어를 생성합니다.
3. 포괄적인 감사 로깅
이번 사고에서 5개월간 무단 접근이 감지되지 않았던 것은 적절한 감사 추적이 없었기 때문입니다. Vault는 모든 작업을 완전한 컨텍스트와 함께 로깅합니다 - 누가, 무엇을, 언제, 어디서 접근했는지 - 컴플라이언스와 포렌식 역량을 제공합니다.
4. 자동화된 인증서 관리
앞서 설명한 공급망 공격 시나리오에서 TLS 미사용이 공격 성공의 핵심 요인이었습니다. Vault의 PKI secrets 엔진은:
- 인증서 발급과 갱신을 자동화
- SPIFFE 신원과 mutual TLS 지원
- 하이브리드 환경에서 확장
이를 통해 TLS가 항상 적절하게 구성되도록 보장하고, 패킷 스니핑을 통한 자격증명 탈취를 원천 차단합니다.
Zero Trust 원칙을 NHI 관리에 적용하기
현대 조직에서 비인간 신원(NHI)은 인간 신원보다 50배 많습니다. AI 에이전트, 마이크로서비스, 컨테이너, IoT 기기 - 이 모든 것이 시크릿을 필요로 합니다. 이번 사고 역시 본질적으로는 NHI(퇴직자의 토큰)가 적절히 관리되지 않아 발생했습니다.
Zero Trust의 5가지 핵심 원칙
1. 신원 기반 액세스 모든 시스템, 에이전트, 서비스는 검증 가능한 신원을 가져야 합니다. "서버 A의 credentials"가 아니라 "서버 A가 사용자 B를 대신해 수행하는 작업"으로 인증되어야 합니다.
2. 동적 권한 부여 권한은 정적으로 할당되는 것이 아니라, 요청 시점의 컨텍스트(시간, 위치, 요청 내용 등)를 기반으로 실시간 평가되어야 합니다.
3. 단기 수명의 Credentials 앞서 설명한 동적 시크릿 원칙. 모든 자격증명은 just-in-time으로 생성되고 짧은 TTL을 가져야 합니다.
4. 포괄적인 감사 추적 모든 액세스는 인간 승인자까지 추적 가능해야 합니다. "누가" 뿐만 아니라 "누구를 대신해서"도 기록되어야 합니다.
5. 암호화된 통신 모든 시크릿 교환은 TLS로 암호화되어야 하며, 이는 자동화되고 기본값이어야 합니다.
On-Behalf-Of (OBO) 토큰 플로우
"Confused Deputy" 문제 - 높은 권한을 가진 서비스가 다른 사용자를 대신해 행동할 때 적절한 신원 경계를 강제하지 못하는 문제 - 는 많은 프롬프트 기반 공격의 핵심입니다.
OBO 토큰 플로우는 이를 해결하는 방법입니다:
- 서비스가 자신의 높은 권한으로 행동하는 대신
- 사용자 신원이 모든 레이어에 걸쳐 안전하게 전파됨
- 각 서비스는 검증된 사용자를 대신해서만 행동
- 토큰은 사용자와 에이전트 신원 주장을 결합
결과: NHI는 인간 소유자에게 부여된 권한 밖에서 행동할 수 없습니다.
HashiCorp Vault Radar를 통한 시크릿 발견과 수정
HCP Vault Radar는 조직 전체에 흩어진 관리되지 않는 시크릿을 찾아내고 수정하는 역할을 합니다. Git 리포지토리, CI/CD 파이프라인, 협업 플랫폼 등 광범위한 데이터 소스에서 시크릿을 스캔합니다.
발견된 문제에 대해서는 실시간 경고와 함께 가이드된 수정 방법을 제공하며, 여기에는 중앙 가시성과 통제를 위해 시크릿을 Vault로 이동하는 것도 포함됩니다.
개발 단계에서의 예방을 위해서는 IDE 레벨의 피드백과 pre-commit hook을 통해 시크릿이 코드에 포함되기 전에 차단할 수 있습니다.
시크릿 관리가 곧 보안의 기초다
3,370만 명의 정보가 유출된 대형 사고는 단 하나의 메시지를 명확히 전달합니다. 시크릿 관리 실패는 조직 전체를 무너뜨릴 수 있습니다. 보안의 기초는 화려한 도구가 아니라 시크릿을 어떻게 생성하고, 저장하고, 사용하고, 폐기하는가에 있습니다.
AI가 코드를 작성하고, 에이전트가 자율적으로 작동하며, 비인간 신원이 인간보다 50배 많은 세상에서, 시크릿 관리는 더 이상 선택이 아닙니다. 이는 생존의 문제입니다.
다음 대형 사고의 주인공이 되지 않으려면, 지금 당장 행동해야 합니다. 조직의 시크릿이 어디에 있는지 파악하고, Vault로 마이그레이션하며, 개발자 워크플로우에 시크릿 스캔을 통합하라. 보안은 사후 점검이 아니라 실시간 가이드가 되어야 합니다.
원문 출처:
Zero turst for agentic systems: Managing non-human identities at scale
3 strategies that reduce security friction in developer workflows
참고 링크:
