SCIM 기반 아이덴티티 자동 프로비저닝(System for Cross-domain Identity Management)
1. 개요
가. 정의 및 등장 배경
SCIM(System for Cross-domain Identity Management)은 서로 다른 보안 도메인·서비스 사이에서 사용자·그룹 등 아이덴티티 자원의 생성·수정·조회·삭제(CRUD)를 자동화하기 위한 표준 프로토콜이자 스키마 규격이다. REST/JSON 기반의 경량 인터페이스로, 아이덴티티 공급자(IdP)가 보유한 계정 정보를 다수의 서비스 공급자(SP, 일반적으로 SaaS)로 밀어 넣어 계정 수명주기(provisioning/deprovisioning)를 일관되게 유지하는 것을 목적으로 한다. 요약하면 SAML·[[oauth2-oidc]]가 "로그인 순간에 사용자가 누구인지"를 전달하는 인증(Authentication) 프로토콜이라면, SCIM은 "로그인 이전에 어느 서비스에 어떤 계정이 존재해야 하는지"를 관리하는 프로비저닝(Provisioning) 프로토콜로서 서로를 보완한다.
SCIM이 등장한 근본 배경은 '인증을 통합해도 계정 자체의 생성·삭제는 여전히 수작업'이라는 운영 현실에 있다. SAML/OIDC로 SSO를 구축하면 사용자는 한 번의 인증으로 여러 SaaS에 접근할 수 있지만, 그 전제는 각 SaaS에 사용자의 계정과 권한이 미리 존재해야 한다는 것이다. 조직이 쓰는 SaaS가 수십~수백 개로 늘어나면, 신규 입사자 1명이 들어올 때마다 관리자가 서비스마다 수동으로 계정을 만들고, 퇴사자가 생기면 다시 서비스마다 계정을 삭제해야 한다. 이 수작업은 비효율적일 뿐 아니라 누락 시 심각한 보안 공백으로 이어진다 — 퇴사했는데도 특정 SaaS에 '유령 계정(orphan account)'이 남아 있으면 내부자 위협과 계정 탈취의 통로가 된다. SCIM은 이 계정 수명주기 관리를 표준 API로 자동화하여 이 문제를 구조적으로 해소한다.
역사적으로 SCIM 1.0/1.1은 2011~2012년 업계 컨소시엄(당시 'Simple Cloud Identity Management')에서 시작되었고, 이후 IETF로 이관되어 현재 사실상 표준인 SCIM 2.0이 2015년 9월 RFC 7643(Core Schema)과 RFC 7644(Protocol)로 제정되었다. 두 RFC는 모두 표준화 트랙(Standards Track) 문서이며, 1.1과는 하위 호환되지 않는다. 20년 가까운 역사의 SAML과 달리 SCIM은 비교적 최근 표준이지만, 클라우드·SaaS 전환이 가속되면서 Okta·Microsoft Entra ID(구 Azure AD)·Google Workspace 등 주요 IdP가 모두 SCIM 2.0을 채택하여 엔터프라이즈 계정 자동화의 사실상 표준으로 자리 잡았다.
나. 필요성
SCIM의 필요성은 운영 효율, 보안, 컴플라이언스의 세 관점에서 모두 설명된다. 운영 효율 관점에서는 입·퇴사·부서이동이라는 인사 이벤트 하나가 연동된 모든 SaaS 계정에 자동 반영되어, 관리자가 서비스마다 반복 작업을 할 필요가 사라진다. 수백 개 SaaS를 쓰는 대기업에서 이 자동화는 단순한 편의를 넘어 운영 가능성(operability) 자체의 전제 조건이 된다.
보안 관점의 필요성이 특히 중요하다. 수작업 계정 삭제는 반드시 누락을 낳고, 누락된 계정은 모니터링되지 않는 공격 표면이 된다. SCIM을 통해 퇴사 즉시 IdP에서 사용자를 비활성화하면 연동된 모든 SP의 계정이 자동으로 비활성화·삭제되므로, 오프보딩의 적시성과 완전성이 보장된다. 이는 최소권한 원칙과 [[zero-trust]] 아키텍처가 요구하는 '권한의 적시 회수(just-in-time deprovisioning)'를 실현하는 핵심 메커니즘이다.
컴플라이언스 관점에서도 SCIM은 유용하다. [[isms-p]]·ISO 27001 등 다수 인증 체계는 접근 권한의 주기적 검토와 퇴사자 계정의 즉시 회수를 요구한다. SCIM 기반 자동 프로비저닝은 '누가·언제·어떤 서비스에 계정을 부여받고 회수되었는가'를 IdP 한 곳에 집중시켜, 감사 증적(audit trail) 확보와 접근권한 재인증(access review)을 체계화한다. 국내 금융·공공 기관의 그룹사 통합 계정 관리에서도 이러한 중앙집중식 수명주기 통제가 내부통제 요건 충족의 기반이 된다.
다. 핵심 특징
SCIM의 특징은 세 가지로 압축된다. 첫째는 REST/JSON 기반의 경량성으로, SOAP·XML 중심의 과거 프로비저닝 규격(SPML 등)과 달리 표준 HTTP 메서드(GET/POST/PUT/PATCH/DELETE)와 JSON 문서만으로 동작하여 구현·연동이 쉽다. 둘째는 표준화된 공통 스키마로, User·Group이라는 공통 리소스 모델과 확장(Enterprise User extension)을 정의하여 IdP와 SP가 속성 의미를 사전에 합의할 수 있게 한다. 셋째는 발견 가능성(discoverability)으로, /ServiceProviderConfig·/ResourceTypes·/Schemas 엔드포인트를 통해 SP가 지원하는 기능과 스키마를 런타임에 조회할 수 있어 느슨한 결합을 이룬다. 이 세 특징이 결합해 SCIM은 '합의된 스키마를 가벼운 REST로 주고받는' 상호운용성 중심의 프로비저닝 표준으로 기능한다.
2. SCIM의 전체 구조와 구성요소
SCIM은 단일 메시지 규격이 아니라 Schema(무엇을 표현하는가)·Protocol(어떻게 주고받는가)·역할자(누가 주고받는가)가 결합된 프레임워크로 이해해야 한다. 아래는 IdP를 SCIM 클라이언트로, SaaS를 SCIM 서버로 두는 전형적 배치의 전체 구조도이다.
flowchart LR
subgraph HR["인사·권한 원천"]
HRIS["인사 시스템(HRIS)"]
DIR["디렉터리(AD/LDAP)"]
end
subgraph IDPDOM["IdP 도메인 (SCIM 클라이언트)"]
IDP["아이덴티티 공급자(IdP)"]
ENG["프로비저닝 엔진"]
IDP --- ENG
end
subgraph SPDOM["서비스 도메인 (SCIM 서버)"]
SP1["SaaS A /Users /Groups"]
SP2["SaaS B /Users /Groups"]
SP3["SaaS C /Users /Groups"]
end
HRIS -->|"입·퇴사 이벤트"| IDP
DIR --- IDP
ENG -->|"SCIM REST(HTTPS, Bearer)"| SP1
ENG -->|"SCIM REST(HTTPS, Bearer)"| SP2
ENG -->|"SCIM REST(HTTPS, Bearer)"| SP3
이 구조의 핵심은 IdP가 권한의 단일 원천(source of truth)이 되고, 각 SaaS는 SCIM 서버로서 그 변경을 수신한다는 점이다. 인사 시스템(HRIS)에서 발생한 입·퇴사 이벤트가 IdP로 유입되면, IdP의 프로비저닝 엔진이 연동된 모든 SaaS에 대해 SCIM REST 호출을 수행한다. 여기서 SCIM 클라이언트(요청 주체)는 IdP, SCIM 서버(요청 수신·자원 보유)는 SaaS라는 역할 구분이 중요하다. 인증은 SAML/OIDC로 SP가 IdP를 신뢰하는 방향이지만, 프로비저닝은 거꾸로 IdP가 SP에 계정을 밀어 넣는 방향이라는 비대칭을 이해해야 한다.
가. 핵심 역할자 — SCIM 클라이언트와 SCIM 서버
SCIM의 두 주연은 SCIM 클라이언트(일반적으로 IdP·IGA 솔루션)와 SCIM 서버(일반적으로 SaaS·대상 애플리케이션)이다. 클라이언트는 사용자 디렉터리의 변경을 감지하여 서버로 전파하는 '능동적 발신자'이고, 서버는 표준 SCIM 엔드포인트(/Users, /Groups)를 노출하여 그 변경을 수용하는 '수동적 수신자'이다.
이 역할 구분은 SCIM의 보안·운영 모델을 규정한다. SCIM 서버인 SaaS는 자신의 계정 저장소에 대한 쓰기 권한을 외부 IdP에 위임하는 셈이므로, 서버는 호출 주체를 강하게 인증(보통 OAuth 2.0 Bearer 토큰)하고 최소 권한만 부여해야 한다. 반대로 IdP는 다수 SaaS의 자격증명(토큰)을 보관하는 '프로비저닝 허브'가 되므로, IdP 자체가 전사 계정의 단일 통제점이자 단일 위험점이 된다. IdP의 프로비저닝 토큰이 유출되면 연동된 모든 SaaS 계정을 조작당할 수 있으므로, 토큰의 안전한 보관([[secrets-management]])과 권한 범위 최소화가 필수다.
나. 공통 자원 모델 — User와 Group
SCIM Core Schema(RFC 7643)는 모든 아이덴티티를 표현하는 공통 리소스로 User와 Group을 정의하며, 각 리소스는 공통 속성과 리소스별 속성을 갖는다. 아래는 핵심 자원의 대표 속성을 정리한 것이다.
| 리소스 | 핵심 속성 | 의미 | 비고 |
|---|---|---|---|
| 공통(Common) | id, externalId, meta |
서버측 고유 ID·클라이언트측 ID·메타정보 | 모든 리소스 공통 |
| User | userName, name, emails, active, groups |
로그인명·이름·이메일·활성여부·소속그룹 | active:false가 비활성화 핵심 |
| Group | displayName, members |
그룹명·구성원 목록 | 역할·권한 매핑의 단위 |
| Enterprise 확장 | employeeNumber, department, manager |
사번·부서·관리자 | 기업 환경용 표준 확장 |
표의 속성 중 실무적으로 가장 중요한 것은 active와 externalId다. active 속성은 계정의 활성/비활성을 나타내며, 퇴사 처리 시 계정을 완전히 삭제(DELETE)하는 대신 active:false로 비활성화(soft-delete)하는 것이 일반적이다. 데이터 보존 의무나 재입사 가능성 때문에 즉시 삭제보다 비활성화가 선호되기 때문이다. externalId는 클라이언트(IdP)가 자신의 기준으로 부여한 식별자로, 서버가 부여한 id와 짝을 이뤄 양측 계정을 안정적으로 대응(correlation)시키는 데 쓰인다. 이 대응 키 설계가 잘못되면 동일 사용자에 대해 중복 계정이 생성되는 운영 사고로 직결된다.
다. 서비스 발견 엔드포인트
SCIM 서버는 자원 엔드포인트 외에 구성 발견용 엔드포인트를 제공한다. /ServiceProviderConfig는 서버가 PATCH·bulk·filter·정렬·변경이력 등 어떤 선택 기능을 지원하는지 선언하고, /ResourceTypes는 서버가 다루는 리소스 종류를, /Schemas는 각 리소스의 속성 정의를 노출한다. 이를 통해 클라이언트는 서버의 능력을 하드코딩하지 않고 런타임에 질의할 수 있어, 서로 독립적으로 진화하는 느슨한 결합이 가능하다. 실무에서는 모든 SaaS가 SCIM 전체 스펙을 동일하게 구현하지는 않기 때문에, 이 발견 엔드포인트를 통해 '이 SaaS가 PATCH를 지원하는가' 같은 차이를 흡수하는 것이 연동 안정성의 관건이 된다.
3. SCIM 프로비저닝 수명주기와 동작 절차
SCIM의 가치는 계정의 생성(onboarding) → 변경(update) → 비활성화(offboarding)로 이어지는 수명주기를 이벤트 기반으로 자동화하는 데 있다. 아래 시퀀스 다이어그램은 입사·부서이동·퇴사 세 이벤트가 SCIM 호출로 전파되는 전형적 흐름을 보여준다.
sequenceDiagram
participant HR as "인사 시스템(HRIS)"
participant IDP as "IdP(SCIM 클라이언트)"
participant SP as "SaaS(SCIM 서버)"
HR->>IDP: ① 신규 입사(사용자 생성)
IDP->>SP: ② POST /Users (active:true)
SP-->>IDP: ③ 201 Created (id 반환)
HR->>IDP: ④ 부서 이동(속성 변경)
IDP->>SP: ⑤ PATCH /Users/{id} (department)
SP-->>IDP: ⑥ 200 OK
HR->>IDP: ⑦ 퇴사(계정 회수)
IDP->>SP: ⑧ PATCH /Users/{id} (active:false)
SP-->>IDP: ⑨ 200 OK (즉시 접근 차단)
위 흐름에서 ①③의 온보딩 단계는 입사자가 생기면 IdP가 대상 SaaS에 ⑥의 변경 단계에서는 부서 이동 같은 속성 변화가 발생하면 POST /Users로 계정을 생성하고, 서버는 고유 id를 발급해 반환한다. 이 id는 이후 변경·삭제 호출의 대상 식별자로 쓰이므로 IdP가 반드시 보관한다. ④PATCH로 바뀐 속성만 부분 갱신한다. 전체 리소스를 교체하는 PUT 대신 PATCH를 쓰는 이유는 네트워크 효율과 동시성 안전성 때문인데, 여러 시스템이 같은 사용자를 건드릴 때 변경 부분만 보내야 다른 속성의 덮어쓰기(lost update)를 막을 수 있다.
⑦~⑨의 오프보딩 단계가 보안상 가장 중요하다. 퇴사 이벤트가 유입되면 IdP는 즉시 PATCH /Users/{id}로 active:false를 전파하여 해당 사용자의 SaaS 접근을 실시간에 가깝게 차단한다. 여기서 핵심 설계 쟁점은 '완전 삭제(DELETE) vs 비활성화(soft-delete)'의 선택이다. 완전 삭제는 흔적을 남기지 않아 깔끔하지만, 감사·법적 보존·재입사 대응이 어렵다. 반대로 비활성화는 데이터와 증적을 보존하되 '비활성 계정이 다시 활성화될 위험'을 관리해야 한다. 대부분의 기업은 즉시 비활성화 후 일정 유예기간 경과 시 삭제하는 2단계 정책을 쓴다.
4. SCIM 프로토콜 연산과 스키마 상세
SCIM 2.0 프로토콜(RFC 7644)은 표준 HTTP 메서드에 프로비저닝 의미를 부여한다. 각 연산의 역할과 실무적 주의점은 다음과 같다.
| HTTP 메서드 | 엔드포인트 예 | 역할 | 주의점 |
|---|---|---|---|
| POST | /Users |
신규 생성 / 복합 검색(.search) |
생성 시 중복 방지(멱등성 아님) |
| GET | /Users/{id}, /Users?filter= |
조회·필터링 | 대량 조회 시 페이징 필수 |
| PUT | /Users/{id} |
전체 교체 | 누락 속성 삭제 위험 |
| PATCH | /Users/{id} |
부분 갱신 | 동시성 안전·권장 방식 |
| DELETE | /Users/{id} |
삭제 | soft-delete 선호 |
| POST | /Bulk |
다건 일괄 처리 | 서버 지원 여부 확인 필요 |
연산 설계에서 가장 흔한 함정은 POST 생성의 비멱등성이다. 네트워크 오류로 응답을 받지 못한 IdP가 POST /Users를 재시도하면 동일 사용자가 중복 생성될 수 있다. 이를 막으려면 서버가 userName·externalId의 유일성을 강제하거나, 클라이언트가 생성 전 filter로 존재 여부를 확인해야 한다([[idempotency]] 설계와 직결). 또한 필터링은 GET /Users?filter=userName eq "hong@corp.com" 형태의 SCIM 전용 필터 문법을 쓰며, 대량 사용자 환경에서는 startIndex·count 기반 페이징과 결합하지 않으면 성능 문제가 발생한다.
스키마 측면에서 SCIM 리소스는 항상 schemas 속성으로 자신이 따르는 스키마 URN을 선언한다. 예컨대 표준 User는 urn:ietf:params:scim:schemas:core:2.0:User를, 기업 확장은 urn:ietf:params:scim:schemas:extension:enterprise:2.0:User를 함께 선언한다. 이 URN 기반 스키마 선언 덕분에 한 리소스가 코어 스키마와 여러 확장을 동시에 담을 수 있고, 서버는 이를 보고 어떤 속성을 해석할지 결정한다. 조직 고유 속성이 필요하면 커스텀 스키마 URN을 정의해 확장할 수 있으나, 확장을 남발하면 SaaS 간 상호운용성이 깨지므로 표준 Enterprise 확장 범위에서 해결하는 것이 바람직하다.
5. 비교 — JIT 프로비저닝·SPML과의 관계
SCIM을 올바로 이해하려면 대안 방식과의 차이를 그 차이가 생기는 이유까지 짚어야 한다. 가장 자주 비교되는 것은 JIT(Just-In-Time) 프로비저닝이다. JIT는 사용자가 SSO로 SaaS에 처음 로그인하는 순간, SAML/OIDC 토큰에 담긴 속성을 보고 SaaS가 그 자리에서 계정을 생성하는 방식이다.
| 구분 | SCIM | JIT 프로비저닝 |
|---|---|---|
| 계정 생성 시점 | 사전(로그인 이전) | 최초 로그인 순간 |
| 비활성화(오프보딩) | 능동·즉시 가능 | 불가(로그인 안 하면 삭제 못함) |
| 사전 권한 부여 | 가능 | 불가(로그인 전엔 계정 없음) |
| 구현 복잡도 | 높음(별도 API 연동) | 낮음(SSO에 편승) |
이 비교의 핵심은 오프보딩의 비대칭성에 있다. JIT는 "로그인할 때 계정을 만든다"는 발상이므로, 반대로 "퇴사자가 더 이상 로그인하지 않을 때 계정을 지운다"는 동작은 원천적으로 불가능하다. 즉 JIT만으로는 유령 계정을 제거할 수 없어 보안 공백이 남는다. 따라서 실무에서는 온보딩은 JIT로 간편하게, 오프보딩과 사전 권한 관리는 SCIM으로 병행하는 조합이 권장된다. 예컨대 Okta·Entra ID는 두 방식을 모두 지원하며, 보안이 중요한 조직은 SCIM 기반 능동 프로비저닝을 기본으로 둔다.
또 다른 비교 대상은 SPML(Service Provisioning Markup Language)이다. SPML은 2000년대 초 OASIS가 만든 XML/SOAP 기반 프로비저닝 표준이었으나, 무겁고 구현이 복잡해 사실상 폐기되었다. SCIM이 성공한 결정적 이유는 바로 이 'SPML의 실패를 교훈 삼아 REST/JSON으로 경량화'한 데 있다. 즉 SCIM의 설계 철학은 "완벽한 표현력보다 구현 용이성과 상호운용성"이며, 이 선택이 SaaS 생태계 전반의 광범위한 채택을 이끌어냈다.
6. 심화 — 최신 동향과 실무 적용
SCIM 생태계의 최신 동향은 이벤트 기반 비동기 프로비저닝으로의 진화다. 기존 SCIM은 IdP가 SaaS로 변경을 밀어 넣는 폴링·푸시 중심이었으나, IETF SCIM 워킹그룹은 draft-ietf-scim-events(SCIM Profile for Security Event Tokens)를 통해 비동기 요청(Asynchronous SCIM Request)과 보안 이벤트 토큰(SET) 기반의 변경 전파를 표준화하고 있다(2025년 기준 RFC 편집자 큐 단계). 이는 [[zero-trust]]가 요구하는 '세션 중 실시간 권한 변화 반영'과 공유 신호(Shared Signals, CAEP) 생태계와 맞물려, 단순 계정 동기화를 넘어 '위협 발생 시 즉시 접근 회수'로 확장되는 흐름이다. 다만 초안 단계이므로 세부 사양은 변동 가능성이 있다.
실무 적용 사례로는 대표적으로 Microsoft Entra ID가 SCIM을 '자동 사용자 프로비저닝'의 표준 커넥터로 삼아 수천 종 SaaS와 연동하는 사례, Okta가 SCIM과 사전 통합(pre-built integration) 카탈로그를 제공해 연동 부담을 낮춘 사례, Slack·Zoom·GitHub Enterprise 등이 SCIM 서버를 노출해 기업 고객의 계정 자동화를 지원하는 사례가 있다. 국내에서도 그룹사 통합 계정관리(IAM/IGA) 구축 시 계열사·SaaS 간 계정 동기화에 SCIM을 채택하는 사례가 늘고 있다. 특히 IGA(Identity Governance and Administration) 솔루션은 SCIM을 '권한 거버넌스의 실행 채널'로 활용하여, 접근권한 검토 결과를 SCIM 호출로 즉시 반영한다.
예상 출제 방향으로는 ① SCIM과 SAML/OIDC의 역할 구분(프로비저닝 vs 인증)을 묻는 비교형, ② 계정 수명주기 자동화와 오프보딩 보안을 묻는 통제형, ③ 제로 트러스트·IGA와의 연계를 묻는 통합형이 유력하다. 답안 작성 시에는 '인증과 프로비저닝은 별개이며 SCIM이 후자를 담당한다'는 핵심 구도를 먼저 제시하고, 오프보딩 자동화의 보안적 가치를 중심에 두는 전략이 효과적이다.
7. 고려사항 및 시사점
SCIM을 기술사 관점에서 도입·운영할 때 고려할 전략적 쟁점은 다음과 같다.
- 단일 원천(SoT) 정립과 권한 거버넌스 연계: SCIM은 '권한을 어디서 결정하는가'를 정하지 않는다. IdP·HRIS·IGA 중 무엇을 권한의 단일 원천으로 둘지 먼저 정의하고, SCIM은 그 결정을 실행하는 채널로만 쓰는 아키텍처 원칙이 선행되어야 한다. 원천이 분산되면 계정 상태 불일치가 발생한다.
- 대응 키(correlation) 설계와 데이터 품질:
externalId↔id매핑 설계가 잘못되면 중복 계정·고아 계정이 양산된다. 입사 전 임시 계정, 사번 변경, 재입사 같은 경계 사례(edge case)에 대한 대응 키 정책을 사전에 수립해야 하며, 이는 결국 인사 데이터의 품질 문제로 귀결된다. - 프로비저닝 토큰 보안과 공격 표면: IdP는 다수 SaaS의 쓰기 권한 토큰을 보관하는 고가치 표적이 된다. 토큰은 최소 권한(필요한 리소스·연산만)으로 발급하고, 안전 저장소([[secrets-management]])에 보관하며, 정기 교체·이상 탐지를 적용해야 한다. 프로비저닝 경로 자체가 공급망 공격의 통로가 될 수 있음을 유의한다.
- 표준 준수 수준의 편차와 상호운용성: 모든 SaaS가 SCIM 2.0 전체(PATCH·bulk·filter)를 동일하게 구현하지 않는다.
/ServiceProviderConfig기반으로 각 서버의 능력을 확인하고, 미지원 기능은 우회 로직으로 흡수하는 연동 설계가 필요하다. 연동 전 적합성 시험(conformance test)을 권장한다. - 점진적 확산과 폴백 전략: 전사 SaaS를 한 번에 SCIM으로 전환하기는 어렵다. 보안 중요도가 높은 서비스부터 단계적으로 적용하고, SCIM 미지원 레거시는 JIT·수동 절차를 병행하는 하이브리드 운영이 현실적이다. 장애 시 수동 회수 절차(런북)를 반드시 백업으로 둔다.
참고자료
- RFC 7643, System for Cross-domain Identity Management: Core Schema, IETF, 2015. https://www.rfc-editor.org/rfc/rfc7643
- RFC 7644, System for Cross-domain Identity Management: Protocol, IETF, 2015. https://www.rfc-editor.org/rfc/rfc7644
- draft-ietf-scim-events, SCIM Profile for Security Event Tokens, IETF SCIM WG. https://datatracker.ietf.org/doc/draft-ietf-scim-events/
- Microsoft, What is SCIM provisioning in Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity/app-provisioning/
한 줄 요약: SCIM은 REST/JSON 기반 공통 스키마(User·Group)와 표준 연산으로 IdP↔SaaS 간 계정의 생성·변경·비활성화 수명주기를 자동화하는 프로비저닝 표준으로, 인증을 담당하는 SAML/OIDC와 보완 관계를 이루며 특히 오프보딩 자동화로 제로 트러스트·IGA 보안의 핵심 통제를 실현한다.