「お名前.com デスクトップクラウド」への不正アクセスで、もっとも考えさせられたのは、グループ代表の熊谷正寿氏が10月25日に公開したブログの一節でした。
社内のホワイトハッカー(攻撃者と同じ技術を守る側で使う技術者)は、事前にこのサービスの課題を現場に指摘していた。現場も改善に取り組んでいた。けれども、サービスを止めないことへの配慮や優先順位の問題で、対応の深さと速さが足りず、そこを突かれた。おおよそ、そういう説明です。
指摘があっても、直すのが間に合わない。これはGMOだけの話ではなく、どの会社でも起きていることだと思います。もっと小さな会社では、脆弱性(悪用されうるシステムの弱点)の指摘が放置されたままになることも珍しくありません。この記事では、指摘が直すところまで届かない理由と、その仕組みの作り方を考えます。
指摘があっても直らない3つの理由
熊谷氏の説明に出てくる言葉を手がかりにすると、理由は3つに分けられます。
1つ目は、止められないことです。直すにはサービスを一度止めたり、利用者に影響が出たりする。売上や利用者への迷惑を考えると、つい後回しになります。
2つ目は、優先順位で負けることです。新しい機能の開発や、目の前の問い合わせへの対応は、締め切りがはっきりしています。セキュリティの改善は、何も起きていない間は締め切りがありません。
3つ目は、ブログには書かれていない、一般によくある理由です。指摘する人と直す人が違うことです。指摘する側は、サービスを直す権限を持たないことが多く、直す現場は指摘の重さを肌で感じにくい。間で温度が下がります。
直す側から見た「指摘」
私自身、自分で作ったものに、Claude Code(AIに頼んでプログラムを書いたり点検したりできる道具)から「この入力欄は長すぎる値の確認がない」と指摘を受けて、「次に直そう」と付箋を貼ったまま数週間たっていたことがあります。そのときは動いていたので困りませんでした。
規模はまったく違いますが、直す側の心理は同じだと思います。動いている間は、直す理由が見えにくい。指摘を受けた瞬間に、直すかどうかを誰かが決める仕組みがなければ、指摘は付箋のまま残ります。
指摘に締め切りを付ける
まずやれるのは、指摘に締め切りを付けることです。重大さを3段階くらいに分けて、それぞれに直すまでの期限を決めておきます。
重大さ | 例 | 直すまでの期限の例 |
|---|---|---|
高 | 外から誰でも入り込める | 数日以内 |
中 | ログインした人だけが悪用できる | 1か月以内 |
低 | 悪用の条件が限られる | 次の定期の更新で |
期限は会社ごとに決めればいいのですが、決めておかないと、2つ目の理由で必ず負けます。
期限を過ぎたら上に上げる
次に、期限を過ぎた指摘を、自動的に経営に上げる決まりを作ります。現場の判断で延ばすのは構いません。ただし、延ばしたことを、サービスを止める権限のある人が知っている状態にしておきます。
熊谷氏はブログで、組織として専門家の力を守りに十分つなげられなかったという趣旨のことを書いています。GMOの内情はわかりませんが、一般には、延ばすという判断そのものが悪いのではなく、それを決めた人と、止める権限を持つ人が別々のままなのが危ないのだと思います。延ばすたびに、いつまで延ばすか、その間に何で守るかを一緒に決めておけば、延ばすことは判断として成り立ちます。
止めて直す練習をしておく
1つ目の理由への備えは、止めて直すことに慣れておくことです。夜間に短時間止めて更新する手順や、利用者へのお知らせのひな形を用意しておけば、止める判断のハードルは下がります。
先週のPHP(Webサイトを動かすプログラムの言語)の重大な脆弱性では、国内の多くのサービスが、修正版が出る前から自分で止まりました。止める判断の材料は、別の記事で整理しています。
小さな会社の場合
社内にホワイトハッカーがいる会社は多くありません。それでも、外部の診断や、使っているソフトの更新のお知らせ、AIの道具による点検など、指摘が来る入口はあります。入口がどこであっても、締め切りと、上に上げる決まりがあれば、指摘は直すところまで運べます。
GMOの件の経緯は、時系列でまとめています。
