セキュリティ＆トラストセンター

Ourpublic bug bountyprogram, 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 theDatabricks Bug Bountyprogram 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.

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 leverages anIdeas Portalthat 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 theStatus Page。在发生任何P0或P1问题,砖utomation 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 theSecurity 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 →

Databricks のレイクハウスアーキテクチャは 2 つのプレーンに分割され、権限設定の簡素化、データの重複の回避、リスクの軽減を実現します。コントロールプレーンは、Databricks がワークスペースアプリケーションの実行や、ノートブック、構成、クラスタなどを管理する管理プレーンです。サーバーレスコンピューティングを選択しない限り、データプレーンはユーザーのクラウドサービスプロバイダのアカウント内で実行し、アカウントからデータを取り出すことなく処理します。顧客管理の VPC/VNet や、エクスポートを無効にする管理コンソールオプションなどの機能を使用して、Databricks をデータ漏出保護アーキテクチャに組み込むことができます。

ノートブック、構成、ログ、ユーザー情報などの特定のデータがコントロールプレーン内に存在しても、その情報は、コントロールプレーン内では保存データ暗号化で、コントロールプレーン間の通信では送受信データの暗号化によって保護されます。また、特定のデータの保存場所を選択できます。データテーブルに関する独自のメタデータストア（Hive メタストア）のホストや、クエリ結果をユーザーのクラウドサービスプロバイダのアカウントに格納してからDatabricks Secret APIの使用を決定することも可能です。

Kafka の未加工データを正規化されたデータセットに変換し、Amazon S3 や Azure Data Lake Storage などのストレージに送信するためのノートブックをデータエンジニアが Databricks で作成するとします。その際の流れは次のようになります。

1. ユーザー認証：データエンジニアをシームレスに認証し、Databricks アカウントでホストされているコントロールプレーンの Databricks Web UI へのアクセスを可能にする（シングルサインオンも選択可能）。
2. コードの送信：データエンジニアが記述したコードは、 Web ブラウザからコントロールプレーンに送信される。JDBC/ODBC リクエストも同じパスをたどり、認証にはトークンが使用される。
3. クラスタの作成：コントロールプレーンは、クラウドサービスプロバイダの API を使用し、データプレーンの新しいインスタンスで構成される Databricks クラスタを CSP アカウントに作成する。管理者は、セキュリティプロファイルを強制するためにクラスタポリシーを適用できる。
4. クラスタへのコード送信：インスタンスの起動後、クラスタマネージャーによってデータエンジニアのコードがクラスタに送信される。
5. 書き込み：クラスタが、ユーザーのアカウントの Kafka からデータを取得し、変換して、ストレージへの書き込みを行う。
6. ステータスの通知：クラスタから、ステータスとアウトプットがクラスタマネージャーにレポートされる。

データエンジニアはコードを記述するだけです。Databricks が上記の全ステップを実行します。