CloudTrail を用いて不適切な操作を検出する

この投稿では、Amazon Web Services (AWS) のクラウドワークロード内で、既存の脅威検知ソリューションを強化できる行動分析技術を使用して、異常な行動を検知するための実用的なアプローチについて説明します。異常検知は、AWS Well-Architected framework のセキュリティの柱に記載されているように、成熟したセキュリティベースラインが整備されている場合に検討すべき、高度な脅威検知技術です。

クラウドで行動分析検知を検討すべき理由

従来、脅威検知ソリューションは、エンドポイントとネットワークに焦点を当て、既知の攻撃の指標や侵害の指標となるログイベントを分析していました。また、ユーザーとデータに焦点を当て、データ損失防止やユーザーとエンドポイントの行動分析を行う製品を使用して、データ層で疑わしいユーザーの行動を検出することもできます。どちらのタイプのソリューションも、オペレーティングシステム、アプリケーションレベル、およびネットワークのログを分析し、既知の攻撃手法や技術、その手順の検知に重点を置いていますが、クラウドのコントロールプレーンやその他のクラウド固有のログソースは、これらの従来の脅威検知ソリューションの使用対象外となっています。

クラウドでセキュリティを確保するためには、環境内の悪意ある行動を検知できることが必要です。クラウドサービスが悪用された可能性があるイベントの検出ができることもその一つです。しかしながら、このようなイベントのアクティビティがコントロールプレーンレベルで記録され、従来の脅威検知ソリューションのログソースに痕跡を残さないことは課題です。例えば、クラウドサービスやクラウドアカウント間の望まれないデータ移動は、データ転送のためにクラウドバックプレーンを使用し、必ずしもエンドポイントやネットワークゲートウェイに接触するわけではありません。したがって、関連するイベントは、AWS CloudTrail や AWS Config などのクラウドネイティブログ内にのみ現れ、ネットワークやオペレーティングシステムのログには現れません。

図1：ソリューションアーキテクチャの例

図1に示す単純化した例では、Amazon EC2 インスタンスのエンドポイントやゲートウェイセキュリティソリューションから明らかになるのはクラウドからファイアウォールを経由し AWS サービスへと通過するデータストリームのみです。

そして、サーバーレスソリューションやクラウドネイティブサービスのアクティビティを通過するデータストリームは、クラウドネイティブログにのみ表示されます。

Amazon GuardDuty は、AWS アカウントを保護するために悪意のある活動や不正な行動を継続的に監視する脅威検知サービスで、ネットワークフローログだけでなくコントロールプレーンをも分析します。GuardDuty は、機械学習と行動モデルを組み合わせた脅威インテリジェンスを使用して、アカウントの侵害や異常なデータアクセスまたは通信などの脅威を検出するために、各クラウドアカウントで有効化する必要があります。
しかし、すべての望まれない動作が既知の攻撃パターンに従っているわけではありません。これらの望まれない動作には、特定のワークロードの意図された動作とは異なる、クラウド環境内の通常の動作も含まれることがあります。各アクティビティやログエントリ自体は悪意のあるものに見えないかもしれませんが、一連のイベントによって、アプリケーションの個々のコンテキストと比較したときに、悪意のあるアクティビティの可能性が明らかになることがあります。CloudTrail には、ファイアウォールやアンチウイルスのログのような悪質なイベントが存在しないため、既知の脅威ベクトルではなく、アプリケーションのユースケースのコンテキストにおけるコンプライアンス違反の動作に基づいて脅威を検出することが課題です。
攻撃や難読化のテクニックは常に進化しており、既知の攻撃手法や技術、その手順に基づいて検出することは難しいため、異常検出は防衛手段の一つとして、ますます重要な役割を果たすようになってきています。

望まれない動作とはどのようなものでしょうか

望まれない動作に関する重要なイベントを特定するための1つのアプローチは、ワークロードのコンテキストを考慮した一般的なクラウドアクティビティをもとに異常かどうかを見極める一連の質問をすることです。ワークロードの種類に応じて、望まれない操作の API のイベントとそれに関連する質問は、次のようになるでしょう。

イベント: EC2 インスタンスが起動しました。
質問: 予期しないユーザーまたはロールが使用されたか、EC2 インスタンスがパイプラインの外で起動しましたか？

イベント: あるユーザーやロールが、短い時間枠の中で多くの List API や Describe API を実行しました。
質問: アプリケーションは通常、本番で list と describe の API コールを生成していますか？そうでない場合、これは侵入者によって実行された偵察活動である可能性があります。

イベント: ユーザーまたはロールがAmazon Elastic Block Store (Amazon EBS) のスナップショットを作成し、他のアカウントと共有します。
質問: スナップショット共有イベントは予期されたものですか？そうでない場合、それはデータを流出させようとする試みである可能性があります。

イベント:  CloudTrail で多くの失敗した APIコールが検出されます。
質問: これらの失敗した呼び出しは、機密性の高いサービスや情報の周辺で生じましたか？もしそうなら、未承認のユーザーが環境を探っている可能性があります。

イベント: 多くの ListBucket イベントが機密性の高いAmazon Simple Storage Service (Amazon S3) バケットで検出されます。
質問: これらのイベントは予期しないもので、予期しない ユーザー によって実行されたものですか？もしそうなら、権限のないユーザーが偵察活動のために S3 バケットのリストを取得しようとしている可能性があります。

このように一連の質問を作成すれば、それらはアプリケーション固有の脅威検出ユースケースに変換され、機密性の高い本番環境に適用することができます。このような環境では通常、パターンが予測可能であるため、有効な方法です。予測可能なパターンがあれば、誤検出の可能性は低くなり、異常を監視するユースケースを開発する労力に見合うだけの価値が生まれます。脅威検出のユースケースは、Security Information and Event Managemt（SIEM）ツールまたは Amazon CloudWatch のルールを使用して CloudTrail ログ内で特定することができます。

CloudWatchでCloudTrailの異常を検出する

CloudTrail は AWS アカウント内の活動を記録することができるため、過去のクラウドアクティビティを深く調査するだけでなく、望まれない行動をほぼリアルタイムで検出するのにも最適なサービスです。CloudTrail はログを S3 バケットに送信し、イベントを CloudWatch に転送することができます。CloudWatch を使用すると、すべての CloudTrail イベントにわたって検索を実行し、自動通知のためにCloudWatch アラームを定義できます。

CloudWatch フィルタとアラームを作成することで、異常と思われる個々の CloudTrail イベントに対してアラートを作成することができます。フィルタは監視したいイベントを定義し、アラームでは通知を受けたいときの閾値を定義します。

前述の S3 バケット列挙の例に対してフィルタを作成するには、図2のように CloudTrail のロググループを選択し、メトリクスフィルタを選択して新しいメトリクスフィルタを作成することになります。

図2: CloudWatch メトリクスフィルタの作成

userAgent が AWS Internal なものを除外することで、AWS Access Analyzer や Amazon Macie などの他の AWS サービスによって実行される S3 へのアクセスアクティビティを除外し、正常な動作と見なすことができ誤検知を防ぐことができます。

このメトリクスフィルタを、すべての異常検出モニタリングに使用する新しい名前空間に保存します。フィルタを作成したら、フィルタに基づいた新しい CloudWatch アラームを作成します。フィルタとアラームしきい値に応じて、Amazon Simple Notification Service (Amazon SNS) トピック を通じて CloudWatch アラーム通知を受け取り、生じたインシデント対応活動を自動で実行することもできます。

アラートが発生した後、同じフィルタパターンを使って CloudWatch で関連イベントを検索することができます。CloudTrail イベントは、IP アドレス（sourceIPAddress）、誰がアクションを実行したか（userIdentity）、またはアクションがマネジメントコンソールからなのか、 AWS Command Line Interface (AWS CLI) からなのか （userAgent = aws-internal or aws-cli）といったより詳細な S3 ListBucket イベントの実行者に関する情報を提供します。以下の図3は、CloudTrail のログの例です。

図3: CloudTrail のログ

トラップによる異常の検出

望まれない行動に基づいて侵入者を検知するためのもう一つの簡単で効果的な手法は、ハニーポットやカナリアのような、おとりサービスを利用することです。ハニーポットは、サブネット内のホストや、データベースやストレージサービスなどのダミーデータを格納したデータストアを偽の本番環境として攻撃者に探索させることで、攻撃者の振る舞いに関する情報を取得するように設計されています。カナリアは、ハニーポット環境内の特権IDのように見える ID やアクセストークンです。ハニーポットもカナリアも、ユーザー名、データベース名、ホスト名などが攻撃者にとって魅力的に見えるだけで、侵入されても組織がリスクにさらされることはありません。
CloudWatch アラームを使って、攻撃者がハニーポットの探索を始めたり、カナリアアクセストークンを使って探りを入れようとしたことを示すイベントを CloudTrail で監視することができます。一度自分自身が攻撃者のように振る舞うことで、CloudTrail 内でテストイベントを生成することができ、監視したいイベントの詳細（イベントソース、イベント名、パラメータなど）を特定するのに役立ちます。以下は、異なる種類のトラップについての監視できる CloudTrail イベントの例です。

トラップは通常、アクセスや使用パターンが予測可能で厳密に管理されている本番環境に展開されます。コスト効率が良く、導入が簡単で、高い確実性でアラームを出すことができるソリューションです。また、トラップは、特に高度に自動化された攻撃など、非常に洗練された攻撃をも検出する可能性を提供します。

統計的な異常の検出

AWS CloudTrail Insights は CloudTrail の機能で、リソースプロビジョニングの急増、AWS Identity and Access Management (IAM) 活動のバースト、定期メンテナンス活動の不一致など、AWS アカウントにおける異常な運用上のアクティビティを特定するために使用することができます。
CloudTrail Insights は、正常な動作のベースラインを確立し、異常なパターンを検出したときに Insights イベントを生成することによって、コンプライアンス違反の動作の主要な指標を提供することができます。主要な指標とは、調査を開始するためのイベントです。
しかし、統計的な変化がアラートのしきい値に達しておらず、問題が提起されていない場合でも、統計的な洞察は、インシデントのコンテキストをよりよく理解するための調査をサポートする二次指標として使用することができます。機密データに関する、あるA PI コールのわずかな変化であっても、GuardDuty などの他のソリューションからのアラートの後や、先に述べた異常検出技術で異常を発見した場合、貴重な情報を提供することができます。

次の図4は、API コールを時系列で表示した CloudTrail Insights で表示するグラフの一例です。

図4: CloudTrail Insights のチャート例

まとめ

この記事では、既存のセキュリティソリューションを補完するために、機密性の高いワークロードのコンプライアンス違反や望まれない動作を監視することの重要性について説明しました。クラウドにおける異常検知は、コントロールプレーンでクラウドサービスのアクティビティを監視し、その動作が各ワークロードのコンテキストで期待されるものかどうかをチェックすることです。このブログ記事で紹介したツールをセットアップしてサポートすることは、クラウドにおける高度な脅威を検知するための、手頃で実用的、かつ強力なメカニズムにつながります。クラウド上の API アクティビティを分析する方法の詳細については、AWS Management & Governance Blog のAnalyzing AWS Cloudtrail in Amazon CloudWatch をご参照ください。
この投稿についてフィードバックがある場合は、以下の Comments セクションにコメントを送信してください。この投稿について質問がある場合は、AWS サポートにお問い合わせください。
AWS Security のハウツー、ニュース、機能アナウンスをより詳しく知りたい場合は、Twitter でフォローしてください。

翻訳はソリューションアーキテクトの佐藤 航大が担当しました。原文はこちらです。