SW BBANG K

EC2 인스턴스를 시작할 때 IAM Role 연결을 빠뜨리는 건 생각보다 자주 있는 실수다. 인스턴스가 이미 프로덕션 트래픽을 받고 있는 상황에서 재시작 없이 IAM Role을 붙일 수 있는지 확인하는 것이 급선무가 된다. 다행히 AWS는 실행 중인 EC2 인스턴스에 IAM Role을 연결하거나 교체하는 기능을 지원한다. TL;DR — IAM Role을 EC2에 연결하는 핵심 요약 상황 방법 재시작 필요 여부 IAM Role이 없는 인스턴스에 최초 연결 associate-iam-instance-profile 불필요 기존 IAM Role을 다른 Role로 교체 replace-iam-instance-profile-association 불필요 연결된 IAM Role 제거 disassociate-iam-instance-profile 불필요 IAM Role이 EC2에 연결되는 구조 이해 IAM Role을 EC2에 직접 붙이는 게 아니다. 중간에 Instance Profile 이라는 컨테이너가 존재한다. IAM Role을 생성하면 AWS 콘솔에서는 자동으로 동일한 이름의 Instance Profile이 함께 생성되지만, AWS CLI나 CloudFormation으로 Role을 만들면 Instance Profile은 별도로 생성해야 한다. EC2 인스턴스에 실제로 연결되는 것은 IAM Role이 아니라 Instance Profile이다. Instance Profile은 IAM Role을 EC2 인스턴스에 전달하는 봉투라고 생각하면 된다. 봉투(Instance Profile) 없이는 Role을 인스턴스에 넣을 수 없다. 인스턴스가 Role의 임시 자격증명을 얻는 경로는 EC2 메타데이터 서비스(IMDSv2)를 통해서다. 인스턴스 내부 애플리케이션이 http://169.254.169.254/latest/meta-data/...

VPC 트래픽 제어를 처음 설계할 때 가장 흔히 겪는 혼란이 있다. Security Group과 Network ACL 둘 다 '방화벽'처럼 동작하는데, 왜 인바운드 규칙만 열었는데 어떤 건 통신이 되고 어떤 건 안 되는지 — 이 차이를 모르면 프로덕션에서 반드시 한 번은 삽질한다. TL;DR — Security Group vs Network ACL 핵심 비교 항목 Security Group Network ACL (NACL) 적용 계층 인스턴스(ENI) 레벨 서브넷 레벨 상태 저장 여부 Stateful (응답 트래픽 자동 허용) Stateless (인바운드·아웃바운드 별도 규칙 필요) 규칙 평가 방식 모든 규칙을 평가 후 허용 여부 결정 번호 순서대로 평가, 첫 매칭 규칙 적용 기본 동작 모든 인바운드 거부, 모든 아웃바운드 허용 모든 인바운드·아웃바운드 허용 (기본 NACL 기준) Allow/Deny 규칙 Allow 규칙만 지원 Allow 및 Deny 규칙 모두 지원 연결 대상 ENI에 직접 연결 (인스턴스당 복수 적용 가능) 서브넷에 연결 (서브넷당 하나의 NACL) Security Group과 Network ACL의 동작 원리 두 서비스 모두 VPC 내 트래픽을 필터링하지만, 동작하는 위치와 방식이 근본적으로 다르다. Security Group은 ENI(Elastic Network Interface)에 연결되어 인스턴스 단위로 동작하고, NACL은 ...

레포지토리가 private이니까 괜찮다고 생각했던 DB 비밀번호가 GitHub 유출 사고의 주인공이 되는 건 순식간이다. Secrets Manager를 왜 써야 하는지, 자동 로테이션이 실제로 어떻게 동작하는지 운영 관점에서 정리한다. TL;DR: 핵심 비교 항목 하드코딩 / 환경변수 AWS Secrets Manager 비밀번호 노출 경로 코드, 로그, CI/CD 환경변수 API 호출 시점에만 메모리 접근 로테이션 수동 (배포 필요) 자동 (Lambda 기반, 무중단) 감사 추적 없음 CloudTrail로 모든 접근 기록 접근 제어 코드 접근 권한 = 비밀번호 접근 IAM 정책으로 세분화 비용 0원 (보안 사고 비용 제외) 시크릿당 월 과금 — AWS 공식 문서 확인 왜 Secrets Manager가 필요한가 — 하드코딩의 실제 위협 모델 'private 레포니까 괜찮다'는 가정이 깨지는 시나리오는 생각보다 많다. 팀원 계정 탈취, 실수로 public 전환, CI/CD 파이프라인 로그 노출, 컨테이너 이미지 레이어 분석 — 이 중 하나라도 발생하면 비밀번호가 코드에 있는 순간 게임 오버다. 환경변수도 완전한 해결책이 아니다. docker inspect , /proc/<pid>/environ , 애플리케이션 에러 로그에 환경변수가 그대로 출력되는 사례는 실제 운영 환경에서 반복적으로 발생한다. 비밀번호를 '어디에 두느냐'가 아니라 '누가, 언제, 어떤 경로로 접근하느냐'를 제어하는 것이 핵심이다. 하드코딩은 자물쇠 없는 금고다. 금고가 지하실에 있다고 안전한 게 아니다 — 지하실 문이 열리는 순간 모든 게 노출된다. Secrets Manager 동작 원리 Secrets Manager는 단순한 키-값 저장소가 아니다. 시크릿 값 자체...

서버 내부에서 실행 중인 스크립트가 자신이 어느 인스턴스인지 알아야 할 때가 있다. 로그에 인스턴스 ID를 찍거나, 태그를 조회하거나, Auto Scaling 그룹에서 자기 자신을 식별해야 할 때 — 이 시나리오에서 EC2 인스턴스 메타데이터 서비스(IMDS)가 유일한 현실적 선택지다. 문제는 기본 설정 그대로 두면 SSRF 취약점 하나로 IAM 자격증명까지 탈취당할 수 있다는 점이다. TL;DR — IMDSv1 vs IMDSv2 핵심 비교 항목 IMDSv1 IMDSv2 인증 방식 없음 (단순 GET) 세션 토큰 (PUT → GET) SSRF 취약점 노출 높음 낮음 (토큰 발급에 PUT 필요) TTL 제어 불가 가능 (1초 ~ 21600초) 강제 적용 방법 해당 없음 HttpTokens=required 기본 엔드포인트 http://169.254.169.254 인스턴스 메타데이터 서비스(IMDS)가 동작하는 방식 IMDS는 인스턴스 내부에서만 접근 가능한 링크-로컬 HTTP 엔드포인트( 169.254.169.254 )다. 하이퍼바이저 계층에서 라우팅을 차단하기 때문에 인스턴스 외부에서는 원칙적으로 도달할 수 없다. 인스턴스 ID, AMI ID, IAM 역할 자격증명, 네트워크 인터페이스 정보 등 부트스트랩에 필요한 거의 모든 런타임 정보를 여기서 가져온다. IMDSv1은 단순 GET 요청만으로 모든 데이터를 반환한다. 애플리케이션에 SSRF(Server-Side Request Forgery) 취약점이 있으면 공격자는 그 취약점을 통해 http://169.254.169.254/latest/meta-data/iam/security-credentials/ 까지 도달해 임시 자격증명을 탈취할 수 있다. 실제로 2019년 Capital One 침해 사고의 핵심 경로가 이 패턴이었다. IMDSv2는 세션...

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...