ウェブアプリのセキュリティアップデート問題

2013/4/11作成

CMSが狙われる3つの理由

これって結構深刻な問題だと思います。いや、思いますではなくて深刻な問題です。

プログラムにはバグは無いのが理想ですが、完璧な人が存在しないのと同じで、バグの無いプログラムはありません。そして、バグのうちのいくつかは脆弱性となり、セキュリティホールとなり得ます。あってはならないことではありますが、現実には存在します。

長い間、セキュリティホールとはOSの問題でした。OSに存在するセキュリティホールを突く攻撃があり、多くのマルウェアが蔓延しました。その反省として、現代において利用されているOSの多くはかなり安全になりました。そもそもの開発スタイルがセキュリティに多くの意識が割かれるようになりましたし、またセキュリティホールが発見されたあとはパッチが自動的に適用されるような仕組みが標準で搭載されるようにもなりました。これらの地道な努力のおかげで、無くなったわけではありませんがOSのセキュリティホールに由来するセキュリティ事故はかなり少なくなったと言えるでしょう。

OSがセキュアになったら、次に攻撃対象として狙われたのはアプリケーションです。と言ってもExcelマクロウィルスなどはかなり昔からありますけどね。ウェブが普及するに従ってウェブブラウザが重要なアプリケーションになると、ウェブブラウザが攻撃対象になることも多くなりました。その結果と言ってはなんですが、ウェブブラウザも今では随分とセキュアになりましたし、OSと同様に自動的にセキュリティパッチが当てられる仕組みも導入されるようになりました。

余談ですが、このセキュリティパッチを当てる仕組みがアプリケーションごとに独立しているため、バックグラウンドで○○updateというプロセスがたくさん動いている状態は、ちょっとスマートではないなぁと思います。どうせならOSの自動アップデートの仕組みに組み込まれてしまえばいいのにと思うのですが。WindowsならWindows Updateですね。Linuxではyumやaptでそういうことは実現できているのですから。まあ、これからはアプリストアからインストールしたアプリに関してはアプリストアが面倒を見てくれるようになるので、○○updateは減少していく傾向にはあるだろうとは思いますが。

話を元にもどして、OSに続いてアプリケーションも今ではセキュアな状態を保つ仕組みが整ってきました。そこでと言ってはなんですが、現代においてもまだそうした仕組みが整っていないのがウェブアプリケーションなのです。

著名なものも含めてですが、多くのウェブアプリケーションのインストール方法はインストーラなどとは無縁です。アーカイブを展開したファイル一式をウェブサーバにアップロードして設定ファイルを書き換えるか、設定プログラムを起動するかです。インストールがこんな状態ですから、アップデートの為の便利な手段など提供されているわけがありません。更新するためには、同じくアーカイブをダウンロードしてきて展開してウェブサーバにアップロードしなければなりません。こんな面倒なことと言っても、ウェブアプリを管理する立場ならそれをしなければならないのですが、万人がそれを出来るわけではないというのも自明でしょう。自動アップデートの仕組みは万人がやらなくても出来るようになっているのですが、手動アップデートではやらない人はかならず存在します。

もっとも、だからといってどうしたらいいのかというと、私も別にいいアイデアを持っているわけではないのですけれどね。私の知る範囲で比較的いいなと思ったのはWordPressです。WordPressでは管理画面に更新ボタンがあり、クリック一つでアップデートをすることが出来ます。いちいちクリックをしなければならないのが手間ではありますが、アーカイブをダウンロードして展開して云々よりははるかに手軽ではあります。

ならいっそのこと勝手にアップデートしてくれてもいいじゃないかという気もしないでもないのですが、それがなかなかできないのはアップデート版が完全な互換性を持っていないことが多いからかもしれません。アップデートする前にはデータのバックアップを取っておいて、出来れば違うディレクトリにアップロードして動作を検証してから新旧を切り替えるというようなことが当たり前に要求されるのが現代のウェブアプリの世界です。何も気にせずアップデートしてもそのまま使えるのが当たり前のOSやアプリケーションの世界に比べると、圧倒的に遅れていると言っても過言ではないでしょう。いや、一応私もそうしたウェブアプリの業界に居るものですからえらそうなことは言えないのですが。

ともあれ、セキュリティの問題がOSからアプリケーションを経て、ウェブアプリケーションに移ってきたのが現代というわけです。おそらくこれからウェブアプリの世界でもセキュアを保つ為の様々な工夫が導入されていくことでしょう。その一端を少しでも私も手伝うことが出来ればなと思います。

(2018/5/31追記)

この記事を書いてから3年ほど経ちまして、状況は随分変わったかと思います。結果的には良い方に変わりましたかね。

変わった第一は、WordPressがさらに進化して自動更新機能を搭載したこと。新バージョンが登場したらウェブサイトの各管理者が何もしなくても、WordPressの配布元が勝手にバージョンアップをしてくれます。WindowsやChromeが勝手にバージョンアップしてくれるようなものですね。ですのでWordPressに脆弱性が見つかっても修正したバージョンがリリースされたら比較的短期間で世界中のWordPressは更新されるようになりました。これはかなり画期的なことですね。

第二は、WordPress以外のCMSが事実上駆逐されたこと。もう何もかも全てがWordPressです。他の専用のCMSを使った方がいいんじゃないかというような用途まで、全てWordPressとプラグインで実装される風潮になりました。その結果、WordPress以外のCMSで脆弱性が発見されてもその影響は全体としては軽微になりました。

第三に、静的ページとCGIの組み合わせサイトが撲滅されたこと。これもまたWordPressに置き換わっています。従来ならウェブデザイナーさんがDreamWeaverでHTMLで制作していたようなサイトも、今ではほとんどがWordPressを使うようになりました。問い合わせフォームなどの一部の動的機能のためにCGIをダウンロードしてきてftpでアップするようなことはなくなり、WordPressの標準機能やプラグインで実現されるようになりました。従来ならCGIに脆弱性が見つかったら修正版をダウンロードしてftpでアップロードとしていましたが、そんなことはしなくてよくなりました。

第四に、単純なウェブサイトが減り、多機能なウェブサービスが増えたこと。ウェブサービスの場合は独自に開発するプログラムが存在しますから、開発したプログラマがバックに存在します。運用も単純にapacheが動いてればいいというわけにはいきませんから運用エンジニアが存在します。これらのエンジニアは運用に関してそれなりに知識と経験がありますから、使用しているアプリに脆弱性が発見された際にもそれなりに自力で対処することが期待できます。

というようなことが起こって、ウェブの世界も随分と安全になったのかなぁという気がします。別のリスクが増大してる部分はありますので、全てが安全とは言えないのですが、少なくともウェブアプリの脆弱性に対してはかなり安全な状態になったのではないかと思います。

もちろん全てのウェブサイトがこのような体制に移行したわけではありません。まだまだ静的HTMLとCGIの組み合わせで運用されているサイトもあることでしょう。ただ、その割合はかなり減ったのではないかということです。


あおやぎのさいと2.0 トドの日記2.0