他社の不正アクセスの報道を機に、運用中の顧客システム3本を点検した。

- ⏱ 約10分で読めます - 👁 … views

運用している顧客向けの業務システム3本を点検しました。 結論から書くと、今回の3本は、確認できた範囲で、安心してよい状態でした。 侵入の形跡は見つからず、攻撃は来ていましたが、成功した形跡もありませんでした。

きっかけは、9月下旬から続いた不正アクセスの公表です。 日本郵便（郵便局アプリ）、ヤマト運輸、佐川急便、セイコーマート、タイムズカー、ニッポンレンタカー。 各社の初報は9月25日から10月1日の間に出て、続報は10月に入っても続いています。 規模は、確認できた範囲で、ニッポンレンタカーの数十名から、タイムズカーの約160万アカウントまで幅があります。

どの会社のシステムも、利用者の個人情報を預かっています。 私が運用している業務システムも、個人情報を預かる点では同じです。 そこで、念のために点検しました。 ただ、形跡がないことと、侵入されていないことの間には、点検では埋められない差が残ります。

各社の公表でわかっていること

読んだ範囲で、悪用された脆弱性や盗まれた認証情報など、具体的な原因を公表している会社はありませんでした。 わかっているのは、何が見られた可能性があるかと、どう気づいたかです。

セイコーマートの9月29日付の公表によると、きっかけは9月24日の22時から23時にありました。 不正にクラブカードの退会処理が行われたアカウントが、1件ありました。 調べた結果、9月28日の17時過ぎに、アプリのサーバーを経由して会員情報のサーバーに第三者が不正にアクセスした可能性が判明しました。 対象は約57万アカウントで、10月5日の第4報では574,647人分とされています。

タイムズカーは9月25日の午前9時07分に不正アクセスを検知しました。 10月1日更新の第3報では、約160万アカウントから運転免許証画像などの本人確認書類が流出したとしています。

公表された項目は、氏名、住所、連絡先、会員情報、本人確認書類の画像などが中心です。

タイムズカー、セイコーマート、ニッポンレンタカーの公表を読むと、決済に関わる情報は、含まれていないか、カード番号の下4桁のような一部にとどまっています。 カード情報のように、決済の別のシステムで管理している情報まで取り出すような、不正アクセスではなかった気がしています。 ただし、各社は手口を公表していないので、これは私の推測です。

セイコーマートは、1件の異常から判明しました。 自分のシステムなら、何から気づけるのか。

3本のシステムで、何を調べたか

対象は、顧客向けに運用している Django 製の業務システム3本です。 いずれも1台のサーバーに Docker を使って載せていて、外部に開いているのは SSH と、HTTP と HTTPS のポートだけです。

調べたのは、SSH のログイン、Web へのアクセス、アプリのログイン、アカウントと管理画面の操作履歴、サーバー上の不審な常駐プロセスです。 あわせて、ログがどれだけ残っているかと、攻撃を遮断する仕組みの有無も確認しました。 点検そのものは読み取り専用で、Claude Code に手伝わせました。

結果は、3本とも異常は見つかりませんでした。

  • SSH の成功は、ログの残る範囲で157件、61件、23件。すべて管理者の IP からの公開鍵認証で、パスワードでの成功は0件
  • アカウントの追加と管理画面からの変更は、直近1〜2か月で0件
  • 不審な定期実行や、見覚えのない外部との通信はなし

攻撃は、実際に来ていました。 インターネットにサーバーを公開した段階で、会社のホームページでも、ランディングページしか流していないサーバーでも、公開した直後から攻撃の対象になります。 2021年に Palo Alto Networks が公表した囮のサーバーの調査は、わざと弱くして公開した320台を対象にしています。 8割が24時間以内に、すべてが1週間以内に侵害されました。

1本のサーバーで、約10日間の SSH のログイン失敗が14,572件あります。 Web には、機密情報のファイルを探すリクエストが、約4週間のログに大量に残っていました。

そのうち15,049件に、サーバーは200を返しています。 200は、リクエストを受け付けて応答したことを意味するので、応答の中身を確認しました。 15,048件は484バイトで、トップページと同じ大きさです。 画面の構成上、存在しないパスにもトップページを返す作りになっていて、機密情報のファイルが読まれた形跡はありません。 残る1件は、本文のない応答でした（原因は確認していません）。

「ない」ことを証明できない理由

ここからは、一般論です。 サーバーを点検して何も見つからなくても、「侵入されていない」ことの証明にならない理由が、4つあります。 どのシステムにも残る限界で、特定のシステムの問題ではありません。 不正アクセスを受けたシステムが、そういう構造になっていたということではありません。

ログの長さ

ログは、多くの環境で標準の設定のままだと、数週間から1か月ほどで、古いものから消えていきます。 それより前に何があったかは、判断できません。

ログそのものへの信頼

点検は、ログが信用できることを前提にしています。 サーバーの管理者権限を取られていれば、ログは消せます。 ログに現れないものは、ログを見る限り見えません。 ファイルの改ざん検査やルートキットの検査は、ログを見る点検とは別の作業になります。

管理者の鍵と IP を正規の根拠にすること

「管理者の IP から公開鍵で入った」ログは、正規と判断します。 鍵が盗まれて、同じ IP の端末から使われていたら、ログの上では区別できません。

読むだけの不正

データを書き換えない不正は、書き込みの記録に残りにくく、読み取りのアクセスも正規の利用と同じ形で記録されます。

この4つがあるため、点検の結果として書けるのは、「ログが残っていた期間に、調べた観点で、侵入の形跡は見つからなかった」までです。 今回の点検報告にも、ログが残っている期間内に限るという条件を付けています。 期間と観点と、やっていない検査を、そのまま書きます。 「侵入されていない」ことは、誰にも証明できないからです。 ただ、確認できた範囲では、調べた観点のすべてで、異常は見つかりませんでした。

点検中に直したこと

点検の中で、次の設定を見直しました。

  • SSH のパスワード認証を無効にして、公開鍵だけにした（2本）
  • 旧方式の認証トークン3件を削除した（1本）
  • ログのローテーションを設定して、90日分を保持するようにした（1本）
  • バックアップの頻度と保持数を見直して、古いものを整理した（1本）
  • ログイン失敗や攻撃のリクエストを検知して、その送信元を自動で遮断する fail2ban を、すでに使っている定義を基に設定した（1本）

fail2ban の定義を共通にした

fail2ban の定義は、サーバーごとに少しずつ違っていました。 方針をそろえて、同じ動作をするようにしました。 SSH は2回失敗したら永久に遮断し、遮断のルールは、コンテナ宛ての通信を止められる DOCKER-USER チェーンに入れる、という方針です。

現状では、fail2ban のような自動の遮断が、いちばん効果的かなと思っています。 攻撃の量が多く、人が見て対応するのは追いつかないからです。 別の1本では、SSH で遮断している送信元が、1万件を超えています。

攻撃する側にも生成AIがある

不正アクセスの手段は、生成AIの広がりで、手に入りやすくなっています。

2025年8月に Anthropic が公表した脅威インテリジェンスレポートには、Claude が悪用された事例が載っています。 少なくとも17の組織を対象に、偵察、認証情報の収集、ネットワークへの侵入を自動化し、盗んだ金融データから身代金の額まで決めさせた恐喝です。

同じレポートに、技術力の低い犯罪者が、従来は年単位の訓練が必要だった作業（ランサムウェアの開発など）をAIの支援で行っていた、という記述もあります。

ChatGPT、Claude、Gemini は、こうした使い方を防ぐガードを入れています。 それでも、悪用の報告は出ています。

ローカルで動かせる LLM には、そもそもサービス側のガードがありません。 2026年9月の論文は、2024年1月から2026年3月までに、制限を外した公開モデルを3,471個確認しました。 それを組み込んだ GitHub 上のアプリ1,643個のうち、約4分の1は、明示的に悪意あるものと分類されています。

この論文が示しているのは、こうしたモデルの出回り方で、攻撃の成功率や被害の大きさではありません。 Anthropic のレポートと合わせて、数年前なら相応の技術が要った手段を、技術力の低い人でも試しやすくなっている、というのが私の見方です。

守る側も、同じ道具を使います。 今回の点検でも、ログの集計や設定の確認を Claude Code に手伝わせました。 攻撃が速くなるほど、人が目で見るだけでは追いつかなくなり、検知も遮断も、生成AIに頼る場面が増えていくと考えています。 攻撃が速くなっても、基本の点検項目は変わらない、とも思っています。

攻撃が増えても、今回の3本では、成功した形跡は見つかっていません。 fail2ban のような遮断の仕組みも、動いています。

どこまでやればいいのか

完璧と言える人は、いないと思います。 どれだけ調べても、ここまでやれば侵入されていないと言い切れる地点には、たどり着けないからです。

決められるのは、やる範囲のほうです。

  • 何を守るか。預かっている個人情報の種類と量
  • どんな攻撃を想定するか。今回の事案のように、利用者向けのアプリや Web サービスへの外部からのアクセス
  • 最低限の点検項目と、点検する頻度
  • 調べたことと、調べていないことの記録

今回の3本の点検では、次の6項目が最初の範囲になりました。 自分のサーバーでも、短時間で確かめられます。

  1. 公開鍵以外で入れないこと。外部からパスワードで入ろうとして、拒否される
  2. SSH の成功ログインが、想定した IP と公開鍵認証だけであること
  3. ログがどれだけ残っているか。サーバーの外にも保存しているか
  4. 攻撃を遮断する仕組みが動いているか。fail2ban なら、動作状況とログのエラーの有無
  5. 攻撃的なリクエストへの200応答の中身。応答の大きさを集計して、トップページと同じ大きさかを見る
  6. 管理者権限のアカウントと、最近作られたアカウントが、想定した人だけであること

セイコーマートは、1件の不正な退会処理から判明しました。 退会、パスワードの変更、管理者権限の付与のような1件の操作が、運用する側に通知される仕組みがあるか。 これも、点検項目に加える候補です。

点検の結果は、「いつ、どの範囲を、何で調べ、何は調べていないか」の記録として残します。 今回の点検報告に、ログが残っている期間内に限るという条件を付けたのは、その一例です。 ファイルの改ざん検査と、ログの外部保全という、ログの外側の確認は、まだ残っています。 点検の頻度は、これから決める必要があります。

今回の結果は、3本とも侵入の形跡なし。 確認できた範囲では、安心してよい結果でした。

それでも、「ない」ことは証明できません。 これは悪魔の証明です。 ここまでやれば終わりという地点がないことが、運用の難しさだと痛感しました。 だから、範囲を決め、調べた内容と調べていない内容を分けて記録し、同じ点検を繰り返します。