들어가며

사용자가 10명일 때는 비밀번호면 충분합니다. 팀 하나에 슬랙 채널 하나, 공유 문서 하나, 그리고 “관리자 계정은 저한테만”이라는 암묵적 약속. 하지만 사용자가 1,000명이 되고, 권한 조합이 50가지를 넘고, “영업팀은 자기 팀 사용자만 관리할 수 있어야 해” 같은 요구사항이 들어오면 이야기가 달라집니다. 비밀번호로는 도저히 감당할 수 없는 영역이 시작됩니다. 이 글에서는 그 영역을 다루는 프레임워크, IAM(Identity and Access Management) 의 뼈대를 잡아보겠습니다.

TL;DR

• IAM은 인증(AuthN), 인가(AuthZ), 감사(Audit) 3대 요소로 구성됩니다
• 접근 제어 모델은 DAC → MAC → RBAC → PBAC로 발전했습니다
• AWS IAM이 사실상의 표준이며, 정책 기반(PBAC) 접근 제어를 사용합니다
• 정책 평가 3원칙: 기본 거부, 명시적 거부 우선, 허용 합산

IAM의 3대 핵심 요소

IAM을 한 문장으로 정의하면 “누가(Who), 무엇을(What), 어떻게(How), 언제(When) 접근할 수 있는가”를 정의하는 프레임워크입니다. 하지만 이 정의만으로는 감이 오지 않습니다. 핵심은 IAM이 단일 기능이 아니라 세 가지 질문에 답하는 구조라는 점입니다. 각 질문은 서로 다른 시점에, 서로 다른 방식으로 검사됩니다.

아래 다이어그램은 이 세 가지 요소가 어떻게 하나의 틀 안에 들어맞는지 보여줍니다. 특히 각 박스 안의 “질문”과 그 아래의 “수단”이 어떻게 연결되는지를 주목해 주세요. 세 요소 모두가 하나의 Identity Store(사용자 정보 저장소)를 바라본다는 것도 놓치지 말아야 할 포인트입니다.

┌──────────────────────────────────────────────────────────────┐
│                       IAM (Identity & Access Management)      │
│                                                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│  │  인증 (AuthN) │  │  인가 (AuthZ) │  │  감사 (Audit) │        │
│  │              │  │              │  │              │        │
│  │ "너 누구야?"  │  │ "뭘 할 수 있어?"│  │ "뭘 했어?"   │        │
│  │              │  │              │  │              │        │
│  │ · 비밀번호    │  │ · 권한 정책    │  │ · 접근 로그   │        │
│  │ · MFA        │  │ · 역할 (Role) │  │ · 변경 이력   │        │
│  │ · SSO        │  │ · 범위 (Scope)│  │ · 컴플라이언스│        │
│  └──────────────┘  └──────────────┘  └──────────────┘        │
│          │                │                │                  │
│          └────────────────┼────────────────┘                  │
│                           ▼                                    │
│              ┌─────────────────────┐                          │
│              │  Identity Store     │                          │
│              │  (AD / LDAP / DB)   │                          │
│              └─────────────────────┘                          │
└──────────────────────────────────────────────────────────────┘

이제 세 가지 요소를 하나씩 펼쳐보겠습니다.

인증 (Authentication, AuthN)

인증이 묻는 질문은 단순합니다. “너가 너라고 주장하는 사람이 맞는가?” 비밀번호가 가장 기본적인 수단이고(지식 기반 — “something you know”), 여기에 OTP나 지문을 더하면 MFA가 됩니다. SSO를 쓰면 한 번의 인증으로 여러 시스템에 진입할 수 있고, 스마트카드나 PKI 인증서는 소유 기반(“something you have”) 방식으로 물리적 보안을 더합니다.

핵심: 인증은 1회성 검사가 아닙니다. 세션이 만료되면 다시 인증해야 하고, 민감한 작업 앞에서는 재인증(step-up authentication)을 요구하기도 합니다. “로그인 한 번 = 영원한 신뢰”는 IAM에서 통하지 않습니다.

인가 (Authorization, AuthZ)

인가는 “인증된 사용자가 어떤 작업을 할 수 있는가?”를 결정합니다. 여기서 중요한 점은 인가 방식이 하나가 아니라는 것입니다. 역할 기반(RBAC), 정책 기반(PBAC), 속성 기반(ABAC) 등 여러 모델이 있으며, 각 모델은 “얼마나 세밀하게 권한을 표현할 수 있는가”에서 차이가 납니다. 이 차이는 이 글 후반부의 핵심 주제입니다.

감사 (Audit)

감사는 “누가 언제 무엇을 했는가?”를 기록하고 추적합니다. 접근 로그(로그인 성공/실패, API 호출), 변경 이력(생성/수정/삭제의 before/after), 그리고 SOC2, ISO 27001, GDPR 같은 컴플라이언스 요구사항이 여기에 해당합니다. 감사는 사후 검증이라서 “있으면 좋은 것”이 아니라, 규제 대상 시스템에서는 법적 의무입니다.

세 요소를 따로 보면 각각 명확해 보입니다. 하지만 실제 시스템에서는 인증과 인가가 헷갈리기 쉬운 지점이 있습니다. 이 둘을 명확하게 구분하지 못하면 보안 사고의 원인이 됩니다. 그래서 먼저 이 차이부터 짚고 넘어가겠습니다.

인증 vs 인가 — 명확한 차이

인증과 인가는 자주 혼용되지만, 검사하는 시점과 실패했을 때의 결과가 완전히 다릅니다. 인증은 요청이 시작될 때 한 번 수행되지만, 인가는 모든 요청마다 정책을 평가합니다. 또한 인가는 정책이 바뀌면 즉시 반영되지만, 인증은 세션이나 토큰이 살아있는 동안 유효합니다.

아래 표는 이 두 개념을 5가지 기준으로 비교한 것입니다. 특히 “실패 시” 행을 주목해 주세요. HTTP 상태 코드의 이름이 역사적 이유로 헷갈리게 지어져 있어서, 실무에서 가장 많이 발생하는 혼란의 원인이 됩니다.

핵심: 401 Unauthorized는 이름과 달리 인증 실패입니다. 403 Forbidden이 진짜 인가(권한) 실패입니다. HTTP 상태 코드 이름이 역사적 실수라서 생긴 혼란이지만, 이 구분을 모르면 디버깅 시간이 배로 듭니다.

인가가 이렇게 중요하다면, “어떤 방식으로 권한을 정의할 것인가”가 곧 시스템 보안의 척도가 됩니다. 그리고 그 방식은 수십 년에 걸쳐 진화해 왔습니다. 이 발전 과정을 따라가 보면, 왜 오늘날 PBAC가 표준이 되었는지 자연스럽게 이해할 수 있습니다.

접근 제어 모델의 발전

권한 관리는 1980년대부터 지금까지 끊임없이 진화해 왔습니다. 처음에는 파일 소유자가 권한을 마음대로 주는 방식(DAC)에서 출발했고, 군사/정부 시스템에서는 보안 분류를 시스템이 강제하는 방식(MAC)을 썼습니다. 90년대에 들어서면서 역할별로 권한을 묶는 RBAC가 등장했고, 2010년대 이후로는 정책 문서로 세밀하게 제어하는 PBAC가 주류가 되었습니다.

아래 타임라인은 네 가지 모델이 각각 어떤 철학을 바탕으로 권한을 다루는지 한눈에 보여줍니다. 각 모델의 “누가 권한을 결정하는가”와 “유연성 수준”이 어떻게 달라지는지에 집중해 주세요. 오른쪽으로 갈수록 제어의 주체가 사람에서 정책 문서로 옮겨가는 흐름이 핵심입니다.

DAC (1980년대)         MAC (1980년대)         RBAC (1990년대)        PBAC (2010년대)
━━━━━━━━━━━━━━━       ━━━━━━━━━━━━━━━       ━━━━━━━━━━━━━━━       ━━━━━━━━━━━━━━━
임의 접근 제어          강제 접근 제어          역할 기반 접근 제어      정책 기반 접근 제어

소유자가 권한 부여       시스템이 강제 분류      역할별 권한 그룹화      정책 문서로 세밀 제어
("파일 주인이 결정")    ("기밀/대외비 분류")   ("관리자/사용자")     ("AWS IAM")

유연하지만 위험         보수적, 관리 힘듦       중간 수준 유연성        최고 수준 유연성

RBAC의 한계, 그리고 PBAC

RBAC는 직관적입니다. “Help Desk 역할”에 “사용자 관리 권한”을 묶어두면, 그 역할을 가진 사람은 누구나 사용자를 관리할 수 있습니다. 역할이 4개(super_admin, user_admin, auditor, viewer) 정도면 충분해 보입니다.

하지만 현실에서는 “영업팀 OU의 사용자만 관리할 수 있는 헬프데스크” 같은 요구사항이 생깁니다. RBAC는 역할에 권한을 묶을 뿐, “어떤 대상에 대해”인지까지는 표현하지 못합니다. RBAC로 이 요구사항을 맞추려면 역할을 “영업팀 헬프데스크”, “마케팅팀 헬프데스크” 식으로 무한정 늘려야 하고, 결국 역할 폭발(role explosion)에 빠집니다.

PBAC를 선택한 이유는, 정책 파일만 수정하면 권한이 즉시 변경되기 때문입니다. 코드를 고치거나 시스템을 재배포할 필요 없이, JSON 정책 문서의 resource 패턴이나 condition만 바꾸면 “영업팀 사용자만”, “업무 시간에만”, “특정 IP에서만” 같은 조건을 모두 표현할 수 있습니다.

아래 표는 실무에서 자주 발생하는 요구사항을 RBAC와 PBAC로 각각 처리했을 때의 차이입니다. “O”와 “X”보다, X인 항목을 RBAC에서 해결하려면 무엇을 희생해야 하는지(코드 수정, 역할 추가 등)를 보는 것이 중요합니다.

이 표가 보여주듯, RBAC는 정적인 역할 할당에만 강하고, PBAC는 정책 평가 시점에 다양한 조건을 조합할 수 있습니다. 하지만 PBAC의 진짜 힘은 “유연하다”는 데 있는 게 아니라, 정책을 어떻게 평가하는가에 있습니다. 그 평가 규칙이야말로 PBAC를 채택하는 모든 시스템(AWS IAM 포함)이 공통으로 따르는 핵심입니다. 마지막으로 그 규칙을 살펴보겠습니다.

정책 평가 3원칙

PBAC 기반 시스템이 권한을 판단할 때 따르는 규칙은 놀랍도록 단순합니다. 단 세 가지입니다. 하지만 이 세 가지의 조합이 어떻게 “안전한 기본값”과 “세밀한 예외”를 동시에 만들어내는지 이해하면, IAM 정책을 읽는 눈이 달라집니다.

먼저 세 원칙을 나열하겠습니다.

1. 기본 거부 (Default Deny): 명시적으로 허용하지 않으면 모두 거부합니다. 즉 “화이트리스트 방식”입니다. 이 원칙을 채택한 이유는, 실수로 빠진 권한은 거부되는 것이 안전하기 때문입니다. 블랙리스트 방식은 “빠진 항목이 곧 보안 구멍”이 되지만, 기본 거부는 그 반대입니다.
2. 명시적 거부 우선 (Explicit Deny wins): 여러 정책 중 하나라도 Deny가 있으면 무조건 거부합니다. Allow가 아무리 많아도 Deny 하나가 모두 덮어씁니다. 이 원칙 덕분에 “보안 담당자가 안전장치를 걸어두면, 다른 정책이 실수로 권한을 열어도 막을 수 있습니다.”
3. 허용 합산 (Allow accumulation): 여러 정책의 Allow는 합산됩니다. “그룹 정책으로 기본 권한을 주고, 개인 정책으로 추가 권한을 주는” 구조가 가능한 것은 이 원칙 덕분입니다.

핵심: 이 세 원칙의 순서가 중요합니다. 먼저 “기본 거부”로 모든 것을 닫고, “허용 합산”으로 필요한 만큼 열고, “명시적 거부”로 예외를 다시 닫습니다. 열고 닫는 방향이 명확하기 때문에 정책이 복잡해져도 결과를 예측할 수 있습니다.

이 원칙들이 실제로 어떻게 작동하는지, Help Desk 정책과 보안 강화 정책이 충돌하는 상황을 보겠습니다. 정책 1은 “사용자 관리 전체 허용”, 정책 2는 “관리자 계정 삭제는 금지”입니다. 같은 사용자가 두 정책을 모두 가질 때, 관리자 계정 삭제 요청이 들어오면 어떻게 되는지 주의 깊게 따라가 주세요.

// 정책 1: Help Desk (그룹 정책) — 사용자 관리 전체 허용
{ "effect": "Allow", "action": ["users:*"], "resource": "*" }

// 정책 2: 보안 강화 (사용자 정책) — 관리자 계정 삭제 금지
{ "effect": "Deny", "action": ["users:Delete"],
  "resource": "cn=Administrator,*" }

// 요청: "users:Delete" on "cn=Administrator,..."
// 평가: 정책1 Allow 매칭 → 정책2 Deny 매칭 → 결과: DENY

정책 1의 Allow가 매칭되더라도, 정책 2의 Deny가 우선합니다. 결과는 DENY입니다. 이것이 “명시적 거부 우선” 원칙의 힘입니다. 보안 담당자가 한 줄의 Deny 정책을 추가하면, 다른 팀이 실수로 과도한 Allow를 줘도 치명적인 작업은 막을 수 있습니다.

AWS IAM은 이 평가 모델을 그대로 사용하는 대표적인 시스템입니다. 아래는 AWS IAM의 전체 구성요소를 정리한 다이어그램으로, Principal(주체)과 Policy(정책)가 어떻게 조합되어 Permission(권한)을 만드는지 보여줍니다. Policy 안의 Effect, Action, Resource, Condition 네 가지 필드가 위에서 본 평가 원칙의 재료가 됩니다.

┌─────────────────────────────────────────────────────────────┐
│                     AWS IAM 구성요소                         │
│                                                             │
│  Principal (주체)                                           │
│  ├── User    — 사람                                        │
│  ├── Group   — 사용자 그룹 (Admins, Developers)             │
│  └── Role    — 임시 역할                                    │
│                                                             │
│  Policy (정책) — JSON 문서                                  │
│  {                                                          │
│    "Effect": "Allow",                                      │
│    "Action": ["s3:GetObject", "s3:ListBucket"],             │
│    "Resource": "arn:aws:s3:::my-bucket/*",                  │
│    "Condition": {"IpAddress": {"aws:SourceIp": "10.0.0.0/8"}}│
│  }                                                          │
│                                                             │
│  Permission (권한) = Policy + Resource + Condition           │
└─────────────────────────────────────────────────────────────┘

마치며

IAM을 처음 공부할 때는 용어가 너무 많아 막막했습니다. 인증과 인가, RBAC와 PBAC, 정책과 권한, 역할과 스코프. 하지만 파고들수록 이 모든 것이 결국 세 가지 질문—”너 누구야?”, “뭘 할 수 있어?”, “뭘 했어?”—을 정확하게 답하기 위한 장치라는 것을 깨달았습니다. 그리고 그 질문들 사이의 관계, 특히 인가 모델이 단순한 역할 할당에서 정책 기반 평가로 진화한 흐름이 핵심이었습니다.

가장 인상적이었던 것은 “기본 거부” 원칙입니다. 처음에는 “왜 일부러 다 막고 시작하지?” 싶었는데, 이것이야말로 보안 설계의 철학이라는 걸 알게 됐습니다. 실수는 항상 일어납니다. 정책을 빼먹을 수도 있고, 권한을 과하게 줄 수도 있습니다. 하지만 기본값이 “거부”라면, 실수의 결과는 “좀 더 불편한 사용자”지 “뚫린 보안”이 아닙니다. 열기 어렵고 닫기 쉬운 시스템이 안전한 시스템이라는 단순한 진리를 정책 평가 원칙 안에서 만났습니다.

독자 여러분에게 전하고 싶은 통찰은 하나입니다. IAM은 “권한을 잘 나누는 기술”이 아니라 “기본을 닫고, 필요한 만큼만 여는 원칙” 입니다. RBAC에서 PBAC로 넘어간 이유도, 명시적 거부가 Allow보다 우선하는 이유도, 모두 같은 방향을 향합니다. 다음 글에서는 이 원칙을 바탕으로 PBAC와 RBAC를 직접 비교하며, 정책 엔진을 어떻게 설계하는지 더 깊이 들어가겠습니다.

다음 글: IAM & 보안 (2) PBAC vs RBAC — 정책 기반 접근 제어 설계