第7回　得手不得手 プログラムにだって ありますよ？ - セキュリティ講座

誰でもアウェイは苦手なもの…だけど

やむを得ない部分も少なからずあるのですが、どうしても、多くの技術者は「自分の得意な領域で勝負のすべてを行おうとする」癖がある事が多いように思われます。

でも、多くの場合「出来る」と「適切」の間には、突き落とされたらどんな獅子の子でも生存不可能なほどの、深くて暗い溝があります。

ある機能に関してただ「出来る」だけの「適切ではない」ものをチョイスしてしまうと、そこで大きな歪みを生んでしまうために、結果としてセキュリティリスクが増大する可能性があります。具体例について少し考察をしてみましょう。

ネットワーク/サーバ管理者とは仲良く

掲示板などユーザ投稿のある類のプログラムでありがちなのが「ある一定範囲のネットワークからのアクセスをブロックしたい」なんていう状況です。

もちろんそれを「プログラム的にチェック＆排除する」ことは十分に可能なのですが、もしその「一定範囲のネットワーク」がある程度決まっているなら、ネットワーク管理者にFireWallレベルで設定をしてもらった方がネットワーク負荷もマシン負荷も低く、かつ、厄介なコーディングも不要になります。

たとえば「わかりきってる一定範囲もあれば、ある程度動的な一定範囲もある」のであれば。わかりきっている一定範囲のIPに対してはFireWallでブロックをかけ、動的な部分だけプログラム側で制御をすれば、どちらにとっても比較的低い負担で、全体として制御をかけることが可能になります。

また、ある程度しっかりしたルータを使っているところであれば意図的に「ネットワーク帯域を絞る」ことでマシンへの過負荷を押さえたり、もうちょっと高度な制御になると、ネットワーク要求をキューイングすることも出来ます(トラフィック シェーピングとか呼称します)。

これをプログラムで制御しようとすると、ちょっと大変ですよね？

また、もちろんそれがよいわけではないのですが、どうしてもDocumentRootに設定ファイルなどを置かざるを得ない場合。Apacheなどの設定で「拡張子単位で出力を抑止」なんていうことをしておくと、最悪の事故が防ぎやすくなります。

こんな風に、ネットワーク/サーバの知識があると、プログラマ側だけでは「厄介だなぁ」と思っていた色々な事が、案外に簡単にできてしまったりもするのです。

パケットは盗聴可能？

重要な情報を…DBに保存する時とかならば、暗号化なりなんなり、プログラム側で対応が出来るのですが。流れているパケットレベルで盗聴されてしまうと、正直プログラム側では手も足もでません。

これがどうでもいい情報ならまだよいのですが、たとえばクレジットカード番号とかが盗聴されるのは限りなく避けたいところです。

そんなときにhttpsは大変に重要なのですが、これもやっぱりネットワーク管理者との二人三脚が必要になります(まずはきちんとした証明書を取得してもらうことから始まります。間違っても自作の証明書なんか使っちゃいけません)。

ちなみに、httpsにすべきところをhttp(暗号化なし)にしてしまったために発生する脆弱性には「HTTPS Misuse」っていう名前がついてたりします。

あちこちで必要な冗長化

すべてのWebアプリケーションが、という訳ではないのですが、業務の性質的に「止まらない」システムが要求されることは少なくありません。

そんなシステムをプログラムだけで構築するのは、ちょっと無理があります。具体的にはハードウェアに絡む関連などです。

そんなときに、ネットワークの冗長化、マシンの多重構成、DBのクラスタリング、などを行うことは非常に大切です。 もちろんネットワーク屋さんDB屋さんからも「そういった多重化に耐えられるシステムを作って欲しい」と願われるモノですので、お互いに「相手のことを考えて」の設計であり構築であり、になるわけです。

具体的には「ローカルにファイルを持たない(PHPの場合セッションがデフォルトでローカルファイルを使うので注意)」などの設計が要求されます。

賢いロードバランサですとCookieなどの値によってマシンを振り分けてくれたりもするのですが、やはりロードバランサにも相応の負荷がかかりますので。

ロードバランサに負荷をかけるのか、セッション情報をDBでもってDBに負荷をかけるのか、については、コストなども視野に入れながら柔軟に設計したいものです。