인증과 접근 제어 (Identity & Access Management)

​

왜 ID 관리가 중요한가요?

💡 IAM(Identity and Access Management) 은 “누가(Who) 무엇에(What) 어떤 권한으로(How) 접근할 수 있는가”를 체계적으로 관리하는 보안 프레임워크입니다. Databricks는 기업의 기존 ID 시스템(Okta, Azure AD/Entra ID, Google Workspace 등)과 연동하여 통합적인 ID 관리를 제공합니다.

​

계정(Account) vs 워크스페이스(Workspace) 수준 ID

​

ID Federation (ID 연합)

💡 ID Federation 은 Account 수준에서 관리하는 사용자/그룹을 별도 추가 없이 워크스페이스에서 사용할 수 있게 해주는 기능입니다. ID Federation이 활성화되면, Account에 사용자를 추가하면 해당 사용자가 모든 연합 워크스페이스에서 인증할 수 있습니다.

Identity Federation이 활성화된 워크스페이스에서는 Account 수준 사용자/그룹이 자동으로 접근 가능합니다.

​

ID 유형: 사용자, 그룹, 서비스 프린시펄

​

사용자 (User)

​

그룹 (Group)

💡 모범 사례: 항상 Account 그룹 을 사용하세요. Workspace 로컬 그룹은 레거시 방식이며, Unity Catalog에서 권한을 부여할 때 Account 그룹만 사용할 수 있습니다.

​

서비스 프린시펄 (Service Principal)

💡 Service Principal(서비스 프린시펄) 은 사람이 아닌 애플리케이션/자동화 시스템 을 위한 계정입니다. 개인 계정으로 프로덕션 파이프라인을 실행하면, 그 사람이 퇴사하면 파이프라인이 중단됩니다. Service Principal을 사용하면 이 문제를 방지할 수 있습니다.

# Service Principal로 인증 (Python SDK)
from databricks.sdk import WorkspaceClient

w = WorkspaceClient(
    host="https://dbc-abc123.cloud.databricks.com",
    client_id="<service-principal-client-id>",
    client_secret="<service-principal-secret>"
)

​

SSO (Single Sign-On) 설정

💡 SSO(Single Sign-On) 란 한 번 로그인하면 여러 서비스에 추가 로그인 없이 접근할 수 있는 인증 방식입니다. 회사에서 Okta로 로그인하면 Databricks, Slack, JIRA 등에 별도 로그인 없이 바로 접근하는 것이 SSO입니다.

​

지원 프로토콜

​

SSO 설정 흐름

​

SSO 설정 단계 (Okta 예시)

1. Okta 관리 콘솔 에서 Databricks 앱을 생성합니다
2. SAML 2.0 설정에서 Single Sign-On URL 과 Audience URI 를 입력합니다
   • SSO URL: https://accounts.cloud.databricks.com/login/saml
   • Audience URI: https://accounts.cloud.databricks.com
3. Databricks Account Console> Settings> Single sign-on 에서 SAML 설정을 입력합니다
4. Test SSO 로 동작을 확인합니다
5. 성공 확인 후 비밀번호 로그인 비활성화 를 권장합니다

⚠️ SSO 강제 전 주의: SSO를 강제 활성화하기 전에 반드시 테스트를 완료하세요. SSO 설정이 잘못된 상태에서 비밀번호 로그인을 비활성화하면 모든 사용자가 로그인할 수 없게 됩니다.

​

SCIM 프로비저닝

💡 SCIM(System for Cross-domain Identity Management) 은 사용자와 그룹 정보를 기업의 ID 공급자(IdP)에서 Databricks로 자동 동기화 하는 표준 프로토콜입니다.

​

SCIM의 동작

​

왜 SCIM이 중요한가요?

​

SCIM 설정 (Account 수준)

1. Account Console> Settings> User provisioning 이동
2. Enable SCIM provisioning 클릭
3. SCIM Token 생성 및 복사
4. IdP(Okta, Azure AD)에서 Databricks SCIM 앱을 설정합니다:
   • SCIM Base URL: https://accounts.cloud.databricks.com/api/2.0/accounts/<account-id>/scim/v2
   • Bearer Token: 위에서 생성한 토큰
5. 동기화할 사용자/그룹을 선택하고 프로비저닝을 시작합니다

💡 Account 수준 SCIM vs Workspace 수준 SCIM: Account 수준 SCIM을 사용하면 모든 워크스페이스에 자동 반영되므로, 워크스페이스마다 별도로 SCIM을 설정할 필요가 없습니다.

​

MFA (다중 인증)

💡 MFA(Multi-Factor Authentication) 는 비밀번호 외에 추가 인증 수단(OTP, 푸시 알림, 보안 키)을 요구하여 계정 보안을 강화하는 방법입니다. 비밀번호가 유출되더라도 MFA가 있으면 무단 접근을 방지할 수 있습니다.

​

MFA 적용 방식

💡 SSO를 사용하는 환경에서는 IdP 측에서 MFA를 강제 하는 것이 가장 효과적입니다. Databricks에서 별도로 MFA를 설정할 필요 없이, IdP의 정책 한 곳에서 관리할 수 있습니다.

​

OAuth 2.0 인증 흐름

​

사용자 대화형 인증 (U2M: User-to-Machine)

# Databricks CLI에서 OAuth U2M 인증
databricks auth login --host https://dbc-abc123.cloud.databricks.com
# 브라우저가 자동으로 열려 로그인 진행

​

서비스 간 인증 (M2M: Machine-to-Machine)

# M2M OAuth 인증
from databricks.sdk import WorkspaceClient

w = WorkspaceClient(
    host="https://dbc-abc123.cloud.databricks.com",
    client_id="<sp-client-id>",
    client_secret="<sp-client-secret>"
)

​

PAT (Personal Access Token) 관리

💡 PAT(Personal Access Token) 는 dapi 접두사가 붙는 개인용 API 토큰입니다. 간단한 API 호출이나 개발 환경에서 사용하지만, OAuth보다 보안성이 낮으므로 프로덕션에서는 권장하지 않습니다.

​

PAT vs OAuth 비교

​

PAT 관리 정책

-- Account Admin: PAT 사용을 제한할 수 있습니다
-- Workspace 설정 > Admin Settings > Personal Access Tokens
-- - 토큰 최대 수명 설정 (예: 90일)
-- - 특정 사용자/그룹만 PAT 생성 허용
-- - PAT 생성 완전 비활성화 (OAuth만 허용)

🆕 Scoped Personal Access Tokens (Preview): 토큰의 권한 범위를 API 유형별로 제한할 수 있습니다. 예를 들어, SQL 실행만 허용하고 클러스터 생성은 불허하는 토큰을 발급할 수 있습니다.

​

워크스페이스 접근 제어

​

워크스페이스 권한 수준

​

워크스페이스 할당

​

실습: Service Principal 생성 및 SCIM 설정

​

실습 1: Service Principal 생성

# Databricks CLI로 Service Principal 생성
databricks service-principals create \
  --display-name "etl-pipeline-sp" \
  --active true

# 결과 예시
# {
#   "id": "1234567890",
#   "application_id": "abcd-efgh-ijkl-mnop",
#   "display_name": "etl-pipeline-sp",
#   "active": true
# }

# Service Principal에 OAuth Secret 생성
databricks service-principal-secrets create \
  --service-principal-id 1234567890

# 결과 예시
# {
#   "id": "secret-id",
#   "secret": "<generated-secret>",  ← 이 값을 안전하게 저장하세요!
#   "status": "ACTIVE"
# }

# Service Principal을 그룹에 추가
databricks groups patch data-engineers \
  --json '{
    "Operations": [{
      "op": "add",
      "value": {
        "members": [{"value": "1234567890"}]
      }
    }]
  }'

​

실습 2: Service Principal로 Job 실행

# Job 정의 시 Service Principal을 실행 주체로 지정
from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

job = w.jobs.create(
    name="daily-etl",
    run_as={"service_principal_name": "etl-pipeline-sp"},
    tasks=[{
        "task_key": "etl-task",
        "notebook_task": {
            "notebook_path": "/Repos/production/etl-pipeline"
        },
        "existing_cluster_id": "cluster-id"
    }]
)

​

인증 방식 비교 총정리

​

모범 사례 (Best Practices)

​

정리

​

참고 링크

• Databricks: Identity and access management
• Databricks: Service principals
• Databricks: SCIM provisioning (Account)
• Databricks: SSO setup
• Databricks: OAuth M2M authentication
• Azure Databricks: Authentication