ISMS 대응하다가 시작한 AWS Access Key 정리: Role 기반 인증 전환기

ISMS 사후심사 대응 과정에서 AWS 계정에 쌓여 있던 Access Key들을 점검하다가, Role 기반 인증으로 전환한 경험을 정리한 글입니다.

도입 배경

• IAM 콘솔을 보니 Access Key가 여러 곳(CI/CD, 배포 스크립트, 로컬 개발 등)에 퍼져 있었고, 어디서 어떻게 쓰이는지 추적이 어려웠음
• Access Key는 만료 없이 유지되고, 탈취 시 부여된 권한이 그대로 노출되는 구조라 위험 부담이 컸음
• AWS도 장기 자격증명(Access Key) 대신 임시 자격증명(역할/STS) 사용을 권장

문제

• 키가 여기저기 복사돼 사용되면서 “이 키가 탈취되면 어디까지 영향?”을 답하기 어려웠음
• 로테이션하려면 흩어진 설정을 동시에 바꿔야 하고, 한 IAM User에 여러 용도 권한이 뭉쳐 최소권한 적용이 어려웠음
• 당시 CI/CD용 IAM User 하나에 ECR/S3/SSM/ECS 배포 권한 등이 한꺼번에 몰려 있었음

전환한 방식(요약)

• Assume Role: 필요한 순간에 다른 Role 권한을 임시로 빌려 쓰는 방식
• OIDC Web Identity: GitHub Actions/EKS(=IRSA)처럼 외부 시스템 ID로 Role을 발급받는 방식
• Instance Profile: EC2/Lambda 등에 Role을 직접 붙여 자동으로 권한을 갖게 하는 방식

실제 전환 과정

• 1단계: 광범위 정책이 붙은 IAM User 권한을 용도별 Role로 분리(ECR 푸시/풀, ECS 배포, S3 캐시 등)
• 2단계: GitHub Actions에 OIDC 적용(Identity Provider 등록 → Trust Policy 조건으로 repo 범위 제한 → 워크플로우에서 configure-aws-credentials 사용)

효과

• 코드/시크릿에서 Access Key 제거, 임시 토큰 기반이라 탈취돼도 만료로 피해 범위가 제한됨
• 키 로테이션 부담이 사라지고, 워크플로우/작업별 권한 추적이 명확해짐

주의할 점

• Trust Policy 조건을 넓게 잡지 말고(org/repo, 가능하면 브랜치까지) 최소 범위로 제한
• 기존 Access Key는 즉시 삭제하지 말고, 전환 후 한동안 비활성화/검증 기간을 둔 뒤 삭제