見出し画像

SIEM環境をDatadogへ移行した話

健康診断で体重がこれまでのピークに近い値に達してしまった「ぎだじゅん」です。
ライフイズテックという会社でサービス開発部 インフラ/SREグループに所属しています。

体重がほぼピークに達したことを知った嫁が、最近アプリと連携できる体重体組成計なるものを最近購入してきました。
これまで体重計を避けて生きてきた自分にとって「どうせ使わないよ・・・」と思いながらも、数日続けてみると体重や体脂肪などの状況の変化がアプリで見えて「今日は少し歩いたから減ったかな」とか「今日は脂っこいものたくさん食べたから増えたのかな」とか自分のその日の生活と紐付けて意識するようになりました。
そして、意識して生活することで体重が少しでも減ってくると、なぜか1日1回計測するのが楽しくなってきました。
人間って、状況を見える化するといろいろ対策しようと思うものなんですね。

イラストはイメージです・・・

本題です。


セキュリティを可視化するSIEM

仕事でもシステムやセキュリティの状態などが可視化されてくると、改善すべきポイントなどが見えてきたりするので、オブザーバビリティ(可観測性)はとても大切です。

可視化って大事

ライフイズテックでは、AWS上の各種ログを集約して相互分析してセキュリティの脅威やその予兆などを観測できるようにするためにSIEM(Security Information and Event Management)を導入をしています。
前回の投稿でもセキュリティ対策で「SIEM(Security Information and Event Management)の導入と運用」について、触れました。

これまではAmazon OpenSearch ServiceのSIEMソリューションである「SIEM on Amazon OpenSearch Service」を利用しているとお話しましたが、最近このSIEM環境をDatadogにお引っ越ししました。
(前回の投稿時も移行の真っ最中でした)

なぜDatadogじゃないといけないんですか?

SIEM on Amazon OpenSearch Service」は、導入方法などもGitHubにわかりやすくまとまっていて、AWS環境のさまざまな種類のログごとにセキュリティ的な観測で必要なダッシュボードがデフォルトで用意されており、デフォルトのウィジェット(グラフやテーブルなどのパーツ)を転用してオリジナルのダッシュボードにまとめたりできるなど、自分のようなSIEMの利用初心者にとってはとても導入しやすいものでした。
Datadogに切り替えはしましたがスモールスタートでSIEM導入や運用ができるこのソリューションは本当に素晴らしいものだと思っています!!

ただ、運用を続けていくとOpenSearch環境の運用として、OpenSearchのインデックスなどのチューニング、リソース管理(処理量やログ保管量にあわせてスペックやEBSの調整)、ログをフォワードするlambda関数「es-loader」のチューニング、OpenSearchのアップデート対応などである程度の運用リソースが必要となりました。
また、取り込んでいたログの量も多かったことから、頻繁にEBSのディスクのスループット制限にひっかかり、最終的にEBSのIOPSを増やすかノードを増やすなどの対策が必要となるなどで、運用コストと環境コストでの問題がでてきました。

そんな運用を続けていく中で、フルマネージドなSIEM環境があったらと思うようになりました・・・

楽したい・・・

そこで、フルマネージドのSIEM機能を提供してくれているサービスを探してみたところ、世の中にいろいろ良さげなサービスがあることを知りました。
いずれもセキュリティに関するオブザーバビリティ機能はもちろんのこと、プリセットされたルールで脅威検知したり、複数のログの依存関係をトレースして詳細に分析する機能などを提供してくれてとてもよいです。

ライフイズテックでは、もともとAWS環境のメトリクスやアクセスログ、アプリケーションログなどを使って、Datadogでサービスの状態やパフォーマンスなどのオブザーバビリティ環境として利用していました。
調べていたらDatadogにもセキュリティ関連のオブザーバビリティサービスがあることを知りました。

CloudTrailなどのログも収集させて現在のSIEMと同様のダッシュボード運用がフルマネージド環境で実現できそうであること、オブザーバビリティ関連のツールを一本化することで運用面もコスト面もメリットがあることから、SIEM環境をDatadogへ移行することにしました。
(なら、最初からDatadogでセキュリティも可視化すればよかったじゃんとは言わないでね、泣いちゃうから・・・)

また、Datadogにもログやメトリクスからダッシュボードを作成してセキュリティに関する状況を可視化できるのはもちろんのこと、Datadog Security として取り込んだログ情報からインフラ環境やアプリケーションに対しての脅威をDatadogが提供しているルール(OOTB Rules)から検出する「Cloud SIEM」や、Datadog Agentを使用してコードレベルでの脆弱性を悪用するアプリケーションレベルの攻撃(SSRF、SQL インジェクション、XSSなど)を監視や保護する「Application Security Management」など、リアルタイムで異常を検出してくれるような機能も提供してくれているので、今後のセキュリティ運用の拡張も期待できます。

Datadogへの移行の内容

「SIEM on Amazon OpenSearch Service」では、AWS環境から主に以下のログを取得してダッシュボードを作成していました。

  • CloudTrail

  • Elastic Load Balancing (ELB)

  • GuardDuty

  • AWS WAF

  • VPC(ACCEPTのみ)

ダッシュボードの内容はだいたい以下のような感じです。

  • AWSコンソールへのログイン状況(ユーザ別ログイン状況、ログイン失敗状況、どこから接続しているか等)

  • AWS APIへのリクエスト状況(主に失敗している状況など)

  • VPCフローログからの接続状況(外部からSSH、データベースなどに不正な接続が起きていないかなど)

  • AWS WAFでの検出状況

  • サービスへのアクセス状況(接続元、ホスト別、パス別、HTTPステータスコード別など)

  • GuardDutyでの検出状況

  • AWS各リソースの変更状況(SecurityGroup/NetworkACL、S3バケットポリシー、VPC/RouteTable/Gateway関連、IAMユーザ/ロール/ポリシー/アクセスキー、AWS ConfigやCloudTrail関連の変更など)

今回の移行では、まずはDatadogでもこれまでと同じ内容でダッシュボードを作成しました。

Datadogでログ収集

Datadogのログ管理の構成 (https://docs.datadoghq.com/ja/logs/ より)

ログの収集(SIEM環境への転送)については、Datadogもこれまで使っていた「SIEM on Amazon OpenSearch Service」とほぼ同じようなアーキテクチャで、サービスが提供するログを転送するForwarder機能のlambda関数をAWS環境にセットアップしてログの転送を行います。

もともとサービスの状態やパフォーマンスなどのオブザーバビリティ環境としてDatadogを利用していたので、初めてDatadogを利用する場合はいろいろ準備が必要です(以下を参考にしてください)。

また、今回の移行ではForwarder機能のlambda関数はすでに用意されていたので初期セットアップは不要でしたが、以下のページにあるCloudFormationやTerraformのLaunch Stackを使って、手順に従って実行することで簡単にセットアップが可能です。

Datadog Forwarderがlambda関数としてセットアップされたら、lambda関数のイベント設定で各AWSサービスからS3バケットへ出力されるログを指定して設定することで、S3へのログ(オブジェクト)出力のイベントをトリガーにしてログを転送してくれます。

CloudWatch Logsでのトリガー設定画面

ちなみに「SIEM on Amazon OpenSearch Service」では基本はS3バケットへ出力されるログのみが転送対象でしたが、DatadogではCloudWatch Logs(ロググループ)のログも出力をトリガーに転送することも可能です。
CloudWatch Logsのログをトリガーにすると、必要なもののみフィルタパターンで送信するなどもできるので、ログ取り込み量を減らすことでDatadogのコスト削減も可能です。
ただAWS内でのログ保管の料金は、S3よりもCloudWatch Logsの方が高いので要注意。

ログインデックスの保存期間の設定

SIEMを最初に導入したときは過去の状態をさかのぼってみれるように取り込まれたログのインデックスは数か月分残しておこうと考えていましたが、そうなるとインデックスの保管量が膨大になりコストがかかります。

SIEMの運用を1年続けてわかったのですが、以下のようなSIEMでの運用において、過去の状態については古くても3日前のものを確認するぐらいのケースでしたので、Datadog上でのログインデックスの保管期間は7日間で運用しています(あくまで弊社の場合です)

  • 毎日状況を確認し続けることで日々の変化を把握する

  • 予兆などの通知が発生したときにリアルタイムに確認する

今のところ利用していませんが、ログの種類ごとに保持期間をセグメント化して保持期間をわけることも可能っぽいです。
(たとえばCloudTrailのログは7日間で各種アクセスログは3日間にするなど)

とはいえ、巷で起きているインシデントのニュースなどでは2か月前にアクセスキー情報が漏洩していたが気が付かず、2か月後にアクセスキーを使ったデータ漏洩の形跡を発見したなどのケースもあったりするので、アクセスキー情報が漏洩した形跡を確認するために過去の状況を振り返りたいなども発生するかもしれません。

Datadogでは、このようなケースに対応できるようにAWS S3などのストレージへログのアーカイブを転送して保管し、必要に応じてアーカイブをDatadogに復元して再度分析が行える機能を提供しています。

これを使うことでDatadogへのログをインデックス上に長期保管することによるコスト増加を防ぎつつ、特定の調査目的で過去の状況を分析する必要があるときにも比較的簡単に対応(アーカイブからのリハイドレート)ができます。
余談: よさげなサービス「Flex Logs」が2023年8月8日に発表されてました。

ダッシュボードの作成

「SIEM on Amazon OpenSearch Service」では、デフォルトでセキュリティに関するログからデフォルトでいくつかのダッシュボードやViewer(ウィジェット)が用意されていました。

DatadogでもいくつかAWSのメトリクスなどから出力できるダッシュボードや「Cloud SIEM」の機能を有効にすればCloudTrailやGuardDutyの検出結果などをベースとしたセキュリティ関連のダッシュボードは用意されています。

「CloudSIEM」を有効にするとデフォルトで用意されるダッシュボード群

しかし、「SIEM on Amazon OpenSearch Service」と同じようなウィジェットがあまりないため、ほとんどのウィジェットを新規で作成しました。
ただ、Datadogのウィジェットの作成は簡単で様々な種類のVisualizationによるウィジェットを以下の工程で作成できます。

  1. グループのウィジェットを作成

    • 「Add Widgets」から「Groups」の「Empty Group」を選択して作成

  2. Visualization の選択

    • 「Add Widgets」から任意のWidgetを選択選択
      (時系列グラフ、テーブル、クエリ値、トップリストなど)

  3. クエリの作成

    • Logsを指定して対象のログをフィルター指定

    • どの値を集計するかなどをフィルター指定

    • エイリアスの指定(COUNT、ステータスコード番号など)

  4. レイアウトの設定

    • 必要に応じて線の色や表示形式などを調整

  5. Visualizationのタイトル記入

  6. 作成されたWidgetsを該当のグループに移動してレイアウト調整

    • 表示させるサイズや場所など)

ウィジェットの作成内容の一例
(ALBのアクセスログからリクエスト先ホスト別のアクセス数をグラフ化)

ダッシュボード作成の詳細についてはDatadogのマニュアルを参照ください。

ダッシュボードは完成したが

この流れでウィジェットをこつこつ作成して、無事、8月よりDatadogでセキュリティ状況を可視化できるダッシュボードでの運用を開始しました。

移行したSIEMのダッシュボード
(ピンクのグループはDatadogの「Cloud SIEM」のダッシュボードのウィジェットからコピー)

ログ(Logs)から作成したウィジェットは、クエリの値などを右クリックして、該当のログの詳細に簡単に遷移できるので、問題のありそうな箇所の詳細を確認して必要な対応を検討していくことができます。

該当のウィジェットの数字を右クリックして表示したメニューから
「View related logs」を選択
「View related logs」から該当のログの詳細を確認できる

さらに、Datadogの強みとしてはリアルタイムでログから異常を検知できることです。
「SIEM on Amazon OpenSearch Service」でもルールを作りこめば同様なことはできますが、Datadogでは「Cloud SIEM」を使うことで脅威と判定するようなルール(OOTB Rules)がデフォルトで用意されているので、とても簡単に利用できます。
これを使って異常を検出して通知させることも可能です。

  • この「Cloud SIEM」については、別途機能を有効にして利用することが可能となりますが、有効にすることで課金も開始します。

ついてはこの「Cloud SIEM」について説明・・・としたいところですが、会社からの月1~2回の投稿ノルマを考慮して、今日はいったんここまでとしたいと思います。

最後に

なんだか今回の内容はDatadog社の回し者みたいな内容になってしまいましたが、このようないいサービスを使って健全な運用を続けるのはとても大事なことだと思っています。
よいサービスを使って、無理のない運用で健康な体型(体系)を目指して頑張ります!

イラストはイメージです・・・

<お知らせ>

ライフイズテック サービス開発部では、今後定期的なカジュアルなイベントを実施しています。
開催予定イベントの詳細はライフイズテックのconnpassからご確認ください。

興味のあるイベントがあったらぜひ参加登録をお願いいたします!

この記事が気に入ったらサポートをしてみませんか?