本文の内容は、2022年11月2日にBrett Wolmaransが投稿したブログ（https://sysdig.com/blog/cloud-log-management-cloudwatch-vs-cloudtrail/)を元に日本語に翻訳・再構成した内容となっております。
クラウドのログ管理はオンプレミスと何が違うのでしょうか？答えは簡単なようですが、CloudTrailとCloudWatchなど、いくつかの要素が絡んできます。
この記事では、最も重要な違いをいくつか取り上げ、AWS CloudTrailとCloudWatchの具体的な例について掘り下げて説明します。
クラウドログとは何か？
例えば、クラウドプロバイダーであるAWSでApacheウェブサーバー（新しいCVE-2022-42889に対する脆弱性がないよう、アップデートされているかどうか確認することを忘れないでください）を運用しているとします。このサーバーがWebリクエストに失敗すると、マシンの/var/log/httpd/error_logにログが記録されます。このログエントリは、Apacheが実際の環境に配備されていたとしても発生します。 したがって、私たちはクラウドのログではないものを扱っているのです。 一方、クラウドのログは、クラウドサービスから直接来るものです。クラウドにしかないものが、真のクラウドログと想定されるものです。 クラウドログを定義するために、この例では、’Brett’というIdentity and Access Management (IAM) ユーザーが、AWS CLIを使ってAmazon EC2 StartInstancesアクションを呼び出している様子を示しています。インスタンス名 ’i-ebeaf9e2’ の以前の状態が ’stopped’だったため、ec2-start-instancesコマンドを使用しています。{"Records": [{
"eventVersion": "1.0",
"userIdentity": {
"type": "IAMUser",
"principalId": "EX_PRINCIPAL_ID",
"arn": "arn:aws:iam::123456789012:user/Brett",
"accessKeyId": "EXAMPLE_KEY_ID",
"accountId": "123456789012",
"userName": "Brett"
},
"eventTime": "2014-03-06T21:22:54Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "StartInstances",
"awsRegion": "us-east-2",
"sourceIPAddress": "<External-IP>",
"userAgent": "ec2-api-tools 1.6.12.2",
"instanceId": "i-ebeaf9e2",
"currentState": {
"code": 0,
"name": "pending"
},
"previousState": {
"code": 80,
"name": "stopped"
}
}]}}
}]}
アクションの結果、現在の状態は ‘pending’ になっています。
ログはどのように管理すべきでしょうか？
ハイレベルでは、この3つの処理をどのように実装するかを決めなければなりません。- ログを作成する
- ログを送信する
- ログの保存（ローテーション、削除を含む）
ベストプラクティス
AWSのログ管理のベストプラクティスは、大きなトピックです。例えば、PCI（Payment Card Industry）規格に従うと、ログを少なくとも1年間は保存しなければなりません。ベストプラクティスをここで紹介する余裕はありませんが、Logglyの人たちは素晴らしいリストを持っていますし、AWSはセキュリティイベント専用のリストも管理しています。 ベストプラクティスをいくつか紹介します：- ログをリモートで送信する場合、TCPと暗号化を使用する。
- AWS CloudTrailでは、90日以上のログが必要な場合、Trailを作成しなければなりません。
- マイクロサービス環境では、コンテナにSSH接続して何が起きているかを確認することは現実的ではないので、ログが私たちの目になるのです。
クラウドのログ管理における新たな課題
クラウドは新たな課題をもたらします：- マルチクラウド：ログの種類や機能によって異なるログを扱うことになります。
- クラウドのログは膨大になる可能性があります。中規模のクラウド環境であっても、1日あたり数百万件のログイベントが発生する可能性があります。膨大なログ量に関連するコストを抑制する戦略は、ここでの検討事項の1つです。もう一つの解決策は、クラウドの検出と応答に実行時検出を追加し、データの大きな湖を保存しないようにして、アラートプロセスを高速化することです。Falcoプラグインはその一助となるかもしれません。
- セキュリティの懸念ログは攻撃者にとって非常に貴重なターゲットです。重要な情報を盗むため、あるいはログを削除することで痕跡を隠す方法を探すためです。
パブリッククラウドのログ取得サービス比較
主要なパブリッククラウドプロバイダーは、自社のクラウド上で行われたすべての変更を記録するという、非常に重要な監査ログ機能を備えています。これは、データセンター内のすべてのデバイスのすべての変更に関するログであると考えることができます。これがなければ、変更内容を記録することはできません。 仮想マシン、セキュリティ、データベース、その他多くのサービスに関するログが存在します。 主要なクラウド・プロバイダーはすべて、仮想マシン用のログ・エージェントを提供しています。 例えば、AWSはCloudWatchエージェントを提供しており、プロビジョニング時のUserdataを含むいくつかの手法を使ってEC2インスタンスに注入することができます。 Google Cloud、Microsoft Azure、AWSで利用できるログの一例を次の表に示します：| Google Cloud | Microsoft Azure | Amazon Web Services | |
| 監査ログサービス名 | Cloud Audit Logs | Azure Activity Logs | AWS CloudTrail |
| その他のログ |
|
|
|
AWS CloudTrail vs. CloudWatch
AWS CloudTrailとは？
AWS CloudTrailは、AWSアカウントの運用・リスク監査、ガバナンス、コンプライアンスを実現するためのAWSサービスです。 ユーザー、ロール、またはAWSサービスによって行われたアクションは、CloudTrailのイベントとして記録されます。イベントには、AWSマネジメントコンソール、AWSコマンドラインインターフェース、AWSソフトウェア開発キット（SDK）およびアプリケーションプログラミングインターフェース（API）で実行されたアクションが含まれます。
CloudTrailは、AWSアカウントでデフォルトで有効になっています。CloudTrailコンソールでEvent historyにアクセスすると、最近のイベントを簡単に確認することができます。
AWSアカウントのアクティビティやイベントを継続的に記録するためには、トレイルを作成します。さもなければ、90日後にデフォルトのS3バケットから削除されます。そのため、アカウントの脆弱性や不正利用をいち早く検知し対応することと、問題の原因を検知するためのログが消えないようにすることが重要です。
Amazon CloudWatchとは？
Amazon CloudWatchはパフォーマンス監視サービスですが、それだけでなくいくつかの芸当が可能です。CloudWatchには、異常な動作を検出する機能、ログを可視化する機能、アラームを設定する機能もあります。しかし、この拡張機能のうち、すぐに利用できるものはほとんどないことを覚えておいてほしい。これを動作させるには、AWS Lambdaでコードを書き、Amazon EventBridgeでトリガーを設定する必要があるかもしれません。
出典: https://aws.amazon.com/cloudwatch/
デフォルトでは、AWS CloudWatchは、AWSリソースとアプリケーションのパフォーマンスを監視するために存在します。AWS CloudWatchは時間経過とともにメトリクスをグラフ化し、セキュリティアラートを取得する方法としてはアウトオブボックスではありません。もしアラートが必要なら、メトリクスに基づいて自分で作成する必要があります。そして、個別のイベントに対するアラートを作成したい場合、ゼロ以外のメトリクスを生成し、それをキーにする必要があります。
クラウドのログから事前に特定できる脅威にはどのようなものがありますか。
検知すべきイベントの種類に応じて、ある種のクラウドログ管理サービスを利用することになります。今回の例では、「S3バケットを公開する」というシンプルなイベントを見つけるために、Cloudtrailを設定してみましょう。public s3 bucket misconfigurationはもう関係ないと思うかもしれませんが、お許しください。 実際、このクラウドのミスは今でも非常に関係があります。例えば、広く知られているs3バケットの公開に関するインシデントを追跡するためだけに作成されたGitHubプロジェクトや、公開されたクラウドストレージを見つけるための検索エンジンを備えたウェブサイトがあります。 では、この例で説明しましょう。まず、バケットを公開します。ありがたいことに、悲惨な警告と、間違えてこれをしないように2回クリックさせるフローが含まれています。
数分以内に、このイベントがCloudTrailに表示されます：
"requestParameters": {
"publicAccessBlock": "",
"bucketName": "brett-public-test-bucket",
"PublicAccessBlockConfiguration": {
"xmlns": "http://s3.amazonaws.com/doc/2006-03-01/",
"RestrictPublicBuckets": false,
"BlockPublicPolicy": false,
"BlockPublicAcls": false,
"IgnorePublicAcls": false
},
ここでは、”BlockPublicPolicy” と他のパラメータが “false” に設定され、このバケットがインターネット上で公開されていることがわかります。
このシナリオでは、CloudWatch はバケットの大量利用を検知するのに役立つかもしれません。しかし、Bucketがプライベートからパブリックに変更された場合は、あまり役に立ちません。
CloudWatchとCloudtrailでイベントを見つける
CloudWatchでこのイベントを見つける方法がいくつか見つかりましたが、簡単なボタンはありません。 CloudTrailをCloudWatchと統合する複雑な方法として、henryやs3-public-alertsなどがあります。しかし、これらのプロジェクトはしばらく更新されておらず、うまく動作させることができませんでした。
Amazon CloudWatchでパブリックS3バケットを検出するための複雑なビルド
AWSのこの一連の手順を忠実に実行したところ、バケットのアラートを確認することができましたが、AWS Configでのみ確認することができました。また、このブログ記事は少し古く、その後AWSのサービスもアップデートされているので、もしかしたらそのせいで課題があったのかもしれません。
AWS Configのスクリーンショット
もし、私たちのシナリオが全く違うものであれば、私たちの主なクラウド検知・対応ツールはCloudWatchになるかもしれません。
例えば、攻撃者がEC2マシンを制御し、クリプトマイニングを開始したとしましょう。この攻撃を検知する方法は、CPUの使用率が急激に上昇するため、その割合から判断する必要があります。この場合、cloudtrailはあまり役に立ちませんが、CloudWatchは貴重な情報を与えてくれます。
AWS内の他のサービス、例えばGuardDutyなども使っています。
したがって、直面している脅威によって、どのサービスが最も検出に適しているかを明確にする必要があります。
便利なツール
この記事を書いている間、私たちは当初非常にシンプルなイベントだと考えていた、「誰が、何を、いつ、どこで」誰かがS3バケットをプライベートからパブリックに変更したかを見つけることに焦点を当てたいくつかの便利なツールを使って実験してみました。| 説明 | プロジェクトや記事へのリンク |
| AWS Configを使ったAmazon S3バケットの監視とパブリックアクセス許可への対応方法 | https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/ |
| List of S3 Hacks | https://github.com/nagwww/s3-leaks |
| Leaky Bucket Finder | https://github.com/willh/henry |
| AWS S3バケットやオブジェクトが公開された場合のアラートについて | https://github.com/cleancloud/s3-public-alerts |
CloudTrail vs. CloudWatch まとめ
AWS CloudTrailとCloudWatchを比較すると、どちらもロギング機能として説明されることがありますが、全く異なるものであることがわかります。また、両者を連携させることは可能ですが、多くの場合、追加設定が必要になります。 クラウドのログ管理は、従来のデータセンターとはかなり異なることがあります。例えば、クラウドにあるようなデータセンター全体の単一の監査ログは存在しません。意外な制約がいくつかあります。 クラウド内で得られる可視性は、ログをどのように管理するかに完全に依存するため、優先的に管理する必要があります。各クラウド・プロバイダーは多くの種類のログを提供していますが、その中でも最上位に位置するのが監査ログです。これは、セキュリティ上の問題を発見するための重要な場所でもあります。また、ログを保存する際の戦略も重要です。リアルタイムに近いオプションは、悪意のあるイベントの早期クラウド検出と対応に役立つからです。 クラウドのニーズでログを取ることは、クラウドで行う他のすべてのことと同様に重要です。間違った方法で行うと、混乱を招く可能性があります。しかし、うまくやれば、クラウドはログのベストプラクティスから大きな利益を得ることができます。これらのサービスの構成と管理方法を知りたい場合は、Sysdigがクラウド・セキュリティ・ポスチャー・マネジメント（CSPM）の向上を支援します。以下のリソースでより深く掘り下げてみてください。
- Sysdig SecureでAWSのセキュリティサービスを改善する
- SysdigでAmazon EC2のセキュリティを確保する方法
- SysdigでAWS Route 53を保護する方法
- SysdigでAWS RDSのセキュリティイベントを監視する
- Amazon GuardDutyとSysdigでマルウェアをハントする