私の立ち位置

システムのインフラ運用に携わりつつ、
内部統制についての監査を担当している人
（ITわからないなりにAWSを勉強中）

そも、ログって大切だよね？

みんなわかっていると思うけれどログの保存についてはなんとなーくで実施している人も多いのでは・・・
大切・・・なのはわかるけど・・・
とりあえず保存しておけばいいでしょ感ないですかね。
実際私もそう思っていた時期がありました（ありました）

で、ログの保存で必要なことは？

①必要なログを出力させること
　超大前提。
　今回はAWSのCloudTrailのログを対象としていたのですでに出力されていたけれど、
　ほかにも必要な場合はまず出力させるところから！

②ログにアクセスさせる人を限定すること
　今回の対応範囲。
　改ざん・削除される可能性を考えて、
　システムの運用からは離した人を設定しておくのがベスト( *´艸｀)

③ログの保護
　今回の対応範囲。
　ログを改ざんされたときとかのためにバージョニングとか管理してねって話。

④ログの整合性
　今回の対応範囲。
　ログファイルが変更されなかったかの判断のために検証機能をonにしておけよって話。
　検証でだめ(乂'ω')って出たらアラートが発火するとかすればさらに良い٩( 'ω' )و

結局、どうやったの？

①ログ保存のための専用アカウントを作成する

提供しているシステムを動かしているアカウントとは別の完全に切り離したログ用アカウントを作成。
そこに、ログ管理者用の専用IAMを作成（今回の場合は２人分）した。
ログを閲覧したい場合もあるじゃん！という要望にお応えして、S3へのRead onlyロールを作成。（最小権限の原則）
※ここで設定したログ管理者はシステムを動かしているアカウントの管理者とは全く別にしているのがポイント！
　権限を分散することで職務分掌を図っているのです

②ログ管理者がログ専用S3バケットを作成する

1.（まあほかにできる人いないんですけど）ログ管理者がログ保存用のバケットを作成。
2. 名前はお好きに。
　（と言いつつ変な命名にすると後ろから刺されるので、格納されているログが名前から判別できるようにしておきましょう）
3. バケットのバージョニングを有効に。（意図しない変更があっても戻せるように）
4. バケットポリシーを設定。
　①各アカウントからのPut許可（ないと死ぬ）
　②Readonlyのロールからのアクセス許可（ないと管理者しか見れない）
　③その他必要なアクセス許可
5. ライフサイクルルールを有効に。（設定期間が短すぎると監査とかで死ねるので注意）

③ログ出力先の設定を変更する

各アカウントにログインして変更可能なIAMまたはロールでCloudTrailの出力先を作成したバケットに変更する。
変更の際に「ログファイルの検証」の有効化も忘れずに！

④ログ出力の確認

適当なRead操作をしてログが設定したS3バケットに出力されていることを確認する。

完成！
おわり！
解散！

まとめ的な感想的な

設定自体はやると決めたら案外すぐできてしまうわりにFTRに対応しているぜ( ･´ｰ･｀)ﾄﾞﾔができるので、普通におすすめです。
ログは後から操作内容が追える唯一の手段といっても過言ではありません。超大切です。
さらっとできるこのようなセキュリティ強化もしてみてはいかがでしょうか？

FTRの対応のためにログのセキュリティを強化した話