why
リカバリーのために、AWS リソースへの操作履歴を見れるようにしたいから。
CloudTrail とは？
AWS リソースを変更した時に記録をするサービス。
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
公式によると、
- ユーザー ( 人間がログインして動かす )
- ロール ( ECS タスクや LAMBDA 関数の実行 )
- AWS のサービス ( よくわからない )
でによって実行されたアクションが記録できると書いてある。
アクションとは EC2 インスタンスなどのリソースの作成や変更などと解釈した。
実際に作成する
CloudTrail のページから Create Trail ボタンを押す。
最初の 1 つは詳細設定が省かれるので、削除して新しく作る。
下記の設定で作る。
- 名前: all-history
- 保存場所: 新しい S3 バケツ
- バケツ名: all-history-by-cloudtrail
- KMS キーエイリアス: all-history-kms
- ログファイルバリデーション: true
- 重複するログを隠してくれると予想。
- SNS 通知: false
- ログが流れるたびに Slack や Twitter に post できると予想
- CloudWatch ログ: false
- CloudTrail で見れれば十分と考えたため。
次に下記の、記録するイベント詳細を決められる。
- イベントタイプ
- 管理イベント: true
- データイベント: false
- 異常なイベント: false
- 管理イベント
- API アクティビティ: Read and Write
- KMS イベントを除外: false
- RDS API イベントを除外: false
AWS リソースの管理ログだけ残したかった。
Read までつけるとログが多すぎるかもしれない。
検証のためにつけた。
これで Create Trail する。
KMS キーエイリアスとは？
KMS キー名のとこらしい。
KMS キーとは？
CloudTrail の作成ではそんなに意識しなくて良さそう。
https://dev.classmethod.jp/articles/10minutes-kms/
KMS キーとはデータを暗号化する AWS 用の鍵。
マスターキーとデータキーがある。
マスターキーは
- データキーを暗号化できる
ローカルに DL できない
実際のデータを暗号化できる。
ローカルに DL できる。ローカルで使う。
実際の運用は
- マスターキーA でデータキーA を作る
- データキーA で実際のデータA を暗号化する。
- 暗号化されたデータキーA と、暗号化されたデータA が手に入る。
- データキーA を削除する
- マスターキーでA 暗号化されたデータキーA を復号する
- データキーA で復号化されたデータA が手に入る。
このように使えると解釈した。
実際にはこのような操作になるらしい。
検証してみる
KMS キーの作成ログはあるのを確認した
EC2 の作成、削除を実際にしてみた。
すると
- TeminateInstanses
- RunInstances
これらのイベントが観測できた。
リンクを辿ると、削除されたインスタンスに飛べた。
まとめ
AWS でリソースの作業ログを残すには CloudTrail を作成する。
設定としては管理イベントの Read Write があれば十分。
以上。
今後やりたいこと
- SNS 通知。Slack
- 異常検知。( 検証が難しそう )
- KMS キーの本格的な運用
Top comments (0)