IBM、以前のIBM i リリースではNew Navをサポートしない意向を表明
Navigator for iの旧バージョン（「Old Nav」）に深刻なLog4jセキュリティ脆弱性があるにもかかわらず、IBMでは、以前のリリースのIBM i オペレーティング システムでNavigator for iの新バージョン（「New Nav」）をサポートする意向はないようです。また、予想外に早くOld Navの終焉を迎えたことで、現行リリースの顧客も、New Navの導入を急かされることになり、3月のアップデートでは、New Navがデフォルト バージョンになるとIBMは述べています。
今月初めに IBM は、Old Nav向けの セキュリティ パッチは用意されていない 旨を発表しました。Old Navは、サイバー犯罪者が被害を受けた製品を完全にコントロールすることを可能にする、深刻なゼロデイ セキュリティ エクスプロイトの核心にあるLog4jコードを使用しています。IBMでは、ユーザーに対して、Old Navの使用を止めて、直ちに、New Navを使用し始めることを推奨しています（ New Navは、9月にIBM i 7.3および7.4向けの最新のテクノロジー リフレッシュ（TR）で公開されています ）。
ここで問題となるのは、New NavはIBM i 7.3および7.4でのみ利用可能である点です。IBMがNew Navを発表した時点で、延長サポートに移行しているバージョン7.1および7.2など、IBM i の以前のリリースでは、New Navは利用可能とされていませんでした。12月にLog4jの脆弱性が明らかになっても、その決定は変わらないと、IBM i プロダクト マネージャーのAlison Butterill氏は述べています。
「IBM i 7.2および7.1は、現在もお使いいただいてはおりますが、すでに延長サポートに移行している製品です」とButterill氏は述べます。「したがって、IBMの標準延長サポート ポリシーへの準拠のため、新機能をロール バック（旧製品への組み込み）することはありません。」
IBMにできることはないとButterill氏は述べます。IBMがOld Navをパッチしようと思っても、Old Navの構築の際に使用したオープンソース コードが利用可能でなくなっているため、そうすることができないのだとButterill氏は述べています。
「最新のバージョンをリリースした理由の1つには、実際、旧バージョンが本当に時代遅れになっているということがあります」と彼女は『 IT Jungle』に述べます。「旧バージョンの一部には、率直に言ってもう更新できないそうしたオープンソース コードが含まれていました。そうしたコードは私たちのものではありません。オープンソースからのものです。そのため、New Navigatorのリリースを決めた時点で、旧バージョンを修正することはできなくなるというのは承知の上でした。」
IBM i 7.1および7.2を使用しているユーザーがOld Navの使用を中止しても、使えなくなる機能はないとButterill氏は述べています。そうした機能の大半は、グリーン スクリーンの対応する機能を使用することで間に合うからです。「Old Navは、実のところは一元管理を行うためのコンソリデーション ツールでした。他の機能に関して言えば、ランチャーとも言えます」と彼女はOld Navについて述べています。「いくつか当てはまらないものもありますが、直接、グリーン スクリーンのコマンド ラインから、そうした機能の多くは実行することができるのです。」
Old Navには深刻なセキュリティ脆弱性があるものの、リスクを承知の上であれば、これまで通り使用することもできるとButterill氏は述べています。「Old Navはそこで動いています。どのようなリスクに曝されるかを理解した上であれば、そのまま使用し続けることもできます」と彼女は述べます。「しかし、実際には、Old Navをオフにして、グリーン スクリーン コマンド ラインからすべてを実行するようにしている顧客がほとんどのようです。確実だからです。」
IBM i 7.1または7.2で、どうにかしてNew Navを稼働できたとしても、発表されている通りには動作しないとButterill氏は述べます。これは、IBM i プラットフォームの他のコンポーネントの中には、そうした以前のリリースには存在しなかったものもあるためです。「技術的には、New Navigatorは7.2でも動作するでしょうが、そうした旧バージョンの他の製品には接続されないため、何も起動できません」と彼女は述べています。
IBM i 7.1および7.2は、長期サポート下にあるため、「使用法および既知の問題のサポート」が提供されます。IBMは、たとえば、9月に OpenSSLの脆弱性に対して行った ように、IBM i 7.1および7.2のセキュリティ脆弱性のパッチを行うこともありますが、こうした以前のOSのユーザーに、Old NavにおけるLog4jの問題に対するフィックスが提供されることはありません。この場合、「フィックス」というのはOld NavをNew Navに置き換えることであり、それは新機能とみなされるからです。
「4月30日以降は、まれな例外を除いて、これ以上問題をフィックスすることはなくなります」とButterill氏は述べます。「まれな例外というのは、たとえば、7.3で問題が確認された場合、その影響レベルによっては、7.2へロール バックすることができるということです。そうするかもしれませんし、しないかもしれません。しかし、そうするのは、私たちの本意ではありません。だからこそ、延長サポートに移行しているのです。」
Old Navは、現在も、12月に公開された最新リリースのAccess Client Solutions for i（ACS）バージョン1.1.8.8で起動するデフォルト バージョンですが、3月リリース予定のPTF以降は、New NavがデフォルトになるとButterill氏は述べています。
GUIのスピードは、IBMが9月に新リリースを発表した際の、New Navの大きなセールス ポイントでした。AngularやPrimeNGのようなJavaScriptツールを使用して構築されたNew Navは、より多くのJavaコンポーネントで構築されていたOld Navに比べて、大幅に改善されたユーザー エクスペリエンスを提供することが意図されていました。また、新ソフトウェアは、IBM i サービスをより幅広く活用することも特徴になっています。IBM i サービスは、それぞれ特定のタスクを実現する小さなSQLコードであり、IBMが、グリーン スクリーン環境のIBM i コマンドおよびCLルーチンの最新の代替機能と位置付けている機能です。
しかし、新製品であるNew Navは、現時点では、Old Navのすべての機能をサポートしているわけではありません。IBM i ユーザーからも、Old Navでは利用できた、Advanced Job Scheduler、PowerHA、BRMS、およびAFPフォーム機能などの機能が、まだNew Navでは利用できないという声が上がっています。そうした違いについてIBMは承知しており、その件に関しては取り組みを行っているとButterill氏は述べています。
「現時点では、New Navigator製品にはまだない機能がいくつかあります」と彼女は述べます。「どうやら、それらの機能すべてをNew Navigatorに組み込もうとして、時間が掛かっているようです。そのため、まったくの1対1での置き換えにはならない機能もあるかもしれません。同じような機能を提供する別の手段を使用することを選ぶケースもあるかもしれません。必ずしもすべての機能が1対1で置き換えられるわけではありませんが、すべての機能について改善を実感されることと思います。」
ロチェスターのIBM i マネジメント チームは、New Navをより迅速に導入してもらえるようにするために、どのようなことができるかを考えています。このグループは、どのようにしたら、プロモーションおよびアウトリーチ活動を通じて、New Navの市場認知を高めることができるかについて検討しているとButterill氏は述べます。IBMが、New Navの導入を促進するための取り組みの一環としてOld Navとの機能ギャップを埋めることを優先するかどうかは、現時点ではまだ明らかではないと彼女は述べています。
「Log4jによって、言ってみれば、いくつかの取り組みに着手させられることになりました。私たちは、まだ、その選り分けようとしている途中です」と彼女は述べています。「現時点でも、通常のデリバリー スケジュールに向けて取り組んでいることがたくさんあります。そこへ何を組み込み、何の優先順位を変更するか。ポートフォリオを調べて何を行う必要があるか考えながら、現時点で、検討しているのはそういうことばかりです。」
IBM i 7.3および7.4の場合、Old NavのLog4j脆弱性に対する最善の対処法は、New Navへアップグレードすることです。IBM i の以前のリリースを稼働している場合は、現行バージョンへのアップグレードが最善の防御策となるとButterill氏は述べています。
「定期的に以前のリリースに新機能を追加し続けるとしたら、誰もアップグレードを行おうとはしないでしょう」とButterill氏は述べます。「そして、この件に関して厄介だったのは、たとえばLog4jのように、2014年に7.2を発表したときには知られていなかった問題に出くわしたということです。そしてそれは突然現れたわけです。クライアントがアップグレードを行い、常に最新の状態を保ち続ける必要があるのは、まさにこうしたことがあるためです。このような問題の対応は、最新リリースで行うからです。」
