AWS Config / CloudTrail ログをSplunkに取り込んでみた (SQS base S3方式)
はじめに
前回の記事ではSQSベースでS3上の一般的なデータをSplunkに取り込んだのですが、今回はAWSログである AWS Configと CloudTrail ログを取得してみたいと思います。
この2つのログは、ガバナンスを効かせる上で重要になるログで、誰がいつどのような操作をしたのか。リソースに対してどのような設定がされており、どのような変更が加えられたのか。などを記録しておくことで、問題が発生した際の追跡が可能となったり、日頃から問題のある行動や設定をチェックしたりすることができます。
ちなみに、こちらの設定はSplunkが推奨している SNSを使った方法ではなく、S3からイベント通知をあげて取り込む方法で試しております。通知する主体が各サービスなのか、S3なのかの違いになりますが、取り込むデータは同じです。
あとAWS側の設定に関しては、もっといい方法やそもそも間違っている可能性もありますので、ゆるーく見て頂けるとうれしいです。
AWS Config / CloudTrail とは
設定に入るまえに、AWS Configと CloudTrailについて理解しておきたいと思います。
ちなみに今回はこちらの資料を参考にさせていただきました。
https://d1.awsstatic.com/events/jp/2017/summit/slide/D4T3-6.pdf
AWS Configログとは?
特定のAWSリソースの設定情報や変更履歴をロギングしたものです。設定情報については定期的にスナップショットとしてS3に保存することができます。対応しているAWSリソースはこちらです。またConfig Ruleのサービスを利用すると設定ルールが守られているかをチェックすることができます。
設定はリージョン毎に行う必要があります。
AWS Configは記録される設定項目につき 0.003 USDかかります
AWS CloudTrailとは?
Configがリソースに対してのログに対して、CloudTrailはユーザーに対しての操作(API)ログになります。誰が、いつ・何に対して・何をしたのか。を確認することができます。
設定は一括に全リージョンを対象に行うことができます。
CloudTrailは無料で利用可能です。
取り込み方法
AWSログ別Splunkの推奨取得方法について (Best Practice Input Type参照)
https://docs.splunk.com/Documentation/AddOns/released/AWS/ConfigureInputs
Config と CloudTrailともに SQS Based S3からの取得が推奨されております。
なので前回の取り込み方法で基本的にはいけるかと思います。
AWS Configの設定
設定はリージョン毎に行う必要があります
[Config] - [設定] - [編集]
今回は全てのリソースを対象にして、保持期間はSplunkに取り込むため最短の30日とします。ロールはデフォルトのものを利用します。
保存先にS3 Bucketを新規作成します。フォルダー名をeu-west-2とします。SNSトピックなどは設定しません。
設定は以上です。監視対象のリージョンで同じように設定してください。ただし同一のS3 Bucketに保存する際はS3へのアクセス許可を変更する必要があります。
AWS Config Ruleの設定
こちらはオプションですが、 Config Ruleを設定すると、コンプライアンスに準拠しているかチェックすることができます。AWS側で100個以上のルールが用意されているので、そちらを簡単に有効化できます。Compliance状況についてはSplunk側でも確認できます。
[Config] - [ルール] - [ルールの追加]
適当にルールを追加しました。こちらのデータはS3に保管される訳ではなく、直接Splunkとやりとりします。
CloudTrailの設定
[CloudTrail] - [認証情報] - [認証情報の作成]
とりあえず、全てのリージョンを対象にして、読み書き両方のログを設定します。(ログ量が増えるため運用時には要検討).その他の設定はデフォルトのまま。データイベントは記録しません。
CloudTrailの保存用に S3 Bucketを作成します。(既存のS3上でも構いません)
SQSを利用したSplunkへの取り込み
それではログがS3上に保存されているのを確認後、SQSを使ってSplunkに取り込みたいと思います。設定方法に関しては、以前の記事と重複するので割愛します。
こちらの記事をご覧ください。
https://qiita.com/maroon/items/76bc6cae205335924f1a
注意点としては
SQS をConfig用とCloudTrail用の2つずつ作成する必要があります(実際は Dead letter queueもあるので、2x2必要ですが)。理由としてはSplunk側で取り込む際にソースタイプが異なるためInputも分ける必要があるからです。そうしないと同一のソースタイプが割り当てられてしまいます。取り込んだ後に苦労します。
Splunk側のInput作成では、[Add-On for AWS]Appを開いて Input画面に移動します。
[Create New Input]-[Cloudtrail]-[SQS-Based S3] を選択します。
インデックスはどこでも大丈夫です。(今回はdefault (main)にしました)
続いてconfig についても作成します。
[Create New Input]-[Config]-[SQS-Based S3]
(*)インデックスを default以外にした場合でも、App for AWSを利用できます。(後ほどのSaved searchを実行すると base search macro の indexに追加してくれます)
Add-on for AWSのサーチ画面で確認すると、データが早速取り込まれているのがわかります。
また、Add-On for AWS の「健全性チェック」では、SQSベースの取り込みエラーを確認できます。
少しハマった所としては、同じ環境に Splunk App for Infrastructure (SAI)がインストールされていると、aws:cloudtrail のパースが、他のAppからうまく行きませんでした。これはSAIの中にも aws:cloudtrail のソースタイプがあり、これが KV_MODE=none となっていたため、そちらが優先されてしまいました。修正方法としては SAIのprops.conf に KV_MODE=json と追記して Splunkを再起動してください。
/opt/splunk/etc/apps/splunk_app_infrastructure/local/props.conf
[aws:cloudtrail]
KV_MODE = json
あと、Config Ruleを設定した場合、追加のInput設定が必要です。
[Create New Input] - [Config Rule] をクリックして、必要項目を入力します。(リージョン毎必要)
App for AWS のインストール&確認
AWSログを取り込んだら、App for AWSをインストールして、用意されているダッシュボードを使って中身を確認してみましょう。
App for AWSはこちらから利用できます。あらかじめインストールしておいてください。
https://splunkbase.splunk.com/app/1274/
またセットアップについては以下のドキュメントに従って実施します。
https://docs.splunk.com/Documentation/AWS/6.0.1/Installation/CreateIndexesRunSavedSearches
App用Index作成
最初にAppが利用するIndexを作成します。ドキュメントによると以下のIndexがSummary Index用に必要なようです。「設定」ー「インデックス」ー「新規インデックス」で作成
aws_topology_history
aws_topology_daily_snapshot
aws_topology_monthly_snapshot
aws_topology_playback
aws_vpc_flow_logs
aws_anomaly_detection
保存済みサーチ (saved search) のスケジュール実行設定
Indexを作成後、保存済みサーチを実行します。保存済みサーチの中身の解説についてはこちら
https://docs.splunk.com/Documentation/AWS/6.0.1/Installation/Savedsearches
「設定」ー「サーチ、レポート、アラート」にて、以下の2つのサーチを実行
・ Addon Synchronization
・ App Upgrader
(*)マニュアルにはないのですが、レポートにて「Addon Metadata - Summarize AWS Inputs」も実行するように画面にメッセージが出ていたので、実行した上で上記の設定を行いました。
Addon Synchronization の例 - 実行をクリック
このサーチ実行で、ベースサーチのマクロに AddOn for AWSで保存したAWS logのIndexをマクロに追加されます。これによって main以外に保存されたIndexに対しても Appで確認することができます。
次に「編集」ー「スケジュール設定」ー「スケジュールを有効」 ーそのまま保存(設定値はそのまま)
App を確認してみよう
ほんの一部ですが、App for AWS に含まれているダッシュボードをご紹介します。
(注意)今回 config / cloudtrail 以外に descriptionログも入っておりますので、キャプチャした画面はみなさんのと少し異なるかもしれません。 descriptionは SQSなどの設定も不要なので試してみてください。
概要画面
まだ、CloudWatch などの主要なログが入っていないため一部はまだ表示されてませんが、ほとんどの箇所がうまりました。
「トポロジー」
config ログが入ったため、このようなトポロジーも確認できます。視覚的に各オブジェクトの関係性がわかります。
「Security Group」
セキュリティグループの設定一覧等も可能です。
「IAM Activity」
ユーザーの活動状況なども可視化
「EC2 Instance 使用量」
EC2の使用量がチェックできます。CloudWatchログを入れるともっと詳細なデータが確認できます。
他にも色々なダッシュボードが用意されておりますので是非試してみてください。
さいごに
今回はガバナンスを効かせるという観点で、AWS Config / Cloudtrailのログを取り込んでみました。これによってリソースがどのように使われているとか、どのような設定になっているか、また誰がどのようなリソースにアクセスしているかなどが確認できるようになります。しかもリアルタイムに。
今度はCloudWatchや VPC Flow logにもチャレンジしてみたいと思います。
(追記)
現時点(4/8)では、Add-on for AWSと ITSI4.4.x を同じインスタンスに同居させてはダメなようです。思いっきりハマってました。
https://splunkbase.splunk.com/app/1841/
NOTE: If you're using the Splunk Add-on for Amazon Web Services and Splunk App for Infrastructure (SAI) to monitor AWS data, don't install ITSI version 4.4.x. These versions of ITSI contain SAI versions 2.0.x, which aren't compatible with the Splunk Add-on for Amazon Web Services. If you're using SAI to monitor AWS data with the add-on, these versions of ITSI provide no way to continue doing so
Author And Source
この問題について(AWS Config / CloudTrail ログをSplunkに取り込んでみた (SQS base S3方式)), 我々は、より多くの情報をここで見つけました https://qiita.com/maroon/items/7776539f79bcfc14a692著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .