의사결정 리포트 · 2026-05-19

EC2 10대 키 침해 의심 — 대응 최적 방법

ap-northeast-2 · 명확한 IoC 보고 · KeyPair 재사용 + 외부인 키 + SSH 22 포트 전면 개방. 6개 옵션을 5개 기준으로 가중 평가한 결과 SSM Run Command 일괄 키 주입 이 1순위.

1st

SSM Run Command 일괄 키 주입

총점 8.45 / 10 · 다운타임 0 · PEM 분실 6대도 IAM 으로 처리 가능

상황 요약

인스턴스
10대 (running 8 / stopped 2). prod = alpha + beta
키 재사용
vite-hana-langconnect 1개 → 3대. grinda-uvc-key 1개 → 2대
외부인 이름 키
ahmed (hermes-korean), suman (rfp-gen)
PEM 분실
10대 중 6대 본인 머신에 PEM 없음
SG
22번 포트 0.0.0.0/0 = 8대 중 7대
IoC
명확한 침해 증거 보유 (사용자 보고)

점수 매트릭스

10점 만점 · 가중치 적용 · 총점순 정렬

#옵션 즉시실행
30%		 audit
20%		 다운타임
20%		 보안강도
15%		 운영부담
15%		 총점
1SSM Run Command 일괄 791089 8.45
2EC2 Instance Connect 65955 6.10
3수동 SSH 키 교체 37946 5.60
4신규 인스턴스 재구축 473104 5.30
5EC2 Serial Console 43943 4.65
6Volume detach-attach 38242 3.80

옵션 상세

1️⃣ SSM Run Command 일괄 키 주입 — 8.45

장점

  • PEM 없이도 IAM 으로 10대 일괄 처리 — 분실 6대 해결
  • 다운타임 0 — in-place 키 갱신 + sshd reload
  • 실행 로그 S3/CloudWatch 자동 저장 → audit trail 보존

단점

  • SSM Agent 미설치/IAM Instance Profile 미부여 인스턴스는 부트스트랩 30~60분 필요
  • SSM Agent 통신용 outbound 443 필요 (대부분 기본 허용)
  • 이미 침입자가 SSM Agent 도 손댔으면 audit 결과 신뢰도 ↓

2️⃣ EC2 Instance Connect 임시 접속 — 6.10

장점

  • SSM Agent 없어도 가능 (Instance Connect Agent 만 있으면 됨)
  • AWS 콘솔에서 60초 임시 키 주입 → 그 세션으로 authorized_keys 교체
  • 다운타임 0

단점

  • 22 포트 열려있어야 함 (지금 SG 문제 그대로)
  • 한 번에 한 세션 — 일괄 자동화 어려움
  • audit log 가 SSM 만큼 풍부하지 않음

3️⃣ 수동 SSH 키 교체 — 5.60

장점

  • 가장 단순. 사전 셋업 불필요
  • last/grep/find 등 audit 명령 직접 실행 가능
  • 다운타임 0

단점

  • PEM 분실 6대 처리 불가 — 치명적 한계
  • 10대 각각 수동 작업 — 휴먼 에러 가능성
  • audit 결과 표준화 안 됨 (수기 기록)

4️⃣ 신규 인스턴스 재구축 — 5.30

장점

  • 침입자 backdoor 100% 제거 — 보안 최강
  • 키 + SG + IAM 전부 깨끗하게 재설계 가능
  • 구 인스턴스는 격리하여 오프라인 forensic

단점

  • prod 다운타임 + DNS 전환 위험
  • 데이터 마이그레이션 + 검증 시간 = 인스턴스당 2~8시간
  • 10대 전부 재구축은 며칠 단위 작업

5️⃣ EC2 Serial Console — 4.65

장점

  • Nitro 인스턴스(m7i/t3/t4g 전부 해당) 콘솔 접근
  • 네트워크 무관 — SG/방화벽 우회

단점

  • root 비번 또는 sysrq 미설정 시 사실상 접근 불가
  • 일괄 자동화 거의 불가능
  • 운영 부담 매우 높음 — 비상 백업 옵션 정도

6️⃣ Volume detach-attach — 3.80

장점

  • 외부 호스트에서 파일시스템 직접 검사 — 오프라인 audit 강력
  • 모든 변조 흔적 추적 가능 (timestamp 신뢰도 ↑)

단점

  • 인스턴스 stop 필수 → prod 다운타임
  • 10대 처리 시간 = 인스턴스당 10~30분
  • 실수 시 데이터 손실 위험

최종 추천 — 하이브리드 단계 실행

  1. Step 0 · 즉시 (분 단위)

    • SG 22 포트 잠그기 — 7대 SG 의 0.0.0.0/0 → 본인 사무실/VPN IP 화이트리스트로 즉시 제한 (CloudShell 또는 aws cli)
    • 외부인 키 (ahmed/suman) 이 들어간 인스턴스는 prod 라우팅에서 빼두기 (해당되면)

  2. Step 1 · 30~60분 (1순위 옵션 셋업)

    • 10대 SSM Agent 설치 상태 확인 — aws ssm describe-instance-information
    • 없는 인스턴스: IAM Instance Profile (AmazonSSMManagedInstanceCore) 부여 + Agent 설치 스크립트
    • SSM Run Command 권한이 있는 IAM user 본인 권한 확인 (Administrator 면 OK)

  3. Step 2 · 1~2시간 (감식 + 키 교체 일괄)

    • SSM Run Command 로 침해 감식 스크립트 실행 — authorized_keys 전수, last 30일, /etc/passwd diff, cron 전체, /tmp /var/tmp 의심 binary, listener 포트
    • 결과 CloudWatch Logs 로 수집 후 비정상 발견 인스턴스 격리
    • 인스턴스별 새 ed25519 키 10개 생성 (재사용 금지) → SSM Run Command 로 일괄 주입 → 새 키 검증 → 옛 키 라인 제거

  4. Step 3 · 후속 (분~시간)

    • 옛 AWS KeyPair 23개 삭제 (메타 정리)
    • 침해 감식에서 양성 신호 발견된 인스턴스는 옵션 6 (재구축) 으로 격상
    • 외부인 키 (ahmed/suman) 인스턴스는 무조건 재구축 권장 (감염 가능성 높음)
    • 장기 — SSM Session Manager 본격 도입 검토 (다음 사고 대응 비용 ↓)

주의 사항