<前の日記(2006年03月02日) 次の日記(2006年03月11日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 3790   昨日: 4173

2006年03月07日

「高橋メソッド」的突貫工事と、脆弱性を排除する構造設計は両立するか

こんな記事が出ていた。

高橋氏は「Webサイトは構築してから3年経つと陳腐化する」と指摘する。ただ,壊れたわけでもないWebサイトを3年でリニューアルするには,事前に顧客と話をつけておく必要がある。3年で捨てる予定のアプリケーションの予算は少ない――これが,WebにはPHPやRubyといったLLが向いている理由である。Javaのような重量級の言語だと,10年持ちそうな設計や構造のアプリケーションを作ることになり,費用もそれなりに高額になってしまう。

それは話が逆だろう。「10年持ちそうな」という言葉で比喩されるような、つまり、しっかりとした設計や構造のアプリケーションを作るときには、設計を事前に十分に吟味しておく必要があることから、「費用もそれなりに高額」となるところ、その際に使用言語として、Javaを使わない理由がない(またJavaが向いている)というのが本来の世間で言われていることの筋道だろう。「Javaだと高額になる」ではなかろう。

そのような論理が現場にあるとすると、それは裏を返せば、「PHPやRubyといったLL (Lightweight Language)」が使用されるときは、予算が小額で、事前のしっかりとした構造設計は行われない場合である――ということになる。(本当か?)

まあ、手っ取り早く作り直しするのも結構だけれども、それは、セキュリティを無視しないことが前提であるはずだ。*1

たしかに、現段階でRubyを採用するような、高い技術力を持っている個人に支えられている企業が受注する場合には、十分な設計をしなくても、根性で脆弱性のないシステムが作られるかもしれない。

だが、日曜プログラマなのになぜかハッカー気分の井の中の蛙タイプのPerlプログラマ*2や、Webページデザイナが本屋で立ち読みして勉強しただけでプログラマになった気分のPHPプログラマたちの場合は、「根性で脆弱性のないシステムが作れる」かどうか疑わしい。

Javaを使った重量級の開発では,たいてい「ユーザー企業の情報システム部門がシステムを発注し,大手システム・インテグレータ(SIer)が受注する」という形になる。一方,ツインスパークが請け負う仕事(引用時注: RubyやPHPなどのLightweight Languageでの開発)は「ユーザー企業の営業部門や広報部門がシステムを発注し,大手広告会社が受注する」という形が多いという。

この発言は、いま時分になっても日本ブログ協会に脆弱性が見つかるというような(おそらく)超初歩的な欠陥が見つかる事例が出てくる現状を、端的に示唆しているように思われる。

発注者が情報システム部門ならよい。RubyやPHPで開発するのであっても、受注者が「高い技術力を持っている個人に支えられている企業」であり、「十分な設計をしなくても、根性で脆弱性のないシステムが作られる」かどうかを吟味する能力を持っているかもしれない。

しかし、「営業部門や広報部門がシステムを発注し大手広告会社が受注する」という場合が困る。たまたま「高い技術力を持っている個人に支えられている企業」が受注すれば幸運(高橋氏のように?)だが、まったくそれに期待できないところが受注すると悲惨なことになる。

日本ブログ協会の事例のようなケースは、そういう低レベル技術力の事業者を、営業部門や広報部門や広告代理店のようなところが見分ける能力を持っていないために起きているのではなかろうか。(日本ブログ協会の事例が、どんな人が誰にどのような方法で発注したのかは私は何も知らないけども。)

そのような不幸な事態を解消するためには、やはり、何らかの安全設計基準に適合したシステムとするよう、発注者が発注仕様で要求し、受注者はそれにしたがって設計、施工したことを保証する「構造計算書」を提出するという方向性にもっていくしかないように思われる。

そうすると問題は、

壊れたわけでもないWebサイトを3年でリニューアルするには,事前に顧客と話をつけておく必要がある。3年で捨てる予定のアプリケーションの予算は少ない

という、少ない予算の案件で、そのような「構造計算書」の提出を要求できるのかどうかだ。*3

しかし、そもそも、

10年持ちそうな設計や構造のアプリケーションを作ることになり,費用もそれなりに高額になってしまう。

というのは本当だろうか。設計をしっかりしていても低予算で開発できるように思えるし、Javaによる案件の多くが高コストである理由が、事前の設計のコストにあるわけでもないようにも思える。

ところで、私もRuby on Railsには大変興味がある(PHPやPerlは死滅すればいいのにと思っている)ので、先日以下の本を買った。

前田さんの監訳だ。本屋でパラパラと見たところ、セキュリティに関する記述がけっこうある*4ようだったので買った。まだ読んでいない。

追記

上で、「この発言は……現状を端的に示唆しているように思われる」と書いたのと同様の現状認識が、@ITの以下の記事の表にも書かれていた。

Webシステム作成業者特徴
システムベンダ(SIer)

Webシステムをプログラムとして考える。見た目よりも、使い勝手や、機能や、パフォーマンスを重視する傾向にある。セキュリティ対策については、技術的に前向きであるが、凝り過ぎの傾向がある。

ホームページ制作専業

Webシステムを、ホームページ作成ととらえ、企業の顔としてのデザインと、機能や、パフォーマンスのバランスを考慮する。セキュリティについての意識は高いが、規模的に小さい企業が多く、各社の対応のバラツキが大きい傾向にある。

広告代理店・デザイン会社

Webシステムというより、広告媒体の一種類として考える傾向にある。機能や、パフォーマンスよりもデザイン重視であり、セキュリティについての意識は低い傾向にある。

「凝り過ぎの傾向」というのはよくわからないが……。何のことだろう?

*1 高橋氏に対して「セキュリティを無視しているのではないか」と言っているわけではないので注意。

*2 リーダース英和辞典第2版参照。

*3 ちなみに、この記事には

もちろん,技術面での責任も1社に集中するため,契約が重要だという。

という記述があるが、脆弱性が後から見つかったときの対応はどのような契約にするのか、興味深い。

*4 p.38にこんな記述がある。

[訳注] 本書のコード例では、説明の簡易化のため h() によるエスケープ処理を省略している部分もあります。実際のアプリケーションでは、エスケープ洩れのないよう十分ご注意ください。

さすが前田さん。というか、原著者も h() くらい全部入れとけばいいのに。たった3文字タイプするだけなのに、そんなに嫌なのか?

本日のTrackBacks(全29件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20060307]

◎分散投資シミュレーション(日経特集/野村アセット/morningstar) ここから飛んでいくシミュレーションサイト[www.morningstar.co.jp/PortfolioAdviser/]ですが、FireFox で見てたら入力箇所とはちょっと違うテキストボックスが右の微妙な位置に登場するんで、なんだこ..

実は上記の訳注は、レビューをしてくださった高橋さんの提案でして、
高橋さん自身はセキュリティを重視されている方だと思います。

Culinary arts school. Culinary school salinas. Culinary specialist a-school contacts. Winemaking culinary school niagara. Paragon culinary school. Alexandria barletta culinary school. Cost of culinary school cia cca.

Ecommerce hosting.

高木浩光@自宅の日記 - 「高橋メソッド」的突貫工事と、脆弱性を排除する構造設計は両立するか

高木浩光@自宅の日記 - 「高橋メソッド」的突貫工事と、脆弱性を排除する構造設計は両立するか

検索

<前の日記(2006年03月02日) 次の日記(2006年03月11日)> 最新 編集

最近のタイトル

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|
<前の日記(2006年03月02日) 次の日記(2006年03月11日)> 最新 編集