SCIM 개요 — SCIM 토큰, 프로비저닝 및 인증

SCIM 2.0(System for Cross-domain Identity Management)은 신원 공급자와 SecureCodingHub 간에 사용자 및 그룹 프로비저닝을 자동화합니다. 수동 개입 없이 사용자를 추가, 업데이트 및 제거하세요 — 조직 설정에서 발급된 단일 SCIM 토큰으로 인증됩니다.

SCIM이란?

SCIM은 사용자 라이프사이클 이벤트를 신원 공급자에서 SecureCodingHub로 자동으로 동기화합니다: 채용 시 사용자 생성, 변경 시 속성 업데이트, 그리고 오프보딩 시 비활성화입니다. 수동 사용자 관리를 완전히 제거합니다.

지원되는 작업

SecureCodingHub의 SCIM 2.0 엔드포인트는 다음 리소스와 작업을 지원합니다:

리소스	작업
Users	생성, 읽기, 업데이트, 삭제, 목록, 필터
Groups	생성, 읽기, 업데이트, 삭제, 목록
Service Provider Config	읽기 (디스커버리)
Schemas	읽기 (디스커버리)
Resource Types	읽기 (디스커버리)

인증

SCIM API는 Bearer 토큰 인증을 사용합니다. SecureCodingHub 관리자 패널에서 토큰을 생성하고 신원 공급자에서 구성합니다.

설정	값
Base URL	`https://api.limeplate.com/api/sch/scim/v2`
Auth Header	`Authorization: Bearer {your-scim-token}`

작동 방식

SCIM 프로비저닝 설정은 간단한 4단계 프로세스입니다:

관리자가 SecureCodingHub에서 SCIM 토큰을 생성

신원 공급자(Okta, Azure AD)에 토큰 구성

IdP가 사용자/그룹 변경 사항을 SecureCodingHub SCIM 엔드포인트로 푸시

사용자와 팀이 자동으로 생성, 업데이트 및 제거됨

참고: SCIM 프로비저닝은 SSO와 함께 작동합니다. SSO는 인증을 처리하고, SCIM은 사용자 라이프사이클 관리를 처리합니다.

SCIM이 컴플라이언스 증거에 중요한 이유

SCIM은 단순한 운영 편의가 아닙니다. SOC 2, ISO 27001 또는 HIPAA 하에서 운영되는 조직의 경우, 자동화된 디프로비저닝은 감사관이 실제로 테스트하는 통제입니다. ISO 27001 Annex A 9.2.6은 고용 종료 시 액세스 권한 제거를 요구하며, SOC 2 Common Criteria 6.2 및 6.3은 더 이상 필요하지 않을 때 논리적 액세스가 적시에 취소될 것으로 기대합니다. 수동 오프보딩 프로세스는 사람들이 예상하는 것보다 더 자주 이 테스트에 실패합니다. 증거 추적이 티켓이 제출되고 모든 다운스트림 도구를 통해 클릭하는 것을 기억하는 사람에 의존하기 때문입니다.

SCIM이 신원 공급자에 연결되면 오프보딩은 단일 이벤트가 됩니다: HR이 HRIS에서 사용자를 종료로 표시하고, IdP가 비활성화를 전파하며, SecureCodingHub는 다음 프로비저닝 주기 내에 사용자를 비활성으로 설정합니다. 감사관은 IdP 이벤트와 상관된 자동 비활성화의 깔끔한 로그를 얻으며, 이는 Type II 관찰 기간 동안 그들이 보고 싶어 하는 정확한 것입니다. 처음 SOC 2 감사를 준비하는 경우, SCIM을 일찍 켜고 6개월간 깨끗한 로그를 생성하도록 두는 것이 사용 가능한 가장 저렴한 증거 생성 승리 중 하나입니다.

일반적인 배포 패턴

세 가지 배포 패턴이 대부분의 환경을 다룹니다. 그린필드 배포가 가장 간단합니다: SecureCodingHub에 기존 사용자가 없고, 첫 초대가 나가기 전에 SCIM이 활성화되며, 모든 사용자가 IdP에서 시작됩니다. 이것이 가장 깔끔한 모델이며 실현 가능할 때마다 권장하는 것입니다. 부분 동기화가 다음 패턴입니다: SCIM을 단일 그룹 또는 부서로 범위 지정하고, 라이프사이클 이벤트가 올바르게 동작하는지 검증하고, 거기에서 확장합니다. 잘못 구성된 속성 매핑이 한 번에 많은 계정에 영향을 줄 수 있는 수천 좌석을 가진 조직에 유용합니다.

세 번째 패턴은 SCIM을 기존 수동 사용자와 병합하는 것입니다. SecureCodingHub는 이메일 주소로 수신 SCIM 사용자를 기존 계정과 일치시키므로, 병합은 일반적으로 비파괴적입니다. 리스크는 일치하지 않는 대소문자, 별칭 주소 또는 오래된 이메일 값을 가진 수동으로 생성된 사용자가 중복을 생성할 수 있다는 것입니다. 스위치를 켜기 전에 현재 사용자 목록을 내보내고, IdP 명단과 조정하고, IdP에서 주소 불일치를 해결하세요. 공급자 구성에 대한 자세한 내용은 Okta SCIM 설정 및 Azure AD SCIM 설정 가이드를 참조하세요.