オープンソース・ソフトウェアのセキュリティ確保 …オープンソース・ソフトウェアのセキュリティ確保に関する調査報告書第Ⅳ部

オープンソース・ソフトウェアの

セキュリティ確保に関する調査報告書

第Ⅳ部

オープンソース・ソフトウェアをセキュアに保つための

運用ガイド

情報処理振興事業協会

セキュリティセンター

第Ⅳ部オープンソース・ソフトウェアをセキュアに保つための運用ガイド

Ⅳ- i

目次

1. はじめに ...................................................................................................................... 1

2. 運用における基本的な考え方 ...................................................................................... 2

2.1. オープンソース・ソフトウェアの運用にあたり認識すべきこと .............................. 2 2.2. 現状のオープンソース・ソフトウェアの運用形態 .................................................... 4 2.3. オープンソース・ソフトウェア運用モデルの分類 .................................................... 7

3. オープンソース・ソフトウェアをセキュアに保つための運用方法.............................. 9

3.1. セキュリティ情報の収集............................................................................................ 9 3.1.1. オープンソース・ソフトウェアコミュニティ ..................................................... 10 3.1.2. セキュリティ情報提供組織 .................................................................................. 11 3.1.3. ディストリビュータ ............................................................................................. 13 3.1.4. システムインテグレータ ...................................................................................... 15 3.1.5. セキュリティ情報提供ベンダ............................................................................... 16 3.1.6. セキュリティ情報収集リソースの選択 ................................................................ 17 3.2. セキュリティ情報への対応 ...................................................................................... 18 3.2.1. パッチ適用手順の概要.......................................................................................... 19 3.2.2. セキュリティ管理者グループ............................................................................... 20 3.2.3. パッチ適用時の作業項目 ...................................................................................... 20 3.2.4. システム管理者のパッチ適用責任........................................................................ 24 3.3. インシデントへの対応 ............................................................................................. 26 3.3.1. 一般的なインシデント発見時の対応手順............................................................. 26 3.3.2. オープンソース・ソフトウェアにおけるインシデント対応................................ 29

4. まとめ........................................................................................................................ 31


Ⅳ- ii

図目次

図 1. 現状のオープンソース・ソフトウェア運用形態........................................................ 4 図 2. 自組織のみで情報の収集と対応をするケース ........................................................... 7 図 3. 有償外部リソースから情報を収集して、自組織で対応するケース........................... 8 図 4. 有償外部リソースに情報の収集と対応を依頼するケース ......................................... 8 図 5. 例）ICAT の検索画面 .............................................................................................. 21 図 6. セキュリティ管理者グループを取り巻く連携環境 .................................................. 24 図 7. システム管理者の役割とセキュリティ管理者グループとの連携 ............................ 25


Ⅳ- iii

表目次

表 1. 図 1 における各々の役割............................................................................................ 5 表 2. セキュリティ情報提供組織の分類 ............................................................................. 9 表 3. その他情報提供を行っている組織........................................................................ 13 表 4. LINUX における主要なディストリビューション ..................................................... 14 表 5. オープンソース・ソフトウェアを推進する主なシステムインテグレータ.............. 16 表 6. オープンソース・ソフトウェアにおけるインシデント対応表 ................................ 29 表 7. オープンソース・ソフトウェア運用モデルと作業項目対応のまとめ ..................... 31


Ⅳ- 1

1. はじめに近年、情報インフラの構成要素としてオープンソース・ソフトウェア(Open Source

Software)が利用されるケースが増えてきている。その一方で、オープンソース・ソフト

ウェアの安全性が重要な問題となってきている。オープンソース・ソフトウェアでは、

基本的にセキュリティは保証されておらず、自己責任において利用されるべきものとさ

れている。しかし、オープンソース・ソフトウェアのセキュリティについて深く検討も

せず導入を行ったために、その脆弱性をつかれて、不正にアクセスされる例は年々増大

しており、利用者側でのオープンソース・ソフトウェアの安全性確保が急務とされてき

ている。オープンソース・ソフトウェアは、従来のソフトウェアとはまったく異なる開発方法

をとっている。オープンソース・ソフトウェアは、インターネットを利用して協調的に

開発されており、頻繁にバージョンアップがなされる。こうしたオープンソース・ソフ

トウェアの特徴は、オープンソース・ソフトウェアを運用していく場合にも、従来のソ

フトウェアとは違った運用方法が求められる。例えば、オープンソース・ソフトウェア

では、利用者側でバージョンアップ情報を把握し、適切にソフトウェアのバージョンを

実施しなければならない。また、利用しているソフトウェアのセキュリティ問題などは、

利用者で積極的に情報を収集し、対応していく必要がある。オープンソース・ソフトウェアを情報インフラとして利用していくためには、セキュ

リティを十分考慮した運用管理が必然的に必要になってくる。本ガイドは、利用者がオ

ープンソース・ソフトウェアをセキュアに利用するにあたっての保守、運用方法及びコ

ミュニティとのかかわり方について網羅的にまとめたものである。本ガイドでは、第 2 章にてオープンソース・ソフトウェアの運用における基本的な考

え方、第 3 章でオープンソース・ソフトウェアをセキュアに保つための運用方法、そし

て第 4 章において全体のまとめを行う。


Ⅳ- 2

2. 運用における基本的な考え方オープンソース・ソフトウェアにおける運用は、一般のソフトウェアと比較してどの

点が異なるのであろうか。オープンソース・ソフトウェアは数年前までは、今日ほど多

くビジネスで利用されてこなかった経緯もあり、運用面に関して、細かな議論がされて

こなかったように思われる。ソースコードが開示されていたり、開発コミュニティによ

るオープンな開発がされていたりといったオープンソース・ソフトウェアの特徴は、運

用に対してどのような影響を及ぼすのかは困難な質問である。本章では、はじめにオー

プンソース・ソフトウェアの運用において、従来のソフトウェアとは区別して意識すべ

きことについて整理し、さらに、今日行われているオープンソース・ソフトウェアの運

用を概観する。

2.1. オープンソース・ソフトウェアの運用にあたり認識すべきこと

オープンソース・ソフトウェアの運用に当たり、従来のソフトウェアの運用と区別

して認識すべき事項を以下のように整理する。 1) ソフトウェア開発

オープンソース・ソフトウェアの開発は従来のソフトウェア開発と異なること

を認識すべきである。オープンソース・ソフトウェアの開発については、1997 年

に Eric S.Raymond（エリック・レイモンド）によって発表された「The Cathedral and the Bazar1（伽羅とバザール）2」が詳しい。この著書では、従来のソフトウ

ェア開発と新しいオープンソースパラダイムとの比較が行われている。伽羅方式

は、閉じたグループソフトウェア開発手法を意味し、そして、デザインと実装は

グループ内のみで、部外者とはごく限られた範囲内、またはそれすらない中で行

われる。一方、バザールのメンバは、開発プロセスにおいて出入り自由で緩やか

に編成された集団内で作業する。新しいオープンソース活動の管理スタイルは、

全く異なっており、緊密な関係を有する集団を持つのではなく、より多くの人に

参加してもらおうとしている。誰でもソースコードを調べ改善することができる

ので、結果として非常に洗練されたものになる。ここで重要なのは、ソフトウェアの開発プロセスがまったく異なるという点で

ある。運用の視点からすれば、オープンソース・ソフトウェアでは、開発の責任

主体を特定することが困難となる。開発面でのこうしたオープンソース・ソフト

ウェアのメリットは、運用面での開発の責任主体の欠如につながる可能性を持つ。

1 原文 http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ 2 山形浩生氏の和訳 http://cruel.org/freeware/cathedral.pdf


Ⅳ- 3

2) サポートの考え方オープンソース・ソフトウェアと従来のソフトウェアでは、サポートの考え方

が異なることを認識すべきである。オープンソース・ソフトウェアでは、コミュ

ニティにおけるメーリングリスト、ニュースグループ等が主なサポート方法であ

り、コミュニティ自体には商用ソフトウェアに相当するサポートサービスが存在

するわけではない。しかしながら、Linux や Apache 等の知名度の高いオープンソ

ース・ソフトウェアについては、営利企業がサポートビジネスを展開しているた

め、有償によるサポートを受けることができる。（これについては、オープンソー

ス・ソフトウェア運用モデルの分類で詳述する。）しかしながら、すべてのオープ

ンソース･ソフトウェアにおいてサポートが十分に受けられるわけではなく、利用

者本人が独自にサポートの体制を構築しなければならない場合もある。 3) セキュリティへの対策

オープンソース・ソフトウェアと従来のソフトウェアではセキュリティへの対

応が異なることを認識すべきである。オープンソース・ソフトウェアであれ、商

用ソフトウェアであれ、バグなどにより、セキュリティのリスクがあることは同

じである。しかしながらこれらのバグの発生において、商用のソフトウェアでは、

ベンダがそのバグに対応しない限り、バグへの対処の方法はない。それに対して、

オープンソース・ソフトウェアではソースコードが開示されているために、場合

によっては利用者本人が、ソースコードを修正することも可能である。従来のベ

ンダに依存したセキュリティ対策は、オープンソース・ソフトウェアではより選

択の幅の広いものとなる。利用者は、どのようにセキュリティの対策を実施して

いかなければならないのか選択しなければならない。またセキュリティ対応のた

めに、さまざまなセキュリティ情報の収集、対応、そしてインシデントへの対応

を実施していかなければならない。（これらについては第 3 章、第 4 章にて詳述す

る。） 4) 運用コスト

オープンソース・ソフトウェアと従来のソフトウェアでは、運用のコストが異

なることを認識すべきである。従来のソフトウェアではベンダへの保守費が発生

したり、委託先の会社への運用費が発生するが、オープンソース・ソフトウェア

では、ソフトウェアそのものに対して保守費用が発生しないものが多い。（場合に

よっては有償で保守を提供するものもある。）そのため、利用者の選択によっては、

直接的な運用コストを抑えることが可能である。しかしながら、独自に運用を実

施しようとした場合の人件費や教育費など間接的な費用が発生してくる。運用コ

ストの違いは、コストの高・低ではなく、多様な運用形態を選択することが可能


Ⅳ- 4

であるため、従来のソフトウェアに比較して、運用コストを低く抑える可能性を

持っているという点である。利用者は、こうした点を十分考慮した上で、運用の

体制を決定していかねばならない。

2.2. 現状のオープンソース・ソフトウェアの運用形態

オープンソース・ソフトウェアは、商用ソフトウェアと比較して、利用に対して自由

度の高いソフトウェアであり、運用においても同様のことが言える。商用ソフトウェア

の運用では、主にソフトウェアベンダとエンドユーザ間においてサポート契約を締結す

るが、オープンソース・ソフトウェアでは、エンドユーザが様々なサポートを選択する

ことが可能である。つまり、サポート提供元とそのサポートのレベルを自由に組み合わ

せることができ、かつオープンソースの特徴でもあるソースコードの開示により透明性

の高い情報を入手することも可能である。このように自由度の高いオープンソース・ソ

フトウェアの運用形態をまとめると図 1のようになる。

図1. 現状のオープンソース・ソフトウェア運用形態

図 1 における各々の役割は、表 1のように定義される。

システムインテグレータ（S/W,H/W系）

セキュリティ管理者（エンドユーザ）

ディストリビュータ

（Linux　etc）

OSSコミュニティ

セキュリティ情報提供

組織（無償）

セキュリティ情報提供

ベンダ（有償）


Ⅳ- 5

図中の組織・企業役割

OSS コミュニティ

オープンソース・ソフトウェア開発者達のコミュニティ。世界

最大のオープンソースコミュニティである SorceForge による

と、5 万件以上のオープンソース・ソフトウェアプロジェクト

が稼働し、50 万人以上のメンバが登録されている。セキュリティ情報提供組織（無償）

セキュリティ対策の関連情報を無償で提供している組織で、政

府関係機関あるいは非営利団体等が活動している。

セキュリティ情報提供ベンダ（有償）

セキュリティ対策の関連情報を有償で提供している組織で、企

業として取り組んでいる。このセキュリティ情報提供ベンダは、

CERT/CC 等の公的機関をはじめ、大学、研究所、H/W・S/Wベンダ、アンダーグラウンドにいたるまで幅広いソースから情

報を収集している。更に、収集した情報は、その信頼性と危険

度を検討して、対象となるサーバやアプリケーションに関する

ものを取捨選択して提供している。

ディストリビュータ (Linux etc.)

ディストリビューション（出自の様々なプログラムを集めたソ

フトウェア頒布物）を作成・配布している、組織・団体・個人

のこと。例えば、Linux の分野では、Red Hat、Debian、SuSE等が広く知られている。

システムインテグレータ（S/W, H/W 系）

ここでのシステムインテグレータは、オープンソース・ソフト

ウェアをベースに顧客の要望に合ったソリューションとして、

システムをインテグレートする組織（企業）のこと。セキュリティ管理者（エンドユーザ）最終のオープンソース・ソフトウェア利用ユーザ

表1. 図 1 における各々の役割

図 1に示すように現状のオープンソース・ソフトウェアの運用においては、複数のパス

が存在している。これは、エンドユーザにとって自由度の高い選択が可能になることを

意味している。しかしながら、オープンソース・ソフトウェアの運用の自由度は、運用

の考え方を複雑化する要因にもなっている。例えば、エンドユーザ企業におけるセキュリティ管理者は、システムインテグレータ、

ディストリビュータのサポートを一切受けずに、自ら全ての情報を入手し対策を実施す

ることが可能である。一方、オープンソース・ソフトウェアのセキュリティ情報の収集

及び対策をすべて、システムインテグレータへ委託してしまうことも可能となる。もち

ろん、一部をシステムインテグレータへ委託し、さらに一部をディストリビュータへ委

託することもあり得る。更に、オープンソース・ソフトウェアのサポート形態の多様さ

が、エンドユーザの選択の幅を広げている。オープンソース・ソフトウェアのサポート

は以下のようなものが存在している。


Ⅳ- 6

(1) インストールサポート

Linux ディストリビュータでは、一般的に 60-90 日間に限り無償のインストー

ルサポートを提供している。 (2) サポートパッケージ

Linux ディストリビュータでは、トラブルの対応可能な件数3に応じて製品をパ

ッケージ化している。 (3) 年間契約

年間契約により提供されるのサポートの特徴は、ベンダごとに様々である。契

約の内容としては以下のようなものがある。 - 時間･･･例：24h×7days で 365days をカバー - リアクションタイム･･･例：8 時間以内のリアクション - サポートプロダクトリスト･･･ハードウェアおよびソフトウェア含む - パーソナリゼーション･･･個々のカスタマイズ - パッチ＆アップデート管理･･･バージョンアップ含む

(4) 特注開発とソフトウェア・インテグレーション

グローバルなプロジェクト管理とソフトウェア・インテグレーションサービス

を要求するような大企業等では、特別な開発および製品インテグレーションを提

案するようにリクエストすることもある。 (5) オープンソース無償サポート

オープンソースコミュニティを利用した無償サポートである。このようにインストールのサポートからカスタマイズ（特注開発含む）を含めたトー

タルなサポートまで、幅広いサービスが存在している。そのため、オープンソース・ソ

フトウェアの利用者は、2.1で説明したオープンソース・ソフトウェアの特性を考慮しつ

つ、運用について検討する必要がある。更に、これらの運用方式の選択は運用コストに

も非常に関わるため、オープンソース・ソフトウェア運用の多様性を考慮して運用方式

を検討することが重要である。

3 インシデントパックあるいはコールパックと呼ばれることが多い。


Ⅳ- 7

2.3. オープンソース・ソフトウェア運用モデルの分類

本調査においては、オープンソース・ソフトウェアの運用の現状についてオープンソー

ス・ソフトウェアの運用をビジネスとして実施している企業に対して、ヒアリング調査を

実施した。その結果、運用形態を大きく以下の 3 つのモデルに分類することができること

が明らかになった。これらは、図 1の関係を単純化してモデル化したものである。（モデル 1）自組織のみで情報の収集と対応をするケース

セキュリティ管理者が自組織のみでオープンソース・ソフトウェア情報をコミュニ

ティ、あるいはセキュリティ情報提供組織から収集し、その対応を行うケースである

（図 2参照）。このケースでは、セキュリティ管理者が全てのオープンソース・ソフト

ウェア情報の収集を行い、必要に応じて組織メンバへのアナウンス、そして管理サー

バへの対策を施す必要がある。自組織でオープンソース・ソフトウェアに精通したセ

キュリティ管理者をアサインできるか等がポイントとなる。

図2. 自組織のみで情報の収集と対応をするケース

（モデル 2）有償外部リソースから情報を収集して、自組織で対応をするケース

セキュリティ管理者が有償の外部リソースである情報提供ベンダ、ディストリビュ

ータ、あるいはシステムインテグレータから情報のみを収集し、対応については自ら

行うケースである（図 3参照）。このケースでは、セキュリティ管理者に代行して、有

償外部リソースから全てのオープンソース・ソフトウェア情報の収集を行い、必要に

応じて組織メンバへのアナウンス、そして管理サーバへの対策を施すものである。セ

キュリティ管理者は、情報の収集を外部リソースへ委託できるため、社内のセキュリ

ティ対策に専念できる。


組織メンバ

セキュリティ情報提供組織（無償）管理サーバ

OSSコミュニティアナウンス

対策


Ⅳ- 8

図3. 有償外部リソースから情報を収集して、自組織で対応するケース

（モデル 3）有償外部リソースに情報の収集と対応を依頼するケース

セキュリティ管理者が有償の外部リソースである情報提供ベンダ、ディストリビュ

ータ、あるいはシステムインテグレータから情報を収集すると共に、その対応も外部

へ委託するケースである（図 4参照）。このケースでは、対応に関しては、主にシステ

ムインテグレータがそれを担うことになる。このような完全なアウトソース化により

セキュリティ管理者の運用工数は大幅に軽減される。このケースは、商用ソフトウェ

アの運用と同じであり、オープンソース・ソフトウェアであることを強く意識する必

要はない。

図4. 有償外部リソースに情報の収集と対応を依頼するケース

以上、3 つのモデルにオープンソース・ソフトウェアの運用形態を分類したが、どのモ

デルに従ってオープンソース・ソフトウェアの運用をしていくのかによって大きく運用

作業の項目が異なる。本報告書では、これらのモデルと運用時に実施すべき運用項目を

整理していくことによって、オープンソース・ソフトウェアを利用していくにあたり、

どのように運用を考えていけばよいのかについて取りまとめていく。以降の章では、3 つ

のモデルを通じてセキュリティ管理者が行わなければならないことを整理する。

組織メンバ

セキュリティ情報提供組織（無償）

管理サーバ


アナウンス

対策

情報提供ベンダ（有償）ディストリビュータ

システムインテグレータ


組織メンバ

管理サーバ

アナウンス

対策セキュリティ情報提供組織（無償）


情報提供ベンダ（有償）ディストリビュータ

システムインテグレータ



Ⅳ- 9

3. オープンソース・ソフトウェアをセキュアに保つための運用方法本章では、第 2 章で説明したオープンソース・ソフトウェア運用における基本的な考

え方を踏まえて、ユーザ自ら中心に運用を行う場合に、実施しなければならない以下の 3つの項目についてまとめる。

1) セキュリティ情報の収集

2) セキュリティ情報への対応（パッチ適用等） 3) インシデントへの対応

3.1. セキュリティ情報の収集

セキュリティ情報の収集リソースとして、主にオープンソース・ソフトウェアコミュ

ニティ、およびセキュリティ情報提供組織を取り上げる。オープンソース・ソフトウェ

アコミュニティは、セキュリティ情報提供を中心にした組織でないが、オープンソース・

ソフトウェアコミュニティ全般の情報が集約されており、情報収集の要となるので取り

上げることにする。本節では、下記の表 2で示す 5 つの分野に情報提供組織を分類し、そ

れぞれどのような情報が提供されているのかについて整理する。各分野は、取り扱う分

野、提供する情報なども異なるほか、情報の取得時のコストもかわってくる。情報収集

の際には、これらに注意し、自身の環境にあった情報提供元を選択する必要がある。

情報提供組織の分類分野情報コストオープンソース・ソフトウェ

アコミュニティ特定のもの脆弱性情報・改善策・パッチ等なし

セキュリティ情報提供組織一般脆弱性情報・改善策等なし

ディストリビュータディストリビ

ューション脆弱性情報・改善策・パッチ等なし*

システムインテグレータ一般脆弱性情報・改善策等あり* セキュリティ情報提供ベンダ一般脆弱性情報・改善策等あり*

* 一部例外もある。

表2. セキュリティ情報提供組織の分類

尚、本報告書で取り上げる情報提供組織は、調査段階で一般的に知られているところ

を参考として抜粋したものであり、全ての情報提供組織を網羅しているものではない。

また、これらの取り上げた情報提供組織を、情報処理振興事業協会として推奨するもの

ではなく、なんらの表明を行うものではない。あらかじめご承知おき願いたい。


Ⅳ- 10

3.1.1. オープンソース・ソフトウェアコミュニティ

3.1.1.1. Free Software Foundation (FSF) Free Software Foundation (以下、FSF) は、コンピュータ・プログラムの使用や複写、

修正、再配布に関する人々の権利の制限を排除することを目的としている団体である。

これを遂行するために、FSF は、あらゆるコンピュータ利用の分野で、フリーソフトウ

ェアの開発と利用を促進しており、特に、Unix と上位互換性のある「GNU」 (GNU's Not Unix.: GNU は Unix ではない。「グヌー」と発音する) という名の完全な統合化ソフ

トウェア・システムを作成している。GNU フリーソフトウェア（約 1900 パッケージ）

に関する一覧を利用して、目的とするソフトウェアを検索することが可能である。

3.1.1.2. Open Source Initiative (OSI) Open Source Initiative(OSI)は、オープンソース宣言ともいえる論文「The Cathedral

and the Bazar（伽藍とバザール）」(1998)の作者である Eric S.Raymond（エリック・レ

イモンド）を中心にオープンソース運動の推進組織として 1998 年 12 月に設立された。

OSI では、オープンソース・ソフトウェアの定義（Open Source Definition: OSD）、オ

ープンソース・ソフトウェアの認定を行い、オープンソースという商標を管理する非営

利法人である。尚、OSI にリンクされているサイト（freshmeat.net, SourceForge, OSDir.com, BerliOS, Bioinformatics.org）を通じて、様々な個別のオープンソース・ソ

フトウェアの情報を入手することができる。

3.1.1.3. フリーソフトウェアイニシアティブフリーソフトウェアイニシアティブは、フリーソフトウェアおよびフリードキュメ

ント (以下フリーソフトウェア等という)の開発者および利用者に対して、フリーソフ

トウェア等に関する国際大会の開催、情報交換と国際的交流の支援、フリーソフトウ

ェアデータベースの整備とその公開、フリーソフトウェア等に関する技術講座の開催

の事業を行っている。セキュリティ情報の収集・発信においても、そのような取り組

みの中で、広く意見交換がなされている。

URL http://www.gnu.org/directory/

URL http://www.opensource.org/

URL http://fsij.org/


Ⅳ- 11

3.1.1.4. SourceForge.jp SourceForge.jp は、オープンソース・ソフトウェアの開発者に CVS、メーリングリ

スト、バグ追跡システム、掲示板・フォーラム、タスク管理システム、 Web サイトホ

スティング、そして、それらを Web ベースで総合的かつ容易な管理を行う環境を提供

する無料のサービスである。この SourceForge.jp は、50,000 以上のオープンソース・

ソフトウェアが登録されており、SourceForge.net (SF.net) の日本でのサイトである。

セキュリティ情報については、各提供サービスの中で意見交換されており、特にバグ

追跡システムでは、バグの情報入手および利用者からのバグの提出を行うができるよ

うになっている。

3.1.2. セキュリティ情報提供組織

3.1.2.1. CERT/CC CERT/CC は、1988 年に米国国防総省高等研究計画局（DARPA： the Defense

Advanced Research Projects Agency）の出資により、カーネギーメロン大学のソフトウ

ェア工学研究所(Software Engineering Institute)内に設置された、セキュリティ上の脅

威に対応するための組織である。主な活動としては大規模な脅威への対処、脅威への対

処を行う専門家の育成、セキュリティ上の脆弱性についての調査などがあり、それらの

活動の一環としてセキュリティ対策情報の提供が行われている。

3.1.2.2. JPCERT/CC JPCERT/CC とは、 Japan Computer Emergency Response Team/Coordination

Center（コンピュータ緊急対応センター）の略称である。非営利団体で、特定の政府機

関や企業からは独立し、中立の組織として活動している。JPCERT/CC は、インターネ

ットを介して発生する、侵入やサービス妨害などのコンピュータセキュリティ・インシ

デントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の

把握、手口の分析、再発防止のための対策の検討と助言などを、技術的な立場から行っ

ている。

URL http://sourceforge.jp/

URL http://www.cert.org/

URL http://www.jpcert.or.jp/


Ⅳ- 12

3.1.2.3. IPA セキュリティセンター (IPA/ISEC) IPA セキュリティセンター（IPA/ISEC）は、わが国において情報セキュリティ対策の

必要性・重要性についての認識を啓発・向上し、具体的な対策実践情報・手段を提供す

るとともに、セキュアな情報インフラストラクチャ整備に貢献することをミッションと

している。IPA セキュリティセンターでは、IT ユーザ向けに、総合的な情報セキュリテ

ィに関する情報、ウィルス対策、そして不正アクセス対策に関する情報を公開している。

また、IT ベンダ向けにおいても、暗号技術、セキュリティ評価・認証に関する情報を公

開している。

3.1.2.4. SANS SANS (SysAdmi Audit Network Security)研究所は、協同研究および教育組織として

1989 年に設立された。SANS 研究所は、156,000 人を越えるセキュリティ専門家、監査

人、システム管理者およびネットワーク管理者が、研修・教育を共有し、かつ直面する

問題の解決策を見つけることを可能にしている。SANS の中心は、情報セキュリティコ

ミュニティ全体を支えるために、毎年研究と教育で何百もの時間を投資する、世界中の

政府系機関、企業および大学の多くのセキュリティ従事者がいる。また、ホームページ

ではネットワークセキュリティ全般に関する広範囲な情報が提供されている。特に、毎

週メールにて発行される無料のダイジェストでは、セキュリティニュース、脆弱性等の

情報を入手することが可能である。

3.1.2.5. CVE CVE (Common Vulnerabilities & Exposures)は、既知のセキュリティの弱点やセキュ

リティの欠陥についての表現を定義し、カタログ化し、標準化しデータベースとして提

供している。ここでの標準化された名前の使用は、これまで統合されなかった個別のデ

ータベースおよびツールを整理し、データを共有できるようにしている。

URL http://www.ipa.go.jp/security/

URL http://www.sans.org/

URL http://www.cve.mitre.org/


Ⅳ- 13

3.1.2.6. その他

組織名 URL

Internet Storm Center http://isc.incidents.org/ Computer Incident Advisory Capability

http://www.ciac.org/ciac/

Department of Defense CERT http://www.cert.mil/ Federal Computer Incident Response Capability (FedCIRC)

http://www.fedcirc.gov/

Forum of Incident Response and Security Teams (FIRST)

http://www.first.org/

Computer Security Resource Center (CSRC)

http://csrc.nist.gov/

ICAT (CVE Vulnerability Search Engine)

http://icat.nist.gov/

表3. その他情報提供を行っている組織

3.1.3. ディストリビュータオープンソース・ソフトウェアの中には、フリーで配布しているものだけではなく、

ディストリビューションの流通形態をとるものもある。特に Linux においては、Red Hat Linux, SuSE Linux に代表されるような、有名なディストリビューションが存在する。

このようなディストリビューションを利用する場合は、ディストリビュータからの公表

されるセキュリティ情報を Web、 Mail 等を通じて入手することができる。表 4に主要な

Linux のディストリビューションリストを示す。

ディストリビュー

ション説明・URL

Red Hat 米 Red Hat, Inc.が手がけるデファクトスタンダードといえるディ

ストリビューション。大きな特徴としては、自社開発した RPM に

より、手軽にパッケージのインストールなどができるよう配慮され

ている点である。また、「Red Hat Network」により、導入してい

る Red Hat Linux に関する重要なアップデート、バグフィックス

などの情報収集、およびそれらの適用状況を一元管理できるサービ

スを提供している。尚、情報収集については、「Red Hat Errata」のサービスを利用することも可能である。

□ URL http://www.jp.redhat.com/support/ Turbo Linux ターボリナックス・ジャパン(パシフィック・ハイテックから社名変

更)が開発、販売している Linux ディストリビューション。日本語

との親和性が高く、日本語インストーラや追加パッケージなしで使

える日本語環境などを備えている。パッケージ管理システムには、

Red Hat Linux と同じ RPM を採用しており、多くの日本語の商用

アプリケーションソフトが対応している。サポート、教育、技術情

報（セキュリティアナウンス）等が提供されている。また、バグト


Ⅳ- 14

ラックの情報も検索することが可能である。 □ URL http://www.turbolinux.co.jp/support/

Miracle Linux

Miracle Linux は、サーバ用途を考慮したディストリビューション

であり、業務システムの中核となるサーバとしての Linux の利用を

推進する製品になっている。以下の URL では、Miracle Linux に

収納されているソフトウェアのセキュリティ情報をはじめ、最新ア

ップデート情報の提供や技術 Q&A、問題解決の支援が提供されて

いる。 □ URL http://www.miraclelinux.com/support/

Vine Project Vine が手がけるディストリビューション。インストーラを

はじめ、コマンドヘルプ（man）に至るところまでしっかりと日本

語化されている。さらにほかのディストリビューションと異なる点

として，「Vmail」（メーラ），「Vedit」（エディタ）を採用し，

Windows 環境と似た手軽に使えるツールを同梱している点に特徴

がある。以下の URL では、Vine Linux の更新・障害情報が製品バ

ージョン別に公開されている。 □ URL http://vinelinux.org/errata.html

Caldera 米 Caldera Systems が手がけるディストリビューションである。日

本語は、日本語対応追加パッケージ「かぼす」を利用できる。ベー

スとなっているのは Red Hat Linux である。製品の最新アップデー

ト、セキュリティに関する情報は、以下の URL にて調べることが

できる。 □ URL http://www.jp.caldera.com/support/

Laser5 Red Hat Linux を基に Laser5 が手がけているディストリビューシ

ョンである。Laser5 は、Red Hat の日本法人が設立される前に総

代理店として Red Hat Linux を提供していた。基本的には、Red Hat Linux と同等である。以下の URL で、製品の最新アップデー

ト、セキュリティに関する情報を調べることができる。また、Laser5のメーリングリストの登録もここで行うことができる。

□ URL http://www.laser5.co.jp/support/ SuSE SuSE Linux は、独 SuSE Linux が販売しているディストリビュー

ションであり、ヨーロッパを中心に高い人気がある。以下の URLでは、セキュリティ関するアナウンス情報を知ることができる。

□ URL http://www.suse.com/us/private/support/security/ Debian Ian Murdock 氏が設立したメーリングリストを利用し、投票によっ

て基本方針を決定するディストリビューションであり、Debian Project と呼ばれている。日本語対応のパッケージは、Debian JP Project が作成しているが、日本語対応の別ディストリビューショ

ンを作るのではなく、本家の Debian Project に統合される形となっ

ている。DEB による高度なパッケージ管理を特徴とするディスト

リビューションでもある。以下の URL では、セキュリティ問題を

積極的に公開しており、バグに関する情報もバグ追跡システムを利

用して調べることが可能である。また、セキュリティ問題への対応

も迅速に行われている。 □ URL http://www.debian.org/support/

表4. Linux における主要なディストリビューション


Ⅳ- 15

3.1.4. システムインテグレータ近年、システムインテグレータの中には、オープンソース・ソフトウェアを積極的に

提案ソリューションの一部に利用し始めているものもある。そのようなシステムインテ

グレータは、Linux を中心にサポートサービスを含む広範囲なオープンソース・ソフトウ

ェアソリューションを提供している。表 5に、主要な大手システムインテグレータのリス

トを示す。特に、最近では NEC、日立、富士通、日本 IBM の 4 社において、共同でエ

ンタープライズ領域に向けた Linux 機能強化およびオープンソースコミュニティへの提

案をすることに合意し、活動が開始されている。インテグレータ取り組み概要・URL

NEC

NEC は、オープンソース・ソフトウェアに関わる戦略検討とオープン

ソース・ソフトウェアを活用したソリューション開発・検証を専門的に

行う「OSS ソリューションセンター」と、Linux を技術的に統括、サ

ポートする「Linux 技術センター」を創設し、最適なオープンソース・

ソフトウェアソリューションの提供を行っている。OSS ソリューショ

ンセンターと Linux 技術センターが中核となり、ビジネスパートナー

や Linux ディストリビュータの各社と密接に連携して迅速なサポート

（OS 設定、ログ監視、ファイル改ざん検査、アップデート等）を展開

している。また、Linux を含むオープンソース・ソフトウェアをより発

展させるために各種のプロジェクトに対して積極的に参加、支援をして

いる □ URL http://www.sw.nec.co.jp/linux/ （Linux を中心としたオ

ープンソース・ソフトウェア情報）日立製作所

日立製作所は、インターネットビジネスを支援するプラットフォームソ

リューションとして、幅広いハードウェア・ソフトウェア製品、そして

サービス分野において、Linux をサポートしている。また、日立は、オ

ープンソースプロジェクトに積極的に参加し、オープンソース・ソフト

ウェアの発展にも貢献している。以下のサイトでは、日立のオープンソ

ースへの取り組みやオープンソースプロジェクトの情報の発信が行わ

れている。 □ URL http://oss.hitachi.co.jp/ （オープンソース・ソフトウェ

アプロジェクト）富士通

富士通は、Linux をインターネット主体の適用範囲から基幹システムの

適用まで幅広くサポートしており、ハードウェアのみならず、ミドルウ

ェア、サポートサービス、ソリューションまでカバーしている。また、

2000 年 1 月には、Linux を基盤としたコンピュータシステムに関する

幅広いソリューションの企画と立案を行い、富士通および関連会社の

Linux ビジネスを統括する組織「Fujitsu Linux Center: 富士通 Linuxセンター」を、設立している。

□ URL http://software.fujitsu.com/jp/linux/ NTT コムウェ

ア

NTT コムウェアでは、NTT のネットワーク網に代表される大規模な ITソリューションを構築・運営してきた実績とノウハウを活かし、トータ

ルな Linux ソリューションである「PROgART（プロアート）」を提供

している。まずコンサルティングから始め、企業の規模やビジネスに最

適なハードやディストリビューションの選定、実際のシステム構築から


Ⅳ- 16

万全のメンテナンス体制までを一括して行っている。また、研修・セミ

ナーによる技術者のスキルアップまでをサポートするなど、Linux 導入

に対する不安の全てに応えることができるサービスラインアップを用

意している。 □ URL http://www.nttcom.co.jp/

日本 IBM

IBM の Linux に対する取り組みは、IBM のサーバ、ソフトウェア、サ

ービスの部門をはじめ広範囲に渡る。その中でも、特にサポートに関し

ては、Linux サポートセンタにおいて、Linux ディストリビュータ各社、

およびパートナー企業との技術連携をもとに、IBM 全サーバ・プラッ

トフォームの実用環境での稼動テストや Windows、ホスト等との共存

環境における接続テスト、また Linux ソリューションのベンチマーク、

問題発生時の技術支援など、幅広い活動を実施している。 □ URL http://www.ibm.com/jp

表5. オープンソース・ソフトウェアを推進する主なシステムインテグレータ

3.1.5. セキュリティ情報提供ベンダ

セキュリティ情報提供ベンダのサービスを利用することにより、最新のセキュリティ

情報を一元把握することができる。ベンダ側では、情報セキュリティに関するアドバイ

ザリ情報、警告・注意情報、ウィルス情報、技術情報、アプリケーション最新バージョ

ン情報等をデータベース化し、検索可能な状態すると共に、顧客とのサービス契約内容

によっては、個別のサーバに対応した情報を提供しているところもある。例えば、「BugTraq」および「DeepSight Alert Services」の提供元であるセキュリテ

ィフォーカス社は、セキュリティ情報を提供するプロバイダであり、メーリングリスト

として世界有数の規模を誇る「BugTraq」（無償）の運営母体として広く知られている。

「BugTraq」は、完全な情報公開であり、モデレータ制を採り、綿密な論述とコンピュ

ータセキュリティに関する脆弱性のアナウンスを目的としたメーリングリストである。

また、有償のセキュリティ情報配信サービスである「DeepSight Alert Services」も合わ

せて提供している。このサービスは、セキュリティフォーカス社専任のアナリストが 24時間体制で、「Bugtraq」やその他の情報源を監視、収集した情報を対策案までを盛り込

み、より技術的なセキュリティ情報に絞り込んで約１時間という短時間で顧客に配信し

ている。更に、顧客自らデータベースを自由に検索することもできる。一方、日本国内でも数社のセキュリティ関連会社が、様々な情報ソースからの情報収

集と、独自の技術をもとにオリジナルな情報提供サービスを展開している。尚、詳細に

ついては、平成 13 年 3 月に情報処理事業振興協会から公開している、「脆弱性情報デー

タベース調査報告」にて記載されているので、参考にして頂きたい[4]。


Ⅳ- 17

3.1.6. セキュリティ情報収集リソースの選択本節を通じて、セキュリティ情報提供組織を 5 つの分野に分け、各々の分野で個別の

リソースを紹介してきた。ここでは、セキュリティ管理者（エンドユーザ）がどのように

情報収集リソースを選択すればよいのかを、1 節で分類した 3 つの運用モデルを用いながら

整理する。

・運用モデル 1 ･･･自組織のセキュリティ管理者が自ら複数の情報収集ソー

スに対して、常に注意を払わなければならない。外部への運用コストの発生

は抑えられるものの、オープンソース・ソフトウェアに精通したセキュリテ

ィ管理者のスキルが要求される。セキュリティ情報収集リソースとしては、

オープンソース・ソフトウェアコミュニティ、セキュリティ情報提供組織が

該当する。・運用モデル 2 ･･･複数のオープンソース・ソフトウェアを自組織の管理サ

ーバに採用している場合、セキュリティ管理者が常に複数の情報収集ソース

を監視することは難しい。そのようなときには、有償外部リソースを活用し

た情報収集が有用である。セキュリティ情報収集リソースとしては、主にセ

キュリティ情報提供ベンダ、ディストリビュータ、システムインテグレータ

が該当する。

・運用モデル 3 ･･･セキュリティ管理者が自組織の管理サーバに対して、直

接技術的対策を施さない場合や、オープンソース・ソフトウェアにあまり精

通していない場合は、有償外部リソースに情報の収集と対応を依頼した方が

有用である。セキュリティ情報収集リソースとしては、主にセキュリティ情

報提供ベンダ、ディストリビュータ、システムインテグレータが該当する。オープンソース・ソフトウェアは、自由に運用形態を選択できる反面、セキュリティ管

理者が積極的にセキュリティ情報を収集し、対応していく必要がある。情報収集のソース

が複数あり、各々のソースによって公開される内容や公開時期が異なることも考慮してお

かなければならない。参考までに、2 つの失敗事例を取り上げる。


Ⅳ- 18

3.2. セキュリティ情報への対応

ここでは、セキュリティ情報への対応として、パッチの適用手順について述べる。セ

キュリティ情報に基づくタイムリーなパッチの適用は、IT システムの可用性、機密性、

完全性の運用を維持するために、非常に重要である。新しいパッチは、異なるアプリケ

ーションごとに頻繁にリリースされ、それは、全ての新しいパッチに精通する経験を積

んだシステム管理者にとってさえも、多くの場合難しいと言える。一般的に、パッチファイルには次のような情報を含んでいる：該当アプリケーショ

ン、ファイルセット、リブートの有無、ステータス（一般・特殊）、クリティカル状態、

症状、欠陥の説明、パッチの競合、パッチの依存関係、ハードウェアの依存関係、その

他の依存関係、置換されたパッチ、同等パッチ、サイズ、インスタレーションに関する

指示、修正プログラム本体等々。

【失敗事例 1】 BIND のパッチ配布方法をめぐる波紋 BIND の開発元である ISC(Internet Software Consortium)は、BIND ソフトウェア

の脆弱性情報およびパッチ配布を有料で行うサービスを行ったことで非難を受けた。

ISC の早期警戒通知サービスの有料メンバにまず情報を提供したが、その数時間後に

は情報はアンダーグランドに流れて、さらに一般に流れたのは数日後であった。ISCの問題は、オープンソース開発グループが、インターネット基盤を構成するソフトウ

ェアの脆弱性について、本当に責任ある対応をしてくれるかという疑問を投げかけた。

【失敗事例 2】 Linux サーバに深刻なセキュリティホール～早期の情報公開で各

社混乱～ Linux の FTP ソフト「wu-FTP」に発見されたセキュリティ上の問題点を、大

手 Linux ディストリビュータが誤って早期に公表してしまった。他のディストリ

ビュータは、その時点でまだパッチの準備ができていなかった。この問題により情報が予定より早く公表されてしまったため、多くの Linux デ

ィストリビュータ、情報公開で足をすくわれた格好となった。普通なら、この種の

警報は歓迎されるべきところであるが、他の Linux ディストリビュータはある期

日まで情報は公開されないとの前提で作業を進めていた。予想外の情報公開によっ

て、当該ディストリビュータ以外の製品を使っている顧客は、修復の術を知らない

ままセキュリティホールの存在だけを知らされることとなった。


Ⅳ- 19

パッチの適用は、一歩間違えればシステムを不安定な状態にさせかねないので、慎重

に行うべきである。個別のアプリケーションにおいて、以上のような情報を、システム

管理下の環境と照らし合わせると共に、該当する脆弱性が及ぼす影響を加味して適用す

るか否かの判断をしなければならない。本ガイドでは、個別アプリケーションに依存するパッチ適用ではなく、より汎用的

なパッチ適用手順についてフォーカスし、説明する。

3.2.1. パッチ適用手順の概要脆弱性は、コンピュータ上の認可された権限より強大なアクセス権限、あるいは許可

を獲得することにより悪意のあるイベントにつながるソフトウェアの弱点である。すべ

ての脆弱性に対してパッチが提供されるとは限らず、システム管理者は、脆弱性とパッ

チについて関心を払うだけでなく、他の方法を通じて、パッチの適用でカバーされない

脆弱性を軽減しなくてはならない。（例えば、ファイアウォールおよびルータ・アクセ

ス・コントロールリストを利用した対処）脆弱性の軽減に対処するために、パッチとセキュリティに関するセキュリティ管理者

グループを編成することが米国において推奨されている。4 ここでは、[1]のレポートを

参考にしながら、オープンソース・ソフトウェアのセキュリティ・パッチの運用手順に

ついて説明する。この手法は、オープンソース・ソフトウェアに限らず商用ソフトウェ

アについても共通であり、オープンソース・ソフトウェア同様に効果が期待される。運

用手順は、以下の 9 項目からなる。

1. 組織のソフトウェア資産目録の作成 2. 新しく発見された脆弱性およびセキュリティ・パッチの識別 3. 優先的なパッチの適用 4. 組織に特有のパッチ・データベースの作成 5. パッチ・テスト 6. パッチおよび脆弱情報の配布 7. ネットワークおよびホスト脆弱性スキャンによるパッチ適用の確認 8. 脆弱性データベースを利用したシステム管理のトレーニング 9. パッチの自動適用

4米国の National Institute of Standards and Technology (通称、NIST)から発行されている NIST Special Publication 800-40 “Procedures for Handling Security Patches”


Ⅳ- 20

3.2.2. セキュリティ管理者グループセキュリティ管理者グループの存在は、このグループの管理下でシステムへのパッチ

適用にあたり、各システム管理者の責任を縮小するものではない。各システム管理者が

行うべきことを、以下に列挙する。 1. セキュリティ管理者グループによって識別されたパッチを適用 2. ターゲットシステムへのパッチのテスト 3. セキュリティ管理者グループによって監視されない、ソフトウェアに関連した脆

弱性とパッチの識別セキュリティ管理者グループの編成に加えて、組織（企業、団体等）は、パッチの適

用および脆弱性の軽減が必ずしも簡単なプロセスだとは限らないことを認識する必要が

ある。そこには、パッチの優先順位、入手、テスト、そして適用に関連した様々な問題

が存在するからである。では、以上のことについて、対策を詳細に検討していく。セキュリティ管理者グループの任務は、組織のソフトウェアに脆弱性を発見して修正

する際に、ローカルの管理者を支援することである。セキュリティ管理者グループは、

一般的に脆弱性に対して彼ら自身がパッチを適用することはなく、パッチを適用してテ

ストするためにローカルの管理者と一緒に仕事をする。セキュリティ管理者グループの

任務を、以下に列挙する。

3.2.3. パッチ適用時の作業項目 1. 組織のソフトウェア資産目録の作成

最初に、組織で頻繁に利用されているソフトウェアと、それらソフトウェアのバ

ージョンを含むデータベースを作成する。それにより、セキュリティ管理者グルー

プは、データベースに形成される資産目録を利用して、ソフトウェアに対応する脆

弱、およびパッチに関する情報を監視することができるようになる。ここで重要な

のは、資産目録を作成することにより、システムを合理的に把握すること可能にな

ることである。新しいパッチあるいは脆弱性があるか、そして、どのソフトウェア

をチェックしているかを管理者が理解できるように、資産目録をシステム管理者に

利用可能にする必要がある。


Ⅳ- 21

資産目録の項目例： - ハードウェア･･･タイプ、メーカ名、シリアルナンバ、ファームウ

ェア、BIOS バージョン等 - OS ･･･タイプ、メーカ名、バージョンナンバ、パッチレベル等 - アプリケーション･･･タイプ、メーカ名、バージョンナンバ、パッ

チレベル等 2. 新しく発見された脆弱性およびセキュリティ・パッチの識別

ソフトウェア資産目録に含まれるソフトウェアの脆弱性とパッチのセキュリティ

ソースを監視し、関連する脆弱性・パッチ情報を取得する。これらの収集について

は、前節で示す情報源を活用のこと。例えば、図 5のように ICAT5の脆弱性検索エン

ジンを利用して、コンピュータにおける脆弱性情報を調べることができる。検索キ

ーには、ベンダ名、プロダクト名、バージョン、脆弱性のタイプ、危険度等がある。

図5. 例）ICAT の検索画面

3. 優先的なパッチの適用パッチを適用する際には、該当マシンのハードウェア・ソフトウェアリソースの

制約を把握しておくことが望ましく、これらのリソースの制約でローカルの管理者

が困惑することを回避できるようにしておく必要がある。更に、既知の脆弱性に対

するパッチを優先的に取り扱い、各パッチの危険度に基づいてローカルの管理者に

5 http://icat.nist.gov/


Ⅳ- 22

アドバイスできるようにする。このときに、以下に示す検討すべき項目を、該当マ

シンの環境に照らし合わせて評価する必要がある。検討すべき項目：

- 脅威･･･コンピュータやネットワークへ害を及ぼす可能性 - 脆弱性･･･コンピュータやネットワークに生じさせる弱点・欠点 - 危険度･･･自組織の業務と照らし合わせた場合の危険度を考慮

4. 組織に特有のパッチ・データベースの作成

組織に適用されるパッチについての情報データベースを作成する必要がある。理

想的には、データベースはそれらのパッチのインストールについて、実際のパッチ

および指示を含んでいることが望ましい。その理由として、インターネットへアク

セス可能でない状況、あるいはあるパッチのダウンロードサイトが危険にさらされ

たかもしれない場合、組織がパッチのコピーを維持することが望ましいからである。 5. パッチ・テスト

もし、組織が利用する機器構成等が標準化されているなら、組織を一括してこれ

らの構成にパッチ･テストを実施することができる。これは個別の管理者による余分

なテストの必要性を回避でき、有効である。重要なサーバーシステムのパッチをテ

ストする際には、テスト体制に配慮すべきである。パッチ・テスト作業時の注意点

を以下に示す。パッチ・テスト作業時の注意点：

- 最初に、パッチドキュメントに記述されている通り、ファイルあるいは

コンフィギュレーションが適切に構成されているかを確認 - 脆弱性検査ツールで実際の脆弱性を確認する。あるいは、対象アプリケ

ーションのバージョンナンバ、パッチレベルを確認 - パッチ後、脆弱性が確実に取り除かれているかを確認

6. パッチおよび脆弱情報の配布

組織的なソフトウェア資産目録に含まれたソフトウェアに対応するパッチに関し

て、各組織の管理者に情報を通知する必要がある。電子メーリングリストは、パッ

チ情報を配布する有効な方法である。しかし、トロイの木馬を含むパッチ等を不正

に送りつけられる脅威がある。そのため実際のパッチは、電子メールで送付するの

ではなく、組織内部の安全なウェブサイトから配布したほうがよい。


Ⅳ- 23

7. ネットワークおよびホスト脆弱スキャンによるパッチ適用の確認全てのパッチを全てのマシンへインストールしたことを確認する必要がある。ま

た、パッチが適用されていないシステムを識別するために、周期的にネットワーク

とホストの脆弱性をスキャンすることは有効である。更に、そのようなスキャンは、

新しい脆弱性およびパッチのための情報源となる。しかし、ネットワークとホスト

の脆弱性スキャナが、すべての既知の脆弱性をチェックするとは限らず、このよう

に脆弱性情報の唯一の情報源として依存することができないことに、注意すべきで

ある。

8. 脆弱性データベースを利用したシステム管理のトレーニングセキュリティ管理者グループは、ソフトウェア資産目録に登録されたソフトウェ

アについて、パッチ情報および脆弱性を監視する。一方、ローカル管理者は、ソフ

トウェア資産目録に登録されているソフトウェアだけでなく、登録されていないソ

フトウェアを利用することもできる。このような場合、ローカル管理者が新しいパ

ッチ、および脆弱性を識別する方法について、ある一定の知識を持っていることが

前提になる。そのために、脆弱性データベースを利用した管理者のトレーニングが

必要となる。 9. パッチの自動適用

大部分の同種のコンピューティング・プラットフォームを持つ組織では、自動配

信されたパッチ配信サービスを利用することができる。それにより、管理者は、何

百、あるいは何千の更新を一括して行うことができるようになる。以上の 9 項目は、各々が密接に関連している。図 6にセキュリティ管理者グループを取

り巻く連携環境を示す。


Ⅳ- 24

図6. セキュリティ管理者グループを取り巻く連携環境

3.2.4. システム管理者のパッチ適用責任セキュリティ管理者グループの存在にかかわらず、システム管理者は、当該システム

に対してのパッチ適用について積極的に取り組む必要がある。場合によっては、セキュ

リティ管理者グループのメンバと直接作業をしてもよいが、セキュリティ管理者グルー

プによって監視されていないパッチ、および脆弱性を持つソフトウェアの識別について

は、責任を負うべきである。そのため、そのようなパッチおよび脆弱性を識別する方法

を訓練する必要がある。システム管理者の任務を、以下に列挙する。

1. セキュリティ管理者グループによって識別されたパッチの適用

システム管理者は、電子メールあるいはウェブサイトによって、セキュリティ管理者

グループからパッチおよび脆弱情報を受け取る。その後、システム管理者は、各パッチ

が当該システムに適用可能かどうか決定しなければならない。そして、どのようにパッ

チを適用するかの優先順位を決定する。場合によってはシステム管理者が、全てのパッ

チを適用しないことを決定してもよい（例えば、パッチによりシステムを不安定させる

恐れがある場合）。セキュリティ管理者グループは、管理者にパッチを推薦し、優先事項

を推奨するが、最終の適用責任は、各システム管理者の責任に委ねられる。

2. 新パッチの識別／脆弱性

3. パッチの優先度

4. パッチデータベース

1. ソフトウェア資産

SystemsAdministrators

5. パッチのテスト

6. パッチ配布

8. 脆弱性データベーストレーニング

9. 自動化パッチ適用

7. 脆弱性スキャン

セキュリティ管理者

グループ


Ⅳ- 25

2. 特定ターゲットシステム上のパッチ・テスト

セキュリティ管理者グループは、可能な限りパッチをテストし、各々のシステム管理

者が各パッチをテストする作業を緩和する。しかしながら、いくつかのパッチは、シス

テム構成に依存してパッチの適用が失敗する恐れがあるので、ターゲットシステムとほ

ぼ同様に構成されたシステム上でテストする必要がある。したがって、大規模な同種の

ソフトウェア・プラットフォームを保有する組織を除いて、セキュリティ管理者グルー

プがパッチ・テストを実行することは、非常に困難だと思われる。パッチのテストが行

われていない場合、ローカルのシステム管理者は、そのようなパッチ・テストの実行に

責任を負わなければならない。

3. セキュリティ管理者グループによってモニターされないソフトウェアに関連する

パッチと脆弱性の識別

セキュリティ管理者グループによって管理されるソフトウェア資産目録は、組織にお

いて使用される全てのソフトウェアを含んでいるとは限らないかもしれない。したがっ

て、ローカルのシステム管理者は、どのパッケージ・ソフトがセキュリティ管理者グル

ープによってカバーされているかを、把握しておく必要がある。つまり、資産目録にな

いソフトウェアのパッチ、および脆弱性の調査であり、システム管理者自ら、当該シス

テムへ必要に応じて適用しなければならない。

これら3つのシステム管理者の任務は、お互いが密接に関連している。図7にその関係

をまとめて図示する。

図7. システム管理者の役割とセキュリティ管理者グループとの連携

3. パッチの識別と脆弱性

SystemsAdministrators

2. パッチのテスト 1. パッチの適用

セキュリティ管理者グループからのパッチ


Ⅳ- 26

3.3. インシデントへの対応

ここでは、インシデントへの対応として、コンピュータ緊急対応センタ JPCERT/CCが公開している、インシデント発見時の対応手順（16 項目）を参考にしながら、オープ

ンソース・ソフトウェアを利用した場合の観点からインシデントへの対応方法について

説明する[2]。オープンソース・ソフトウェアを利用していると言ってもインシデントへの

対応自体に大きな違いがあるわけではない。しかしながら、第 2 章で述べた「運用モデ

ルの分類」の違いにより、対応手順を分けて述べる。

3.3.1. 一般的なインシデント発見時の対応手順以下に、インシデント発見時の対応手順（16 項目）を列挙する。

1) 冷静に対処するセキュリティ上の問題が発生した場合、様々なことを決断しなくてならない。発生し

た問題がどのようなものであっても、何も考えずに行動したのでは事態を悪化させるだ

けである。その結果、さほど深刻ではないインシデントの被害や影響範囲を無用に拡大

してしまう恐れがある。

2) 手順の確認緊急事態に的確に対処するためには、前もって手順を決めておく必要がある。既に手

順が決められている場合は、その内容を確認する。

3) 作業記録の作成時刻情報を含めた形で、作業内容を記録する。この作業記録は、作業時の手順を後日

評価する際の資料に用いられるだけでなく、作業中に副次的に障害が発生した場合など

には、作業手順のポリシーなどを見直すための重要な資料になる。

4) 責任者、担当者への連絡発見者がインシデント対応担当でない場合には、事前に定められた連絡手順に従い、

組織内のインシデント対応チームなどの対応者に連絡して、指示を仰ぐ。また、インシ

デントの内容や程度によっては、組織内の他の部署とも協力して対応を行わなければな

らない場合がある。

5) 事実の確認どのようなインシデントが起こっているのか、冷静に事実関係を確認する。外部から

の不審なアクセスが全て不正なアクセスとは限らないことを注意する。


Ⅳ- 27

6) スナップショットの保存システム自体に、ある程度の影響が想定される場合には、後々の調査に備えてインシ

デント発生時のシステムのスナップショットを保存する。

7) ネットワーク接続やシステムの遮断もしくは停止自システムが他サイトの攻撃に（踏み台として）悪用され、被害が拡大する恐れがあ

る場合には、ネットワークやシステムの全体、もしくは一部を遮断または停止する。遮

断や停止については、事前に意思決定プロセスや判断基準を整理しておくとともに、具

体的な作業手順についても明確に定めておく必要がある。

8) 影響範囲の特定これからの対応を判断する前提として、どのような種類の影響が、サイト内外のどの

範囲にまで、どの程度生じているかを調べる。例えば、ほかのシステムとの通信履歴な

どから、関連するサイトを調査、ファイルへのアクセス状況（最終アクセス時刻など）

から機密情報の漏えいがなかったかどうかを調べる。特に、持ち出し、参照された可能

性のあるファイルが、自サイトにとってどれだけ「機密」に当たるものかを確認し、以

後の対応を検討する。また、踏み台として他サイトへのアクセス（攻撃）に使われた可能性がある

場合には、実際に自サイトから外部に対して「いつ」「どのような」アクセスが行われたかを、シス

テムのログやルータなどのネットワーク機器のログなどから整理しておく。

9) 渉外、関係サイトへの連絡

インシデントの影響の程度により、サイト内外への事情説明や謝罪などが必要とされ

ることがある。広報や渉外などの担当者と調整し、必要な情報を提供する。また、ほか

のサイトがインシデントに関係している可能性がある場合（例えば、アクセス元）には、

それらのサイトに必要な情報を提供し、協力して解決に取り組めないかどうかを検討す

る。しかし関係するサイトへの連絡にはリスクも伴うため、注意が必要である。

10) 要因の特定

インシデントの再発を防ぐための再発防止策について検討するために、インシデント

が発生した要因（原因）を特定する。例えば、システムの設定に問題がなかったかどう

か、また使用している OS やソフトウェアのセキュリティ上の弱点で対策を講じていなか

ったものがなかったかどうか等を、ベンダや配布元の提供する情報を参照して確認する。

11) システム復旧何らかの改ざんやデータの破壊が行われた場合には、バックアップメディアあるいは


Ⅳ- 28

配布メディアからシステムを復旧する。バックアップデータを保存した時点で、すでに

システムが改ざんされていた可能性がある場合には、意図しない設定やプログラムが記

録されていると考えられる。バックアップメディアからの復旧に際しては、それらの意

図しない情報を書き戻さないように注意する必要がある。最悪の場合、バックアップメ

ディアからの復旧をあきらめ、配布メディアまたは当該サイトからオープンソース・ソ

フトウェアをダウンロードして、初期インストールが必要となる場合もある。

12) 再発防止策の検討上記 10）において特定した要因に対して、どのような対策が可能か検討する。例えば、

使用している OS やソフトウェアのセキュリティ上の弱点が悪用された（と考えられる）

場合には、ベンダや配布元の提供する情報を参照し、問題を修正するために必要なパッ

チ等の情報を確認する。パッチの適用やソフトウェアの更新などによる対策が困難もし

くは不可能な場合には、可能な回避策を調査する。また、パスワードデータベースの情

報が盗まれた可能性がある場合には、全ユーザのパスワードを変更しておく必要がある。

13) 監視体制の強化一度、攻撃に成功し、脆弱なサイトとして情報が流されると、引き続き何らかの攻撃

を受ける可能性が飛躍的に高まる。インシデントの再発に備え、監視体制を強化する必

要がある。

14) 作業結果の報告作業終了後、記録に基づいて、作業内容や作業にかかったコスト（時間、費用など）、

また（確認された範囲内での）損失をまとめ、責任者に報告する。

15) 作業の評価、ポリシー・運用手順の見直し作業報告に基づいて、セキュリティポリシーに定められた手順に不十分な点がなかっ

たかどうかを確認し、必要に応じてポリシーを見直す。またこれまでの運用体制や手順、

更に今回実際に行ったインシデント対応作業に問題がなかったかどうかを確認する。

16) JPCERT/CC への報告

JPCERT/CC へのインシデント報告6を行う。

6 http://www.jpcert.or.jp/form/


Ⅳ- 29

3.3.2. オープンソース・ソフトウェアにおけるインシデント対応 3.3.1 で説明した手順を、2 章で述べた「運用モデルの分類」のモデル 1～3 の違いによ

り整理すると、表 6のようになる。

No. 対応項目モデル 1 モデル 2 モデル 3

1 冷静に対処する ○ ○ ○ 2 手順の確認 ○ ○ ○ 3 作業記録の作成 ○ ○ ○ 4 責任者、担当者への連絡 ○ ○ ○ 5 事実の確認 ○ ○ － 6 スナップショットの保存 ○ ○ － 7 ネットワーク接続やシステムの

遮断もしくは停止 ○ ○ －

8 影響範囲の特定 ○ ○ － 9 渉外、関係サイトへの連絡 ○ ○ ○

10 要因の特定 ○ △ △ 11 システムの復旧 ○ ○ △ 12 再発防止策の検討 ○ △ △ 13 監視体制の強化 ○ ○ － 14 作業結果の報告 ○ ○ － 15 作業の評価、ポリシー・

運用手順の見直し ○ ○ ○

16 JPCERT/CC への報告 ○ ○ ○ 自組織で対応する項目に “○” 印で表示自組織で一部対応する項目に “△” 印で表示外部リソースへ委託する項目に “－” 印で表示モデル 1 ･･･自組織のみで情報の収集と対応をする場合モデル 2 ･･･有償外部リソースから情報を収集して、自組織で対応する場合モデル 3 ･･･有償外部リソースに情報の収集と対応を依頼する場合

表6. オープンソース・ソフトウェアにおけるインシデント対応表

対応項目 1～4 までは、どのモデルにおいても自組織が中心となってイニシアティブを

とり対応する。項目 5～7 では、外部リソースを活用しているときのみ、対応を依頼する

ことができる。このとき、事前に決めている意思決定や判断基準に基づいて、外部リソ

ースと自組織の判断の切り分けをしておく必要がある。項目 8 の影響範囲の特定であるが、ここでは、モデル 3 の運用形態をとっていれば、

インシデントの影響範囲の特定を外部リソースへ依頼する。影響範囲が特定されれば、

自組織が責任を持って、渉外、関係サイトへの連絡を行う（項目 9）。


Ⅳ- 30

項目 10の要因の特定では、外部リソースが持つセキュリティ情報が非常に重要になる。

要因を特定する際には、どのようなインシデントの影響があったのかを踏まえて、脆弱

性に関する情報についてオープンソース・ソフトウェアコミュニティをはじめ、様々な

リソースから収集しなければならない。このとき、外部リソースとの連携が効果を発揮

する。

項目 11 のシステムの復旧では、モデル 3 において、項目 10 で特定した要因が外部リ

ソースへの委託範囲であれば、そちらへ復旧依頼を行う。さらに、再発を防止するため

に、外部リソースからの脆弱性情報をもとに対策の検討をする（項目 12）。再発防止の検

討が済めば、監視体制の強化を行い、及び作業結果の報告をする。モデル 3 の運用形態

であれば、この作業は外部リソースへ依頼することができる。最後に、作業結果報告に基づき、作業の評価、ポリシー・運用手順の見直しを自組織

内部で行う。更に、一連のインシデントの経緯について、JPCERT/CC へ報告を行う。


Ⅳ- 31

4. まとめ

オープンソース・ソフトウェアは、商用ソフトウェア利用時の運用と比較して、自由度

の高い運用方法の選択をエンドユーザにもたらしてくれる。本報告書では、オープンソー

ス・ソフトウェア運用モデルを以下の 3 つに分類して説明してきた。

作業項目モデル 1 モデル 2 モデル 3

セキュリティ情報収集自組織で対応外部リソースで対応外部リソースで対応

セキュリティ情

報への対応自組織で対応自組織で対応外部リソースで対応

インシデントへの対応自組織で対応

対応項目 10, 12 について

は、自組織が中心となり外

部リソースから情報を入

手。それ以外は、自組織で

対応

対応項目のうち、5, 6, 7, 8, 13, 14 については外部リソ

ースを中心に対応。また、

項目 10, 11, 12 について

は、自組織が中心となり情

報となり対応。それ以外は、

自組織で対応モデル 1 ･･･自組織のみで情報の収集と対応をする場合モデル 2 ･･･有償外部リソースから情報を収集して、自組織で対応する場合モデル 3 ･･･有償外部リソースに情報の収集と対応を依頼する場合

表7. オープンソース・ソフトウェア運用モデルと作業項目対応のまとめ

表 7から分かるように、セキュリティ情報の収集については、自組織のみならず、セキ

ュリティ情報提供サービスを行っている外部リソースを活用することで、複数の運用形

態をとることが可能である。また、セキュリティ情報対応に関しては、外部リソースへ

依頼することで、自組織の役割を最小化することができる。インシデントへの対応では、

対応項目に応じて、外部リソースの活用状況が異なってくる。モデル 1 は自組織での対

応を想定しているが、モデル 2 では、対応項目 10,12 について、セキュリティ情報を外

部から積極的に入手する。さらにモデル 3 では、入手した情報を元に特定原因を洗い出

し、事前に決められている方針に基づいて、対応を外部リソースへ依頼する。以上のように、大別するとオープンソース・ソフトウェアの運用モデルは、3 つに分類

することができる。どの運用モデルを採用するかは、組織における人、機材、費用等の

制約条件を考慮して判断する必要がある。


Ⅳ- 32

参考文献

[1] National Institute of Standard and Technology, “Procedures for Handling Security Patches”, April 2002

[2] JPCERT ホームページ,「管理者のためのセキュリティ推進室」 http://www.jpcert.or.jp/magazine/atmarkit/

[3] IT ビジネス実践ガイド, ダニエル・アモール, ピアソン・エデュケーション [4] 情報処理振興事業協会（IPA）平成 12 年度セキュリティ対策研究開発等事業

「脆弱性情報データベースに関する調査」 http://www.ipa.go.jp/security/ccj/report/h12/chousa/vuldb.pdf

Documents

オープンソース・ソフトウェアの セキュリティ確保 …オープンソース・ソフトウェアの セキュリティ確保に関する調査報告書 第Ⅳ部

オープンソース・ソフトウェアのセキュリティ確保 …オープンソース・ソフトウェアのセキュリティ確保に関する調査報告書第Ⅳ部