セキュリティチームにとって気掛かりなイベントが発生したときに、必要な変更を行って対処してもらうためにイベントのコンテキストを開発チームに伝えるにはどうすればよいでしょうか？ミーティングや話し合いを重ねるのが一般的ですが、この方法では、セキュリティイベントの詳細が開発者に正確に伝わるまでに数日、時には数週間かかることもあります。厄介なのは、開発者は通常、セキュリティチームが使用するSplunkコア機能やSplunk CloudまたはSplunk Enterpriseのインデックスにアクセスできず、Splunk Observabilityを使用するのはメトリクス、トレース、ログを収集するときのみという場合もあることです。
こうしたSplunkイベントのコンテキストをSplunk Observabilityにイベントとして送信するプロセスを効率化するのがSplunk Observability Cloud Alert Action for Splunkです。
送信したSplunk Observabilityイベントは、開発者がよく使用するダッシュボードに表示され、Splunkで追跡中の関連するイベントや重要なイベントに関する情報が通知されます。この仕組みを実現するために必要な作業は、Splunk CloudまたはSplunk Enterpriseで、他のアラートと同じ方法でアラートアクションを設定し、Splunk Observabilityにコンテキストとして渡したいフィールドを選択して、ツール間でイベントコンテキストが送受信されるのを確認することだけです。
図1-1.Splunkで「Vulnerabilty_app」のコードスキャンを実行した結果を開発者に伝えるSplunk Observabilityイベントの例。この場合、脆弱性(CVE-2021-43138)を含むasyncパッケージがコードで使用されており、対処が必要です。
なぜイベントなのか？
イベントはSplunk製品のあらゆる場所で使われているからです。Splunkはイベントが大好きなのです！イベントなら最小限の負荷でコンテキストを渡すことができます。Splunk CloudやSplunk Enterpriseでは、基本構成要素としてログイベントが広く活用されています。
Splunk Observabilityでは、イベントがディテクターで使われるほか、時系列でない関連コンテキストをユーザーに伝える場合にも使用されます。イベントについては以前にこのブログですでにお話ししていますが、そのすばらしさをここで改めてご紹介します。イベントは、特定時点の出来事を理解するための入口となり、Observabilityダッシュボードとシームレスに連携して、重要な情報を届けてくれます(しかも無料で)。
SplunkインデックスからSplunk Observabilityにコンテキストを渡すことで解決できる問題の例をいくつか挙げましょう。
「社内リポジトリのコードの脆弱性スキャンを実行したら新しい脆弱性が見つかった。リポジトリの所有者である開発者に伝える必要がある」
「Splunkでファイアウォールの設定ミスが検出され、ネットワークのパフォーマンスが低下している。他のすべての監視ツールからユーザーに通知したい」
「Splunk ITSIで監視している基幹ビジネスプロセスで問題が起きている。この問題に関わっているソフトウェアの開発者にこの情報を伝える必要がある」
「サービスに必要なソフトウェアのデプロイ状況や気になるサービスの運用状況をObservabilityダッシュボードで確認したい。この状況はSplunkで監視されている。Observabilityに情報を取り込む方法はないだろうか？」
これらは考え得るユースケースのほんの一部にすぎません。現実には、Splunkで問題が検出され、Splunk Observabilityのユーザーに通知したくても、Splunkからの通知メールが無視されたり、チェックされないメールフォルダーに振り分けられたりすることがあります。情報をSplunk Observabilityに直接送れば、問題の発生日時が正しく記録され、開発者やSREが使用するツールで表示されて必ず目に留まります。
アラートアクションを必要とするのは誰か？
アラートアクションを使ってSplunk Enterprise/CloudとSplunk Observabilityを連携させる上で最も重要なのは、組織内の幅広いユースケースとチームがこの連携の恩恵を受ける点です。
- IT運用/サポートアナリスト：サポートアナリストは通常、全体像の把握に努めます。そのため、ITSIのグラステーブルや、Splunkで定義して高度にカスタマイズしたサービス集約表示を確認することが多いでしょう。Splunk Observabilityとの連携により、問題が起きたときに通知メールを送る代わりにアラートを送信して、開発者が使用しているツールで通知できます。
- ソフトウェア開発者/DevOps担当者/SRE：通常、この種のチームはSplunk Observabilityを使用しますが、Splunkや特定のSplunkインデックスにアクセスできないことがあります(SPLのことすら知らないかもしれません)。そのため、インデックスに含まれるイベントのコンテキストを知ることで大きなメリットを得られる可能性があります。Splunk Observabilityとの連携により、データがスムーズにSplunk Observabilityに渡され、コンテキストが提供されます。
- セキュリティチーム：セキュリティイベントや脆弱性のコンテキストをソフトウェアチーム、DevOpsチーム、SREチームに提供することは重要ですが、提供してもなかなか気づいてもらえないことがあります。このような情報をSplunk Observabilityに送れば、通知ができるだけでなく、報告や参照の履歴を簡単に記録できます。Splunk Observability Cloud Alert Action for Splunkで、脆弱性発見から通知までの面倒なやり取りを省略して、プロセスを自動化しましょう。
このように効率的な作業環境を整えて、全員を負担から解放できます。SplunkとSplunk Observabilityを連携させてコンテキストを渡せば、セキュリティチームからも、開発チームからも、サポートチームからも感謝されるはずです！
ぜひSplunk Observability Cloud Alert Action for Splunkをダウンロードしてご活用ください。
そしてObservabilityからSplunkへ
こうなると今度はSplunk ObservabilityからSplunkへもデータやコンテキストを送りたいと思うでしょう。「帰り」はやや面白味に欠けますがとても簡単です。
Splunk HEC (もちろんSSL有効化)を設定し、Splunk HECトークンを取得します。次に、 Splunk ObservabilityでWebhookインテグレーションを作成して送信先をHECの「collector/raw」エンドポイントに設定します。
AWS Lambdaを使って、ObservabilityアラートデータをSplunk ITSIに送信するプロセスをもっとカスタマイズしたい場合は、こちらのSplunk Lantern記事をご覧ください。
その後、ObservabilityのWebhookをディテクターに通知方法として追加します。これにより、アラートがSplunk EnterpriseまたはSplunk Cloudに送られるようになります。この方法は、SplunkやSplunk ITSIを「モニターのモニター」として使用している場合に便利です。
次のステップ
Splunkを使用していて、Splunk Observabilityをまだご利用でない場合は、無料トライアルに登録することで、ニアリアルタイムのソフトウェア監視を実際に体験していただけます。
Splunkをまだご利用でない場合は、Splunk CloudまたはSplunk Enterprise (オンプレミス)の無料トライアルをお試しください。
このブログ記事はSplunkのソリューションイノベーションエンジニアであるJeremy Hicksが執筆しました。ご協力いただいた以下の同僚に感謝申し上げます(敬称略)：Doug Erkkila、Joel Schoenberg、ソリューションイノベーションエンジニアリングチームのその他のメンバー
