IAM 솔루션 비교 2026, SSO·MFA·권한 수명주기 도입 기준

IAM 솔루션 비교 보안 운영실에서 접근 권한 정책을 검토하는 장면 — IAM 솔루션 비교는 로그인 통합보다 계정 수명주기와 감사 증거 설계가 먼저입니다.

IAM 솔루션 비교를 검색하는 조직은 대개 SSO 로그인 화면 하나가 아니라 퇴사자 계정, 관리자 권한, SaaS 접근 승인, 감사 대응을 한꺼번에 정리해야 하는 상태입니다.

견적서에는 사용자 수와 인증 기능이 보이지만, 실제 비용은 HR 연동, SaaS별 예외, 관리자 권한 회수, 로그 보존, 헬프데스크 티켓 처리에서 더 자주 커집니다.

따라서 IAM 도입은 어떤 제품이 유명한가보다 어떤 계정을 누가 만들고, 누가 승인하고, 언제 자동으로 회수할지 먼저 정해야 합니다.

핵심 요약

IAM 솔루션은 SSO, MFA, 계정 수명주기, 권한 승인, 접근 검토, 감사 로그를 한 흐름으로 묶을 때 가치가 납니다.
AWS IAM, Microsoft Entra, Google Cloud IAM처럼 cloud 권한 중심 제품과 Okta, Auth0 같은 workforce·customer identity 축은 평가 기준이 다릅니다.
비용 비교는 사용자 단가만 보면 부족하고 HR 연동, SaaS 커넥터, 관리자 계정, 로그 보존, 운영 인력 시간을 같이 봐야 합니다.
이 조건이면 먼저 PoC를 시작합니다: 퇴사자 계정 회수가 늦고, 관리자 권한이 상시 부여되며, 감사 때 승인 증거를 다시 찾는 조직입니다.

이 글이 필요한 사람

SSO는 일부 서비스에만 연결했고 SaaS마다 로컬 관리자 계정이 남아 있는 보안 담당자.
Microsoft Entra, Okta, Auth0, Google Cloud IAM, AWS IAM 중 어떤 축을 먼저 비교해야 할지 정해야 하는 플랫폼팀.
퇴사자 계정 회수, 부서 이동자 권한 정리, 외주 인력 만료일을 자동화해야 하는 IT 운영팀.
감사 대응에서 누가 언제 접근을 승인했는지 증거를 빨리 제출해야 하는 컴플라이언스 담당자.
IAM 솔루션 견적이 사용자 수만으로 끝나지 않는 이유를 구매 전에 설명해야 하는 의사결정자.

IAM 솔루션 비교의 출발점은 제품명이 아니라 identity 범위다

IAM은 identity and access management의 약자지만, 실제 프로젝트에서는 workforce identity와 cloud permission, customer identity, privileged access가 서로 다른 예산과 owner를 가집니다.

AWS IAM과 Google Cloud IAM은 cloud resource 권한 모델을 중심으로 보아야 하고, Microsoft Entra와 Okta는 workforce SSO, MFA, 조건부 접근, 계정 수명주기와 더 자주 연결됩니다.

Auth0 같은 customer identity 플랫폼은 고객 로그인, 개발자 API, 애플리케이션 통합이 핵심이므로 임직원 계정 통제와 같은 표로만 비교하면 판단이 흐려집니다.

이 경우는 첫 회의에서 범위를 세 조각으로 나누는 편이 안전합니다.

임직원 identity: 입사, 부서 이동, 퇴사, 외주 인력 만료, SSO, MFA, 조건부 접근을 다룬다.
Cloud identity: AWS, Google Cloud, Azure resource 권한, role, service account, audit log를 다룬다.
고객 identity: 회원 로그인, 소셜 로그인, API 권한, 개인정보 동의, 개발자 통합성을 다룬다.
특권 identity: 관리자 권한, break-glass 계정, just-in-time 승인, session 기록을 다룬다.

처음부터 모든 범위를 한 솔루션으로 묶겠다고 정하면 PoC가 늦어지고, 반대로 로그인 통합만 보고 계약하면 권한 회수와 감사 증거가 빠집니다.

후보 솔루션을 비교할 때 보는 축

비교 축	확인 질문	좋은 신호	위험 신호
SSO와 앱 연결	핵심 SaaS와 내부 앱이 얼마나 빨리 연결되는가	상위 20개 시스템 owner와 SSO 전환 일정이 있다	커넥터 수만 많고 실제 사내 앱 연동 책임자가 없다
MFA와 조건부 접근	관리자와 위험 로그인에 강한 인증을 강제할 수 있는가	관리자, 재무, 외주, 미등록 기기 정책이 분리된다	모든 사용자에게 같은 MFA만 적용하고 예외 추적이 없다
계정 수명주기	입사·이동·퇴사 이벤트가 권한 생성과 회수로 이어지는가	HR source of truth와 ticket evidence가 연결된다	퇴사자 계정을 월말 수동 점검으로만 닫는다
Cloud 권한	role과 service account를 최소 권한으로 관리하는가	권한 변경 이력과 owner가 cloud audit log로 남는다	관리자 계정이 상시 권한으로 유지된다
감사와 로그	누가 승인했고 언제 만료되는지 재구성할 수 있는가	access review, exception, session, policy 변경 기록이 남는다	감사 요청 때 화면 캡처와 수동 엑셀로 맞춘다

이 표에서 가장 먼저 빨간불이 켜지는 곳이 실제 도입 범위입니다.

예를 들어 앱 연결은 충분하지만 퇴사자 회수가 약하면 솔루션 비교보다 HR 연동과 deprovisioning 흐름을 먼저 설계해야 합니다.

비용은 사용자 단가보다 운영 잔여 비용을 봐야 한다

IAM 견적은 활성 사용자, 관리자 기능, 고급 MFA, lifecycle module, governance module, customer identity MAU, cloud log 연동에 따라 달라질 수 있습니다.

공식 가격표나 견적 정책은 바뀌므로 이 글에서 단가를 단정하지 않고, 비교 회의에서 빠뜨리기 쉬운 비용 항목을 따로 분리합니다.

비용 항목	견적서에 보이는가	누가 확인할 것	검토 메모
사용자·월 활성 계정	대부분 보임	구매팀과 IT 운영팀	정규직, 외주, 휴면 계정, 고객 계정을 같은 단위로 보지 않는다
SaaS 커넥터와 내부 앱 연동	제품별 차이	플랫폼팀	상위 20개 앱부터 SSO 전환 난이도와 owner를 적는다
Lifecycle·governance module	별도 module일 수 있음	보안팀과 HR 시스템 owner	입사·이동·퇴사 자동화와 access review 비용을 분리한다
로그 보존과 SIEM 연동	빠지기 쉬움	SOC와 인프라팀	로그량, 보존 기간, export 형식, 검색 비용을 같이 본다
운영 인력과 헬프데스크	대개 안 보임	IT 운영팀	MFA 초기화, 앱 예외, 권한 요청 처리 시간을 산정한다

이 조건이면 단가가 조금 높은 제품도 검토할 만합니다: lifecycle 자동화가 퇴사자 계정 회수 시간을 줄이고, 감사 증거 생성 시간을 줄인다는 내부 지표가 있습니다.

이 경우는 보류가 맞습니다: 아직 source of truth가 HR 시스템인지 AD인지 불명확하고, 앱 owner도 정해지지 않았는데 고급 governance module부터 계약하려고 합니다.

보안 기준은 MFA 체크박스에서 끝나면 안 된다

NIST 디지털 identity 가이드와 CISA 제로트러스트 성숙도 모델을 보면 인증 강도, device context, 접근 정책, 로그 검증이 함께 움직여야 합니다.

MFA가 있다고 해도 관리자 계정이 영구 권한을 가지고 있고, 공유 계정이 남아 있고, break-glass 계정 검토가 없다면 공격자가 노릴 경로는 그대로 남습니다.

IAM 솔루션 비교에서 보안팀이 물어봐야 할 질문은 제품 기능 목록보다 운영 통제 문장에 가깝습니다.

관리자 로그인을 phishing-resistant MFA나 hardware key 정책으로 분리할 수 있는가.
외주 계정은 만료일 없이는 생성되지 않도록 강제할 수 있는가.
부서 이동자가 기존 권한을 며칠 안에 잃는지 지표로 볼 수 있는가.
service account와 robot account에 owner, rotation, scope가 붙는가.
조건부 접근 정책이 report-only 모드에서 enforce 모드로 넘어갈 때 rollback 기준이 있는가.
SIEM이나 XDR로 보낼 event 범위를 severity와 민감도로 나눌 수 있는가.

실무 시나리오 1: 퇴사자가 협업 SaaS와 cloud console에 동시에 남아 있는 조직은 SSO보다 lifecycle deprovisioning을 먼저 잡아야 합니다.

실무 시나리오 2: 개발팀 관리자 계정이 production cloud와 CI/CD에 상시 접근하는 조직은 IAM 비교와 PAM·JIT 접근 설계를 같이 봐야 합니다.

운영팀 관점의 도입 순서

IAM 프로젝트는 로그인 전환 공지부터 시작하면 실패하기 쉽습니다.

먼저 계정 inventory와 권한 owner를 확정하고, 그다음 SSO, MFA, lifecycle, access review 순서로 좁게 적용해야 rollback이 가능합니다.

상위 20개 SaaS, cloud console, 내부 관리자 도구를 뽑고 user count, admin count, owner, 현재 인증 방식을 기록한다.
HR 시스템, AD 또는 directory, SaaS 계정 목록 중 어떤 데이터가 source of truth인지 정한다.
관리자 계정과 일반 계정을 분리하고, 공유 계정과 local admin 계정을 migration backlog에 넣는다.
report-only 조건부 접근 정책으로 위험 로그인, 미등록 기기, 외부 IP, 외주 계정 예외를 관찰한다.
재무 또는 개발자 플랫폼처럼 위험과 효과가 큰 2~3개 시스템만 SSO와 MFA enforce 대상으로 잡는다.
퇴사자 disable, 부서 이동자 권한 회수, 외주 계정 만료를 ticket evidence와 함께 자동화한다.
분기별 access review를 owner별로 돌리고, 예외에는 승인자와 만료일을 필수로 둔다.
정책 변경, 로그인 실패, MFA 초기화, 관리자 권한 부여 event를 SIEM 또는 감사 저장소로 보낸다.

이 순서가 느려 보일 수 있지만, 전체 직원에게 한 번에 MFA를 강제한 뒤 헬프데스크가 터지는 방식보다 실제로는 더 빠릅니다.

특히 외주와 협력사 계정은 조직도 밖에 있어 HR 이벤트만으로 닫히지 않으므로 계약 종료일과 시스템 owner 확인을 별도로 둬야 합니다.

제품 유형별로 다르게 봐야 할 포인트

유형	대표 평가 포인트	잘 맞는 상황	주의할 점
Workforce IAM	SSO, MFA, lifecycle, access review, SaaS connector	임직원 앱이 많고 퇴사자 계정 회수가 늦다	Cloud 권한 세부 통제까지 한 번에 해결한다고 보면 위험하다
Cloud IAM	resource role, service account, audit log, policy condition	cloud console과 workload 권한이 핵심 위험이다	임직원 SaaS lifecycle과 헬프데스크 흐름은 별도 설계가 필요하다
Customer IAM	회원 로그인, API, consent, social login, developer SDK	고객 서비스 로그인과 개발자 통합이 중요하다	내부 직원 권한 검토와 같은 기준으로만 보면 비교가 틀어진다
Identity governance	권한 요청, 승인, access review, SoD, 감사 증거	규제 감사와 승인 이력이 자주 필요하다	기초 directory와 앱 owner가 없으면 workflow만 복잡해진다
PAM·JIT 접근	특권 계정, session, approval, emergency access	관리자 권한과 production 변경 리스크가 크다	일반 사용자 SSO 대체품으로 보면 범위가 어긋난다

AWS 공식 IAM 설명은 cloud resource 접근 통제에 초점이 있고, Microsoft Entra와 Okta 설명은 workforce identity 흐름과 더 직접적으로 연결됩니다.

Google Cloud IAM도 cloud resource 권한을 세밀하게 다루므로, SaaS 계정 lifecycle 프로젝트와는 별도 평가표를 두는 편이 낫습니다.

Auth0는 고객 identity와 애플리케이션 개발 통합의 맥락이 강하므로, 내부 직원 SSO와 같은 체크리스트만으로 평가하면 비용과 리스크가 잘못 잡힙니다.

도입 전 정책 스켈레톤

아래 예시는 바로 배포하는 설정이 아니라 IAM 솔루션 비교 전에 내부 기준을 맞추기 위한 검토용 스켈레톤입니다.

# iam-intake-policy.yml
# 목적: IAM 솔루션 비교 전에 계정 수명주기, 인증 강도, 권한 승인, 감사 증거 범위를 한 번에 맞춘다.
# 실제 속성명, 그룹명, API 이름은 선택한 공급사 공식 문서와 내부 보안 규정에 맞게 바꾼다.

identity_lifecycle:
  source_of_truth: hr_system
  joiner:
    required_fields:
      - employee_id
      - department
      - manager
      - employment_type
    default_access: baseline_only
  mover:
    trigger: department_or_role_change
    remove_previous_role_after_days: 3
    require_manager_reapproval: true
  leaver:
    disable_account_within_hours: 4
    revoke_sessions: true
    preserve_audit_logs: true

access_policy:
  sso_required: true
  mfa_required:
    admins: phishing_resistant
    finance: strong_mfa
    contractors: step_up_mfa
  privileged_access:
    standing_admin: forbidden
    just_in_time_minutes: 60
    approval_required: true
  conditional_access:
    unknown_device: block_or_step_up
    impossible_travel: step_up_and_alert
    risky_ip: block_admin_login

audit_evidence:
  access_request_ticket: required
  approval_owner: manager_and_system_owner
  quarterly_review: required
  exception_expiry_date: required

identity_lifecycle에서 source_of_truth가 비어 있으면 어떤 제품을 골라도 퇴사자 회수와 부서 이동자 권한 정리가 수동 작업으로 남습니다.

access_policy는 처음부터 완벽할 필요는 없지만, 관리자와 외주 계정은 일반 사용자보다 먼저 별도 기준을 가져야 합니다.

IAM 준비도 점검 스크립트 스켈레톤

아래 코드는 실제 제품 API를 호출하지 않고, PoC 전 회의에서 빠진 질문을 점수로 보여주는 예시입니다.

# iam_readiness_check.py
# 목적: 특정 제품을 평가하는 코드가 아니라 IAM 도입 준비도를 회의 안건으로 바꾸는 점검 스켈레톤이다.
# 입력은 HR master, IdP export, SaaS admin export, ticket export, SIEM alert export에서 가져온다고 가정한다.

CHECKS = {
    "hr_source_of_truth_defined": 15,
    "sso_coverage_measured": 15,
    "mfa_policy_by_risk_defined": 15,
    "joiner_mover_leaver_owner_defined": 15,
    "privileged_access_separated": 15,
    "approval_and_exception_expiry_logged": 10,
    "audit_export_tested": 10,
    "break_glass_account_reviewed": 5,
}

sample = {
    "hr_source_of_truth_defined": True,
    "sso_coverage_measured": False,
    "mfa_policy_by_risk_defined": True,
    "joiner_mover_leaver_owner_defined": True,
    "privileged_access_separated": False,
    "approval_and_exception_expiry_logged": True,
    "audit_export_tested": False,
    "break_glass_account_reviewed": True,
}

def score(readiness):
    return sum(weight for key, weight in CHECKS.items() if readiness.get(key))

ready_score = score(sample)
if ready_score < 75:
    print("pilot first: fix SSO coverage, privileged access, and audit export before broad rollout")
else:
    print("start limited IAM pilot with lifecycle workflow and access review evidence")

점수가 낮으면 제품이 나쁘다는 뜻이 아니라 SSO 범위, 특권 접근, 감사 export 같은 사전 질문이 빠졌다는 뜻으로 해석해야 합니다.

이 조건이면 PoC를 시작해도 됩니다: 상위 앱 owner가 정해졌고, report-only 정책으로 실패 로그를 먼저 볼 수 있으며, rollback 계정이 문서화되어 있습니다.

Rollout runbook 예시

IAM 도입은 보안팀 혼자 끝내기 어렵기 때문에 rollout 문서를 만들어 HR, IT 운영, 플랫폼, 각 시스템 owner가 같은 표를 보게 해야 합니다.

# iam-rollout-runbook.md
# 목적: IAM 솔루션을 로그인 화면 교체가 아니라 권한 수명주기와 감사 증거 프로젝트로 운영한다.

phase_1_inventory:
  target: top_20_saas_and_cloud_accounts
  output:
    - user_count_by_system
    - admin_count_by_system
    - sso_enabled_or_local_account
    - mfa_method
    - owner

phase_2_policy:
  admin_login: phishing_resistant_mfa
  contractor_access: expiry_required
  shared_account: migration_plan_required
  service_account: owner_and_rotation_required
  emergency_account: sealed_review_every_30_days

phase_3_pilot:
  scope:
    - finance_saas
    - cloud_admin_console
    - developer_platform
  mode: report_only_then_enforce
  rollback:
    - keep_break_glass_account
    - preserve_previous_sso_app_config
    - notify_service_owner_before_enforcement

phase_4_review:
  metrics:
    - sso_coverage_ratio
    - dormant_admin_count
    - access_review_completion_ratio
    - leaver_disable_time
    - exception_age

runbook에서 break-glass 계정을 남기는 이유는 장애 시 복구 경로를 지키기 위해서입니다.

다만 emergency account는 sealed review와 주기적 점검이 없으면 공격자가 가장 좋아하는 우회 계정이 됩니다.