IMDSv1 비활성화 점검, 계정 기본값만 바꾸면 안 되는 이유

📌 3줄 요약

1. PISM-064는 AWS EC2 인스턴스가 인증 없는 메타데이터 방식인 IMDSv1을 허용(optional)하고 있는지 보는 위험도 5.0 항목입니다.

2. 계정 기본값을 IMDSv2로 바꿔도 기존 인스턴스는 그대로이고, 설정은 리전마다 따로라서 리전 하나만 보면 놓치는 인스턴스가 생깁니다.

3. 전 리전에서 대상을 찾고, IMDSv1 사용 여부를 확인한 뒤 기존 인스턴스·실행 템플릿·계정 기본값을 모두 IMDSv2 필수로 맞추면 됩니다.

EC2 대시보드에서 계정 기본값을 "V2 only"로 바꾸고 점검 대응을 끝냈다고 생각하셨나요? 그런데 다음 점검 스크립트 결과에 여전히 인스턴스 ID가 줄줄이 찍혀 나온다면, 설정이 틀린 게 아니라 설정이 미치는 범위를 놓친 것입니다.

계정 보안 1편에서 login.defs가 새 계정에만 적용된다는 이야기를 했는데, 클라우드에서도 똑같은 일이 벌어집니다. 2026년 평가기준에 새로 생긴 클라우드 관리체계 항목 가운데, AWS 환경에서 가장 먼저 확인해야 할 PISM-064를 정리합니다.

---

🧭 IMDS와 PISM-064

IMDS(인스턴스 메타데이터 서비스)는 EC2 인스턴스가 자기 자신에 대한 정보를 조회하는 내부 창구입니다. 인스턴스 ID, 네트워크 정보, 사용자 데이터 같은 정보와 함께, 인스턴스에 연결된 IAM 역할의 임시 자격증명도 여기서 받아 갑니다. 애플리케이션이 액세스 키를 코드에 넣지 않고도 AWS API를 쓸 수 있는 이유입니다.

 

문제는 방식입니다. IMDSv1은 단순한 GET 요청 한 번이면 응답을 줍니다. IMDSv2는 먼저 PUT 요청으로 세션 토큰을 받고, 그 토큰을 헤더에 넣어야만 응답합니다.

PISM-064는 금융보안원 전자금융기반시설 보안 취약점 평가기준(제2026-1호)의 클라우드 관리체계 항목으로, 위험도는 최고 등급인 5.0입니다. 인스턴스의 메타데이터 옵션이 IMDSv2 필수(required)면 양호, 선택(optional)이면 취약입니다. 같은 기능을 하는 서드파티 솔루션이나 대체 기능을 적절히 적용했다면 양호로 볼 수 있다는 예외가 있습니다. 참고로 이 항목은 AWS 전용이라, 같은 평가기준에서 Azure는 해당 없음으로 되어 있습니다.

---

⚠️ IMDSv1이 위험한 이유

핵심은 SSRF(서버 측 요청 위조)입니다. 웹 애플리케이션에 "입력받은 주소로 서버가 대신 요청을 보내는" 취약점이 있으면, 공격자는 그 서버를 시켜 메타데이터 주소로 요청을 보낼 수 있습니다. IMDSv1은 인증 없이 GET 한 번에 응답하므로, 이 취약점 하나만으로 IAM 역할의 임시 자격증명이 밖으로 새어 나갈 수 있습니다. 그 자격증명으로 할 수 있는 일은 역할에 준 권한만큼입니다. 스토리지 데이터 조회부터 리소스 변경까지 이어질 수 있습니다.

 

AWS도 이 위험을 막으려고 2019년 IMDSv2를 내놓았습니다. AWS 설명에 따르면, PUT으로 세션을 시작하고 토큰을 따로 요구하는 방식만으로도 실제 SSRF 취약점 대부분을 막을 수 있습니다. 여기에 응답 홉 제한이 더해져, 잘못 열린 방화벽이나 NAT 장비를 통해 토큰이 인스턴스 밖으로 나가는 것도 막습니다.

---

💡 설정했는데 취약 나오는 5가지 이유

함정	흔한 오해	실제 동작	해결
계정 기본값	계정 기본값을 V2로 바꾸면 끝이다	새로 만드는 인스턴스에만 적용된다. 기존 인스턴스는 직접 바꿔야 한다	기존 인스턴스 옵션 수정
리전	한 번 설정하면 계정 전체에 적용된다	설정도 조회도 리전 단위다. CLI 기본 리전만 보면 다른 리전의 인스턴스를 놓친다	전 리전 반복 조회·설정
Auto Scaling	인스턴스를 고치면 끝이다	인스턴스가 교체되면 실행 템플릿의 설정으로 새로 뜬다. 템플릿이 optional이면 취약이 되살아난다	실행 템플릿도 수정
컨테이너	V2 필수만 켜면 된다	홉 제한이 1이면 컨테이너 안에서 메타데이터를 못 받아 장애가 날 수 있다	컨테이너 호스트는 홉 제한 2
AMI 설정	AMI에 V2를 걸어 두고 문제 있으면 풀면 된다	AMI의 imds-support를 v2.0으로 바꾸면 되돌릴 수 없다. 원래 스냅샷으로 AMI를 새로 만들어야 한다	IMDSv2 지원 확인 후 적용

첫 번째와 세 번째 함정이 겹치면 특히 헷갈립니다. 계정 기본값도 바꾸고 인스턴스도 고쳤는데, 며칠 뒤 Auto Scaling이 인스턴스를 교체하면서 실행 템플릿에 남아 있던 optional 설정으로 새 인스턴스를 띄우는 식입니다. 인스턴스를 만드는 모든 경로를 같이 맞춰야 하는 이유입니다.

---

🛠 조치 방법

아래 명령은 관리용 단말기의 AWS CLI에서 실행합니다. EC2 조회·메타데이터 옵션 수정 권한과 CloudWatch 조회 권한이 있는 IAM 역할이 필요합니다. 인스턴스 ID와 실행 템플릿 ID는 가상 예시입니다.

1단계. 전 리전에서 대상 찾기

# IMDSv2가 optional인 인스턴스를 리전별로 출력 (중지된 인스턴스 포함)
for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  echo "== $region"
  aws ec2 describe-instances --region "$region" \
    --filters "Name=metadata-options.http-tokens,Values=optional" \
    --query "Reservations[].Instances[].[InstanceId,State.Name]" --output text
done

평가에서 흔히 쓰는 조회 명령은 리전을 지정하지 않아 CLI 기본 리전만 봅니다. 위처럼 리전을 돌면서 조회해야 빠짐이 없습니다. 중지된 인스턴스도 다시 켜면 그대로 IMDSv1을 허용하므로 함께 조치합니다.

2단계. IMDSv1을 실제로 쓰는지 확인

⚠️ 주의 오래된 SDK나 에이전트가 IMDSv1으로만 메타데이터를 읽고 있다면, V2 필수로 바꾸는 순간 자격증명을 못 받아 서비스가 멈출 수 있습니다. 바꾸기 전에 반드시 사용 여부를 확인하세요.

# MetadataNoToken: 토큰 없이(IMDSv1으로) 들어온 호출 수. 최근 2주 합계가 0이어야 안전
aws cloudwatch get-metric-statistics --region ap-northeast-2 \
  --namespace AWS/EC2 --metric-name MetadataNoToken \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-10-06T00:00:00Z --end-time 2026-10-20T00:00:00Z \
  --period 86400 --statistics Sum

0이 아니라면 그 인스턴스에서 도는 소프트웨어(AWS SDK, CLI, 모니터링 에이전트 등)를 IMDSv2를 지원하는 버전으로 먼저 올립니다. 그다음 값이 0이 된 것을 확인하고 3단계로 갑니다.

 

한 가지 의외의 경우가 있습니다. AWS SDK는 기본적으로 IMDSv2를 먼저 시도하지만, 응답을 받지 못하면 IMDSv1으로 다시 시도합니다. 그래서 최신 SDK를 쓰는데도 MetadataNoToken이 올라간다면, 컨테이너 환경에서 홉 제한이 1이라 IMDSv2 응답이 컨테이너까지 오지 못하는 경우를 의심해 보세요.

3단계. 기존 인스턴스를 IMDSv2 필수로

# IMDSv2 필수로 변경 (재시작 불필요)
aws ec2 modify-instance-metadata-options --region ap-northeast-2 \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required --http-endpoint enabled

# 컨테이너를 돌리는 인스턴스라면 홉 제한 2를 함께 지정
aws ec2 modify-instance-metadata-options --region ap-northeast-2 \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required --http-endpoint enabled --http-put-response-hop-limit 2

# 되돌리기 (장애 시)
aws ec2 modify-instance-metadata-options --region ap-northeast-2 \
  --instance-id i-0123456789abcdef0 \
  --http-tokens optional --http-endpoint enabled

이 변경은 실행 중인 인스턴스에 바로 적용되고 재시작이 필요 없습니다. 장애가 나면 위 되돌리기 명령으로 바로 복구할 수 있습니다. 다만 4단계의 계정 강제를 먼저 켜 두면 IMDSv1을 다시 켜는 것이 막히므로, 순서를 지키세요.

4단계. 다시 만들어질 인스턴스와 계정 설정

# 실행 템플릿에 IMDSv2 필수를 넣은 새 버전 생성
aws ec2 create-launch-template-version --region ap-northeast-2 \
  --launch-template-id lt-0123456789abcdef0 --source-version '$Latest' \
  --launch-template-data '{"MetadataOptions":{"HttpEndpoint":"enabled","HttpTokens":"required","HttpPutResponseHopLimit":2}}'

# 리전의 계정 기본값을 IMDSv2로 (새 인스턴스용)
aws ec2 modify-instance-metadata-defaults --region ap-northeast-2 \
  --http-tokens required --http-put-response-hop-limit 2

# 모든 인스턴스 전환이 끝난 뒤: IMDSv1 인스턴스 실행 자체를 차단
aws ec2 modify-instance-metadata-defaults --region ap-northeast-2 \
  --http-tokens required --http-tokens-enforced enabled

# 설정 확인
aws ec2 get-instance-metadata-defaults --region ap-northeast-2

실행 템플릿을 새 버전으로 만들었다면, Auto Scaling 그룹이 그 버전(또는 최신 버전)을 쓰도록 지정해야 합니다. 계정 기본값과 강제 설정도 리전마다 따로이므로 1단계처럼 리전을 돌면서 적용합니다. AWS Organizations를 쓴다면 선언적 정책(declarative policy)으로 여러 계정과 리전에 한 번에 적용할 수 있습니다.

🔐 보안 포인트 설정을 다 맞춰 놓아도, 누군가 메타데이터 옵션을 다시 optional로 바꿀 수 있다면 소용없습니다. 메타데이터 옵션과 계정 기본값을 바꾸는 API 권한은 지정된 관리 역할에만 주도록 IAM 정책으로 제한하세요. 역할 자격증명이 새더라도 피해를 줄이려면, 인스턴스 역할 자체를 최소 권한으로 두는 것도 함께 챙겨야 합니다.

5단계. 확인

# 관리용 단말기: 1단계 반복문을 다시 실행해 모든 리전에서 출력이 비었는지 확인

# 인스턴스 안: 토큰 없는 요청이 거부되는지 (HTTP 401이면 IMDSv2 필수 상태)
curl -s -o /dev/null -w "%{http_code}\n" http://169.254.169.254/latest/meta-data/

---

🎉 정리

정리하면, PISM-064는 "IMDSv2를 켰는가"가 아니라 "IMDSv1을 쓸 수 있는 인스턴스가 어느 리전에도 남아 있지 않은가"를 봅니다. 계정 기본값은 새 인스턴스, 인스턴스 옵션은 지금 있는 인스턴스, 실행 템플릿은 다시 만들어질 인스턴스를 맡습니다. 이 셋을 모든 리전에서 맞추고, 마지막에 강제 설정으로 문을 잠그면 됩니다.

✅ 점검 체크리스트

대상	확인할 것
인스턴스	모든 리전에서 http-tokens가 optional인 인스턴스(중지 포함)가 없는가
사용 현황	전환 전에 MetadataNoToken이 0인지 확인했는가
실행 템플릿	Auto Scaling이 쓰는 템플릿 버전에 HttpTokens=required가 들어 있는가
컨테이너	컨테이너 호스트의 홉 제한이 2인가
계정 설정	모든 리전의 계정 기본값이 required이고, 전환 완료 후 강제 설정을 켰는가
권한	메타데이터 옵션 변경 권한이 지정된 관리 역할로 제한되어 있는가

💬 자주 묻는 질문

Q. 메타데이터를 아예 끄면(HttpEndpoint=disabled) 더 안전하지 않나요?
가능하지만 부작용이 큽니다. 인스턴스의 SSH 공개키와 사용자 데이터도 메타데이터로 전달되기 때문에, 시작할 때 끄면 SSH 접속이나 초기화 스크립트가 동작하지 않을 수 있습니다. 또 역할 자격증명을 쓰는 애플리케이션도 멈춥니다. 대부분은 IMDSv2 필수가 현실적인 답입니다.

Q. 요즘 새로 만든 인스턴스는 처음부터 IMDSv2 아닌가요?
Amazon Linux 2023처럼 기본이 IMDSv2인 AMI도 있고, AWS는 2024년 중반 이후 새로 나온 인스턴스 유형을 IMDSv2 전용 기본값으로 바꿨습니다. 하지만 AMI, 실행 템플릿, 계정 설정에 따라 여전히 optional로 뜰 수 있으니 "새것이니 괜찮다"고 넘기지 말고 1단계 조회로 확인하세요.

Q. EKS 같은 관리형 서비스의 노드도 대상인가요?
노드가 EC2 인스턴스라면 같은 원칙이 적용됩니다. 노드 그룹이 쓰는 실행 템플릿에서 메타데이터 옵션을 설정하고, 컨테이너가 메타데이터를 써야 한다면 홉 제한을 2로 두세요.

🔗 참고 자료

· AWS 문서: 새 인스턴스의 메타데이터 옵션 (계정 기본값·강제·AMI)
· AWS 문서: 기존 인스턴스의 메타데이터 옵션 수정
· AWS 문서: IMDSv2 전환 권장 절차와 MetadataNoToken
· AWS 보안 블로그: IMDSv2의 SSRF 방어 원리
· AWS 뉴스 블로그: IMDSv2 기본값 전환 일정

---

※ 이 글은 공개된 AWS 문서를 바탕으로 작성한 일반 가이드이며, 특정 조직과 무관합니다. 인스턴스 ID, 실행 템플릿 ID, 리전, 날짜는 가상 예시입니다. 금융보안원 평가기준 원문은 배포가 제한된 문서이므로, 원문의 판단 문구와 점검 절차는 싣지 않았습니다. SSRF는 개념 설명에 그쳤으며 공격 방법은 다루지 않았습니다. 실제 판정은 각 조직이 적용하는 최신 평가기준을 따르세요.