1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【AWS】「CloudTrail ユーザーガイド」を読んでみた[検出に関するベストプラクティス編]

Last updated at Posted at 2021-02-06

#はじめに
「CloudTrailは良い」という認識は持っているのですが、「使いこなす」レベルには達していないので、ユーザーガイドを読んでみました。
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/awscloudtrail-ug.pdf
このPDF資料が全352ページと中々えげつないボリューム。
AWS認定資格のアソシエイトレベルなら「AWS上のアクティビティ(APIイベント)を証跡として記録してくれるサービス」という理解だけ持っていれば大丈夫だったと思います。
が、CloudTrailマスターになるには道のりは長そうです…。

ということで、ユーザーガイドを読んで得た知見や試したことを書き残していきます。
今回は「セキュリティのベストプラクティス」の「検出に関するベストプラクティス」を読んだので、しゃべりかけるノリで理解した内容を書いてみます。
私自身の解釈含みます!
※わかりやすいかはわからないので、読んだ方ぜひコメントでご意見ください(__)!

#セキュリティのベストプラクティス
紹介するベストプラクティスは全部重要だけど、「これ全部やれば完璧!」てものではないよ。
なので、「自分の環境でも有効な手段かな?」とか「他にやるべきことはないかな?」とか、使う側でしっかり考えていこうね!

#検出に関するベストプラクティス
4つ紹介するよ。
##証跡の作成
まずは証跡(Trails)を作ったほうがよいよ。
CloudTrailてのはあくまでサービス名で、証跡はイベントログを実際に保管するリソースていうイメージかな。
保管先はS3, CloudWatche Logs, CloudWatchEventsがある。
ちなみに、証跡を作らなくてもコンソール上に90日分のイベント履歴は残る。だから一応直近のできごとについては最初から分析できるね。けど、古いものから削除されてくし、情報も限られてるんよね。
全部のイベントを、古いやつも全部とっときたいならちゃんと証跡を作ろう。

あとデータを管理しやすいように、「ひとつの証跡に」「全リージョンと組織管理下の複数アカウントのイベントをぜんぶ記録する」のがおすすめ。
もしリージョンやアカウントごとに証跡が分割されてたらいちいち「どの証跡みるか」を考えないといけなくてめんどくさい。「何かあったらこの証跡を調べればOK」てものがあれば、いざという時安心だよね。
「簡単にできること」は「続けること」や「いざというときに必ず実施できる」ための重要要素だと思うから、意識しときたいね。

S3のイベント通知とかLambdaでログ加工して、特定用途の追加証跡を作るのもクールかもね。

##証跡は「全てのリージョンに適用」しとこう
ちょっとさっきも触れた話題だね。
ユーザー、ロール、サービスから発生するイベントログを全部完璧に取得するために、全リージョンの証跡を取得するように設定しとこう。
ただ、マネジメントコンソールから証跡を作成した場合は、デフォルトで全リージョンイベント取得の設定になるみたいだから、認識しとくだけでよいかも。
※CLIで証跡作る場合は、明示的にオプション指定する必要あるよ!

「全リージョンでの取得」が有効になってるかを、AWS Configのルールで検知することもできるよ。

##信じられるCloudTrailログでいてもらうには
人から一度でも嘘をつかれると、もうその人のこと信じられなくなると思う。
ITの世界でも「嘘をついているかもしれない」ログは役に立たない。知らない人が変更してたりとか、削除したりとかされるとね。
CloudTrailで「ログファイルの検証設定」をしとけば、「バレずにログを改ざんしたりすること」ができなくなる。
「信じられるCloudTrail」でいてもらうために、設定を有効化しておこう。
「変なことをされてること」に気付けたら、「入口のセキュリティを再確認する」とか「疑わしいログは処分する」とか色々アクションに移せるよね。

##CloudWatch Logsとのコラボ
CloudWatch Logsは、色んなAWSサービスのログを収集して監視できるクールなサービス。
CloudTrailのログを送り込むこともできるんよ。
特定イベントを監視して、アラートを受信するなんてこともできる。
例えば、コンソールへのサインイン失敗とかね。連続的にたくさんサインインの失敗が発生してたら、ちょっと心配よね。
気付いた後、仮にそのユーザにMFA未設定だったら、「これを機に設定しとこう!」とか「そもそもMFA設定義務化しよう!」という行動に移すとかね。
その他にも主要なセキュリティとかネットワークに関するイベントを監視できるみたい。

#感想
CloudTrailの基本機能は「AWS上のAPIイベントを記録する」ってシンプルなものだけど、「じゃあどうやって活用する?」を考え出すと奥深い。
Lambdaでデータ加工検討したりとか、CloudWatch Logsと組み合わせて検知の仕組み作ったりとか。
そもそも活用するには、セキュリティ対策に必要な基本の考えを理解する必要があったりとか。
AWSサービスを勉強すると、IT業界にどんな分野と概念があるのかを勉強するきっかけになって、すごく知見が広がるし面白いなーと思います。

次は、予防のベストプラクティスについて同じことしてみます。
あとは具体的な設定方法とかケーススタディ的なこととか書いていきたい。

#参考情報
AWS CloudTrail ユーザーガイド Version 1.0
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/awscloudtrail-ug.pdf
※機械翻訳ベースで、正しく訳されていない部分もあるので、腹落ちしない部分は原文で読むことをおすすめします。

Security Best Practices in AWS CloudTrail
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/best-practices-security.html

AWS Well-Architected フレームワーク > フレームワークの 5 本の柱 >セキュリティ
https://wa.aws.amazon.com/wat.pillar.security.ja.html

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?