기업의 접근통제는 로그인 화면에서 시작하지만 로그인만으로 끝나지 않는다. 직원이 입사하면 업무에 필요한 계정을 만들어야 하고, 부서나 담당 업무가 바뀌면 권한도 함께 변경되어야 한다. 퇴직하거나 계약이 종료되면 더 이상 필요하지 않은 접근권한을 신속하게 회수해야 한다.
이 과정을 체계적으로 관리하는 것이 IAM(Identity and Access Management)이다. IAM은 단순한 계정관리 시스템이나 SSO 솔루션을 의미하지 않는다. 사용자와 시스템의 Identity를 관리하고, 누가 어떤 자원에 어느 수준까지 접근할 수 있는지를 전체 수명주기 동안 통제하는 체계라고 보는 것이 정확하다.
NIST의 최신 Digital Identity Guidelines인 SP 800-63-4는 디지털 신원관리 영역을 신원확인, 인증, 인증수단 관리, 연합(Federation) 등의 구조로 다룬다. Microsoft의 Identity Governance 역시 Identity Lifecycle, Access Lifecycle, Privileged Access Lifecycle을 주요 관리 영역으로 구분한다.
1. IAM의 기본 개념
IAM은 Identity and Access Management의 약자다. 핵심은 누가 → 어떤 자원에 → 어떤 권한으로 → 언제까지 접근할 수 있는가라는 질문으로 정리할 수 있다.
여기서 Identity는 회사 직원만 의미하지 않는다. 임직원뿐 아니라 계약직, 협력사 직원, 고객, 관리자 계정, 서비스 계정, 애플리케이션, 서버 워크로드 등도 접근권한을 가진 Identity가 될 수 있다.
예를 들어 직원 한 명이 입사하면 그룹웨어, 메일, ERP, VPN, 파일서버, 클라우드 서비스 등 여러 시스템에 접근해야 할 수 있다. 모든 계정을 시스템 담당자가 각각 생성하고 권한을 수작업으로 부여한다면 사용자가 늘어날수록 누락과 오류 가능성도 커진다.
IAM은 이런 Identity와 접근권한을 일정한 정책과 절차에 따라 관리할 수 있도록 한다. Microsoft는 Identity Governance를 설명하면서 기업이 지속적으로 확인해야 할 문제를 어떤 Identity가 어떤 Resource에 접근해야 하는지, 그 접근권한을 어떻게 관리하고 검증할 것인지의 관점으로 제시한다.
2. 인증과 인가의 차이
IAM을 이해할 때 가장 먼저 구분해야 하는 개념이 인증(Authentication)과 인가(Authorization)다.
인증 Authentication
인증은 사용자가 자신이 주장하는 Identity가 맞는지 확인하는 과정이다. 비밀번호, OTP, 인증 애플리케이션, 보안키, 생체인증, 인증서, Passkey 등이 대표적인 인증수단이다.
인가 Authorization
인가는 인증된 사용자가 어떤 시스템이나 데이터에서 어떤 작업까지 할 수 있는지를 결정하는 과정이다. 같은 ERP에 로그인했더라도 일반 직원과 재무 담당자의 권한은 서로 다를 수 있다.
| 구분 | 인증 | 인가 |
|---|---|---|
| 영어 | Authentication | Authorization |
| 핵심 질문 | 누구인가 | 무엇을 할 수 있는가 |
| 대표 기술 | Password, MFA, Passkey | Role, Group, Policy |
| 목적 | 신원 확인 | 접근권한 결정 |
| 실패 시 | 로그인 거부 | 특정 자원·기능 접근 거부 |
인증이 강력하다고 권한관리까지 안전한 것은 아니다. MFA를 적용한 계정이라도 불필요한 관리자 권한을 가지고 있다면 계정이 탈취됐을 때 피해 범위가 커질 수 있다. 따라서 IAM에서는 인증과 인가를 별개의 통제로 관리해야 한다.
3. 기업 IAM을 구성하는 핵심 요소
Identity 관리
사용자의 이름, 사번, 소속, 직무, 재직 상태 같은 정보를 관리한다. 임직원의 경우 인사시스템이 Identity 기준 정보의 원천(Source of Truth)이 되는 경우가 많다.
Provisioning과 Deprovisioning
Provisioning은 필요한 시스템에 계정을 생성하고 접근권한을 제공하는 과정이며, Deprovisioning은 필요하지 않은 계정을 비활성화하거나 삭제하는 과정이다. 계정을 빠르게 만드는 기능만큼 사용이 끝난 계정을 정확하게 제거하는 기능도 중요하다.
Authentication과 Authorization
Authentication은 사용자의 Identity를 확인하고 Authorization은 인증된 사용자에게 어떤 Resource와 기능을 사용할 수 있는지 결정한다.
Access Review
이미 부여된 권한이 계속 필요한지 다시 확인하는 과정이다. Microsoft Entra Access Reviews는 그룹, 애플리케이션, 역할 등에 대한 접근권한을 검토하고 필요하지 않은 접근을 제거할 수 있도록 지원한다. 한 번 승인된 권한이 영구적으로 필요하다는 보장은 없기 때문에 정기적인 재검토가 필요하다.
4. 계정과 접근권한의 수명주기
IAM 실무에서는 Identity Lifecycle을 흔히 Joiner–Mover–Leaver, 즉 JML 관점으로 설명한다.
Joiner — 입사
직원이 입사하면 Identity가 생성되고 업무에 필요한 계정과 권한이 제공된다. 기본 흐름은 인사정보 등록 → Identity 생성 → 기본 계정 생성 → 업무 기준 권한 부여 → 시스템 접근이다. 신속성과 최소권한을 함께 고려해야 한다.
Mover — 조직·업무 변경
조직 이동에서는 새로운 권한은 추가되지만 기존 부서에서 사용하던 권한이 남기 쉽다. 이런 상황이 반복되면 사용자의 권한이 계속 누적된다. 따라서 Mover 관리에서는 신규 권한 부여 + 기존 불필요 권한 회수가 함께 이루어져야 한다.
Leaver — 퇴직·계약 종료
퇴직자는 메일, VPN, ERP, 클라우드, SaaS 등 모든 접근경로에서 권한을 제거해야 한다. 중앙 계정만 비활성화해도 별도의 SaaS 계정, 로컬 계정, API Key 등이 남을 수 있기 때문에 퇴직 이벤트와 시스템별 Deprovisioning 대상을 연결해야 한다.
5. RBAC와 최소권한 원칙
모든 사용자에게 권한을 하나씩 지정하면 관리 복잡도가 증가한다. 이를 줄이기 위해 많이 사용하는 방식이 RBAC(Role-Based Access Control)다.
RBAC에서는 사용자에게 개별 권한을 직접 할당하기보다 업무 역할에 필요한 Permission을 Role에 묶어 관리한다. 예를 들면 사용자 → 재무 담당자 Role → 재무 조회·결재 권한과 같은 구조다.
최소권한 원칙
IAM에서 함께 적용해야 하는 핵심 원칙이 Least Privilege다. 사용자는 업무를 수행하는 데 필요한 최소 수준의 권한만 가져야 한다. AWS도 IAM 보안 모범사례에서 특정 업무에 필요한 권한만 부여하고 사용하지 않는 사용자, Role, Permission, Credential을 정기적으로 검토해 제거할 것을 권고한다.
실무에서는 ‘최소’라는 말 자체보다 어떤 권한까지가 실제 업무에 필요한지 판단하는 일이 어렵다. 최소권한은 한 번 정해 끝나는 설정값이 아니라 지속적으로 조정해야 하는 운영 원칙이다.
7. IAM 운영에서 실제로 어려운 부분
권한 기준은 IAM 제품이 결정하지 않는다
IAM 시스템은 설정된 정책을 실행할 수 있지만 특정 직무에 어떤 권한이 필요한지를 스스로 결정하지는 못한다. 현업이나 Resource Owner가 업무 필요성을 판단하고, 보안 조직은 통제 기준을 정하며, IT·IAM 운영자는 이를 시스템에 구현하는 역할 분담이 필요하다.
예외 권한이 계속 발생한다
프로젝트, 겸직, 직무대행, 외부 협력처럼 기본 Role만으로 처리하기 어려운 상황이 발생한다. 예외 권한을 영구적으로 제공하기보다 승인자, 사용 목적, 만료 시점을 함께 관리하는 것이 좋다.
권한 부여보다 회수가 어렵다
새로운 시스템이 필요한 사용자는 직접 권한을 요청하지만 더 이상 필요하지 않은 권한을 스스로 신고하는 경우는 많지 않다. 그래서 신규 권한 부여만큼 Access Review와 자동 회수 기능이 중요하다.
8. 기업에서 확인해야 할 IAM 운영 기준
Identity 기준정보가 명확한가
임직원의 재직 상태와 조직정보를 어떤 시스템에서 최종 판단하는지 명확해야 한다. 인사시스템, AD, IAM의 정보가 서로 다르면 자동화에서도 오류가 발생할 수 있다.
권한 승인 책임자가 명확한가
Resource Owner나 업무 책임자가 권한의 업무상 필요성을 판단하고 보안·IT 조직이 정책과 기술적 통제를 지원하는 구조가 필요하다.
조직 이동 시 기존 권한을 확인하는가
Mover 관리에서는 새로운 권한뿐 아니라 이동 전에 사용하던 Role과 예외 권한까지 함께 확인해야 한다.
고권한 계정을 별도로 관리하는가
관리자 권한에는 별도 계정, 강화된 인증, 승인, 사용기록 등의 통제를 적용할 필요가 있다.
접근권한을 정기적으로 재검토하는가
처음에는 적절했던 권한도 시간이 지나면 필요하지 않을 수 있다. Joiner·Mover·Leaver 자동화와 함께 정기적인 Access Review가 필요하다.
사람 이외의 Identity도 관리하는가
서비스 계정, API, 자동화 도구, 애플리케이션도 실제 시스템 권한을 가질 수 있다. IAM을 임직원 계정만의 문제로 보면 Non-Human Identity가 관리 사각지대가 될 수 있다.
결론: IAM의 핵심은 로그인보다 접근권한의 전체 수명주기다
IAM을 로그인 시스템으로만 이해하면 SSO나 MFA 도입이 목표가 되기 쉽다. 하지만 실제 기업 IAM은 사용자가 조직에 들어올 때 권한을 제공하고, 업무가 변경되면 조정하며, 조직을 떠나면 접근을 제거하는 전체 과정을 다룬다.
IAM의 전체 흐름은 Identity 생성 → 인증 → 권한 부여 → 사용 → 검토 → 변경·회수로 볼 수 있다.
기술적인 자동화는 이 과정을 빠르고 일관되게 만드는 수단이다. 그러나 누가 어떤 자원에 어떤 권한을 가져야 하는지에 대한 기준은 기업의 업무와 책임체계에서 결정된다.
결국 잘 운영되는 IAM은 계정을 많이 자동화한 시스템이 아니라 필요한 Identity에 필요한 권한을 필요한 기간 동안만 제공하고, 필요성이 끝나면 정확하게 회수할 수 있는 접근관리 체계다.