AWSをいじり倒す(9.CroudTrail、Athena)
前回からの引き続きで、CroudTrailを使ってVPCエンドポイントを使ったS3へのアクセス証跡を確認してみる
参考にしたのはこれ
S3のVPC Endpoint経由でアクセス出来ているか否かの確認 – Publicサブネット編 – サーバーワークスエンジニアブログ
CroudTrailは有効化しないとログ残らないのかな、と思っていたが
特に設定の必要はなく常時ONになっているようだ。
画面を開いてみると早速今までいじくりまわしてきた形跡が見えた。
一部切り取って確認してみる。
眺めていて気付いたのは
・バケットにオブジェクトをアップロードしたログ、というのは残ってない。
・EC2上でCLIによるBucket操作を行うと、ユーザ名はEC2のインスタンスIDになる。
（黒塗りのところはAWSコンソールから操作したので自分のユーザIDが表示されている）
という点。つまり、何でもかんでもCroudTrailに残るわけではないので、事前に目的のログが保存されるかどうかは確認しておかないといけないし、EC2に誰がアクセスしたかを別途把握する仕組みがないと追えなくなる。
具体的には、S3のオブジェクト操作ログは、
のようにオブジェクトレベルのログの記録を有効にする必要がある。
また、EC2のログはClowdWatch logsと連携させてログ記録+監視できる。
AWS構成パターン（CloudWatch Logs/EC2ログ管理）
このように調べたら何らかの対処法は出てくるけど、この辺は手探りで設定していくと検討漏れが出ること間違いなしなので、構築ノウハウを記載した書籍等を読んで所謂ベストプラクティスなやり方を身に付けた方が良さそうだ。
資格対策本ではこの辺はカバーできないなぁ。
さて改めて、
・S3にエンドポイント経由のアクセスができているかどうか
・ついでにオブジェクトレベルのログ記録ができるかどうか
の２点を確認することにする。
S3にエンドポイント経由のアクセスができているかどうか
エンドポイントのない状態でバケット作成・削除→エンドポイント作成→バケット作成・削除のログ。
エンドポイント作成前のCroudTrailのイベント情報
ログ詳細を頑張って見なくても、発信元IPがパブリックIPになっているので、
これでもう十分インターネット経由ってわかりそう
エンドポイント作成後
発信元IPアドレスがローカルになっている。
やはりこれだけでちゃんと機能しているとわかってしまった。
寂しいのでログ詳細も見てみると
エンドポイントなし
エンドポイントあり
vpnEndpointIdってのが増えていることがわかる。
通信時間に大した差がないのは前記事の通りだが、
エンドポイント経由かどうかで料金が変わってくるので、
エンドポイント設定後は一度ぐらいこのログを見て安心した方が良いと思う。
オブジェクトレベルのログの記録
このオブジェクトレベルのログというのは
今まで見ていたイベント履歴にログが増えるわけではなく、
証跡情報として指定したS3バケットに保存される形式になるようだ。
まずはログ保存用のバケットをサクッと作る
そしてログ保存の設定。
CroudTrailの証跡の作成から
証跡情報の作成
証跡名は適当に。
別リージョンからアクセスすることはないので、
全てのリージョンに→いいえ
管理イベントはとりあえず全部記録したいので「すべて」「はい」
Insightsイベント
書き込み管理APIの異常な呼び出しボリュームとはいったい
CloudTrail Insights の発表: 異常な API アクティビティの特定とそれへの対応 | Amazon Web Services ブログ
スムーズに実行されている場合のログエントリは、さながら工場で安定して響く安心感のある機械音のようなものです。しかし不具合が発生した際には、その音が邪魔になりどの機器に不具合があるのかが聞き取りにくくなります。ログデータの量が膨大になる可能性があるような大規模なソフトウェアシステムでも、同じことが言えます。その記録を精査して実用的な情報を見つけるのは骨が折れる仕事です
ぐうわかる・・・
で、その中から異常なアクティビティを発見してくれる機能ってことらしい。
お値段安かったら有効にしてもいいと思うけど
CloudTrail Insights では、Insight タイプごとに分析された書き込み管理イベントについて、100,000 イベントごとに 0.35 USD の料金が請求されます。
100000イベント・・・が多いかどうかはシステムの規模にも依るのでなんとも。
データイベント
記録したいS3バケットを指定することができる。
てっきりS3の設定画面からログ記録の有効化するのかと思ったけど、
CroudTrail側から設定できるみたいだ。
ストレージの場所
ログの保存先S3。さっき作ったS3バケットを指定。
プレフィックスで指定した場所にたまっていく模様
ログファイルの検証とは、ログの改竄がないかどうかをチェックする仕組み。
できた。
S3の設定を見に行くと、オブジェクトレベルのログ記録が有効になっている
さっそくオブジェクト操作をしてみる
確認、削除、アップロードを行った。
念の為、S3のGUIから手動でも適当なファイルをアップロードダウンロードを行っておく
〜１０分後〜
ログの生成を確認。保存先の階層が結構深い
json形式が.gzで保存されているので、ローカルに落として解凍し
中身を見てみる
わかりにくっ！
これはこうやって読むものじゃないな
これによるとAthenaで読むのが良いみたい。
CloudTrailでS3オブジェクトレベルのログを取得してAthenaで閲覧してみた | Developers.IO
そもそもAthenaってなんだ
Amazon Athena とは - Amazon Athena
標準 SQL を使用して Amazon Simple Storage Service (Amazon S3) でのデータの直接分析を簡易化するインタラクティブなクエリサービスです。
めちゃめちゃ限定的ィ！
それだけS3のログはよく利用されるってことなのかな。
早速、CroudTrailのイベント履歴からAmazon Athenaで高度なクエリを実行
保存場所を選ぶ。この時のSQLのクエリは自動で作ってくれている。
ここで自動生成されるAthenaテーブル名は後で使う。
できたようなのでAthenaに移動
Athenaの画面。
まずはSettingsで、Athenaクエリ実行結果を保存するS3バケットを指定。
クエリを作成。
参考記事からコピペしたものをベースに、日付とテーブル名を変更。
テーブル名はさきほど表示されていたものを使用。
左のメニューにも表示されてるけどね。
ところでこのクエリの書き方って、どうやって学ぶんだろう・・・。
自動生成する方法は見当たらないので、いじくってたらだんだん覚えていく系かしら
Save asでクエリを保存。
Run queryで実行してみると・・・
あれ？GUIから出し入れしたログのみが出てきて、
EC2からCLIで操作したログがでてこない・・・。
仕方ないのでログファイルを直接頑張って読んでみることにする
eventNameがDeleteObject・・・これはrmしたときのログだろう。
一方でcpしたときは
UploadPartに
CreateMultipartUploadに
CompleteMultipartUpload
という３種類が出てきている。
みるべきキーワードが分かってきたので、クエリを変更してみる。
GetObject,DeleteObjectに加えて上記の３種イベントを追加。
また、ログに
と書いてあったので、
and useridentity.type = 'IAMUser';
の条件では引っ掛からなくなると思い、削除した。
このクエリの実行結果はこちら。
で、このUploadpartとは、
つまるところ適当に30MBのファイルをアップロードしてしまったせいで
図らずしもこのマルチパートアップロードを行ってしまったらしい
大きなファイルをアップロードするときに分割する機能。
cpコマンドを使うと自動でマルチパートになるんだと。
これは１パートあたり５MB以上、最大１００００パートまでという仕様。
Amazon S3 マルチパートアップロードの制限 - Amazon Simple Storage Service
今回30Mのアップロードは４分割されてるっぽいので、8M前後に勝手に分けられたと推測。ログをよく読むとそれも書いてあった。
これが１つと
これが３つ。
いい具合に分割して送ってくれてたのね。
順番としては
CreateMultipartUpload→Uploadpart*4→CompleteMultipartUpload
なんだろうけど、順番通りログがでてないのは謎。
ログはコンマ0秒以下は残ってないので、仕方ないのかなぁ。
で、小さいファイルならCLIでもPutObjectになるんだよね？
ってことで1KBのファイルを作ってcpしてみる
結果。
無事PutObjectになった。
S3に複数人でファイルやりとりするとなったら、
やっぱ出し入れの情報は見たいし、オブジェクトレベルでのログ確認は必須だろうなぁ
ということでS3の操作から始まって、AWS CLI、VPCエンドポイント、CroudTrail、Amazon Athena、マルチパートアップロードと色々話が広がって勉強になった。
進捗
