1. はじめに
1.1 PCI DSSについて
MIXIでは、全社ID・決済基盤システムを内製で開発・運用しており、各種決済手段を社内で開発している各サービスから統合的なインタフェースで利用できるようになっています。利用しているサービスの一例がMIXI MとモンストWebショップです。
この決済基盤システムは決済代行の役割を担っており、クレジットカードで決済する時は、カード会員データを保持しながら決済プロバイダと通信しています。そのため、MIXIは、カード会員データを安全に取り扱うためのセキュリティ基準であるPCI DSSを2019年より取得しています。
1.2 要件10.4について
PCI DSSの現行バージョンは4.0.1で、300以上の要件から成っています。要件の中に以下の項目があります。
10.4 監査ログをレビューし、異常あるいは疑わしいアクティビティを識別する。
（出典：PCI DSS v4.0.1）
この要件では、システムやアプリケーションのログに関して、異常や疑わしいアクティビティを迅速に識別するために、定期的なレビューが求められています。特に、カード会員データを処理するシステムや重要なシステムコンポーネントに関しては、少なくとも毎日一度のレビューが求められます。
この要件をどう解釈して運用に落とし込むかはサービスによって異なります。MIXIで運用しているサービスでは、「カード会員データ環境下の全てのシステムコンポーネント全てについて、毎日一度のログレビューを実行し、証跡を記録する」運用をしています。
また、カード会員データ環境のシステムを開発・運用しているチームはMIXI ID基盤やモンストWebショップの開発にも携わっているため、それらの関連するサービスのシステムコンポーネントに関しても、日次でログレビューする方針です。
1.3 日次ログレビューの課題
ログレビューの目的は、潜在的に疑わしい、または異常な活動を早期に検知して対応することであるため、ログレビューでは、過去のログ傾向と比較して異常な結果が出ていないか判断する必要があります。
この判断は過去経験に基づくものであるため、非常に属人的で、運用上の課題となっていました。
ログレビューの対象となるシステムコンポーネントのログは、全てAmazon CloudWatch Logsに集約する運用としています。CloudWatchのダッシュボードを使うことで、ログレビュー作業は一部自動化できていました。
しかし、ログのレビュー自体や、証跡の記録は人力に依存しており、工数的に大きな負担となっていました。作業は365日、毎日シフト制で回しており、1日あたりおよそ30分ほどの工数が必要となっていました。
このように、PCI DSS要件を満たすためのログレビューは、運用の属人化と工数負担という2つの課題を抱えていました。
Amazon Bedrockを使ってログレビューを自動的に行うシステムを設置することで、これらの課題を大幅に改善できました。この記事ではそのシステムについて紹介します。
2. ログレビューシステムの構成
ログレビューシステムの構成は以下の図のようになっています。
毎日指定の時刻にLambda関数を発火させるEventBridgeを設置します。Lambda関数は、CloudWatch Logsからレビュー対象となるログを抽出し、レビューを指示するプロンプトと共にBedrockに入力します。Bedrockでレビューした結果がレスポンスされてきたら、Lambdaで証跡となるレポートを生成し、Slackに投稿します。
2.1 CloudWatch Logsからのログ抽出
LambdaでCloudWatch Logs Insightsのクエリを実行し、対象システムのエラーログを抽出します。具体的には、以下のようなクエリを実行します。
fields coalesce(content.event, content.processor_error_code, content, content.message, content.error) as msg,
concat(content.method, content.request_path) as path
| filter level != "info"
| filter level != "notice"
| filter not isblank(msg)
| filter not isblank(level)
| display @timestamp, msg, path
| sort msg, path, @timestamp desc
対象システムのログには、全てログレベルを設定しているため、ログレベルによってフィルタすることで重要なエラーログのみ抽出が可能です。また、カラムをある程度まとめてフィルタすることで、必要な情報のみを抽出し、Bedrockへの入力が大きくなりすぎないように工夫しています。
CloudWatch Logsから抽出するログは、Lambdaの実行日時より、過去一週間のデータです。このうち、レビュー対象とするのは昨日分だけですが、過去一週間のデータと比較することで、Bedrockに異常値を検出してもらいます。
2.2 Bedrockへのプロンプト設計
CloudWatch Logsから抽出したログは、BedrockにCSVドキュメントとして渡します。Bedrockのモデル呼び出しは、将来的なモデル切り替えの可能性を加味して、Converse APIを使っています。
プロンプトの内容は以下の通りです。集計・比較・報告フォーマットまで明示的に指示します。プロンプトは一度日本語で記述し、GPT-4oに英訳・整形してもらったものを利用しています。
# Role
You are a senior SRE engineer working in a team that develops web services.
One of your responsibilities is to review error logs on a daily basis to detect and prevent application failures.
Some error logs are output regularly and do not indicate major issues.
Therefore, you need to understand the historical trends of the error logs, assess the severity of each error, and report your findings to the application engineers.
# Rules
Please aggregate *all* error logs from **${formattedStartTime}** to **${formattedEndTime}** by their content and report the number of occurrences for each.
Additionally, by comparing the logs from the period **7 days before ${formattedStartTime}** to **${formattedEndTime}**, if you find any error logs that have rapidly increased or any unfamiliar error messages, please include them in your report as well.
# About the Input Error Logs
- The error logs will be provided in CSV format.
- The first column in the CSV contains the timestamp when the error was logged, the second column contains the error message, and the third column contains the request path where the error occurred.
- The logs contain data from the past several days. All timestamps are in UTC.
- The logs will be pre-sorted by the error message content.
# About the Report Format
Please write the report in **Markdown format**.
First, report the time range being analyzed.
Next, for **all** error logs from **${formattedStartTime}** to **${formattedEndTime}**, report the aggregated results grouped by error content.
The aggregated results **must** include the error message and the number of log entries with that same message.
The error message in the report **should** be shown exactly as it appears in the input.
Also, be sure to report **all** error logs within the aggregation period.
Then, by comparing with the logs from the period **7 days before ${formattedStartTime}** to **${formattedEndTime}**, report **all** error logs that can be judged as important.
If there are no error logs that can be considered important, please report: **"No issues detected"**.
Only report objective facts based on the data. Do not include guesses or suggestions for improvement.
The report must be written in **Japanese**.
このようにプロンプト設計すると、例えば以下のような出力が得られます。
# ログレビュー (2025/05/08)
以下は、2025年5月8日のエラーログの分析レポートです。
## 分析期間
2025/05/08 00:00:00 から 2025/05/08 23:59:59 まで
## エラーログの集計結果
1. "** (Plug.UploadError) could not create a tmp directory to store uploads. Set..." - 8件
2. "Revoke failed: {:error, :invalid_request, "user_grant is not found"}" - 1件
3. "Revoke failed: {:error, :invalid_token, "unknown token format"}" - 1件
## 重要と判断されるエラーログ
1. "** (Plug.UploadError) could not create a tmp directory to store uploads. Set..."
* このエラーは2025/05/08に8回発生しており、前の7日間には見られないため、新たに発生した問題である可能性があります。
1. "Revoke failed: {:error, :invalid_request, "user_grant is not found"}"
* このエラーは2025/05/08に新たに発生しており、前の7日間には見られません。
1. "Revoke failed: {:error, :invalid_token, "unknown token format"}"
* このエラーも2025/05/08に新たに発生しており、前の7日間には見られません。
これらのエラーは全て新しく発生したものであり、アプリケーションの動作に影響を与える可能性があるため、注意が必要です。
2.3 レポートのSlack投稿
AIが生成したMarkdownレポートは、SlackのCanvas機能を使って投稿します。Slack認証情報はAWS Secrets Managerから取得し、Canvasの作成・権限設定・リンク投稿までをLambdaで行います。
3. PCI DSS環境下でのBedrock利用
PCI DSSにおいて、カード会員データや機密認証データを取り扱うカード会員データ環境には、厳格な管理と制御が求められます。
今回、PCI DSS環境下でBedrockを利用するために、以下のように利用可否の検討をしました。
他のPCI DSS環境下でBedrockを利用される場合は、別途その環境に合った検討が必要です。以下の検討事項はMIXI社内のPCI DSS環境に特化したものであるため、参考にされる場合はご注意ください。
3.1 カード会員データ環境のスコーピング
MIXI社内のPCI DSS環境において、CloudWatch Logsはカード会員データ環境外と定義しています。CloudWatch Logsにログを流すシステムコンポーネント上では、カード会員データや機密認証データを保存・処理・送受信していますが、ログにはそういった機密データが露出しないようにフィルタリングを徹底しているためです。
CloudWatch Logsがカード会員データ環境外であるため、CloudWatch Logsのログを処理するLambda及びBedrockもカード会員データ環境外と定義しています。
3.2 Bedrockへの入出力
以下の記事を根拠に、Bedrockへの入出力はBedrockサービス側およびモデルプロバイダには保存されないと整理しました。このため、誤って機密データが入力されたとしても、Bedrockに保持されることはないと解釈しています。
一方、Fine-tuningを利用すると、Bedrockへの入出力がAIモデルの学習に利用されるため、Fine-tuningは行わない構成としました。
3.3 サードパーティサービスプロバイダの整理
Bedrock及びサードパーティのモデルプロバイダを利用するにあたって、Bedrockで利用するAIモデルプロバイダをPCI DSS v4.0.1要件12.8の「サードパーティサービスプロバイダ」と位置付けました。
社内では、PCI DSS環境で利用するサードパーティサービスプロバイダを選定するにあたって、以下の条件を課しています。
- PCI DSSに準拠していること（カード会員データ、および機密認証データを直接扱う場合）
- SOC 2 type II reportを取得していること
今回はSOC 2 type II reportを取得していることを条件に、Anthropicが提供しているAIモデルを利用可能とする整理にしました。
4. Lambda関数のソースコード
以下で、実際に利用しているLambda関数のソースコードを公開しています。
5. まとめ
本システムを導入することで、日次のログレビューにかける工数を大幅に削減できました。もともと1日あたり30分程度要していた工数を数分にまで減らすことができたため、年間およそ150時間ほどの工数が削減できる見込みです。
PCI DSS環境は様々な運用上の制約があり、サービスによってAIモデルの導入可否は様々です。この記事で紹介したケースはあくまでも一例として、AI活用の参考としていただけたら幸いです。
Discussion