IAM

주체는 IAM 시스템에서 권한을 행사할 수 있는 모든 엔티티를 가리킨다. 일반적으로 사용자, 애플리케이션, 서비스 계정, 또는 가상 머신과 같은 자원이 주체가 될 수 있다. 주체는 시스템에 접근을 요청하는 주체적 존재이다.

자격 증명은 주체의 신원을 시스템에 증명하기 위해 사용되는 정보 또는 객체이다. 가장 일반적인 형태는 사용자명과 비밀번호의 조합이다. 그 외에도 디지털 인증서, API 키, 생체 인증 데이터 등이 자격 증명으로 활용된다. 자격 증명은 인증 과정에서 제시되어 주체의 신원을 검증받는다.

주체와 자격 증명의 관계는 다음과 같이 요약할 수 있다.

자격 증명의 관리와 보호는 IAM 보안의 핵심이다. 약한 자격 증명이나 노출된 자격 증명은 시스템에 대한 무단 접근의 주요 경로가 된다. 따라서 강력한 암호 정책, 다중 인증 적용, 자격 증명 회전과 같은 관행이 필수적이다.

인증은 주체가 자신이 주장하는 신원이 맞는지 확인하는 과정이다. 일반적으로 사용자 이름과 비밀번호, 생체 인증, 또는 보안 토큰과 같은 자격 증명을 검증하는 방식으로 이루어진다. 인증이 성공하면 시스템은 해당 주체의 신원을 신뢰하게 되고, 이후 접근 제어 결정의 기초가 된다.

반면, 권한 부여는 인증된 주체가 특정 리소스에 대해 어떤 작업(예: 읽기, 쓰기, 삭제)을 수행할 수 있는지 결정하는 과정이다. 권한 부여는 "이 사용자는 무엇을 할 수 있는가?"라는 질문에 답한다. 이 결정은 일반적으로 사전에 정의된 정책이나 역할에 기반하여 이루어진다.

두 개념은 밀접하게 연관되어 있지만 명확히 구분된다. 인증 없이는 권한 부여가 불가능하며, 인증은 권한 부여의 필수 선행 단계이다. 이를 일상적인 예로 비유하면, 인증은 건물 출입증을 확인하는 절차이고, 권한 부여는 그 출입증을 가진 사람이 특정 층이나 방에 들어갈 수 있는지 결정하는 규칙이다.

효율적인 IAM 시스템은 이 두 메커니즘을 명확히 분리하여 설계한다. 이는 보안 강화, 관리 편의성 증대, 그리고 최소 권한 원칙을 준수하는 데 기여한다. 인증과 권한 부여의 분리는 시스템이 신원 확인과 접근 권한 평가를 독립적으로 처리할 수 있게 하여, 보다 유연하고 안전한 접근 제어를 가능하게 한다.

정책은 IAM에서 권한 부여를 정의하는 기본 단위이다. 정책은 하나 이상의 권한을 포함하는 문서로, 어떤 주체가 어떤 자원에 대해 어떤 액션을 수행할 수 있는지를 명시한다. 정책은 일반적으로 JSON이나 YAML 형식으로 작성되며, 효과(Allow 또는 Deny), 액션(예: s3:GetObject), 자원(예: arn:aws:s3:::example-bucket/*), 조건(선택 사항) 등의 요소로 구성된다. 정책은 직접 사용자나 그룹에 연결되거나, 역할을 통해 간접적으로 할당된다.

역할은 특정 권한 집합을 가진 IAM 엔터티이다. 사용자와 달리 역할은 특정 개인이나 애플리케이션에 고정되지 않으며, 필요할 때 자격 증명을 가진 주체가 수임(Assume)할 수 있다. 역할은 신뢰 정책(어떤 주체가 이 역할을 수임할 수 있는지 정의)과 권한 정책(역할이 가지는 권한을 정의)으로 구성된다. 이는 최소 권한 원칙을 적용하고, 장기적인 자격 증명 사용을 피하는 데 유용하다. 예를 들어, EC2 인스턴스가 S3 버킷에 접근해야 할 때, 인스턴스에 액세스 키를 저장하는 대신 적절한 권한을 가진 역할을 부여한다.

정책과 역할의 관계는 권한을 부여하는 메커니즘에서 명확히 드러난다. 아래 표는 주요 차이점을 보여준다.

역할은 특히 클라우드 컴퓨팅 환경에서 중요한 구성 요소이다. AWS, Azure, Google Cloud와 같은 퍼블릭 클라우드 제공자는 서비스 간 접근을 안전하게 위임하거나, 다른 계정의 사용자나 애플리케이션에게 임시 권한을 부여하기 위해 역할 기반 모델을 광범위하게 사용한다. 이는 정적이고 장기적인 자격 증명의 사용을 최소화하여 보안 위험을 줄인다.

사용자는 IAM 시스템에서 가장 기본적인 주체 중 하나로, 시스템이나 서비스에 접근하는 개별 실체를 의미한다. 사용자는 일반적으로 사람을 나타내지만, 애플리케이션 또는 서비스 계정과 같은 비인간 실체도 포함될 수 있다. 각 사용자는 시스템 내에서 고유한 자격 증명(예: 사용자 이름과 비밀번호)을 부여받아 자신의 신원을 증명한다.

사용자 계정은 보통 다음과 같은 속성 정보를 포함한다.

사용자에게 권한을 부여하는 방식은 크게 두 가지이다. 첫째, 정책을 사용자에게 직접 연결하는 방식이다. 둘째, 더 권장되는 방식으로, 사용자를 그룹에 포함시키고 해당 그룹에 정책을 부여하는 것이다. 그룹을 통한 권한 관리는 사용자 수가 많아질수록 효율성을 높이고 관리 복잡도를 줄이는 데 유리하다. 또한, 사용자 계정의 생성, 권한 변경, 비활성화, 삭제를 포함한 라이프사이클 관리는 보안과 규정 준수의 핵심 요소이다.

그룹(Group)은 IAM에서 사용자(User)를 논리적으로 묶어 관리 효율성을 높이는 컨테이너 객체이다. 개별 사용자에게 정책(Policy)을 직접 부여하는 대신, 그룹에 정책을 연결하면 해당 그룹의 모든 구성원에게 일괄적으로 권한이 적용된다. 이 방식은 사용자 수가 많거나 조직 구조가 복잡할 때 권한 관리의 복잡성을 크게 줄인다.

그룹의 주요 특징은 다음과 같다. 첫째, 그룹은 사용자만을 포함할 수 있으며, 다른 그룹이나 역할(Role)을 포함할 수 없다. 둘째, 한 사용자는 여러 그룹에 동시에 소속될 수 있어 다양한 직무 권한을 조합하여 부여받을 수 있다. 이때 사용자의 최종 권한은 소속된 모든 그룹의 정책이 합쳐진 형태로 결정된다. 셋째, 그룹 자체는 자격 증명을 가지지 않아 직접 리소스에 접근할 수 없으며, 순수하게 권한 관리의 논리적 단위로만 기능한다.

일반적인 그룹 관리의 라이프사이클은 아래 표와 같다.

그룹을 효과적으로 활용하면 신규 직원 온보딩 시 적절한 그룹에만 추가하면 필요한 모든 시스템 접근 권한이 부여되어 관리 부담이 감소한다. 또한, 직무 변경이나 퇴사 시 해당 사용자를 그룹에서 제거하는 것만으로도 관련 권한이 일괄 철회되어 보안성을 강화한다. 대부분의 IAM 시스템은 이러한 그룹 기반 관리를 핵심 기능으로 제공한다.

역할은 사용자(User)나 애플리케이션 등 특정 주체(Principal)에게 일시적으로 할당되는 권한의 집합이다. 사용자와 달리 역할은 자격 증명(비밀번호나 액세스 키)을 직접 소유하지 않으며, 필요할 때 위임받아 사용하는 임시 권한의 개념이다. 이는 최소 권한 원칙을 구현하는 핵심 메커니즘으로, 주체가 항상 모든 권한을 가지는 것이 아니라 작업 수행 시에만 필요한 권한을 역할을 통해 획득한다.

역할은 일반적으로 하나 이상의 정책(Policy)에 연결되어 있으며, 이 정책들이 역할이 수행할 수 있는 구체적인 작업(예: 특정 S3 버킷 읽기, EC2 인스턴스 시작하기)을 정의한다. 역할은 사용자, 그룹(Group), 서비스, 혹은 외부 인증을 받은 주체에게 할당될 수 있다. 클라우드 환경에서는 한 AWS 계정의 역할이 다른 AWS 계정의 사용자에게 할당되거나, AWS Lambda 같은 서비스가 다른 서비스의 리소스에 접근하기 위해 역할을 수임하는 방식으로 활용된다.

역할 기반 접근 제어의 주요 이점은 권한 관리의 중앙화와 간소화에 있다. 개별 사용자에게 직접 권한을 부여하는 대신, '관리자', '감사자', '개발자'와 같은 업무 기능에 맞는 역할을 미리 정의하고 사용자에게 역할을 할당한다. 이렇게 하면 직무 변경 시 사용자의 모든 개별 권한을 수정할 필요 없이 역할 할당만 변경하면 되므로 관리 효율성이 크게 향상된다. 또한 역할은 임시 보안 자격 증명을 사용하기 때문에 장기적인 액세스 키 관리에 따른 보안 위험을 줄일 수 있다[1].

정책은 IAM 시스템에서 권한 부여를 정의하는 기본 단위이다. 정책은 하나 이상의 권한을 포함하는 문서 형식으로, 어떤 주체가 어떤 자원에 대해 어떤 액션을 수행할 수 있는지를 명시적으로 규정한다. 정책은 일반적으로 JSON이나 YAML과 같은 구조화된 형식으로 작성되며, 특정 조건이 충족될 때만 권한이 부여되도록 구성할 수 있다.

정책의 핵심 구조는 주로 '효과(Effect)', '액션(Action)', '자원(Resource)', 그리고 선택적으로 '조건(Condition)'으로 구성된다. '효과'는 해당 문장이 접근을 허용(Allow)할지 거부(Deny)할지를 결정한다. '액션'은 허용되거나 거부될 특정 작업(예: 읽기, 쓰기, 삭제)을 나열한다. '자원'은 정책이 적용될 구체적인 대상을 지정한다. '조건'은 정책이 적용되기 위해 충족되어야 하는 추가적인 기준을 정의한다[2].

정책은 크게 두 가지 유형으로 분류된다. 첫째는 관리형 정책으로, 독립적인 정책 문서로서 사용자, 그룹, 역할에 직접 연결(Attach)하여 사용한다. 둘째는 인라인 정책으로, 특정 사용자, 그룹 또는 역할에 직접 포함되어 생성되는 정책이다. 관리형 정책은 재사용성이 높고 중앙 집중식 관리가 용이한 반면, 인라인 정책은 해당 정책이 오직 하나의 주체에만 연결된다는 특징이 있다.

정책 평가는 일반적으로 명시적 거부가 암시적 허용보다 우선하는 원칙을 따른다. 시스템은 요청된 액션에 대해 관련된 모든 정책을 평가하며, 하나라도 명시적인 'Deny'가 존재하면 접근이 거부된다. 'Allow'가 하나도 존재하지 않으면 암시적으로 거부된다. 이는 최소 권한 원칙을 구현하고 보안을 강화하는 데 기여한다.

역할 기반 접근 제어(RBAC)는 사용자 개인에게 직접 권한을 부여하는 대신, 사전에 정의된 역할(Role)에 권한을 할당하고 사용자에게 해당 역할을 부여하는 방식의 접근 제어 모델이다. 이 모델에서 사용자의 접근 권한은 사용자가 맡은 직무나 책임에 따라 결정된다. 예를 들어, '재무 관리자' 역할에는 재무 보고서 조회 및 승인 권한이 할당되고, 해당 직무를 가진 사용자에게 그 역할이 부여된다.

RBAC의 핵심 구성 요소는 사용자(User), 역할(Role), 권한(Permission), 세션(Session)이다. 권한은 역할에 할당되고, 사용자는 하나 이상의 역할을 부여받는다. 사용자가 시스템에 로그인하면 세션이 생성되며, 이 세션을 통해 활성화된 역할에 해당하는 권한을 행사할 수 있다. 이 구조는 권한 관리의 복잡성을 줄여준다. 새로운 직원이 입사하면 개별 권한을 일일이 설정하지 않고, 해당 직무에 맞는 역할을 할당함으로써 효율적으로 접근 권한을 부여할 수 있다.

RBAC는 일반적으로 계층 구조를 지원한다. 상위 역할은 하위 역할의 권한을 상속받을 수 있어 조직의 보고 구조를 반영한 권한 관리가 가능하다. 또한, 최소 권한의 원칙을 쉽게 적용할 수 있어 보안성을 강화한다. 사용자에게 작업 수행에 필요한 최소한의 권한만을 역할을 통해 부여함으로써, 권한 남용이나 오용의 위험을 줄인다.

이 모델은 중앙 집중식 권한 관리와 감사 추적의 용이성으로 인해 기업 환경에서 널리 채택되었다. 사용자의 직무 변경 시 여러 시스템의 권한을 개별적으로 수정할 필요 없이, 사용자에게 부여된 역할만 변경하면 되므로 관리 오버헤드가 크게 감소한다.

ABAC는 접근 제어 결정을 내리기 위해 사용자, 자원, 환경과 관련된 다양한 속성을 활용하는 모델이다. RBAC가 미리 정의된 역할에 기반한다면, ABAC는 보다 세분화되고 동적인 접근 제어가 가능하다. 이 모델은 일반적으로 "주체가 특정 조건에서 특정 자원에 대한 작업을 수행할 수 있다"는 형태의 정책 규칙으로 표현된다.

ABAC 정책은 주체 속성(예: 부서, 직급), 자원 속성(예: 파일 분류, 소유자), 동작 속성(예: 읽기, 쓰기), 그리고 환경 속성(예: 접근 시간, IP 주소, 디바이스 보안 상태)을 결합하여 평가한다. 예를 들어, "재무부 소속 사용자만이 '재무' 태그가 붙은 문서를 업무 시간에 회사 네트워크에서만 열람할 수 있다"는 규칙은 여러 속성을 조합한 전형적인 ABAC 정책이다. 이로 인해 정책 관리 포인트(PAP), 정책 결정 포인트(PDP), 정책 실행 포인트(PEP) 등으로 구성된 정책 실행 아키텍처가 필요하다.

ABAC의 주요 장점은 세분화된 제어와 상황 인식 접근 제어가 가능하다는 점이다. 새로운 자원이나 사용자가 추가될 때마다 역할을 재정의할 필요 없이, 속성 값에 따라 자동으로 접근 권한이 결정된다. 그러나 구현 복잡도가 높고, 속성 관리 체계가 잘 구축되어야 하며, 모든 정책 결정을 속성 평가에 의존하므로 성능 고려사항이 발생할 수 있다. ABAC는 XACML(eXtensible Access Control Markup Language)과 같은 표준화된 정책 언어를 통해 구현되는 경우가 많다.

PBAC은 정책을 중심으로 접근 권한을 동적으로 결정하는 접근 제어 모델이다. RBAC이 미리 정의된 역할에 권한을 부여하는 방식이라면, PBAC은 요청 시점의 다양한 속성을 평가하는 정책 규칙에 따라 권한 부여 여부를 판단한다. 이 모델은 더 세밀하고 상황에 맞는 접근 제어가 가능하다는 특징을 가진다.

PBAC 시스템의 핵심은 정책 결정 지점(PDP)과 정책 집행 지점(PEP)의 분리 구조에 있다. 사용자의 접근 요청이 발생하면 PEP는 요청을 가로채 관련 정보(주체, 자원, 행동, 환경 속성 등)를 수집하여 PDP로 전달한다. PDP는 미리 정의된 정책 규칙 집합을 평가하여 '허용' 또는 '거부' 결정을 내리고, PEP는 이 결정을 실행하여 접근을 허용하거나 차단한다. 이 과정에서 정책은 일반적으로 속성 기반 접근 제어의 원칙을 따르는 경우가 많아, PBAC은 종종 ABAC의 구현 프레임워크로 간주되기도 한다[4].

PBAC의 주요 장점은 유연성과 중앙 집중식 관리에 있다. 비즈니스 규칙이나 보안 요구사항이 변경될 때마다 개별 시스템의 권한을 수정할 필요 없이 중앙 정책만 업데이트하면 적용이 가능하다. 또한 시간, 위치, 장치 보안 상태와 같은 다양한 환경 속성을 정책 평가에 포함시켜 동적인 접근 제어를 구현할 수 있다. 예를 들어, '평일 오전 9시부터 오후 6시까지 회사 네트워크 내에서만 재무 데이터에 접근 가능하다'와 같은 복합적인 규칙을 정책으로 정의할 수 있다.

이 모델은 복잡한 엔터프라이즈 환경이나 클라우드 컴퓨팅 환경에서 여러 시스템에 걸쳐 일관된 접근 제어 정책을 적용해야 할 때 특히 유용하다. 그러나 정책 규칙이 복잡해질수록 관리 부담과 정책 충돌 가능성이 증가할 수 있다는 점이 도전 과제로 남아 있다.

싱글 사인온은 사용자가 한 번의 로그인 절차를 통해 여러 개의 독립된 애플리케이션이나 시스템에 접근할 수 있도록 하는 인증 메커니즘이다. 이는 사용자가 각 서비스마다 별도의 아이디와 비밀번호를 기억하고 입력해야 하는 번거로움을 해소한다. SSO는 일반적으로 중앙 집중식 인증 서버를 통해 자격 증명을 검증하고, 인증이 완료되면 다른 서비스들에 대한 접근 권한을 부여하는 토큰이나 어설션을 발급한다.

SSO의 핵심 구성 요소는 신뢰 관계를 형성하는 ID 제공자와 서비스 제공자이다. 사용자가 서비스 제공자에게 접근을 시도하면, 서비스 제공자는 사용자를 미리 정의된 ID 제공자로 리디렉션한다. ID 제공자는 사용자를 인증하고, 인증 성공 정보가 담긴 SAML 어설션이나 JWT 토큰 같은 보안 토큰을 서비스 제공자에게 전달한다. 서비스 제공자는 이 토큰을 신뢰하고 사용자에게 접근을 허용한다.

주요 구현 프로토콜로는 SAML, OAuth 2.0, OpenID Connect 등이 있다. 각 프로토콜은 서로 다른 사용 사례와 요구사항에 맞춰 설계되었다. 예를 들어, SAML은 엔터프라이즈 환경에서 널리 사용되는 반면, OAuth 2.0과 OpenID Connect는 모바일 애플리케이션과 웹 기반 서비스에 더 적합하다.

SSO 도입은 보안과 운영 효율성 측면에서 장점을 제공하지만, 단일 실패 지점이 될 수 있다는 위험도 내포한다. 따라서 SSO 시스템 자체의 보안을 강화하고, 다중 인증과 같은 추가 보안 계층을 결합하는 것이 일반적이다. 또한, 모든 애플리케이션이 동일한 인증 프로토콜을 지원하지 않을 수 있어, 페더레이션 게이트웨이를 통한 통합이 필요할 수 있다.

다중 인증은 사용자의 신원을 확인하기 위해 두 가지 이상의 독립적인 인증 요소를 요구하는 보안 메커니즘이다. 단순한 암호 입력만으로는 충분하지 않다고 판단하여, 추가적인 증명을 통해 접근을 제어한다. 이는 인증 단계의 강도를 높여, 비인가된 접근 시도를 효과적으로 차단하는 데 목적이 있다.

MFA는 일반적으로 다음 세 가지 범주의 요소 중 두 가지 이상을 조합하여 사용한다.

* 아는 것(지식 요소): 사용자만이 알고 있는 정보이다. 예를 들어 비밀번호, PIN 번호, 보안 질문의 답변이 해당된다.

* 가지고 있는 것(소유 요소): 사용자만이 물리적으로 소유한 장치나 토큰이다. 스마트폰(OTP 앱, SMS 수신), 보안 카드, 하드웨어 토큰, 스마트 카드 등이 여기에 속한다.

* 되는 것(생체 요소): 사용자 고유의 생체적 특징이다. 지문, 홍채, 안면 인식, 음성 인식 등이 대표적이다.

이 방식은 사용자의 비밀번호가 유출되더라도 공격자가 두 번째 인증 요소를 함께 획득하지 않는 한 계정에 접근할 수 없게 만든다. 따라서 피싱, 무차별 대입 공격, 자격 증명 누출 등에 의한 보안 위협을 상당히 완화한다. 많은 규정 준수 표준(예: PCI DSS, GDPR)과 기업 보안 정책에서도 중요 계정에 대한 MFA 적용을 권고하거나 의무화한다.

MFA 구현은 애플리케이션 로그인, 원격 시스템 접근, 특정 권한이 필요한 작업 실행 전 등 다양한 시점에 적용될 수 있다. 최근에는 사용자 행동 패턴, 접속 위치, 시간 등의 상황 정보를 추가적인 '맥락' 요소로 활용하는 적응형 MFA도 등장했다[5]. 이는 보안 강화와 사용자 편의성 사이의 균형을 더욱 정교하게 조정한다.

라이프사이클 관리는 사용자나 서비스 계정, 디지털 자격 증명의 생성부터 폐기까지 전 과정을 체계적으로 관리하는 IAM의 핵심 기능이다. 이는 보안 위험을 줄이고 규정 준수를 보장하며 운영 효율성을 높이는 데 목적이 있다.

일반적인 라이프사이클은 온보딩(생성), 운영 중 관리, 오프보딩(폐기)의 세 단계로 구분된다. 온보딩 단계에서는 신규 사용자나 시스템에 필요한 최소 권한을 부여하는 최소 권한의 원칙을 적용한다. 운영 중에는 직무 변경이나 프로젝트 이관에 따라 권한을 조정하거나, 정기적인 권한 검토를 통해 불필요한 권한을 회수한다. 오프보딩 단계에서는 퇴사나 계정 미사용 시 접근 권한을 즉시 철회하여 무단 접근을 방지한다.

이 과정의 자동화는 효율성과 정확성을 크게 향상시킨다. HR 시스템과의 통합을 통해 입사, 전보, 퇴사 정보를 기반으로 계정과 권한을 자동으로 생성, 변경, 비활성화할 수 있다. 또한, 일정 기간 동안 로그인 기록이 없는 휴면 계정을 자동으로 탐지하고 처리하는 정책을 설정하는 것이 일반적이다.

라이프사이클 관리는 내부 보안 정책 뿐만 아니라 GDPR, SOX, HIPAA와 같은 외부 규정 준수 요구사항을 충족시키는 데도 필수적이다. 적절한 감사 로그를 남겨 누가, 언제, 어떤 자원에 접근했는지에 대한 증적을 확보할 수 있다.

감사 및 로깅은 IAM 시스템의 투명성, 책임 추적성, 보안 사고 대응 능력을 보장하는 핵심 기능이다. 이 기능은 시스템 내에서 발생하는 모든 인증 및 권한 부여 관련 활동을 기록하고 분석하는 것을 목표로 한다. 주요 기록 대상에는 사용자 로그인 시도, 권한 변경, 정책 수정, 역할 할당, 중요한 데이터에 대한 접근 시도 등이 포함된다.

이러한 로그 데이터는 일반적으로 중앙 집중식 SIEM 시스템으로 전송되어 통합 분석된다. 로그는 보안 정책 위반, 비정상적인 접근 패턴, 내부 위협을 탐지하는 데 활용된다. 예를 들어, 한 사용자가 짧은 시간 내에 여러 차례 실패한 로그인 시도를 기록하거나, 평소와 다른 시간대나 위치에서 시스템에 접근하는 경우 의심스러운 활동으로 플래그가 지정될 수 있다.

규정 준수 측면에서 감사 로그는 GDPR, HIPAA, PCI DSS 등 다양한 보안 및 개인정보 보호 규정의 필수 요구사항이다. 조직은 법적 분쟁이나 보안 사고 발생 시, 로그를 근거로 사건의 전말을 재구성하고 책임 소재를 명확히 할 수 있다. 효과적인 감사 및 로깅 구현을 위해서는 로그의 무결성과 비수정성을 보장하고, 정의된 보존 기간 동안 안전하게 저장해야 한다.

AWS IAM은 아마존 웹 서비스 클라우드 플랫폼 내에서 접근 제어와 권한 관리를 제공하는 핵심 서비스이다. 이 서비스는 AWS 계정 내의 사용자, 그룹, 역할이 어떤 AWS 리소스에 접근할 수 있는지를 세밀하게 정의하고 관리하는 기능을 담당한다. AWS IAM의 기본 원칙은 최소 권한 원칙으로, 사용자나 애플리케이션이 자신의 작업을 수행하는 데 필요한 최소한의 권한만 부여하는 것을 강조한다.

AWS IAM의 주요 구성 요소는 사용자(User), 그룹(Group), 역할(Role), 정책(Policy)이다. IAM 사용자는 AWS 서비스와 리소스에 접근하는 개인이나 애플리케이션을 나타낸다. 사용자는 장기적인 자격 증명(사용자 이름과 비밀번호) 또는 액세스 키를 가질 수 있다. IAM 그룹은 여러 사용자를 하나의 단위로 묶어 정책을 일괄 적용하기 위해 사용된다. IAM 역할은 특정 권한 집합을 정의하며, AWS 리소스(예: EC2 인스턴스)나 외부 사용자에게 위임하는 데 사용된다. 역할은 장기 자격 증명을 부여하지 않고 임시 보안 자격 증명을 통해 접근을 허용한다. 모든 권한은 JSON 형식으로 작성된 IAM 정책 문서를 통해 명시적으로 부여된다. 정책은 특정 리소스에 대해 허용하거나 거부할 액션(API 작업)을 정의한다.

AWS IAM은 다양한 고급 기능과 통합을 제공한다. 다중 인증(MFA)을 활성화하여 계정 보안을 강화할 수 있다. AWS Organizations와 통합되어 여러 AWS 계정을 중앙에서 관리할 수 있다. 또한, AWS CloudTrail과 완전히 통합되어 IAM과 관련된 모든 API 호출을 기록하여 감사와 규정 준수를 지원한다. 정책 시뮬레이터를 사용하면 정책이 특정 요청에 대해 어떤 권한을 부여하는지 테스트해볼 수 있다.

AWS IAM의 권한 평가 로직은 명시적 거부가 모든 허용을 우선한다는 규칙을 따른다. 요청이 들어오면, 해당 주체(사용자 또는 역할)에 연결된 모든 정책을 평가한다. 요청된 액션이 하나의 정책에서라도 명시적으로 거부되면 접근이 거부된다. 거부가 없을 경우, 하나 이상의 정책에서 명시적으로 허용되어야 접근이 승인된다. 기본적으로 모든 요청은 암묵적으로 거부된 상태로 시작한다.

Azure Active Directory(Azure AD)는 마이크로소프트의 클라우드 기반 식별 및 접근 관리 서비스이다. 이 서비스는 사용자와 그룹을 관리하고, 애플리케이션에 대한 접근을 제어하며, 싱글 사인온과 다중 인증 같은 핵심 IAM 기능을 제공한다. Azure AD는 Microsoft 365, Azure 포털, 수천 개의 SaaS 애플리케이션을 포함한 다양한 리소스에 대한 인증과 권한 부여의 중심이 된다.

주요 구성 요소로는 Azure AD 테넌트, 사용자 및 그룹 객체, 사전 통합된 애플리케이션 갤러리, 조건부 액세스 정책 등이 있다. 조건부 액세스는 사용자의 신원, 장치 상태, 위치, 애플리케이션 민감도 등의 신호를 기반으로 동적으로 접근 제어 결정을 내리는 핵심 보안 기능이다[6]. Azure AD는 역할 기반 접근 제어와 속성 기반 접근 제어 모델을 모두 지원한다.

Azure AD의 기능은 기본적인 디렉터리 서비스를 넘어선다. Azure AD Connect 도구를 통해 기존의 온프레미스 Active Directory와의 하이브리드 동기화를 지원하며, B2B 협업을 통해 외부 게스트 사용자 초대 및 관리가 가능하다. 또한 Azure AD B2C는 고객 대상 애플리케이션을 위한 별도의 고객 식별 및 접근 관리 솔루션으로 제공된다.

이 서비스는 OAuth 2.0과 OpenID Connect 같은 현대적인 표준 프로토콜과 SAML 프로토콜을 광범위하게 지원하여 다양한 애플리케이션과의 통합을 용이하게 한다. Azure AD는 클라우드 우선, 모바일 우선 환경에서의 제로 트러스트 보안 모델 구현을 위한 핵심 구성 요소로 자리 잡았다.

Google Cloud IAM은 Google Cloud Platform(GCP)의 리소스에 대한 접근을 관리하는 통합 접근 제어 시스템이다. 이 서비스는 "최소 권한의 원칙"을 핵심으로 하여, 사용자, 서비스 계정, 그룹에 정확히 필요한 권한만 부여하는 세분화된 정책 관리를 가능하게 한다. GCP의 모든 서비스와 리소스에 대한 인증 및 권한 부여를 중앙에서 제어하는 역할을 담당한다.

Google Cloud IAM의 권한 부여 모델은 조직(Organization), 폴더(Folder), 프로젝트(Project), 리소스(Resource)로 구성된 계층적 구조를 기반으로 한다. 정책(Policy)은 이 계층의 특정 수준(예: 프로젝트 수준)에 부여되며, 상위 수준에서 부여된 정책은 하위 수준으로 상속된다. 정책은 주체(누가), 권한(무엇을 할 수 있는지), 리소스(어디에서)의 조합으로 정의된다. 주요 구성 요소로는 Google 계정(최종 사용자), 서비스 계정(애플리케이션 및 가상 머신), Google 그룹, Google Workspace 도메인이 있으며, 이들에 역할(Role)을 부여하여 권한을 관리한다.

사전 정의된 역할(Custom Role)과 사용자 정의 역할(Custom Role)을 모두 제공한다. 사전 정의된 역할은 소유자(Owner), 편집자(Editor), 뷰어(Viewer)와 같은 기본 역할과, 특정 서비스(예: Cloud Storage 관리자)에 대한 세분화된 역할로 구성된다. 사용자 정의 역할을 통해 조직은 필요한 최소한의 권한만을 포함한 맞춤형 역할을 생성하여 보안 상태를 더욱 강화할 수 있다. 또한, 조건부 역할 부여(Conditional Role Binding) 기능을 통해 특정 조건(예: 접근 시간, IP 주소, 리소스 태그)이 충족될 때만 역할이 부여되도록 설정할 수 있다.

Google Cloud IAM은 다른 Google 관리 서비스와 긴밀하게 통합되어 운영된다. 예를 들어, Google Cloud 조직 정책(Organization Policy)을 통해 조직 전체의 제약 조건을 설정할 수 있으며, Cloud Identity and Access Management API를 통해 프로그래밍 방식으로 정책을 관리할 수 있다. 접근 권한 변경과 API 호출에 대한 상세한 감사 로그는 Google Cloud 운영 제품군(Cloud Operations)의 Cloud Audit Logs에 자동으로 기록되어 규정 준수와 보안 분석을 지원한다.

IAM 시스템 설계에서 가장 중요한 과제 중 하나는 강력한 보안과 사용자 편의성 사이의 적절한 균형을 찾는 것이다. 지나치게 엄격한 보안 정책은 업무 효율성을 저해하고 사용자에게 불편을 초래하여 우회적인 보안 우회 행위를 유발할 수 있다. 반대로, 편의성만을 지나치게 강조하면 시스템에 취약점이 생겨 무단 접근이나 데이터 유출과 같은 보안 사고의 위험이 높아진다. 따라서 조직은 자산의 중요도, 업무 프로세스, 규정 준수 요구사항 등을 종합적으로 평가하여 최적의 균형점을 설정해야 한다.

이 균형을 달성하기 위한 일반적인 전략은 위험 기반 접근 제어를 도입하는 것이다. 민감도가 낮은 리소스에 대해서는 비교적 간소화된 인증 절차를 적용하고, 핵심 시스템이나 고위험 작업에 대해서는 다중 인증과 같은 강화된 보안 조치를 요구한다. 예를 들어, 사내 위키 접근에는 단일 패스워드로 충분하지만, 재무 데이터베이스 접근이나 관리자 권한 실행 시에는 추가적인 인증 수단을 요구할 수 있다.

또한, 자동화와 셀프 서비스 포털을 활용하여 반복적이고 저위험의 작업에 대한 관리 부담을 줄이는 것이 효과적이다. 암호 재설정, 특정 애플리케이션에 대한 일시적 접근 권한 요청 등을 사용자가 직접 처리할 수 있도록 하면, IT 관리자의 운영 부담이 줄어들고 사용자 경험이 개선된다. 이때, 각 자동화된 작업은 사전에 정의된 정책과 승인 워크플로우에 의해 통제되어야 한다. 최종적으로, 정기적인 권한 검토와 사용자 행동 분석을 통해 설정된 정책이 실제로 적절하게 작동하는지 지속적으로 모니터링하고 조정하는 과정이 필수적이다.

IAM 도입과 운영은 다양한 산업과 지역의 법적, 규제적 요구사항을 충족해야 합니다. 주요 규정으로는 GDPR(유럽 일반 데이터 보호 규칙), HIPAA(미국 건강보험 이동성 및 책임에 관한 법률), PCI DSS(결제 카드 산업 데이터 보안 표준), SOX(사베인스-옥슬리 법) 등이 있습니다. 이러한 규정은 데이터 프라이버시, 무결성, 가용성을 보호하기 위해 엄격한 접근 통제, 감사 추적, 데이터 처리 기록을 요구합니다.

IAM은 규정 준수를 달성하는 핵심 수단으로 작동합니다. 예를 들어, 최소 권한의 원칙에 기반한 세밀한 접근 제어는 불필요한 데이터 접근을 방지하고, 포괄적인 감사 로그는 누가, 언제, 어떤 자원에 접근했는지에 대한 증거를 제공합니다. 또한 역할 기반 접근 제어를 통해 직무 분리 원칙을 시행하여 사기나 오류의 위험을 줄일 수 있습니다.

특정 규정은 IAM 구현에 구체적인 요건을 부과합니다. GDPR은 데이터 주체의 접근 권리와 삭제 권리를 보장하기 위해 신원 확인 및 권한 관리 프로세스를 필요로 합니다. PCI DSS는 강력한 인증과 정기적인 접근 권한 검토를 의무화합니다. 따라서 조직은 적용받는 규정을 분석하고, IAM 정책과 절차를 해당 요구사항에 맞춰 설계해야 합니다.

규정 준수를 효과적으로 관리하기 위해 조직은 IAM 솔루션이 관련 규정을 준수하는지 검증하고, 정기적인 준수 감사를 수행하며, 감사 보고서를 자동으로 생성할 수 있는 기능을 확보해야 합니다.

IAM 시스템은 기업 내 다양한 애플리케이션, 서비스, 클라우드 플랫폼 간에 원활하게 작동해야 합니다. 이를 위해 표준 프로토콜과 통합 프레임워크의 지원이 필수적입니다. OAuth 2.0과 OpenID Connect(OIDC)는 현대적인 API 인증 및 사용자 인증을 위한 사실상의 표준으로 자리 잡았으며, SAML은 기업용 싱글 사인온(SSO) 시나리오에서 널리 사용됩니다. 또한 SCIM 표준은 사용자 계정의 생성, 수정, 삭제와 같은 라이프사이클 관리 작업을 자동화하여 여러 시스템 간의 프로비저닝을 효율화합니다.

상호 운용성을 보장하기 위해 IAM 솔루션은 다양한 IDP(Identity Provider) 및 서비스 제공자와의 통합을 지원해야 합니다. 이는 하이브리드 및 멀티 클라우드 환경에서 특히 중요합니다. 예를 들어, 기업의 온프레미스 Active Directory를 Azure AD와 연동하거나, 타사 SaaS 애플리케이션을 기업 IAM 시스템에 통합하는 경우가 있습니다. 효과적인 통합은 사용자 경험을 단순화하고, 관리 부담을 줄이며, 보안 정책의 일관된 적용을 가능하게 합니다.

통합 시 고려해야 할 주요 요소는 다음과 같습니다.

통합이 미흡할 경우, 정보의 사일로화가 발생하고 관리가 복잡해져 보안 위협과 비효율성을 초래할 수 있습니다. 따라서 IAM 도입 전략 수립 단계에서 기존 IT 인프라와의 통합 경로와 상호 운용성 수준을 철저히 평가하는 것이 중요합니다.

제로 트러스트 보안 모델은 "신뢰하되 검증하라"는 전통적인 네트워크 보안 패러다임에서 벗어난 새로운 접근법이다. 이 모델의 핵심 원칙은 네트워크 내부와 외부를 구분하지 않고, 어떤 주체나 디바이스도 기본적으로 신뢰하지 않는 것이다. 모든 접근 요청은 인증과 권한 부여를 거쳐야 하며, 이는 사용자의 신원, 디바이스 상태, 위치, 요청 시간 등 다양한 컨텍스트 정보를 기반으로 동적으로 평가된다.

제로 트러스트의 구현은 IAM과 깊이 연관되어 있다. IAM은 신원 확인과 최소 권한 원칙에 기반한 세밀한 접근 제어를 제공함으로써 제로 트러스트 아키텍처의 핵심 구성 요소 역할을 한다. 특히, ABAC나 PBAC와 같은 정교한 권한 부여 모델은 사용자 속성과 환경 변수를 실시간으로 분석하여 접근 결정을 내리는 제로 트러스트의 요구사항에 부합한다.

제로 트러스트 모델을 채택할 때의 주요 구성 요소와 원칙은 다음과 같이 정리할 수 있다.

이 모델은 클라우드, 모바일 워크포스, 하이브리드 근무 환경이 확산되면서 기업의 경계가 모호해진 현대 IT 환경에서 특히 중요성을 얻었다. 내부자가 개입할 수 있는 위협과 같은 전통적인 방어선 모델로는 대응하기 어려운 위협에 효과적으로 대응할 수 있는 프레임워크를 제공한다[7].

CIEM은 클라우드 인프라스트럭처 내에서 과도하거나 미사용 권한을 식별, 관리, 최소화하는 데 중점을 둔 클라우드 보안 도구 및 관행의 한 분야이다. 이는 클라우드 컴퓨팅 환경이 확장되고 다중 클라우드 전략이 보편화되면서, 수많은 IAM 역할, 정책, 자격 증명이 복잡하게 얽혀 발생하는 권한 부풀림 문제를 해결하기 위해 등장했다. CIEM 솔루션은 지속적으로 클라우드 환경을 모니터링하여 실제 사용 패턴을 기반으로 최소 권한 원칙을 적용할 수 있도록 지원한다.

CIEM의 주요 기능은 크게 가시성 확보, 권한 관리, 위협 탐지로 구분된다. 가시성 확보 단계에서는 AWS, Microsoft Azure, Google Cloud Platform 등 다양한 클라우드 서비스 공급자(CSP)의 계정을 통합하여 모든 자산과 연결된 권한을 중앙에서 조회할 수 있게 한다. 권한 관리 단계에서는 자동화된 분석을 통해 불필요한 권한을 제거하거나 조정하는 정책 권고안을 생성한다. 위협 탐지 단계에서는 비정상적인 권한 사용 패턴이나 위험한 정책 구성(예: 관리자 권한이 과도하게 부여된 정책)을 실시간으로 식별하여 경고한다.

CIEM의 도입 효과는 보안 위험 감소와 규정 준수 용이성에 있다. 권한 부풀림을 제거함으로써 내부 위협이나 침해 사고 발생 시 공격자가 이용할 수 있는 수평적 이동 경로를 차단한다. 또한, GDPR, ISO 27001, SOC 2 등 주요 보안 및 프라이버시 규정에서 요구하는 최소 권한 원칙의 이행을 증명하는 데 도움을 준다. 그러나 CIEM은 일회성 도구가 아닌 지속적인 권한 거버넌스 프로세스의 일부로 통합되어야 하며, 초기 설정과 정책 튜닝 과정에서 업무 연속성에 방해가 되지 않도록 주의해야 한다.

IAM 시스템에서 인공지능과 기계 학습 기술은 전통적인 규칙 기반 접근 제어를 넘어선 적응형 보안을 가능하게 한다. 이 기술들은 시스템 내의 방대한 로그 데이터, 사용자 행동 패턴, 리소스 접근 이력을 분석하여 정상적인 활동 기준을 학습한다. 학습된 모델은 실시간으로 수신되는 활동 데이터와 비교를 수행하며, 기준에서 벗어난 이상 행위나 잠재적인 권한 남용 시도를 탐지한다.

탐지 가능한 위협의 예시는 다음과 같다.

AI/ML 기반 접근 방식은 사전에 정의하기 어려운 새로운 위협 패턴을 식별할 수 있다는 장점이 있다. 예를 들어, 합법적인 자격 증명을 가진 공격자가 점진적으로 접근 패턴을 변경하며 데이터를 유출하는 경우, 기계 학습 모델은 미세한 행동 변화를 이상 징후로 판단할 수 있다. 또한, 이러한 시스템은 탐지된 위협에 대한 위험 점수를 부여하고, 위험 수준에 따라 경고를 발생시키거나 MFA를 재요청하는 등의 자동화된 대응 조치를 트리거할 수 있다.

이 기술의 효과적인 적용을 위해서는 품질 높은 학습 데이터와 지속적인 모델 재학습이 필수적이다. 또한, 탐지 결과에 대한 설명 가능성이 부족할 수 있어, 보안 운영팀이 의사 결정을 내리는 데 어려움을 초래할 수 있다. 따라서 AI/ML 기반 위협 탐지는 인간 분석가의 판단을 보조하는 도구로 통합되어 운영되어야 한다.

OAuth 2.0은 제3자 애플리케이션이 사용자의 리소스에 제한적으로 접근할 수 있도록 허용하는 인가 프레임워크이다. 사용자가 비밀번호를 제3자에게 제공하지 않고도, 특정 자원에 대한 접근 권한을 위임할 수 있게 해준다. 이는 "접근 위임"을 위한 개방형 표준으로, 주로 API 보안에 사용된다. OAuth 2.0의 핵심 구성 요소는 리소스 소유자, 클라이언트, 리소스 서버, 인가 서버이다. 인가 코드 승인, 암시적 승인, 리소스 소유자 암호 자격 증명, 클라이언트 자격 증명 등 여러 승인 유형을 제공하여 다양한 애플리케이션 시나리오를 지원한다.

OpenID Connect(OIDC)는 OAuth 2.0 프로토콜 위에 구축된 간단한 인증 레이어이다. OAuth 2.0이 인가에 중점을 둔다면, OpenID Connect는 사용자가 누구인지 확인하는 표준화된 인증 방법을 제공하는 데 주력한다. OIDC는 클라이언트가 리소스 서버의 인가 서버를 통해 최종 사용자의 신원을 확인할 수 있게 해준다. 이 과정에서 핵심적인 요소는 사용자 정보를 담은 ID 토큰이다. ID 토큰은 JSON Web Token(JWT) 형식을 사용하며, 사용자의 프로필 정보나 이메일 주소 같은 기본적인 신원 정보를 포함할 수 있다.

두 기술은 현대 IAM 시스템에서 상호 보완적으로 작동한다. 일반적인 흐름은 OpenID Connect를 사용하여 사용자를 인증하고 ID 토큰을 발급받은 후, OAuth 2.0을 통해 해당 사용자의 리소스(예: Google 드라이브 파일)에 접근하는 데 필요한 액세스 토큰을 얻는 방식이다. 이 조합은 "로그인에 Google 계정 사용"과 같은 싱글 사인온 경험의 기반이 된다.

이 표준들은 마이크로서비스 아키텍처와 클라우드 네이티브 애플리케이션에서 분산된 신원 및 접근 관리를 가능하게 하는 데 필수적이다.

SAML은 XML 기반의 개방형 표준 데이터 형식으로, 인증 및 권한 부여 데이터를 교환하기 위해 사용된다. 주로 웹 브라우저 싱글 사인온(SSO) 구현의 핵심 프로토콜로 기능한다. SAML은 보안 도메인이 서로 다른 두 당사자, 즉 신원 제공자(IdP)와 서비스 제공자(SP) 간에 인증 및 권한 부여 데이터를 안전하게 전달한다.

SAML의 동작은 어설션(Assertion)이라는 신뢰할 수 있는 진술을 중심으로 이루어진다. IdP가 생성하는 이 어설션에는 사용자가 인증받았다는 사실, 사용자의 속성(예: 이메일, 부서), 그리고 해당 SP에서의 접근 권한에 대한 결정이 포함된다. 일반적인 SAML 흐름은 사용자가 SP에 접근을 시도하면 SP가 사용자를 IdP로 리디렉션하고, IdP에서 인증(예: 아이디/비밀번호 입력)이 이루어진 후, 인증 성공 정보가 담긴 SAML 응답(어설션)을 사용자 브라우저를 통해 SP에게 전달하는 방식이다.

SAML의 주요 구성 요소는 어설션, 프로토콜, 바인딩이다. 어설션은 인증, 속성, 권한 부여 결정을 담는 핵심 데이터 패키지다. 프로토콜은 어설션을 요청하고 전달하기 위한 규칙을 정의하며, 바인딩은 이러한 SAML 메시지를 HTTP POST나 리디렉션 같은 하위 전송 프로토콜에 매핑하는 방법을 규정한다.

SAML은 엔터프라이즈 환경에서 널리 채택되어, 직원이 한 번의 로그인으로 회사 네트워크 내의 여러 클라우드 애플리케이션과 서비스에 접근할 수 있게 한다. 이는 OAuth 2.0이 API 접근 위임에 중점을 두는 반면, SAML은 주로 사용자 인증 정보의 교환에 특화되어 있다는 점에서 차이를 보인다. SAML 2.0은 현재 가장 보편적으로 사용되는 버전이다.

SCIM은 도메인 간 ID 관리를 위한 개방형 표준 프로토콜이다. 주로 클라우드 컴퓨팅 환경에서 사용자 계정과 그룹 정보를 다양한 애플리케이션과 서비스 간에 자동으로 동기화하고 관리하기 위해 설계되었다. 이 표준은 사용자 프로비저닝과 디프로비저닝 작업을 자동화하여 관리자의 수동 작업 부담을 줄이고 보안을 강화하는 것을 목표로 한다.

SCIM은 RESTful API를 기반으로 하며, JSON 형식을 사용하여 사용자 및 그룹 리소스를 표현한다. 주요 리소스는 User와 Group이며, 이를 통해 사용자의 이름, 이메일, 부서, 계정 상태와 같은 속성과 그룹 멤버십 정보를 교환한다. 표준화된 스키마와 CRUD (생성, 읽기, 갱신, 삭제) 작업을 정의함으로써 서로 다른 시스템 간의 통합을 단순화한다.

이 프로토콜은 싱글 사인온 솔루션, HR 시스템, ITSM 도구와 같은 ID 공급자가 다수의 서비스 제공자에게 사용자 정보를 전파할 때 특히 유용하다. 예를 들어, 회사에서 신입 사원이 입사하면 HR 시스템에서 생성된 계정 정보가 SCIM을 통해 Microsoft 365, Google Workspace, Slack 등 다양한 업무용 클라우드 서비스에 자동으로 생성된다. 반대로 퇴사 시 계정이 중앙에서 비활성화되면 모든 연결된 서비스에서도 일괄 삭제되어 보안 위험을 줄인다.

SCIM은 OAuth 2.0을 주된 인증 메커니즘으로 활용하며, SAML이나 OpenID Connect와 같은 인증 프로토콜과 함께 사용되어 포괄적인 IAM 솔루션을 구성한다. 이를 통해 조직은 사용자 라이프사이클 관리를 효율화하고, 수동 오류를 최소화하며, 규정 준수 요구사항을 더 쉽게 충족할 수 있다.