Access Key에서 IAM Role 기반 인증으로 전환 — 왜, 어떻게

Access Key가 위험한 이유

Access Key는 AWS API를 호출할 수 있는 문자열 자격증명입니다.

# 개발자가 로컬에서 AWS CLI 쓸 때
aws configure
  AWS Access Key ID: AKIA...EXAMPLE
  AWS Secret Access Key: wJal...EXAMPLEKEY

이 키는 한번 발급하면 만료 없이 영구적으로 유효합니다. 유출되면 누구든 그 권한으로 AWS를 조작할 수 있어요.

실제로 .env 파일에 넣어두다가 GitHub에 올라가거나, 슬랙에 공유하다가 유출되는 사고가 빈번합니다. 보안 감사에서 Access Key가 하나라도 남아있으면 지적 대상이 됩니다.

IAM Role 기반 인증이란

IAM Role을 할당하면, AWS가 내부적으로 STS(Security Token Service) 임시 자격증명을 자동 발급합니다. 이 토큰은 보통 1~12시간 후 자동 만료되고, 코드에 키를 넣을 필요가 없어요.

# Access Key 방식 (나쁜 예)
코드/설정에 키 하드코딩 → 영구 유효 → 유출 시 무제한 접근

# IAM Role 방식 (좋은 예)
AWS가 임시 토큰 자동 발급 → 1~12시간 후 만료 → 코드에 키 없음

Access Key vs IAM Role 비교

환경별 적용 사례

ECS Fargate → Task Role

컨테이너가 S3, Secrets Manager 등에 접근할 때 Access Key 없이 Role로 인증합니다.

ECS Task Definition
    └── Task Role (컨테이너 내 코드가 AWS API 호출 시 사용)
        └── S3, SES, Secrets Manager 등 접근 정책 연결

Task Execution Role과 혼동하지 않도록 주의. Execution Role은 이미지 Pull, 로그 전송 등 ECS 인프라 작업용이고, Task Role이 애플리케이션 코드가 사용하는 Role입니다.

EC2 → Instance Profile (IAM Role)

EC2에서 AWS CLI나 SDK를 쓸 때 Access Key 없이 Role로 인증합니다.

# Access Key 설정 없이 바로 사용 가능
aws s3 ls s3://my-bucket/
# → EC2에 할당된 IAM Role의 권한으로 실행됨

Lambda → Execution Role

Lambda 함수가 SES, DynamoDB, S3 등을 호출할 때 Role로 인증합니다. Lambda는 태생적으로 Access Key를 쓸 이유가 없는 구조입니다.

Access Key가 불가피한 경우

모든 환경에서 IAM Role을 쓸 수 있는 건 아닙니다.

온프레미스 서버

AWS 외부 서버이므로 EC2 Instance Role을 사용할 수 없습니다. IAM User를 생성하고 Access Key를 발급받아야 합니다.

aws configure --profile onprem-service
# → 장기키 사용, 로테이션 관리 필수

Presigned URL (장기 유효)

ECS Task Role(STS 기반)로 Presigned URL을 생성하면, URL 유효기간을 7일로 설정해도 STS 세션 토큰이 먼저 만료되어 ExpiredToken(400) 에러가 발생합니다.

[문제]
ECS Task Role (STS) → Presigned URL 생성
  → STS 세션 만료 시 URL 조기 사망
  → 주말 걸치는 다운로드 실패

[해결]
IAM User 장기키 → Presigned URL 생성
  → 세션 만료 없음
  → URL 만료시간 = 실제 유효시간 (최대 7일)

이런 경우에는 장기키를 쓰되, 다음 통제를 반드시 적용합니다:

• prod/dev 키 완전 분리
• Prefix 단위 최소 권한 (버킷 전체 접근 불가)
• StaticCredentialsProvider로 명시적 사용 (다른 AWS 호출에 장기키가 전파되지 않도록)
• Access Key 정기 로테이션
• CloudTrail로 키 사용 이력 추적

Access Key 보안 통제 (남아있는 키 관리)

완전히 제거할 수 없는 Access Key에 대해서는 다음 통제를 적용합니다.

AWS Config 규칙

버킷 정책으로 IP 제한

{
  "Sid": "DenyOtherIPsExceptAppRole",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Condition": {
    "NotIpAddress": {
      "aws:SourceIp": ["[office-ip]/32"]
    },
    "StringNotLike": {
      "aws:PrincipalArn": "arn:aws:iam::[account-id]:role/[task-role-name]"
    }
  }
}

Access Key가 유출되더라도 허용된 IP가 아니면 접근이 차단됩니다.

IMDSv2 — Role 자격증명 보호

IAM Role 기반 인증을 쓰더라도, EC2 메타데이터 서비스(IMDS)를 통해 임시 자격증명이 탈취될 수 있습니다.

# IMDSv1 (위험) — SSRF 공격으로 바로 접근 가능
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]
# → AccessKeyId, SecretAccessKey, Token 노출

IMDSv2를 강제 적용하면 PUT + 커스텀 헤더 기반 토큰 발급이 필요해져서 SSRF 공격을 원천 차단합니다. Capital One 해킹 사건(1억 600만 명 유출)이 IMDSv1 취약점을 악용한 대표적 사례입니다.

# IMDSv2 강제 적용
aws ec2 modify-instance-metadata-options \
  --instance-id i-[instance-id] \
  --http-tokens required

전환 체크리스트

정리

• AWS 환경에서 Access Key는 영구 유효한 문자열이라 유출 시 피해가 크고, IAM Role(STS 임시 자격증명)로 전환하면 자동 만료 + 코드에 키 없음으로 보안이 크게 향상됨
• ECS Task Role, EC2 Instance Profile, Lambda Execution Role로 대부분의 환경에서 Access Key 없이 운영 가능
• 온프레미스, 장기 Presigned URL 등 불가피한 경우에는 장기키 + 로테이션 + IP 제한 + CloudTrail 추적으로 통제
• IMDSv2 강제 적용으로 Role 임시 자격증명 자체의 탈취도 방어
• AWS Config 규칙으로 Access Key 로테이션, 미사용 자격증명, 루트 키 존재 여부를 상시 감시