メインコンテンツへジャンプ

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

データ保護は Databricks の最優先事項です

 

 

trust-image-new-header

トラスト

トラストを重視した Databricks のプラットフォームには、ソフトウェアの開発から提供に至るまでのライフサイクル全体にセキュリティが組み込まれています。Databricks は、ペネトレーションテスト、脆弱性テスト、内部アクセス制御など、運用における厳格なセキュリティ慣行に従っています。透明性が信頼を得るカギであるという考えのもと、運用に関する情報を公開し、お客さまやパートナーと緊密に連携してセキュリティ要件に対応します。PCI-DSS、HIPAA、FedRAMP の各コンプライアンスを提供し、ISO 27001、ISO 27017、ISO 27018、SOC 2 Type II に準拠しています。

契約上の要件

セキュリティ&トラストセンターでご覧いただけるドキュメントやベストプラクティスに加えて、セキュリティに対する契約上の要件を明記し、全てのお客さまに提供しています。この要件は、「セキュリティに関する補足条項」に記載されています。「セキュリティに関する補足条項」では、お客さまのデータをセキュアに保護するセキュリティ対策と実践を説明しています。

脆弱性の管理

お客さまが信頼するソフトウェアの脆弱性の検知と迅速な修正は、ソフトウェアやサービス提供者の極めて重要な責任です。私たちはこの責任を真摯に受け止め、「セキュリティに関する補足条項」のなかで、修復のタイムラインに関するコミットメントを共有しています。

Databricks の社内においては、脆弱性管理を自動化し、環境中の脆弱性を効果的に追跡、優先順位付け、調整、是正しています。新しいコードやイメージを本番環境に導入する前に、Databricks と Databricks が使用するサードパーティ/オープンソースパッケージの認証済み脆弱性スキャンを毎日行い、信頼できるセキュリティスキャンツールを使用して静的および動的コード解析(SAST および DAST)を実施しています。また、サードパーティの専門家を採用して、Databricks の公開サイトを分析し、潜在的なリスクを報告しています。

Datbricks は、スキャンベンダーから報告される前に新たな脆弱性を監視するための脆弱性対応プログラムに資金を投入しています。これは、社内ツール、ソーシャルメディア、メーリングリスト、脅威情報源(US-CERT、その他の政府、業界、オープンソースのフィードなど)を使用して達成されます。Datbricks は、CVE TrendsOpen CVDB などのオープンな脆弱性プラットフォームを監視しています。これらに対応するためのプロセスを確立しており、Datbricks、製品、または顧客に対する影響を迅速に特定できるようにしています。このプログラムにより、報告された脆弱性を迅速に再現し、ゼロデイ脆弱性を解決できます。

Datbricks の脆弱性管理プログラムは、ゼロデイなどの Severity-0 の脆弱性を最も緊急に扱い、他のロールアウトよりも優先的に修正することを約束します。

ペネトレーションテストとバグバウンティ

Databrcisk では、社内の攻撃検証セキュリティチーム、資格を有するサードパーティーのペネトレーションテスター、および通年の公開バグバウンティ(バグ報奨金プログラム)を組み合わせ、ペネトレーションテストを実施しています。ファジング、セキュアコードレビュー、ダイナミックアプリケーションテストを組み合わせて、プラットフォームの完全性とアプリケーションのセキュリティを評価します。メジャーリリース、新サービス、セキュリティ上の重要な機能については、侵入テストを実施しています。オフェンシブなセキュリティチームは、インシデント対応チームやエンジニアリング内のセキュリティチャンピオンと協力して、発見事項を解決し、社内に学びを浸透させています。

サードパーティーによる外部ペネトレーションテストは通常、年間 8~10 回、内部ペネトレーションテストは 15~20 回実施し、テストが合格と判定される前に、全ての重要な発見事項に対処する必要があります。透明性へのコミットメントの一環として、デューデリジェンスパッケージの一部として、プラットフォーム全体のサードパーティーのテストレポートを一般公開しています。

HackerOne が運営する公開バグバウンティプログラムに参加することで、世界中のサイバーセキュリティ研究者や侵入テスト担当者が、Databricks のセキュリティ脆弱性をテストすることが可能です。このプログラムを成功させるために、私たちが行った重要な決定には以下のようなものがあります。

  • HackerOne プログラムの統計情報(回答率や支払額など)に透明性を持たせることで、ハッカーのコミュニティが活発に活動するよう促す。
  • バグ報奨金の提出に対して迅速に対応する。バグ報奨金を受け取るまでの平均期間は 1 週間未満とする。
  • 全ての有効な送信に対してバリアント解析を行い、悪用される可能性のある別の方法を特定し、100% の修正を検証する。
  • 製品の最も重要な部分に注意を促すボーナスの追加。

私たちは、プログラムを成功させ、それぞれの報告から学ぶことに注力しています。私たちのバグ報奨金プログラムに対するオープンで協力的なアプローチにより、100 名以上のセキュリティ研究者が 200 件以上の報告に対して感謝の意を表しました。Databricks の安全性を保つためにご協力いただき、ありがとうございます。

私たちは、お客さまが安心して Databricks 上でワークロードを実行できるよう全力でサポートします。Databricks に対する脆弱性スキャンやペネトレーションテストの実施においては、次のことを推奨しています。

  1. クラウドサービスプロバイダのアカウント内にあるデータプレーンシステムでの脆弱性スキャンの実行。
  2. お客さまのコードに対してのテストの実行。ただし、これらのテストは、お使いのクラウドサービスプロバイダのアカウントにあるデータプレーン(またはその他のシステム)内で、お客さまのコントロールを評価する場合に限ります。
  3. Databricks バグ報奨金プログラムに参加すると、Databricks の専用デプロイメントにアクセスして、侵入テストを実行できます。Databricks のマルチテナント型コントロールプレーンに対する侵入テストは、このプログラムに参加する必要があります。

セキュリティ調査とインシデント対応

私たちは、Datbricks を SIEM と XDR のプラットフォームとして使用し、1 日あたり 9 テラバイトを超えるデータを処理して、検知とセキュリティ調査を実施しています。クラウドインフラ、デバイス、ID 管理システム、SaaS アプリケーションからログやセキュリティシグナルを取り込み、処理しています。構造化されたストリーミングパイプラインと Delta Live Tables を利用し、データ駆動型アプローチと統計的 MLモデルを使って最も関連性の高いセキュリティイベントを特定し、新規アラートの生成や、既知のセキュリティ製品から既存のアラートを相関、重複排除、優先順位付けします。また、MITRE ATT&CKフレームワークを使用して追跡された敵の戦術、技術、手順(TTP)を基にランブックのモデル化を行っています。Databricks のセキュリティ調査チームは、Databricks ノートブックを利用して、再現性のある調査プロセスを作成し、インシデント調査プレイブックを継続的に進化させ、2 ペタバイト以上の履歴イベントログに対して脅威探索を行い、非構造化データおよび半構造化データを複雑に検索しています。

Databricks のインシデント対応チームは、常に最新の情報を入手し、Databricks がインシデント管理シナリオに備えることができるよう、以下のことを実施しています。

  • SANS などのベンダーが提供する業界評価の高いコースに参加し、fwd:cloudsec、Black Hat、BSides, RSA などのセキュリティカンファレンスに参加する。
  • 経営幹部や社内チームと定期的に卓上演習を行い、Databricks 製品や企業インフラに関連するセキュリティ対応シナリオを実践する。
  • エンジニアリングチームと協力して、プラットフォームの観測可能性に優先順位をつけ、効果的なセキュリティ検知と対応を可能にする。
  • 進化するインシデント対応のスキルと能力のマトリックスに基づき、雇用とトレーニングの戦略を定期的に更新する。

内部アクセス

本番稼働システム、顧客環境、顧客データへの社員のアクセスについては、厳格なポリシーと制御を適用しています。

AWS、GCP、Azure などのクラウドサービスプロバイダのコンソールなど、コアインフラのコンソールにアクセスする際には、多要素認証が必要です。Databricks では、ポリシーと手順を定め、パスワードや API キーなどの明示的な認証情報の使用は可能な限り回避しています。例えば、新しい AWS の IAM プリンシパルまたはポリシーの例外リクエストを処理できるのは、指定されたセキュリティチームのメンバーのみです。

Databricks の社員が本番稼働システムにアクセスできるのは、緊急のブレークフィックスといった極めて特殊な状況下においてのみです。アクセスは Databricks が構築したシステムによって管理され、いかなるアクセスでも、正当性の確認、ポリシーのチェックが行われます。社員によるアクセスは、 Databricks の VPN を利用し、シングルサインオンソリューションでは多要素認証が必要です。
詳しく見る→

Databricks 社内のセキュリティ基準では、可能な限り職務分離(SoD)を実施することが求められています。例えば、クラウド ID プロバイダの認証および認可プロセスを一元化し、アクセスの承認申請をする社員と許可する社員を分離しています。

社内システムおよび本番稼働システムへのアクセスは、必要最小限の権限によるアクセスを適用しています。最小権限は、内部ポリシーに明確に組み込まれ、手順に反映されています。例えば、ほとんどのお客さまは、Databricks 社員によるワークスペースへのアクセスを制御できます。アクセスを許可する前にプログラムで多数のチェックを実行し、制限時間後に自動的にアクセス権限を取り消すことが可能です。
詳しく見る→

セキュアなソフトウェア開発ライフサイクル

Databricks には、ソフトウェア開発ライフサイクル(SDLC)があり、機能の要求から本番環境の監視まで、設計、開発、生産の全てのステップにセキュリティが組み込まれています。ライフサイクルを通じて機能を追跡するように設計されたツールでサポートされています。システム、ライブラリ、コードの自動セキュリティスキャンや、自動の脆弱性追跡機能を備えています。

Databricks では、顧客と社員の両者が投稿でき、機能に関する要求を追跡するアイデアポータルを活用しています。機能設計プロセスには、プライバシーとセキュリティの設計が含まれています。初期評価の後、影響の大きい機能は、エンジニアリングのセキュリティチャンピオンと連携した製品セキュリティチームによるセキュリティ設計レビューが実施され、脅威モデルやその他のセキュリティ特有のチェックが行われます。

Databricks ではアジャイル開発手法を用い、新たな機能を複数のスプリントに分割しています。Databricks プラットフォームの開発は外部委託をしておらず、開発者には全員、入社時およびその後毎年、OWASP Top 10 を含むセキュアなソフトウェア開発トレーニングを受けることを義務付けています。本番データおよび本番環境は、開発環境、QA 環境、ステージング環境から分離されています。コードは全て、きめ細かな権限が設定された多要素認証によるシングルサインオンを必要とするソース管理システムに照合されます。コードのマージには、影響を受ける各領域の機能エンジニアの所有者の承認を必要とし、全てのコードをピアレビューしています。製品セキュリティチームは、セキュリティ上重要なコードを手動でレビューし、ビジネスロジックのエラーを排除しています。

Databricks では、ベストオブブリードのツールを使用して、脆弱性のあるパッケージやコードを特定しています。本番前の環境における自動化では、認証済みホストとコンテナに対して、オペレーティングシステムとインストールされたパッケージの脆弱性スキャン、および動的・静的コード分析スキャンを実行します。脆弱性が確認された場合は、エンジニアリングチケットが自動的に作成され、関連チームに割り当てられます。また、製品のセキュリティチームは、Databricks アーキテクチャにおける重要な脆弱性をトリアージし、その深刻度を評価しています。

コードマージ時、コードマージ後、リリース時、本番稼働時など、SDLC プロセスの複数の段階で、ユニットテストやエンドツーエンドテストなどの品質チェックを実施します。テストには、ポジティブテスト、回帰テスト、ネガティブテストが含まれます。デプロイ後は、広範な監視で障害を特定し、ユーザーはステータスページを通じてシステムの可用性に関するアラートを受け取ることができます。P0 または P1 の問題が発生した場合は、Databricks が自動的に原因分析のための「なぜなぜ分析(5 whys)」をトリガーし、レビューの担当者をアサインし、問題解決にあたります。調査結果は経営幹部に伝えられ、フォローアップ項目は追跡されます。

Databricks には、正式なリリース管理プロセスがあり、コードをリリースする前に決行か中止かの判断を行います。変更におけるテストには、回帰の回避、新機能の現実的なワークロードにおけるテストの認証が含まれます。さらに、監視を行いながら段階的な展開を実施し、早期に問題を特定します。職務分離に則り、デプロイメント管理システムのみが変更を本番環境にリリースでき、全てのデプロイメントには複数人による承認が必要です。

Databricks では、イミューダブルインフラストラクチャのモデルに従い、パッチではなくシステムを入れ替えることで、設定のドリフトリスクを回避し、信頼性と安全性を向上させています。新規のシステムイメージやアプリケーションコードの展開時には、新たなコードで展開するワークロードを新たなインスタンスに移行します。これは、コントロールプレーンとデータプレーンの両方に当てはまります。(Databricks アーキテクチャについて詳しくは、セキュリティ機能のセクションを参照してください。)コードが本番稼動すると、検証プロセスで、許可なくアーティファクトが追加、削除、変更されていないことを確認します。

SDLC プロセスの最後のフェーズは、顧客向けのドキュメント作成です。Databricks のドキュメントは、ソースコードと同様に管理され、ドキュメントは同じソース管理システム内に保存されます。重要な変更については、公開前に技術レビューとドキュメントチームのレビューを徹底させています。
ドキュメントを見る →

セキュリティポリシーとコミュニケーションの詳細

Databricks は、セキュリティ脆弱性の取り扱いと通信に関する RFC 9116、ISO/IEC 30111:2019(E)、ISO/IEC 29147:2018(E) 標準に準拠しています。Databricks の安全な通信と PGP 署名の詳細については、Databricks のsecurity.txtファイルを参照してください。