Skip to main content

SCIM이란?

SCIM(System for Cross-domain Identity Management) 은 기업의 ID 공급자(IdP)에서 Databricks로 사용자와 그룹 정보를 자동 동기화 하는 표준 프로토콜입니다.
💡 기본 개념은 인증과 접근 제어의 “SCIM 프로비저닝” 섹션에서 소개했습니다. 이 문서에서는 실제 설정 절차와 고급 구성을 다룹니다.

SCIM이 해결하는 문제


Account 수준 vs Workspace 수준 SCIM

Databricks에서는 두 수준 의 SCIM을 제공합니다.
💡 항상 Account 수준 SCIM을 사용하세요. Account 수준에서 동기화된 사용자/그룹은 ID Federation을 통해 모든 워크스페이스에서 사용할 수 있습니다. Unity Catalog의 GRANT 문에도 Account 그룹만 사용할 수 있습니다.

동기화 대상

SCIM을 통해 동기화되는 정보는 다음과 같습니다.
⚠️ SCIM은 IdP → Databricks 단방향 동기화입니다. Databricks에서 직접 변경한 내용은 다음 동기화 시 IdP의 정보로 덮어씌워질 수 있습니다.

Okta SCIM 설정

사전 준비

  1. Databricks Account Admin 권한 필요
  2. Okta Admin 권한 필요

단계 1: Databricks에서 SCIM 토큰 생성

  1. Databricks Account Console> Settings> User provisioning
  2. Enable user provisioning 클릭
  3. Generate token 클릭하여 SCIM 토큰을 복사합니다

단계 2: Okta에서 SCIM 앱 설정

  1. Okta Admin Console> Applications> Databricks 앱 선택
  2. Provisioning 탭 > Configure API Integration 클릭
  3. Enable API Integration 체크
  1. Test API Credentials 클릭하여 연결 확인

단계 3: 프로비저닝 설정

To App 설정에서 다음을 활성화합니다:

단계 4: 사용자/그룹 할당

  1. Assignments 탭에서 동기화할 사용자/그룹을 선택합니다
  2. Push Groups 탭에서 Databricks로 동기화할 그룹을 설정합니다

Azure AD (Entra ID) SCIM 설정

단계 1: Databricks SCIM 토큰 생성

Okta 설정과 동일하게 Account Console에서 SCIM 토큰을 생성합니다.

단계 2: Azure Portal에서 프로비저닝 설정

  1. Azure Portal> Microsoft Entra ID> Enterprise applications
  2. Databricks 앱 선택 > Provisioning> Get started
  3. Provisioning Mode: Automatic 선택
  4. Admin Credentials 설정:
  1. Test Connection 클릭하여 연결 확인

단계 3: 매핑 설정

기본 매핑을 확인하고 필요시 조정합니다:

단계 4: 프로비저닝 시작

  1. Provisioning Status: On으로 변경
  2. 초기 동기화는 최대 40분이 소요될 수 있습니다
  3. 이후 약 40분 간격으로 증분 동기화가 실행됩니다

동기화 모니터링

감사 로그로 확인

CLI로 사용자/그룹 확인


주의사항


모범 사례


SCIM 프로토콜 내부 동작 상세

SCIM은 REST API 기반의 CRUD(Create, Read, Update, Delete) 프로토콜입니다. IdP가 Databricks의 SCIM 엔드포인트에 HTTP 요청을 보내는 방식으로 동기화가 이루어집니다.

SCIM REST API 구조

SCIM 동기화 사이클 상세

IdP는 다음과 같은 사이클로 Databricks와 동기화합니다.

SCIM 요청/응답 예시


대규모 조직(만 명 이상) SCIM 운영 시 고려사항

스케일링 문제와 해결

동기화 범위 최적화

만 명 이상의 조직에서 모든 사용자를 Databricks에 동기화하는 것은 비용이 높은입니다.
💡 실무 권장: 전체 직원 5만 명 중 Databricks 실사용자가 500명이라면, 해당 500명이 속한 그룹만 동기화하세요. 불필요한 사용자 동기화는 API 호출 낭비이며, Databricks Account의 사용자 관리 화면도 복잡해집니다.

동기화 지연과 캐시

동기화 지연 구조

SCIM 동기화에서 발생하는 지연은 여러 단계에서 누적됩니다.

긴급 상황에서의 수동 동기화

IdP의 자동 동기화를 기다릴 수 없는 긴급 상황(즉시 접근 차단이 필요한 보안 사고 등)에서는 Databricks API를 직접 호출합니다.
⚠️ 주의: Databricks에서 직접 변경한 내용은 다음 IdP 동기화 시 IdP의 상태로 덮어써질 수 있습니다. 반드시 IdP에서도 동일하게 비활성화 해야 합니다.

그룹 중첩(Nested Groups) 한계

SCIM에서의 그룹 중첩 지원

그룹 설계 모범 사례

권장하지 않는 패턴(중첩 의존):
💡 실무 권장: IdP의 조직 구조(부서별 중첩 그룹)와 Databricks의 접근 제어 그룹을 분리하여 설계 하세요. IdP에서 dbx- 접두사가 붙은 평면 그룹을 별도로 생성하고, 이 그룹만 SCIM으로 동기화하면 중첩 문제를 회피할 수 있습니다.

IdP 장애 시 영향과 대응

IdP 장애 시나리오별 영향

IdP 장애 대응 방안


정리


참고 링크