라벨이 보안인 게시물 표시

IAM 정책 구조 완전 해설: Effect, Action, Resource, Condition 차이점

처음 IAM 정책 JSON을 열어봤을 때, 왜 이 권한이 작동하는지 혹은 왜 막히는지 파악하지 못해서 한참을 헤맨 경험이 있을 것이다. IAM 정책 구조 의 네 가지 핵심 요소 — Effect , Action , Resource , Condition — 를 정확히 이해하지 못하면, 권한 오류는 항상 예상치 못한 곳에서 터진다. TL;DR — IAM 정책 핵심 요소 비교 요소 역할 필수 여부 핵심 주의사항 Effect Allow 또는 Deny 결정 필수 Explicit Deny는 모든 Allow를 재정의 Action 허용/거부할 API 작업 지정 필수 서비스 네임스페이스:작업명 형식 필수 Resource 정책이 적용될 AWS 리소스 범위 필수 일부 작업은 * 만 허용 Condition 정책 적용 조건 (선택적 필터) 선택 조건 키는 서비스별로 지원 범위가 다름 IAM 정책이 평가되는 방식 IAM 정책은 단순한 허용 목록이 아니다. AWS는 요청이 들어올 때마다 해당 요청에 적용되는 모든 정책을 수집하고, 정해진 평가 로직에 따라 최종 Allow/Deny를 결정한다. 이 평가 순서를 모르면 왜 권한이 막히는지 절대 파악할 수 없다. graph TD A["API 요청 수신"] --> B{"Explicit Deny 존재 여부"} B -- "Yes" --> C["즉시 거부 (Deny)"] B -- "No...

S3 Presigned URL 생성 완전 가이드 — SDK로 1시간 임시 다운로드 링크 만들기

프라이빗 S3 버킷에 저장된 파일을 외부 사용자에게 일시적으로 공개해야 할 때, 버킷 정책을 건드리거나 퍼블릭 ACL을 열지 않고도 해결하는 방법이 바로 Presigned URL이다. 실제 운영 환경에서는 '이 파일 한 번만 다운로드할 수 있게 해줘'라는 요구가 생각보다 자주 온다 — 계약서 전달, 리포트 공유, 미디어 파일 배포 등. S3 Presigned URL은 서버 측에서 서명된 임시 접근 토큰을 URL에 포함시켜, 지정된 만료 시간 내에만 해당 객체에 접근할 수 있도록 제어한다. TL;DR — S3 Presigned URL 핵심 요약 항목 내용 목적 IAM 자격증명 없이 특정 S3 객체에 임시 접근 허용 서명 방식 SigV4 (AWS Signature Version 4) 기본 만료 범위 최소 1초 ~ 최대 7일 (IAM 역할 기반 서명 시 최대 12시간) SDK 메서드 Python: generate_presigned_url / JS: getSignedUrl (v2), getSignedUrl from @aws-sdk/s3-request-presigner (v3) 주요 주의사항 서명에 사용된 자격증명이 만료되면 URL도 즉시 무효화됨 S3 Presigned URL 동작 원리 Presigned URL은 S3 서비스가 생성하는 것이 아니다. SDK를 실행하는 서버(혹은 Lambda)가 로컬에서 서명을 계산해 URL에 포함 시킨다. S3는 요청이 들어왔을 때 URL에 포함된 서명 파라미터를 검증할 뿐이다. 이 차이가 중요한 이유는 — 서명을 생성한 자격증명(IAM 사용자 또는 역할)이 비활성화되거나 만료되면, URL 자체의 만료 시간이 남아 있어도 요청이 거부된다. sequenceDiagram participant App as 애플리케이션 서버 parti...

EC2 인스턴스 ID를 스크립트에서 가져오는 법 — IMDSv2가 V1보다 안전한 이유

서버 내부에서 실행 중인 스크립트가 자신이 어느 인스턴스인지 알아야 할 때가 있다. 로그에 인스턴스 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는 세션...

Lambda 환경 변수 완전 가이드: DB 엔드포인트 주입부터 KMS 암호화까지

Lambda 함수에 데이터베이스 엔드포인트를 하드코딩했다가 코드 리포지토리에 그대로 노출된 경험이 한 번쯤은 있을 것이다. Lambda 환경 변수는 이 문제를 해결하는 가장 직접적인 방법이지만, KMS 암호화 옵션을 잘못 이해하면 오히려 보안 감사에서 지적을 받는다. TL;DR — Lambda 환경 변수 핵심 요약 항목 내용 환경 변수 설정 방법 콘솔, CLI, IaC 모두 지원. 런타임에 OS 환경 변수로 주입됨 기본 암호화 저장 시 AWS 관리형 키(aws/lambda)로 자동 암호화 KMS 고객 관리형 키(CMK) 별도 KMS 키 지정 시 추가 제어 가능. 함수 실행 역할에 kms:Decrypt 필요 전송 중 암호화 콘솔 헬퍼 암호화 사용 시 배포 전 클라이언트 측 암호화 적용 민감 정보 대안 Secrets Manager 또는 SSM Parameter Store(SecureString) 권장 Lambda 환경 변수가 동작하는 방식 Lambda는 함수 배포 패키지와 환경 변수를 분리해서 관리한다. 환경 변수는 함수 설정의 일부로 저장되고, 실행 환경(Execution Environment)이 초기화될 때 프로세스의 OS 환경 변수로 주입된다. 코드에서는 process.env.DB_ENDPOINT (Node.js), os.environ['DB_ENDPOINT'] (Python) 처럼 일반 환경 변수와 동일하게 읽는다. 저장 계층에서 Lambda는 기본적으로 AWS 관리형 KMS 키( aws/lambda )를 사용해 환경 변수를 암호화한다. 이 키는 AWS가 소유하고 관리하므로 별도 비용이 발생하지 않지만, 키 정책 제어나 감사 로그 분리는 불가능하다. 고객 관리형 키(CMK)를 지정하면 키 정책으로 접근을 제어하고 CloudTrail에서 복호화 이벤트를 추적할 수 있다. ...

IAM User vs IAM Role 차이점 완전 정리 — EC2에서 S3 접근 시 무엇을 써야 하는가

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은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...