はじめに
AWSを利用して構築した環境を運用管理するにあたり、あらゆるレイヤーのアクティビティがわかることは非常に重要です。 というより、事実関係がわからなければあらゆるトラブルに対応することが困難になります。
そこで、この記事ではアクティビティの収集にフォーカスしてAWSのサービスや機能を整理してみたいと思います。 主に自分のために。
なぜアクティビティを収集するのか
「事実関係がわからなければあらゆるトラブルに対応することが困難」と一言で書きましたが、アクティビティが明確になることで以下の様な対応が可能になると思います。
- 問題の予兆を検知、予防する
- 発生した問題の内容や原因を特定し、影響を緩和・根本的な対策を実施する
- 問題の収束後にステークホルダーへの説明責任を果たす
アクティビティに関する情報がなければ、このいずれも不可能でしょう。
それでは、AWS上でアクティビティを収集するサービスおよび機能を紹介していきます。
この記事の前提について
まず、この類の記事を書くと一定の割合で誤解されるのですが、ここで述べる各種の設定はすべて実施する必要はありません。 要件や管理対象のワークロードに問題が起きたときのインパクト、予算などによります。 アクティビティの収集自体は目的ではありません。 サービスを提供する地域や業界において、法規制や各種ガイドラインがあればそれに準拠するべきでしょうし、脅威モデリング等を利用して管理対象のシステムをどのような脅威から守る必要があるかを整理した上で収集が必要なアクティビティを選択するのもよいでしょう。
また、（正規のアクセスについては）IAM UserやサードパーティのIdPで発行されたIDの共有などを行っていないことを前提とします。 でなければ、そのアクティビティが誰によるものなのか識別できません。
アクティビティを収集するAWSサービス
まずは、アクティビティを収集すること自体が目的のサービスについてまとめます。
- CloudTrail
- Config
- GuardDuty
CloudTrail
CloudTrailにより、IAM User / IAM Role / AWS Serviceによって実行されたアクションを記録することができます。
CloudTrailで記録できるアクションはManagement EventsとData Eventsに分類されます（Insights Eventsは通常とは異なる傾向のイベント群を検知した際に記録されるものなのでここでは説明を割愛します）。 Management Eventsは証跡を作成する事で記録が開始されますが、データイベントは明示的に設定しない限り記録されません。 管理するワークロードにおいて発生するデータイベントのうち、必要なもの（機密性の高いデータを操作するイベントなど）については記録することを検討しましょう。 その際、記録の対象を必要以上に設定した場合に料金が高額になる可能性があるので注意してください（Data Eventsは、使い方次第ですが一般的には大量に発生します）。
ちなみに、マネージメントコンソールでデータイベントの取得設定をしようとするとS3 / DynamoDB / Lambdaのみがサポート対象であるように見えるかもしれませんが、実際には他のサービスにも対応しています（Advanced Event Selectorを利用して設定できます）。 詳細はドキュメントを確認してください。
CloudTrailの証跡を作成することで、S3にログを収集する事ができます（CloudTrail Lake / Security Lake等の選択肢については割愛）。
大半のAWSサービスに関するアクションを記録する事が可能です（すべてではありません）。
サポートしているサービスにおいてどのイベントの記録をサポートしているのかはドキュメントに明記されているので、必要に応じて確認してください。
もっと広範な情報を簡単に確認したい場合には弊社ブログの記事も併せてどうぞ。
Config
Configにより、AWSリソースの現在および過去の構成や他のリソースとの関係を記録することができます。
構成の変更操作自体はCloudTrailでも記録されますが、AWSリソースを軸にその変化を確認する事ができるのでCloudTrailと併せて利用する事をおすすめします。
記録を有効化することで、AWSリソースの構成に関する情報をS3に記録することができます。
サポートされるリソースはすべてではないので、必要に応じて確認しましょう。
弊社ブログの記事も併せてどうぞ。
GuardDuty
純粋なアクティビティの収集とは異なりますが、重要なサービスなので言及します。
GuardDutyは脅威検知を行うマネージドサービスです。
CloudTrailのManagement Events / DNS Log / VPC Flow Logs 等に基づいてセキュリティ上のリスクがあるアクティビティを検知してくれます。 なお、GuardDutyを有効化するにあたりこれらのログを別途収集・保存する必要はありません。
具体的にどのような脅威を検知できるかについては定義されたFinding Typesで確認できます。
基本的には有効化するだけで脅威検知を開始する事ができます（ちゃんと運用するには、通知や分析に関する追加の設定を推奨します）。
また、オプション機能として以下のような脅威検知・保護機能が提供されています。
- EKS Protection
- Lambda Protection
- Malware Protection for EC2
- Malware Protection for S3
- RDS Protection
- Runtime Monitoring
- Amazon S3 Protection
弊社ブログの記事も併せてどうぞ。
アクティビティを収集するための機能
次に、数多あるAWSサービスにおけるアクティビティを収集するための機能についてまとめます。
ただし、サービス数があまりにも多いので、（個人的に）一般的に利用する機会が多い以下のサービスに限って機能をまとめます。
- CloudFront
- ELB
- WAF
- RDS
- ECS
- EC2
- VPC
- Route53
- S3
- Lambda
- StepFunctions
- SNS
- Systems Manager (Session Manager)
また、この章においてはCloudTrailで収集できる情報（Management EventsおよびData Events）については基本的に言及しません。
CloudFront
CloudFrontにおいては、以下の様なアクティビティに関する情報を収集できます。
- CloudFront standard logs and real-time logs
- Edge function logs
- CloudFront console reports
CloudFront standard logs and real-time logs
CloudFrontの Distributionに対するアクセスログをS3に収集できます。
ログに含まれる情報はドキュメントで確認できます。
Real-time logsについては完全性が保障されておらず、リクエストへのアクセスの「傾向」を知るために利用することが推奨されているので、ここでは説明を割愛します。
Edge function logs
Lambda@EdgeおよびCloudFront Functionsのログを収集できます。
ログは、CloudWatch Logsに保存されます。
アプリケーションで出力するべきログについては各所で議論されていると思うのでここでは割愛します。
CloudFront console reports
CloudFrontへのアクセスに関する統計情報を確認することができます。
基本的にはアクセスログの情報に基づいているのですが、傾向を手早くつかむのには活用できるでしょう。
ELB
アクセスログ（および接続ログ）
ALB / NLB / CLBではアクセスログを取得する事ができます。
- Access logs for your Application Load Balancer
- Access logs for your Network Load Balancer
- Access logs for your Classic Load Balancer
アクセスログはS3に保存することができます。
各ログのフォーマットはドキュメントで確認できます。
- ALB
- NLB
- CLB
また、ALBに関しては接続ログを取得することも可能になっています。
接続ログが具体的にどの様なものかは以下の記事が参考になると思います。
WAF
WAFを経由するトラフィックに関するログを取得することが可能です。
出力先には、CloudWatch Logs / S3 / Kinesis Firehoseを選択できます。
出力するログは、フィルターしたり指定した項目を削除することも可能です。
ログに含まれる項目や具体例はドキュメントを参照してください。
RDS
監査ログ
各データベースエンジンにおいては監査ログを取得することが可能です。
データベースエンジンによって設定方法が異なり、個人的にはややこしいなーと思っています。
Aurora for MySQL / PostgreSQLの場合、パラメーターグループを利用してログの出力を有効化できます。
- Using Advanced Auditing with an Amazon Aurora MySQL DB cluster
- Using pgAudit to log database activity
監査ログは、CloudWatch Logsに配信することが可能です。
- Publishing Amazon Aurora MySQL logs to Amazon CloudWatch Logs
- Publishing Aurora PostgreSQL logs to Amazon CloudWatch Logs
そのほかのデータベースエンジンに関してもそれぞれサポートされているようです。
- DB2
- MariaDB
- SQL Server
- MySQL
- Oracle
- PostgreSQL
Database Activity Streams
リアルタイムの監視を実現したい場合にはActivity Streamという選択肢もあります。
具体的な構成方法については以下の記事が参考になるかと思います。
イベント通知
RDSで事前定義済の各種イベントをAmazon SNSを介して通知することができます。
具体的にどのようなイベントが定義されているかもドキュメントで確認できます。
- RDS
- Aurora
ECS
Log driver
AWSのドキュメントにおいては、ログの収集方法としてawslogsとFirelensの2つのログドライバーが示されています。
柔軟にログルーティングを行いたい場合にはFirelensの利用を検討してください。
EC2
OS / Middleware / Application logs
EC2インスタンスにおいては、OS / Middleware / Application等様々な要素がログを出力します。 これらのログは一旦ファイルとして出力されます。 CloudWatch Agentを利用する事で、指定したログファイルを収集することができます。
設定ファイルの書き方や具体例はドキュメントを参照してください。
要件次第ではサードパーティのツールを利用するのもいいでしょう（逆に、特に要件がないのであれば技術サポートを得やすいCloudWatchが良いのでは？）。
VPC
VPC Flow Logs
VPC内のトラフィックをVPC Flow Logsとして記録することができます。
ログはCloudWatch Logs / S3 / Kinesis Firehoseに出力することが可能です。
- Publish flow logs to CloudWatch Logs
- Publish flow logs to Amazon S3
- Publish flow logs to Amazon Data Firehose
特に指定しなければDefault format (version 2 fields)が含まれるログが出力されます。 必要であればECSのメタデータなどのフィールドを追加できます。
Route53
DNS Query logging
VPC内で発生したDNSクエリとその応答を記録することができます。 C&Cサーバーとの通信の痕跡などを確認できる可能性があります。
ログはCloudWatch Logs / S3 / Kinesis Firehoseに出力することが可能です。
ログのフォーマットやサンプルはドキュメントで確認できます。
S3
アクセスログ
CloudTrailのData Eventsとは別にS3独自でアクセスログを収集することが可能です。
CloudTrailのログとはフォーマットが異なるので、要件を満たせるいずれかを利用すれば良いでしょう。
こちらの比較表も参考になると思います。
Lambda
アプリケーションログ
LambdaではアプリケーションログをCloudWatch Logsに収集することができます。
ランタイム毎に適切な方法でログを出力してください。
- AWS Lambda function logging in Node.js
- AWS Lambda function logging in TypeScript
- AWS Lambda function logging in Python
- AWS Lambda function logging in Ruby
- AWS Lambda function logging in Java
- AWS Lambda function logging in Go
- Lambda function logging in C#
- AWS Lambda function logging in PowerShell
- Lambda function logging in Rust
StepFunctions
ワークフローの実行履歴
ワークフローの実行履歴をCloudWatch Logsに記録することができます。
SNS
メッセージのアーカイブ
Kinesis firehoseを利用してメッセージのアーカイブを行うことが可能です。
ドキュメントではユースケースも紹介されています。
Systems Manager (Session Manager)
イベント通知
Event Bridgeを利用してセッションの開始・再開・終了のイベントを通知することが可能です。
操作ログ
Session Managerを利用して接続した環境での操作を記録することができます。
収集とは別に考えること
以上のように、様々なレイヤーでAWS上に構築した環境のアクティビティを取得することが可能です。 ただし、何も考えずにすべての設定を有効にすればいいわけではありません。
最後に、これらの設定を実施する際に考慮するべき点を整理してみます。
アクティビティの分析について
収集されたアクティビティは様々なタイミング・契機で参照・分析されます。 しかし、事前に分析する手段を用意しておかないと、いざという時に有効に活用できない可能性があります。 実現したいことや予算に応じて対応を検討しましょう。
いくつか具体的な例を紹介します。
Detective
Detectiveを利用する事で、セキュリティ的に疑わしいアクティビティの根本原因を調査・特定を支援することができます。
GuardDutyで検出したイベントを調査する際、Deectiveを事前に有効化しておく必要があります。
Athena
S3に保存されているログファイルのうち、適切に構造化されているものはAthenaを利用して分析することが可能です。
分析する際にはテーブルを作成する必要がありますが、AWSサービスは生成するログに対してはその方法がドキュメントに記載されています。
Opensearch Service
OpenSearch Serviceを利用したログの可視化を実現するソリューションも提供されています。
データの保護
悪意を持った攻撃者は、各種アクティビティが記録されたログファイルを削除することで問題の発見・調査・復旧等を妨害するでしょう。
そのため、以下の様な対策を検討すると良いでしょう。
- データの上書き・削除権限やIAMの管理権限の最小化
- Permission boundaryの活用
- Resource based policy（S3のバケットポリシーなど）の活用
- S3 Object Lockの活用
CloudWatch Logsに配信されたデータをS3等で保護したい場合には、サブスクリプションフィルターを利用するとよいでしょう。 配信先としてKinesis Data Stream / Kinesis Data firehose / Lambdaをサポートしていますが、Firehoseを利用するのが簡単だと思います。
コストの最適化
アクティビティの収集を行うことで、ストレージにデータを保存したり、保存するまでの処理でコストが発生します。
アクティビティの多い大規模なワークロードほどコストが無視できなくなってしまうので、不必要なコストが発生しないよう考慮する必要があります。
ログの保存期間
適切なログの保存期間については、その根拠を明確にするのはまとまった情報が少なく非常に困難です。 とはいっても、無期限に保存するのもお金の無駄です。
以前は、IPAが2016年に公開した「企業における情報システムのログ管理に関する実態調査」なる資料にまとまった情報が記載されていてとても参考になったようなのですが、現在は参照できなくなってるようでした。
- 企業における情報システムのログ管理に関する実態調査
- 記載されたURLにアクセスすると、
あれこれ探したところ、国立国会図書館がアーカイブしているのを発見しました。
ここで公開されている資料の「表 4-2： ログ保存期間の目安」が目安になるでしょう。 ただし、資料自体は2016年に公開されたものなので、法改正などで現状との乖離がある可能性もあります。 必要に応じて一次資料を確認しましょう。 以下のブログ記事も非常に参考になります。
S3のストレージクラス
S3では様々なストレージクラスを提供しており、それぞれで保存のコストや読み書きのコストが変わってきます。
様々なログファイルのうち、何も問題が無ければ1度もアクセスされないものもあれば、分析のために定期的にアクセスされるものもあるでしょう。 運用の実態に合わせて選択してみてください。
Storage Lensを利用してアクセス頻度の少ないバケットを特定したり、ライフサイクル管理機能を利用してストレージクラスを自動的に移行する事が可能です。
- Using Amazon S3 Storage Lens to optimize your storage costs
- Example 3: Tiering down storage class over an object's lifetime
CloudTrailで収集するData Events
CloudTrailでData Eventを収集する際、Advanced Event Selectorを利用して収集対象を細かく指定する事ができます。
機密情報を扱うイベントに限定するなど、必要な対象を限定することでコストを最適化できるはずです。
Configの配信頻度
従来のConfigでは継続的な構成変更の記録のみをサポートしていたため、運用次第ではConfigのコストが高額になる場合がありました。 現在は日次での記録をサポートしており、要件次第ではコストを削減できる可能性があります。
AthenaのPartition Projection
Athenaの料金はスキャンするデータの量に比例します。 時間の経過と共にログの量が増えることでクエリの料金が増加してしまう可能性があります。
AthenaのPartition Projectionを利用する事で、パーティショニングによるスキャンデータの削減 / パーティショニングの自動化を実現できます。
まとめ
AWS上に構築されるワークロードは様々なレイヤーの様々なコンポーネントが連携して動作しています。 AWSではそれぞれの要素でアクティビティの収集をサポートしています。
アクティビティの収集に関する設計を行うにあたっては、ワークロードに対してどのようなアクセスが行われ、その際にどのようなデータが扱われるのかを理解した上で重要なアクティビティについては記録をするとよいでしょう。 また、通常のユースケースだけで無く、悪意を持った攻撃者がどのような方法・何を狙って攻撃を試みるのか考え、それを検知・防御するためには何が必要かを考えてみる必要もあるでしょう。
とは言っても、セキュリティに対する投資にも限度がありますので、コストに関しても意識する必要があります。
考えることが多く、かつ正解が1つじゃないので本当に難しいですが、チョットずつ改善できるとよいのではないでしょうか。
現場からは以上です。
1
