この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWSチームのすずきです。
AWSが提供する脅威検知サービス「GuardDuty」、 その検出結果を サードパーティへのデータ配信をサポートした 「Kinesis Data Firehose」 を利用して 「Datadog Logs」に転送、集約管理を試す機会がありましたので紹介させていただきます。
AWS設定
GuardDuty
「GuardDuty の有効化」のみ実施しました。
Firehose
データ配信先として「Datadog Logs」を設定した 配信ストリームを利用しました。
EventBridge
GuardDuty の 検出結果を Firehose に転送するルールを新規に作成しました。
サービスごとの事前定義パターンを利用し、以下設定を行いました。
- サービスプロバイダ: 「AWS」
- サービス名 : 「GuardDuty」
- イベンドタイプ: 「GuardDuty Findng」
- ターゲット: 「Firehose配信ストリーム」
- ストリーム: 事前にDatadog Logs 転送設定を実施したストリームを指定
GuardDutyサンプル
GuardDuty の検出結果のサンプルを生成します。
Datadog 設定
サンプルログ確認
GuardDuty のログは、EventBridge、Firehose を経由して、5分前後でDatadog 上で確認可能になります。
パイプライン
ログ処理を行うパイプラインを設定します。
GuardDuty用として用意された設定を「Browse Pipeline Library」より選択、複製して利用しました。
2020年8月時点では Firehose経由で転送されたGurdDutyログが処理対象外とならないフィルタ設定が存在します。 GuardDuty用のパイプライン設定の複製時、フィルタ設定を「source:guardduty」→「source:aws」と変更しました。
パイプライン設定後、「GuardDutyサンプル」を再実行します。 5分程度経過した後、パイプラインにより加工されたログが Datadog Logs 上に表示されます。
Facet設定
フィルタ、絞り込み対象として利用するログ項目を指定します。
以下の設定を「Add Facet」で追加しました。
| Facet | 内容 |
|---|---|
| @account | AWSアカウント番号 |
| @region | AWSリージョン |
| @detail.severity | GuardDutyの重要度 |
| @detail.service.serviceName | ログ識別用 |
| @evt.name | GuardDuty 結果タイプ |
| @title | GuardDuty 結果詳細 |
設定後「GuardDutyサンプル」を再実行、5分待機します。
指定した項目による絞り込みが可能となっている事を確認します。
フィルタ設定
パイプラインのフィルタ設定に「@detail.service.serviceName:guardduty」を追加、 GuardDuty ログ専用のパイプラインとして機能するように設定しました。
ログレベル設定
Category Processor
GuardDuty ログに含まれる「severity」の値は 0～10の範囲で、高い値が重度の問題である事を示す仕様です。
Datadog Logs上でのログレベル、ステータスの識別を可能にするため、
GuardDuty ログ用のパイプラインに「Processor」を追加、GuardDuty 重要度を示す数値を 一般的なSyslog の Severity に変換します。
- Target category attribute: severity_syslog
- Poplate category (GuardDuty Severity値 -> severity_syslog)変換
| MATCHING QUERY(GuardDuty Severity) | GuardDuty重要度 | severity_syslog |
|---|---|---|
| @detail.severity:[7 TO 8.9] | High | Error |
| @detail.severity:[4 TO 6.9] | Medium | Warning |
| @detail.severity:[1 TO 3.9] | Low | Notice |
| @detail.severity:[9 TO 10] | (予約) | Critical |
| @detail.severity:[0 TO 0.9] | (予約) | Informational |
| - | - | Emergency |
| - | - | Alert |
| - | - | Debug |
Status Remapper
Category Processor で 変換した、「severity_syslog」を Datadog Logs のログステータスに反映させる「Processor」設定を追加します。
パイプライン動作確認
以下のGuardDuty用パイプライン設定後、「GuardDutyサンプル」を再実行しました。
- FILTERS
- Category Processor
- Status Remapper
GuardDutyの重要度が Datadog Logsの ステータスに反映、色分け表示が可能になりました。
費用
GuardDutyの検出イベント、1件5KBのログが 月間 1000 ～ 1000000 件 発生する想定で、 Datadog Logs と Firehose の料金を試算してみました。
| ログ件数(月間) | Datadog(件数) | Datadog(容量) | Firehose(容量) | 費用合計(Datadog+AWS) |
|---|---|---|---|---|
| 1000 | $0.003 | $0.001 | $0.000 | $0.003 |
| 10000 | $0.026 | $0.005 | $0.002 | $0.032 |
| 100000 | $0.255 | $0.050 | $0.018 | $0.323 |
| 1000000 | $2.550 | $0.500 | $0.180 | $3.230 |
GuardDutyの検出イベントログのDatadog転送、多くの環境では低コストでの利用が可能と思われます。
まとめ
GuardDuty と Datadog Logs の連携、これまでも Lambda関数を利用する事で実現可能でしたが、 Firehoseのアップデートにより、コード実装なく利用することが可能になりました。
Datadog を利用する事で、柔軟なアラート設定や Slack などチャット通知なども実現可能です。 GuardDuty のより効率的な利用を実現するツール Datadog Log、その連携手段としてFirehose をぜひお試しください。
2
