「身に覚えのない操作がある」と利用者から連絡が来たとき、該当する時間帯のログを取り出せるでしょうか。保存しているはずでも、場所や閲覧権限が分からなければ、確認を始められません。
まず一つのWebサービスを選び、ログの保存先、実際に残っている期間、確認できる担当者を調べます。本記事では、普段の運用で準備しておく内容を、構成図と問い合わせ例で説明します。
すでに侵害が疑われる場合は、社内の事故対応窓口や契約先へ連絡し、被害を抑える対応と記録の保全を進めてください。この記事の整理が終わるまで対応を待つ必要はありません。
攻撃の仕組みについては、A2B攻撃とAPIセキュリティの記事で説明しています。
1．通信の経路と、記録の場所を並べる
ログは、システムで起きた出来事を記録したものです。利用者からの通信を受け付ける入口と、注文や会員情報を処理するアプリでは、記録できる内容が異なります。
図1：通信とログの関係。実線は通信の経路、点線はログの出力を示します。応答は省略しています。記録の有無・項目は製品と設定によって異なります。画像を開くと拡大できます。
| 記録の種類 | 確認に使える情報の例 | その記録だけでは判断できないこと |
|---|---|---|
| 入口・Webサーバのアクセスログ | 時刻、接続元、アクセス先、応答コード | アプリが誰のデータの操作を許可したか |
| アプリのログ | 利用者の識別子、操作、対象、処理結果 | 記録していない操作や処理の詳細 |
| データベースの監査ログなど | 接続や操作の履歴。対象は設定による | アプリの利用者とDB操作の対応関係 |
AWSでは、クラウドの設定変更などを調べる場合に、操作記録も確認します。CloudTrailはAWSアカウント内の操作などを記録するサービスです。自社アプリの会員が何を閲覧・更新したかを調べるログの代わりにはなりません。
また、「AWSを使っているからアクセスログも残る」とは限りません。たとえばALB（通信をサーバへ振り分ける機能）の従来型アクセスログは、既定で無効です。有効化した場合は指定したS3へ保存されます。現在は別のログ配信方式も提供されているため、実環境の方式と設定を確認してください。AWS公式資料
2．保存設定と、実際に取り出せる記録を確認する
設定画面を見るだけでなく、権限のある担当者が対象期間の記録を取り出せるか確かめます。次は社内で整理する項目の例です。
| 確認項目 | 記録する内容 |
|---|---|
| 対象 | サービス名、本番・検証の区別、ログの種類 |
| 保存先 | クラウドのアカウント・リージョン・保存場所、またはサーバとファイルの場所 |
| 期間 | 保存設定と、実際に取得できた最も古い・新しい日時、途中の欠落 |
| 時刻 | UTC・日本時間などの基準、時計のずれ、発生時刻と保存時刻の違い |
| 担当 | 閲覧できる人、内容を調べる人、連絡先と対応時間 |
| 確認結果 | 確認日、取り出せた範囲、権限不足や取得失敗の内容 |
「保存期間90日」という設定と、90日分が実際に揃っていることは別です。取得開始前や設定変更中の記録がない場合もあります。委託先に依頼する際も、「ログはありますか」だけでなく、「この日時の、このサービスの記録を取り出せますか」と対象を伝えます。
3．一件の問い合わせを、記録からたどってみる
たとえば、「10月20日10時ごろ、注文履歴を開いたらエラーになった」と問い合わせが来たら、どこから調べるでしょうか。
- 日時と対象をそろえる。 日本時間の10時か、どのサービス・画面かを確認し、前後の時間帯も検索対象にします。
- 入口の記録を探す。 対象APIへのアクセスと応答を確認します。接続元IPだけで利用者本人と判断せず、ほかの記録と照合します。
- アプリ側の結果を確認する。 リクエストIDなど、同じ処理を対応付ける識別子が記録されていれば、それを手がかりに探します。
- 必要な場合にDB側も確認する。 アプリ側のエラーや処理内容を踏まえて、接続・操作の記録を担当者へ確認します。
リクエストIDは、一つの要求を区別する番号です。入口・アプリ・DBのすべてに自動で同じ番号が記録されるわけではありません。引き渡しと記録の仕組みがなければ、時刻など別の手がかりで照合し、対応が確定できない部分はそのまま残します。
HTTPの「200」は正常応答を表すコードですが、それだけで正しい利用者に正しいデータを返したとは判断できません。「403」も、どの処理が拒否したかを調べる必要があります。
確認結果は、たとえば「入口で対象時刻の応答を確認。アプリ側の保存期間外のため、処理内容は確認できない」と書きます。「ログに異常がないので問題なし」と結論を広げないでください。
4．記録が見つからない理由を切り分ける
記録が見つからなければ、検索条件、取得設定、保存期間、配信の遅延や失敗を確認します。AWSもALBアクセスログについて、すべての要求を完全に数えるための記録ではないと説明しています。AWS公式資料
記録がないことだけで、不正アクセスがなかったとは判断できません。調べられた範囲と調べられなかった範囲を分け、必要な追加確認を担当者へ引き継ぎます。
また、今からログを有効にしても、記録していなかった過去の出来事は戻りません。残っている記録を調べる作業と、今後の記録設定を直す作業は分けて進めます。
5．記録内容と、確認する担当を決める
ログを増やす前に、何を確認したいかを決めます。ログインの成功・失敗、権限の変更、重要なデータ操作など、対象を開発・運用担当で整理してください。OWASPは、出来事の日時・場所・主体・内容や、関連する処理を結び付ける識別子を記録する考え方を示しています。OWASP Logging Cheat Sheet
要求や応答の全文をそのまま保存すると、パスワード、トークン、個人情報まで記録するおそれがあります。必要な項目を選び、秘密情報を除外・マスキングし、閲覧や削除の権限を制限します。保存期間も一律の日数ではなく、調査に必要な期間、契約等の条件、費用を踏まえて決めます。
設定を変えた後は、管理下のテストで予定した記録が残るか、不要な情報が含まれないかを確認します。記録が止まったときの通知と、その通知を受ける担当も決めてください。
まずは対象サービスを一つ選び、担当者に必要な時間帯の記録を取り出してもらってください。保存先、権限、記録内容のどこで困るかが分かれば、次に直す箇所を決められます。
ログの保存設定・運用の整理について相談する
「保存先が分からない」「委託先から必要な記録を取り出せない」「通知後に誰が確認するか決まっていない」といった場合は、現在の状況をお知らせください。
対象サービス、困っていること、開発・運用の担当体制、対応したい時期を分かる範囲でご記載ください。最初のお問い合わせに、生のログや認証情報を添付する必要はありません。
クラウド環境の設定確認、手順の整備、運用の役割分担について、対応可否・範囲・費用を個別に確認します。専門的な侵害調査や緊急対応を一律に提供するものではありません。
参考資料
確認日：2026年10月20日。
