Pregunta ¿Buenas prácticas sobre software discontinuado en producción (OpenDS)?


Que tan malo es usar OpenDS, que no se mantiene activamente, y tuvo el último parche en 2010, y requiere JDK6 (que también está obsoleto) en un entorno de producción (aunque en el backend y no directamente expuesto a los usuarios finales).

Si ya está allí, ¿merece la pena el tiempo y el dinero necesarios para encontrar un reemplazo, ejecutar pruebas de integración y demás? ¿Cuáles son los criterios comunes para dar este paso, con respecto al software obsoleto en producción en general?


8
2018-06-25 16:59


origen


Una buena práctica es hacer una evaluación adecuada de los riesgos en su situación individual. - HBruijn
En este caso específico, ¿no sería posible migrar a OpenDJ, que es una bifurcación de OpenDS y, probablemente, fácil de migrar a? - ptman
Secundando ForgeRock tiene un bonito poco mapa vial para OpenDJ, también. - Yolo Perdiem


Respuestas:


Le sugiero que evalúe esto en términos de riesgo comercial / operativo.

El uso de software antiguo y no compatible a menudo conlleva estos riesgos potenciales.

  • No hay soporte del vendedor
  • No hay actualizaciones de errores
  • No hay parches de seguridad.
  • Las actualizaciones del sistema operativo pueden ser incompatibles
  • Las opciones de recuperación de desastres pueden ser limitadas.
  • Los problemas de licencia pueden causar problemas de recuperación / operativos.
  • Incapacidad para escalar / expandir las operaciones basadas en este servicio.

Los dos últimos son a menudo pasados ​​por alto.

Hace años, tuve un caso en el que un cliente estaba usando un software MTA heredado y propietario. Obtuvieron un nuevo contrato importante de marketing por correo electrónico y necesitaban acelerar rápidamente su granja de servidores de correo.

No pudieron obtener una licencia para su MTA. El MTA tenía ciertas características y una API especial que se integraba profundamente en su plataforma de marketing por correo electrónico.

Tuvimos que clonar manualmente los discos y colocarlos en nuevos servidores más potentes para escalar el sistema. La renovación de un nuevo servidor hubiera tenido más sentido, pero no era una solución viable debido al software heredado.

Por lo tanto, si no planea actualizar pronto, es posible que deba evaluar los riesgos y, al menos, tener planes provisionales sobre cómo mitigar los problemas en caso de que surjan.

La gente a menudo menciona la seguridad. Sin embargo, el software antiguo, siempre que no tenga, explotaciones activas conocidas no es intrínsecamente más seguro que un reemplazo moderno.

El riesgo de seguridad no es que el software pueda ser explotado sino que no tiene un recurso fácil si se identifican problemas de seguridad.

Personalmente, preferiría actualizar algunos componentes clave de las operaciones de una manera planificada que intentar diseñar con urgencia una nueva solución.


13
2018-06-25 18:26