CI部 佐竹です。
今回は「Macie を使うと CloudTrail の利用料が意図せず増加して驚いた」という話です。皆さんが同じハマり方をしないように、ブログに残しておきます。
Amazon Macie
今回は Amazon Macie について記載します。Amazon Macie は、S3 をセキュアに使うにあたり、非常に有効なサービスです。Macie は S3 に保存されているファイル群をそれぞれ分析し、「機密情報が含まれているかどうか」を検知して教えてくれます。実際に Amazon Macie を検証のため、個人検証アカウントで有効にしてみました。
有効化するだけで、現在の S3 バケットの状況が一覧で表示されます。これだけで Public Access がないことが一目でわかりますね。
ただし、有効化するだけでは S3 Object に対する機密情報の検査（検出）は行われません。
Macie の利用料
以下で簡単に利用料について説明します。
以下の利用料は Macie を有効化すると継続的に請求される利用料です。つまりバケット数に応じて $0.1 毎月請求されるのみですので、非常に低コストです。
| セキュリティとアクセス制御について評価したバケット | 料金 |
|---|---|
| 最初の 30 日間に評価したすべてのバケット | 無料 (0.00 USD) |
| 最初の 30 日後に評価した S3 バケットの数/月 | S3 バケットあたり 0.10USD |
それに加えて、検出ジョブに対して利用料が発生します。これはジョブを実行しない限りは請求されません。
| 機密データ検出のデータ処理量 | 料金 |
|---|---|
| 最初の 1 GB/月 | 無料 (0.00 USD) |
| 次の 50,000 GB/月 | GB あたり 1.25USD |
| 次の 450,000 GB/月 | GB あたり 0.63USD |
| 500,000 GB/月を超えた場合 | GB あたり 0.31USD |
詳細は以下をご覧ください。
sensitive data discovery jobs
S3 に保存されている各ファイルに機密情報があるかどうかを検査する には sensitive data discovery jobs の実行が必要になります。先にご紹介した通り、ジョブを実行することでデータの処理容量に対して利用料金が発生します。
ジョブを作成するには「Macie マネジメントコンソール」の「Create job」を押下して進めます。
Jobで最初に選択するのが、どのバケットを検査するかです。ここで全バケットを一気に検査することもできます。実際、私は全てのバケットを選択して実行してみました。
CloudTrail の利用料が突然増加
サーバーワークスの社内では、Cost Anomaly Detection の他に独自実装の「marusa」と言われるコスト管理ツールが動作しています。
※Cost Anomaly Detection については以下をご覧ください
この marusa によって、私の個人検証アカウントで利用料が急激に増加していることに気付きました。
Cost Explorer で分析をしてみると、Macie の利用料だけではなく、CloudTrail の利用料が大きく増加していることがわかりました。
Macie の利用料が高額になるのは理解していましたが、何故 CloudTrail の利用料が増加するのでしょうか？
CloudTrail 利用料増加の理由
結論からお伝えすると sensitive data discovery jobs は CloudTrail の利用料を増加させる原因になります。
その理由ですが sensitive data discovery jobs では、指定した S3 バケット内に保管されている全てのオブジェクトを検査するため、全てのオブジェクトを一度 Get object します。通常 S3 Object 単位のログ（GetObject, DeleteObject や PutObject という API operation）は CloudTrail に保存されませんが、これを保存するように設定で有効化することができます。
上図の設定画面で「Data events」にチェックを入れることで有効化されます。詳しくは以下のドキュメントも合わせてご覧ください。
つまり私の検証アカウントのように CloudTrail で S3 の Data event を有効化している場合、かつ Macie の discovery job に CloudTrail のバケットを指定した場合には、CloudTrail の過去全てのファイルを Get したという記録が CloudTrail に書き込まれてしまうため、CloudTrail の利用料を増加させてしまうことになります。
Athena での利用料分析
実際にどれくらい Macie の discovery job によって CloudTrail の履歴が発生したのか追いかけてみました。
クエリ（SQL）の例は以下の通りです。
SELECT count(eventname) AS count,
eventname
FROM "default"."cloudtrail_logs_apnortheast1_202105"
WHERE useridentity.arn='arn:aws:sts::XXXXXXXXXXXX:assumed-role/AWSServiceRoleForAmazonMacie/classifier-content-fetcher'
GROUP BY eventname;
XXXXXXXXXXXX は AWS アカウントの ID のため伏せています。AWSServiceRoleForAmazonMacie によってコンテンツがフェッチされているログをカウントしました。
クエリの結果から上画像の通り GetObject、GetObjectAcl、HeadObject がそれぞれ154万回以上実行されたことがわかりました。これはつまり S3 Bucket にオブジェクトが154万ファイル以上設置されているということです。
CloudWatch で S3 バケットに配置されているオブジェクトの数を確認する
特定の S3 バケットに保持されているオブジェクトの個数は、CloudWatch を見ることでおおよその数が確認できます。
NumberOfObjects の推移を確認すると、CloudTrail に利用している S3 バケットには 154万程度のファイルが保存されていることがわかりました。
これにより Amazon Macie の sensitive data discovery jobs 実行時 CloudTrail 用のバケットを選択していたため、合計463万以上の S3 Data event (GetObject、GetObjectAcl、HeadObject) が発生し、その利用量が請求されたことの裏付けが取れました。
余談：CloudTrail の検査結果
これは余談ですが、CloudTrail 用のバケットを検査した結果、56個の SensitiveData:S3Object/Financial が High で発見されました。
これは Credit card number no keyword に値するとのころで、以下の条件に当てはまる文字列が存在しているということでした。
Detection requires the data to be a 13–19 digit sequence that adheres to the Luhn check formula and uses a standard card number prefix for any of the following types of credit cards: American Express, Dankort, Diner’s Club, Discover, Electron, Japanese Card Bureau (JCB), Mastercard, UnionPay, and Visa.
偶然、生成されたログの中に13桁から19桁の数字が存在したのが、154万ファイル中「56個だけ」あったようですね。詳細は以下も合わせてご覧ください。
まとめ
今回は Amazon Macie を利用することで、CloudTrail の利用料が意図せず増えてしまった実体験について記載しました。この条件を再度おさらいしておきます。
- CloudTrail で S3 のデータイベントを記録する設定を有効にしている
- Amazon Macie の sensitive data discovery jobs を実行するにあたり、CloudTrail 用の S3 バケットを含める
- CloudTrail に大量のログファイルが存在している（作成したばかりの AWS アカウントの場合はファイル数が少ないため問題にならない）
上記の条件に全て当てはまると、CloudTrail の利用料が意図せず増加する場合があります。これを避けるには sensitive data discovery jobs の実行対象として CloudTrail 用の S3 バケットを避けて頂くのが良いでしょう。他にも、ELB のアクセスログや AWS Config 用のバケットなど、小さいオブジェクトが大量に設置されるようなバケットは discovery job の対象外としても良い場合があると考えます。
本ブログは以上になります。
ではまたお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
