公開の準備で最後に残ったのは、自分しか使わない画面だった。注文の状態を見たり、公開してよいものを選んだりする管理の画面が、利用者向けのサイトと同じ入口にぶら下がっていた。認証はかけてある。それでも、住所さえ分かれば、誰でもそのログイン画面までは辿り着ける状態だった。
入口にいちばん近いところで止める
守りを足す場所は二つ考えられた。アプリの中で「この人は管理者か」を見る方法と、アプリに届く前の、外から最初に受ける入口で弾く方法。前者はすでに入っている。それでも後者を足したのは、アプリまで届いてしまえば、そこには処理が動く余地があるからだった。ログインの試行を受け付ければ、それだけで計算も記録も動く。届く前に断れば、そもそも何も動かない。守りは、遠いところほど安上がりに効く。
存在ごと、無かったことにする
そこで、管理画面のページと、管理用のやりとり口を、入口の段階で許可した所からしか通さないようにした。それ以外から来た場合は、権限がないという返事すら返さない。そんなものは無い、という返事にした。権限がないと答えるのは、そこに何かがあると教えることでもある。侵入を試みる側にとっては、無いと言われた場所より、権限がないと言われた場所のほうが価値が高い。存在を知らせない、という一段を挟むだけで、探る側の手がかりは減る。
ログインは、一分に十二回まで
そのうえで、ログインの受け口だけに回数の制限をかけた。一分あたり十二回。ただし瞬間的に数回続くのは許すようにした。人が打ち間違えて続けて入れ直す動きは通り、機械的に総当たりを仕掛ける動きは頭を押さえられる、という線引きだった。制限は強くしすぎると自分が締め出される。自分が普通に使っている速さを一度測ってから、その数倍のところに置いた。
誰が叩いたのかを、正しく数える
ここで一つ、見落としかけた点があった。回数を数えるには、誰が叩いたのかを見分ける必要がある。ふつう、経路の途中を通ってきた要求には、元はどこから来たかという申告が付いてくる。この申告は、送る側が自由に書ける。つまり、書き換えれば、毎回違う相手のふりができ、回数の制限は素通りになる。だから管理まわりだけは、途中の申告を信じず、実際に繋いできた接続元そのものを見るように変えた。一般の利用者向けの経路は従来どおり申告を引き継ぐ。同じ入口でも、守りたいものによって、信じてよい情報が違った。
認証そのものも、この機会に見直した。合言葉を覚えて打ち込む方式は、打ち込む場所さえ見つければ誰でも試せる。手元の端末に持たせた鍵で本人を確かめる方式に寄せ、こちらも別立てで通しの試験を用意した。ただ、方式を新しくしたからといって、入口を開けたままでよい理由にはならない。強い鍵をつけたので扉を通りに面して置いてよい、とはならないのと同じだった。
重ねることが、守りだった
結局、管理画面には、場所を明かさない、来られる所を絞る、回数を絞る、認証を通す、という四段が重なった。どれか一つで完璧を目指すより、突破の手数を増やすほうが現実的だと思う。一人で作って一人で運んでいるものほど、破られたときに気づくのが遅れる。気づくのが遅れる前提なら、そもそも辿り着かせない設計に寄せておくのが妥当だった。
ここまでで、公開前の点検はひととおり終わった。試験は、正常に動くかを見るものから、壊れたときに何が起きないかを見るものへ変わっていった。次の巻では、公開したあとに実際に起きたことを書く。