AWS IAM 권한관리 실전 가이드 - 사용자, 역할, 정책을 어떻게 나눌까

IAM이 어려운 이유

AWS IAM은 문법보다 운영 모델이 더 어렵습니다.

실무에서 문제를 만드는 대표 패턴은 아래와 같습니다.

모든 사람이 관리자 권한을 공유
액세스 키를 장기간 방치
서비스 권한과 사람 권한이 섞여 있음
CI/CD에 과도한 권한을 부여
누가 어떤 리소스에 접근 가능한지 설명이 안 됨

IAM은 “접근을 허용하는 기능”이 아니라 “접근 경계를 설계하는 체계”로 보는 게 맞습니다.

가장 먼저 구분해야 하는 4가지

IAM User

사람 또는 특수한 장기 계정에 부여하는 식별자입니다.

현재는 가능하면 사람에게 직접 권한을 주기보다, SSO 또는 Role Assume 방식이 더 권장됩니다.

IAM Group

여러 User에 공통 정책을 부여하기 위한 단위입니다.

예:

developers
readonly
security-auditors

IAM Role

가장 중요한 개념입니다. 사람, 애플리케이션, EC2, Lambda, GitHub Actions 같은 주체가 “일시적으로 맡는 권한”입니다.

대부분의 실무 권한 설계는 Role 중심으로 가는 편이 안전합니다.

IAM Policy

실제 권한 문서입니다. 어떤 액션을 어떤 리소스에 허용 또는 거부할지 정의합니다.

최소 권한 원칙은 어떻게 적용할까

최소 권한은 “처음부터 완벽하게 좁게 만들기”보다 “필수 작업 기준으로 권한을 명시”하는 방식이 현실적입니다.

예를 들어 배포 Role이라면 이런 식으로 접근합니다.

ECR 이미지 Push 필요
ECS 또는 EKS 배포 갱신 필요
S3 아티팩트 업로드 필요
CloudFront 캐시 무효화 필요

이 업무 범위를 기준으로 필요한 액션만 부여합니다.

나쁜 예:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

개선된 예:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:CompleteLayerUpload",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ],
      "Resource": "arn:aws:ecr:ap-northeast-2:123456789012:repository/testforge-api"
    }
  ]
}

사람 권한은 어떻게 줄까

권장 모델은 아래와 같습니다.

개발자: 읽기 권한 + 개발 계정 제한적 배포 Role
운영자: 운영 계정 AssumeRole 권한
보안 담당자: CloudTrail, IAM Access Analyzer, Config 읽기 권한
DBA/플랫폼 팀: 특정 서비스 범위의 Role

사람이 AWS 콘솔에 로그인할 때 곧바로 관리자 권한을 얻는 구조는 피해야 합니다.

서비스 권한 설계 예시

EC2 / ECS / EKS 워크로드

애플리케이션이 S3, Secrets Manager, SQS를 써야 한다면, 해당 워크로드 전용 Role을 따로 둡니다.

예:

role/app-api-prod
role/batch-worker-prod
role/cicd-deployer-prod

애플리케이션마다 필요한 AWS API가 다르기 때문에 하나의 공용 Role을 여러 서비스가 공유하면 권한이 계속 비대해집니다.

CI/CD 권한은 특히 조심해야 한다

많은 팀이 GitHub Actions나 Jenkins에 관리자 권한을 줍니다. 가장 위험한 패턴입니다.

배포 파이프라인은 보통 아래 권한만 있으면 충분합니다.

컨테이너 레지스트리 Push
배포 대상 리소스 업데이트
아티팩트 저장소 접근
배포 로그 확인

GitHub Actions라면 OIDC 기반 Role 연동이 좋습니다.

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:testforge-kr/testforge-blog:*"
    }
  }
}

이렇게 하면 액세스 키를 저장소 시크릿으로 오래 보관하지 않아도 됩니다.

계정 분리는 권한 설계의 일부다

IAM만 잘 짜도 계정이 하나면 한계가 있습니다.

꼭 켜야 하는 보안 기능

IAM 운영 시 함께 보는 것이 좋은 기능들:

MFA
CloudTrail
IAM Access Analyzer
AWS Config
GuardDuty
Access Advisor

특히 Access Analyzer는 외부 공개 가능성이 있는 리소스를 찾는 데 도움이 됩니다.

실무 체크리스트

루트 계정 MFA 활성화
사람 계정 장기 액세스 키 제거
관리자 권한 사용자 최소화
서비스별 Role 분리
CI/CD Role 범위 제한
정책에 Resource: "*" 남용 금지
퇴사자/권한 변경 프로세스 문서화

마무리

AWS IAM 권한관리는 문서가 아니라 운영 습관에 가깝습니다.

잘 된 IAM 구조는 아래 특징이 있습니다.

누가 어떤 권한을 갖는지 설명 가능
서비스별 권한 경계가 분명함
액세스 키보다 임시 자격 증명을 우선함
사고가 나도 영향 범위를 빠르게 제한할 수 있음

초기에는 단순한 Role 구조로 시작하되, 사람 권한과 서비스 권한을 분리하는 것만으로도 보안 수준이 크게 올라갑니다.