Si los datos nunca salen del sistema, probablemente no haya ninguna ventaja de usar SSL para proteger los datos transmitidos. Pero veo otros problemas con su enfoque:
Tiene un servidor web local que suministra una consola de administración para un producto que usamos
Esto sugiere que acceda a la consola de administración con un navegador web en el sistema local. A menos que haya alguna forma de restringir el navegador solo a este host, debe tener mucho cuidado con los ataques como CSRF, que pueden activarse si visita otros sitios con el mismo navegador. Este es un vector de ataque típico para las consolas de administración basadas en web y le sorprendería cuántos enrutadores o incluso los firewalls son vulnerables a este tipo de ataque.
E incluso con esta restricción, se pueden desencadenar acciones de administración no deseadas desde los registros de visitas u otros archivos en su consola de administración, a menos que haya tenido mucho cuidado de evitar la entrada del usuario para vencer los ataques usando inyecciones de script o inyecciones de HTML (como XSS).
También es probable que sea fácil acceder a la consola desde el control remoto mediante el envío explícito de puertos (utilizando masilla o productos similares). Esto se usa comúnmente para los sistemas de control remoto, incluso si el propio proveedor se aseguró explícitamente de que el acceso remoto no es posible en la configuración predeterminada por razones de seguridad. Se hace porque este tipo de restricción a menudo se ve más como una molestia y el riesgo se ignora.
Los firewalls han bloqueado el acceso a la consola de administración para todos los sistemas externos.
Si esta protección solo es realizada por cortafuegos, entonces debe verificar el diseño nuevamente. Por lo general, es mejor que el servidor solo se ejecute en una dirección IP a la que no se pueda acceder desde fuera por diseño, por ejemplo. localhost (127.0.0.1). En este caso, no se necesitaría un firewall para restringir el acceso y hay una cosa menos que puede salir mal.