翻訳：Junichi Maruyama. - Original Blog Link
データフォワード組織にとってレイクハウスがますますミッションクリティカルになるにつれて、予期せぬイベント、停止、セキュリティインシデントが新たな予期せぬ方法で業務を頓挫させるリスクも高まっています。Databricks はいくつかの重要な観測可能性機能を提供し、顧客がこの新しい脅威のセットを先取りし、かつてないほどレイクハウスを可視化できるように支援します。
セキュリティの観点から、組織が現代社会に適応する方法の 1 つは 、ゼロ トラスト アーキテクチャ (ZTA) モデルに従うことによって、「信頼せず、常に検証する」という原則に頼ることです。このブログでは、Databricks Lakehouse Platform上でZTAを始める方法を紹介し、一連のSQLクエリとアラートを自動生成するDatabricks Notebookを共有します。もしあなたが普段このようなことにTerraformを使っているのであれば、こちらのコードをご覧ください
システムテーブルは、Delta Lakeによってバックアップされ、Unity Catalogによって管理される一元化された運用データストアとして機能する。システムテーブルはあらゆる言語でクエリを実行できるため、BIからAI、さらにはジェネレーティブAIまで、さまざまなユースケースの基盤として使用することができます。システム・テーブルの上に実装される最も一般的なユースケースには、以下のようなものがあります：
様々なスキーマが利用可能ですが、このブログでは主にsystem.access.auditテーブル に焦点を当て、特にDatabricks上のゼロトラストアーキテクチャを補強するためにどのように使用できるかを説明します。
system.access.auditテーブルは、Databricks Lakehouse Platform上で発生した全てのマテリアルイベントを記録するシステムとして機能します。このテーブルを使用するユースケースには以下のようなものがあります：
従来、この種のログを分析するためには、クラウドストレージをセットアップし、クラウドプリンシパルとポリシーを設定し、ETLパイプラインを構築してスケジューリングし、データを処理して準備する必要があった。今回のSystem Tablesの発表では、オプトインするだけで、必要なデータがすべて自動的に利用できるようになる。何よりも、サポートされているすべてのクラウドでまったく同じように機能する。
ゼロ・トラスト・アーキテクチャー（ZTA）の重要なコンセプトには、以下のようなものがある：
このブログでは、主に「モニタリング」が重要であることに焦点を当てますが、Unity Catalogがどのようにデータ先進企業のZero Trustアーキテクチャの実装を支援するかについても、その幅広い機能セットで簡単に触れておきましょう：
効果的なモニタリングは、効果的なゼロ・トラスト・アーキテクチャの重要な基盤の1つである。効果的な監視を行うには、必要と思われるログを取得し、調査やインシデントが発生した場合にのみ照会すれば十分だと考える罠にはまりがちだ。しかし、"Never Trust, Always Verify"（信頼せず、常に検証する）の原 則に沿うためには、もっと積極的に行動する必要があります。ありがたいことに、Databricks SQLではsystem.access.auditテーブルに対するSQLクエリを簡単に書くことができます。
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のドキュメントをご覧ください。
これまで見てきた監視と検出のユースケースは比較的単純だが、システム・テーブルはどんな言語でもクエリできるため、オプションは基本的に境界がない！以下のアイデアを考えてみよう：
geolocation_function_and_queries.sqlノー トブックを見てください：
前回の監査ログについてのブログから1年、Databricks Lakehouse Platformも世界も大きく変わりました。当時は、必要なデータにアクセスするだけでも、実行可能なインサイトを生成する方法を考える前に、多くのステップが必要でした。今では、System Tablesのおかげで、必要なデータはすべてボタンをクリックするだけで入手できます。ゼロ・トラスト・アーキテクチャ（または、Never Trust, Always Verify）は、System Tablesによって実現できる多くのユースケースの1つに過ぎません。 AWS と Azureのドキュメントをチェックして、今すぐDatabricksアカウントでSystem Tablesを有効にしてください！
