AWS IMDSv1과 IMDSv2를 보안 관점에서 이해하기

AWS EC2를 운영하다 보면 IMDSv1, IMDSv2라는 표현을 자주 보게 됩니다.

여기서 IMDS는 Instance Metadata Service의 약자로, EC2 인스턴스 내부에서 자기 자신의 메타데이터를 조회할 수 있게 해주는 서비스입니다.

예를 들어 EC2 내부에서는 다음과 같은 정보를 조회할 수 있습니다.

인스턴스 ID
AMI ID
리전
가용 영역
네트워크 정보
IAM Role 이름
IAM Role 임시 자격 증명

이 중 보안 관점에서 가장 중요한 것은 IAM Role 임시 자격 증명입니다.

EC2에 IAM Role이 연결되어 있으면 애플리케이션은 Access Key를 코드나 환경 변수에 직접 저장하지 않아도 됩니다.

대신 IMDS를 통해 임시 자격 증명을 받아 AWS API를 호출할 수 있습니다.

이 구조 자체는 매우 좋은 보안 설계입니다.

하지만 애플리케이션에 SSRF 같은 취약점이 있으면 이야기가 달라집니다.

1. IMDS는 어디에 있는가?

EC2 인스턴스 내부에서는 다음 링크 로컬 주소로 IMDS에 접근할 수 있습니다.

http://169.254.169.254/latest/meta-data/

예를 들어 인스턴스 ID를 조회하려면 다음과 같이 실행합니다.

curl http://169.254.169.254/latest/meta-data/instance-id

IAM Role이 연결된 인스턴스라면 다음 경로에서 Role 이름을 확인할 수 있습니다.

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Role 이름을 알면 해당 Role의 임시 자격 증명도 조회할 수 있습니다.

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

여기서 반환되는 정보에는 다음 값들이 포함됩니다.

AccessKeyId
SecretAccessKey
Token
Expiration

즉, EC2 내부에서 동작하는 애플리케이션은 IMDS를 통해 AWS API 호출에 필요한 임시 자격 증명을 얻을 수 있습니다.

2. IMDSv1의 동작 방식

IMDSv1은 구조가 매우 단순합니다.
별도의 토큰 없이 HTTP GET 요청만으로 메타데이터를 조회할 수 있습니다.

예시는 다음과 같습니다.

curl http://169.254.169.254/latest/meta-data/

IAM Role 임시 자격 증명도 다음처럼 조회할 수 있습니다.

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

IMDSv1의 장점은 단순성과 호환성입니다.

오래된 AWS SDK, 오래된 에이전트, 오래된 스크립트에서도 쉽게 동작합니다.

하지만 보안 관점에서는 이 단순함이 문제가 될 수 있습니다.

3. IMDSv1의 보안 문제

IMDSv1의 가장 큰 문제는 요청에 별도 토큰이 필요 없다는 점입니다.

IMDS는 원래 EC2 내부에서만 접근 가능한 서비스입니다.

따라서 외부 사용자가 인터넷에서 직접 169.254.169.254에 접근할 수 있는 것은 아닙니다.

하지만 웹 애플리케이션에 SSRF 취약점이 있다면 공격자는 애플리케이션 서버가 대신 IMDS에 접근하도록 만들 수 있습니다.

예를 들어 어떤 웹 서비스에 URL을 입력하면 서버가 해당 URL을 대신 가져오는 기능이 있다고 가정해보겠습니다.

https://example.com/fetch?url=http://example.org/image.png

이 기능이 URL 검증 없이 동작한다면 공격자는 다음과 같이 요청할 수 있습니다.

https://example.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

이 경우 외부 공격자가 직접 IMDS에 접근하는 것은 아니지만, EC2 내부의 웹 애플리케이션이 대신 IMDS에 접근하게 됩니다.

이것이 SSRF와 IMDSv1이 결합될 때 위험해지는 대표적인 시나리오입니다.

4. SSRF와 IMDSv1이 결합되면 왜 위험한가?

SSRF를 통해 공격자가 IMDS에 접근할 수 있다면 다음 정보가 노출될 수 있습니다.

EC2에 연결된 IAM Role 이름
임시 Access Key
임시 Secret Key
Session Token
자격 증명 만료 시간

이때 EC2 Role에 과도한 권한이 부여되어 있다면 피해 범위는 커집니다.

예를 들어 다음과 같은 권한이 Role에 포함되어 있으면 매우 위험합니다.

S3 전체 접근
Secrets Manager 전체 조회
DynamoDB 전체 접근
EC2 생성/삭제 권한
IAM PassRole
관리자 권한

결국 문제는 단순히 “IMDSv1을 사용했느냐”만이 아닙니다.

실제 보안 사고 관점에서는 다음 요소가 함께 작용합니다.

애플리케이션에 SSRF 취약점이 있는가?
EC2에서 IMDSv1이 허용되어 있는가?
EC2 Role 권한이 과도한가?
네트워크 또는 애플리케이션 레벨에서 메타데이터 주소 접근을 차단하지 않았는가?

5. IMDSv2의 동작 방식

IMDSv2는 IMDSv1의 보안 약점을 줄이기 위해 나온 방식입니다.

핵심은 토큰 기반 세션입니다.

IMDSv2에서는 바로 메타데이터를 조회할 수 없습니다.
먼저 PUT 요청으로 토큰을 발급받아야 합니다.

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

그 다음 메타데이터 요청에 토큰을 헤더로 포함해야 합니다.

curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

IAM Role 자격 증명 조회도 마찬가지입니다.

ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/)

curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME

즉, IMDSv2에서는 다음 두 단계가 필요합니다.

PUT 요청으로 토큰 발급
발급받은 토큰을 헤더에 넣고 메타데이터 조회

6. IMDSv2가 보안을 강화하는 방식

IMDSv2는 다음 방식으로 공격 난이도를 높입니다.

1) 단순 GET 요청 차단

IMDSv1에서는 GET 요청만으로 메타데이터를 가져올 수 있었습니다.

curl http://169.254.169.254/latest/meta-data/

하지만 IMDSv2 Required 상태에서는 토큰 없는 요청이 실패합니다.

즉, 단순히 URL만 조작할 수 있는 SSRF 취약점이라면 IMDSv2를 우회하기 어렵습니다.

2) PUT 요청 필요

IMDSv2 토큰은 PUT 요청으로 발급받습니다.

많은 SSRF 취약점은 단순 GET 요청만 허용하거나, HTTP 메서드 변경을 허용하지 않습니다.
이 경우 공격자는 토큰을 발급받기 어렵습니다.

3) 커스텀 헤더 필요

IMDSv2에서는 메타데이터 조회 시 다음 헤더가 필요합니다.

X-aws-ec2-metadata-token: <TOKEN>

URL만 조작할 수 있는 SSRF 취약점에서는 이 헤더를 추가하기 어렵습니다.

4) Hop Limit 제어

IMDSv2에는 HttpPutResponseHopLimit 설정이 있습니다.

이 값은 IMDSv2 토큰 응답이 몇 개의 네트워크 홉을 지나갈 수 있는지 제한합니다.

일반적인 EC2 단독 환경에서는 1을 사용할 수 있습니다.
다만 컨테이너 환경에서는 네트워크 경로가 한 단계 더 생길 수 있으므로 2가 필요할 수 있습니다.

7. IMDSv1과 IMDSv2 비교

구분	IMDSv1	IMDSv2
메타데이터 조회 방식	GET 요청	PUT으로 토큰 발급 후 GET 요청
토큰 필요 여부	없음	필요
SSRF 방어력	낮음	상대적으로 높음
커스텀 헤더 필요	없음	필요
HTTP 메서드	주로 GET	PUT + GET
운영 권장 여부	레거시 호환용	운영 환경 권장
설정 값	HttpTokens=optional에서 사용 가능	HttpTokens=required로 강제 가능
주요 장점	단순함, 호환성	보안성 강화
주요 단점	SSRF에 취약해질 수 있음	구버전 SDK/Agent 호환성 확인 필요

8. EC2 메타데이터 옵션 주요 설정

EC2에는 IMDS와 관련된 메타데이터 옵션이 있습니다.

설정	설명	권장
HttpEndpoint	IMDS 사용 여부	필요 없으면 disabled
HttpTokens	IMDSv2 토큰 요구 여부	required 권장
HttpPutResponseHopLimit	IMDSv2 토큰 응답 hop limit	일반 EC2는 1, 컨테이너는 2 검토
InstanceMetadataTags	인스턴스 태그를 메타데이터로 노출할지 여부	필요 없으면 disabled

운영 환경에서는 보통 다음과 같은 방향을 권장합니다.

IMDS가 필요 없는 인스턴스: HttpEndpoint disabled
IMDS가 필요한 인스턴스: HttpTokens required
일반 EC2: Hop Limit 1 검토
ECS/EKS/컨테이너 환경: Hop Limit 2 검토
인스턴스 태그 조회가 필요 없으면 InstanceMetadataTags disabled

9. 현재 EC2의 IMDS 설정 확인

AWS CLI로 현재 인스턴스들의 메타데이터 옵션을 확인할 수 있습니다.

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{
    InstanceId:InstanceId,
    State:State.Name,
    HttpEndpoint:MetadataOptions.HttpEndpoint,
    HttpTokens:MetadataOptions.HttpTokens,
    HopLimit:MetadataOptions.HttpPutResponseHopLimit,
    MetadataTags:MetadataOptions.InstanceMetadataTags
  }' \
  --output table

결과에서 HttpTokens 값을 보면 됩니다.

optional: IMDSv1과 IMDSv2 모두 허용
required: IMDSv2만 허용

즉, HttpTokens=optional이면 보안 관점에서 전환 검토 대상입니다.

10. 기존 EC2를 IMDSv2 Required로 변경

기존 EC2 인스턴스를 IMDSv2 Required로 변경하려면 다음 명령을 사용할 수 있습니다.

aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --http-tokens required \
  --http-endpoint enabled

변경 후에는 다음 명령으로 확인합니다.

aws ec2 describe-instances \
  --instance-ids i-xxxxxxxxxxxxxxxxx \
  --query 'Reservations[].Instances[].MetadataOptions' \
  --output json

컨테이너 환경에서 hop limit을 2로 설정해야 한다면 다음처럼 적용할 수 있습니다.

aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --http-tokens required \
  --http-put-response-hop-limit 2 \
  --http-endpoint enabled

11. 신규 EC2에 IMDSv2를 기본 적용하기

운영 환경에서는 인스턴스를 만든 뒤 수정하는 것보다 처음부터 IMDSv2를 요구하도록 만드는 것이 좋습니다.

Launch Template에서 다음 설정을 지정할 수 있습니다.

{
  "MetadataOptions": {
    "HttpTokens": "required",
    "HttpEndpoint": "enabled",
    "HttpPutResponseHopLimit": 2
  }
}

AWS CLI로 계정/리전 단위 기본값을 설정할 수도 있습니다.

aws ec2 modify-instance-metadata-defaults \
  --http-tokens required \
  --http-put-response-hop-limit 2 \
  --http-endpoint enabled \
  --region ap-northeast-2

다만 기존 애플리케이션, 에이전트, SDK가 IMDSv2를 지원하지 않는 경우 장애가 발생할 수 있습니다.
따라서 운영 환경에서는 바로 강제 적용하기보다 먼저 IMDSv1 사용 여부를 확인해야 합니다.

12. IMDSv1 사용 여부 점검

IMDSv2 전환 전에는 아직 IMDSv1을 사용하는 프로세스가 있는지 확인해야 합니다.

대표적인 확인 방법은 다음과 같습니다.

CloudWatch MetadataNoToken 지표 확인

MetadataNoToken 지표는 토큰 없이 IMDS에 접근한 요청을 확인하는 데 사용됩니다.

쉽게 말해 IMDSv1 방식의 요청이 발생했는지 확인할 수 있는 지표입니다.

이 지표가 계속 증가한다면 아직 IMDSv1을 사용하는 애플리케이션이나 에이전트가 있다는 의미입니다.

IMDS Packet Analyzer 사용

AWS에서 제공하는 IMDS Packet Analyzer를 사용하면 인스턴스 내부에서 어떤 프로세스가 IMDSv1을 호출하는지 확인할 수 있습니다.

전환 전에는 다음 항목을 점검하는 것이 좋습니다.

오래된 AWS CLI
오래된 AWS SDK
구버전 SSM Agent
구버전 CloudWatch Agent
직접 작성한 curl 스크립트
오래된 애플리케이션 라이브러리

13. 보안 관점의 권장 전환 절차

운영 환경에서는 다음 순서로 전환하는 것이 안전합니다.

EC2 전체 목록에서 HttpTokens=optional 인스턴스 식별
CloudWatch MetadataNoToken 지표 확인
IMDS Packet Analyzer로 IMDSv1 호출 프로세스 확인
AWS CLI, SDK, SSM Agent, CloudWatch Agent 업데이트
개발 환경에서 IMDSv2 Required 테스트
스테이징 환경 적용
운영 인스턴스에 순차 적용
Launch Template, Auto Scaling Group, AMI 빌드 파이프라인에 IMDSv2 Required 반영
신규 인스턴스 기본값을 IMDSv2 Required로 설정
조직 단위 강제가 필요하면 SCP 또는 계정 기본값 검토

14. IMDSv2만으로 충분한가?

IMDSv2는 매우 중요한 방어 장치입니다.
하지만 IMDSv2만 적용했다고 모든 위험이 사라지는 것은 아닙니다.

보안 관점에서는 다음 대책을 함께 적용해야 합니다.

IAM Role 최소 권한

IMDS를 통해 탈취될 수 있는 가장 중요한 정보는 IAM Role 임시 자격 증명입니다.
따라서 EC2 Role에는 최소 권한만 부여해야 합니다.

나쁜 예시는 다음과 같습니다.

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

좋은 예시는 필요한 서비스와 리소스만 제한하는 방식입니다.

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": [
    "arn:aws:s3:::example-bucket/app/*"
  ]
}

SSRF 방어

웹 애플리케이션에서 외부 URL을 받아 서버가 직접 요청하는 기능은 주의해야 합니다.

다음 주소들은 기본적으로 차단 대상입니다.

169.254.169.254
fd00:ec2::254
127.0.0.1
localhost
RFC1918 사설 IP 대역
링크 로컬 주소
내부 DNS 이름
클라우드 메타데이터 엔드포인트

또한 리다이렉션이 발생하는 경우 최종 목적지도 다시 검증해야 합니다.
DNS Rebinding 공격도 고려해야 합니다.

컨테이너 환경 권한 분리

ECS나 EKS 환경에서는 컨테이너가 EC2 노드의 Instance Profile 권한을 사용할 수 있는지 확인해야 합니다.

가능하면 다음 구조를 사용하는 것이 좋습니다.

ECS: Task Role 사용
EKS: IRSA 또는 EKS Pod Identity 사용
노드 Role 권한 최소화
Pod 또는 컨테이너에서 IMDS 접근 필요성 검토

컨테이너가 노드의 IMDS에 접근할 수 있고 노드 Role 권한이 과도하다면, 컨테이너 탈취 시 AWS 계정 권한으로 확장될 수 있습니다.

15. CIS 벤치마크 관점에서 보는 IMDSv2

CIS AWS Foundations Benchmark나 클라우드 보안 점검 기준에서는 EC2 메타데이터 서비스 설정을 중요한 보안 항목으로 봅니다.

특히 다음과 같은 관점에서 점검할 수 있습니다.

IMDSv1이 허용되어 있는가?
IMDSv2 Required가 적용되어 있는가?
EC2 Role에 과도한 권한이 부여되어 있는가?
인스턴스 메타데이터 태그 노출이 필요한가?
컨테이너 워크로드에서 노드 Role 권한이 노출될 가능성이 있는가?

자동 진단 스크립트에서는 보통 describe-instances 결과의 MetadataOptions 값을 확인합니다.

예를 들어 다음 기준으로 진단할 수 있습니다.

HttpTokens == required 이면 양호
HttpTokens == optional 이면 취약 또는 개선 필요

단, 운영 환경에서는 단순히 명령으로 바꾸는 것보다 애플리케이션 호환성 확인이 먼저입니다.

16. 실무 결론

IMDSv1은 오래된 방식이고 단순 GET 요청만으로 메타데이터를 조회할 수 있습니다.
이 때문에 SSRF 취약점과 결합되면 EC2 IAM Role 임시 자격 증명이 노출될 수 있습니다.

IMDSv2는 토큰 기반 세션을 사용합니다.

먼저 PUT 요청으로 토큰을 발급받고, 이후 요청에 토큰 헤더를 포함해야 합니다.
이 구조 덕분에 단순 SSRF 공격으로 메타데이터를 탈취하기 어려워집니다.

운영 환경에서는 다음 기준을 권장합니다.

가능하면 IMDSv2 Required 적용
IMDS가 필요 없는 인스턴스는 IMDS 비활성화
EC2 IAM Role은 최소 권한으로 설계
SSRF 방어 로직 적용
컨테이너 환경에서는 Task Role, IRSA, EKS Pod Identity 사용
전환 전 MetadataNoToken 지표와 에이전트 호환성 확인

한 줄로 정리하면 다음과 같습니다.

IMDSv1은 호환성 중심의 레거시 방식이고,
IMDSv2는 SSRF와 메타데이터 탈취 위험을 줄이기 위한 보안 강화 방식입니다.
운영 환경에서는 특별한 이유가 없다면 IMDSv2 Required를 기본값으로 두는 것이 안전합니다.

참고 링크

AWS EC2 User Guide - Instance Metadata Service
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

AWS EC2 User Guide - Configure instance metadata options
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html

AWS Security Blog - Add defense in depth against SSRF vulnerabilities
https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

AWS Security Blog - Get the full benefits of IMDSv2 and disable IMDSv1
https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/

저작자표시 비영리 변경금지 (새창열림)

'일반IT > IT보안' 카테고리의 다른 글

브라우저에 내장된 인증기관 목록은 무엇일까 — Root Store와 HTTPS 신뢰 구조 이해하기 (0)	2026.07.23
보안 업무에서 활용 가능한 생성형 AI 사례 — SOC 분석부터 클라우드 보안까지 (0)	2026.07.23
🔬 Kali에서 radare2로 악성코드 PE를 해부하다 — 어셈블리 추출 완전 정복 (0)	2026.06.02
🐍 코드로 사냥하라 — yara-python으로 만드는 자동화된 시그니처 탐지기 (0)	2026.05.23
🎯 악성코드를 사냥하는 사냥꾼의 언어, YARA 룰 직접 만들어보기 (0)	2026.05.23

CLOUD SECURITY LAB with AI

AWS IMDSv1과 IMDSv2를 보안 관점에서 이해하기

1. IMDS는 어디에 있는가?

2. IMDSv1의 동작 방식

3. IMDSv1의 보안 문제

4. SSRF와 IMDSv1이 결합되면 왜 위험한가?

5. IMDSv2의 동작 방식

6. IMDSv2가 보안을 강화하는 방식

1) 단순 GET 요청 차단

2) PUT 요청 필요

3) 커스텀 헤더 필요

4) Hop Limit 제어

7. IMDSv1과 IMDSv2 비교

8. EC2 메타데이터 옵션 주요 설정

9. 현재 EC2의 IMDS 설정 확인

10. 기존 EC2를 IMDSv2 Required로 변경

11. 신규 EC2에 IMDSv2를 기본 적용하기

12. IMDSv1 사용 여부 점검

CloudWatch MetadataNoToken 지표 확인

IMDS Packet Analyzer 사용

13. 보안 관점의 권장 전환 절차

14. IMDSv2만으로 충분한가?

IAM Role 최소 권한

SSRF 방어

컨테이너 환경 권한 분리

15. CIS 벤치마크 관점에서 보는 IMDSv2

16. 실무 결론

참고 링크

'일반IT > IT보안' 카테고리의 다른 글

티스토리툴바

AWS IMDSv1과 IMDSv2를 보안 관점에서 이해하기

1. IMDS는 어디에 있는가?

2. IMDSv1의 동작 방식

3. IMDSv1의 보안 문제

4. SSRF와 IMDSv1이 결합되면 왜 위험한가?

5. IMDSv2의 동작 방식

6. IMDSv2가 보안을 강화하는 방식

1) 단순 GET 요청 차단

2) PUT 요청 필요

3) 커스텀 헤더 필요

4) Hop Limit 제어

7. IMDSv1과 IMDSv2 비교

8. EC2 메타데이터 옵션 주요 설정

9. 현재 EC2의 IMDS 설정 확인

10. 기존 EC2를 IMDSv2 Required로 변경

11. 신규 EC2에 IMDSv2를 기본 적용하기

12. IMDSv1 사용 여부 점검

CloudWatch MetadataNoToken 지표 확인

IMDS Packet Analyzer 사용

13. 보안 관점의 권장 전환 절차

14. IMDSv2만으로 충분한가?

IAM Role 최소 권한

SSRF 방어

컨테이너 환경 권한 분리

15. CIS 벤치마크 관점에서 보는 IMDSv2

16. 실무 결론

참고 링크

'일반IT > IT보안' 카테고리의 다른 글

관련글

티스토리툴바