IAM — 자격 증명과 권한

클라우드의 모든 호출은 결국 "누가 · 무엇을 · 어디에" 의 질문을 통과합니다. AWS 에서 그 질문을 받는 자리가 IAM (Identity and Access Management) 입니다. 다른 매니지드 서비스가 화려해 보이는 데 비해 IAM 은 텍스트 정책 위주의 평범한 표면을 가지지만, 운영 사고의 상당수가 이 표면에서 발생합니다.

1. IAM 에 대한 이야기

시기	사건
2010	IAM 일반 공개 + MFA 디바이스.
2012	IAM Roles.
2018	Permission Boundary.
2019	IAM Access Analyzer.
2022	IAM Identity Center (구 SSO 리브랜드).

전 리전 공통 (global) 으로 동작하며 사용 자체는 무료 (자원이 없으므로).

핵심 객체:

Root 사용자 — 계정 생성 시 만들어지는 최상위. 일상에 쓰지 않는 흐름.
IAM User — 사람 또는 시스템 단위 신원.
IAM Group — 사용자 묶음.
IAM Role — 임시 자격으로 누군가가 가정 (assume) 하는 신원.
Policy — JSON 으로 적은 권한 규칙 묶음.

2. Policy 의 구조

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
      "StringEquals": { "s3:prefix": "uploads/" }
    }
  }]
}

Effect 는 Allow 또는 Deny. 명시적 Deny 는 항상 우선. Action 은 서비스 prefix + 동작 이름. Resource 는 ARN. Condition 으로 IP · 시간 · 태그 · MFA 여부 등을 추가합니다.

3. Managed vs Inline

종류	메모
AWS Managed Policy	AWS 가 만든 표준 정책. `AmazonS3ReadOnlyAccess`.
Customer Managed Policy	사용자가 만든 재사용 정책. 여러 신원에 부착.
Inline Policy	한 신원에 직접 박힌 정책. 신원과 함께 삭제.

운영에서는 Customer Managed 가 권장됩니다. 재사용·버전 관리·CloudFormation 추적이 자연스럽습니다.

4. Identity-based vs Resource-based

Identity-based — 정책이 IAM User · Group · Role 에 붙음. "이 신원은 무엇을 할 수 있다."
Resource-based — 정책이 자원에 붙음 (S3 Bucket Policy · KMS Key Policy · Lambda Resource Policy). "이 자원에 누가 접근할 수 있다."

같은 호출은 두 정책이 모두 Allow 이거나, 한쪽이 Allow 이고 다른 쪽이 명시적 Deny 가 아니어야 합니다.

5. AssumeRole · STS

STS (Security Token Service) 는 임시 자격 증명을 발급하는 서비스입니다. AssumeRole API 가 가장 흔한 진입점.

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AppRole \
  --role-session-name app-session

응답으로 AccessKeyId · SecretAccessKey · SessionToken · 만료 시각이 돌아옵니다. 기본 1 시간 (최대 12 시간) 만료. EC2 인스턴스 프로파일 · Lambda 실행 역할 · IRSA (EKS) 도 결국 내부에서 AssumeRole 을 호출해 임시 자격을 받는 모델입니다.

6. Trust Policy

Role 에는 두 종류 정책이 따라붙습니다. Permission Policy (이 Role 이 무엇을 할 수 있는지) 와 Trust Policy (누가 이 Role 을 가정할 수 있는지).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

이 Trust Policy 는 EC2 서비스가 Role 을 가정할 수 있다는 의미. 다른 계정 ARN 을 Principal 로 두면 cross-account 접근.

7. Permission Boundary

신원에 부여 가능한 최대 권한의 상한. Boundary 를 벗어나는 정책은 부착해도 무효가 됩니다. 위임 권한 (개발자가 자신의 팀 IAM 객체를 만들도록 허용) 의 안전 장치로 자주 쓰입니다.

8. IAM Access Analyzer

자원 기반 정책을 분석해 외부 (다른 계정 · 공개) 에 노출된 자리를 찾아 보고합니다. S3 · KMS · Lambda · IAM Role 트러스트 정책 등을 대상.

9. IAM Identity Center

조직 단위 SSO. AD · Okta · Azure AD 와 연동, 콘솔·CLI 의 일회성 자격 발급. 여러 AWS 계정을 운영하는 조직에서 IAM User 를 직접 만들기보다 Identity Center 의 Permission Set 으로 위임하는 흐름이 권장됩니다.

10. 다른 클라우드의 대응

Azure — RBAC + Managed Identity. Subscription · Resource Group 단위 역할.
GCP — Service Account 가 1 급 신원. Workload Identity Federation.
Cloudflare Zero Trust · Tailscale ACL — 신원을 네트워크 차원에서 강제.
Vault (HashiCorp) — 동적 자격 증명 발급. AWS · DB · SSH.

11. 최소 권한 + MFA

필요한 Action 만 부여, * 권한은 임시·예외에만.
자원 ARN 을 가능한 한 좁게.
Condition 으로 IP · MFA · Tag 추가 제약.
정책 변경 시 Access Analyzer · IAM Policy Simulator 로 영향 검증.

MFA 강제:

{
  "Effect": "Deny",
  "Action": "iam:DeleteUser",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
  }
}

장기 액세스 키 (IAM User) 는 회전·노출 위험이 따라옵니다. 가능한 곳에서는 Role + STS 임시 자격 (EC2 인스턴스 프로파일 · Lambda 실행 역할 · OIDC 연합) 으로 대체.

12. 자주 걸리는 자리

* 정책의 잔존 — 초기엔 편의로 Action: *, Resource: * 으로 시작했다가 정리되지 않음. 주기적 점검.

신뢰 정책 누락 — Role 의 Trust Policy 에 호출 주체가 없으면 가정 자체가 안 됩니다. "AccessDenied" 의 단골 원인.

자원 기반 정책 vs 신원 정책 충돌 — 한쪽 Allow, 한쪽 Deny 인 경우 Deny 가 이깁니다. 양쪽을 모두 봅니다.

루트 자격 일상 사용 — 사고 시 회복 어려움. 별도 IAM User 또는 Identity Center 사용 후 잠그는 흐름.

세션 토큰 누락 — 임시 자격을 받을 땐 AccessKey + SecretKey 외에 SessionToken 까지 환경 변수로.

Permission Boundary 와 SCP 의 혼동 — SCP (Service Control Policy) 는 Organization 레벨, Permission Boundary 는 IAM 레벨. 두 층이 동시 작동.

하고픈 말

IAM 은 표면이 단조로운 만큼 사고가 잘 보이지 않습니다. * 권한 · 루트 자격 일상 사용 · MFA 미강제 셋이 가장 흔한 사고 패턴입니다. Access Analyzer 와 Policy Simulator 를 반복 운영의 기본 도구로 두면 점검이 쉬워집니다.

IAM 사용자 가이드 · STS · IAM Identity Center · Policy Simulator · Access Analyzer · Vault · GitHub Actions OIDC 를 참고합니다.

IAM — 자격 증명과 권한

1. IAM 에 대한 이야기

시기	사건
2010	IAM 일반 공개 + MFA 디바이스.
2012	IAM Roles.
2018	Permission Boundary.
2019	IAM Access Analyzer.
2022	IAM Identity Center (구 SSO 리브랜드).

전 리전 공통 (global) 으로 동작하며 사용 자체는 무료 (자원이 없으므로).

핵심 객체:

Root 사용자 — 계정 생성 시 만들어지는 최상위. 일상에 쓰지 않는 흐름.
IAM User — 사람 또는 시스템 단위 신원.
IAM Group — 사용자 묶음.
IAM Role — 임시 자격으로 누군가가 가정 (assume) 하는 신원.
Policy — JSON 으로 적은 권한 규칙 묶음.

2. Policy 의 구조

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
      "StringEquals": { "s3:prefix": "uploads/" }
    }
  }]
}

3. Managed vs Inline

종류	메모
AWS Managed Policy	AWS 가 만든 표준 정책. `AmazonS3ReadOnlyAccess`.
Customer Managed Policy	사용자가 만든 재사용 정책. 여러 신원에 부착.
Inline Policy	한 신원에 직접 박힌 정책. 신원과 함께 삭제.

운영에서는 Customer Managed 가 권장됩니다. 재사용·버전 관리·CloudFormation 추적이 자연스럽습니다.

4. Identity-based vs Resource-based

Identity-based — 정책이 IAM User · Group · Role 에 붙음. "이 신원은 무엇을 할 수 있다."
Resource-based — 정책이 자원에 붙음 (S3 Bucket Policy · KMS Key Policy · Lambda Resource Policy). "이 자원에 누가 접근할 수 있다."

같은 호출은 두 정책이 모두 Allow 이거나, 한쪽이 Allow 이고 다른 쪽이 명시적 Deny 가 아니어야 합니다.

5. AssumeRole · STS

STS (Security Token Service) 는 임시 자격 증명을 발급하는 서비스입니다. AssumeRole API 가 가장 흔한 진입점.

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AppRole \
  --role-session-name app-session

6. Trust Policy

Role 에는 두 종류 정책이 따라붙습니다. Permission Policy (이 Role 이 무엇을 할 수 있는지) 와 Trust Policy (누가 이 Role 을 가정할 수 있는지).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

이 Trust Policy 는 EC2 서비스가 Role 을 가정할 수 있다는 의미. 다른 계정 ARN 을 Principal 로 두면 cross-account 접근.

7. Permission Boundary

8. IAM Access Analyzer

자원 기반 정책을 분석해 외부 (다른 계정 · 공개) 에 노출된 자리를 찾아 보고합니다. S3 · KMS · Lambda · IAM Role 트러스트 정책 등을 대상.

9. IAM Identity Center

10. 다른 클라우드의 대응

Azure — RBAC + Managed Identity. Subscription · Resource Group 단위 역할.
GCP — Service Account 가 1 급 신원. Workload Identity Federation.
Cloudflare Zero Trust · Tailscale ACL — 신원을 네트워크 차원에서 강제.
Vault (HashiCorp) — 동적 자격 증명 발급. AWS · DB · SSH.

11. 최소 권한 + MFA

필요한 Action 만 부여, * 권한은 임시·예외에만.
자원 ARN 을 가능한 한 좁게.
Condition 으로 IP · MFA · Tag 추가 제약.
정책 변경 시 Access Analyzer · IAM Policy Simulator 로 영향 검증.

MFA 강제:

{
  "Effect": "Deny",
  "Action": "iam:DeleteUser",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
  }
}

12. 자주 걸리는 자리

* 정책의 잔존 — 초기엔 편의로 Action: *, Resource: * 으로 시작했다가 정리되지 않음. 주기적 점검.

신뢰 정책 누락 — Role 의 Trust Policy 에 호출 주체가 없으면 가정 자체가 안 됩니다. "AccessDenied" 의 단골 원인.

자원 기반 정책 vs 신원 정책 충돌 — 한쪽 Allow, 한쪽 Deny 인 경우 Deny 가 이깁니다. 양쪽을 모두 봅니다.

루트 자격 일상 사용 — 사고 시 회복 어려움. 별도 IAM User 또는 Identity Center 사용 후 잠그는 흐름.

세션 토큰 누락 — 임시 자격을 받을 땐 AccessKey + SecretKey 외에 SessionToken 까지 환경 변수로.

Permission Boundary 와 SCP 의 혼동 — SCP (Service Control Policy) 는 Organization 레벨, Permission Boundary 는 IAM 레벨. 두 층이 동시 작동.

하고픈 말

IAM 사용자 가이드 · STS · IAM Identity Center · Policy Simulator · Access Analyzer · Vault · GitHub Actions OIDC 를 참고합니다.

IAM — 자격 증명과 권한

IAM — 자격 증명과 권한

1. IAM 에 대한 이야기

2. Policy 의 구조

3. Managed vs Inline

4. Identity-based vs Resource-based

5. AssumeRole · STS

6. Trust Policy

7. Permission Boundary

8. IAM Access Analyzer

9. IAM Identity Center

10. 다른 클라우드의 대응

11. 최소 권한 + MFA

12. 자주 걸리는 자리

하고픈 말

Next

cloud 카테고리의 다른 글

IAM — 자격 증명과 권한

IAM — 자격 증명과 권한

1. IAM 에 대한 이야기

2. Policy 의 구조

3. Managed vs Inline

4. Identity-based vs Resource-based

5. AssumeRole · STS

6. Trust Policy

7. Permission Boundary

8. IAM Access Analyzer

9. IAM Identity Center

10. 다른 클라우드의 대응

11. 최소 권한 + MFA

12. 자주 걸리는 자리

하고픈 말

Next

cloud 카테고리의 다른 글