[Part1 기본 개념 4편] IAM - 클라우드의 인증과 인가

mask - ACL 안전장치

위에서 ACL 출력 설명에서 넘어갔던 mask 를 살펴보겠습니다. mask::rws 를 처음 보면 뭔지 모를 수도 있습니다. 쉽게 얘기하면 권한의 최대 한도를 정하는 안전장치 역할을 합니다.

1ACL 항목:    user:철수:rwx         ← 철수에게 명시된 권한
2mask:       mask::r--           ← 마스크가 r-- 라면
3실제 적용:    r--                 ← AND 연산 결과만 효력
Copy

mask는 "이 파일의 모든 ACL 항목은 절대 mask를 넘지 못한다" 는 의미입니다. chmod g-w 같은 명령으로 그룹 권한을 줄이면 자동으로 mask도 함께 줄어들어, 기존 ACL 항목이 자연스럽게 따라 줄어듭니다.

mask 가 필요한 이유는 chmod 같은 명령은 9bits 만 알지 ACL은 모릅니다. 만약 ACL이 9bits 를 무시하고 권한을 뚫어버리면 기존 도구들의 예약된 동작이 깨져버립니다. mask가 "chmod로 권한을 줄이면 ACL도 따라 줄어든다" 를 보장해서 호환성을 지킵니다.

Default ACL - 권한 상속

서브 디렉토리를 만들 때마다 한땀 한땀 ACL을 설정하기는 매우 번거롭습니다. Default ACL 을 사용하면 굳이 새로운 ACL 을 설정할 필요가 없습니다.

1# /shared/project 안에 새로 만들어지는 모든 항목에 기본 ACL 부여
2# -d: default
3setfacl -d -m u:철수:r-x,u:영희:rwx /shared/project
4
5# 새 파일을 만들고 확인
6touch /shared/project/new-doc.txt
7getfacl /shared/project/new-doc.txt
8
9# 출력 결과 
10# file: shared/project/new-doc.txt
11user::rw-
12user:철수:r-x       ← 자동 적용
13user:영희:rwx          ← 자동 적용
14group::rwx
15mask::rwx
16other::---
Copy

위의 출력처럼 부모 디렉토리에 deafult ACL을 설정해두면 하위의 모든 파일과 폴더에 같은 부모 디렉토리와 같은 권한을 상속받습니다.

ACL 만 쓰면 되는 거 아닐까?

POSIX ACL 도입으로 9bits 권한 모델모다 훨씬 유연하게 권한 관리가 가능해졌습니다. 하지만 대부분의 AWS,GCP 와 같은 CSP 사들은 ACL을 그대로 적용하지 않고 새롭게 설계했습니다. POSIX ACL 이 9bits 권한 모델의 한계점을 개선하긴 했지만 클라우드, 분산환경에서는 아직도 문제점이 있기 때문입니다.

특히 클라우드 환경에서는 "확장성"과 "객체별 관리 오버헤드" 한계가 치명적입니다. ACL은 객체별로 권한을 관리하기 때문에 리소스, 객체가 많은 클라우드 환경에서는 관리 자체가 불가능하다고 봐야합니다. 그래서 "객체에 권한을 부여하는 게 아닌, 정책을 별도로 두고 자원(리소스)는 패턴(예: AWS의 arn)으로 매칭한다" 는 패러다임으로 전환했습니다.

1[ACL 모델]                            [IAM 모델]
2객체에 권한이 박혀있음                 정책은 별도, 객체는 ARN으로 매칭
3─────────────────────            ─────────────────────────
4file1.txt → ACL [수십 줄]          Policy 1개:
5file2.txt → ACL [수십 줄]           "S3의 backup-* 버킷에 read 가능"
6file3.txt → ACL [수십 줄]                 
7...                                  
8fileN.txt → ACL [수십 줄]          → 객체 1억 개라도 정책 1개로 커버
9
10객체 수만큼 권한 데이터가 늘어남         정책 수만큼만 권한 데이터가 늘어남
Copy

클라우드의 Linux 권한 모델 한계

클라우드 환경에서 Linux 권한 모델의 한계를 좀 더 자세히 살펴보겠습니다.

행위자가 더 이상 "사람"만이 아니다

9bits 권한 모델, POSIX ACL은 인증 대상이 "사람"이라고 가정합니다. 하지만 클라우드에서는 Virtual Machine, 서버리스 컴퓨팅, 외부 Saas 등 인증 대상이 다양해집니다.

- 사람: 개발자, 운영자, 외부 협력사 등
- 머신/서비스: EC2 인스턴스, Lambda 함수, ECS task, EKS pod
- CI/CD 파이프라인: GitHub Actions, GitLab CI 러너
- 외부 SaaS: Datadog, Snyk, Terraform Cloud
- AI 에이전트: 자동화된 봇, MCP 서버

특히 클라우드 환경에선 머신이 행위자가 되는 경우가 압도적으로 많습니다. 예를 들어 Lambda 함수가 S3에 파일을 올리고, EC2 인스턴스가 RDS에 쿼리하고, ECS task가 Secrets Manager에서 비밀을 꺼내옵니다. 이 모든 머신이 "누구" 로 식별되고 "무엇을 할 수 있는지" 결정되어야 합니다.

권한이 코드로 관리되어야 한다

1만 명의 직원, 100개의 마이크로서비스, 50개의 SaaS 통합이 있는 회사를 상상해봅시다. 각각의 ACL을 콘솔에서 수동으로 클릭클릭 관리하면 어떻게 될까요?

- 누가 언제 어떤 권한을 줬는지 추적 불가
- 실수로 한 번에 1만 명에게 admin 권한을 줘버림

그래서 클라우드 권한은 선언형 정책(Declarative policy)으로 표현하고 버전 관리를 합니다. 선언형 정책으로 바뀌면서 JSON으로 적힌 IAM Policy는 Git에 커밋되고, Terraform으로 배포되고, PR 리뷰를 거칠 수 있게 됩니다.

비밀번호와 영구 키는 위험하다

사용자명/비밀번호 또는 영구 API Key 와 같이 전통적인 인증 방식은 클라우드에서 보안사고를 발생시킵니다.

- GitHub에 실수로 AWS access key를 푸시 → 몇 분 안에 봇이 탈취해 EC2 1000대 띄워서 비트코인 채굴
- 직원이 퇴사했는데 그 사람이 발급받은 키가 어딘가에 남아있음
- 키를 어디에 썼는지 추적 어려움

이를 해결하기 위해 "필요할 때만 잠시 발급받아서 사용하고, 자동 만료 시킨다"는 단기 자격증명(short-lived credentials)을 사용합니다. 이게 AWS STS(Security Token Service)와 Role의 역할입니다.

IAM의 세 가지 주축: Principal, Policy, Trust

개념 설명이 정말 길었습니다. 앞의 개념과 POSIX ACL 의 한계를 이해하면 IAM은 의외로 단순합니다. IAM은 Principal, Policy, Trust 를 기반으로 약간씩 변형한 것이라고 생각하시면 됩니다.

Principal - "행위자"

Linux 권한 모델에 user, group 이 있다면 IAM에는 Principal 이 있습니다. Principal 은 IAM에서 행동의 주체를 가리키는 추상 개념입니다.

AWS IAM 을 설정하다보면 arn 이라는 단어를 굉장히 자주 보게 됩니다. arn(Amazon Resource Name)은 일종의 클라우드 UID + 풀네임으로 조합된 고유 식별자라고 생각하시면 됩니다.

1 arn: aws:iam::123456789012:user/wook
2└─┬─┘ └┬┘ └─┬─┘ └────┬────┘ └──┬──┘
3  │    │    │        │         └─ 리소스 (사용자명)
4  │    │    │        └─ 12자리 계정 번호
5  │    │    └─ 서비스 (iam)
6  │    └─ 파티션 (aws, aws-cn, aws-us-gov)
7  └─ 고정 prefix
Copy

Policy - "무엇을 할 수 있는가"

Policy는 "누가 무엇을 할 수 있는가"의 규칙을 JSON으로 표현한 것입니다. POSIX ACL보다 훨씬 더 다양하고 자유롭게 설정할 수 있습니다.

기본 구조는 단순합니다.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": "s3:GetObject",
7      "Resource": "arn:aws:s3:::my-bucket/*"
8    }
9  ]
10}
Copy

Identity-based vs Resource-based Policy

Policy 에는 2가지 종류가 있는데, 처음 접했을 땐 헷갈릴 수도 있습니다. 둘 다 같은 "누가 뭘 할 수 있는가" 의 표현이기만 하지만 권한에 대한 관점이 서로 다릅니다.

Identity-based 는 "이 사람/역할은 무엇을 할 수 있다"를 표현하고 Resource-based 는 "이 자원은 누구의 어떤 행동을 허용한다"를 표현합니다. Linux로 비유하자면 Identity-based는 sudoers(사용자별 허용 명령)이고 Resource-based는 파일의 ACL(파일별 허용자)라고 볼 수 있습니다.

AWS 리소스의 대부분은 Identity-based 만 지원합니다. S3 bucket policy, KMS key policy, Lambda function policy, SQS queue policy 등 다 같이 공유하는 리소스들은 Resource-based를 추가로 지원합니다.

운영 규모가 커질수록 2가지 관점이 점점 중요해지며, 설정할 일이 생깁니다. 만약 팀의 규모가 크거나 운영하는 리소스의 수가 많다면 두 정책의 관점 차이를 명확하게 이해하고 있어야 합니다.

1[Identity-based Policy]        [Resource-based Policy]
2   사용자/역할에 부착                 자원에 부착
3
4   "철수는 S3 GetObject 가능"       "이 버킷은 철수와 영희에게만 GetObject 허용"
5
6   주체 관점에서 권한 정의            객체 관점에서 권한 정의
Copy

Condition - 조건부 권한

IAM의 Condition 은 Linux 권한 모델의 한계점이었던 정적 표현을 해결한 강력한 기능입니다. "오직 회사 IP에서만", "MFA 인증을 한 경우에만", "특정 시간대에만" 같은 동적 조건을 추가할 수 있습니다.

1{
2  "Effect": "Allow",
3  "Action": "s3:DeleteObject",
4  "Resource": "arn:aws:s3:::critical-bucket/*",
5  "Condition": {
6    "Bool": { "aws:MultiFactorAuthPresent": "true" },
7    "IpAddress": { "aws:SourceIp": "203.0.113.0/24" },
8    "DateGreaterThan": { "aws:CurrentTime": "2026-01-01T00:00:00Z" }
9  }
10}
Copy

먼저 위 Policy 를 Condition 의미에 집중해서 해석해보시길 바랍니다. 위의 정책은 "MFA 인증된 상태이고, 203.0.113.0/24 IP 대역에서 2026년 01-01 이후에만 critical-bucket 에 있는 객체를 삭제할 수 있다"는 의미입니다. Linux ACL 만으로는 이와 같은 의미 표현을 나타낼 수가 없습니다.

Trust Policy - 누가 이 Role을 사용할 수 있는가

IAM의 Role 기본 전제는 "누구든 사용할 수 있다"입니다. 여기서 "누구"는 사람, 머신/서비스, AI에이전트 등을 의미합니다. 필요에 의해서 우리가 정의한 Role 을 특정 사용자/주체만 사용할 수 있도록 해야합니다. 그것을 정의하는 방법이 Trust Policy(신뢰 정책)이라고 이해하시면 됩니다.

AWS에서 문법은 간단합니다. Principal: {$Key: $Principal_Value} 형태로 사용하면 됩니다.

1# 이 역할은 EC2 인스턴스만 사용할 수 있다.
2{
3  "Version": "2012-10-17",
4  "Statement": [
5    {
6      "Effect": "Allow",
7	  # "Ec2 인스턴스만 사용할 수 있다" 표현
8      "Principal": { "Service": "ec2.amazonaws.com" },
9      "Action": "sts:AssumeRole"
10    }
11  ]
12}
13
14# 이 역할은 222222222222 계정의 user/admin만 사용할 수 있다. 
15{
16  "Version": "2012-10-17",
17  "Statement": [
18    {
19      "Effect": "Allow",
20      "Principal": { "AWS": "arn:aws:iam::222222222222:user/admin" },
21      "Action": "sts:AssumeRole",
22      "Condition": {
23        "StringEquals": { "sts:ExternalId": "shared-secret-string" }
24      }
25    }
26  ]
27}
Copy

STS와 단기 자격증명

이제 IAM의 핵심의 마지막 STS(Security Token Service)에 대해 알아보겠습니다. STS는 Role을 잠시 부여하고 단기 자격증명을 발급해주는 서비스입니다. Linux 의 sudo 와 비슷한 역할을 수행한다고 생각하시면 됩니다. AWS의 STS 플로우는 살펴보겠습니다.

이 플로우에서 핵심은 3가지입니다.

1. Role을 입을 때마다 새 자격증명이 발급된다.
2. 발급된 자격증명은 짧은 만료 시간(기본 1시간, 최대 12시간) 을 가진다
3. 모든 호출이 CloudTrail에 기록된다는 점이에요.

머신을 위한 자동 자격증명 주입

Ec2, Lambda, ECS 등과 같은 머신이 직접 STS를 호출하게 하는 것은 매우 번거로운 작업일겁니다. 그래서 AWS에서는 서비스, 머신 별로 자동 주입을 할 수 있는 매커니즘을 제공합니다.

boto3라는 라이브러리가 개발자 대신에 이 수행을 대신해주게 됩니다. 덕분에 개발자가 키를 직접 다룰 일이 없어집니다.

1import boto3
2# 자격증명을 명시적으로 안 줘도 됨 — boto3가 IMDS에서 자동으로 가져옴
3s3 = boto3.client('s3')
4obj = s3.get_object(Bucket='my-bucket', Key='data.json')
Copy

boto3의 credential provider chain 이 다음 순서로 자격증명을 찾습니다.

1. 환경 변수 (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
2. ~/.aws/credentials 파일
3. ECS task metadata endpoint (AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)
4. EC2 Instance Metadata Service (IMDS)
… 등등

Github Actions OIDC

많은 주니어들이 Github Actions 를 사용할 때 AWS 서비스 인증/인가 방식을 어떻게 수행해야 하는지 헷갈려합니다. CSP별로 방법이나 서비스의 차이가 있겠지만 AWS STS 방식을 알고 있다면 GCP, Azure를 사용할 때도 도움이 되실 겁니다.

위에서 다뤘던 Trust Policy 까지 사용한다면 "이 repo의 main 브랜치에서 실행되는 워크플로우만"으로 허용 범위를 좁힐 수 있습니다.

1{
2  "Effect": "Allow",
3  "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
4  "Action": "sts:AssumeRoleWithWebIdentity",
5  "Condition": {
6    "StringEquals": {
7      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
8      "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
9    }
10  }
11}
Copy

이러한 방법을 사용한다면 영구 access key를 Github에 저장할 일이 없어지고, 키 갱신이나 유출 걱정을 안해도 됩니다.

마무리

이번 포스팅은 다른 포스팅들보다 설명도 길었고, 내용도 쉽지 않았습니다. 만약 끝까지 이 글을 따라오신 분이 있다면 정말 박수쳐드리고 싶습니다!! 이로써 제가 생각했을 때 클라우드를 위한 기본기는 모두 다룬 것 같습니다.

다음 시리즈부터 본격적으로 AWS를 기반으로 한 서비스 설계에 대한 내용을 다룰 예정입니다.
Part2 에서는 단일 서비스 설계를 다루겠습니다.

2-1. 로드밸런서 — TCP 핸드쉐이크와 HTTP 프로토콜 → ALB/NLB 선택 기준
2-2. 컴퓨팅 선택 가이드 — 프로세스 모델 → EC2 vs ECS vs Lambda
2-3. 데이터베이스 아키텍처 — ACID와 B-Tree → RDS Multi-AZ, Read Replica
2-4. 캐시 설계 — Cache Coherence와 LRU → CDN, ElastiCache
2-5. 첫 3-Tier 아키텍처 — 설계부터 Terraform 배포까지

긴 글 읽어주시느라 고생하셨고, Linux 권한을 IAM Policy 로 번역해보는 예시를 마지막으로 끝내겠습니다.

연습1 - 이 파일은 owner만 읽고 쓸 수 있다

Linux:

1chmod 600 /home/wook/secret.txt
2chown wook:wook /home/wook/secret.txt
Copy

IAM:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "OnlyWookCanReadAndWrite",
6      "Effect": "Allow",
7      "Principal": { "AWS": "arn:aws:iam::123456789012:user/wook" },
8      "Action": ["s3:GetObject", "s3:PutObject"],
9      "Resource": "arn:aws:s3:::my-bucket/secret.txt"
10    },
11    {
12      "Sid": "DenyEveryoneElse",
13      "Effect": "Deny",
14      "NotPrincipal": { "AWS": "arn:aws:iam::123456789012:user/wook" },
15      "Action": "s3:*",
16      "Resource": "arn:aws:s3:::my-bucket/secret.txt"
17    }
18  ]
19}
Copy

연습2 - dev 그룹은 /var/log를 읽을 수 있다

Linux:

1chmod 750 /var/log
2chown root:dev /var/log
Copy

1resource "aws_iam_group" "dev" {
2  name = "dev"
3}
4
5resource "aws_iam_group_policy" "dev_logs_read" {
6  group = aws_iam_group.dev.name
7  policy = jsonencode({
8    Version = "2012-10-17"
9    Statement = [{
10      Effect   = "Allow"
11      Action   = ["logs:GetLogEvents", "logs:DescribeLogStreams", "logs:DescribeLogGroups"]
12      Resource = "arn:aws:logs:ap-northeast-2:123456789012:log-group:/var/log/*"
13    }]
14  })
15}
16
17resource "aws_iam_user_group_membership" "wook_dev" {
18  user   = "wook"
19  groups = [aws_iam_group.dev.name]
20}
Copy

연습3 - 철수는 평소엔 일반 권한, sudo로 admin 가능

1# /etc/sudoers
2철수  ALL=(ALL)  NOPASSWD: /usr/bin/systemctl restart nginx
Copy

1// 평소엔 일반 권한, MFA 인증 후 AssumeRole 로 admin 역할 입기 → sudo와 정확히 같은 패턴입니다.
2
3{
4  "Version": "2012-10-17",
5  "Statement": [
6    {
7      "Sid": "AliceCanAssumeAdminRole",
8      "Effect": "Allow",
9      "Action": "sts:AssumeRole",
10      "Resource": "arn:aws:iam::123456789012:role/AdminRole",
11      "Condition": {
12        "Bool": { "aws:MultiFactorAuthPresent": "true" }
13      }
14    }
15  ]
16}
Copy