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