TOP
＞
サーバ構築・運用
＞ パッチ適用における管理者の負担
サーバOSの脆弱性対策
パッチ適用を自動化せよ！
著者：
クワンティ 寺澤 陽一郎
2007/6/27
前のページ
1
2
3
次のページ
パッチ適用における管理者の負担
では、なぜ85%ものシステムがパッチを適用せず危険な状態にさらされているのか? そこには主に3つの要因がある。
認識不足によるリスクの軽視
1つ目は「認識不足によるリスクの軽視」だ。業者の勧めるファイアウォールや侵入検知システム、最近ではUTM（統合脅威管理）アプライアンスを導入することだけで安全性が保たれていると誤解していることが多い。もしくは危険性はある程度承知しているが周りに理解されず予算も取れない。最悪のケースであるが管理者の怠慢の可能性もある。
サービスメニューを用意せず「OSなどのパッチ適用はお客様自身の責任で実施してください」といい切るデータセンター事業者もあるが、これは考えものだ。少なくとも利用者より専門知識と技術を有するプロフェッショナルなのだから、リスクの説明とパッチ適用の必要性を説明し、パッチ適用などの保守が困難な利用者には有償ででもパッチ適用代行メニューを用意すべきであろう。
パッチの数と専門技術員の数のバランスが取れていない
2つ目は「パッチの数と専門技術員の数のバランスが取れていない」ことだ。Linuxのセキュリティ問題対策パッチだけで「ディストリビューション＋バージョン」ごとに月あたり6〜10個リリースされている（2007年5月のRed Hat Enterprise Linux 4.0 ESでは27個）。
それら1つ1つについて自社システムへ適用する必要があるかを判断し、必要であればサーバ群に適用するという作業を、管理者は毎回繰り返すのである。
この負担軽減のために、Linuxディストリビューションごとに用意されたパッチ適用ツールがあるものの、次に説明する3つ目の要因で実際の適用作業では使われないのが実情だ。
本番稼動環境への悪影響の懸念
3つ目は「本番稼動環境への悪影響の懸念」だ。パッチを適用すると本番稼動中のシステムへ悪影響があり業務に支障を来たす恐れがある。その懸念からシステム管理者は、ベンダーやLinuxディストリビュータからリリースされたパッチを直接本番環境に適用することはないのである。
では、現在パッチを適用する際に手法にはどうのようなものがあるのか。
現状の対応手法とパッチ適用ルール
今までにもソフトウェア更新ツールがなかった訳ではない。
システム運用保守の観点から、統合システム管理ツールでパッチ適用させるオプション機能が提供されている場合がある。しかし、サーバは業務使用のクライアントPCのように型にはめたように同じソフトが同じように稼動しているわけではない。またセンター側にトラフィックや処理が集中する弊害や、被管理側サーバに直接行った変更がセンター側で把握できず不整合が発生するなど、運用に予想外の手間が掛かるのだ。
製品選定の際にALL or Nothingでシステム管理に関するすべての要望が適えられているか否かで判断されることも多い。しかし、比較的多くの要望を満たしていると妥協して導入したシステムも、その多機能が災いして理解が困難な上、システム自体が変化に追従できず使われなくなって行くことが多く見受けられる。結果として、ほとんどの保守運用におけるパッチ適用作業は手作業となっているのが現状なのである。
セキュリティを確保するためにSELinuxを使う
手作業でそれなりにコストをかけて個別システムの安全性を維持するにはSELinux（Security-Enhanced Linux）でシステム構築するのも1つの選択肢だ。SELinuxとは米国安全保障局が開発したLinuxOSのセキュリティを高める拡張機能モジュール（オープンソース）で通常LinuxOSのオプション的設定で誰でも利用可能である。
SELinuxの仕組みは、通常のLinuxで弱点といわれる管理者rootの権限範囲を廃して、サービスごとにアクセス権を設定することで、セキュリティを高める。いわばサービスごとに別々の鍵で施錠し、アカウントごとにどの鍵を持たせるかを設定するのである。こうすれば1つのサービスの脆弱部分から侵入されても脆弱性対策がきちんと行われている他のサービスには容易に侵入されることはない。
図1：通常のLinux
図2：SELinux
しかし、注意しなければならないのは、サービス自体は通常のLinuxと安全性は変わらないので、サービスごとの脆弱性対策が必要であるという点だ。また、パッチ適用はサービスの権限割り当てアカウントごとに行わなければならないので、手間がかかる。さらに、より専門的な知識と技術を必要とし、権限割当ての設計・運用をしっかりするなどセキュリティポリシーを決め遵守することが重要だ。
もう1つの選択肢、それはシステム管理者がその都度パッチを適用すること
もう1つの選択肢であり、一般的で最も有効な安全性の維持は、リリースされるパッチをその都度早急にサーバへ適用することだ。パッチ適用の最大の問題点は稼動中システムへの悪影響の懸念である。この懸念がなければ毎月いくつパッチリリースされようがツールで自動適用すれば問題はない。
しかし、パッチ適用によって障害が発生することがある。セキュリティレベルを維持するために行った作業でサービスが停止して、業務が滞ることになれば本末転倒だ。
では、システム管理者は具体的にどのような手順でパッチ適用しているのかというと、本番環境と類似したテスト環境を用意してリリースされたパッチを適用し、「適用時にエラーが発生しないか、適用後にサービスに異常は発生しないか、アプリケーションや業務システムに不具合は生じていないか」を確認できたパッチのみを本番環境のサーバに適用しているのである。
また、問題が発生したパッチはその原因を調査して、必要であればパッチの修正や業務システムの修正対応パッチを同時に適用するのである。この作業を毎月10個近くのパッチがリリースされるたびに実施することの大変さは容易に想像できるであろう。
ではどのようにすれば、この厄介で面倒な作業を改善できるのか。ポイントを押さえ分類して見ると、こらの作業は以下の2つに分けられる。
パッチ適用時の稼動確認作業
実際のパッチ適用作業
表1：パッチ適用作業の分類
そしてこの作業は世界中のインターネットサーバ運用者の共通した作業である。
1の稼動確認作業はユーザシステムの独自性や導入アプリの組み合せが無数にあるため機械化は困難で、むしろ担当SEが行う方が安全性・確実性も高く効率も良い。
2のパッチ適用作業は、誰もが同様の作業でサーバごとに必要なパッチを漏れなく適用する作業なので機械化が有効である。保守管理対象のサーバが多数であれば、管理者は動作確認済みパッチをバイキング形式の料理のように置いておくだけで、ユーザ側であるサーバが自機に適した必要なパッチを勝手に持っていき、適用までしてくれれば管理者の負担は大変軽くなる。
図3：理想的なパッチ適用の作業
（画像をクリックすると別ウィンドウに拡大図を表示します）
また、パッチ適用テスト結果の情報を共有できればさらに楽になる。つまり同様の「サーバOS＋アプリケーション」の構成なら、他者の行ったテスト済みパッチが適用でき、作業が効率的になる。
前のページ
1
2
3
次のページ
著者プロフィール
クワンティ株式会社 寺澤 陽一郎
代表取締役
日本システム技術（JAST）にて大型汎用コンピュータの業務システム設計・開発、Windows NT・ORACLE利用の業務ソフトウェアパッケージの企画・業務分析・設計・開発・ユーザ教育・運用保守・バージョンアップまでのライフサイクル全て経験。2000年クワンティ株式会社設立、代表取締役就任。産学協同でオープンソース（Linux）利用と安全性向上を研究・製品開発でオープンソースの普及とビジネス利用に貢献。
INDEX
パッチ適用を自動化せよ！
クラックの最大要因とは
パッチ適用における管理者の負担
Qloc EngineとqeMOTHERserver
