ニュースレターNo.31/2005年11月発行

特集3：サーバアプリケーションセキュリティ

～JPNIC・JPCERT/CCセキュリティセミナー2005開催報告～

xSPのオペレーターを対象としたJPNICと有限責任中間法人JPCERTコーディネーションセンター(JPCERT/CC)共催のセキュリティセミナーも、早いもので今年で3年目となり、今回の開催で8回目を数えます。この8回、「セキュリティ対策に特効薬はない」という考えから、毎回違う側面からのプログラムを提供するよう心掛けてきましたが、8回行ってもまだまだ語るべきことが多いことに驚いています。一言で「インターネットセキュリティを確保する」といっても、実際にオペレーターの方々がやるべきことは多岐にわたり、一つの事象に対応するには包括的な観点でセキュリティをとらえなくてはいけないことを、今更ながらに痛感しています。

JPCERT/CCの代表理事であり、JPNICの理事でもある歌代和正は、今回のセミナーの中で、インターネットセキュリティの多面性を次のように表現していました。

2005年10月6日・7日に東京・秋葉原コンベンションセンターにて開催した今回のセミナー「サーバアプリケーションセキュリティ」は、代表的なサーバのアプリケーションである「Web」「メール」「DNS」について、それぞれOS別にWindowsとUNIXとに分けて解説するという構成で組み立てました。今までのようにネットワークセキュリティ中心の話からは少し離れましたが、サーバアプリケーションについて網羅的に知るというのも、オペレーターにとって、サーバの工夫のポイントが考えやすく、興味深く聞いていただけたのではないかと考えてます。本稿では、プログラムのうち基調講演部分と、全体のプログラム内容についてご報告します。

セミナーの資料並びにビデオについては、後日、以下のWebページに掲載予定ですので、本稿を読んで興味を持たれた方は、是非ご覧になってみてください。

★JPNIC・JPCERT/CCセキュリティセミナー資料
　http://www.nic.ad.jp/ja/materials/security-seminar/

(注：基調講演の内容は、当日の話をもとに編集を行ったものです。)

基調講演：このパッチをあてて、本当に大丈夫？

株式会社ラック 代表取締役社長 三輪信雄

本日は「このパッチをあてて、本当に大丈夫？」というお話をさせていただければと思います。私は、1995年からラックでセキュリティ事業を一人でキックオフし、現在に至っています。当時、「英語版OSで脆弱性があっても、日本語版では大きな問題にならない」などと言われていましたが、それはおかしいと思い、検証コードを少し改良して全く同じ動きをするように作り変えた情報を提供したことにより、マイクロソフトからパッチが提供されたということがありました。当時は日本のマイクロソフトには窓口がなく、シアトルのチームと直接やり取りし始め、これは面白いと思い、以後、付き合いも広がっていきました。

パッチのリリース期間が延びている？

脆弱性を発見する人間とウィルスや攻撃ツールを作る人間は、今のところなぜか別人であることが多いです。但し、いつまでも見つける人と作る人が別人であるという保証はなく、誰も知らない脆弱性を突いたウィルスやワームを作って蔓延させるホラーストーリーがささやかれてもおかしくはありません。実際にスーパーマンでもなんでもない人が脆弱性を見つけることは往々にしてあります。また、攻撃コードを作ることもそんなには難しいことではなく、それほど特殊な能力も必要ありません。

これらの脆弱性に対し、なぜか「紳士的」に処理される仕組みが作られつつあります。「紳士的仕組み」とはパッチを作成するまで脆弱性の発表は控えるべきである、という一連の流れです。さらに最近は脆弱性の存在への批判よりも、出たパッチの動作の不具合に対する批判の方が大きいように感じます。穴はあってもOSが動いているからいいが、パッチに不具合があって落ちるのはよくないという考えです。動作の不具合の無いことが確認されたパッチができるまではパッチを公開しない、遅らせてもいいという仕組みができればできるほど、脆弱性に対する対応は遅れると私自身は危惧しています。結局メーカーは経済原則に基づいて動いているので、ユーザーがそれでいいよと思っていると、そうなってしまうものです。

パッチあては誰の責任？ -もし飛行機会社だったら -

聞くところによると、日本ではパッチの適用率が高いらしいです。しかし一方で、むしろ「パッチをあてたくありません」という声も大きいのではないでしょうか。なぜならパッチをあてるとサーバが止まる可能性をはらむからです。こういったことはサーバの環境に依存するので予測が不可能です。ハマった経験がある、もしくはハマったということを聞いたことがある人は多いでしょう。調子が悪くなるなら、あてないほうがマシという人がいることは決しておかしなことではありません。

そのような危険性をはらみながら、「緊急」と言われても「いつあてるか」が判断できないというのは当然のことではないでしょうか。「緊急」というものに対して、システム管理者が自分の責任範囲で「いつ」ということを判断するのはナンセンスです。自分のスキルに非常に自信があるとか、正義感が特別強い、という個人の属性に依存する部分が大きすぎます。また、パッチをあてたくてもアプリケーションやドライバが対応していないのであてられないことも良くあることです。

例えば飛行機会社が、欠陥のある部品を使った飛行機を飛ばしていたとしたらどのようなことになるでしょうか？　その事実だけで社会的批判を浴びるはずです。ですから、重大な欠陥のある部品が見つかったら、代替機を用意し運行をやめ、部品を交換するでしょう。でもそれは整備士の判断で行うわけではありません。経営者の判断が必ずあり、部品交換による運行続行の仕組みや環境の構築にも責任を負うでしょう。なぜなら費用もかかるからです。そして、彼らは「人命より優先されるものはない」と必ず言うでしょう。

もし、皆様が人命まで関わらないまでも、ものすごく重要なサーバや制御系システムを扱っていたらどう考えますか？　オンラインバンキングで欠陥のあるサーバを使っていたらそれだけで社会的批判を浴びる、と思うのではないでしょうか。

パッチを上手に利用するには -「サーバを止めるな」はナンセンス -

私はまず、パッチ適用のリスクは経営者が負うべきであると考えています。「ビジネス継続プラン(Business Continuity Plan：BCP)」という概念があります。「事業をいかに継続させるか」ということですが、ある意味、事業をきちんと継続させようと思うのであれば、部品の交換やメンテナンスをするというのは当たり前です。パッチあても同等にとらえられるべきです。そしてこれらは全てBCPに含まれるべき内容です。

よくサーバの管理者は「サーバを一秒たりとも止めることは許されない」を大玉条のように掲げています。でもそう掲げるから何もできなくなるのです。そして、「脆弱性」というから経営者も判断を誤るのです。経営者の耳に届けるときには、「ウィルスにかかる【欠陥】があります。それを避けるにはサーバを止めてパッチをあてなくてはいけません。でもひょっとすると二度と立ち上がらなくなる可能性があります。どうしますか？」とストレートに伝えるべきです。大事なサーバを止める判断もパッチをあてないで運用を続けるリスクもシステム管理者が考えることではなく、ビジネスの問題であり、経営者が考え、責任を負うべき事項です。

こういった不測の事態に備え、検証環境の構築は組織の責任としてきちんと果たしてほしいと思います。経営者が重要なサーバがシングルで動いていることがおかしいことを理解し、基本的にはシステムをテスト環境と本番環境と二重化しておく措置をとるべきです。また、パッチをあてなくても済む環境の検証と構築も必要です。パッチが出たからといって必ずしも絶対にあてなくてはいけないということではないかもしれません。ファイアウォールやパケットフィルタリングの設定による攻撃の無効化、サーバとして不要なサービスの停止や削除で、あてなくてもいい可能性もあります。また設定で逃げられることもあります。そういったことを総合的に理解して、今回出た「緊急」のパッチをあてるか否か判断することは脆弱性に対する深い技術的知識と自信がないとできないことです。ですから、こういった企業や顧客を守る重要なシステムにおける検証環境の構築に対する適正な費用の負担をするということが、経営者に求められることです。

勇気ある人にスポットライトを

私は常々、「パッチによる不具合情報の積極的な共有をしたらどうか」ということを考えています。厳しい秘密保持契約を結んだ上であれば、「勇気ある」ユーザーグループによるパッチの動作確認が事前にあってもいいのではないでしょうか。「不具合が生じた・生じなかった環境(ドライバのバージョン・CPUの構成・アプリケーション／ミドルウェアの情報)」のマトリクスがあれば、例えば自力で検証環境を構築する体力のない会社の経営者もこれを見れば何に対処すべきかわかります。また、少々過激な意見かもしれませんが、まじめにパッチに対応する企業か否かの情報公開があってもいいかもしれません。

しかし、残念ながら今のところこういった大きな取り組みはありません。取り組みには費用もかかり、当然ボランティアではできませんし、勇気あるユーザーグループへのインセンティブも必要です。しかし、自分達で自分達の製品の品質を上げようとするなら、常に誰かのせいにするのではなく、勇気を持つことも必要なのではないでしょうか。こういった勇気を持てる人にスポットライトをあてるべきです。なぜなら、自分達のサービスに誇りを持ちたいなら、メーカーに責任を押し付けるだけでは解決しない問題なのですから。

1日目(UNIX Day)

基調講演 「セキュリティ」の今昔
JPCERT/CC代表理事　歌代 和正

◆Unix系サーバのセキュリティ概要 　富士通株式会社 fujitsu.com室 　インターネットセキュリティ部 　城崎 徹	Unix系サーバを安全に構築する為の基本的な考え方や、OSやサーバアプリケーションのセキュアな設定方法について、また実際に運用していく上での注意点についてなどを解説した。
◆DNS (BIND, djbdns) 　株式会社日本レジストリサービス 　技術研究部 　民田 雅人	Unix系サーバ上で動作するDNSサーバ、システムにおけるインシデント事例を紹介した。またソフトウェアごとのセキュリティ対策の違い、規模別設定の違いについて紹介した。 TOPIC：IPA発表のDomain問題、TCP/UDP、Server/clientなどの脆弱性とセキュリティ対策の最新情報
◆メールサーバとセキュリティ(迷惑メール対策) 　株式会社インターネットイニシアティブ 　山本 功司	メールサーバ/システムが直面しているセキュリティ上の脅威は、今日ではその大部分が「迷惑メール」に関連していると言える。 メールサーバを運用していくにあたって考慮すべきセキュリティリスクとその対策を「迷惑メール」を切り口に解説した。
◆Webのセキュリティ 　セコム株式会社 IS研究所　新井 幹也 　セコム株式会社 IS研究所　金岡 晃 　JPNIC 木村 泰司 　JPNIC 岡田 雅之	前半では、フィッシング詐欺等で利用される技術とXSS・CSRFを中心にしたWebアプリケーションセキュリティの仕組みについて解説し、更に対策を考察した。後半では、取り上げてきたWebのセキュリティを分類し、関係してくる立場と取られるべき対策についてまとめた。 TOPIC：Phishing、 CSS(XSS)、 CSRF、 Pharming、 Webのセキュリティと対策

2日目(Windows Day)

基調講演 「このパッチあてても大丈夫？」
株式会社ラック 代表取締役社長　三輪 信雄

◆Windows Serverのセキュリティ概要 　マイクロソフト株式会社 　セキュリティ レスポンス チーム 　小野寺 匠	Windows Serverを安全に運用するためのセキュリティ設定および、基本的な考え方について、幾つかの組織規模別に解説した。
◆Windows DNS と ActiveDirectory 　マイクロソフト株式会社 　システムテクノロジー本部 　山本 明広	Windows環境におけるDNSの役割とActive Directoryとの関係性について解説。実践的なセキュリティ設計や展開方法、また、UNIX環境におけるDNSとの相互運用性についても説明した。
◆RADIUSで実現する認証サーバ 　～概要および脆弱性と対策～ 　株式会社アクセンス・テクノロジー 　取締役・研究開発部部長　納村 康司	近年、様々な用途で活用が広がっているRADIUS。元来ダイヤルアップ接続での認証プロトコルであったRADIUSが、どのようにして無線LANや認証VLANの認証サーバとして利用されているのか。また数々指摘されている脆弱性には、どのようなものがあるのか。更にそれら脆弱性の対策について、どのような事柄に留意すればよいのか。プロトコルの機能の観点から解説した。
◆Web (IIS, Apache) 　インターネット セキュリティ システムズ株式会社 　シニアセキュリティエンジニア 　守屋 英一	セキュリティオペレーションセンターで日々顧客ネットワークを監視している立場から現状のWindows系サーバ上で動作するWebサーバとWebアプリケーションに対するインシデント事例などについて紹介した。 TOPIC：Phishing、 CSS(XSS)、 CSRF、 Pharming、スパイウエアとセキュリティ対策の最新情報

(JPNIC インターネット基盤企画部 根津智子)