ITインフラ運用の現場が直面する「脆弱性対策」

2022年4月19日

ワイドテック プロダクト企画のYです。

去る4月6日から8日まで、久々に東京ビッグサイトで最大規模の会場「東展示棟」において、2022年の「Japan IT Week 春」が開催され、弊社も「システム運用自動化展」エリアに出展しました。ご来場いただいた皆様に、この場をお借りして感謝を申し上げます。


2022年「Japan IT Week 春 システム運用自動化展」ワイドテックブース


■久々の「東京ビッグサイト・東展示棟」

弊社POLESTARチームでは、2018年以来、新型コロナウイルスの影響で開催中止となった2020年を除いて、毎年Japan IT Week 春への出展を続けているのですが、最初に出展した2018年は東展示棟全体を使って開催され、3日間の来場者が10万人を超える規模の大規模展示会でした。弊社ブースは限られた人数で回していたにもかかわらず、多数のご来場をいただき、スタッフは休憩を取る間もないほどで、ハードだった印象が強烈に残っています。

しかし、東展示棟は2020年開催予定だった東京オリ・パラのプレスセンターに供されることになり、翌2019年はテーマ別に「前期」「後期」の分散開催となり、さらに会場も、東京ビッグサイト本棟の小さい方の会場「西展示棟」と、東展示棟が使えない期間中の展示スペース不足対策として、本棟最寄りのりんかい線「国際展示場」から1駅離れた「東京テレポート」駅前に仮設で建てられた「青海展示棟」での分散開催でした。

弊社は後期、青海展示棟での出展となりましたが、会期だけでなく会場までも分散し、1駅分離れた西展示棟と青海展示棟をバスで行き来するという状況では、来場者の足も遠のいてしまったようで、集客は前年をかなり下回ってしまいました。

翌2020年にも出展を予定していましたが、コロナ禍により中止に。昨年2021年も、オリ・パラの1年延期により東展示棟は召し上げられたままだった上、さらに緊急事態宣言の影響で日程が一度延期されたこともあり、当初西展示棟と聞いていた会場が変更され、またも青海展示棟となりました。しかし、強行的な開催かつ出展者の激減もあって、来場者も少なく、寂しい限りでした。

ちなみに仮設の青海展示棟は役目を終えた昨年末に解体されましたが、その眼の前にあって、2019年展示会の打ち上げや、何度か昼食を摂りにも出掛けた商業施設「ヴィーナスフォート」も、3月27日で閉鎖となってしまいました。建物の中にあった噴水や、ユニークな「空の照明」が印象的な施設でしたが、個人的にはそれらは青海展示棟とセットで、オリ・パラとコロナ禍対応というビッグサイト過渡期の風景として刻まれています。


■DXよりも何よりも、喫緊のテーマは「脆弱性対策」

さて、久々に東展示棟への帰還を果たしたJapan IT Week 春のPOLESTAR Automationブースですが、まだ出展を見合わせる企業が多く、3日間合計の全体来場者数も4万人弱と、過去最低だった昨年に比べれば3倍近くまで増えたものの、かつて10万を超えていたところからすると、まだ回復したとはいえない状況でした。

それでも、POLESTARブースには予想外に多くの皆様にご来場いただき、時間帯によっては応対が間に合わず、せっかくお越しいただいたのに、説明の機会を逸してしまうような場面もありましたことを、改めてお詫び申し上げます。

今回は弊社の新事業として、POLESTAR AutomationやZabbixを利用したマネージドサービス「ITインフラ運用DX支援サービス」を開始したこともあり、内部的に「ITインフラ運用のDX(デジタル・トランスフォーメーション)」を主なテーマに掲げていて、毎回の展示会で好評をいただいてきた、Zabbixとの連携による障害検知から回復までの自動化や、サーバー・ネットワーク機器構成の「いま」を瞬時に把握できる、構成管理ツールとしてのPOLESTAR Automationをご紹介するためのデモをメインで用意していました。

いざ蓋を開けてみると、目立ったのは「脆弱性対策」という課題を抱えておられるお客様の多かったことです。特に、サーバーを多数抱えるお客様にあっては、昨年12月に明らかになったJavaベースのオープンソースログ収集ライブラリ「Apache Log4j 2(以下Log4j)」の脆弱性「Log4Shell」対策が、喫緊の課題となっているようです。

過去にも暗号化データ通信を担うOpenSSLの「Heartbleed」や、UNIX/Linux系OSで最も有力なコマンドシェルであるBashで発覚した「シェルショック」など、サーバーなら何にでも入っているほど影響範囲が幅広く、危険度も高くて悪用されやすい大型の脆弱性事案が、数年ごとに発覚してきました。Log4jもオープンソース、商用を問わず多数のサーバー用ソフトウェアにおいて、ログ収集を司るモジュールとして組み込まれ、活用されてきたものです。

Log4Shell脆弱性のあるLog4jでは、任意のコードをリモートで実行可能となっていたため、この脆弱性を悪用すると、さまざまなマルウェアを企業のネットワーク上に侵入させることが可能です。ランサムウェアやボットネット、仮想通貨のマイニングプログラムなどを侵入・実行させた事例が確認されているようです。


■POLESTAR Automationで、脆弱性に立ち向かう

バイナリモジュールのバージョン特定によってセキュリティホールを見つけていた過去のHeartbleedやBashの脆弱性事案とは異なり、圧縮されたJavaの.jarファイルが対象となるLog4jの脆弱性確認は、やや面倒です。

POLESTAR Automationでは、シェルコマンドなどを利用して調査可能な範囲であれば、管理対象サーバーのインストール済みパッケージの構成を調べて、容易にリスト化できます。このリスト化や報告書の作成機能は、POLESTAR Automationならではのものといえます。

ソフトウェアパッケージに脆弱性確認済みのLog4jを含むことがベンダーから発表されている場合は、公開情報を用い、パッケージ名を確認することで特定できるでしょう。

パッケージ名で特定できない場合、Log4jのモジュール自体は、多くの場合「.jar」ファイルの形で存在していますので、WindowsならWHERE、UNIX/Linux系ならfindなどのコマンドにより、サーバー内のファイルを検索することで発見できます。

ファイル名にバージョン番号が含まれている場合は簡単ですが、ファイルがリネームされてバージョン番号が抹消されているなどの場合は、.jarファイルをZIPアーカイブ用の展開ツールで展開し(.jarファイルはZIP形式で圧縮されています)、中に必ずある「MANIFEST.MF」ファイルに記載のバージョン番号を調べることで特定が可能です。

こうした一連の作業は、POLESTAR Automationではジョブを書いて実行することで、ある程度自動化できるでしょう。ただし、findやWHEREなどのコマンドはサーバーのファイルシステムなどに負荷を掛けるものですので、実行にあたってはスケジュールの検討が必要でしょう。

POLESTAR Automationなら、ジョブ実行のスケジュールも設定できますので、夜間などシステムが稼働していないか、稼働率の低い時間帯に、そうした作業を自動的に行うことができるでしょう。


■さまざまな運用の課題を、まとめて解決!

インストールやデプロイ、アップデートから、死活監視やパフォーマンス管理、そして脆弱性対応まで。多岐にわたるITインフラ運用の多くの場面において、課題解決に役立つのが、POLESTAR Automationです。

脆弱性・セキュリティ対策については、ゼロデイ(未知の)脆弱性のようにPOLESTAR Automationでは対応が難しいものもありますが、いざ脆弱性事案が発生すれば、POLESTAR Automationの得意とする構成管理が役立ちます。

また、ネットワーク機器における不要なポートの開放確認、サーバーやミドルウェア、アプリケーションへのタイムリーなパッチ適用など、セキュリティの基本とされつつも手作業では煩雑な日常のセキュリティ対策にも、POLESTAR Automationは有用です。 まずは、評価版でお試しください。