トップ > SIEM on Amazon OpenSearch Service > 何ができるの？SIEM on Amazon OpenSearch Service【SIEM on AOSを1から学ぶ！第一弾】

何ができるの？SIEM on Amazon OpenSearch Service【SIEM on AOSを1から学ぶ！第一弾】

SIEM on Amazon OpenSearch Service 基礎から学ぶ Amazon OpenSearch 初心者向け
記事タイトルとURLをコピーする

「漠然とデータを採っているが活用できていない」「ログ分析の手間を減らしたい」…
このようなお困りごとを解決してくれるSIEM on AOSは何ができて、何が良いのか？図解してみました。

はじめに

こんにちは、最近図解が得意な気がしている垣見（かきみ）です。

SIEM on Amazon OpenSearch Service (SIEM on AOS)について検証して社内勉強会を開催したので、勉強会で使ったスライドをブログにしました。

このブログシリーズでは、「何も知らなくてもSIEM on AOSのデプロイ方法、使い方、強みがわかる」ようになることを目的としています。
第一弾となる今回は概要編ということで、「SIEM on AOSはどんな課題を解決し、何が良いのか」がわかるようになることがゴールです。

第二弾では「SIEM on Amazon OpenSearchのデプロイ方法とパラメータ」をお送りする予定です。
「とにかく色々触ってみた」という上級編の過去ブログもございますのでこちらも併せてご覧ください。 blog.serverworks.co.jp

シリーズ第二弾（SIEMデプロイ方法、CloudTrailとのレプリケーションでの連携）
シリーズ第三弾（できたリソースを全て確認してみる）
色々試してみた（過去ブログ、上級者向け）

SIEM on Amazon OpenSearchとは？

概要

「SIEM on Amazon OpenSearch Service」は、AWSが提供しているソリューションです。
「しーむ おん おーぷんさーち」と読みます。

こちらのgithub上に説明とソースコードが存在しており、CloudFormationをダウンロードするだけでデプロイが可能です。
https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README_ja.md
AWS公式のワークショップも存在し、分析体験用のデータももらえます。力が入ったソリューションだとわかります。ありがたいですね。

どんな人向け？

「漠然とデータを採っているが活用できていない」「ログ分析の手間を減らしたい」…
SIEM on Amazon OpenSearchは、このようなお困りごとを解決してくれます。

どういうもの？

結論として、SIEM on Amazon OpenSearchとは、「Amazon OpenSearch 上で行うSIEM」です。
…あまりにそのままですね。これだけだとよくわからないので一つずつ見ていきます。

SIEMとは

SIEM は Security Information and Event Management の略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューションです。
https://aws.amazon.com/jp/blogs/news/siem-on-amazon-elasticsearch-service/

ざっくりいうと「色々なデータを集めて一元的に管理・分析し、セキュリティ強化するシステム」とイメージしてください。
日本語直訳だと「セキュリティ情報とイベント管理」でそのまんまですね。

セキュリティに関するソリューションの一つで、製品面ではなく概念なので、例えばOpenSearchではなく「DatadogでSIEMを行う」のような言葉の使われ方もありえます。
色々なデータを集めて一元的に管理・分析をするという点が大事です。

OpenSearchとは

OpenSearch は、（中略）100% オープンソースの検索および分析スイートです。OpenSearch は、統合された視覚化ツールである OpenSearch ダッシュボードを使用して、大量のデータへの高速アクセスと応答を提供するための高度にスケーラブルなシステムを提供します。これにより、ユーザーはデータを簡単に探索できます。
https://aws.amazon.com/jp/what-is/opensearch/

OpenSearchは「ダッシュボードに可視化して検索・分析できるオープンソースのツール」です。

AWS マネージドサービスで、インフラストラクチャの管理、モニタリング、保守に悩まされたり、OpenSearch クラスターの運用に関する深い専門知識を構築することなく、OpenSearch クラスターを運用およびスケールすることができます。

AWSのサービスであるAmazon OpenSearch Serviceは、AWS上のOpenSearchと考えてください。
（参考：OpenSearchとは何ですか？）

SIEM on Amazon OpenSearchとは

ということで、SIEM on Amazon OpenSearchとは、「Amazon OpenSearch 上で行うSIEM」です。

より具体的にするとこんな感じになります。
異常をGuardDuty等で検知したら、セキュリティ担当はSIEMonAOSをチェックします。SIEM上ではCloudTrailやVPCフローログ、GuardDutyをはじめとするログを取得・一元的に視覚表示することができ、異常の原因を探って解決につなげることができます。

逆のパターンを考えてみましょう。

もしSIEMが無かったら、異常が起こっていたとしても大量のS3に保存されるデータを一つ一つ見に行かなければなりません。
（Athenaなどを使って検索することもできますが、複数サービスのログを確認できるようにするには手間がかかります。）

それを1つのブラウザから時系列に並べたり検索したりして見ることができるので、ただ漠然と採っているだけになりがちなデータをきちんと「活用」することができるのです。

ということで、「漠然とデータを採っているが活用できていない」「ログ分析の手間を減らしたい」のようなお困りごとを解決できるのです。

構成図

エンジニアならみんな気になる構成図。公式で出ている図はこんな感じです。
先ほどの図解を具体的に書いていますね。ログ集約用S3に色々なデータを集め、LambdaがAmazon OpenSearchにどんどん吸い上げてくれるという構成になっています。

AWS公式の図
geoIPについては後述

ただ、実際はもう少し多数のリソースが動いています。物足りなかったので、環境と公式の記載を見ながら頑張って書いてみました。達成感…。
これらリソースの一つ一つの説明はSIEMブログ第二弾以降でお話します。

垣見作構成図
S3のXXXにはアカウントIDが入ります

次の章では具体的な画面を説明します。

何ができるの？基本機能の紹介

実際のホーム画面で左ペインを出した状態です。

SIEMの核となる機能として、「OverView」の部分に3つの機能があります。

  • Discover：イベント一覧・検索
  • Visualize：図表の作成
  • Dashboards：Visualizeの一覧

また、＋αであるいくつかの機能の内、アラート機能も紹介します。

Discover：イベント一覧・検索

SIEM on AOSの中で最も重要なのがこちらの機能だと言っても過言ではないのではないでしょうか？
取り込んだログを表形式で一覧化してくれる機能です。1つ1つのイベントはこのように並んでいきます。 これが集まった画面が下図です。情報を展開して詳しいパラメータを確認することもできます。 また、左側のフィルター項目で一覧の見た目を変えることもできます。
例えば下の例では、最右列ではCloudTrailのイベントアクションで縦に整形し、一覧として確認できるようになっています。このイベントやIPアドレスの中からさらに一つのものだけ抜き出して（串刺しにして）確認することも可能です。
情報が得られやすい、お勧めのフィルター項目は写真左にあるこれら（@log_type, event.action, event.module, event.outcome, source.ip）です。検索条件は保存できるので、迷ったらとりあえず使ってみてください。

SIEMを使ったトラブルシューティングのユースケースはこんな感じです。

検索機能と串刺しによって、うまく原因の不正アクセスのログにたどり着くことができました。
このあたりを練習するには、公式のワークショップがかなりおすすめです。

Visualize：図表の作成

次に紹介するのはVisualize、これは「Discoverにあったデータを集計して図表にできるよ～」という機能です。
Excelのピボットテーブルやグラフ挿入をイメージしてもらえばスムーズです。操作感は似ていると思います。

また、基本的なVisualizeは初めから用意されているので、設定をしなくても済みます。
例えば、「ログイン失敗アクションの数や増加時期を確認したい」などのケースで役に立ちます。

テーブルへの出力はこんな感じです。基本的にずっとGUIで進みます。

Dashboards：Visualizeの一覧

Visualizeで作成した図を1つのダッシュボードにまとめて表示する機能です。複数のVisualizeをまとめて見れます。
例として、時系列/ある一定期間での異常を一覧で視覚的に探したり、評価したりしたい、などのケースが考えられます。
こちらも基本的なダッシュボードはあらかじめ用意されております。公式ページ冒頭で存在感を放っているのもこのDashboard機能です。

Visualizeができてさえいれば、ダッシュボードの整形は簡単です。

アラート機能

特定の条件でアラートを飛ばすこともできます。詳しくはOpenSearchのこちらをご確認ください。
CloudFormationデプロイ時にはAmazon SNSが作成されます。また、Chime, Slack, Custom webhook, Emailにもアラートを飛ばせます。（SIEM_Home画面のNotificationsから通知先設定です）

その他

機能はOpenSearchを踏襲しているため、OpenSearch公式側でわかりやすいデモがある項目も多いです。ただ、SIEM向けの確立した使い方はまだ見えてないので検証等が必要です。便利だよ～という情報がありましたら教えてください…！

何が良いの？

大きく3つのメリットがあります。

  1. トラブルシューティングをこれ1つで直感的にできる
  2. ログ集約のための導入が簡単
  3. 可視化が簡単

トラブルシューティングをこれ1つで直感的にできる

冒頭でも紹介しましたが、このサービスでは1つの画面で異なるサービスのログをまとめて確認可能だという部分が大きなポイントです。

特徴的なのはフィールド名の統一（正規化）が行われていることです。

例えば同じ「送信元アドレス」を表すフィールドは、本来VPC Flow Logsでは「srcaddr」、CloudTrailでは「sourceIPAddress」という用に分かれています。
これをSIEMでは「source.ip」に自動統一しているため、表の同じ列を見るだけでどこからの通信かを比べて見たり、あるIPアドレスの動きを串刺しして見たりすることができます。

また、クエリとGUI操作でのログのフィルタリングを行うこともできます。
フィルター基準はあらかじめ用意されているフィールド名から選ぶ形で、GUI形式で簡単にフィルタリング操作もできます。

クエリ例：eventName:ConsoleLogin and responseElements.ConsoleLogin:Failure
※詳しくはこちら（OpenSearch公式：Using Dashboards Query Language）

また、アラートでトラブルシューティングにあたっての「検知」「監視」をある程度自動化することもできます。

ログ集約のための導入が簡単

SIEM on AOS は CloudFormationで簡単にデプロイすることができます。
コンソールから、S3のURLを入力してパラメータをポチポチ設定するだけで基本の方はできてしまうのです。

私はTEAMという別のソリューションを触った際、「SIEMってすごく簡単だったんだ…！」と深く感動しました。後からわかる優しさです。（TEAMもかなり手順書が読みやすかったのでみんな違ってみんないいということですね）

一元化したいデータは集約用S3においてあげれば、lambdaで自動取り込みがされていきます。また、基本的な監視項目（Cloudtrail, VPCFloulogs, GuardDuty, …などAWSの主要データ）のための取り込み設定は最初から用意されています。

これが意味するところ、それは、CloudTrailなどの出力先をログ集約用S3に設定してあげるだけで、データ取り込みの設定までが終わってしまうということです。
なんて素晴らしいんでしょうか。

※対応しているログ（一部抜粋。一覧はこちら）（非対応の場合、設計を行う必要があります。）：

  • Amazon GuardDuty
  • AWS WAF
  • AWS CloudTrail
  • Amazon Route 53 Resolver
  • Elastic Load Balancing
  • Linux OS（/var/log/messages, /var/log/secure）
  • Windows Server（System event log, Security event log）

S3にはこのように、アカウント配下に各種サービスが分かれてたまる形になります

「もうすでにCloudTrail用のS3は設定しているんだが？」という方もご安心ください。S3のレプリケーション設定を利用すれば、今までのS3とログ集約用S3の共存も可能です。これまでのデータを移し替え、まとめてしまうこともできます。
このレプリケーションを使えば、マルチアカウント環境での集約も可能です。

レプリケーション

S3周りは公式のこの図がわかりやすいですね

可視化が簡単

取り込んだデータを図示・表化することも簡単です。
基本的なVisualizeセットは用意されており、Excelのグラフ作成のような操作感で可視化を行うことができます。

例えば、「ある一定時期にはどんなCloudTrailイベントが多かったか」を簡単にグラフにすることができます。

好きなVisualizeの図表をまとめた一覧として、「ダッシュボード」を作ることもできます。特定の情報に特化した画面を保存しておいて、すぐに見ることができます。

また、世界地図上のマッピングにより異常アクセスを視認可能です。
GeoMappingのLambdaが動き、IPだけではすぐに分からない場所の把握がスムーズにできます。お客様の「国内向けWebサービスに対する日本国外からの異常アクセス（DDoS攻撃など）を確認できるようにしたい」といった需要に答えてくれる部分です。

このように、どの国からのアクセスが多いかが視覚的にわかります

注意事項

料金と運用についてです。

料金

新規導入となると、気になってくるのが料金ですよね。
料金がかかるリソースは以下の通りです。

OpenSearchオンデマンド利用料＋EBSボリューム＋S3ログ＋Lambda＋各種セキュリティサービス 自体のコスト

ログ取得というサービスの性質上、ライフサイクルルールの設定やサービス使用規模感、どのログを連携するかの設定によりかなり金額が変わってきてしまうのは注意点です。

参考までに、最初の検証目的でのスモールスタートでの金額例を下に記載しました。

例

  • オンデマンド利用料
    • 例：t3.medium.search（デフォルト）で$0.112 /h

  • EBSボリューム利用料

    • 1 GB あたり USD 0.1464/月 (gp3)

  • t3.mediumインスタンス数1、EBSサイズ100GBを使用すると想定すると、

    • 0.112 * 730 h = $81.76
    • 0.1464 * 100 GB = $14.64
    • 合計 $96.4/月

検証用ではこのくらいです。※ただ、実際は大規模なログがどんどんたまっていくため、もっと高額なことが予想されます。
さすがに「すっごくお安い！」「無料！」とはいきませんが、同じSIEM系サービスの中ではかなり導入がしやすい価格帯ではあるようです。
OpenSearchにはReserved Instanceの適用もできるため、計画的に運用するならその分コストを下げることもできます。

また、注意点としてはS3ログとLambda実行処理で思わぬ料金が発生することがあります。
ログの量とログをS3からOpenSearchに流していくLambda（es-looader）は使い方に左右されるため、料金に関しては事前予測が困難で、運用しながら見ていくしかないです。

金額の増減には気を配る必要がありますが、それでもSIEM最初の一歩としてはおすすめです。

運用

次に、運用面です。

SIEMはとにかく検証導入が楽で、ログ連携も簡単なのですぐに使い始めることができるのが強みです。
ただ、本番運用するとなるとどうしても設計が発生してきます。

設計が必要な例は以下の通りです。

  • OpenSearchに関わる設計
    • インスタンスタイプ
    • ノード当たりのEBSストレージ
    • OpenSearchのインデックス（ログの蓄積単位。DBのレコードみたいなこと）の管理単位チューニング。小さめ推奨。（Ultrawarmストレージ）
    • シャードの配置（優先度低）
  • S3のライフサイクル
  • もしソリューション対象外のログを取りたい場合、そのための取得lambdaやアカウント分割の設計も必要になってきます

SIEM on Amazon OpenSearchで検索すると、実際に運用している方々の「事例」も出てきます。そういった生の声も参考にすると良いかもしれません。
料金・運用コストともかかわってくる部分で、どこまで設計するかの兼ね合いは難しい部分になってきます。

導入方法（初心者向けの例）

  1. まずはスモールスタートとして検証用を試してみてください！
    検証用環境でCloudTrail、GuardDuty、VPCフローログあたりを有効化し、ワークショップ等を見ながら使い方を色々触ってみると良いと思います。

  2. 「定期的に見る」と「何かあったら見る」を実施しましょう 導入だけでは誰も見ずに終わりになってしまいます。
    まずは担当者・チームを決め、「定期的にダッシュボードを見て問題が無いか確認する時間」を作ってみると良いでしょう。
    よく使うダッシュボード（好きな図表を一画面に配置したもの）は名前を付けて保存しておくと良いです。

「何かあったときにDiscover（一覧図）で確認・原因追及する」ができたらSIEMとして最高です。
「何かあったとき」には「GuardDutyアラート」「障害発生時」などが含まれます。緊急性がある場合、初めは後からでも構わないので、取り込んだSIEMを触る癖をつけるとよさそうです。

SIEM上でのカスタマイズアラートなど、機能を試してみるのも良いかと思います。

  1. 慣れてきたら規模を増やし、実践的な運用をしていく そのワークロードの特徴に合わせ、どのログを取得するか・などの規模を増やしていくと良いと思われます。

このあたりになると、追加の開発や設計見直しが必要になってくるかもしれません。
必要に応じてパートナーに相談するなどして対応してください。

まとめ

今回のゴール「SIEMはどんな課題を解決し、何が良いのか」について、いかがでしたでしょうか？
第二弾では「SIEM on Amazon OpenSearchのデプロイ方法とパラメータ」をお送りします。
このブログが皆様のお役に立てば幸いです。

垣見(かきみ)(執筆記事の一覧)

2023年新卒入社　エンタープライズクラウド部所属

図解するのが好き。「サバワク」のアイキャッチ作成も担当しています

【お知らせ】

【AWS re:Invent 2024 をエンジニアブログで振り返ろう】

2024年12月2日 - 12月6日 | ラスベガス（米国）
世界最大の AWS カンファレンス・AWS re:Invent 2024の感動をエンジニアブログで振り返りましょう！

AWS re:Invent 2024のブログ記事を読む