Databricks Unityカタログのシステムテーブルを使用したLakehouseセキュリティ監視の改善
システム・テーブルを使用して実用的な洞察を導き出し、レイクハウスにゼロ・トラスト・アーキテクチャーを導入する方法をご覧ください
翻訳：Junichi Maruyama. - Original Blog Link
データフォワード組織にとってレイクハウスがますますミッションクリティカルになるにつれて、予期せぬイベント、停止、セキュリティインシデントが新たな予期せぬ方法で業務を頓挫させるリスクも高まっています。Databricks はいくつかの重要な観測可能性機能を提供し、顧客がこの新しい脅威のセットを先取りし、かつてないほどレイクハウスを可視化できるように支援します。
セキュリティの観点から、組織が現代社会に適応する方法の 1 つは、ゼロ トラスト アーキテクチャ (ZTA) モデルに従うことによって、「信頼せず、常に検証する」という原則に頼ることです。このブログでは、Databricks Lakehouse Platform上でZTAを始める方法を紹介し、一連のSQLクエリとアラートを自動生成するDatabricks Notebookを共有します。もしあなたが普段このようなことにTerraformを使っているのであれば、こちらのコードをご覧ください
システムテーブルとは？
システムテーブルは、Delta Lakeによってバックアップされ、Unity Catalogによって管理される一元化された運用データストアとして機能する。システムテーブルはあらゆる言語でクエリを実行できるため、BIからAI、さらにはジェネレーティブAIまで、さまざまなユースケースの基盤として使用することができます。システム・テーブルの上に実装される最も一般的なユースケースには、以下のようなものがあります：
- 利用分析
- 消費/コスト予測
- 効率分析
- セキュリティ＆コンプライアンス監査
- SLO（サービスレベル目標）分析とレポーティング
- 実用的なデータ運用
- データ品質のモニタリングとレポート
様々なスキーマが利用可能ですが、このブログでは主にsystem.access.auditテーブルに焦点を当て、特にDatabricks上のゼロトラストアーキテクチャを補強するためにどのように使用できるかを説明します。
Audit Logs
system.access.auditテーブルは、Databricks Lakehouse Platform上で発生した全てのマテリアルイベントを記録するシステムとして機能します。このテーブルを使用するユースケースには以下のようなものがあります：
- セキュ リティと法令遵守
- 監査分析
- 利用規定（AUP）の監視と調査
- セキュリティ・インシデント対応チーム（SIRT）の調査
- フォレンジック分析
- 障害調査と事後調査
- 侵害の兆候（IoC）の検出
- 攻撃の指標（IoA）の検出
- 脅威モデリング
- 脅威ハンティング
従来、この種のログを分析するためには、クラウドストレージをセットアップし、クラウドプリンシパルとポリシーを設定し、ETLパイプラインを構築してスケジューリングし、データを処理して準備する必要があった。今回のSystem Tablesの発表では、オプトインするだけで、必要なデータがすべて自動的に利用できるようになる。何よりも、サポートされているすべてのクラウドでまったく同じように機能する。
システム・テーブルで、あなたのレイクハウスを "信頼せず、常に検証する"
ゼロ・トラスト・アーキテクチャー（ZTA）の重要なコンセプトには、以下のようなものがある：
- ユーザーとアクセスの継続的検証
- 最も権限のあるユーザーとサービスアカウントを特定
- データフローのマッピング
- 最小権限の原則に基づいてアクセス権を割り当てる
- モニタリングが重要
このブログでは、主に「モニタリング」が重要であることに焦点を当てますが、Unity Catalogがどのようにデータ先進企業のZero Trustアーキテクチャの実装を支援するかについても、その幅広い機能セットで簡単に触れておきましょう：
- ユーザーとアクセスの継続的検証:
- Unity Catalogは、すべてのリクエストに対してパーミッションを検証し、許可されたユーザーに短命でダウンスコープされたトークンを付与する。
- UCにおけるアイデンティティ・アクセス管理は、最初のプロアクティブな防衛ラインを提供する一方で、「信頼せず、常に検証する」ためには、レトロスペクティブなモニタリングと組み合わせる必要がある。アクセス管理だけでは、設定ミスの特権やポリシー、あるいは組織内で誰かが退職したり役割が変わったりしたときの権限のドリフトを検出し解決することはできない。
- 最も特権のあるユーザーとサービスアカウントを特定する：
- Unity Catalogに組み込まれているsystem.information_schemaは、誰がどのセキュラブルにアクセスできるかを一元的に表示するため、管理者は最も権限のあるユーザーを簡単に特定できます。
- information_schemaは現在のビューを提供しますが、これをsystem.access.auditログと組み合わせることで、付与/取り消し/特権を長期にわたって監視することができます。
- データフローのマッピング:
- Unity Catalogは、カラムレベルまでリアルタイムでデータのリネージを自動追跡します。
- Systemテーブルのおかげで、UI（AWS とAzureのドキュメントを参照）を介してリネージを探索することができる一方で、それはまた、プログラムでクエリすることができます。AWSとAzureのドキュメントをチェックし、近々このトピックに関するブログを更新する予定だ！
- 最小特権の原則に基づいてアクセス権を割り当てる。:
- Unity Catalogの統一インターフェースは、データやAI資産へのアクセスポリシーの管理を大幅に簡素化し、あらゆるクラウドやデータプラットフォーム上で一貫してポリシーを適用します。
- さらに、システムテーブルは最小特権の原則にもすぐに従います！
モニタリングが重要
効果的なモニタリングは、効果的なゼロ・トラスト・アーキテクチャの重要な基盤の1つである。効果的な監視を行うには、必要と思われるログを取得し、調査やインシデントが発生した場合にのみ照会すれば十分だと考える罠にはまりがちだ。しかし、"Never Trust, Always Verify"（信頼せず、常に検証する）の原則に沿うためには、もっと積極的に行動する必要があります。ありがたいことに、Databricks SQLではsystem.access.auditテーブルに対するSQLクエリを簡単に書くことができます。
Quickstart notebook
Databricksワークスペースにリポジトリをクローンし（AWS と Azureのドキュメントを参照）、create_queries_and_alertsノートブックを実行します。40 以上のクエリとアラートが自動生成されます：
| Query / Alert Name | Query / Alert Description |
|---|---|
| Repeated Failed Login Attempts | 過去24時間以内に、60分以上にわたって繰り返しログインに失敗した。 |
| Data Downloads from the Control Plane | ノートブック、Databricks SQL、Unity Catalogボリューム、MLflowからの結果のダウンロード数が多いこと、および過去24時間以内のクエリ結果を含む可能性のあるフォーマットでノートブックがエクスポートされていること。 |
| IP Access List Failures | 過去24時間以内に信頼できないIPアドレスからアカウントまたはワークスペースにアクセスしようとしたすべての試行。 |
| Databricks Access to Customer Workspaces | 過去 24 時間以内に Databricks サポートプロセス経由でワークスペースにログ インしたすべて。このアクセスはサポートチケットに関連付けられますが、ワークスペースの設定に従うことでこのようなアクセスを無効にすることもできます。 |
| Destructive Activities | 過去24時間以内に60分間で削除された件数が多い。 |
| Potential Privilege Escalation | 過去24時間以内に60分間でパーミッションの変更回数が多い。 |
| Repeated Access to Secrets | 過去 24 時間以内の 60 分間に、秘密へのアクセスを繰り返し試行した。これは、認証情報を盗む試みを検出するために使用できる。 |
| Repeated Unauthorized Data Access Requests | 過去24時間以内に、Unityカタログのセキュラブルへのアクセスが60分以上にわたって繰り返し不正に試みられた。繰り返し失敗するリクエストは、権限の昇格、データ流出の試み、またはデータへのブルートフォースアクセスを試みる攻撃者を示している可能性があります。 |
| Antivirus Scan Infected Files Detected |
強化されたセキュリティとコンプライアンスアドオンをご利用のお客様には、過去24時間以内にホスト上で検出された感染ファイルを検出します。 |
| Suspicious Host Activity | 化されたセキュリティとコンプライアンスアドオンをご利用のお客様には、過去24時間以内にビヘイビアベースのセキュリティ監視エージェントによってフラグ付けされた不審なイベントを検出します。 |
ノートブックを実行したら、一番下までスクロールすると、各SQLクエリとアラートへのリンクがあるHTMLテーブルが表示されます：
アラートをテストするには、リンクをたどって更新を選択するだけです。アラートが作動していなければ、左上に緑色のOKマークが表示されます：
アラートがトリガーされた場合、アラートをトリガーしたすべてのイベントを含むテーブルが記載されたEメールを受信します。アラートをスケジュールで実行するように設定するには、[編集]、[更新]の順に選択し、アラートを実行する頻度を選択します：
電子メールアドレス、Slackチャンネル、MS Teamsなど（他にもあります！）通知先を追加するなど、必要に応じてアラートをさらにカスタマイズすることができます。 すべてのオプションの詳細については、AWS と Azureのドキュメントをご覧ください。
高度な使用例
これまで見てきた監視と検出のユースケースは比較的単純だが、システム・テーブルはどんな言語でもクエリできるため、オプションは基本的に境界がない！以下のアイデアを考えてみよう：
- 以前のブログで紹介したように、ノートブック・コマンドの静的解析を行い、ハードコードされた秘密情報、クレデンシャルの漏えいなど、疑わしい行動や悪習を検出することができる。
- システム・テーブルのデータを人事システムのような追加データ・ソースと組み合わせることができます。例えば、休暇中やサバティカル（研究休暇）中、あるいは退社したとマークされているにもかかわらず予期せぬ行動が見られた場合に、自動的にフラグを立てることができます。
- システム・テーブルのデータをsystem.information_schemaのようなデータ・ソースと組み合わせることで、最も特権的なユーザに焦点を当てた監視を行うことができます。
- システム・テーブルのデータをジオロケーション・データセットと組み合わせることで、アクセス要件やデータ・レジデンシー要件に対するコンプライアンスを監視することができます。
geolocation_function_and_queries.sqlノートブックを見てください：
- 冗長な監査ログに対してLLMモデルを微調整し、組織のコーディング手法に合わせたコーディングアシスタントを提供することができる。
- システムテーブルとsystem.information_schemaのようなデータソースの組み合わせでLLMモデルを微調整し、データチームとビジネスユーザーの両方に自然言語でデータに関する質問への回答を提供することができる。
- 教師なし学習モデルをトレーニングして、異常なイベントを検出することができる。
さいごに
前回の監査ログについてのブログから1年、Databricks Lakehouse Platformも世界も大きく変わりました。当時は、必要なデータにアクセスするだけでも、実行可能なインサイトを生成する方法を考える前に、多くのステップが必要でした。今では、System Tablesのおかげで、必要なデータはすべてボタンをクリックするだけで入手できます。ゼロ・トラスト・アーキテクチャ（または、Never Trust, Always Verify）は、System Tablesによって実現できる多くのユースケースの1つに過ぎません。 AWS と Azureのドキュメントをチェック して、今すぐDatabricksアカウントでSystem Tablesを有効にしてください！
