0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Databricksクラスターにおける不審なアクティビティを検知、アラートするための強化セキュリティモニタリングの活用

Posted at

Using Enhanced Security Monitoring to Detect & Alert for Suspicious Activity on Your Databricks Clusters - The Databricks Blogの翻訳です。

本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

Databricks on AWSはお客様のアカウント内のEC2インスタンスとしてデプロイされるカスタムマシンイメージであるAMIに依存しています。これらのEC2インスタンスはDatabricksクラスターに弾力性のある計算資源を提供します。Databricksのアーキテクチャにおいては、お客様のコードはホスト自身ではなく、低い権限を持つコンテナで実行されます。このモデルは、複数のユーザーが計算資源を共有するユーザーアイソレーションクラスターにおいては特に重要なセキュリティモデルとなります。我々は、強化セキュリティモニタリング機能の一部として、お客様が不審なアクティビティを検知・アラートするために活用できるプリインストールされたセキュリティエージェントと高度な強化がされたAMIを提供します。この記事では、Capsule8に含まれるアラートに基づいて、悪意の可能性のあるアクティビティを検知するための有用なクエリーのいくつかをカバーします。

Databricksワークスペースの監査ログの活用

まず最初に、お客様はEnhanced Security Monitoring (ESM)機能を有効化する必要があります。これはDatabricks担当者にコンタクトすることで行うことができます。また、我々のHIPAA、PCI-DSS、FedRAMP向けコンプライアンスセキュリティプロファイルの一部となっています。ESMが有効になったら、監査ログのデリバリーを有効化し、Databricksからクエリーするログをロードする様にしてください。これを非常にシンプルなものにするサンプルDelta Live Tablesパイプラインを提供しています。ログがDeltaテーブルに取り込まれると、DBSQLあるいはノートブック経由で効率的にクエリーすることができます。

Capsule8アラートの理解

サイトのドキュメントで説明している様に、DatabricksではESMのAMIで特定のCapsule8検知を有効化しています。この例では、アラート全体のサブセットにフォーカスしますが、お客様は自分たちの環境において何を検知することが最も重要なのかに関して優先度をつけるためにセキュリティチームと作業する必要があります。Databricksクラスターの性質上、ユーザーコードはホストOSやベースAMIにアクセスすることはできませんので、これらのようなアラートは、ホストにおける不審なアクティビティやプラットフォームで悪意を持つユーザーを示す良いインジケータとなり得ます。

ここでフォーカスするイベントの4つの主要なカテゴリーは以下の通りとなります。

  • Container Escape

    権限の低いコンテナでユーザーコードが実行されている場合、コンテナ回避は、クラスターのセキュリティを侵害しうる重要なイベントとなることがあります。特に、ユーザーアイソレーションやテーブルACLクラスターにおいて、コンテナ回避はデータ漏洩や他のリスクにつながることがあります。

  • Kernel Related Events

    繰り返しになりますが、ユーザーコードはホストOSの権限を持たず、間違いなくカーネルモジュールをロードする権限を持つことはありません。これらのタイプのカーネル関連のイベントは、ホストに対する悪意のある行動、あるいはコンテナ回避の次のアクションの可能性があります。

  • Host Security Changes

    AppArmor、boot files、認証ストアのようなホストのセキュリティ設定への変更は不自然であり、調査するべきです。

  • Other Suspicious Activity

    インスタンスがアクティブになりクラスターに割り当てられたら、ホストにおける新たなインタラクティブシェルやコンテナで新規ファイルの実行、権限を持つコンテナの起動は行われるべきでありません。

Capsule8アラートのモニタリング

ここでは、Delta Live Tablesを用いてCapsule8のアラートをどの様に関しするのかを説明しますが、ワークスペースの監査ログは標準的なJSONファイルとしてデリバリーされるので、もちろんお客さまにおいてはこれを行うために任意のモニタリングツールを活用することができます。このケースでは、Delta Live Tablesパイプライン経由でワークスペース監査ログが取り込まれる際に検知を行います。シンプルなSQLフィルター表現を用いて、上述の検知のためのフィルターに基づいてアラートテーブルを更新します。

Python
detections = {
    "container-escape": "actionName in ('Container Escape via Kernel Exploitation', 'Userland Container Escape', 'New File Executed in Container', 'Privileged Container Launched')",
    "host-security": "actionName in ('Processor-Level Protections Disabled', 'AppArmor Disabled In Kernel', 'AppArmor Profile Modified', 'Boot Files Modified', 'Root Certificate Store Modified')",
    "kernel-exploit": "actionName in ('BPF Program Executed', 'Kernel Module Loaded', 'Kernel Exploit')",
    "suspicious-activity": "actionName in ('New File Executed in Container', 'Suspicious Interactive Shell', 'User Command Logging Evasion', 'Privileged Container Launched')"
}

# we inverse the detection logic for DLT expectations
detection_expectations = dict([(key, f"not({value})") for (key,value) in detections.items()])

@dlt.table(
  name="workspace_audit_logs",
  partition_cols=["date", "workspaceId", "serviceName"],
  table_properties={
    "pipelines.autoOptimize.managed": "true",
    "delta.autoOptimize.optimizeWrite": "true",
    "delta.autoOptimize.autoCompact": "true"
  }
)
@dlt.expect("clean_schema", "_rescued_data is null")
@dlt.expect_all(detection_expectations)
def workspace_audit_logs_ingest():
  return (spark.readStream
          .format("cloudFiles")
          .option("cloudFiles.format", "json")
          .option("cloudFiles.inferColumnTypes", "true")
          .option("cloudFiles.schemaEvolutionMode", "addNewColumns")
          .load(workspace_logs_ingest_path)
          .withColumn("filename", input_file_name()))

@dlt.table(
    name="alerts",
    table_properties={
        "pipelines.autoOptimize.managed": "true",
        "delta.autoOptimize.optimizeWrite": "true",
        "delta.autoOptimize.autoCompact": "true"
      }
)
def alerts():
    logs = dlt.read_stream("workspace_audit_logs")
    alerts = compute_alerts(logs, detections)
    
    return alerts.filter("size(alerts) > 0") # only return records with alerts

また、検知はDelta Live Tableのエクスペクテーションとしても適用されます。これによって、我々の検知条件にレコードがマッチしたのかどうかに関して、クイックにパイプラインUIで確認することができます。プロアクティブなアラートのために、新規に検知した際にメール、Slackメッセージ、さらには任意のwebhookを送信できる様にDBSQLのアラートを活用することができます。

監査ログの取り込みとCupsule8イベントのアラートのためのDLTパイプライン

Capsule8のイベントには、アラートを引き起こしたホストに対応するAWSインスタンスIDが含まれます。このインスタンスIDとCloudTrailやVPCフローログの様な他のログと関連づけることができます。AWSのログに加えて、アナリストは我々の新たなverbose audit logsを用いることで、Cupsule8のアラートやその他のインシデントに対する調査の一部として、ワークスペースで実行されたノートブックコマンドをレビューすることができます。

まとめ

強化セキュリティモニタリングを用いることで、Databricksの利用者は自身のデプロイメントをサポートしているインフラストラクチャのセキュリティに対して更なる可視性を得ることができます。Delta Live Tablesを用いることで、サイバーレイクハウスにセキュリティログを取り込み処理するための高信頼かつスケーラブルな方法を取ることができます。わずかなシンプルなクエリーによって、容易にアラートを発呼し、いかなる不審なアクティビティを調査することができます。

強化セキュリティモニタリングを有効化する場合には、Databricks担当にコンタクトしてください。

Databricks 無料トライアル

Databricks 無料トライアル

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?