Enterprise security for the E2 version of the Databricks platform | Databricks on AWS [2021/6/11時点]の翻訳です。
Databricksクイックスタートガイドのコンテンツです。
本書では、E2バージョンのDatabricksレイクハウスプラットフォームにおける、最も重要なセキュリティに関連する制御と設定の概要について説明します。
本書では、架空の企業を例に取り、中小企業、大企業においてどのように異なるデプロイメントになるのかを比較するために幾つかのシナリオを説明します。ここでは、架空の大企業LargeCorpと、架空の小企業SmallCorpを考えます。これらの例を全体的なガイドとして使用しますが、企業ごとに事情は異なります。疑問がある場合には、Databricksの担当者にお問い合わせください。
特定のセキュリティ機能の詳細に関しては、Databricksセキュリティガイドを参照ください。Databricks担当にお問い合わせいただければ、担当者からE2プラットフォームにおける追加のセキュリティ、コンプライアンスに関するドキュメントが提供されます。
注意
このドキュメントで議論される機能は全ての料金プラン、デプロイメントタイプ、リージョンで利用できるわけではありません。いくつかの機能はパブリックプレビューです。機能を利用できるかどうかに関しては、Databricks担当にお問い合わせください。
アカウントプラン
利用したい機能に関しては、Databricks担当にお問い合わせください。必要な料金プランおよびデプロイメントタイプを選択する手助けをいたします。全ての料金プラン、デプロイメントタイプ、リージョンで全ての機能を利用できるわけではありません。料金プランと機能の対応関係は、Databricks AWSプライシングページでご確認ください。
このドキュメントでは、お使いのアカウントはE2バージョンであることを前提としています。以下のセキュリティ関係の機能はE2デプロイメントでしか利用できません。
- 顧客管理VPC：お客様のAWSアカウントのVPCにDatabricksワークスペースをデプロイします。Premiumプランが必要となります。
- セキュアクラスター接続：VPCにはオープンされているポートはなく、DatabricksランタイムクラスターノードにもパブリックのIPアドレスは付与されません。E2バージョンのプラットフォームにおいては、デフォルトでセキュアクラスター接続が有効化されています。Premiumプランが必要となります。
- マネージドサービスに対する顧客管理の暗号化キー：お客様が管理するAWS KMSキーによりノートブック、機密データを暗号化します。この機能はパブリックプレビューであり、Enterpriseプランが必要となります。
この他、本書で議論されるセキュリティ関連の機能の多くはPremiumプランで利用できますが、いくつかはEnterpriseプランが必要となります。
- IPアクセスリスト：ワークスペースのユーザーのアクセス元を制限します。
シングルサインオン(SSO)は全てのプランで利用できます。
ワークスペース
Databricksのワークスペースは、お客様がDatabricksのアセットにアクセスするための環境となります。ワークスペースはお客様のオブジェクト(ノートブック、ライブラリ、エクスペリメント)をフォルダーで整理します。ワークスペースからデータやクラスター、ジョブと言った計算資源にアクセスすることができます。
お客様の組織において、チームがコラボレーションするために、幾つのワークスペースが必要になるのかを地理的要件に基づいて決定します。
SmallCorpのように中小企業の例においては、一つあるいは数個のワークスペースのみが必要になるでしょう。これは、大企業において自己完結する単独の部門においても同じことが成立します。ワークスペースの管理者は、ワークスペースを利用するユーザーの一人かもしれません。いくつかのケースでは、別の部門(IT/OpSec)が企業のガバナンスポリシーを施行し、アクセス権、ユーザー、グループを管理するかもしれません。
LargeCorpのような大企業の例では、多くの場合、多数のワークスペースが必要となります。LargeCorpにはすでに全てのセキュリティと管理機能を有した集中管理されたグループ(IT/OpSec)があります。多くの場合、このグループが新たなワークスペースをセットアップし、企業全体にセキュリティコントロールを適用します。
大企業において複数のワークスペースを作る一般的な理由には、以下のようなものがあります。
- それぞれのチームが異なるレベルの機密情報(個人情報を含む)を取り扱います。ワークスペースを分けることで、アクセスコントロールリストなどの複雑性を持ち込むことなしに、チームは異なるレベルの機密情報を分離できます。例えば、LargeCorpの財務部チームは容易に財務関係のノートブックを、簡単に他の部門が使うワークスペースから分離することができます。
- Databricks利用(DBU)に対する請求と、クラウドコンピューティングの課金を異なる部門にチャージできるので、予算管理をシンプルにすることができます。
- チーム及びデータソースの地理的リージョンのバリエーション。あるリージョンのチームは、コスト、ネットワークのレーテンシー、リーガルの観点から異なるリージョンのクラウドリソースを必要とするかもしれません。それぞれのワークスペースを異なるリージョンにデプロイすることができます。
ワークスペースのデータプレーンは、AWSのリージョンap-northeast-1、ap-south-1、ap-southeast-2、ca-central-1、eu-west-1、eu-west-2、eu-central-1、us-east-1、us-east-2、us-west-1、us-west-2にデプロイすることができます。しかし、マネージドサービス、ワークスペースストレージの暗号化に顧客管理の暗号化キーを使う際、us-west-1のVPCを利用することはできません。
チーム、プロジェクト、地理的位置に基づいてリソースに対するアクセスを隔離する際、ワークスペースの分離が一般的なアプローチですが、他の選択肢もあります。ワークスペースの管理者は、ワークスペースでアクセスコントロールリスト(ACL)を用い、グループのメンバーシップに基づいて、ノートブック、フォルダー、ジョブなどのリソースに対するアクセスを制限することができます。単一のワークスペースにおいて、データソースに対するアクセスを制御する別の選択肢には、クレディンシャルパススルーがあります。
VPCのプラン
AWSのVirtual Private Cloud(VPC)を用いることで、AWSクラウドにおいて、バーチャルネットワーク上にAWSのリソースを起動することができる、論理的に分離されたセクションを提供することができます。VPCはDatabricksクラスターのネットワーク上の位置となります。デフォルトでは、DatabricksがDatabricksワークスペースのためのVPCを作成、管理します。
顧客管理VPCを用いることで、ワークスペースのクラスターをホストするお客様管理のVPCを指定することができます。IPアドレスのレンジ、サブネット、ルーティングテーブル、NATゲートウェイを制御することができます。
SmallCorpでは、Databricksワークスペースに対して単一の顧客管理VPCのみが必要になるかもしれません。ネットワークアーキテクチャ、リージョンに依存して、2〜3のワークスペースがある場合には、複数ワークスペースに対して単一のVPCをシェアする場合もあれば、そうでない場合もあるかもしれません。あるいは、SmallCorpがより幅広いアクセス権が割り当てられたクロスアカウントIAMロールをDatabricksに提供し、Databricksが自動でVPCを作成するケースにおいては、SmallCorpはDatabricksが作成、管理するVPCを使用するという選択をするかもしれません。
お客様が大企業の場合には、Databricksが使用するVPCに顧客管理VPCを指定したいと思うかもしれません。AWSリソース割り当てをシンプルにするために、複数のワークスペースでVPCをシェアすることも可能です。あるいは、異なるAWSアカウント、リージョンのVPCをお持ちの場合には、別々にVPCとワークスペースを割り当てることができます。
LargeCorpのような大企業が単一のVPCに複数のワークスペースをグルーピングする理由は、VPCごとに類似した外向き通信(egress)の設定を集中管理するというものです。例えば、5つの部署が同様のデータソースで作業をするために、同じVPCをシェアするでケースがあるでしょう。しかし、財務チームのデータアナリストが特別な内部データベースにアクセスする特別なネットワークを必要とするかもしれませんが、不正アクセスのリスクを低減することが重要となります。別々のVPC(異なるAWSアカウントに存在するかもしれません)にチームをグルーピング、分離することで、適切なクラウドNATやファイアウォールアプライアンスによって、ネットワークレベルでデータソースへのアクセスを許可、あるいはブロックすることが可能となります。
ネットワークのアーキテクチャを設計し、ワークスペースでVPCを共有するかどうか江尾決定する際には、クラスターノードからそれぞれのデータソースへの外向きのネットワーク接続をどのようにロックダウンしたいのかを検討してください。
ワークスペースの作成
E2バージョンのプラットフォームのアカウントにおいては、アカウントコンソールあるいはアカウントAPIを用いて新規ワークスペースを作成することができます。あるいは、TerraformやAWS Quick Start(CloudFormation)による自動化テンプレートでワークスペースを配備することができます。
新規ワークスペースを作成する際の一般的なアプローチは以下の通りとなります。
- Databricksがワークスペースに対して適切なタスクを実行できるようにIAMクロスアカウントロール(委任クレディンシャル)を作成します。次に、アカウントコンソールあるいはアカウントAPIを用いて、新規ロールに対するIDを包含する認証設定(credential configuration)を作成します。
- ライブラリ、ログ、ノートブックの改訂履歴などのワークスペースデータを格納するS3バケットを作成します。このルートストレージを本格運用で用いる顧客データなどには使用しないでください。次に、アカウントコンソールあるいはアカウントAPIを用いて、S3バケット名を包含するストレージ設定(storage configuration)を作成します。
- オプションとして、顧客管理VPCを指定します。ワークスペース用のVPCを作成していない場合には、作業を進める前にVPCの要件を注意深く読んでください。アカウントコンソールあるいはアカウントAPIを用いて、VPC、サブネット、セキュリティグループを包含するネットワーク設定(network configuration)を作成します。
- (アカウントコンソールではなく)アカウントAPIを利用している場合にのみ、オプションとして、マネージドサービスに対する顧客管理キーとワークスペースストレージに対する顧客管理キーを指定することができます。お使いのAWS KMSの鍵のIDを含む鍵設定(key configuration)をアカウントAPIで指定します。
- アカウントコンソールあるいはアカウントAPIを用いて、上記設定オブジェクトを指定してワークスペースを作成します。
上記手順を繰り返すことで、お使いのアカウントに複数のワークスペースを作成することができます。すべてではありませんがいくつかのリソースを複数のワークスペースで共有することができます。
- 認証設定を別のワークスペースで再利用できます。
- ストレージ設定を別のワークスペースで再利用できます。
- VPCは再利用できますが、別のワークスペースでサブネットを再利用することはできません。ネットワーク設定にVPCのサブネットIDが含まれているため、別のワークスペースでネットワーク設定を再利用することができません。
- 顧客管理キーを別のワークスペースで再利用することはできます。
詳細に関してはこちらを参照ください。
- アカウントコンソール：Create and manage workspaces using the account console
- アカウントAPI：Create a new workspace using the Account API
認証及びユーザーアカウントの作成
デフォルトのDatabricksのユーザー認証は、ローカルのユーザーアカウントと認証情報がDatabricksのコントロールプレーンで管理されるシンプルなものです。
セキュリティを気にされる多くの企業では、SAML 2.0を用いたシングルサインオン(SSO)を実装します。お使いのSAML 2.0アイデンティティプロバイダー(IdP)が多要素認証(MFA)をサポートしているのであれば、Databricksでも活用することができますが、実装の責任はIdPが負います。DatabricksはユーザーのSSOの認証情報へのアクセスはできません。詳細はSet up single sign-onをご覧ください。
Allow Auto User Creationと呼ばれるSAMLの設定機能を有効化することで、SSOのログインの過程で必要に応じてユーザーのDatabricksアカウントが配備されます。これは時にJust-in-time(JIT)プロビジョニングとよばれます。
Databricksは、クロスドメインアイデンティティ管理向けシステム(SCIM)をサポートしています。多くのIdPは、Databricksアカウントの作成、削除を行うユーザー、グループのSCIM同期をビルトインでサポートしています。ノートブックのようなDatabricksのリソースに対するアクセスコントロールリスト(ACL)の管理にユーザー名を使うことができますが、グループのSCIM同期を用いることでDatabricksのACL管理がより容易になります。詳細はアクセスコントロールリスト(ACL)をご覧ください。SCIMはパブリックプレビューとして利用できます。
SSOが有効化された際、デフォルトでは管理者のみがローカルのパスワードを用いてWebアプリケーションにログインすることができます。ローカルに保存されたパスワードの使用は、ナイーブな認証と呼ばれます。REST APIにおいては、デフォルトで全てのユーザーはローカル(ナイーブな認証)のパスワードで認証されます。管理者はAdminコンソールあるいはPermissions APIを用いて、SSOが有効化された際に、どのユーザーがナイーブな認証で(WebアプリケーションあるいはREST APIに)接続できるのかを制限できるように、パスワードの設定権限を設定することができます。
セキュアなAPIアクセス
REST APIの認証に関しては、復旧可能なDatabricksビルトインのパーソナルアクセストークンを使用してください。ユーザーは、Webアプリケーションインタフェースでパーソナルアクセストークンを作成します。
現在のパーソナルアクセストークンの確認、削除、新規トークンの寿命を設定できるトークン管理APIがあります。ワークスペースのREST APIにアクセスするために、どのユーザーがトークンを作成、使用できるようにするのかを定義するトークンアクセス権を設定するためにPermissions APIを使用してください。
使用が許可されたユーザー、グループのみがREST APIにアクセスできるように、最小権限の原則を適用するためにトークンのアクセス権を使用してください。
Databricksプラットフォームバージョン3.28(2020年9月15日)リリース以降に作成されたワークスペースにおいては、デフォルトでは管理ユーザーのみがパーソナルアクセストークンを生成することができます。管理者は明示的に、すべてのusersグループ、あるいはユーザー、グループごとに、これらの権限を許可すべきです。Databricksプラットフォームバージョン3.28以前に作成されたワークスペースにおいては、この変更の前に許可されたアクセス権は維持されますが、異なるデフォルトの振る舞いをします。ワークスペースがいつ作成されたのかがわからない場合には、ワークスペースのトークンのアクセス権を確認してください。
トークンに対するAPI、adminコンソールのツールの完全なリストに関しては、Manage personal access tokensを参照ください。
注意
トークンを使用することを強くお勧めしますが、AWSのDatabricksユーザーは、Databricksのユーザー名、パスワードを用いて(ナイーブな認証)REST APIにアクセスすることもできます。パスワードのアクセスコントロールを用いてREST APIに対するナイーブな認証を無効にすることができ、特定のユーザー、グループにアクセスを割り当てることができます。
IPアクセスリスト
認証はユーザーのアイデンティティを検証しますが、ユーザーのネットワーク上の位置を強制するものではありません。セキュアでないネットワークからのクラウドサービスへのアクセスは、特にユーザーが機密データ、個人情報にアクセスできる場合にはリスクを引き起こします。企業ネットワーク周辺(例えば、ファイアウォール、プロキシー、DLP、ロギング)ではセキュリティポリシーが適用され、外部サービスへのアクセスは制限されますが、これらの制御からはずれているアクセスは信頼できないものと考えられます。
例えば、従業員がオフィスから出てコーヒーショップに行った場合には、企業は、この従業員が適切な認証情報を持っていたとしても、WebアプリケーションやREST APIへのアクセスをブロックすることができます。
パブリックネットワークにおけるIPアドレス(あるいはCIDRレンジ)を指定してアクセスを許可することができます。これらのIPアドレスは外向き通信のゲートウェイや特定のユーザー環境に属することも可能です。あるいは、許可リストに含まれていたとしても、ブロックすべきIPアドレス、サブネットを指定することができます。例えば、許可されたIPアドレスレンジに、通常はセキュアなネットワークの外と考えられる小規模のインフラストラクチャのIPアドレスを含めることができます。
詳細に関しては、IP access listsを参照ください。
監査、使用ログ
お客様のDatabricksユーザーの使用量、アクティビティをモニタリングするために、監査、使用ログを設定することを強くお勧めします。
- **課金使用ログのデリバリー：**使用ログをAWS S3バケットに自動でデリバリー。詳細はDeliver and access billable usage logsを参照ください。
- **監査ログのデリバリー：**監査ログをAWS S3バケットに自動でデリバリー。詳細はConfigure audit loggingを参照ください。
新規ワークスペースで監査ログを有効化する際には、Databricks担当にコンタクトしてください。監査ログを有効化した後は、感サログを確認してください。課金使用ログはデフォルトで有効化されており、アカウントコンソールで参照することができますが、AWS S3バケットにログファイルをデリバリーするにためには設定が必要です。
クラスターポリシー
インスタンスタイプやノード数、アタッチされるライブラリ、計算コストなどの特定のクラスター設定を強制し、異なるユーザーに異なるクラスター作成画面を表示するためにクラスターポリシーを使用してください。ポリシーによるクラスター設定の管理は、全体的なガバナンスの適用と、計算インフラストラクチャの管理をサポートします。
SmallCorpのような中小規模においては、全クラスターに対して単一のポリシーで十分かもしれません。
LargeCorpのような大企業においては、以下のように複雑な複数のポリシーが必要になるかもしれません。
- 極端に大きいデータセットを操作し、複雑な計算を必要とする顧客データの分析者には、100ノードのクラスターの作成を許可。
- 財務チームのデータ分析者には、10ノードのクラスターを許可。
- 小規模のデータセットとシンプルなノートブックを操作する人事部には、4〜8ノードにオートスケールするクラスターを許可。
アクセスコントロールリスト(ACL)
多くのDatabricksオブジェクトには、特定のユーザー、グループのアクセスを制御するアクセスコントロールリスト(ACL)があります。管理者はAdminコンソールあるいはPermissions APIでACLを有効化することができます。
管理者は、非管理者ユーザーにCan manage権限を許可することで、いくつかのACL設定を委任することができます(例えば、クラスターに対してCan manage権限を持つユーザーは、他のユーザーに対して当該クラスターのアタッチ、再起動、リサイズ、管理を許可することができます)。
ユーザー、グループに対して以下のACLを設定することができます。特別な場合を除き、WebアプリケーションあるいはREST APIでACLを変更することができます。
| オブジェクト | 説明 |
|---|---|
| テーブル | データテーブルへのアクセスを強制します。 |
| クラスター | どのユーザーがクラスターを管理、再起動、アタッチできるかを管理します。クラスターにデータソースに対する認証パススルーが設定されている場合には、クラスターへのアクセスはセキュリティに影響します。詳細はデータソースクレディンシャルパススルーを参照ください。 |
| プール | どのユーザーがプールにアタッチできるのかを管理します。いくつかのAPI、ドキュメントではプールをインスタンスプールと呼んでいます。プールを用いて、すぐに使えるアイドル状態のクラウドインスタンスを維持することで、クラスターの起動時間、オートスケーリングに要する時間を短縮することができます。プールにアタッチされたクラスターがインスタンスを必要とした際に、まずプールにあるアイドル状態のインスタンスを配置しようとします。プールにアイドル状態のインスタンスがない場合には、クラスターの要求に応えるためにインスタンスプロバイダーからインスタンスを割り当てることでプールを拡張します。クラスターがインスタンスをリリースした際には、インスタンスはプールに戻り、他のクラスターが使用することができます。プールにアタッチされたクラスターのみが、プールのアイドルインスタンスを使用できます。 |
| ジョブ | どのユーザーがジョブを参照、管理、実行、キャンセル、所有できるのかを管理します。 |
| ノートブック | どのユーザーがノートブックを参照、実行、編集、管理できるのかを管理します。 |
| フォルダー(ディレクトリ) | どのユーザーがフォルダー内のすべてのノートブックを参照、実行、編集、管理できるのかを管理します。 |
| MLflowに登録されたモデル及びエクスペリメント | どのユーザーがMLflowに登録されたモデルおよびエクスペリメントを参照、編集、管理できるのかを管理します。 |
| トークン | どのユーザーがトークンを作成、使用できるのかを管理します。セキュアなAPIアクセスを参照ください。 |
| パスワード | SSOが有効化され、REST APIを利用する際に、どのユーザーがパスワードログインできるのかを管理します。認証及びユーザーアカウントの作成も参照ください。 |
チームサイズと情報の機密度に依存しますが、自身のワークスペースを持つSmallCorpのような小規模な企業あるいはLargeCorpの小規模なチームは、クラスター、ジョブ、ノートブック、ディレクトリのような同じオブジェクトに対して、すべての非管理者ユーザーのアクセスを許可するかもしれません。
大規模チーム、あるいは美々津性の高い情報を取り扱う企業においては、ここのユーザーが許可されたリソースにのみアクセスできるようにする最小権限の原理を強制するために、これらのアクセスコントロールを使いたいと考えるでしょう。
例えば、LargeCorpにおいて特定のワークスペースのフォルダー(このフォルダーにはノートブック、エクスペリメントがあります)にアクセスする必要がある人が財務チームに3人いるとします。LargeCorpは財務データチームのグループにのみディレクトリへのアクセスを許可するためにこれらのAPIを使用できます。
データソースクレディンシャルパススルー
IAMロールのクレディンシャルパススルーを用いることで、Databricksにログインする際に使用しているアイデンティティを用いて、DatabricksクラスターからS3バケットに対して自動で認証を行うことができます。管理者がIAMロールを作成し、Databricksユーザーを適切なロールにマッピングし、これらのIAMロールをクラスターに割り当てます。ユーザーがクラスターで実行するコマンドは、対応するアイデンティティを用いてS3にデータを読み書きします。
あるいは、AWSのインスタンスプロファイルを設定し、クラスターに割り当てることで、S3バケットにセキュアにアクセスすることができます。このアプローチの欠点は、一つのインスタンスプロファイルしかクラスターに割り当てられず、クラスターにアクセスする必要があるユーザーは当該インスタンスプロファイルにもアクセスできる必要があるということです。一方、IAMロールのクレディンシャルパススルーは、データセキュリティを維持しつつも、S3のデータにアクセスするために一つのDatabricksクラスターを共有して、複数のユーザーに異なるデータアクセスポリシーを割り当てることができます。別の利点にはデータガバナンスがあります。IAMロールのクレディンシャルパススルーはアイデンティティとユーザーを紐付けます。これによって、CloudTrailによるS3オブジェクトのロギングが可能となります。CloudTrailのログにおけるARNによって、S3へのすべてのアクセスはユーザーと直接関連づけられます。
LargeCorpのような大企業においては、彼らの秘密情報をAWS Systems Manager(以前のEC2 SSM)に保存したいと考え、アクセス用のIAMロールを作成し、このIAMロールを一連のクラスターIAMロールに設定したいと考えるかもしれません。
詳細は、Access S3 buckets using IAM credential passthrough with Databricks SCIMを参照ください。
シークレット
ノートブックで必要となる秘密情報を設定するためにシークレットマネージャを昼用とするかもしれません。シークレットは、外部データソースや他の計算処理に必要となる秘密情報を格納するキーバリューのペアです。キーの名前はシークレットスコープで一意である必要があります。
REST APIあるいはCLIでシークレットを作成できますが、シークレットをノートブック、ジョブで読み取るためにはシークレットユーティリティ(dbutils.secrets)を使う必要があります。
あるいは、LargeCorpのような大企業では、彼らの秘密情報をAWS Systems Manager(以前のEC2 SSM)に保存したいと考え、アクセス用のIAMロールを作成し、このIAMロールを一連のクラスターIAMロールに設定したいと考えるかもしれません。データソースクレディンシャルパススルーを参照ください。
オートメーションテンプレートのオプション
DatabricksのREST APIによって、TerraformやAWS Quick Start(CloudFormation)テンプレートを用いてセキュリティ設定タスクのいくつかを自動化することができます。これらのテンプレートは新規ワークスペースのデプロイ、設定に使用できますが、既存ワークスペースの管理設定を更新するために使用することができます。特に多数のワークスペースがある大企業においては、テンプレートの利用によって、迅速かつ一貫性のある自動設定を実現します。
Use automation templates to create a new workspace using the Account APIを参照ください。