클라우드활용 4주차 — AWS IAM: 인증·인가, 사용자·그룹·정책 & MFA

IAM의 인증·인가 개념과 그룹·사용자·정책, 최소권한 인라인 정책, 액세스 키 라이프사이클, 가상 MFA 활성화(TOTP 검증)까지 CLI로 다뤄 본 4주차 기록.

Posted Apr 2, 2026

By 최 민우

9 min read

4주차는 AWS의 자격증명·접근제어 서비스인 IAM(Identity and Access Management) 을 다룬다. 강의는 콘솔(GUI) 기반이지만 여기서는 AWS CLI로 진행했다. 그룹·정책·사용자 생성부터 인라인 최소권한 정책(JSON), 액세스 키 라이프사이클, 가상 MFA 활성화(TOTP 검증) 까지 한 흐름으로 진행했다. 생성한 자원은 끝에서 모두 삭제했고, 계정 ID는 일부 가렸다.

핵심 개념

인증(Authentication) vs 인가(Authorization): 인증은 “누구인가”(자격증명 확인), 인가는 “무엇을 할 수 있는가”(정책으로 접근 허용/거부). IAM이 둘 다 담당한다.
Root 사용자 vs IAM 사용자: Root는 모든 권한의 계정 소유자라 꼭 필요할 때만 쓰고, 일상 작업은 권한을 제한한 IAM 사용자 로 한다.
IAM 그룹(Group): 여러 사용자에게 권한을 한 번에 부여하는 묶음. 사용자를 그룹에 넣으면 그룹 정책을 상속한다.
정책(Policy): 권한을 정의한 JSON 문서. AWS가 관리하는 관리형 정책 과 특정 주체에 직접 붙이는 인라인 정책 이 있다.
최소 권한 원칙(Least Privilege): 업무에 필요한 만큼만 허용. 여기서는 “특정 버킷 1개만 읽기” 정책을 작성했다.
MFA: 비밀번호(아는 것) + OTP 토큰(가진 것)의 2단계 인증.
액세스 키: CLI/SDK용 자격증명. 유출 위험이 커 가능하면 만들지 않고, 만들었다면 비활성화→삭제 로 무력화할 수 있어야 한다.

IAM 다루기

관리 권한을 가진 admin IAM 사용자로, --profile clouduse(서울 리전 ap-northeast-2)에서 실행했다.

그룹 생성 + 관리형 정책 연결

  
$ aws iam create-group --group-name clouduse-dev --query "Group.[GroupName,GroupId,Path]" --output text
clouduse-dev    AGPA5SZRJB65********    /

$ aws iam attach-group-policy --group-name clouduse-dev \
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

$ aws iam list-attached-group-policies --group-name clouduse-dev \
    --query "AttachedPolicies[].PolicyName" --output text
AmazonS3ReadOnlyAccess

개발자용 그룹에 S3 읽기 전용 관리형 정책을 연결했다. 이후 이 그룹에 들어오는 사용자는 동일 권한을 상속한다.

사용자 생성 + 그룹 가입

  
$ aws iam create-user --user-name clouduse-week4 --query "User.[UserName,UserId,Arn]" --output text
clouduse-week4  AIDA5SZRJB65********    arn:aws:iam::9337****0266:user/clouduse-week4

$ aws iam add-user-to-group --user-name clouduse-week4 --group-name clouduse-dev
$ aws iam list-groups-for-user --user-name clouduse-week4 --query "Groups[].GroupName" --output text
clouduse-dev

사용자를 그룹에 넣는 것만으로 권한이 부여된다.

최소 권한 인라인 정책(JSON) 작성·부착

버킷 1개에 대한 읽기/목록만 허용하는 정책을 작성했다.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOneBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::clouduse-portfolio-demo",
        "arn:aws:s3:::clouduse-portfolio-demo/*"
      ]
    }
  ]
}

  
$ aws iam put-user-policy --user-name clouduse-week4 \
    --policy-name read-one-bucket --policy-document file://least-privilege.json
$ aws iam list-user-policies --user-name clouduse-week4 --query "PolicyNames" --output text
read-one-bucket

관리형 정책(*FullAccess/*ReadOnly)보다 범위를 좁힌 인라인 정책으로, Resource 를 특정 ARN으로 못박아 최소 권한을 구현했다.

콘솔 로그인 프로필 생성

  
$ aws iam create-login-profile --user-name clouduse-week4 \
    --password '********' --password-reset-required \
    --query "LoginProfile.UserName" --output text
clouduse-week4

--password-reset-required 로 최초 로그인 시 비밀번호 변경을 강제해 초기 비밀번호 유출 위험을 줄인다.

액세스 키 라이프사이클 (생성 → 비활성화 → 삭제)

키 유출 대응 흐름 — 만들었다가 즉시 무력화한다.

  
$ aws iam create-access-key --user-name clouduse-week4    # SecretAccessKey는 미표시
AccessKeyId = AKIA5SZR**************   (생성됨)

$ aws iam update-access-key --user-name clouduse-week4 \
    --access-key-id AKIA5SZR... --status Inactive          # 유출 의심 시 즉시 비활성화
$ aws iam list-access-keys --user-name clouduse-week4 \
    --query "AccessKeyMetadata[].[AccessKeyId,Status]" --output text
AKIA5SZR************    Inactive

$ aws iam delete-access-key --user-name clouduse-week4 --access-key-id AKIA5SZR...   # 영구 삭제

“비활성화(Inactive)”는 즉시 못 쓰게 막으면서 되돌릴 수 있는 상태, “삭제”는 영구 제거다. 사고 대응에서는 먼저 비활성화 → 영향 확인 후 삭제 순서가 안전하다.

가상 MFA 디바이스 생성 + 활성화 (TOTP 검증)

인증 앱이 하는 일을 CLI로 재현했다. 시드로 RFC 6238 TOTP 코드를 계산해 활성화한다.

  
$ aws iam create-virtual-mfa-device --virtual-mfa-device-name clouduse-week4-mfa \
    --outfile mfa_seed.txt --bootstrap-method Base32StringSeed
  → 가상 MFA 발급(Base32 시드 파일) — 시드는 미표시

# 시드로 연속된 두 시간창의 TOTP 코드 계산 (인증앱과 동일 알고리즘)
$ aws iam enable-mfa-device --user-name clouduse-week4 \
    --serial-number arn:aws:iam::9337****0266:mfa/clouduse-week4-mfa \
    --authentication-code1 481420 --authentication-code2 643903
  → MFA 활성화 완료

$ aws iam list-mfa-devices --user-name clouduse-week4 \
    --query "MFADevices[].SerialNumber" --output text
arn:aws:iam::9337****0266:mfa/clouduse-week4-mfa

AWS는 연속된 두 개의 OTP 를 요구해 시드 동기화를 검증한다. 활성화 후 list-mfa-devices 에 디바이스가 잡히면 2단계 인증이 걸린 것이다.

상태 확인 + 정리 (자원 삭제)

  
# 정리 — 의존성 역순으로 삭제
$ aws iam deactivate-mfa-device  --user-name clouduse-week4 --serial-number ...:mfa/clouduse-week4-mfa
$ aws iam delete-virtual-mfa-device --serial-number ...:mfa/clouduse-week4-mfa
$ aws iam delete-login-profile   --user-name clouduse-week4
$ aws iam delete-user-policy      --user-name clouduse-week4 --policy-name read-one-bucket
$ aws iam remove-user-from-group  --user-name clouduse-week4 --group-name clouduse-dev
$ aws iam delete-user             --user-name clouduse-week4
$ aws iam detach-group-policy     --group-name clouduse-dev --policy-arn ...AmazonS3ReadOnlyAccess
$ aws iam delete-group            --group-name clouduse-dev

# 삭제 확인
$ aws iam get-user  --user-name clouduse-week4 2>&1 | grep -o NoSuchEntity
NoSuchEntity

IAM은 과금되지 않지만 사용자·MFA·키 같은 자격증명은 그대로 두면 보안 위험이라 모두 삭제했다. 삭제는 MFA→로그인프로필→정책→그룹탈퇴→사용자→정책분리→그룹 의존성 역순으로 진행한다.

정리

그룹에 정책을 두고 사용자를 가입시키면, 인사이동(그룹 이동)만으로 권한이 재구성되는 그룹 기반 권한 관리 가 가능하다. 최소 권한은 결국 정책 JSON의 Action·Resource 를 얼마나 좁히느냐의 문제이며, AmazonS3ReadOnlyAccess(전체 버킷 읽기) → 특정 버킷만 읽기 인라인 정책으로 범위를 줄여봤다. MFA는 CLI로 직접 활성화해, 인증 앱의 6자리 숫자가 시드 + 현재 시각 으로 만든 TOTP라는 것을 코드 계산으로 확인했다. 액세스 키는 만들지 않는 것이 최선이고, 만들었다면 비활성화→삭제 2단계 대응이 정석이다.

Dev, DevOps

This post is licensed under CC BY 4.0 by the author.