Skip to main content
이 문서는 보안과 거버넌스 섹션의 일부입니다.

네트워크 보안이 왜 중요한가요?

데이터 플랫폼은 대량의 민감한 데이터를 다루기 때문에, 외부로부터의 무단 접근을 차단하는 네트워크 수준의 보안 이 필수적입니다. 아무리 강력한 인증과 권한 시스템을 갖추더라도, 네트워크 자체가 노출되어 있으면 공격 표면(Attack Surface)이 넓어집니다.
💡 네트워크 보안 은 데이터에 도달하기 전의 첫 번째 방어선 입니다. “허용된 네트워크에서만 접근 가능한가?”라는 질문에 답하는 계층입니다.
특히 금융, 의료, 공공 분야에서는 규제 요건(PCI-DSS, HIPAA, GDPR 등)으로 인해 네트워크 격리가 필수 사항입니다.

Databricks 네트워크 아키텍처

Databricks는 크게 Control PlaneCompute Plane 이라는 두 영역으로 나뉩니다. 이 구조를 이해하는 것이 네트워크 보안 설정의 출발점입니다. 출처: Databricks Docs
💡 Classic Compute Plane 은 고객의 VPC에서 실행되므로 고객이 네트워크를 직접 제어할 수 있습니다. Serverless Compute Plane 은 Databricks가 관리하지만, 네트워크 격리와 데이터 접근은 동일한 수준으로 보호됩니다.

고객 관리형 VPC (Customer-Managed VPC/VNet)

기본적으로 Databricks는 자체 관리 VPC를 생성하지만, 보안 요건이 높은 조직은 직접 생성한 VPC 를 사용할 수 있습니다.

Customer-Managed VPC 필수 요건


IP 접근 제한 목록 (IP Access Lists)

IP Access List 는 Databricks 워크스페이스에 접근할 수 있는 IP 주소를 제한합니다. 회사 VPN이나 사무실 IP만 허용하여 외부 접근을 차단하는 가장 기본적인 네트워크 보안 설정입니다.

IP Access List 유형

설정 방법

1. Databricks CLI
2. REST API
⚠️ 주의: IP Access List를 잘못 설정하면 본인도 워크스페이스에 접근할 수 없게 됩니다. 반드시 현재 접속 중인 IP가 허용 목록에 포함되어 있는지 확인하세요. Account Console에서 복구할 수 있습니다.

💡 Private Link 는 Databricks와의 모든 통신을 퍼블릭 인터넷을 거치지 않고 클라우드 제공자의 백본 네트워크를 통해 수행하는 기술입니다. AWS에서는 AWS PrivateLink, Azure에서는 Azure Private Link 라고 합니다.
Backend PrivateLink Frontend PrivateLink 출처: Databricks Docs
⚠️ Private Link는 Workspace 생성 시 설정하는 것이 권장됩니다. 기존 Workspace의 마이그레이션도 가능하지만, 다운타임이 발생할 수 있습니다.

VPC Peering

VPC Peering 은 Databricks의 Compute Plane VPC와 고객의 다른 VPC(예: 데이터베이스 VPC, 애플리케이션 VPC)를 프라이빗하게 연결 합니다.
VPC Peering으로 상호 연결

아웃바운드 제어 및 데이터 유출 방지

방화벽/NAT Gateway를 통한 아웃바운드 제어

Customer-Managed VPC에서는 아웃바운드 트래픽을 제어하여 데이터 유출(Data Exfiltration) 을 방지할 수 있습니다.

S3 버킷 정책을 이용한 데이터 유출 방지 (AWS)

💡 데이터 유출 방지(Data Exfiltration Prevention) 란, 허가되지 않은 경로로 데이터가 외부로 빠져나가는 것을 막는 보안 정책입니다. 예를 들어, Databricks 클러스터에서 임의의 외부 S3 버킷으로 데이터를 복사하는 것을 차단합니다.

클라우드별 네트워크 보안 비교


보안 수준별 네트워크 구성 가이드

기본 (Basic) — 개발/PoC 환경

표준 (Standard) — 일반 프로덕션 환경

강화 (Enhanced) — 규제 산업 (금융/의료/공공)


컴플라이언스 체크리스트


현업 사례: 퍼블릭 인터넷으로 Databricks 접근하다가 보안 감사에서 지적받은 사례

네트워크 보안은 “나중에 하자”고 미루다가 큰 낭패를 보는 대표적인 영역입니다.

사례: 금융사 보안 감사 지적

사례: 금융사 네트워크 보안 강화

이 사례에서 배우는 교훈

⚠️ 현업에서는 이렇게 합니다: 프로덕션 환경은 반드시 네트워크 보안을 먼저 설정 한 후 워크로드를 배포합니다. 특히 금융, 의료, 공공 분야에서는 IP Access List와 Private Link가 “선택”이 아니라 “필수”입니다. PoC에서 프로덕션으로 전환할 때, 네트워크 아키텍처를 반드시 재검토하세요.

Private Link는 “설정하면 끝”이 아닙니다. 현업에서 겪는 현실적인 복잡성을 솔직하게 공유합니다.

현실적으로 어려운 부분들

💡 현업 팁: Private Link는 새 Workspace를 생성할 때 처음부터 설정 하는 것이 10배 쉽습니다. 기존 Workspace를 마이그레이션하면 다운타임, DNS 변경, 기존 연결 끊김 등의 리스크가 있습니다. 신규 프로젝트라면 처음부터 Private Link를 켜세요.

IP Access List만으로 충분한 경우

Private Link가 항상 필요한 것은 아닙니다. 비용과 복잡성을 고려하면 IP Access List만으로도 충분한 경우가 있습니다.

판단 기준

IP Access List로 충분한 시나리오

IP Access List + 추가 보안으로 강화하는 방법

Private Link 없이도 보안을 강화할 수 있는 조합:
⚠️ 현업에서는 이렇게 합니다: “Private Link가 좋은 건 알지만, 설정/유지 비용이 부담”이라면, 위 조합으로 시작하세요. 규제 당국이 명시적으로 Private Link를 요구하거나, 보안 감사에서 지적받은 경우에만 Private Link로 전환해도 늦지 않습니다. 단, IP Access List는 반드시 설정 하세요. 이것조차 안 하면 워크스페이스 URL만 알면 전 세계 누구나 로그인 시도가 가능합니다.

정리


참고 링크