アクティブにメンテナンスされておらず、2010年に最後のパッチが適用されていて、運用環境でJDK6(これも廃止された)が必要なOpenDSを使用するのはどれほど悪いことですか(バックエンドで直接エンドユーザーに公開されていませんが) )。
それがすでにある場合、一般的に、代替品を見つけたり、統合テストを実行したりするのに必要な時間とお金の価値がありますか?本番環境で廃止されたソフトウェア全般に関して、このステップを実行するための一般的な基準は何ですか?
アクティブにメンテナンスされておらず、2010年に最後のパッチが適用されていて、運用環境でJDK6(これも廃止された)が必要なOpenDSを使用するのはどれほど悪いことですか(バックエンドで直接エンドユーザーに公開されていませんが) )。
それがすでにある場合、一般的に、代替品を見つけたり、統合テストを実行したりするのに必要な時間とお金の価値がありますか?本番環境で廃止されたソフトウェア全般に関して、このステップを実行するための一般的な基準は何ですか?
回答:
ビジネス/オペレーショナルリスクの観点からこれを評価することをお勧めします。
サポートされていない古いソフトウェアを使用すると、これらの潜在的なリスクが軽減されます。
最後の2つは見過ごされがちです。
数年前、私は顧客がレガシーのプロプライエタリMTAソフトウェアを使用していたケースがありました。彼らは新しい主要なメールマーケティング契約を確保し、メールサーバーファームを迅速に立ち上げる必要がありました。
彼らはMTAのライセンスを確保できませんでした。MTAには、メールマーケティングプラットフォームに深く統合された特定の機能と特別なAPIがありました。
システムをスケールアウトするには、ディスクを手動で複製し、新しい強力なサーバーに配置する必要がありました。新しいサーバーを起動することは理にかなっていますが、レガシーソフトウェアのため、実行可能なソリューションではありませんでした。
したがって、すぐにアップグレードする予定がない場合は、リスクを評価し、少なくとも問題が発生した場合の軽減方法について暫定的な計画を立てる必要があります。
人々はしばしばセキュリティについて言及します。ただし、古いソフトウェアは、それがなければ、既知のアクティブなエクスプロイトは本質的に最新の代替品より安全ではありません。
セキュリティ上のリスクは、ソフトウェアが悪用される可能性があるということではありませんが、セキュリティの問題が特定された場合、簡単な解決策はありません。
個人的には、新しいソリューションを早急に設計するよりも、計画的な方法で主要な運用コンポーネントをアップグレードしたいと考えています。