Splunkダッシュボード作成の基礎！〜ログイン状況を可視化してみよう〜

Tips & Tricks November 06, 2024 倉浪晃一(Kuranami Koichi)

Splunkには、単一値表示や折れ線グラフの他、地理情報へのマッピングなど、様々な視覚化機能があります。

これら視覚化機能について理解を深めるためには、実際にパネルやダッシュボードを作成してみるのが近道です。しかし、どのような可視化を行えばいいのか、何のダッシュボードを作成すればよいか、など悩んでしまう方も多いのではないでしょうか？

今回は、Splunkの内部ログをソースとして、Splunkのログイン情報を可視化するためのダッシュボード作成の例と手順をご紹介します。

ちなみに、Splunkのセキュリティ全般を向上させるための考え方のポイントは、Splunk Docにまとまっております。こちらもぜひ一度、ご参照ください。

Splunkの内部ログについて

Splunkでは、ログインに関する情報を内部ログとして保管しています。これらログを活用し、ログイン情報について集計とレポーティングを行うことができます。

具体的には、監査ログである「_audit」インデックスにログイン/ログアウトに関するログが保管されています。Actionフィールドが”login attempt”であるログがログイン試行ログですので、まず以下のサーチを実行してみます。

index="_audit" action="login attempt*"

サーチ

ログイン試行に関するログが表示されました。ちなみに、上記のサーチでlogin attemptの後に*が使用されている理由は、login attempt以外にlogin attempt locked out userなどの複数のactionが存在しており、このログも対象に含めるためです。

Splunkの監査ログについては、こちらのドキュメントも参考にしてください。

ダッシュボードデザインの考え方の一例

次に、ダッシュボードデザインの考え方の一例をご紹介します。

ダッシュボードをデザインする際は、実際の運用業務を想定し、どのような状態であることを確認したいのか、または逆にどのような兆候を発見したいのか、などを踏まえて必要な情報やパネルの種類を決定する必要があります。

ダッシュボードデザインの考え方の一例としては、まず目的を定め、その目的に沿って3つの階層を意識した画面設計にするというものがあります。以下のように階層を分けてそれぞれのパネルを配置するという考え方です。

1階層：最初に見る階層。目的に対する、最も重要なメトリックスやKPIを決定して表示する。このメトリックスやKPIが異常な値を示していた場合、すぐに調査が必要だと判断できるものを表示する。単一数値であると分かりやすい。
2階層：メトリックスやKPIに関するインサイトや詳細情報を表示する。メトリックスや関連する値を時系列表示、グループ化、リストすることで、単一数値だけでは判断しづらい情報を表示する。
3階層：問題があると判断した場合、更なる調査や分析を行うために必要な情報やサーチを行うためのパネルを表示させる。

参考記事「ダッシュボード設計：ベストプラクティスをもとに作成を始める(パート1)」

今回は、Splunkログイン情報を可視化するためのダッシュボードを作成します。上記のダッシュボードデザインの考え方に沿って、例えば以下のようにダッシュボードをデザインすることを考えました。

目的：Splunkに対して不正なログインが試行されていないかを調べたい。また不審なログインがあった場合、すぐにそれに気づいて調査を行いたい。

1階層：最も重要なメトリックスとして、(a)ログイン試行回数および(b)ログイン成功率をパネルで表示する。これら指標が急変した場合、理由を調査するべきと考えられる。
2階層：最も重要なメトリックスに対する詳細情報として、(c)ログイン試行回数およびそれら成否の割合の時系列表示、(d)ログイン失敗率の高いユーザーのリスト、(e)最近ユーザーがロックアウトされたイベントのリスト、(f)滅多にログインしないユーザーがログインに成功したイベントのリスト、(g)ログインを試行したユーザーの物理的アクセス元、を表示する。これらによって、追加のインサイトを得ることができ、場合によっては追加の調査や分析を行う。
3階層：調査や分析のため、(h)特定のユーザーを指定して、関連するイベントをサーチして表示するパネルを用意する。このパネルによって、更に詳細な調査を行うべきかどうかを判断する。

企業によっては、守らなければならないセキュリティポリシーがあらかじめ定められている場合もあると思います。その場合、それらポリシーを出発点としてダッシュボードをデザインすることになるでしょう。

また、よく私自身がダッシュボードデザイン時に経験することとして、デザインの細部にこだわりすぎて実際に使い始めるまでに時間がかかってしまうという問題が発生することがあります。これは、日本の文化や気質によるところもあり良し悪しでもあると考えているのですが、可能であれば、早い段階で実業務にダッシュボードを利用してみて、業務を行いながらダッシュボードを修正していくという流れで進めていったほうが、精神的に疲弊などせず、素早く効率的に役に立つダッシュボードが作成できると個人的には考えています。

(ただし、大規模なプロジェクトなどで、ダッシュボード開発と実運用業務を担当する部署や人が明確に分けられている場合もあると思います。その場合は画面レビューなど、十分な部署間のコミュニケーションを行いながらデザインを行う必要があると思っています)

ログイン状況を可視化するためのパネル/サーチの実装

最後に、Splunkログイン情報を可視化するためのパネル/サーチを実装します。

(a)ログイン試行回数
(b)ログイン成功率
(c)ログイン試行回数およびそれら成否の割合の時系列表示
(d)ログイン失敗率の高いユーザーのリスト
(e)最近ユーザーがロックアウトされたイベントのリスト
(f)滅多にログインしないユーザーがログインに成功したイベントのリスト
(g)ログインを試行したユーザーの物理的アクセス元
(h)ユーザーやIPアドレスを指定して、関連するイベントをサーチして表示するパネル

それぞれのSPL、サーチの時間範囲の指定、可視化の種類は以下の通り実装しました。

パネル名

SPL

時間範囲

可視化の種類

(a)ログイン試行回数

index="_audit" action="login attempt*" NOT user=internal*
| stats count

ダッシュボード中で指定する時間範囲1にて指定(デフォルト24時間)

単一値

(b)ログイン成功率

index="_audit" action="login attempt*" NOT user=internal*
| eval result=if(info="succeeded", "succeeded", "failed")
| stats count(eval(result="failed")) as failures, count(eval(result="succeeded")) as successes
| eval login_success_rate = round((successes / (successes + failures)) * 100, 2)
| table login_success_rate

ダッシュボード中で指定する時間範囲1にて指定(デフォルト24時間)

単一値

(c)ログイン試行イベントの時系列表示

index="_audit" action="login attempt*" NOT user=internal*
| eval date=strftime(_time, "%Y-%m-%d")
| eval result=if(info="succeeded", "succeeded", "failed")
| timechart count by result