3. CIAM 핵심 기능 7가지: 인증·인가·프로파일·MFA·동의·셀프서비스·감사
CIAM(Customer Identity and Access Management) 솔루션을 평가할 때 흔한 실수는 기능 목록만 확인하는 것입니다. 로그인, 소셜 로그인, MFA, 동의 관리 기능이 각각 존재하더라도 고객 여정과 보안 정책이 하나의 일관된 흐름으로 연결되지 않으면 운영 복잡성과 사용자 불편이 커질 수 있습니다.
이 글에서는 CIAM에서 자주 요구되는 핵심 기능을 7개 영역으로 나누고, 각 기능의 역할·구현 포인트·위험·도입 판단 기준을 정리합니다. 특정 MAU 숫자나 하나의 보안수준을 모든 조직에 적용하기보다 서비스 위험도, 사용자 경험, 개인정보 처리범위, 규제·운영 요구에 따라 선택하는 것이 핵심입니다.
아래의 기능 구분과 도입 순서는 CIAM 설계를 위한 실무 프레임워크입니다. 특정 벤더나 표준기관이 제시한 공식 7개 기능 목록이 아니며, 실제 우선순위는 조직별 위험·규모·업무특성에 따라 달라질 수 있습니다.
1. 기능 1 — 인증 (Authentication)
인증은 “현재 접근하려는 사용자가 주장하는 계정의 정당한 사용자인가”를 확인하는 기능입니다. CIAM에서는 비밀번호, OTP, 소셜 로그인, FIDO 기반 인증, passkey 등 여러 authenticator를 사용할 수 있습니다.
| 방식 | 주요 특징 | 실무 고려사항 |
|---|---|---|
| Password | 보편적이고 호환성이 높음 | password reuse, phishing, credential stuffing 위험에 대비한 보완통제 필요 |
| Social / Federated Login | 가입·로그인 마찰을 줄일 수 있음 | 외부 IdP 의존, account linking, recovery 정책 확인 |
| SMS / Voice OTP | 사용자 접근성이 높음 | NIST SP 800-63B-4에서 PSTN 기반 out-of-band 인증은 restricted authenticator로 취급 |
| TOTP / Authenticator App | 별도 authenticator를 통한 추가 factor | phishing-resistant는 아니므로 위험도가 높은 환경에서는 추가 대책 검토 |
| FIDO2 / Passkey | 공개키 기반, phishing-resistant | account recovery, device migration, fallback 경로까지 함께 설계 |
NIST SP 800-63B-4는 2025년 최종판으로 개정되었고, AAL2에서는 phishing-resistant authentication option을 제공하도록 요구합니다. AAL3에서는 phishing-resistant authenticator가 필요합니다. Passkey/FIDO2는 verifier name binding을 이용하는 phishing-resistant 방식의 대표 예입니다.
중요: “단일 인증 환경에서 계정탈취 사고의 80% 이상이 발생한다” 같은 수치는 직접 검증 가능한 원출처가 없으면 사용하지 않는 편이 적절합니다. 대신 서비스별 위험평가에 따라 MFA 또는 phishing-resistant authentication을 적용하는 것이 더 정확합니다.
2. 기능 2 — 인가 (Authorization)
인가는 인증된 사용자가 어떤 리소스에 어떤 행동을 할 수 있는가를 결정합니다. CIAM에서는 RBAC, ABAC, ReBAC 같은 여러 모델을 사용할 수 있으며 한 방식이 모든 서비스에 항상 우월한 것은 아닙니다.
| 모델 | 예시 | 적합한 상황 |
|---|---|---|
| RBAC | 일반회원 / 프리미엄 / 관리자 | 역할 구조가 비교적 명확한 서비스 |
| ABAC | 회원등급 + 국가 + 기기 + 시간 + risk signal | 조건 기반 정책이 필요한 서비스 |
| ReBAC | 사용자와 리소스의 소유·공유·조직 관계 | 협업·공유형 서비스 |
실무 포인트: 인가 규칙이 여러 애플리케이션에 중복 하드코딩되면 변경 누락 가능성이 커질 수 있습니다. 공통 정책이 많은 환경에서는 중앙 authorization service 또는 policy engine이 유용할 수 있지만, 모든 권한 판단을 반드시 CIAM 한 곳에서 수행해야 하는 것은 아닙니다. 업무 도메인에 종속적인 권한은 애플리케이션 또는 별도 policy layer에서 관리할 수도 있습니다.
OAuth 2.0을 사용하는 경우에는 2025년에 발표된 RFC 9700(OAuth 2.0 Security BCP)의 권고사항도 확인하는 것이 좋습니다. 예를 들어 redirect URI exact matching, PKCE, token replay 방지 등 기존 OAuth 보안 권고가 최신화되어 있습니다.
3. 기능 3 — 회원가입 및 프로파일 관리
CIAM의 프로파일 관리는 가입정보를 저장하는 것에 그치지 않고 계정 생성, 검증, 속성 변경, account linking, recovery, 폐기까지 고객 identity lifecycle을 관리합니다.
| 기능 | 설계 포인트 |
|---|---|
| Progressive Profiling | 가입 시 필요한 최소정보부터 수집하고 추가정보는 실제 필요시점에 요청 |
| Account Linking | 소셜·이메일·기존회원 계정이 동일인인지 검증 후 연결 |
| Profile Synchronization | CRM·CDP·마케팅 시스템과 변경 이벤트를 어떻게 동기화할지 정의 |
| Data Quality | 이메일·전화번호 검증, 중복 탐지, required attribute 관리 |
| Recovery | 계정복구가 강한 인증을 우회하는 약한 통로가 되지 않도록 설계 |
ID Stitching 주의: 동일 고객의 여러 계정을 하나로 병합하는 경우 오탐 병합은 계정 탈취나 개인정보 노출로 이어질 수 있으므로 confidence, evidence, reversible merge, human review 등의 통제가 필요할 수 있습니다.
4. 기능 4 — MFA·패스키·위험기반 인증
MFA와 passkey를 선택할 때는 단순히 “보안 강도 높음/낮음”만 볼 것이 아니라 phishing resistance, 사용자 마찰, 복구경로, 기기 제약, 업무 위험도를 함께 봐야 합니다.
| 방식 | Phishing Resistance | 설계 고려사항 |
|---|---|---|
| SMS OTP | 낮음 | 접근성은 높지만 SIM swap·번호이동 등 위험을 고려. NIST에서는 restricted |
| Email OTP | 낮음 | 이메일 계정 보안에 의존. NIST의 out-of-band authenticator로는 사용하지 않음 |
| TOTP | 낮음 | SMS보다 운영상 이점이 있을 수 있으나 manual code entry는 phishing-resistant가 아님 |
| Push MFA | 구현에 따라 다름 | push fatigue, number matching, device binding 등을 검토 |
| Passkey / FIDO2 | 높음 | origin-bound 공개키 인증. recovery·fallback이 약하면 전체 보안수준이 낮아질 수 있음 |
위험기반 인증(RBA): RBA는 새 기기, 비정상 위치, 행동패턴 등 risk signal에 따라 step-up authentication을 요구하는 유용한 방식입니다. 그러나 “모든 로그인에는 MFA를 적용하지 말고 RBA만 적용하는 것이 최선”이라는 하나의 정답은 없습니다. 업무 위험도와 assurance level에 따라 지속적인 MFA나 phishing-resistant authentication이 더 적절할 수도 있습니다.
5. 기능 5 — 동의·개인정보 관리
CIAM의 개인정보 관리에서 가장 중요한 원칙은 모든 개인정보 처리를 동의에 의존하지 않는 것입니다. 한국 개인정보보호법과 GDPR 모두 동의 외의 법적 처리근거를 두고 있으므로, 먼저 처리 목적과 legal basis를 구분해야 합니다.
| 단계 | CIAM 설계 |
|---|---|
| Legal Basis | 계약 이행, 동의, 법적 의무 등 목적별 처리근거 분류 |
| Consent Collection | 동의가 필요한 경우 목적·항목을 명확하게 구분 |
| Evidence | 동의문 버전, 시점, 채널, 목적을 재현 가능한 형태로 기록 |
| Withdrawal | 철회 경로를 제공하고 동의 기반 처리를 관련 시스템에서 중단 |
| Propagation | CRM·마케팅·분석 등 downstream 시스템에 최신 상태를 전파 |
중앙화된 consent/preference service는 일관성과 감사성을 높이는 유용한 설계지만, 법이 특정 기술구조를 강제하는 것은 아닙니다. 핵심은 source of truth, 증적, 철회, 시스템 전파가 일관되게 동작하는가입니다.
GDPR의 높은 과징금 상한은 특정 위반 유형에 적용되는 법정 최대치입니다. 따라서 “마케팅 이메일 1건 오발송 = 전 세계 매출 4% 과징금”처럼 단순화해서는 안 됩니다.
6. 기능 6 — 셀프서비스
셀프서비스는 고객이 계정·보안·프로파일·동의 관련 기능을 직접 관리하게 해 운영 부담을 줄이고 사용자 통제권을 높이는 기능입니다.
| 영역 | 가능한 기능 |
|---|---|
| Account Security | 비밀번호 변경, passkey/MFA 관리, 활성 세션 확인·종료 |
| Recovery | 검증된 계정복구, recovery channel 관리 |
| Profile | 프로파일 수정, 연결된 계정 확인 |
| Privacy / Consent | 동의·선호 설정 확인 및 철회 |
| Rights Request | 적용 법령과 조직 프로세스에 따라 열람·삭제·처리정지 등 요청 접수 |
셀프서비스는 반드시 별도 웹페이지 하나로 구현할 필요는 없습니다. 모바일 앱, 웹 계정센터, 고객지원 연계 등 여러 UX가 가능합니다. 중요한 것은 본인확인 수준, 권리요청 처리흐름, recovery abuse 방지입니다.
GDPR Article 12는 정보주체 권리 요청에 대해 원칙적으로 1개월 이내 대응하도록 하고, 복잡성·요청 수를 고려해 추가 연장이 가능한 구조를 둡니다. Article 17의 삭제권 역시 예외 없이 모든 데이터를 무조건 즉시 삭제하도록 요구하는 규정은 아닙니다.
7. 기능 7 — 감사 로그·관측가능성
감사 로그는 보안사고 조사와 운영 분석을 위해 인증·인가·계정변경·관리자행위·동의 변경 등의 이벤트를 추적하는 기능입니다.
- 로그인 성공·실패 및 관련 risk signal
- password·passkey·MFA 등록·해제·recovery
- 동의·선호 설정 변경
- 프로파일·계정 상태 변경
- 관리자의 계정 접근·변경
- authorization policy 변경
- 대량 export·삭제·민감 action
로그 무결성: audit trail의 변조 방지는 중요하지만 모든 CIAM 로그가 법적으로 WORM 또는 완전 immutable storage에 있어야 하는 것은 아닙니다. 접근통제, append-only 설계, tamper-evident storage, SIEM 연계 등 조직의 위험과 규제에 맞는 통제를 선택할 수 있습니다.
또한 GDPR Article 30의 “records of processing activities”와 CIAM의 기술 audit log는 동일한 개념이 아닙니다. 개인정보 처리활동 기록 의무를 곧바로 “모든 로그인 로그를 특정 방식으로 보존해야 한다”는 규정으로 해석해서는 안 됩니다.
8. 도입 우선순위 — MAU보다 Risk Tier
CIAM 기능의 도입순위를 `MAU 10만`, `MAU 100만` 같은 하나의 사용자 수 기준으로 정하는 것은 적절하지 않습니다. 가입자가 적어도 금융·의료·고위험 서비스라면 강한 인증·감사가 먼저 필요할 수 있고, 가입자가 매우 많아도 서비스 위험이 낮으면 다른 우선순위가 가능하기 때문입니다.
아래는 통계적 maturity model이 아니라 기능 우선순위를 정하기 위한 예시입니다.
| 단계 | 주요 질문 | Exit Criteria 예시 |
|---|---|---|
| Foundation | 안전한 인증·recovery·기본 audit가 있는가 | 핵심 계정 lifecycle이 통제됨 |
| Risk Control | MFA, passkey, authorization, abuse control이 위험도에 맞는가 | 주요 account takeover·privilege risk 통제가 운영됨 |
| Privacy & Self-Service | profile·consent·rights request를 사용자가 관리할 수 있는가 | 법적·운영 요구에 맞는 preference와 request flow가 있음 |
| Scale & Observe | 멀티리전, SIEM, event integration, 정책 중앙화가 필요한가 | 피크·장애·보안 이벤트를 측정·대응할 수 있음 |
즉, 사용자 수 자체보다 Account Takeover Risk, Transaction Impact, Privacy Scope, Geographic Reach, Recovery Risk, Operational Scale을 기준으로 우선순위를 정하는 것이 적절합니다.
9. 정리
CIAM의 핵심은 기능 개수가 아니라 인증 → 인가 → 프로파일 → 개인정보 → 셀프서비스 → 감사가 하나의 정책과 고객 여정으로 연결되는가에 있습니다.
사용자 경험과 보안·개인정보 정책이
일관되게 연결되는 Identity Platform입니다."
솔루션을 평가할 때는 “MFA가 있는가?” 같은 체크박스에서 끝내지 말고, 어떤 위험에서 어떤 authenticator를 요구하는지, account recovery가 동일한 보안 수준을 유지하는지, authorization·consent·audit가 채널 간 일관되게 작동하는지를 확인하는 것이 중요합니다.
- NIST — SP 800-63B-4: Authentication and Authenticator Management
- FIDO Alliance — Passkeys
- IETF / RFC Editor — RFC 9700 OAuth 2.0 Security BCP
- OpenID Foundation — OpenID Connect Core 1.0
- EUR-Lex — GDPR
- 국가법령정보센터 — 개인정보 보호법
- 개인정보보호위원회 — 개인정보 안내서
※ Reviewed: September 2026. NIST SP 800-63B-4, FIDO, RFC 9700, GDPR, 개인정보보호법 및 개인정보보호위원회 현행 안내자료를 기준으로 보완했습니다.
※ 기능 우선순위와 Risk Tier는 Digital Future & Strategy Practitioner View이며, 특정 산업 표준이나 통계모델이 아닙니다.
Comments
Post a Comment