【ITニュース解説】When Incident Reports Say 'Found Traces of Unauthorized Access', What Are They Actually Looking At?

セキュリティに関するニュース記事で「不正アクセスの痕跡を確認した」という報告を目にすると、多くの人が実際に何をどう見て、そう判断しているのか疑問に思うだろう。もし自分の開発したサービスが攻撃された場合、どのようにそれに気づけば良いのか。悪意のある情報収集を行うスクレイパーと、通常の利用者を見分けるにはどうすれば良いのか。このような疑問に対して、専用のセキュリティチームを持たない個人開発者でも実践できる、不正アクセス検知と防御のポイントを解説する。

まず、システムへのリクエストが急増する「トラフィックスパイク」が発生したからといって、必ずしもデータが外部に漏洩したとは限らない。多くの小規模なプロジェクトでトラフィックスパイクが起きる主な原因は、実は内部的な問題である場合が多い。例えば、フロントエンドのプログラムにバグがあり、無限ループで何度もサーバーにリクエストを送ってしまうケースや、圧縮されていない大きな動画や画像をデータベースから直接配信している場合、あるいはデータベースのインデックス設定に不備があり、毎回全データを読み込むような重いクエリが頻繁に実行されるケースなどが挙げられる。また、開発中のデータベースの移行やバックアップ作業によって、一時的に大量のリクエストが発生することもあるだろう。このような状況では、まず最近リリースした変更にバグがないかを確認することが重要である。

しかし、もし外部のIPアドレスから何千ものリクエストがシステムに集中して押し寄せたとしても、それが直ちにデータ漏洩を意味するわけではない。ここで「行レベルセキュリティ（RLS）」という防御機能が重要な役割を果たす。データベースの特定の行に対して、どのユーザーがアクセスできるかを細かく設定できるこの機能が適切に設定されていれば、たとえ認証されていない攻撃者がデータ取得を試みるリクエストを送ってきても、データベースは不正な行を返さずに空の配列を返す。そして、この時システムはエラーではなく、あたかも正常に処理されたかのようにHTTP 200 OK（成功）というステータスコードを返し、コンテンツは空の状態となる。つまり、リクエストの数が数万件に跳ね上がっても、ユーザーのデータが一つもデータベースから流出していない状態を作り出せるのである。この仕組みを理解していれば、トラフィックスパイクに直面した際も、それが内部のバグによるものか、それとも外部からの攻撃だがデータは保護されている状況なのかを冷静に判断できるようになる。

次に、「不正アクセスの痕跡」を具体的に検証するための実践的なステップについて説明する。クラウドサービスのダッシュボードの表示がどのように変化しても、データベースやウェブAPIに対する普遍的な3つの核心的な痕跡を比較検討することが重要である。

第一に、「リクエスト数」と「データ転送量（Egress）」のギャップを注意深く観察する。これは最も重要な比較点である。リクエスト数は急増しているにもかかわらず、データ転送量が横ばいであれば、攻撃者はエンドポイントにアクセスしているが、RLSや認証機能によってデータが外部に送信されていない可能性が高い。しかし、リクエスト数の急増と比例してデータ転送量も増加している場合は、実際にデータが外部に流れ出ていることを示しており、これは即座に「赤信号」と判断すべき事態である。

第二に、受信したリクエストのパスとパラメータを確認する。通常のユーザーが直接アクセスしないような内部的なルートを狙ったリクエストや、?select=*のような、データベースの全情報を取得しようとする貪欲なパラメータを付加した大量取得のリクエストがないかを調査する。

第三に、HTTPステータスコードの偏りを見る。通常の正当なアクセスでは、ほとんどのリクエストがHTTP 200 OK（成功）を返す。もし短期間にHTTP 401 Unauthorized（認証なし）、403 Forbidden（アクセス拒否）、429 Too Many Requests（リクエスト過多）のような400番台のエラーが大量に発生している場合、それは自動化されたスクリプトや脆弱性スキャナーがシステムのエンドポイントを探索し、認証の穴を探している可能性が高い。

「不審なアクセス」を識別するためのさらに具体的なヒントもある。馴染みのないクライアントのIPアドレスを調査ツールで確認する際、ネットワークの所属組織（ASN / Org）が一般のインターネットサービスプロバイダ（ISP）や携帯電話会社であれば通常の人間による利用である可能性が高い。一方、AWSやDigitalOceanのようなクラウドやデータセンターの組織に属している場合は、悪意のあるスクレイパーやボットの可能性が高まる。また、User-Agent（ユーザーエージェント）がChromeやSafariといった標準的なブラウザやモバイルアプリのものであれば通常の利用者だが、「python-requests」や「curl」、「Go-http-client」のようなプログラムからのリクエストを示す文字列であれば、自動スクリプトである可能性が高い。リクエストの頻度も判断材料となる。人間は通常、数秒から数分間隔でリクエストを行うが、悪意のあるスクリプトは毎秒数十回ものリクエストを送信することがある。さらに、トラフィックの広がり方として、通常のユーザーは複数のページを自然に遷移するが、自動化されたスクリプトは特定の単一のエンドポイントを繰り返し集中的に攻撃する傾向がある。データセンターのIPアドレスから、PythonスクリプトがプライベートなAPIエンドポイントを毎秒数十回も叩いているような状況は、ほぼ間違いなく自動スキャナーによる攻撃であると判断できる。

このようなセキュリティリスクに備えるためには、「自動アラート」を事前に設定することが非常に重要だ。日々手動でログを確認するのは現実的ではないため、小さな問題が大きな被害になる前に通知を受け取れるようにしておく。例えば、Vercelでは設定画面から使用量の上限に近づいた際やセキュリティイベント発生時に通知を受け取るように設定できる。Supabaseでも、請求連絡先メールアドレスが普段から監視しているものになっていることを確認し、クォータ超過の警告を見逃さないようにすることが重要である。

トラフィックスパイクが発生した場合に備えて、多層的な防御戦略を講じておくことも有効である。外部からのトラフィックやスキャナーに対して、まず「Vercel WAF（Web Application Firewall）」が自動的なボット検知とブロッキングを行う。持続的な攻撃に対しては、「Attack Mode」を有効にすることで、疑わしい自動トラフィックに対してCAPTCHAのようなチャレンジを強制し、スクリプトによるアクセスを即座に停止させることができる。次に、「Supabase RLS（行レベルセキュリティ）」が第二の防衛線として機能する。たとえリクエストがデータベースに到達しても、権限のない行は空の配列を返すため、データは保護される。最後に、「Spend Cap（請求上限）」という財政的な安全ネットを設定しておく。Supabaseの請求設定で「Spend Cap」を有効にしておけば、従量課金の制限を超過した場合でも、APIがHTTP 429（リクエスト過多）でスロットリングされ、予期せぬ高額なクラウド利用料が発生するのを防ぐことができる。

個人開発者がセキュリティのために何時間もログを監査し続けるのは難しい。現実的なメンテナンスルーチンとしては、普段は特別なアラートメールがVercelやSupabaseから届かなければ、プロダクト機能の開発に100%集中するという「受動的」な姿勢で良い。週に一度、2～3分程度で良いので、使用状況のグラフに異常なリクエストやデータ転送量の急増がないかを確認し、最近のAPIログをざっと見て、400番台のエラーが異常に集中していないかをチェックするだけでも、多くのリスクを未然に防ぐことができる。

「不正アクセスの痕跡」という言葉は、かつては抽象的で遠い問題、あるいは漠然とした恐怖に感じられたかもしれない。しかし、この記事で解説したように、データ転送量とリクエスト数を比較して冷静に判断すること、RLSがたとえ攻撃を受けてもデータを保護してくれること、そして請求上限やアラートメールを設定することで壊滅的なリスクを排除できることを理解すれば、より安心して開発に集中できるだろう。これらの実践的なチェックリストが、システムを安全に保ち、安心してサービスを運用するための一助となることを願う。