SIEMだけでは不十分：データベースにDAMが必要な理由

データベースセキュリティでは、長年にわたって同じ手法が使われてきました。最も重要なデータベースを10個か20個選び、ImpervaまたはGuardiumを導入する。そのために18か月を費やし、7桁の費用を負担するというものです。残りの数百個のデータベースでは、標準の監査機能を有効にしてログをSIEMに送信し、それを「監視」と呼んでいました。

そのプレイブックは、 データベースアクティビティ監視（DAM） が困難であり、保護の対象とされていたデータベースが規制当局の精査を受けるものだけで、そこにアクセスする最もリスクの高いユーザーが人間であった時代には理にかなっていました。

そうした前提は、もはやどれも通用しません。セキュリティ担当者は、GuardiumやImpervaの導入に伴う負担とコストに疲弊しています。この手法のうち、大半のデータベースで行っていた「Splunkへのログ送信」は、そもそもデータベースセキュリティと呼べるものではありませんでした。費用をかけて、コンプライアンスに対応している体裁を整えていたにすぎません。しかも今、データベースにアクセスするのは、少数の人間のユーザーではなく、数百、数千もの自律型エージェントです。SIEMにログを蓄積するだけでは、こうしたアクセスからデータベースを守れません。

Varonis Next-Gen DAMは、データベースの標準監査機能からデータを収集し、すべてのデータベースを当社の統合データセキュリティプラットフォームに取り込みます。必要なのは、データベースが生成したログの送信先をVaronisに指定することだけです。未加工のイベントがSIEMに積み上がるだけの状態から、実際の検出結果が得られるようになります。

「SIEMへのログ送信」で実際に得られるもの

現在、データベースとSIEMを運用しているどのチームに話を聞いても、状況は同じです。

• 莫大な費用がかかる：未加工の監査データは膨大な量に上り、SIEMへの取り込みにはギガバイト単位で料金がかかります。どのSIEMを使っていても、気づけば組織のデータベース監視インフラの中で最も費用がかかるものになっています。それだけの費用をかけても、セキュリティの確保にはまったくつながっていません。

• アラートが意味をなさない：SIEMは、どのテーブルに規制対象のデータが含まれているかも、SQLのSelectとShowの違いも認識していません。どのイベントも同じに見えてしまいます。重要なアクティビティを見つけるためのルールを作成するには、データベースに関する深い知識が必要ですが、SOCにはその知識がありません。ほとんどのチームは諦め、ルールをまったく作成しないままです。

• 監査レポートの作成は、いまだに手作業：四半期ごとに、誰かがログストアに対してカスタムクエリを実行し、出力結果の書式を手作業で整えます。あとは、監査人が受け入れてくれることを祈るだけです。これでは、リスクの軽減にもデータの保護にもまったく役立ちません。

一方、エージェントベースのDAMツールで管理されているデータベースも、別の問題から抜け出せずにいます。エージェントの導入には何年もかかるうえ、環境全体の一部しかカバーできず、チームは区別のつかない大量のアラートへの対応に追われています。このカテゴリーを築いた当事者たちも、そのことを認めています。

Varonisの戦略担当バイスプレジデントであるRon Bennatanは、次のように説明しています。「私たちがエージェントベースのDAMを構築した当時は、ハードウェアに制約があり、ブロック、動的マスキング、接続のスロットリングといったインライン制御が実際に必要でした。しかし、こうしたハードウェアの制約は、クラウドと最新のストレージによって何年も前に解消されています。そして、インライン制御は現在、主にAIエージェントに対して必要とされています。今のデータベースに必要なのは、高精度の検出と、AIエージェントが意図しない結果を引き起こすことを確実に防ぐ仕組みです。興味深い課題は、数百万件のアクティビティ記録から、本当に意味のある少数の検出結果をどう導き出すか、そしてエージェントの意図をどう理解するかということです。」

RonはVaronisに入社する前、Guardium（IBMが買収）とjSonar（Impervaが買収）の共同創業者として、25年にわたりエージェントベースのDAMの構築に携わってきました。現在、最新のデータベースでは、標準監査機能のオーバーヘッドは実測で5％を大きく下回り、エージェントベースの収集と同程度になっています。

結局、業界では、問題を抱えた2つの方式が並行して使われることになりました。（1）従来型のDAMで莫大な費用をかけてデータベースのごく一部を監視し、（2）残りはSIEMでカバーするものの、セキュリティはまったく確保できていないのです。

従来型DAMとSIEMの組み合わせが機能しなくなった理由

従来型DAMとSIEMを組み合わせる折衷策は、DAMでカバーしていないデータベースには、労力をかけて保護するほどの価値はないという前提に立っていました。しかし、AIエージェントがそれらのデータベースにクエリを実行し始めた瞬間、その前提は崩れます。

社内LLMを基盤に構築されたカスタマーサポートエージェントを考えてみましょう：

• ユーザーがそれに質問します

• モデルは、顧客データベースから3行のデータが必要だと判断します

• MCPサーバーは、共有サービスアカウントでクエリを実行します

• 標準のログには、「svc_ai_supportが14:02にcustomers.payment_methodsから3行を読み取った」と記録されます

こうしたクエリが1日に1万件、12のAIワークフローにわたって実行されると、膨大なデータが流れ込んできますが、役には立ちません。リクエストのきっかけとなった操作を誰が行ったのかは見えません。サービスアカウントは、6か月前なら行わなかったような処理を行っています。

SIEMは、アクセス対象のデータがどの程度機密性の高いものなのかを把握していません。その情報がなければ、こうしたアクティビティが正常かどうかを判断することもできません。こうしたエージェントが100体、1,000体に増えたらどうでしょうか。それぞれが自律的に行動し、意図しない動作を起こしやすく、完全に「暴走」することさえあります。今や、従来型DAMでカバーする予定の10個にとどまらず、すべてのデータベースがリスクにさらされているのです。

Varonis Next-Gen DAMですべてのデータベースを保護

セキュリティチームが長年、すべてのデータベースを監視してこなかったのは、全体を監視することが難しく、大きな負荷もかかるためでした。Varonis Next-Gen DAMは、1つのSaaSプラットフォーム上で2つの収集方法を提供し、この状況を変えます。

ネイティブ監査データ収集は、大半のデータベースをカバーします。SQL Server、Oracle、PostgreSQL、MySQL、Snowflake、Databricks、Amazon RDSをはじめとするすべての主要なエンジンに標準搭載された監査ストリームを、Varonisコレクターに送信するよう設定するだけです。データベースホストへのインストールは不要です。エージェントやインライン機器の導入も、DBAへの対応依頼も必要ありません。

Varonis Gatekeeperは、特に重要な少数のデータベースをカバーします。ブロックや動的マスキングなどのインライン制御、旧バージョンのデータベースへの対応が必要な場合に適しています。そもそも、エージェントの導入が必要とされていたのは、こうしたワークロードでした。

どちらの方法で収集したデータも、同じSaaSプラットフォームに送信されます。つまり、重要な10個のデータベースにも、これまでSplunkにログを送るだけで宙に浮いていた数百個のデータベースにも、同じセキュリティ対策が適用されます。

Varonis Next-Gen DAMがもたらすもの

ログエントリを検出結果に変えるには、処理するプラットフォームが3つのことを把握している必要があります。アクセス対象が機密データか、そのユーザーにアクセスを認めるべきか、そして、その行動がそのユーザーにとって通常のものかということです。

午前2時に顧客テーブルに対して実行されたSELECTを例に考えてみましょう。未加工の監査データを取り込むSIEMにとって、これは数百万件あるイベントの1件にすぎません。Varonisでは、3つの処理が並行して行われます。

• 分類エンジンは、宛先テーブルがカラムレベルに至るまでPIIを保持していることをすでに把握しています。

• IDグラフがActive DirectoryまたはEntraを通じて、データベースアカウントに対応する実際の企業内IDを特定します。

• そして、ユーザーエンティティ行動分析（UEBA）を活用することで、Varonisはこのユーザーがこのテーブルや列に一度もアクセスしたことがなく、業務時間外に作業することも滅多にないことを示します。

その結果、何が異常なのかが明確なアラートが生成されます。「このアカウントが、これまでアクセスしたことのない規制対象データを、業務時間外に、新たなエンドポイントから読み取りました」というものです。

上記のAIエージェントの例でも、同じように3つの情報を照合してみましょう。データ分類によって、customers.payment_methodsがPCIの適用範囲に含まれることが分かります。IDレイヤーは、svc_ai_supportによる処理の起点となったワークフローをたどり、最終的にはユーザーのプロンプトまでさかのぼります。行動モデリングによって、このエージェントがこれほどの量のアクセスをこのテーブルに行う正当な理由があるかどうかを判断します。人間のユーザーの場合と同じように、ログが検出結果へと変わるのです。

これが、レポート作成のためにログをどこかへ送ることと、データベースを保護することの違いです。

DAMが想像以上に簡単な理由

今では、環境内のすべてのデータベースに、DAMの対象を容易に広げられます。何年もSplunkに送信してきたデータベースログは、そのまま送信先をVaronisに切り替えられます。データストリームも手間も変わりません。しかし今度は、誰も読まないイベントにギガバイト単位の料金を払うのではなく、データ分類とIDの特定を完全に行ったうえで、具体的な検出結果を得られます。

まずは無料のVaronisデータリスク評価をご利用ください。SQL Server、Oracle、PostgreSQL、MySQL、RDS、Snowflake、Databricksなどのデータベースを自由に組み合わせ、OneDrive、SharePoint、Google Workspace、Box、Salesforce、NASなどの非構造化データとともに取り込めます。データ分類モデルもIDグラフも1つに統一され、検出結果も1つにまとまります。

評価で得られるもの：

• すべてのデータベースとファイルストアにある機密データの所在を網羅し、データの露出やアクセスに伴うリスクを数値で示すマップ

• Active DirectoryとEntraを通じて、データベースアカウントを実際の企業内IDにひも付けるIDマッピング

• Varonis UEBAが検出するリアルタイムのアクティビティアラート。評価期間中はMDDRアナリストが24時間・週7日・年365日の体制で監視します

• 優先順位を付けた是正手順をまとめた、経営層への報告にそのまま使えるレポート。ご契約に至らなかった場合も、お手元に残せます

設定は1時間未満で完了し、24時間以内に検出結果を確認できます。

 注：このブログはAI翻訳され、当社日本チームによってレビューされました