CODE IN TOKYO

「無理なセキュリティは、現場に“抜け穴”を作らせる —— 20年前のFTP地獄の話」

もう20年近く前の話なので、さすがに時効だと思うから書いてしまう。

当時、とあるお客さんの環境でWebシステムを開発していた。 ところが、その環境がなかなか強烈だった。

サーバーにはFTPでしかアップできない。 しかも、使えるのは実質 PUT だけ。

ディレクトリ確認もろくにできない。 サーバーログインもできない。 Apache設定も見えない。 もちろん本番だけじゃない。開発環境ですら同じ。

つまり、

という、地獄みたいな状況だった。

こちらとしては、

「ローカルでは動いてます」 「でもサーバーの情報が何もわからないです」

としか言えない。

一方で、サーバーを管理している情シス側は、

「サーバーには触らせません」 「でも動かしてください」

というスタンス。

今思えば、完全に“責任分界点が壊れてる案件”だった。

しかも厄介なのは、現場担当者も困っていたことだ。 開発を進めたい。でも別部署のルールは曲げられない。

結果、現場は「抜け穴」を探し始める。

ルール上、「FTPで配置したPHPが何をするか」までは制限されていなかった。 つまり、PHPさえ置ければ、サーバー側でコマンド実行もできる。

なので最終的に、

「環境調査用PHP」

みたいなものをアップして、Apache構成やパス、モジュール状況を調べることになった。

もちろん、お客さん担当者の合意は取っている。 ただ、ルール的にはかなりグレー、というかアウト寄りだったと思う。

でも、現場はもうパニックだった。

こちらは、 「サーバー情報がないと動かせない」

情シスは、 「それは管轄外」

お客さん担当は、 「でもリリース日は決まってる」

という状態。

今振り返ると、たぶん情シス側は、

「HTMLを置く程度の運用」

しか想定していなかったんだと思う。

だから、

「FTPで置ける」 ↓ 「だから問題ない」 ↓ 「動かないのはアプリ側の問題」

という認識。

でも実際には、PHPアプリという時点で、

など、サーバー側要素に依存しまくる。

そこを全部ブラックボックス化して、 「自己責任で動かせ」は、さすがに無理がある。

ちょっと意地悪な見方をすると、

「そもそも情シス側もサーバーにログインできなかったんじゃないか？」

とすら思っている。

外注に丸投げで、問い合わせるたびに金がかかるとか、そういう構造だったのかもしれない。

もちろん、本来なら社内調整してから案件化すべき話だ。 でも、部署が違うと本当にこういうことは起きる。

営業は売る。 現場は作る。 情シスは守る。

そして誰も全体最適を見ていない。

結局、なんとかApache構成を把握して動かすことはできた。

ただ、社内では当然こうなる。

「なんでこんな案件受けたんだ……」

と。

そして20年経った今、このブログを書いていて疑惑が確信に変わった。

あのとき情シスの人たちも、たぶんサーバーにログインできなかった。

だから「触らせない」のではなく「触れない」だったのだ。 俺たちは戦っていたんじゃなくて、たぶん、一緒に途方に暮れていた。

ネットで流れるセキュリティ事件の話を聞くたびに、ふと思う。

——あのとき俺たちがアップした“環境調査用PHP”、まさか今もあのサーバーで静かに動いてたりしないよな？

いや、まさか。消したはず。。。

……まさか、ね。