Amazon OpenSearch Serviceによるセキュリティ分析とモニタリング機能

Pulisher : Cloud Technology Center イ・ヨンジン
Description : OpenSearchの様々な活用法について紹介したセッション

はじめに

ElasticSearchから変化したOpenSearchは、膨大なログデータから欲しいものを探すのに最適なサービスです。今では、このような膨大なデータから特徴やトレンドを見つけることは、非常に一般的で必須の作業として位置づけられています。AI/MLも似たような結果を導き出すことができますが、データ加工過程の前にデータの生のまま確認するにはOpenSearchほど良いものはありません。

最近では、このような特徴を持って、セキュリティ分析や、モニタリング用に多く使われていますが、AWSの専門家が提案するOpenSearchの活用法について調べてみました。

セッションの概要紹介

Amazon OpenSearch ServiceとAmazon Security Lakeは、この2つを活用することで、包括的で費用対効果の高いセキュリティ戦略を提供します。これにより、セキュリティ運用(SecOps)チームは、記録されたデータに対してセキュリティ調査を容易に行い、潜在的な脅威を迅速に検出することができます。 また、DevOpsおよび監視エンジニアが重要なイベントログを確認し、コンテナ化されたアプリケーションやマイクロサービスの問題を検出するための統合された環境を提供します。本セッションでは、OpenSearchの活用のベストプラクティス、モニタリングパターン、組織のセキュリティと検証のニーズについて、その規模に合った低コストで実現できる方法について学びました。

セッションの内容は以下の通りです。大容量データの中に隠れている価値を探したり、データを生成した環境で実行中のアプリケーションの動作について、どのように詳細なインサイトを探して分析するかを共有する場でした。 また、OpenSearchを利用したログ分析を通じてセキュリティ問題を確認するアーキテクチャについても、デモを通じて理解させる場でした。

全世界で2023年一年間に新たに生成されるデータの容量が129 ZB（Zettabyte – Terabyteの1000 x 1000 x 1000の規模）になると言われています。

特に、ITインフラで生成される機械的なデータとしては、アプリケーションとインフラ。 で生成される機械的なデータとしては、アプリケーションとインフラの運用で発生するオペレーションログがあります。最近では、現場のセンサーから発生する膨大な容量のIoTログも存在します。

では、このような膨大に蓄積されるデータから何を確認することができるのでしょうか。Applicationとinfra.対象は問題なく運営されているか、もし問題が発生した場合、どのような原因で発生したのかなどを確認する必要があります。セキュリティ的な観点からは、疑わしい認証が発生したのか、特定のIPがどのデータでアクセスしたのかなども確認する必要があります。

そして、このようなインフラから生成されたデータは分析され、その中に隠されたインサイトを得ることができます。

これらを実現できるのが、このあたりから登場するAWSサービスがOpenSearchになります。 OpenSearchをリリースして以来、短い時間にもかかわらず、多くの機能と改善が行われ、非常に幅広く使われています。

準リアルタイムで検索が可能で、それを分析することができるので、様々なベンダーに多く使用されています。

ちなみに、IoTなどのセンサーからデータがOpenSearchに入ると、データを構成するすべてのフィールドにindexが付けられ、他の作業なしで検索が可能になります。もちろん、多段階で階層化されたJSON形式もサポートしています。

Oberavablityは最近、クラウドインフラでよく使われる単語になりました。日本語で簡単に説明すると” ビジビリティ” という意味になります。 各アプリケーションとインフラが発生させるログを活用し、システム外部から内部を簡単に確認することができ、問題が発生する可能性のある内容についてオペレータや管理者に通知したり、問題解決の糸口を見つけることができるという意味に解釈されます。

ほぼ全てのシステムが準リアルタイムで確認できる必要があるのは、やはり即時の障害対応が要求されるからではないでしょうか。 これを逃すと、機会費用の損失や売上の減少による直接的な金銭的な損害とともに、会社に対する評価により、信用の低下などにつながる可能性があります。

では、どうすればこのようなリスクから抜け出すことができるのでしょうか？ 結局、何らかの状況が発生した場合、それを認知（MTTD）して回復（MTTR）する時間との戦いになります。

最終的に顧客に提供されるサービスに対するSLAを満たすためには、運用するインフラの” ビジビリティ”の確保がビジネスデリバリーには必須となりました。

このような”可視性”確保のために必要なアーキテクチャは、下の図に表現されているように、logソースから必要なlogを収集し、高速処理のためのバッファ構造を持ち、logを最終フォーマットに合わせて処理できるようにソートした後、最後に分析後に結果を表現する、このような一連のプロセスを持つことになります。

AWSを活用した可視化構築のベストプラクティスとして、オープンスソースで標準化を提供しているOpenTelemetryというものがあります。これを活用すれば、自由に可視化システムを構築することができます。関連する簡単な説明と資料リンクをここに共有します。

AWS Distro for OpenTelemetry
https://aws.amazon.com/otel/
https://aws-otel.github.io/

Build an observability solution using managed AWS services and the OpenTelemetry standard
https://aws.amazon.com/blogs/mt/build-an-observability-solution-using-managed-aws-services-and-the-opentelemetry-standard/

このような可視性確保に必要なログ収集に関しては、フルマネージドのサーバーレスサービスであるAmazon OpenSearch Ingestionがあります。従来はLogstashなどの3rd-partyソリューションを使ったり、sidecar形式でdockerで収集することができましたが、AWSが提供するサービスができました。

Amazon OpenSearch Ingestion
https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ingestion.html

このOpenSearch Ingestionは、ログデータを収集すると同時に、データストリーミングに対するETL作業も一緒に行うことができます。データソース側に貼り付けてデータを受け取ることもできますし、network endpointからデータを受け取ることもできます。最終的にはその名前が示すように、OpenSearchにデータをプッシュしてくれます。

OpenSearch Ingestionのパイプライン設定は、Source / Processor / Sinkの3つの項目に分けられます。Sourceはデータが入ってくる場所であり、Sinkは最終的にデータを送る終着点です。真ん中のProcessorで必要なETL作業も可能に設定することができます。

特に、Blueprintsオプションを利用すれば、インポートされるsource dataの形式に合わせるだけで、自動的に処理してくれるのでとても便利です。

結局、私たちが追求する”可視性”architectureは次のように構成することができます。

・Collection : 3rd-party / opensourceのagent / AWSが提供する機能 / OpenTelemetry
・Buffering : S3
・Transformation : OpenSearch Ingestion
・Analytics engine : OpenSearch
・Visualization : OpenSearch dashboard

分析とVisualizationを助けることができる、モニタリング項目の定立とdashboard表現のために、Amazon Managed Service for PrometheusとAmazon Managed Grafanaを一緒に使用して、管理利便性とインサイトを得ることができます。

最終的にすべてを合わせたパイプラインは以下のようになります。

これを実際の構成上、アーキテクチャに置き換えてみると、次のような図になります。

下記はdemo画面で、実際のトランザクションを発生させた時、どのようにダッシュボードに表示されるかを確認するためのページです。

デモダッシュボードでは、どの項目でトランザクションが発生したのか、そのトランザクションがどこと繋がっているのかを画面ですぐに確認することができます。

OpenSearchに取り込まれるデータフォーマットについて定義してあげると、既に作成されたダッシュボードテンプレートがすぐに使えるようになっています。汎用的に使われるlog formatということで、基本フォーマットを使うと、設定に対する修正やチューニングをすることなく、すぐに使えるようになります。

では、OpenSearchを利用したセキュリティ分析はどのように行われるのでしょうか？

セキュリティの観点からの2023年以降の状況は以下の通りです。 非常に専門化されていると同時に、頻繁に発生するイベント数、AIを利用した攻撃、政府機関からの非常に強いサイバーセキュリティの要求、そして疑わしいユーザー活動などが継続的に、またより多くの頻度で発生すると予測されます。

セキュリティ分析には様々なハードルがありますが、簡単に列挙すると、非常に多くのデータ量、またはその逆で、継続的で十分なデータ投入、指標とデータ間の関連性の欠如、そしてそれを実行できる人的リソースの不足などが挙げられます。

OpenSearchで活用できるSecurity Analytics pluginを通じて、簡単に標準ログに対して分析することができます。 結局、このような機能の活用は、問題発生時、問題を認識して原因を把握し、対応まで完了する時間を加速することができます。

SIEM(Security Information and Event Management)とログ分析用システムでOpenSearch + SIGMA ruleをすぐに活用できます。

OCSF(Open Cybersecurity Schema Framework)データも互換性があり、すぐにOpenSearchでマッピング作業なしで活用できるようになりました。

OpenSearchのSecurity Analytics機能は、問題の検出から始まり、アラートとともに、今後の問題発生の可能性とともに、組織全体の状況やログを見ることができます。

課題に対する検出の流れは、対象となるログと認識設定によって動き、内容を整理して表示します。

Correlation engine機能が、発見した内容に対する関連性を確認し、ある程度関連性のあるイベント認識図と色で区別してくれます。管理者は視覚的な情報を基に、どの程度の深刻度であるかをすぐに認識することができ、クリックするだけでその内容を確認することができます。

FindingとAlertを時系列の棒グラフでも表現してくれます。

各項目をクリックすることで、どのような内容がFindingであり、Alertであるかを確認することができます。

Correlationグラフを通じて、お互いの関連関係を図式で確認することができ、即座に詳細を閲覧することができ、すぐに行動を起こすことができる情報を提供することになります。

セキュリティ関連データとログを一箇所に収集してSecurity Lakeを構成することで、セキュリティ管制に必要な情報を一括管理することができます。

さらに、Security LakeとOpenSearchの組み合わせにより、強力なモニタリングが可能になります。

Security LakeデータをOpenSearchに注入して、どのようにダッシュボード化するかを示すプロセスです。

Parquet形式のOCSFファイルについてもテンプレートが既に用意されているので、別途手動でマッピングをする必要はありません。 メニューから選択するだけで、自動的に接続されます。

データを取り込むSource、それを処理設定するProcessor、そして結果をエクスポートするSinkで構成されるプロセスを作ります。Sinkには今まで確認したOpenSearchを設定します。

OpenSearchを活用したセキュリティ分析と可視化において多くの利点をもたらします。

要約すると、次のようになります。
・セキュリティデータをSecurity Lakeのような中央管理ツールを使ってまとめる。
・公開されているSIGMA / OCSFを利用する。
・セキュリティデータの可視化のためのOpenSearchを活用する。

セッションを終えて

OpenSearchは、一般的に膨大なログから確認したい内容を素早く検索するサービスエンジンです。これをセキュリティと融合させ、セキュリティデータに関する管制及び対応を迅速に処理できるように支援するツールとして活用も可能です。これに対する3rd-party pluginや、セキュリティ標準テンプレートであるSIGMA/OCFSなども簡単に連動することができます。これからは、別途ルールやダッシュボードを作成することなく、OpenSearch一つで全てが可能になりました。セキュリティ管制や対応に、OpenSearchを活用してみてください。

参考
Amazon OpenSearch Service
https://aws.amazon.com/what-is/opensearch/?nc1=h_ls
Amazon OpenSearch Service | AWS Big Data Blog
https://aws.amazon.com/ko/blogs/big-data/category/analytics/amazon-elasticsearch-service/
Amazon Solution Library: Centralized Logging with OpenSearch
https://aws.amazon.com/solutions/implementations/centralized-logging-with-opensearch/