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

By PLURA

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

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

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


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

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

  • 로컬 노트북에 키가 남아 있을 수 있고
  • 개인 클라우드·백업 스토리지에 존재할 수 있으며
  • 실수든, 고의든 외부로 유출되었을 가능성도 있습니다

중요한 점은 이것입니다.

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

따라서 개발자 퇴사는
단순 인사 이벤트가 아니라
보안 이벤트로 취급되어야 합니다.


2️⃣ 1차 대응은 명확합니다: 키를 즉시 교체해야 합니다

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

키를 교체하지 않는 순간,

  • 공격자는 정상 사용자처럼 보이고
  • 인증은 정상적으로 통과되며
  • 공격은 “합법적인 요청” 형태로 진행됩니다

이 단계에서는
종래의 WAF나 단순 네트워크 장비로는 구분이 어렵습니다.


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

현실에서는 이런 문제가 남습니다.

  • 교체 전 공백 시간
  • 교체 지연 가능성
  • 이미 키를 확보한 공격자의 자동화 공격

즉,

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

그 2차 방어가 바로
행위 기반 Brute Force 탐지·차단입니다.


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

발표에 따르면,
퇴사자가 사용한 IP 주소는 약 2,000여 개,
전체 접속 시도는 3,367만여 건입니다.

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

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

그러나 이미 2018년 우리은행 공격 사례에서도
단 3개의 IP로 56만 건의 접속 시도가 확인되었습니다.


📌 흥미로운 점

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

👉 IP 1개당 1.68만건은 탐지못할 수준이 아닙니다.

1개 IP당 약 1.68만 건 수준의 반복 요청
행위 기반 Brute Force 탐지 시스템에서
충분히 이상 징후로 인식 가능한 범위입니다.

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

우리는 실제로 이와 유사한 공격을
IP 기준 100~1,000개 내외 범위에서
지속적으로 탐지·차단하고 있습니다.

즉,

IP를 2,000개로 분산했다고 해서
탐지 자체가 불가능해지는 것은 아닙니다.

공격의 본질은 IP 숫자가 아니라,

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

입니다.


5️⃣ 분산 IP 공격은 오히려 ‘행위 기반 탐지’의 영역입니다

Brute Force 탐지는
IP 블랙리스트가 아닙니다.

중요한 것은 다음입니다.

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

PLURA-XDR는
Brute Force 탐지 시스템을 통해
이러한 행위 패턴 자체를 기준으로 차단합니다.

IP는 달라도
행위 패턴은 동일하다면,

충분히 탐지 가능한 공격입니다.


6️⃣ 그렇다면 왜 2025년에도 막지 못했을까요?

이미 2018년 사례로
Brute Force 공격은 충분히 알려진 유형이었습니다.

그럼에도 불구하고
2025년에 동일한 유형이 반복되었다면,

문제는 공격의 진화가 아니라
대응 체계의 정체에 있습니다.

많은 조직에서:

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

즉,

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


7️⃣ 정리하면

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

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

그리고 가장 중요한 것:

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

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

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

로 판단해야 합니다.


📚 PLURA 매뉴얼

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