kdnakt blog

hello there.

AWS CloudTrailはすべてのAWS APIコールを記録するわけではない

AWS CloudTrail(クラウドトレイル)は監査向けサービスで、AWS上でのユーザーアクティビティとAPI使用状況を追跡してくれる。その程度の理解で使っていたところ1時間ほど時間を無駄にしてしまったので、気づいたことをまとめておく。

 

 

[AWS CloudTrailとは]

aws.amazon.com

 

公式サイトの説明によれば、AWS CloudTrailは「AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービス」である。

 

AWSアカウントのAPIコールがS3上のログファイルに記録され、誰が、いつ、どのような操作を行ったかを後から追跡することができる。また、CloudWatch Logsと連携することにより、特定のAPIコールが実行された際に通知を行うこともできる(とはいえAPIコールからログの保存まで15分程度のタイムラグがあるので注意が必要である)。

 

CloudTrail自体の利用料金としては基本的に無料で、別途連携先のS3やCloudWatch Logsの利用料金が課金される。

  

[DynamoDBのCloudTrail対応イベント]

AWS CloudTrailはAWS認定試験でも、監査関連の問題で時折登場するサービスだ。監査用のサービスだから、きっとすべてのAPIコールを記録するのだろう、とぼんやり思っていた。

 

ぼんやりしていたので、先日DynamoDBのデータが書き換わっていることによるエラーが発生した際に、いつからエラーが発生する状態だったのかを調査しようとして、それができないことに気づき愕然とした。

AWSマネジメントコンソールのCloudTrailの画面からは、APIコールについてイベント名を指定して検索することができる。DynamoDBのデータを書き換えているのだから、とりあえず「UpdateItem」イベントか「PutItem」イベントだろうと思い、それぞれの文字列を入力して検索してみるものの、一向に検索結果が表示されないのだ。

 

不思議に思い検索してみると、下記のドキュメントにたどり着いた。

docs.aws.amazon.com

 

CloudTrailに記録されるDynamoDBのAPIコールとして、「CreateTable」や「ListTables」といったテーブル操作のAPIがリストアップされている。一方で、ScanやQuery、GetItemやUpdateItemといった個々のデータを操作するAPIについてはCloudTrailのログの対象外となっているようだ。

 

別の資料として、AWSサービスを詳しく説明してくれるBlack Beltセミナーの解説ブログにも同様のことが記載されているのも見つけることができた。

aws.typepad.com

Q2. CloudTrailで吐き出されないサービスなどは何かありますか?

A2. 下記がCloudTraiがサポートするサービスになります。

http://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-supported-services.html

また上記に記載があるサービスでも、取得しないAPIもございますので、一度ご確認下さい。たとえばCloudWatchはCloudTrailがサポートしていますが、下記APIのみの取得となります。

http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/logging_cw_api_calls.html

 

[CloudTrailのデータイベント]

aws.amazon.com

FAQのページをよく読むと、「データイベント」に関する項目がある。

 

データ自体に対する操作のログは大量になり課金額が見通せないことから、デフォルトでは無効となっていること、S3の個々のオブジェクトに対するAPIコールと、Lambda関数の実行に関するログのみが保存の対象であることが書かれている。

 

残念ながら、2019年5月時点ではDynamoDBはデータイベントの対象ではないらしい。

 

[DynamoDBのデータへのアクセスを記録するには]

とはいえデータの変更についても、監査を受ける上で、誰がいつどのようにして行ったかを記録しておきたいというニーズは、それほど不自然ではないだろう。

 

どのように解決されているのだろうか、とGoogleで検索してみると、AWSのディスカッション・フォーラムに次のようなスレッドがあった(閲覧にはAWSアカウントへのログインが必要である)。

Access logs for Dynamodb

 

このスレッドの質問の概要としては、「DynamoDBに保存されている機密情報へのアクセスを記録したいがCloudTrailが対応していないが良い方法はないか」というものだった。

この質問が投げられたのは2015年で、その後何度かこの機能のリクエストが出されてはいるようだが、2019年5月末現在は実装されていない。

スレッドの後半では、Envoyなどのミドルウェアを利用して、独自にDynamoDBのデータへのアクセスを記録するプロキシの実装が提案されていた。

www.envoyproxy.io

 

確かに、プロキシを動かすEC2インスタンスやコンテナにIAMロールを割り当てて、DynamoDBへのアクセスをプロキシ経由のみに限定することで、以下のように監査対応を実現することができそうな気がする。

  • DynamoDBへのアクセス権が他のロールやユーザーに割り振られていないことをCloudTrailで確認する
  • プロキシに割り当てられたIAMロールが、他のEC2インスタンスなどで利用されていないことをCloudTrailで確認する
  • DynamoDBのデータへのアクセスが適切かどうかはプロキシで記録したログで確認する

 

でもこのプロキシ実装するとなると、相当な苦労が予想される。2018年のre:Inventで発表されたTransactGetItemsみたいにDynamoDBのAPIが増えると、その分プロキシの実装を追加する必要があるからだ。

そういった苦労をするくらいなら、DynamoDB Streamsを利用してDynamoDBのデータの変更履歴をS3バケットに保存し、このS3バケットのデータイベントを有効にしておく、とかでしのぐ方がマシかもしれない。

 

[まとめ]

  • AWS CloudTrailを利用すると、AWSアカウントの監査を行うことができる
  • AWS CloudTrailはすべてのAWSサービスのすべてのAPIコールを記録してくれるわけではない
  • DynamoDBの場合、CreateTableなどのテーブル操作系APIコールは記録される
  • 一方で、ScanやGetItemなど個々のデータを操作するDynamoDBのAPIコールは記録されないので、DynamoDB Streamsを利用するか、独自のミドルウェアを実装する必要がある

 

なんだかこんなレベルでプロフェッショナルと名乗って良いのか不安になってきた。もっと勉強するぞ。 

kdnakt.hatenablog.com