Admin Isolation on Shared Clusters - The Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
この記事はDatabricksのSVP Product ManagementであるDavid MeyerとSecureworksのセキュリティ研究者のJoosua Santasaloの共著です。
Databricksにおいて、我々は我々のプラットフォームで処理されるデータのセキュリティがお客様にとって重要であることを理解しています。我々のセキュリティトラストセンターの歴史においては、内部ポリシーとプロセス(脆弱性管理やセキュアなSDLCなど)、セキュリティ機能(顧客管理キーやPrivateLinkなど)に投資を行なってきています。
我々のベストなセキュリティの投資の一部は、我々のバグハンターやセキュリティ研究者との関係構築に費やされています。共に取り組むことで、脆弱性や設定ミスを発見・修正し、ドキュメントを改善し、Databricksを世界で最も困難な問題をセキュアに解決するためのベストの場所にするためにコラボレーションしています。
本日、我々はバグハンターのレポートがどのようにして製品をより良くするのかを説明したいと思います。我々はJoosua Santasaloの建設的なフィードバック、適切にドキュメントされたレポート、この共同ブログの執筆、公開におけるコラボレーション精神に感謝の意を表します。
導入
最近、Databricksはセキュリティ研究者であるJoosua SantasaloからDatabricks管理者が「分離なし共有」アクセスモードクラスター、以前の「スタンダード」モードクラスター(AWS | Azure | GCP)を操作する際に潜在的な権限エスカレーションのリスクに関するレポートを受け取りました。報告された問題は、Databricks SQLウェアハウスや共有・シングルユーザーアクセスモードのクラスターのようにアクセスコントロールがなされているDatabricksの機能、古いクラスターUIを使っているユーザーにおいてはテーブルACLやクレディンシャルパススルーを使用しているハイコンカレンシークラスターでは影響はありません。
Joosuaが発見したことは、適切に認証された誰か、あるいは、権限のないDatabricksアカウントが同じワークスペース、同じ企業の境界内で管理者権限を得られるというものです。この問題を悪用するには、当該クラスターを操作する管理者権限が必要です。Databricksではこの様なエスカレーションが実際に起きた事実は確認していません。
我々は、以前はシングルユーザーのユースケース、あるいは、ユーザー分離が強い要件でない場合には「分離なし共有」クラスターモードを使うをことをお勧めしていました。このため、我々はいくつかの点で改善を加えます。
- 依然として「分離なし共有」クラスターを使用しているDatabricks管理者に対しては、よりセキュアな代替案に切り替えることを推奨する通知を行います。前述した通り、Databricks SQLウェアハウスと、共有・シングルユーザーアクセスモードを使用しているクラスター、テーブルACLやクレディンシャルパススルーを使用しているハイコンカレンシークラスターは影響を受けません。
- Databricks管理者に対して、ノートブックやタスクを実行する際に「シングルユーザー」あるいは「共有」クラスターを使用すること、あるいはAccount Feature Enablement Settings内の「分離なし共有」クラスター向けの新たな管理者防御機能(AWS、Azure、GCP)をお勧めします。
- よりセキュアなクラスターオプションをデフォルトにしようとしており、より厳密なセキュリティの選択肢をユーザーが有効化できる様にする追加の機能をデプロイしようとしています。
- セキュリティの影響をより明確にするためにUI(AWS | Azure | GCP)、クラスタータイプに関するドキュメント(AWS | Azure | GCP)、セキュリティベストプラクティスをアップデートしました。
以下に研究者自身の言葉による発見に対する説明を示し、Databricksの回答とお客様に対する推奨事項を示します。以下で説明されている研究内容は例としてAzure Databricksで実施、テストされていますが、この発見はいかなるクラウドプロバイダーにおける「分離なし共有」クラスターで影響を受けます。
Databricksデフォルトクラスターの内部処理の調査
by Joosua Santasalo
少し前に私はDatabricksに対する攻撃の別の観点を調査していました。このプロセスの途中で「サイドクエスト」の発見にたどり着きました。この発見は、デフォルトの挙動の不思議な組み合わせであり、多くの企業がデフォルトのプロビジョニングウィザートに従った際や常にデフォルトを使用する人が辿り着くものです。私はセキュリティの研究で多くの場合、プラットフォームとしてAzureを使っていますが、この発見はクラウドプロバイダーとしてAzure固有のものではありません。言い換えると、この発見はクラウドプロバイダーに依存するものではなく製品に依存するものです。
これらの発見を公開すると、私はDatabricksのセキュリティチームに紹介されましたが、彼らは非常に印象的な人たちでした。これまで、私は非常に積極的で知識豊富なセキュリティチームに会ったことはありませんでした。軽減策や製品変更に適切な猶予を与えるために、公開までに最大90日の猶予を持つことに合意しました。
この攻撃では、権限を持つユーザーのコントロールプレーンのトラフィックをインターセプトすることで、権限を持たないユーザーはDatabricksワークスペースに対して権限を持つユーザーのフルアクセスを得ることができます。クラスターの用途に応じて、侵害されるアクセスにはさまざまな権限や特定のDatabricksインスタンスに関連づけられるアイテムが含まれます。
Databricksが軽減策を講じる前は、同じデフォルトクラスターで処理を実行しているより高い権限を持つユーザーのトークンを得るために、シンプルに以下のtcpdumpとgrepのパターンを使用することができました。
%sh sudo tcpdump -i lo tcp port 6061 -Aq | grep "token"
このパターンは、過去に作成したデフォルト(スタンダード)クラスターでは依然として動作しますが、幸運なことに以下の「防御フラグ(Protection Flags)」の元では対応策が講じられます。
これらの発見に基づいて、Databricksでは3つのカテゴリーで変更を行いました。
新たなプロビジョンのワークフロー
新たなプロビジョニングワークフローでは、「攻撃」の部分で説明された挙動を防ぐシングルユーザークラスターがデフォルトになりました。
UXの変更とよりセキュアなデフォルト
以前のスタンダード(デフォルト)クラスターは、今では「分離なし共有(No isolation Shared)」クラスターと呼ばれています。今ではドキュメントでは、以前のデフォルトクラスターモードを使用することを推奨していません。以前のデフォルトクラスターモードを作成するには、UXにおいて選択肢を確認することで、一連の「ガードレール」を意図的に取り除く必要があります。
防御フラグ
おそらく最大の変更は、既存あるいは新規のクラスターでこの悪意のある挙動を防御することです。このフラグを有効化することで、クラスターを操作している管理者ユーザーがいることを検知し、同じクラスターで悪意を持つユーザーによる共有チャネルのAPIトークンの漏洩を防御します。
公開のタイムライン
- 6月 - MSRCとのミーティング後すぐに初回の提出
- 7月-9月 - さまざまなコミュニケーション、テスト、対策の提案
- 10月 - 対策のデプロイ
研究者のクレジット、議論 : Secureworks, MSRC & MS Adversary Tradecraft Group - Nixu, DataBlinc
Databricksの解答および推奨事項
Joosuaが指摘したこの発見は、あなたが「分離なし共有」クラスターを使用しており、管理者と非管理者のロールを強力に分離する位必要がある場合にはワークスペースに影響があります。上述した様に、Databricks SQLウェアハウスや共有、シングルユーザーアクセスモードのクラスターは影響を受けません。古いクラスターUI(AWS | Azure | GCP)を使用している際には、テーブルACLやクレディンシャルパススルーを使用しているハイコンカレンシークラスターでは影響はありません。この研究では、「分離なし共有」アクセスモードのクラスターにおいて、ある認証済みユーザーが同じクラスターで作業している別のユーザーのシークレットを取得することができる方法を文書化しています。これによって、当該クラスターにおいて別のユーザーのアクセス権限に、権限を持たないユーザーがアクセスできる可能性があります。
この問題がなぜ起こりうるのか、対策としてDatabricksは何をしたのか、何をしているのか、お客さまが適用したいと考えるであろういくつかのステップを説明したいと思います。最も重要なステップは、可能であれば分離なし共有クラスターからワークロードを取り除くことです。
-
なぜ起こりうるのか？ 分離なし共有クラスターは、設計上、同じ共有環境で複数ユーザーからの任意のコードを実行します。これは複数ユーザーによって共有されるクラウドの仮想マシンと同じ様なものです。結果として、当該環境にプロビジョンされるデータや認証情報は、その環境で実行される任意のコードからアクセスできる場合があります。通常のオペレーションにおいてDatabricksのAPIを呼び出すためには、これのクラスターにユーザーの代わりにアクセストークンがプロビジョンされます。ワークスペース管理者のような高い権限を持つユーザーがクラスターでコマンドを実行すると、高い権限を持つトークンが同じ環境で見える様になります。上述した通り、この発見は任意のクラウドプロバイダーの「分離なし共有」クラウsターで影響があります。
分離なし共有クラスターは、すべてのユーザーが同じレベルのアクセス権限を持っている場合(1つのクラウドIAMロールなど)や、コラボレーションするための柔軟な環境を必要とした際に有用です。この様な条件では、複数のユーザーは同じレベルのアクセス権を持つことで、権限のエスカレーションはリスクとはならず、分離なし共有モードは戦略的な環境となり得ます。しかし、通常のユーザーと管理者との間に強力なセキュリティ境界が必要な場合には、シングルユーザーあるいは共有アクセスモードはよりセキュアなユーザー分離を可能とします。
-
Databricksは何をしているのか？ Account Feature Enablement Settings内で「分離なし共有」クラスターの管理者保護を可能にするための、アカウント管理者向けのアカウントレベルのセキュリティコントロール(AWS、Azure、GCP)を実装しました。このオプトイン設定によって、分離なし共有クラスターに管理者の認証情報がプロビジョンされることを防ぐことができます。
また、管理者がワークスペース全体で「分離なし共有」クラスターを無効化するための「Enforce User Isolation」ワークスペースフラグを提供しています。
最後になりますが、我々のドキュメント、UI、セキュリティのベストプラクティスが、リスクとトレードオフを十分に説明するようにすることおで、お客様に十分な情報と選択肢を提供するご支援を行なっています。
-
お客様は何をすべきか？ この記事の最後のセクションにベストプラクティスを列挙していますが、端的に言うと管理者はよりセキュアなクラスタータイプを使用すべきであり、分離なし共有クラスターでは非管理者アカウントのみを使用すべきであり、予防策として新たな管理者保護機能(AWS、Azure、GCP)を有効化すべきです。
お使いのDatabricksクラスターを強固にする
お客様は、以下の推奨事項を通じてご自身のDatabricksデプロイメントのセキュリティを強化することができます。
- 可能であればユーザー分離をサポートするクラスタータイプを使用してください。 お客様は多くの場合、Databricks SQLウェアハウスや共有、シングルユーザーアクセスモードのクラスター、テーブルACLやクレディンシャルパススルーを設定したハイコンカレンシークラスターを用いることで、ユーザー分離を強制しており、これらの問題を回避しています。
- Account Feature Enablement Settingsで「分離なし共有」クラスター向けの管理者保護(AWS、Azure、GCP)を有効化してください。この新たな設定により、「分離なし共有」クラスターに管理者の認証情報がプロビジョンされることを防ぐので、短期間に別のクラスタータイプに移行できないお客様に対してはおすすめの方法となります。
- ワークスペースで分離なし共有クラスターの作成を許可しない、あるいは、特定のユーザーグループのみが分離なし共有クラスターの作成を許可する(AWS、Azure、GCP)ことができます。どのユーザーがこれらのクラスターにノートブックをアタッチできるのかを制御するクラスターACLを使用する子ができます。あるいは、新たな「Enforce User Isolation」ワークスペースフラグによって、特定のワークスペースでの「分離なし共有」クラスターを無効化することができます。
- ワークスペースを管理する必要があるユーザーは、通常の使用においては別の非管理者アカウントを使うべきであり、管理目的のアクティビティの際にのみ管理者アカウント使用すべきです。
ユーザー分離クラスター：まとめと今後
進化し続けるお客様とデータチームのニーズに応えるために、Databricksは徐々に「分離なし共有」クラスターの利用を取りやめる方向にあります。Unity Catalogのリリースは我々が目指しているモデルの一部であり、ここではすべてのユーザーはユーザー分離を強制するセキュアなクラスターで作業を行います。Unity Catalogのデータは設計上、分離なし共有クラスターからはシンプルにアクセすることができず、設定ミスによるエラーのいかなるリスクも防御します。より多くのユーザーは、Joosuaのようなセキュリティ研究者によって報告される一連の問題を対策する様に設計された共有アクセスモードのクラスター、テーブルACLを伴うハイコンカレンシークラスター(あるいは、Databricks SQLウェアハウス)を設定しています。
繰り返しになりますが、Databricksをよりセキュアなものにするために日々取り組んでいるJoosua Santasaloとすべてのセキュリティ研究者に感謝の意を表します。あなたがセキュリティ研究者であるのであれば、hackerone.com/databricksでお会いしましょう。