開発者だからこそできるセキュリティ向上策（1/2 ページ）

「Microsoft Tech・Ed 2004」では、.NET Frameworkのセキュリティ技術「コードアクセスセキュリティ」などをテーマにしたセッションも行われた。

[高橋睦美，ITmedia]

　マイクロソフトがパシフィコ横浜で開催している「Microsoft Tech・Ed 2004」で例年になく目立つのが、セキュリティ関連のセッションだ。デベロッパーにとってもセキュリティは、もはや無視することのできないテーマになりつつある。

　というのも、「設計段階からセキュリティを組み込むのに比べると、いったん開発したアプリケーションに後からセキュリティを追加すると手間もかかるし、コストもかさむ」（NRIラーニングネットワークの近藤美貴子氏）からだ。

　近藤氏は「IIS 6.0とASP.NETによるセキュリティ」と題したセッションの中で、SQL InjectionやクロスサイトスクリプティングといったWebサーバの代表的な脆弱性について説明するとともに、これらを含めたさまざまな脅威からWebサーバを保護するための方策について語った。

　Webサーバのセキュリティを高めるに当たってまずなすべきことは、「どの資産（情報）を」「どんな脅威から」守るのかを明確にすることである。これは何もWebサーバだけに限った話ではないが、各脅威の深刻さを見積もり、優先順位を付けて対処を進めれば、対策漏れを防ぐことにもつながる。近藤氏はそのための手法として、マイクロソフトが作成した「STRIDE」および「DREAD」モデルを紹介した。

　その上で個別の対策を通じて、セキュリティを固めていく。サーバであってもパッチはできるかぎり最新のものを適用し、当該アプリケーションを管理者権限で動作させないのは当たり前として、たとえばSQL Injectionならば「特殊文字がそのまま解釈されないよう入力チェックを行う」「ストアドプロシージャを用いる」「バインドメカニズムを利用する」といった方法があるという。またクロスサイトスクリプティングについては、同じく「入力チェック」を怠るべきではないのはもちろん、「見知らぬ人から送られてきた電子メールは気軽に開かず、文中のURLもクリックしないようユーザー教育を行う」のが有効だとした。

　さらに、IISとASP.NETの双方でセキュリティ対策とユーザー認証、承認を行い、マイクロソフトの言う「多層防御」を実現すべきという。

　特にASP.NETについては、入力チェックを行うのはもちろん、Aspnet_setreg.exeやDPAPIを用いて資格情報など重要なデータを保護するとともに、監査を丁寧に行うべきという。特にフォーム認証や.NETパスポート認証については、ログオンの成功だけでなく「失敗」についても監査すべきだし、ASP.NET用の拡張子マッピングが改ざんを受ける可能性に備え、その変更を監査しておくべきだと述べた。

コードアクセスセキュリティにできること

　また「コードアクセスセキュリティを使用した安全なアプリケーションの構築」というセッションでは、.NET Frameworkで可能になったセキュリティフレームワーク、コードアクセスセキュリティの概要が紹介された。

　マイクロソフトデベロッパーマーケティング本部のデベロッパーエバンジェリスト、辻郷隆史氏は、「これまでのモデルはユーザーレベルのセキュリティだった。これにプラスし、より安全なアプリケーションの実行を可能にするのがコードアクセスセキュリティだ」という。

　これまでは、あるコードを実行してもいいかどうかは、それを実行しようとする「ユーザーが誰か」をACLと比較することによって判断されていた。これに対しコードアクセスセキュリティの枠組みでは、そのコードが「どこから来たか」「どの会社のものか」という要素によって実行の可否を判断する。この結果、たとえユーザーが同一人物でもコードの出所が異なれば、実行できる権限は違うものになる。