最近、自分でもWebサービスを作り、インターネット上で公開するようになりました。
開発しているときは、
「検索できた」
「DBにつながった」
「画面が表示された」
「クラウドへデプロイできた」
ということに目が向きます。
ところが、実際にサービスを公開すると、少し見える景色が変わりました。
「これ、攻撃されたらどうするんだろう？」
作る側から、ほんの少し「運営する側」へ視点が変わったのだと思います。
タイムズカーの情報漏えいを見て考えたこと
2026年9月、タイムズカーがWebシステムへの不正アクセスと情報漏えいを公表しました。
公表情報によれば、不正アクセスを検知した後、外部専門機関と調査を行い、不正アクセス経路や攻撃元との通信を遮断しています。
このニュースを見ながら、自分のサービスだったらどうするだろう、と考えました。
最初に浮かんだのは、とても単純な発想でした。
「攻撃を検知したら、自分でDBを落とせばいいんじゃないか？」
サービスが止まるのは困ります。
でも、サービスが30分止まることと、個人情報が大量に外へ出てしまうことを比較すれば、後者の方がはるかに深刻です。
ただ、もう少し考えると、DBそのものを落とす必要はありません。
止めるべきなのは、
攻撃者からデータまでの経路
なのだと思います。
Webサービスにも「非常停止」があっていい
工場の機械には非常停止ボタンがあります。
危険な状態になったとき、機械を動かし続けることよりも、人や設備を守ることを優先するためです。
Webサービスにも同じ考え方があっていいのではないでしょうか。
例えば通常時を、
NORMAL
としておく。
異常なアクセスが増えたら、
RESTRICTED
にしてレート制限を強化する。
さらに異常が続けば、
READ ONLY
にして更新処理を停止する。
重大な侵害の可能性が出たら、
ISOLATED
としてWeb/APIからDBへの通信を遮断する。
つまり、
NORMAL → RESTRICTED → READ ONLY → ISOLATED
という段階的なSecurity Modeです。
全部止めるか、全部動かすか。
その二択ではなく、危険度に応じてサービスを縮退させる仕組みです。
「入口」だけ守ればいいのか
もう一つ考えるようになったのが、攻撃の入口だけを監視すればいいのか、ということです。
WAF、認証、Firewall、SQLインジェクション対策など、入口を守る仕組みはもちろん重要です。
でも、正規のAPIを経由してデータを取得されていたらどうでしょう。
普段、一人のユーザーが数十件程度しか参照しないサービスなのに、突然、
100件、
1,000件、
10,000件、
100,000件……
と読み出され始めた。
リクエストそのものは正常でも、振る舞いとしては明らかにおかしい。
だったら、
「攻撃を検知する」のではなく、「異常なデータの動きを検知する」
という考え方も必要になります。
大量SELECT。
大量ダウンロード。
通常とは違う時間帯からのアクセス。
短時間での大量API呼び出し。
通常とは異なる地域や環境からのアクセス。
こうした複数の情報を組み合わせて、
「ちょっと怪しい」
なら制限する。
「かなり怪しい」
ならRead Onlyにする。
「これは危ない」
となったら隔離する。
人間が気づいて対応するまで、システムが無防備に動き続ける必要はないはずです。
個人開発では24時間監視できない
企業ならSOCやセキュリティ担当者がいる場合があります。
しかし個人開発では、自分が開発者であり、インフラ担当であり、運用担当であり、セキュリティ担当でもあります。
そして当然ですが、24時間監視することなどできません。
仕事をしているかもしれない。
寝ているかもしれない。
サウナに入っているかもしれない。
その間にもサービスはインターネットにつながっています。
だから個人開発ほど、
「自分が見ていなくても守れる仕組み」
が必要なのかもしれません。
インフラエンジニアとして少し面白いテーマになってきた
インフラの仕事をしていると、
「止めない」
ということをかなり意識します。
冗長化する。
障害を検知する。
フェイルオーバーする。
バックアップする。
復旧時間を短くする。
どれも重要です。
しかしセキュリティについて考えると、逆方向の設計も必要になります。
止めることで守る。
何があっても動き続けるシステムではなく、
危険な状態になったら、安全側へ倒れるシステム。
工学では昔からあるフェイルセーフの考え方ですが、Webサービスにももっと積極的に入れていいのではないかと思います。
作って終わりではなく、守って復旧するところまで
自分でWebサービスを公開したことで、
「サービスを作る」
という言葉の意味も少し変わりました。
開発する。
公開する。
監視する。
異常を検知する。
遮断する。
証拠を残す。
復旧する。
そして、そもそも必要以上のデータを持たない。
ここまで考えて、初めて「サービスを運営する」なのかもしれません。
今回のタイムズカーのインシデントを見て、自分のサービスについても一度、
「今夜、自分が寝ている間に攻撃されたら、このサービスはどうなる？」
と考えてみようと思いました。
そして最終的には、
攻撃を完全に防ぐことだけを目指すのではなく、攻撃されても被害を広げない。
そんな設計を、自分のサービスにも少しずつ取り入れてみたいと思います。
「止めない」ことだけが、良いインフラではない。
必要なときに、正しく止まれることもインフラの品質なのだと思います。
