Boas práticas relacionadas ao software descontinuado em produção (OpenDS)?

8

Quão ruim é usar o OpenDS , que não é mantido ativamente, e teve o último patch em 2010, e requer o JDK6 ( que também é obsoleto) em um ambiente de produção (embora no backend e não diretamente exposto aos usuários finais).

Se já está lá, geralmente vale a pena o tempo e dinheiro necessários para encontrar um substituto, executar testes de integração e tal? Quais são os critérios comuns para dar esse passo, em relação ao software obsoleto na produção em geral?

    
por Henrik Kjus Alstad 25.06.2014 / 18:59

1 resposta

13

Sugiro que você avalie isso em termos de risco operacional / de negócios.

O uso de software antigo e sem suporte costuma prejudicar esses possíveis riscos.

  • Não há suporte para fornecedores
  • Não há atualizações para bugs
  • Sem patches de segurança
  • As atualizações do sistema operacional podem ser incompatíveis
  • As opções de recuperação de desastre podem ser limitadas.
  • Problemas de licenciamento podem causar problemas operacionais / de recuperação.
  • Incapacidade de dimensionar / expandir operações com base nesse serviço.

Os dois últimos são frequentemente ignorados.

Anos atrás, eu tive um caso em que um cliente usava software MTA herdado e legado. Eles garantiram um novo contrato importante de marketing por e-mail e precisaram acelerar rapidamente o farm de servidores de e-mail.

Eles não conseguiram obter uma licença para o seu MTA. O MTA tinha alguns recursos e uma API especial que se integrou profundamente em sua plataforma de email marketing.

Tivemos que clonar discos manualmente e colocá-los em novos servidores mais poderosos para dimensionar o sistema. Girar o novo servidor teria feito mais sentido, mas não era uma solução viável devido ao software legado.

Portanto, se você não planeja fazer uma atualização em breve, talvez seja necessário avaliar os riscos e, pelo menos, ter planos preliminares sobre como atenuar os problemas, caso eles surjam.

As pessoas costumam mencionar a segurança. No entanto, o software antigo, desde que não tenha explorações ativas conhecidas, não é inerentemente mais seguro do que um substituto moderno.

O risco de segurança não é que o software possa ser explorado, mas você não tem um recurso fácil se forem identificados problemas de segurança.

Pessoalmente, prefiro atualizar alguns componentes-chave das operações de uma maneira planejada do que tentar projetar com urgência uma nova solução.

    
por 25.06.2014 / 20:26