JPNICJavaScriptが無効になっています。JavaScriptを有効にしてご利用いただくことで、より快適にご利用いただけます。特集3:サーバアプリケーションセキュリティ~JPNIC・JPCERT/CCセキュリティセミナー2005開催報告~xSPのオペレーターを対象としたJPNICと有限責任中間法人JPCERTコーディネーションセンター(JPCERT/CC)共催のセキュリティセミナーも、早いもので今年で3年目となり、今回の開催で8回目を数えます。この8回、「セキュリティ対策に特効薬はない」という考えから、毎回違う側面からのプログラムを提供するよう心掛けてきましたが、8回行ってもまだまだ語るべきことが多いことに驚いています。一言で「インターネットセキュリティを確保する」といっても、実際にオペレーターの方々がやるべきことは多岐にわたり、一つの事象に対応するには包括的な観点でセキュリティをとらえなくてはいけないことを、今更ながらに痛感しています。JPCERT/CCの代表理事であり、JPNICの理事でもある歌代和正は、今回のセミナーの中で、インターネットセキュリティの多面性を次のように表現していました。「インターネットセキュリティ」にはいろいろな切り口があります。「ネットワークのセキュリティ」と「コンピュータのセキュリティ」に分けることができます。「コンピュータセキュリティ」には、クライアントPCのセキュリティもあるし、その対極にある管理者が運用するサーバのセキュリティもあります。それぞれのセキュリティは、最も基本的な「OSのセキュリティ」から「ミドルウェアのセキュリティ」「アプリケーションのセキュリティ」と階層的な構造を持っています。ISPや、ネットワークを利用して何らかのサービスを提供するxSPの方々がいかにセキュアにインターネットを通じてサービスを提供するかを考えた場合、そのサービスを提供するためのサーバのセキュリティをどのように確保するかは極めて重大な課題です。最近のソフトウェアは非常に大規模化し、手を入れて対策できる部分は少なくなってきていますが、個々のアプリケーションの動作原理を理解することは重要です。その上で、それらをどう設定し、ミドルウェアやオペレーティングシステムとのインタラクションをどのようにとっていくのかということが「オペレーターに求められる技術」と言えるのではないでしょうか。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が動いているからいいが、パッチに不具合があって落ちるのはよくないという考えです。動作の不具合の無いことが確認されたパッチができるまではパッチを公開しない、遅らせてもいいという仕組みができればできるほど、脆弱性に対する対応は遅れると私自身は危惧しています。結局メーカーは経済原則に基づいて動いているので、ユーザーがそれでいいよと思っていると、そうなってしまうものです。-聞くところによると、日本ではパッチの適用率が高いらしいです。一方で、むしろ「パッチをあてたくありません」という声も大きいのではないでしょうか。パッチをあてるとサーバが止まる可能性をはらむからです。いったことはサーバの環境に依存するので予測が不可能です。ハマった経験がある、もしくはハマったということを聞いたことがある人は多いでしょう。調子が悪くなるなら、あてないほうがマシという人がいることは決しておかしなことではありません。そのような危険性をはらみながら、「緊急」と言われても「いつあてるか」が判断できないというのは当然のことではないでしょうか。「緊急」というものに対して、システム管理者が自分の責任範囲で「いつ」ということを判断するのはナンセンスです。自分のスキルに非常に自信があるとか、正義感が特別強い、という個人の属性に依存する部分が大きすぎます。パッチをあてたくてもアプリケーションやドライバが対応していないのであてられないことも良くあることです。その事実だけで社会的批判を浴びるはずです。重大な欠陥のある部品が見つかったら、代替機を用意し運行をやめ、部品を交換するでしょう。それは整備士の判断で行うわけではありません。経営者の判断が必ずあり、部品交換による運行続行の仕組みや環境の構築にも責任を負うでしょう。費用もかかるからです。彼らは「人命より優先されるものはない」と必ず言うでしょう。オンラインバンキングで欠陥のあるサーバを使っていたらそれだけで社会的批判を浴びる、と思うのではないでしょうか。-私はまず、パッチ適用のリスクは経営者が負うべきであると考えています。Plan:BCP)」という概念があります。「事業をいかに継続させるか」ということですが、ある意味、事業をきちんと継続させようと思うのであれば、部品の交換やメンテナンスをするというのは当たり前です。パッチあても同等にとらえられるべきです。これらは全てBCPに含まれるべき内容です。サーバの管理者は「サーバを一秒たりとも止めることは許されない」を大玉条のように掲げています。掲げるから何もできなくなるのです。「脆弱性」というから経営者も判断を誤るのです。経営者の耳に届けるときには、「ウィルスにかかる【欠陥】があります。それを避けるにはサーバを止めてパッチをあてなくてはいけません。すると二度と立ち上がらなくなる可能性があります。しますか?」とストレートに伝えるべきです。大事なサーバを止める判断もパッチをあてないで運用を続けるリスクもシステム管理者が考えることではなく、ビジネスの問題であり、経営者が考え、責任を負うべき事項です。いった不測の事態に備え、検証環境の構築は組織の責任としてきちんと果たしてほしいと思います。経営者が重要なサーバがシングルで動いていることがおかしいことを理解し、基本的にはシステムをテスト環境と本番環境と二重化しておく措置をとるべきです。パッチをあてなくても済む環境の検証と構築も必要です。パッチが出たからといって必ずしも絶対にあてなくてはいけないということではないかもしれません。ファイアウォールやパケットフィルタリングの設定による攻撃の無効化、サーバとして不要なサービスの停止や削除で、あてなくてもいい可能性もあります。設定で逃げられることもあります。いったことを総合的に理解して、今回出た「緊急」のパッチをあてるか否か判断することは脆弱性に対する深い技術的知識と自信がないとできないことです。いった企業や顧客を守る重要なシステムにおける検証環境の構築に対する適正な費用の負担をするということが、経営者に求められることです。勇気ある人にスポットライトを私は常々、「パッチによる不具合情報の積極的な共有をしたらどうか」ということを考えています。厳しい秘密保持契約を結んだ上であれば、「勇気ある」ユーザーグループによるパッチの動作確認が事前にあってもいいのではないでしょうか。「不具合が生じた・生じなかった環境(ドライバのバージョン・CPUの構成・アプリケーション/ミドルウェアの情報)」のマトリクスがあれば、例えば自力で検証環境を構築する体力のない会社の経営者もこれを見れば何に対処すべきかわかります。少々過激な意見かもしれませんが、まじめにパッチに対応する企業か否かの情報公開があってもいいかもしれません。残念ながら今のところこういった大きな取り組みはありません。取り組みには費用もかかり、当然ボランティアではできませんし、勇気あるユーザーグループへのインセンティブも必要です。自分達で自分達の製品の品質を上げようとするなら、常に誰かのせいにするのではなく、勇気を持つことも必要なのではないでしょうか。いった勇気を持てる人にスポットライトをあてるべきです。自分達のサービスに誇りを持ちたいなら、メーカーに責任を押し付けるだけでは解決しない問題なのですから。Unix系サーバを安全に構築する為の基本的な考え方や、OSやサーバアプリケーションのセキュアな設定方法について、また実際に運用していく上での注意点についてなどを解説した。Unix系サーバ上で動作するDNSサーバ、システムにおけるインシデント事例を紹介した。ソフトウェアごとのセキュリティ対策の違い、規模別設定の違いについて紹介した。メールサーバ/システムが直面しているセキュリティ上の脅威は、今日ではその大部分が「迷惑メール」に関連していると言える。メールサーバを運用していくにあたって考慮すべきセキュリティリスクとその対策を「迷惑メール」を切り口に解説した。前半では、フィッシング詐欺等で利用される技術とXSS・CSRFを中心にしたWebアプリケーションセキュリティの仕組みについて解説し、更に対策を考察した。後半では、取り上げてきたWebのセキュリティを分類し、関係してくる立場と取られるべき対策についてまとめた。Serverを安全に運用するためのセキュリティ設定および、基本的な考え方について、幾つかの組織規模別に解説した。Directoryとの関係性について解説。実践的なセキュリティ設計や展開方法、また、UNIX環境におけるDNSとの相互運用性についても説明した。近年、様々な用途で活用が広がっているRADIUS。ダイヤルアップ接続での認証プロトコルであったRADIUSが、どのようにして無線LANや認証VLANの認証サーバとして利用されているのか。数々指摘されている脆弱性には、どのようなものがあるのか。それら脆弱性の対策について、どのような事柄に留意すればよいのか。プロトコルの機能の観点から解説した。セキュリティオペレーションセンターで日々顧客ネットワークを監視している立場から現状のWindows系サーバ上で動作するWebサーバとWebアプリケーションに対するインシデント事例などについて紹介した。トピックスとお知らせ一覧2019年2018年2017年2016年2015年2014年2013年2012年2011年2010年2009年2008年2007年2006年2005年2004年2003年2002年2001年2000年1999年1998年1997年Web更新履歴一覧2020年の更新履歴2019年の更新履歴2018年の更新履歴2017年の更新履歴2016年の更新履歴2015年の更新履歴2014年の更新履歴2013年の更新履歴2012年の更新履歴2011年の更新履歴2010年の更新履歴2009年の更新履歴2008年の更新履歴2007年の更新履歴2006年の更新履歴2005年の更新履歴2004年の更新履歴2003年の更新履歴2002年の更新履歴Q&AIPアドレスWHOIS/DBJPNIC認証局ドメイン名ニュースレター/メールマガジン会員JPNICについて統計よくある質問イベントカレンダー2020年2019年2018年2017年2016年2015年2014年2013年2012年2011年2010年2009年2008年2007年2006年2005年2004年2003年2002年2001年2000年1999年1998年1997年1996年1995年1994年1993年WHOISGateway表示例このページを評価してくださいこのWebページは役に立ちましたか?役に立った役に立たなかったどちらとも言えないページの改良点等がございましたら自由にご記入ください。回答を差し上げられません。回答が必要な場合は、お問い合わせ先をご利用ください。Views)登録パスワードが記載された確認メールが発送されます。再度ご登録手続きを行ってください。Views)登録パスワードが記載された確認メールが発送されます。再度ご登録手続きを行ってください。