
Conclusion
この記事の結論
WAFのマスクとCloudFrontの記録項目は実ログで確認し、APIについてはステージ設定までを確認しました。
ログを減らす作業では、「不要な情報を残さないこと」と「障害を調べる情報が残ること」を両立させます。保存期間、記録する項目、項目のマスクは別の設定です。保持日数だけ短くしても一件のログに残る値は変わらず、項目を外しても既に保存したログの保持期間までは変わりません。
今回の対応
11月1日、ログの保持期間や記録項目を設定しました。AWS WAFでは実際の遮断イベントで対象部分がマスクされていることを、CloudFrontでは選択した15項目が記録されることを確認しました。
サービスごとに観測したもの
AWS WAFでは遮断された実際のイベントで対象部分がマスクされたことを見ました。CloudFrontでは出力に選択した15項目があることを確認しました。APIステージは設定を確認できましたが、今回の観測範囲で対象の実リクエストを確認できず、出力された値の検査までは行っていません。
状況別の判断と次の対応
| 観察した状態 | そこから判断できること | 次に確認すること |
|---|---|---|
| WAFで遮断イベントを取得 | 対象項目を実データで確認できる | 値を転載せずマスク状態を記録する |
| CloudFrontログを取得 | 選択した列と出力列を比較できる | 調査に必要な列が残るかを見る |
| APIの設定だけ確認 | 出力結果のサンプルは得られていない | 次の正規リクエストの観測を待つ |
結果を使うときの注意点
単一の遮断ログで確認できたマスク状態を、別のログ種類にも自動的に適用されたと考えないことが大切です。記録にはサービス、対象のログ種類、確認時刻、確認対象項目を残します。個人情報を含み得る元の値を報告書に貼り直す必要はありません。
- 01残す項目とマスク対象を分ける
- 02サービス別に設定と実ログを比較する
- 03実ログ待ちの箇所を追跡する
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認
