보안 및 신뢰 센터

여러분의 데이터 보안을 최우선으로 생각합니다

배경 이미지

데이터는 고객의 가장 중요한 자산이고 언제나 보호해야 할 대상입니다. 그래서 보안은 Databricks 레이크하우스 플랫폼의 모든 계층에 기본으로 들어갑니다. Databricks는 투명성을 지켜 고객이 당사 플랫폼을 활용하는 동안 필수적인 규정을 준수할 수 있도록 돕습니다.

문서, 규정 준수 자료가 포함된 실사 패키지를 사용하여 Databricks의 보안을 직접 검토해 보세요.
wehkamp 로고
wehkamp 로고
"Databricks 플랫폼은 관리와 거버넌스를 간소화해주어서 회사 전체에서 여러 팀이 데이터를 기반으로 한 의사 결정을 내릴 수 있게 되었습니다. 사용자를 추가하기 쉽고 클라우드 제공업체와 기본적으로 보안이 통합되며 APIs-for-everything이 제공되어 Wehkamp 직원 모두에게 필요한 데이터와 툴을 제공할 수 있었어요."

— Wehkamp 선임 데이터 사이언티스트 Tom Mulder

Adren Street Labs
wehkamp 로고
wehkamp 로고
“우리가 개발한 십여 개의 솔루션은 모두 Azure Databricks를 핵심 기반으로 삼아 구축되었습니다. 그 덕분에 연구실에서 운영 배포까지 매우 빠르게 진행되는 패턴을 활용하면서도 데이터 보안과 컴퓨팅 확장성을 유지할 수 있게 되었습니다.”

— Jeff Feldman, CTO, Arden Street Labs

Credit Suisse
wehkamp 로고
wehkamp 로고
"빅데이터와 AI 도입이 늘어나고 있지만 대부분 금융 서비스 기업은 여전히 데이터 유형, 개인정보 보호, 확장과 관련하여 상당한 어려움을 겼습니다. Credit Suisse는 개방형 클라우드 기반 플랫폼(예: Azure Databricks)에서 표준화를 통해 이러한 장애물을 극복하고, 조직 전체의 운영 및 ML의 속도와 규모를 늘립니다."

— Credit Suise 사례 연구

배경 이미지


Our trusted platform is built by embedding security throughout the software development and delivery lifecycle. We follow rigorous operational security practices such as penetration testing, vulnerability assessments and strong internal access controls. We believe transparency is the key to winning trust — we publicly share how we operate, and work closely with our customers and partners to address their security needs. We have offerings for PCI-DSS, HIPAA and FedRAMP compliance, and we are ISO 27001, ISO 27017, ISO 27018 and SOC 2 Type II compliant.

계약상의 약속

Beyond the documentation and best practices that you will find in our Security and Trust Center, we also provide a contractual commitment to security written in plain language to all our customers. This commitment is captured in the Security Addendum of our customer agreement, which describes the security measures and practices that we follow to keep your data safe.

취약성 관리

Detecting and quickly fixing vulnerable software that you rely on is among the most important responsibilities of any software or service provider. We take this responsibility seriously and share our remediation timeline commitments in our Security Addendum.

Internally, we have automated vulnerability management to effectively track, prioritize, coordinate and remediate vulnerabilities in our environment. We perform daily authenticated vulnerability scans of Databricks and third-party/open-source packages used by Databricks, along with static and dynamic code analysis (SAST and DAST) using trusted security scanning tools, before we promote new code or images to production. Databricks also employs third-party experts to analyze our public-facing sites and report potential risks.

Databricks has funded a Vulnerability Response Program for monitoring emerging vulnerabilities before they’re reported to us by our scanning vendors. We accomplish this using internal tools, social media, mailing lists and threat intelligence sources (e.g., US-CERT and other government, industry and open-source feeds). Databricks monitors open vulnerability platforms, such as CVE Trends and Open CVDB. We have an established process for responding to these so we can quickly identify the impact on our company, product or customers. This program allows us to quickly reproduce reported vulnerabilities and resolve zero-day vulnerabilities.

Our Vulnerability Management Program is committed to treating Severity-0 vulnerabilities, such as zero days, with the highest urgency, prioritizing their fix above other rollouts.

침투 테스트 및 버그 포상 제도

We perform penetration testing through a combination of our in-house offensive security team, qualified third-party penetration testers and a year-round public bug bounty program. We use a mixture of fuzzing, secure code review and dynamic application testing to evaluate the integrity of our platform and the security of our application. We conduct penetration tests on major releases, new services and security-sensitive features. The offensive security team works with our incident response team and security champions within engineering to resolve findings and infuse learnings throughout the company.

We typically perform 8-10 external third-party penetration tests and 15-20 internal penetration tests per year, and all material findings must be addressed before a test can be marked as passed. As part of our commitment to transparency, we publicly share our platform-wide third-party test report in our due diligence package.

Our public bug bounty program, facilitated by HackerOne, allows a global collective of cybersecurity researchers and penetration testers to test Databricks for security vulnerabilities. Some of the key decisions we’ve made to make the program successful include:

  • Encouraging an engaged community of hackers to be active on our program by providing transparency to our HackerOne program statistics such as response rate and payouts
  • Promptly responding to bug bounty submissions, with an average time-to-bounty under a week
  • Performing variant analysis on every valid submission to identify alternative ways that an exploit may be used, and verifying 100% of fixes
  • Adding bonuses that drive attention to the most important areas of the product

We work hard to make our program successful and to learn from each submission. Our open and collaborative approach to our bug bounty program has resulted in over 100 security researchers being thanked for over 200 reports. Thank you all for helping us keep Databricks secure!

We want our customers to have confidence in the workloads they run on Databricks. If your team would like to run a vulnerability scan or penetration test against Databricks, we encourage you to:

  1. Run vulnerability scans on data plane systems located inside of your cloud service provider account.
  2. Run tests against your code, provided that those tests are entirely contained within the data plane (or other systems) located in your cloud service provider account and are evaluating your controls.
  3. Join the Databricks Bug Bounty program to access a dedicated deployment of Databricks to perform penetration tests. Any penetration test against our multi-tenant control plane requires participation in the program.

Security investigations and incident response

We use Databricks as our SIEM and XDR platform to process over 9 terabytes of data per day for detection and security investigations. We ingest and process logs and security signals from cloud infrastructure, devices, identity management systems, and SaaS applications. We use structured streaming pipelines and Delta Live Tables to identify the most relevant security events using a data-driven approach and statistical ML models to generate novel alerts, or to correlate, de-duplicate and prioritize existing alerts from known security products. We model our runbooks on adversary tactics, techniques and procedures (TTP) tracked using the MITRE ATT&CK framework. Our security investigations team uses collaborative Databricks notebooks to create repeatable investigation processes, continually evolve incident investigation playbooks, and perform threat hunting against more than 2 petabytes of historic event logs handling complex searches over unstructured and semi-structured data.

Our incident response team stays up to date and helps Databricks prepare for incident management scenarios by:

  • Participating in industry-reputed courses from vendors like SANS and attending security conferences like fwd:cloudsec, Black Hat, BSides, RSA
  • Performing regular tabletop exercises with executive leadership and internal teams to practice security response scenarios relevant to Databricks products and corporate infrastructure
  • Collaborating with engineering teams to prioritize platform observability to allow effective security detection and response
  • Regularly updating hiring and training strategies based on an evolving incident response skills and capabilities matrix

내부 액세스

Databricks는 내부 직원이 프로덕션 시스템, 고객 환경, 고객 데이터에 액세스하는 데 엄격한 정책을 적용하고 통제합니다.

We require multifactor authentication to access core infrastructure consoles such as the cloud service provider consoles (AWS, GCP and Azure). Databricks has policies and procedures to avoid the use of explicit credentials, such as passwords or API keys, wherever possible. For example, only appointed security team members can process exception requests for new AWS IAM principals or policies.

Databricks employees can access the production system under very specific circumstances (such as emergency break-fix). Access is governed by a Databricks-built system that validates access and performs policy checks. Access requires that employees are connected to our VPN, and authenticate using our single sign-on solution with multifactor authentication.
Learn more →

Our internal security standards call for the separation of duties wherever possible. For example, we centralize our cloud identity provider’s authentication and authorization process to separate authorizing access (Mary should access a system) from granting access (Mary can now access a system).

We prioritize least privilege access, both in internal systems and for our access to production systems. Least privilege is explicitly built into our internal policies and reflected in our procedures. For example, most customers can control whether Databricks employees have access to their workspace, and we programmatically apply numerous checks before access can be granted and automatically revoke access after a limited time.
Learn more →

안전한 소프트웨어 개발 수명 주기

Databricks has a software development lifecycle (SDLC) that builds security into all design, development and production steps — from feature requests to production monitoring — supported by tooling designed to trace a feature through the lifecycle. We have automatic security scanning and automated vulnerability tracking of systems, libraries and code.

Databricks leverages an Ideas Portal that tracks feature requests and allows voting both for customers and employees. Our feature design process includes privacy and security by design. After an initial assessment, high-impact features are subject to a security design review from the product security team in association with the security champions from engineering, along with threat modeling and other security-specific checks.

We use an agile development methodology that breaks up new features into multiple sprints. Databricks does not outsource the development of the Databricks platform, and all developers are required to go through secure software development training — including the OWASP Top 10 — when hired and annually thereafter. Production data and environments are separated from development, QA and staging environments. All code is checked into a source control system that requires single sign-on with multifactor authentication and granular permissions. Code merges require approval from the functional engineering owners of each area impacted, and all code is peer reviewed. The product security team manually reviews security-sensitive code to eliminate business logic errors.

Databricks에서는 업계 최고의 도구를 사용하여 취약한 패키지나 코드를 찾아냅니다. 사전 프로덕션 환경에서는 자동으로 운영 체제와 설치된 패키지를 대상으로 인증된 호스트 및 컨테이너 취약성 스캔을 실행하고, 동적 및 고정 코드 분석 스캔을 병행합니다. 취약성에 대해서는 엔지니어링 티켓이 자동으로 생성되고, 관련 팀에 할당됩니다. 제품 보안팀도 중요한 취약성을 분류하여 Databricks 아키텍처에서 심각도를 평가합니다.

We run quality checks (such as unit tests and end-to-end tests) at multiple stages of the SDLC process, including at code merge, after code merge, at release and in production. Our testing includes positive tests, regression tests and negative tests. Once deployed, we have extensive monitoring to identify faults, and users can get alerts about system availability via the Status Page. In the event of any P0 or P1 issue, Databricks automation triggers a “5 whys” root cause analysis methodology that selects a member of the postmortem team to oversee the review. Findings are communicated to executive leadership, and follow-up items are tracked.

Databricks has a formal release management process that includes a formal go/no-go decision before releasing code. Changes go through testing designed to avoid regressions and validate that new functionality has been tested on realistic workloads. Additionally, there is a staged rollout with monitoring to identify issues early. To implement separation of duties, only our deployment management system can release changes to production, and multiperson approval is required for all deployments.

We follow an immutable infrastructure model, where systems are replaced rather than patched to improve reliability and security and to avoid the risk of configuration drift. When new system images or application code is launched, we transfer workloads to new instances that launch with the new code. This is true both for the control plane and the data plane (see the Security Features section for more on the Databricks architecture). Once code is in production, a verification process confirms that artifacts are not added, removed or changed without authorization.

The final phase of the SDLC process is creating customer-facing documentation. Databricks docs are managed much like our source code, and documentation is stored within the same source control system. Significant changes require both technical and docs team review before they can be merged and published.
Visit documentation →

Security Policy and Communication Details

Databricks follows RFC 9116, ISO/IEC 30111:2019(E), and ISO/IEC 29147:2018(E) standards for security vulnerability handling and communications. For details on our secure communications and PGP signature, please refer to our security.txt file.

배경 이미지
네트워크 액세스 클라우드

Option to deploy into a VPC/VNet that you manage and secure. By default there are no inbound network connections to the data plane.

AWS, Azure

사용자 또는 클라이언트가 Databricks 제어 플레인 UI 및 API로 비공개 액세스(또는 비공개 링크)

AWS, Azure

클래식 데이터 플레인에서 Databricks 제어 플레인으로 비공개 액세스(또는 비공개 링크)

AWS, Azure

클래식 데이터 플레인에서 클라우드 플랫폼의 데이터로 비공개 액세스(또는 비공개 링크)

AWS, Azure

IP 액세스 리스트에서 인터넷을 통한 Databricks 제어 플레인 UI 및 API 액세스 제어

AWS, Azure, GCP

통신을 제한하는 자동 호스트 기반 방화벽

AWS, Azure, GCP

사용자 및 그룹 관리 클라우드

클라우드 서비스 공급업체 ID 관리를 사용하여 클라우드 리소스와 매끄럽게 통합

AWS, Azure, GCP

Azure Active Directory 조건부 액세스 정책 지원

Azure(AWS/GCP에는 적용되지 않음)

SCIM 프로비저닝으로 사용자 ID 및 그룹 관리

AWS, Azure, GCP

ID 제공자 통합을 제공하는 SSO(ID 제공자를 통해 MFA 활성화)

AWS(Azure/GCP에는 적용되지 않음*)

자동화를 위해 애플리케이션 ID를 관리하는 서비스 주체 또는 서비스 계정

AWS, Azure, GCP

사용자 계정을 잠궈서 일시적으로 사용자의 Databricks 액세스 비활성화

AWS(Azure/GCP에는 적용되지 않음*)

비밀번호 권한으로 로컬 비밀번호 비활성화

AWS(Azure/GCP에는 적용되지 않음*)

액세스 관리 클라우드

Fine-grained permission based access control to all Databricks objects including workspaces, jobs, notebooks, SQL

AWS, Azure, GCP

권한 관리와 개인 액세스 토큰이 포함된 보안 API 액세스

AWS, Azure, GCP

OAuth 토큰 지원

Azure, GCP

여러 워크스페이스에서 각 보안 프로필로 사용자, 워크로드, 데이터 세분화

AWS, Azure, GCP

데이터 보안 클라우드

저장된 제어 플레인 데이터 암호화

AWS, Azure, GCP

고객 관리형 키 암호화 제공

AWS, Azure

제어 플레인과 데이터 플레인 사이의 모든 통신 전송 암호화

AWS, Azure, GCP

Intra-cluster Spark encryption in transit or platform-optimized encryption in transit

AWS, Azure

세분화된 데이터 보안 및 동적 뷰로 마스킹

AWS, Azure, GCP

관리자 제어로 데이터 유출 위험 제한

AWS, Azure, GCP

Data governance 클라우드

Unity Catalog로 데이터 거버넌스 세분화

AWS, Azure

Centralized metadata and user management with Unity Catalog

AWS, Azure

Centralized data access controls with Unity Catalog

AWS, Azure

Data lineage with Unity Catalog

Preview on AWS and Azure

Data access auditing with Unity Catalog

AWS, Azure

Secure data sharing with Delta Sharing

AWS, Azure

워크로드 보안 클라우드

리포지토리에서 코드 버전을 효과적으로 관리


내장된 시크릿 관리로 코드에 자격 증명을 하드코딩할 위험 제거


관리형 데이터 플레인 머신 이미지를 패치, 보안 스캔, 기본 강화로 정기 업데이트

AWS, Azure (GCP not applicable)

클러스터 정책으로 비용 억제, 보안 및 검증 요구 사항 적용


불변 단기 인프라로 구성의 일관성 상실 방지


Enhanced hardening with security monitoring and vulnerability reports of managed data plane images


감사 및 로깅 클라우드

Databricks 사용자 활동의 포괄적이고 구성 가능한 감사 로깅


Databricks SQL 명령 기록 로깅


Databricks 클러스터 로깅


보안 검증(규정 준수) 클라우드

ISO 27001, 27017, 27018 준수

AWS, Azure, GCP

SOC 1 Type II, SOC 2 Type II, SOC 3

AWS, Azure, GCP


AWS, Azure, GCP

PCI DSS를 준수하는 배포


FedRAMP Moderate 준수


FedRAMP High 준수


HIPAA를 준수하는 배포




* Azure Databricks는 Azure Active Directory와 통합되고, GCP 기반 Databricks는 Google Identity와 통합됩니다. Databricks 자체에서는 이를 구성할 수 없지만, 필요에 따라 Azure Active Directory 또는 Google Identity를 구성할 수 있습니다.

보안 모범 사례

Databricks는 수천 곳의 고객사와 함께 일하며 고객의 아키텍처 요구 사항에 맞는 보안 기능을 포함하여 Databricks 플랫폼을 안전하게 배포한 경험이 있습니다. 이 문서는 기업 고객과의 경험에서 배운 배포에 적용할 수 있는 보안 모범 사례 체크리스트, 배포에 적용할 수 있는 고려 사항과 패턴을 제공합니다.

View document for AWS, Azure and GCP

Security Analysis Tool

Security Workspace Analysis Tool (SAT) monitors your workspace hardening by reviewing the deployments against our security best practices. It programmatically verifies workspaces using standard API calls and reports deviations by severity, with links that explain how to improve your security.

View blog for more detail, and GitHub to get started.
(Currently available for AWS)

Databricks 보안 문서

Databricks는 보안 기능 운영 방법과 모범 사례에 대한 문서를 제공함으로써, 고객이 신속하고 안전하게 배포하는 데 도움을 드리고자 합니다. 이 문서는 Databricks를 배포하거나 사용하는 팀을 주요 대상으로 합니다.

Access documentation for AWS, GCP or Azure

Databricks Security and Trust Overview Whitepaper

보안 개요 백서는 보안팀이 Databricks의 모든 면을 빠르게 살펴볼 수 있는 요약 정보를 제공합니다.

문서 보기

Shared Responsibility Model

The Databricks shared responsibility model outlines the security and compliance obligations of both Databricks and the customer with respect to the data and services on the Databricks platform.

문서 보기

플랫폼 아키텍처

Databricks 레이크하우스 아키텍처는 두 개의 플레인으로 나뉘어, 권한을 단순화하고 데이터 중복을 피하며 위험을 완화합니다. 제어 플레인은 관리 플레인이며, Databricks가 워크스페이스 애플리케이션을 실행하고 노트북, 구성, 클러스터를 관리합니다. 서버리스 컴퓨팅을 사용하지 않는 한, 데이터 플레인은 클라우드 서비스 제공업체 계정 내에서 실행되어 데이터를 계정 밖으로 꺼내지 않고 처리합니다. Databricks를 고객 관리형 VPC/VNet, 내보내기를 비활성화하는 관리자 콘솔 옵션 등의 기능을 사용하여 데이터 유출 보호 아키텍처에 Databricks를 포함할 수 있습니다.

일부 데이터(예: 노트북, 구성, 로그, 사용자 정보)가 제어 플레인 내부에 존재하기는 하지만, 이 정보는 제어 플레인에 저장된 상태에서 암호화되고 제어 플레인과의 통신 시 전송 중에 암호화됩니다. 또한, 특정 데이터를 저장할 곳을 선택할 수 있습니다. 데이터 테이블(Hive 메타스토어)에 대한 메타데이터를 저장하는 자체 스토어를 호스팅하고, 클라우드 서비스 제공업체 계정에 쿼리 결과를 저장하고, Databricks Secrets API를 사용할지 결정할 수 있습니다.

어떤 데이터 엔지니어가 Databricks에 로그인해서 Kafka의 원시 데이터를 정규화된 데이터 세트로 변환하고 Amazon S3, Azure Data Lake Storage 등의 스토리지로 전송하는 노트북을 작성한다고 생각해 보세요. 6단계:

  1. 데이터 엔지니어가 원할 경우, SSO를 사용하여 Databricks 계정에서 호스팅되는 제어 플레인의 Databricks 웹 UI로 매끄럽게 인증합니다.
  2. 데이터 엔지니어가 코드를 작성하는 동안 웹 브라우저가 제어 플레인으로 보냅니다. JDBC/ODBC 요청도 동일한 경로를 따라 토큰으로 인증합니다.
  3. 준비가 끝나면 제어 플레인은 Cloud Service Provider API를 사용하여 데이터 플레인의 새로운 인스턴스로 구성된 Databricks 클러스터를 CSP 계정에 생성합니다. 관리자는 클러스터 정책으로 보안 프로필을 적용합니다.
  4. 인스턴스가 시작되면 클러스터 관리자가 데이터 엔지니어의 코드를 클러스터로 보냅니다.
  5. 클러스터가 계정의 Kafka로부터 풀링하고, 계정 내 데이터를 변환하여 계정 내 스토리지에 작성합니다.
  6. 클러스터가 상태와 모든 결과를 클러스터 관리자에게 보고합니다.

데이터 엔지니어는 이런 세부적인 사항은 대부분 걱정할 필요가 없고, 코드와 이를 실행하는 Databricks만 작성하면 됩니다.

규정 준수

전 세계의 고객사들이 Databricks를 믿고 가장 민감한 데이터를 맡깁니다. Databricks는 매우 규제가 엄격한 산업의 고유한 규정 준수 요구 사항을 지키기 위한 제어 조치를 취했습니다.

실사 패키지

셀프 서비스 보안 검토를 원한다면 실사 패키지를 다운로드할 수 있습니다. 여기에는 일반적인 규정 준수 문서(예: ISO 인증, 연간 침투 테스트 확인서)가 포함됩니다. 또한, Databricks 계정팀에 문의하여 엔터프라이즈 보안 가이드와 SOC 2 Type II 보고서의 사본을 요청할 수 있습니다.


인증 및 표준

배경 이미지


Databricks는 개인 정보 보호를 중요하게 생각합니다. Databricks를 사용하여 분석하는 데이터는 고객과 고객의 조직 모두에게 중요하며, 여러 가지 개인정보 보호법과 규정이 적용될 수 있음을 알고 있습니다.

Databricks가 자신에게 적용되는 규제 프레임워크를 준수하는지 확인하는 데 도움이 될 수 있도록 Databricks의 개인정보 보호정책을 투명하게 설명한 개인정보 보호 FAQ 및 문서를 준비했습니다.

배경 이미지

Databricks 워크스페이스의 보안 인시던트 조사 지원

워크스페이스 데이터가 해킹되었거나 데이터 내에서 불일치 또는 부정확한 내용을 발견한 경우, 즉시 Databricks로 신고하세요.

Databricks에서 보낸 스팸 또는 의심스러운 커뮤니케이션 신고

사기성이거나, 부적절하거나, 부적절한 콘텐츠/멀웨어가 있는 스팸이나 커뮤니케이션을 받은 경우, 즉시 Databricks로 연락해주세요.

Databricks 제품에 대한 내부 취약성 스캐너 보고서

취약성 스캔 보고서를 분석하는 데 도움을 제공하려면 Databricks 지원 채널을 통해 지원 요청을 보내고, 제품 버전, 구체적인 구성, 구체적인 보고서 결과, 스캔 실행 방법을 제출하세요.

CVE가 Databricks 워크스페이스 또는 런타임에 미치는 영향

타사 CVE 또는 Databricks CVE가 미치는 영향에 대한 정보가 필요한 경우, Databricks 지원 채널을 통해 지원 요청을 보내고, National Vulnerability Database에서 확인한 CVE 설명, 심각도, 참조를 제공하세요.

Databricks 제품 또는 서비스의 버그 신고

Databricks 제품에서 재현 가능한 취약성을 발견한 경우, 문제를 해결할 수 있도록 신고를 부탁드립니다. HackerOne에서 지원하는 공개 버그 포상 제도에 참여하세요.

배경 이미지


HIPAA는 보호된 건강 정보에 대한 다양한 보호 조치가 포함된 미국 규정입니다. Databricks는 HIPAA를 준수하는 배포 옵션이 있습니다.

지원되는 클라우드


Azure 멀티 테넌트 — 모든 지역

AWS 싱글 테넌트 — 모든 지역

AWS 멀티 테넌트 — us-east-1, us-east-2, ca-central-1, us-west-2