1. 들어가기 앞서
입사한 지 한 달이 조금 지난 시점, 연이어 쏟아지는 이슈와 백엔드 팀 안정화를 위한 작업들을 헤쳐 나가던 중 이번주에 상당한 시간을 붙잡고 있었던 사건이 AWS SES SMTP 자격 증명 유출이었다.
인증 메일이 핵심인 서비스에 서 발송이 중단되면 어떤 일이 생기는지, 그리고 AWS Trust & Safety와의 커뮤니케이션이 얼마나 긴 호흡을 요구하는지 전 과정을 통해 배웠다.
2. 대응 상세 내용
2.1. 사건 타임라인
•
2025-10-24
◦
SMTP 자격 증명이 탈취되어 AWS SES를 통해 스팸 발송 시작. 약 2시간 동안 16,000건 이상 비정상 메일이 나가며 complaint 700+, bounce 300+ 기록
◦
AWS Trust & Safety가 발송 권한을 pause. 인증 메일과 관리자 초대 흐름이 모두 중단
•
2025-10-25~26
◦
고객지원 채널에 “인증 메일이 오지 않는다”는 문의가 일부 접수. (내부 경보는 조용했다)
•
2025-10-27
◦
CX팀 제보로 장애 최초 인지
◦
AWS 케이스 대응, IAM 분석, 키 폐기 및 재발급, SMTP 계정 재생성, 서비스 재배포 순서로 처리
◦
이후 제한 해제 통보, 발송 정상화 확인
2.2. 상황 진단 과정
첫 신호는 “인증 메일이 안 온다”는 고객 문의였다. AWS 콘솔에서 특정 IAM 사용자의 SMTP 호출이 폭증한 로그를 확인하면서 퍼즐이 맞춰졌다. 편의를 위해 광범위한 권한을 갖고 있던 해당 자격증명이 탈취됐고, 공격자는 SMTP 엔드포인트를 직접 호출해 스팸을 쏟아냈다. complaint 비율이 3.31%까지 치솟자 AWS가 바로 발송을 차단했다.
유출 경로는 끝내 특정하지 못했다. 오래전에 만든 자격 증명이 여러 배포 파이프라인과 환경 변수에서 재사용되고 있었고, 어떤 경로에서든 노출 가능성이 있었다.
결국 “노출됐을 것”이라는 가정 아래 전면 회전과 최소 권한화를 진행하는 선택을 했다.
2.3. 즉시 해결
모든 작업은 IAM 콘솔과 CLI를 병행해 진행했고, 키 삭제·회전·배포 내역을 빠짐없이 기록해 두었다. 덕분에 AWS 측에 제출할 근거가 명확해졌다.
•
운영용 SES IAM 사용자에 연결된 기존 Access Key 전량 비활성화 및 삭제, 정책을 ses:SendRawEmail 수준으로 축소
•
동일 사용자에 새 Access Key 발급 후 인증 서버·관리자 API 등 관련 서비스 환경 변수 전부 교체
•
기존 SMTP 전용 IAM 사용자 삭제, 권한을 최소화한 새 SMTP 전용 사용자 생성 후 배포
•
영향 받은 서비스 재배포 및 테스트 발송으로 정상 동작 확인
•
조치 내역을 정리해 AWS Trust & Safety에 회신, 발송 제한 해제 승인 확보
•
CloudWatch 메트릭 기반으로 전송 실패율 3% 초과 시 즉시 알림이 가도록 구성
2.4. AWS와의 커뮤니케이션
AWS는 complaint 비율을 근거로 발송 중단 사실을 알리며 “취약점 원인·조치 내용·재발 방지책을 구체적으로 설명하라” 고 요청했다. 첫 회신 이후에는 “기존 SMTP 사용자가 여전히 남아 있다”는 피드백을 받으며, 삭제·재생성 내역을 증빙하라는 추가 요구가 들어왔다.
이후 추가 작업을 한 이후 최종 회신에서는 삭제한 사용자, 새로 만든 SMTP 전용 사용자, Access Key 회전 시각과 상태, CloudWatch 알람 구성 등을 팩트 기반으로 제출했다. 약 20분 뒤 발송 권한 복구 통보와 함께, 리스트 건강도 관리·키 회전·CAPTCHA/Rate Limit 적용 등 베스트 프랙티스 가이드를 제안 받았다.
AWS와의 대화에서 중요한 건 “시도했다”는 말이 아니라 “누가, 무엇을, 언제 바꿨는지”를 보여주는 데이터였다. 콘솔 캡처와 CloudTrail 이벤트 ID까지 준비해 두니 왕복 횟수가 줄었다.
3. 마무리
이번 경험으로 얻은 결론은 명확하다. SMTP 자격 증명뿐 아니라 보안과 인프라 전반이 언제든 위협받을 수 있다는 가정을 전제로 시스템을 설계해야 한다. 초기 스타트업 특성상 아직 많은 부분이 체계적으로 자리 잡지 못했지만, 이번 사건이 보여주듯 “나중에 정비하자”는 유예가 곧 취약점이 된다.
편의를 위해 넓혀 둔 권한, 미뤄 둔 모니터링, 문서화되지 않은 절차로 인해 많은 리소스가 소모되었다. 하루라도 빨리 기본기를 정상화하고, “신뢰하되 검증하라”는 원칙을 팀과 조직의 습관으로 만들어야 겠다는 생각이 들었다.
3.1. 배운 점
•
모니터링 공백의 비용
◦
실패율과 complaint 비율에 자동 경보가 없으면 고객 문의가 사실상의 알람이 된다. 이번에 3% 임계치 알림을 즉시 붙일 수 있었던 것도 CloudWatch 메트릭을 이미 수집하고 있었기 때문이다.
•
최소 권한은 습관
◦
”나중에 줄이자”는 말은 거의 실현되지 않는다. 편의를 이유로 넓혀 둔 권한은 결국 공격자의 무기가 된다.
•
디테일이 협상의 속도를 결정
◦
IAM 사용자, 키 ID, 생성·삭제 시각을 빠짐없이 기록하면 Trust & Safety와의 왕복을 줄일 수 있다.
3.2. 재발 방지 백로그 (미착수)
•
전사 IAM Access Key 회전 정책 수립
◦
모든 키를 회전하고, Jenkins, GitHub Actions, 배포 환경 변수에 남은 민감 정보를 정리해야 한다.
•
퇴사자 계정 정리
◦
과거에 사용된 IAM 자격 증명의 사용 이력을 추적해 불필요한 접근을 제거해야 한다.
•
모니터링 고도화
◦
이메일 전송 실패율 3% 초과 시 슬랙 알림을 연동하고, complaint/bounce 추세 대시보드를 구성해 상시 관측체계를 마련해야 한다.
(현재 위 항목들은 모두 백로그에 올라가 있으며 아직 작업을 시작하지 못했다.)