Skip to main content

왜 시크릿 관리가 필요한가요?

데이터 파이프라인에서는 데이터베이스 비밀번호, API 키, 서비스 계정 자격 증명 등 민감한 정보 를 자주 사용합니다. 이러한 값을 노트북 코드나 설정 파일에 직접 입력하면 보안 사고 로 이어질 수 있습니다.
💡 기본 개념은 보안 개요의 “비밀 관리” 섹션에서 소개했습니다. 이 문서에서는 Secret Scope의 유형, CLI 관리, ACL 설정을 상세히 다룹니다.

Secret Scope 유형

Databricks-backed Scope

Databricks가 자체적으로 관리하는 암호화된 저장소입니다.

Azure Key Vault-backed Scope

Azure Key Vault의 Secret을 Databricks에서 직접 참조합니다.

Secret Scope 생성 및 관리

Scope 생성

Secret 추가/수정

Secret 목록 조회

Secret 삭제


노트북에서 Secret 사용

dbutils.secrets.get()

Spark 설정에서 사용

SQL에서 사용


보안 동작

REDACTED 처리

Secret 참조 시 주의사항


ACL (접근 제어 목록) 설정

Secret Scope에 대한 접근 권한을 세밀하게 관리할 수 있습니다.

권한 유형

ACL 설정 명령

권장 ACL 구성


실전 활용 패턴

패턴 1: 환경별 Scope 분리

패턴 2: Lakeflow Connect 연결에서 Secret 사용


현업 사례: 코드에 비밀번호를 하드코딩해서 Git에 올라간 사고

🔥 실전 경험담 한 스타트업의 데이터 엔지니어가 급하게 외부 API 연동 노트북을 작성하면서, API 키를 코드에 직접 입력 했습니다.
이 노트북이 Git Repo에 커밋되었고, 해당 Repo가 퍼블릭 리포지토리 로 설정되어 있었습니다. 24시간도 안 되어 외부에서 API 키를 탈취하여 약 $2,000(약 270만원)의 부정 API 호출 이 발생했습니다. GitHub에는 Secret 탐지 봇이 돌고 있어서 퍼블릭 리포의 Secret은 수분 내에 발견됩니다. 사고 수습 과정:
  1. API 키 즉시 무효화 (API 제공사에 연락)
  2. Git 이력에서 Secret 제거 (git filter-branch 사용, 하지만 이미 캐시된 사본은 제거 불가)
  3. 리포지토리를 Private으로 전환
  4. 모든 노트북 대상 Secret 하드코딩 감사 수행
  5. Secret Scope 도입 및 개발 가이드라인 배포
교훈: 한 번 Git에 올라간 Secret은 이력을 삭제해도 완전히 제거할 수 없습니다. Fork, Cache, 로컬 Clone 등에 남아 있을 수 있기 때문입니다. 처음부터 코드에 Secret을 넣지 않는 것이 유일한 해결책 입니다.

Secret Scope 설계 전략 (환경별 분리)

현업에서 가장 효과적인 Secret Scope 설계 패턴을 소개합니다.

권장 Scope 구조

설계 원칙

💡 현업 팁: 키 이름을 환경 간에 통일 하면, 노트북 코드에서 Scope 이름만 변경하여 환경을 전환할 수 있습니다. 이는 Asset Bundles와 결합하면 더욱 강력합니다.

Azure Key Vault 연동 시 주의사항

Azure 환경에서 Key Vault-backed Scope를 사용할 때, 현업에서 자주 만나는 문제들입니다.
🔥 이것을 안 하면: Azure Key Vault-backed Scope는 읽기 전용 입니다. dbutils.secrets.put()으로 값을 업데이트할 수 없고, Key Vault Portal이나 CLI에서 직접 업데이트해야 합니다. 이 사실을 모르고 자동화 스크립트에서 put()을 호출하여 에러가 발생하는 경우가 많습니다.

Key Vault 연동 시 추가 보안 권장사항


모범 사례


정리


참고 링크