構成管理というファンダメンタル
いきなりですが、インターネット上では日々いろんな攻撃が行われているわけです。それこそホームページの改ざんとか、個人情報やクレジットカード情報を盗み出そうとか、ID/パスワード情報を盗み出そうとか。で、ネットワーク経由で攻撃のほとんどについては、未知の脆弱性ではなく既知の脆弱性を利用して行われているのが実情です。
既知の脆弱性なので、セキュリティパッチを当てれば済みそうなものなのですが、現実としてはなかなかうまくいかないところが、難しいわけです。うまくいかない原因はいろいろあるのですが、その中の一つに「構成管理がきちんとできていない」というのがあります。
ということで、今回は構成管理についてちょっと考えてみましょう。
構成管理はISMSにおいても初期の段階からセキュリティ対策の一つとして定義されていますが、意外に多くの組織でおざなりにされていることが多い、というのが私の印象です。まあ、「構成管理」という一言の用語で片づけて、何のためにやるのか、具体的な構成管理のタスク・作業は何か？を分かりやすく説明したものがないというのも、我々セキュリティ業界側の問題なわけなので、ここで少しだけひも解いてみましょう。
さて、なぜ構成管理をやるのか？構成管理ができていないと何がまずいのでしょうか？
構成管理ができていない場合のまずい状況をざっと挙げてみると、
- ある製品の脆弱性情報について、自社に関係あるかどうかがわからない。
- 自社で使っている製品の脆弱性情報について、どこに適用すべきかがわからない。
- 事故が発生した場合の影響範囲の特定ができない。
- 不正プログラムがあるらしいが、どれが不正プログラムかが分からない。
- ユーザが勝手にPCに許可されていないアプリケーションをインストールした。
- アプリケーションプログラムの脆弱性を修正したが、本番環境にあるプログラムファイルが修正後のものかが分からない。
- 端末のセキュリティパッチを適用したが、きちんと全体に適用されたかが分からない。
などがあります。
上記のような状況を考えると、構成管理では以下のようなことを行う必要があることが分かります。
① システム（サーバ、ネットワーク、端末等）の構成情報（物理、論理、ハードウェア、ソフトウェア、等）の収集・維持・最新化。
② 収集した情報を元とした、不正の監視
③ インシデント（脆弱性、事故）発生時の対象範囲、影響範囲の分析
上記3点ですが、気を付けなくてはいけないのは、①がきちんと出来ていないと、②③がきちんとできないということです。その意味で多くの組織で①がきちんと出来ていない、もしくは②③を行うことを前提とした①が出来ていない、ということなのです。ということで、①②③をそれぞれ考えてみましょう。
① システムの構成情報の収集・維持・最新化
実際、構成管理として端末に「構成管理システム」のソフトを導入して、終わり、という会社も多いのですが、じゃあ、ネットワーク構成は？サーバのソフトは？の管理は？となると、良く分からない、という場合もあります。
構成情報を一カ所で集中管理する必要はないですが、端末の情報はこれ、サーバの情報はここ、ネットワークの情報はあそこ、というように、構成情報の所在を明確にしておくことは必要です。
また、端末に構成管理システムを導入した場合には、端末の構成の最新情報を得る（維持する）のはシステムの機能を利用すれば簡単にできる（はず）ですが、サーバ構成、ネットワーク構成については、そういった情報を自動的に収集・最新化してくれるシステムはなかなかないと思いますので、文書で管理する場合も多いのですが、そういった文書が往々にして最新化されていないこともあるので、普段からそれらの文書をきちんと最新化しておくことも必要です。その意味では、セキュリティ対策でいう「構成管理」はITILでいうところの「構成管理」「変更管理」「リリース管理」までも含めたものになります。
② 収集した情報を元とした、不正の監視
不正の監視と簡単に書いていますが、構成管理上における「不正」もしくは「不正な状態」とは何か？実は、これをきちんと定義しないと、作業として何をどうやって監視するのかを組み立てることができません。
端末で言えば、
- 許可されていないソフト・不正なソフトがインストールされていないか？
- セキュリティパッチが最新化されているか？
- 端末に許可されていない周辺機器等が接続されていないか？
ネットワークで言えば、
- 不正な端末の接続、無許可の無線LANのアクセスポイントの設置
- ネットワーク構成の勝手な変更
サーバで言えば、
- プログラムの勝手なバージョンの変更
- パッチの最新化がされているか？
- サーバの勝手な設定変更
- ホームページコンテンツの勝手な変更
などがあります。
まあ、ほかにもあると思いますが、①で管理する情報をもとに、これらをどのようなサイクル、タイミングで、どうやって監視するのかを決めて、実行していく必要があります。そのため、監視作業から逆算して①でどのような情報を収集・管理するのかを考えておく必要があります。
③ インシデント（脆弱性、事故）発生時の対象範囲、影響範囲の分析
これに関しては、①の情報がきちんと整備されていれば、実行はできます。ソフトの脆弱性が分かれば、該当するソフトが①で管理する情報の中から探し出します。事故が発生した場合には、構成情報を元に影響範囲を分析する（分析する人の腕はまた別の話ですが）だけですね。特に、事故が発生した場合には、影響範囲の分析は早急に行う必要がありますので、①で必要な情報が管理されているか？最新化されているか？は重要な問題になります。
と、ここまでざっと書いてきましたが、以上①②③の活動から逆算して考えると、構成管理の目的は、「システムの正しい状態を維持すること」と言えるのです。まあ、「正しい状態」の定義もしなくてはいけないのですけどね。
で、ここまでやってどんな効果があるのか？ということなのですが、構成管理はタイトルに「ファンダメンタル」と書いた通り、他のいろんな活動の基礎部分なのです。
つまり、構成管理というファンダメンタルがあるため、脆弱性対策、障害対応が迅速・適切にできる。地味な活動ではあるのですが、パフォーマンスを上げるという点では非常に重要な活動なので、もっと真剣に取り組んでいただけると、いいと思うのですが…。
NANAROQ株式会社セキュリティ・エグゼクティブ・ディレクター
中島浩光