🛡️ EC2의 IMDSv1 vs IMDSv2: SSRF, 메트릭, 위험 및 안전한 마이그레이션

(dev.to)

AWS EC2의 IMDSv1은 SSRF 공격을 통한 IAM 자격 증명 탈취 위험이 크므로, 서비스 중단을 방지하기 위해 CloudWatch 메트릭을 확인하며 IMDSv2로 안전하게 전환하는 전략이 필수적입니다.

이 글의 핵심 포인트

1IMDSv1은 SSRF 공격을 통해 IAM 임시 자격 증명이 노출될 위험이 있음
2IMDSv2는 세션 기반 토큰을 사용하여 보안성을 대폭 강화함
3IMDSv2 전환 시 기존 애플리케이션, SDK, 스크립트의 호환성 문제가 발생할 수 있음
4전환 전 CloudWatch의 `MetadataNoToken` 메트릭을 통해 IMDSv1 사용 여부를 반드시 확인해야 함
5AWS 콘솔의 'IMDSv2 필수' 설정은 API/CLI/Terraform에서 `HttpTokens`로 표현됨

이 글에 대한 공공지능 분석

왜 중요한가?

IMDSv1의 보안 취약점은 Capital One 사례처럼 대규모 데이터 유출로 이어질 수 있는 치명적인 공격 경로가 됩니다. 따라서 클라우드 보안의 핵심인 IAM 권한 보호를 위해 IMDSv2로의 전환은 인프라 보안의 필수 과제입니다.

어떤 배경과 맥락이 있나?

클라우드 네이티브 환경에서 EC2 인스턴스는 메타데이터를 통해 IAM 역할을 수행하며, 이 과정에서 발생하는 SSRF(Server-Side Request Forgery) 공격은 인프라 전체의 권한 탈취로 확산될 수 있습니다. AWS는 이를 방지하기 위해 세션 기반 토큰을 사용하는 IMDSv2를 도입했습니다.

업계에 어떤 영향을 주나?

보안 강화를 위해 IMDSv2 도입이 권장되지만, 레거시 코드나 오래된 SDK를 사용하는 기업은 서비스 중단(Downtime) 리스크를 안게 됩니다. 따라서 인프라 운영팀은 메트릭 기반의 단계적 마이그레이션 전략을 수립해야 합니다.

한국 시장에 어떤 시사점이 있나?

클라우드 전환이 가속화된 한국 스타트업들은 초기 구축 시부터 IMDSv2를 기본값으로 설정하여 보안 부채를 최소화해야 하며, 운영 중인 서비스의 경우 CloudWatch를 통한 사전 의존성 검증이 필수적입니다.

이 글에 대한 큐레이터 의견

보안 강화는 클라우드 운영의 기본이지만, '보안'과 '가용성' 사이의 트레이드오프를 신중히 고려해야 합니다. IMDSv2로의 강제 전환은 보안 수준을 비약적으로 높이지만, 준비되지 않은 상태에서의 적용은 운영 중인 서비스의 장애를 초래하는 '보란로 인한 가용성 침해'를 야기할 수 있습니다.

특히 레거시 에이전트나 스크립트가 IMDSv1에 의존하고 있다면, 단순히 설정을 바꾸는 것만으로도 인프라 전체가 마비될 수 있습니다. 따라서 창업자와 개발자는 단순히 '최신 기술 도입'이라는 명분에 매몰되기보다, `MetadataNoToken` 메트릭을 활용해 의존성을 먼저 파악하고, 점진적으로 토큰 기반 인증을 지원하도록 코드를 현대화하는 실행 가능한 로드맵을 구축해야 합니다.

원문 보기 →