Q21. 퇴사한 개발자가 서명키를 반출해 공격자로 변한다면 어떻게 대응할까요?

By PLURA 2026-02-11

A. 전제를 바꿔야 합니다.
“반출되지 않았을 것”이 아니라,
“이미 반출되었을 수 있다”에서 출발해야 합니다.

Q20에서 논의했듯이,
서명키 사고의 본질은 단순한 하드코딩 문제가 아니라
교체를 전제로 하지 않은 설계와 운영이었습니다.

이 문제는
개발자 퇴사 시점에서 더 분명해집니다.

먼저 보는 핵심 요약

이 글의 결론은 네 가지입니다.

키 관리 개발자의 퇴사는 인사 이벤트가 아니라 보안 이벤트로 봐야 합니다.
1차 대응은 즉시 키 교체(Key Rotation)입니다.
하지만 키 교체만으로는 부족하며, 교체 전후 공백을 막기 위한 2차 방어선이 필요합니다.
그 2차 방어선은 IP 숫자가 아니라 행위 패턴을 보는 Brute Force 탐지·차단입니다.

1. 퇴사한 개발자는 ‘의도와 무관하게’ 리스크가 됩니다

키 관리를 담당했던 개발자가 퇴사하면
다음 가능성을 완전히 배제할 수는 없습니다.

로컬 노트북에 키가 남아 있을 수 있고
개인 클라우드나 백업 스토리지에 복사본이 있을 수 있으며
협업 도구, 메모장, 스크립트, 환경 변수 파일에 흔적이 남아 있을 수 있습니다
실수든 고의든 외부로 유출되었을 가능성도 존재합니다

중요한 점은 이것입니다.

의도가 악의적이었는지는 부차적입니다.
키가 이미 통제 밖으로 나갔을 가능성 자체가 리스크입니다.

그래서 개발자 퇴사는
단순 인사 이동이 아니라
보안 이벤트로 취급되어야 합니다. :contentReference[oaicite:1]{index=1}

2. 1차 대응은 분명합니다: 키를 즉시 교체해야 합니다

이 원칙은 단순합니다.

키 관리 개발자 퇴사
⇒ 해당 서명키는 더 이상 신뢰 불가
⇒ 즉시 교체 대상

키를 교체하지 않는 순간
공격자는 정상 사용자와 거의 다르지 않게 보일 수 있습니다.

인증은 정상적으로 통과하고
요청 형식도 합법적으로 보이며
공격은 “정상 API 호출”처럼 진행됩니다

이 단계에서는
전통적인 WAF나 단순 네트워크 장비만으로는
구분이 어렵습니다.

즉,

퇴사자 관련 키는 “문제가 생기면 바꾸는 것”이 아니라
퇴사 시점에 신뢰를 상실한 것으로 보고 즉시 교체해야 합니다.

3. 그러나 키 교체만으로는 충분하지 않습니다

실무에서는 다음 문제가 항상 남습니다.

교체 전 공백 시간
교체 지연 가능성
이미 키를 확보한 공격자의 자동화 공격
일부 시스템에 남아 있는 구버전 키
운영자의 적용 누락

즉,

“이미 키를 가진 공격자”를 전제로 한 2차 방어선이 필요합니다.

그 2차 방어가 바로
행위 기반 Brute Force 탐지·차단입니다. :contentReference[oaicite:2]{index=2}

4. 2,000개 IP는 탐지 불가능한 수준이 아닙니다

발표에 따르면,
퇴사자가 사용한 IP 주소는 약 2,000여 개,
전체 접속 시도는 3,367만여 건이었습니다. :contentReference[oaicite:3]{index=3}

일부에서는 이렇게 생각할 수 있습니다.

“IP가 2,000개나 되니 탐지가 어려웠던 것 아닐까?”

하지만 원문이 짚듯,
이미 2018년 우리은행 사례에서도
3개의 IP로 56만 건의 접속 시도가 확인된 바 있습니다. :contentReference[oaicite:4]{index=4}

이를 단순 계산하면:

3개 IP 사례: 약 18.6만 건 / IP
2,000개 IP 사례: 약 1.68만 건 / IP

즉,

IP 1개당 약 1.68만 건 수준의 반복 요청은
행위 기반 Brute Force 탐지에서 충분히 이상 징후로 볼 수 있는 수준입니다.

실제 운영 환경에서는
수백~수천 건 단위의 반복 시도만으로도
차단 정책이 작동하는 경우가 흔합니다.

즉,
IP를 많이 분산했다고 해서
탐지 자체가 불가능해지는 것은 아닙니다.

문제의 핵심은 IP 숫자가 아니라:

반복성
시간 밀도
자동화 패턴
정상 트래픽 대비 편차

입니다. :contentReference[oaicite:5]{index=5}

5. IP 기반 탐지와 행위 기반 탐지는 무엇이 다를까요?

구분	IP 기반 탐지	행위 기반 탐지
핵심 기준	특정 IP가 악성인지	요청 패턴 자체가 자동화 공격인지
장점	단순하고 즉각적	분산 공격에도 강함
약점	IP가 분산되면 우회 쉬움	더 정교한 분석 필요
잘 잡는 것	고정 공격원, 반복 단일 IP 공격	분산 IP 공격, 크리덴셜 스터핑, 자동화 패턴
핵심 질문	“이 IP를 막을까?”	“이 행동이 정상 사용자 행동인가?”

중요한 차이는 이것입니다.

IP 기반 탐지는 공격자를 주소로 보지만,
행위 기반 탐지는 공격을 패턴으로 봅니다.

즉, IP가 달라도
행위 패턴이 같다면
충분히 탐지 가능합니다.

6. Brute Force 탐지는 결국 ‘행동’을 보는 문제입니다

Brute Force 탐지를
단순 IP 블랙리스트 문제로 이해하면 한계가 분명합니다.

실제로 중요한 것은 다음입니다.

단위 시간 대비 요청 증가율
동일 리소스 반복 호출
정상 사용자 대비 편차
자동화 도구 특유의 지속성
짧은 시간 안에 다량 계정 시도
응답 성공/실패 패턴의 비정상 조합

예를 들어 다음과 같은 패턴은
행위 기반 탐지의 전형적인 기준이 됩니다.

예시로 볼 수 있는 탐지 기준

같은 IP 또는 IP군에서 짧은 시간 안에 다수 계정 시도
동일 계정에 대한 반복 인증 시도
정상 사용자 대비 비정상적으로 높은 요청 밀도
성공/실패 여부와 무관하게 지속되는 자동화 요청 패턴
특정 API에만 집중된 과도한 호출

즉,

공격자는 IP를 바꿀 수 있어도,
자동화된 행동 패턴까지 완전히 숨기기는 어렵습니다.

원문에서도 이 점을 강조하며
PLURA-XDR은 Brute Force 탐지 시스템을 통해
이런 행위 패턴 자체를 기준으로 차단한다고 설명합니다. :contentReference[oaicite:6]{index=6}

7. 그렇다면 왜 2025년에도 막지 못했을까요?

이미 2018년 사례를 통해
Brute Force 공격은 충분히 알려진 유형이었습니다. :contentReference[oaicite:7]{index=7}

그럼에도 2025년에 같은 유형이 반복되었다면,
문제는 공격이 너무 새로워서가 아니라
대응 체계가 실제로 작동하지 않았기 때문일 가능성이 큽니다.

많은 조직에서는 다음과 같은 상황이 벌어집니다.

Brute Force 탐지 기능은 존재하지만
임계값은 조정되지 않았고
자동 차단은 비활성화되어 있으며
로그는 남지만 대응은 일어나지 않습니다

즉,

기술은 있었지만, 운영하지 않았던 것입니다.

보안은 제품 보유 여부가 아니라
실제로 다음이 작동하는가로 판단해야 합니다.

설정이 켜져 있는가
임계값이 현실에 맞게 조정돼 있는가
차단이 실제로 일어나는가
운영자가 반복적으로 검증하고 있는가

8. PLURA-XDR은 이 문제를 어떻게 다르게 보나요?

PLURA-XDR의 핵심은
“IP가 몇 개인가?”보다
공격 패턴이 자동화된 행위인가를 보는 데 있습니다.

원문 기준으로 핵심 관점은 다음과 같습니다. :contentReference[oaicite:8]{index=8}

1) IP 수보다 반복성과 밀도를 본다

단위 시간당 요청 증가율
동일 리소스 반복 호출
정상 사용자 대비 편차
자동화 패턴의 지속성

2) 키 유출 전제를 놓고 본다

“유출되지 않았을 것”이 아니라
“이미 유출되었을 수 있다”를 전제로
키 교체와 2차 탐지를 함께 설계합니다

3) 기술 보유보다 실제 차단을 중시한다

탐지 기능이 있다는 사실보다
실제로 임계값이 켜져 있는지
자동 차단이 작동하는지
운영되고 있는지가 더 중요합니다

즉,

PLURA-XDR의 핵심은
공격자를 IP로 구분하는 것이 아니라
공격 행위를 패턴으로 구분하고 실제로 차단하는 것입니다.

9. 퇴사자 키 유출 대응 체크리스트 ✅

실무에서는 최소한 아래 항목을 점검해야 합니다.

항목	핵심 질문	체크
키 교체	퇴사 시 즉시 키 로테이션 절차가 작동하는가?	□
적용 범위 확인	구버전 키가 일부 시스템에 남아 있지 않은가?	□
저장 위치 점검	로컬, 백업, 클라우드, 스크립트, 환경변수 등에 잔존 키가 없는가?	□
Brute Force 탐지	반복 요청 수, 시간 밀도, 자동화 패턴을 탐지하는가?	□
자동 차단 정책	탐지만 하고 끝나지 않고 실제 차단이 작동하는가?	□
운영 검증	임계값과 정책을 정기적으로 점검·조정하는가?	□

✍️ 정리하면

퇴사한 개발자가 공격자가 되는 상황에서
필요한 것은 단일 해법이 아닙니다.

키 즉시 교체
행위 기반 Brute Force 탐지
자동 차단 정책 유지
“키는 이미 유출되었을 수 있다”는 전제

그리고 가장 중요한 것은 이것입니다.

공격은 새롭지 않았습니다.
대응이 실제로 작동하지 않았을 뿐입니다.

보안은
기술 보유 여부가 아니라,

설정이 켜져 있는가,
차단이 실제로 일어나는가,
운영되고 있는가

로 판단해야 합니다.

📺 함께 읽기

쿠팡 등 API 인증 키(JWT) 유출 사고
👉 https://blog.plura.io/ko/threats/case-coupang_authkey/

📚 PLURA 매뉴얼

PLURA Brute Force 대응 방법
👉 https://docs.plura.io/ko/v6/fn/comm/sdetection/bruteforce