[AWS 하드닝 04] SSH를 열기 전에: EC2 관리 경로와 IMDSv2

About this offer

인스턴스에 접속하려고 인터넷 전체에 SSH를 열어 놓으면 관리가 끝난 뒤에도 진입점이 남을 수 있습니다. 한편 웹 애플리케이션이 임의 URL을 요청하는 취약점은 관리 포트와 다른 경로로 인스턴스 정보를 노립니다. EC2 하드닝에서는 관리자의 접속 경로와 애플리케이션의 메타데이터 접근 을 따로 점검하겠습니다. 기존 AWS 시리즈 에서 서비스별 역할을 정리한 데 이어, 이번에는 정상 업무를 유지하면서 접근 범위를 줄이는 방법을 살펴봅니다. EC2, 보안 그룹, IAM 역할을 알고 있다는 전제입니다. 이번 예제는 일반 EC2 VM을 대상으로 하며 컨테이너의 모든 네트워크 형태를 포괄하지 않습니다. IMDS에는 무엇이 있나요? 인스턴스 메타데이터 서비스인 IMDS는 실행 중인 인스턴스가 자신의 정보를 조회하는 경로입니다. 인스턴스 역할의 임시 자격 증명도 이 경로와 관련됩니다. IMDSv2는 먼저 세션 토큰을 받은 뒤 그 토큰을 포함해 조회합니다. 인스턴스에서 토큰 사용을 required 로 설정하면 IMDSv1 방식은 사용할 수 없습니다. IMDSv2 동작 서버 측 요청 위조인 SSRF는 서버가 공격자가 유도한 주소로 요청하는 문제입니다. IMDSv2는 이 문제에 대한 방어를 보강하지만, 애플리케이션의 임의 URL 요청 취약점을 없애 주지는 않습니다. 대상 URL 제한, 리디렉션 처리, 인스턴스 역할의 최소 권한도 따로 검토합니다. 두 경로를 나눠 읽어 주세요. Session Manager를 사용했다고 IMDSv2가 자동 필수로 바뀌는 것은 아닙니다. IMDSv2를 필수로 해도 SSH 포트가 저절로 닫히지 않습니다. 메타데이터 옵션의 작은 예제 아래는 CloudFormation LaunchTemplate의 LaunchTemplateData 안에 넣는 속성 조각 입니다. 전체 인스턴스를 만드는 템플릿이 아닙니다. { "MetadataOptions": { "HttpEndpoint": "enabled", "HttpTokens": "required", "HttpPutResponseHopLimit": 1, "InstanceMetadataTags": "disabled" } } HttpTokens: required 가 IMDSv2 필수 설정입니다. 홉 제한은 응답이 이동할 수 있는 네트워크 홉에 관한 설정입니다. 일반 VM 예제에서는 1로 두었지만, 컨테이너 환경에서 이 값을 무조건 적용하면 필요한 메타데이터 요청이 실패할 수 있습니다. 실제 네트워크 구조와 사용 중인 SDK를 확인해야 합니다. MetadataOptions 필드 메타데이터 자체가 전혀 필요 없다면 엔드포인트 비활성화도 검토할 수 있습니다. 하지만 역할 자격 증명을 가져오는 SDK나 운영 도구의 의존성을 확인하지 않고 끄면 정상 작업을 막을 수 있습니다. 태그 공개 옵션 역시 태그 안에 비밀을 넣지 않는 원칙을 대신하지 않습니다. 관리 접속을 바꾸는 순서 Session Manager는 인바운드 관리 포트를 열지 않는 관리 경로를 제공합니다. 사용하려면 SSM Agent, 인스턴스와 운영자 IAM 권한, Systems Manager 서비스까지의 통신 경로를 준비해야 합니다. 인터넷 출구를 제거한 프라이빗 환경이라면 필요한 서비스 엔드포인트와 DNS도 확인합니다. Session Manager 개요 SSH를 먼저 닫고 새 경로를 준비하면 장애 때 접근할 수 없습니다. 테스트 인스턴스에서 접속, 권한 거부, 접속 종료, 감사 기록을 먼저 확인한 뒤 기존 인바운드 규칙을 줄입니다. 관리자의 세션 시작 권한도 모든 인스턴스가 아닌 업무 대상에 맞춥니다. 세션 내용을 항상 녹화한다고 생각하는 것도 위험합니다. SSH 방식이나 포트 포워딩 세션 등은 Session Manager의 세션 콘텐츠 로깅에 제한이 있습니다. 시작·종료 이력과 명령 내용 기록을 구분해 필요한 감사 범위를 설계해야 합니다. 이 글에서는 실제 세션 로깅을 시험하지 않았습니다. 세션 로그의 제한 변경 뒤 확인할 항목 SDK와 운영 도구가 IMDSv2를 지원하는지 확인합니다. 새 인스턴스뿐 아니라 현재 인스턴스의 메타데이터 옵션도 확인합니다. LaunchTemplate 수정이 기존 VM을 자동 변경했다고 가정하지 않습니다. 테스트 대상에서 토큰 없는 요청이 거부되고 정상 애플리케이션이 계속 동작하는지 확인합니다. 자격 증명 응답을 로그에 남기지 않습니다. 새 관리 경로가 동작한 뒤에 넓은 SSH 인바운드를 제거합니다. 되돌릴 경우에는 영향을 받은 옵션이나 관리 규칙만 검토된 이전 상태로 복구합니다. 전체 인터넷에 관리 포트를 여는 자동 원복을 피하고, 사전에 승인된 복구 경로를 사용합니다. IMDSv1 의존 도구가 발견됐다면 임시 예외의 대상과 종료 시점을 기록합니다. 로컬 검증: JSON 구문, IMDSv2 필수, VM 예제 홉 제한을 검사했습니다. HttpTokens 를 optional 로 바꾼 반례는 학습용 기준에서 탈락했습니다. 실제 EC2 요청, SSRF 방어 효과, Session Manager 접속과 감사 로그는 시험하지 않았습니다. 확인 문제 IMDSv2를 켜면 SSH가 자동으로 닫힐까요? 홉 제한 1을 모든 컨테이너 환경에 적용해도 될까요? 관리 포트를 없애기 전에 무엇을 확인해야 할까요? 답과 해설 아닙니다. 메타데이터와 관리 접속은 별개입니다. 아닙니다. 네트워크 홉과 SDK 의존성을 확인해야 합니다. Agent, IAM, 서비스 통신, 실제 새 관리 접속과 승인된 복구 경로입니다. 복습 오늘은 두 접근 경로를 나눠 그려 보세요. 내일은 기존 VM과 새 VM 중 어디에 설정이 적용됐는지 확인하는 질문을 써 보세요. 일주일 뒤에는 애플리케이션 역할을 줄이는 것이 SSRF의 피해에 어떤 영향을 주는지 설명해 보세요. 확인일: 2026-10-04, 한국 시간 . EC2 IMDSv2, CloudFormation LaunchTemplate, Systems Manager Session Manager 기준입니다.