최근 외부 교육에서 Active Directory를 AWS에 연동해서 사용하는 실습을 해봤다.

평소 AWS를 사용하면서 IAM User, IAM Role, Policy 같은 것들은 많이 사용했지만, 회사의 사용자 계정과 AWS 계정을 연결해 중앙에서 관리하는 환경은 제대로 구성해본 적이 없었다.

교육에서는 Active Directory의 사용자와 그룹을 AWS에 연결하고, 해당 사용자에게 AWS 계정과 권한을 할당하는 과정을 직접 해봤다.

생각보다 재미있었다.

특히 이런 구조가 눈에 들어왔다.

flowchart TD
    U["사용자"] --> AD["Active Directory"]
    AD --> IC["AWS IAM Identity Center"]
    IC --> D["Development Account"]
    IC --> S["Staging Account"]
    IC --> P["Production Account"]

사용자가 AWS마다 별도의 계정을 가지는 것이 아니라,

회사에서 사용하는 하나의 Identity를 기준으로 여러 AWS Account와 서비스의 접근 권한을 관리한다.

AWS IAM Identity Center는 AWS Managed Microsoft AD 또는 자체 Active Directory를 Identity Source로 연결할 수 있고, 외부 IdP의 경우 SAML 2.0과 SCIM을 이용해 Okta나 Microsoft Entra ID 같은 제품과도 연결할 수 있다.

이걸 직접 사용해보니 자연스럽게 궁금해졌다.

회사 규모가 커지면 사용자 계정과 권한을 어떻게 관리할까?

그리고 예전부터 관심이 있었던 Okta를 시작으로 IAM 제품들을 조금 찾아보기 시작했다.

실습 경험과 제품 비교의 범위

앞부분의 AD 연동 경험과 아래 제품 비교는 구분해서 읽어야 한다. 이 글에는 당시 사용한 Directory 유형, 네트워크 구성, 실제 Permission Set과 오류 로그를 재현할 만큼의 기록이 포함되어 있지 않다. 뒤의 제품 소개는 도입 후보를 이해하기 위한 정리이며, 모든 제품을 직접 구축해 성능을 비교한 결과는 아니다.

AD 연동을 다시 실습한다면 다음을 기록하겠다.

  • Identity Source: AWS Managed Microsoft AD인지, 자체 AD와 AD Connector를 사용하는지
  • 연결: DNS·네트워크 연결·디렉터리 상태
  • 사용자/그룹: 동기화된 테스트 사용자와 그룹
  • 권한 할당: AWS 계정·Permission Set·할당 대상
  • 성공/실패 기준: 테스트 계정 로그인과 허용 API, 금지 API 접근 결과
  • 계정 회수: 사용자 비활성화 후 새 로그인과 기존 세션의 처리 결과

특히 사용자 프로비저닝, 로그인 인증, AWS 권한 할당은 서로 다른 단계다. SCIM으로 사용자가 동기화됐다는 것만으로 AWS 계정 접근이 완료됐다고 판단하지 않는다.

먼저 IAM이 뭘까?

IAM은 Identity and Access Management, 즉 Identity와 접근 권한을 관리하는 시스템이다.

쉽게 말하면 다음 두 가지 질문을 처리한다.

  • Who are you? 누구인가?
  • What can you access? 무엇에 접근할 수 있는가?

조금 더 실제 회사 환경으로 바꾸면 이런 문제들이다.

신입 개발자가 입사하면 다음 작업이 필요하다.

  • Google Workspace·GitHub·VPN 계정 생성
  • Slack 초대
  • Jira·Confluence 권한 부여
  • AWS Developer 권한 부여

그리고 퇴사한다면?

  • Google 계정 차단
  • GitHub 제거
  • Slack 제거
  • AWS 권한 제거
  • VPN 차단

서비스가 5개일 때는 사람이 관리할 수도 있다.

하지만 사용하는 SaaS가 50개, 직원이 1,000명이 되면 이야기가 완전히 달라진다.

그래서 Identity를 한 곳에서 관리하는 시스템이 중요해진다.

IAM을 이해하기 전에 알아두면 좋은 용어

처음 IAM 제품들을 찾아보면 비슷한 단어가 계속 등장한다.

Directory

사용자와 그룹 정보를 저장하는 곳이다.

대표적인 것이 Microsoft Active Directory다.

  • User
  • Group
  • Computer
  • Organization Unit

같은 정보를 관리한다.

IdP

Identity Provider.

사용자의 Identity를 확인하고 인증해주는 시스템이다.

예를 들어 서비스에 접속했는데

  • Login with Microsoft
  • Login with Okta
  • Login with Google

같은 화면이 나온다면 해당 Microsoft, Okta, Google 등이 IdP 역할을 한다.

SSO

Single Sign-On.

한 번 인증한 Identity를 사용해 여러 서비스에 접근하는 방식이다.

Okta를 통해 Slack, AWS, GitHub, Jira의 로그인을 통합한다.

각 서비스마다 비밀번호를 따로 관리하지 않아도 된다.

SAML / OIDC

SSO를 구현할 때 많이 사용하는 인증 프로토콜이다.

기업 SaaS 환경에서는 SAML을 많이 볼 수 있고, 현대적인 Web/Application 환경에서는 OAuth 2.0과 함께 OIDC를 자주 사용한다.

SCIM

System for Cross-domain Identity Management.

로그인을 위한 프로토콜이라기보다 사용자 Provisioning을 자동화하기 위한 표준이다.

예를 들어 Okta에서 사용자를 만들었을 때:

Okta에서 사용자가 생성되면 연동 설정에 따라 Slack·GitHub 사용자 생성과 AWS 사용자 프로비저닝으로 연결한다.

반대로 사용자를 비활성화하면 연결된 시스템의 접근 권한도 함께 제거할 수 있다.

어떤 IAM 솔루션들이 있을까?

1. Microsoft Active Directory

기업 Identity 시스템 이야기에서 가장 먼저 등장하는 제품이다.

오랫동안 기업 내부의 Windows 환경에서 사실상 표준처럼 사용되어 왔다.

flowchart TD
    E["Employee"] --> A["Active Directory"]
    A --> W["Windows Login / Group Policy"]
    A --> F["File Server"]
    A --> L["LDAP / Internal System"]

장점

가장 큰 장점은 전통적인 기업 인프라와의 강력한 통합이다.

Windows PC, Windows Server, LDAP, Kerberos, Group Policy 같은 환경에서는 여전히 강력하다.

기존 회사가 이미 AD를 중심으로 구성되어 있다면 AWS나 SaaS 환경으로 Identity를 확장하는 것도 자연스럽다.

단점

근본적으로 On-Premise 중심으로 발전해온 기술이다.

Cloud SaaS와 모바일, Mac, Linux까지 범위가 넓어지면서 AD 하나만으로 모든 Identity를 관리하기에는 구조가 복잡해질 수 있다.

그래서 현대 환경에서는 AD 단독보다는 다른 Cloud Identity 플랫폼과 함께 사용하는 경우가 많다.

2. Microsoft Entra ID

예전 이름은 Azure Active Directory다.

이름 때문에 Active Directory의 Cloud 버전 정도로 생각하기 쉽지만, 실제로는 성격이 조금 다르다.

Entra ID는 Cloud 기반 Identity Provider에 가깝다.

flowchart TD
    A["Active Directory"] -->|"Sync"| E["Microsoft Entra ID"]
    E --> M["Microsoft 365 / Azure"]
    E --> C["AWS / SaaS"]

장점

Microsoft 생태계와의 통합이 굉장히 강하다.

특히 회사에서 Windows, Microsoft 365, Teams, Azure, Intune을 많이 사용하고 있다면 자연스러운 선택이다.

기존 Active Directory를 가지고 있는 회사도 Hybrid Identity 형태로 확장하기 좋다.

단점

Microsoft 생태계 비중이 높아질수록 편해지는 대신 Microsoft 의존도도 자연스럽게 높아진다.

라이선스 구조와 Identity Governance, Conditional Access 같은 기능까지 들어가기 시작하면 처음 접하는 입장에서는 꽤 복잡하게 느껴질 수도 있다.

3. Okta

내가 개인적으로 가장 관심이 있었던 제품이다.

Okta는 대표적인 Cloud Identity Provider다.

특정 Cloud Vendor에 크게 종속되지 않고 다양한 SaaS와 Infrastructure를 연결하는 것을 목표로 한다.

flowchart TD
    U["User"] --> O["Okta"]
    O --> C["AWS"]
    O --> M["Google Workspace / Microsoft 365"]
    O --> S["Slack / GitHub / Salesforce"]

단순 SSO뿐 아니라 Lifecycle Management, Identity Governance, Privileged Access, Workflow 같은 영역까지 제공한다.

장점

가장 큰 장점은 Vendor Neutral에 가까운 위치다.

AWS 회사에서도 사용할 수 있고 Azure 중심 회사에서도 사용할 수 있으며 Google Workspace 환경에서도 사용할 수 있다.

SaaS Integration이 많고 SSO, MFA, 사용자 Lifecycle 관리까지 Identity를 중심으로 묶을 수 있다.

특히 Multi Cloud 환경에서는 매력적이다.

Okta를 중심으로 AWS·Azure·GCP, SaaS, 내부 애플리케이션의 접근을 통합한다.

Identity가 Cloud보다 위에 존재하는 형태다.

단점

기능이 많아질수록 비용도 커질 수 있다.

그리고 이미 Microsoft 중심 환경이라 Entra ID가 충분한 회사라면 별도의 Okta를 도입하는 것이 오히려 시스템을 하나 더 운영하는 결과가 될 수도 있다.

4. AWS IAM Identity Center

AWS를 사용하는 개발자라면 가장 쉽게 접할 수 있는 서비스다.

예전 이름은 AWS SSO였다.

중요한 것은 IAM Identity Center를 Okta와 완전히 같은 종류의 제품이라고 생각하면 조금 다르다는 점이다.

IAM Identity Center는 특히 AWS Account와 AWS Application 접근 관리에 강한 서비스다.

AWS Organizations와 함께 사용하면

AWS Organizations의 계정 구성 예시:

  • Management
  • Development
  • Staging
  • Production
  • Security

여러 Account에 사용자나 그룹별 Permission Set을 할당할 수 있다.

예를 들어:

개발자 그룹에 할당하는 권한 예시:

  • Dev: Administrator
  • Staging: PowerUser
  • Production: ReadOnly

같은 구조를 중앙에서 관리할 수 있다.

장점

AWS 환경에서는 굉장히 편하다.

특히 Multi Account 전략을 사용하면 효과가 크다.

AWS CLI 역시 SSO 인증을 사용할 수 있어서 Access Key를 개발자 PC에 장기간 저장하는 구조를 줄일 수 있다.

단점

Okta 같은 범용 Workforce Identity 플랫폼과 비교하면 역할의 범위가 다르다.

회사 전체 SaaS Identity를 관리하는 중앙 Identity Platform이라기보다는 AWS 접근 관리의 중심이라고 보는 것이 더 이해하기 쉽다.

그래서 실제 환경에서는 다음과 같은 구조를 고려할 수 있다.

flowchart TD
    N0["Okta"]
    N1["AWS IAM Identity Center"]
    N2["계정·Permission Set 선택"]
    N3["임시 자격 증명으로 AWS 접근"]
    N0 --> N1
    N1 --> N2
    N2 --> N3

또는

flowchart TD
    N0["Entra ID"]
    N1["AWS IAM Identity Center"]
    N2["계정·Permission Set 선택"]
    N3["임시 자격 증명으로 AWS 접근"]
    N0 --> N1
    N1 --> N2
    N2 --> N3

5. JumpCloud

조사하면서 꽤 흥미로웠던 제품이다.

JumpCloud는 Cloud Directory와 Device 관리까지 같이 가져가는 것이 특징이다.

flowchart TD
    J["JumpCloud"] --> I["Identity 관리"]
    J --> D["Device 관리"]
    I --> A["AWS / SaaS / LDAP"]
    D --> O["Windows / macOS / Linux"]

장점

Cloud Native 회사나 스타트업에서 흥미로운 선택지가 될 수 있다.

특히 Windows, Mac, Linux Device 환경이 섞여 있다면 전통적인 AD보다 자연스러운 구조를 만들 수 있다.

기존 AD와 연결해서 사용하다가 점진적으로 AD 의존도를 줄이는 구성도 고려할 수 있다.

단점

대규모 Windows Enterprise 환경에서는 이미 구축된 Active Directory 생태계를 완전히 대체하는 것이 현실적으로 쉽지 않을 수 있다.

반대로 Cloud First 조직에서는 굉장히 재미있는 선택지라고 생각한다.

6. Keycloak

앞의 제품들과 조금 다른 선택지다.

Keycloak은 Open Source Identity and Access Management 솔루션이다.

flowchart TD
    A["Application"] --> K["Keycloak"]
    K --> D["LDAP / Active Directory"]
    K --> S["Google / GitHub"]
    K --> E["External IdP"]

OIDC, OAuth, SAML 등을 지원하고 외부 Identity Provider를 연결하는 Identity Brokering도 지원한다.

장점

가장 큰 장점은 직접 운영할 수 있다는 것이다.

특정 SaaS IAM Vendor에 모든 인증 시스템을 의존하고 싶지 않은 경우 좋은 선택지가 될 수 있다.

그리고 개발자 입장에서는 굉장히 재미있는 제품이다.

Authentication Flow나 Token, OAuth, OIDC 같은 Identity 기술을 직접 이해하기에도 좋다.

단점

직접 운영해야 한다는 것은 동시에 가장 큰 단점이다.

  • HA
  • Database
  • Backup
  • Upgrade
  • Security Patch
  • Monitoring
  • Scaling

전부 우리의 책임이다.

Identity 시스템은 장애가 발생하면 회사의 모든 서비스 로그인이 동시에 막힐 수도 있다.

따라서 단순히 “SaaS 비용이 아까우니까 Keycloak을 쓰자” 정도로 결정할 문제는 아니다.

7. Ping Identity

Enterprise IAM 분야에서 오래된 강자 중 하나다.

특히 Hybrid 환경이나 기존 Legacy 시스템이 많은 대기업 환경에서 강점을 가진다.

장점

대규모 Enterprise와 복잡한 Hybrid 환경에서 강력하다.

Legacy Application부터 SaaS까지 Identity를 연결해야 하는 조직에서는 좋은 선택지가 될 수 있다.

단점

작은 조직이 가볍게 시작하기에는 다소 무거운 Enterprise 솔루션이다.

기능과 구성의 자유도가 높은 만큼 Identity Architecture에 대한 이해도 필요하다.

Auth0도 IAM 아닌가?

IAM을 찾아보다 보면 Auth0도 거의 반드시 만나게 된다.

Auth0 역시 Identity 플랫폼이지만 앞에서 이야기한 Okta Workforce나 Entra ID와는 주 사용처가 조금 다르다.

쉽게 구분하면:

  • 직원 Identity: Okta, Entra ID, Ping, JumpCloud
  • 서비스 사용자 Identity: Auth0, Keycloak, Amazon Cognito

물론 실제 제품 기능은 이 정도로 깔끔하게 나뉘지는 않는다.

하지만 제품을 처음 이해할 때는 Workforce IAM과 Customer IAM(CIAM)을 구분해서 보는 것이 편하다.

예를 들어 회사 직원이 AWS에 로그인하는 것은 Workforce Identity 문제이고,

내가 만든 쇼핑몰에 고객이 Google 계정으로 로그인하는 것은 Customer Identity 문제에 가깝다.

한눈에 비교해보면

솔루션 성격 잘 맞는 환경 장점 단점
Active Directory Directory / Domain 기존 Enterprise Windows/Legacy 통합 Cloud Native 환경에서는 복잡
Entra ID Cloud IAM / IdP Microsoft 중심 기업 M365/Azure 통합 Microsoft 의존도
Okta Workforce IAM Multi Cloud / SaaS 많은 Integration, Vendor Neutral 비용
AWS IAM Identity Center AWS Access AWS Multi Account AWS 권한 관리가 매우 편함 범용 IAM 역할은 제한적
JumpCloud Cloud Directory Cloud Native / Mixed OS Identity + Device 관리 대규모 AD 환경 전환 부담
Keycloak Open Source IAM 자체 서비스 / Private 환경 자유도, Open Source 운영 부담
Ping Identity Enterprise IAM 대기업 / Hybrid 복잡한 Enterprise 통합 구성과 비용이 무거울 수 있음
Auth0 CIAM / Application IAM Web / Mobile 서비스 Application 인증 구현 편리 Workforce IAM과 목적이 다름

내가 지금 선택한다면?

결국 어떤 제품이 가장 좋다고 말하기는 어렵다.

현재 회사가 어떤 환경인지가 훨씬 중요하다.

Microsoft 중심 회사

  • AD
  • Microsoft 365
  • Windows
  • Azure

이라면 Active Directory + Entra ID 조합이 가장 자연스럽다.

AWS 중심 회사

  • AWS Organizations
  • Multi Account
  • Cloud Native

라면 우선 AWS IAM Identity Center부터 시작해볼 것 같다.

SaaS와 Multi Cloud가 많은 회사

  • AWS
  • Azure
  • GCP
  • Slack
  • GitHub
  • Notion
  • Jira
  • Google Workspace

이라면 Okta 같은 독립적인 Identity Platform이 매력적이다.

Mac/Linux가 많고 AD가 없는 회사

Cloud Native 스타트업이라면 JumpCloud도 상당히 흥미로운 선택지다.

직접 Identity 시스템을 운영해야 한다면

Keycloak을 가장 먼저 검토해볼 것 같다.

다만 Identity 시스템 자체를 운영할 역량이 있는지를 먼저 고민해야 한다.

결국 중요한 것은 제품보다 Identity Architecture

이번에 Active Directory를 AWS에 연결해보면서 가장 흥미로웠던 부분은 특정 제품 자체가 아니었다.

예전에는 AWS 권한이라고 하면 자연스럽게 이런 것부터 생각했다.

  • IAM User
  • IAM Role
  • IAM Policy
  • Access Key

그런데 조금 더 큰 조직의 관점에서 보면 시작점 자체가 다르다.

flowchart TD
    H["HR"] --> I["Identity: 직원·팀·부서·역할"]
    I --> P["Identity Provider"]
    P --> C["AWS / Kubernetes"]
    P --> S["GitHub / Slack"]
    P --> N["VPN / Internal Service"]

결국 핵심은

“AWS 권한을 어떻게 줄까?”

보다

“이 사람은 누구이고, 어떤 조직에 속해 있으며, 어떤 Resource에 접근할 수 있어야 하는가?”

에 더 가깝다.

그리고 한 단계 더 가면 IAM뿐 아니라

IAM에서 함께 살펴볼 영역은 SSO, MFA, Federation, Provisioning, 그리고 IGA(Identity Governance)와 PAM(Privileged Access Management)이다.

같은 영역으로 자연스럽게 확장된다.

DevOps를 하다 보면 Terraform, Kubernetes, AWS 같은 Infrastructure 기술에 집중하기 쉬운데 결국 이 모든 시스템의 입구에는 Identity가 있다.

그래서 앞으로는 AWS IAM뿐 아니라 Okta, Entra ID, Keycloak, IAM Identity Center 같은 제품들을 직접 구성해보면서 Identity Architecture를 조금 더 깊게 공부해보고 싶다.

개인적으로 다음에는 이런 구조를 한번 만들어보고 싶다.

flowchart TD
    O["Okta"] -->|"SAML / SCIM"| I["AWS IAM Identity Center"]
    I --> A["계정 선택: Dev / Staging / Prod"]
    I --> P["할당된 Permission Set"]
    A --> T["Temporary Credentials"]
    P --> T

그리고 가능하다면 이 전체 구성을 Terraform으로 관리해보는 것.

아마 IAM 공부는 여기서부터 꽤 재미있어질 것 같다.

참고 자료