PR

 さて、前回は書籍の脆弱性についてお話しました。急激に膨らむWebアプリケーション(以下Webアプリと略)開発市場に人材の供給が追いついていないことがその原因では、とも書きました。
 では、少しくらい開発コストが高くなるとしても、いくつもWebアプリを作ってきた経験を持つ専門家に頼めば良いのでしょうか?
 ……残念ながら、どうもそうではないようです。というのも、わたしが見かけた脆弱性には、それなりにパッケージ製品を出している開発会社によるものや、ばりばりカスタマイズしている企業のものも少なくないからです。もちろん、個人的な体験だけを材料に一般化はできませんが、開発を行っている会社=Webアプリ開発の専門家であるからといって、脆弱性とは無縁でいられるというわけではなさそうです。

 それどころか、何度脆弱性を指摘しても、その都度その場所しか修正せずに、システム全体を見直すなんてことは全く考えようともしなかったり、そもそも脆弱性に対する根本的な理解が十分でない、そんな「専門家」も存在します。動くものを作って、それをきれいに仕上げるところまではできても、情報を保護する、という側面から見ると心もとない……そんな業者に当たってしまったら利用者も発注者も災難というほかはありません。

 しかし、そんな「専門家」を一方的に責めることはできないような気がします。というのも、Webアプリケーションのセキュリティ対策は、最近でこそ開発するときからしっかり考える、という方向性になりつつありますが、それまでは秘奥義として、せいぜい監査をする人たちの間だけでノウハウを共有していただけに過ぎないからです。そのノウハウがWebアプリケーションのコードを書く人の目に触れるのは稀だったと言えるでしょう。

 つまり、これまでセキュリティ対策とは「隠れた仕様」だったのです。プログラムを組むことそのもののノウハウは、プログラムを開発するために読むさまざまなコンテンツに書かれていますが、プログラミング時のセキュリティ対策は「情報セキュリティ」というカテゴリーの中にしか存在していませんでした。まあぶっちゃけ、「情報セキュリティ」のカテゴリーなんてよほどのフリーク(笑)か、アンテナの感度が相当良い開発者でもなければ読まないでしょう。その結果、攻撃や防御の研究をするコミュニティの現在の到達点は、ことセキュリティ対策に関する限り開発側の100光年先になってしまっていると思うのです。

 とはいえ、社会状況は変わりつつあります。Webサイトを運営する側の「預かった個人情報は保護しなければならないけど、保護できているのか?」という「危機感」は募って来つつあるようです。何しろ利用者に突き上げを食らいますからね。どの業界でもそういうところはありますが、利用者の意識の方が進んでいるわけです。
 危機感を抱いた運営側は、しかし自分の危機感を言語化できないのではないでしょうか。「扱っている個人情報が漏洩しないこと」……おそらく今は、言えたとしてもこんなところでしょう。これは大正解なのですが、しかし要求される側としては最も困るパターンです。いや、例え「SQLインジェクション」に気を付けることと言われたとしても、「SQLインジェクション」に気を付けるために何をすればいいのかがわからないかもしれません。やむを得ずにわか勉強で何とか対応したとしても、今度は受け取った側(発注者)がそれをどうやってチェックすればいいのかわからない。

 つまるところ運営者(発注者)、開発者の両方とも、セキュリティ対策は本業ではないわけです。本来やりたいことは、Webアプリケーションの開発、コーディングであり、Webサイトでの新規ビジネス展開です。セキュリティは近頃利用者がうるさいから仕方なく気を付けているに過ぎません。できれば避けて通りたいでしょう。
 しかし、そのWebサイトのセキュリティがヤバイときは最終的に被害者になってしまう利用者としては、そんなことでは困るわけです。

 きわめてまっとうな改善を考えるならば、「そんなこと言わずに、みんなでセキュリティに気を付けようよ」という世界を実現すべきなのでしょう。しかし、わたしの意見は少し違います。わたしはセキュリティの専門家のノウハウを自動的に、あるいは明示的に組み込む方法を模索すべき、と思います。

 自動的に組み込む方法には、例えばそもそも開発する環境にライブラリや開発のフレームワークを入れておくというやり方があります。開発者が「安全にしか作れない」ようにしてしまうというわけです。少し難点なのは、ライブラリやフレームワークに関する知識があまり一般的ではないので、使い方を覚えて習熟する必要がある、というところでしょう。しかし、慣れてしまえば、セキュリティ対策を後追いしながら自分でこつこつ作り込む必要性は、大幅に減るでしょう。
 明示的に組み込むには、例えばWebアプリケーションのセキュリティ監査を行うやり方があります。出荷直前、あるいは開発途中にチェックを行い、その結果を見て改善することになります。課題は監査を行う人の能力をどう保証するのか、あるいは、監査のための予算を誰が出すのか、というところでしょうか。出荷直前の場合、改修期間の確保もポイントでしょう。

 こうした提案は、セキュリティ対策やそのノウハウをブラックボックスにして、その中はセキュリティの専門家に任せつつ、開発も運用もそれぞれの担当者はそれぞれの「本業」に集中しよう、という考え方に基づいています。これは王道ではないかもしれません。しかし、開発現場が「開発費は低く! 納期は短く!」とあまりにも買い叩かれている現状では、セキュリティ対策になるべくパワーを割かずに何とかしのぎたいと思うのは自然だと思うのですが、いかがでしょうか?