SIEM on Amazon ES で生成されるインデックスに対して Index State Management を使ったライフサイクル設定をしてみた

SIEM on Amazon ES で溜まったインデックス、きちんとライフサイクル設定してますか
2021.03.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大前です。

SIEM on Amazon ES で ElasticSearch 上に生成されるインデックス対してライフサイクルの設定をする機会がありましたので、紹介します。

そもそも SIEM on Amazonn ES とは

AWS が OSS で公開している SIEM ソリューションです。このソリューションを利用することで、各種ログの可視化やセキュリティ分析を行う事が可能となります。

詳しくは、以下ブログを参照ください。

やりたい事

SIEM on Amazon ES を展開すると、各種ログが Amazon Elasticsearch Service(以下 Amazon ES)に保存されます。 大量のログファイルが取り込まれるので、Amazon ES 上のログデータに対してライフサイクルを設定することはほぼ必須になるかと思います。

Amazon ES では、UltraWarm を使用してストレージコストを抑える、Curator を使用してインデックスの管理を行うなど、いくつか選択肢が存在します。

今回は、Index State Management(以下 ISM)を使用して SIEM から取り込まれたログデータ(インデックス)に対してライフサイクルを設定してみたいと思います。

注意点として、ISM を利用するためには Elasticsearch 6.8 以降が必要です。SIEM on Amazon ES のソリューションを今からデプロイする方などは問題ないかと思いますが、参考までに。

やってみた

1. SIEM on Amazon ES のデプロイ

まずはじめに、SIEM on Amazon ES を AWS アカウントにデプロイします。 下記ブログの手順に従い、ソリューションを展開します。「CloudTrailのログを取り込む」についてはまだ実施しないでおきます。

2. インデックスのローテーション間隔を変更する

SIEM on Amazon ES のデプロイに成功したら、SIEM on Amazon ES にて生成される Amazon ES インデックスのローテーション間隔を変更します。

デフォルトでは月単位でインデックスが生成されますが(1インデックス/1ヶ月)、今回は 1日毎に異なるインデックスを生成する様に設定変更します。

Lambda コンソールを開き、aes-siem-es-loader という関数を開きます。

関数コード内から aws.ini というファイルを開きます。

85行目あたりに index_rotation = monthly という記述があるので、これを index_rotatino = daily に変更します。これでインデックスのローテーション間隔が変更されます。

今回はインデックスのローテーション間隔を変更するのみでしたが、SIEM on Amazon ES は他にも細かい設定が存在します。必要に応じて、色々触ってみてください。

ISM を設定する

続いて、ISM を使用してインデックスのライフサイクルを定義します。

SIEM on Amazon ES をデプロイした際の CloudFormation スタックの出力欄に Kibana のログイン URL、ID/Pass が記載されているので、これを用いてログインを行います。

ログイン後、「Management」→「Index Management」→「Index Policies」→「Create policy」から新規ポリシーの作成画面を開き、ポリシーID とポリシー定義を入力します。

今回は動作確認の為に 1日後にインデックスが削除されるポリシーを定義しました。実際に使用する際には、90日など適切な値を設定ください。

{
    "policy": {
        "description": "A policy to delete index by 1day.",
        "default_state": "hot",
        "states": [
            {
                "name": "hot",
                "actions": [],
                "transitions": [
                    {
                        "state_name": "delete",
                        "conditions": {
                            "min_index_age": "1d"
                        }
                    }
                ]
            },
            {
                "name": "delete",
                "actions": [
                    {
                        "delete": {}
                    }
                ],
                "transitions": []
            }
        ]
    }
}

また、ISM を使用するとインデックスに関する様々な制御を行う事ができますので、下記ドキュメント等を参照ください。

(2021/6/17追記) Index Template を設定する

手順がアップデートされたらしく、変更後の手順を追記しましたのでこちらを参照ください。

以前はインデックステンプレートなるものを作成し、上記にて作成したインデックスポリシーにアタッチする必要がありましたが、ism_template という項目が追加され、インデックスポリシー内で対象となるインデックスパターンを指定可能になっています。

AWS の公式ドキュメントにも記載が追加されています。こちら参照ください。

(旧) Index Template を設定する

2021/6/17追記 この手順は現在使用できません

上記にて作成したポリシーをインデックスにアタッチする事でポリシーの適用が可能ですが、インデックスは毎日新しく生成される為、Index Template を使用して自動でポリシーがアタッチされる様に設定します。

設定にあたっては、以下の AWS 公式 QA を参考にしました。


Index Template の作成は API から行う必要がある為、Kibana にログインした状態で「Management」→「Dev Tools」を開き、以下 API を叩きます。

  • _template/index_template_cloudtrail の {index_template_cloudtrail}
    • 作成する Index Template 名を指定します。
  • index_patterns
    • ここで指定したパターンに合致するインデックスに対して、Index Template が適用されます。今回は CloudTrail のログで検証をする予定なので、"log-aws-cloudtrail-*" としました。
    • 生成されるインデックス名は、インデックスのローテーション間隔を変更した際に開いた aws.ini に記載があります。
  • settings
    • この Index Template で何を行うか記載します。今回は policy_id で指定した ISM ポリシーが自動で適用される様な記述になっていますので、先ほど作成した ISM ポリシーID を記載します。
POST _template/index_template_cloudtrail
{
  "index_patterns": [
    "log-aws-cloudtrail-*"
  ],
  "settings": {
    "index": {
      "opendistro": {
        "index_state_management": {
          "policy_id": "delete_index_after1day"
        }
      }
    }
  }
}

ログを取り込んでみる

ここまで実施したら設定としては完了ですので、実際にログを取り込み、インデックスが日次で生成される事や、作成したポリシーがアタッチされることを確認したいと思います。

ログの取り込みについては、以下ブログに従い、CloudTrail ログを取り込む設定を行いました。

インデックスを確認

ログの取り込み後、少しして Kibana のインデックス一覧を確認すると log-aws-cloudtrail-2021-03-01 という名前でインデックスが作成されている事が確認できます。

また、Managed Indices 一覧では作成した delete_index_after1day がアタッチされている事が確認できます。

インデックス生成直後はしばらくステータスが Initialize でしたが、しばらく待つと問題なくポリシーがアタッチされている事も確認できました。問題なさそうです!

翌日

1日後(24時間後)にインデックスを確認したところ、ポリシーで定義した通りに delete の状態に遷移し、最終的にインデックスがなくなった事が確認できました。

おわりに

SIME on Amazon ES を使用した際に Amazon ES に蓄積されるインデックスに対して ISM を使用したライフサイクル設定をやってみました。

SIEM on Amazon ES を導入する際には必要となる設定になるかと思いますので、参考にしていただければ幸いです。


以上、AWS 事業本部の大前でした。

参考