Aquí están mis "respuestas espontáneas", que pueden cambiar después de pensarlo más.
1) No estoy seguro si hay mucho sentido para una sal aquí. En el uso normal, una sal protege una base de datos de contraseñas filtrada contra ataques de arco iris. Eso ciertamente no es relevante aquí, y además, no creo que haya otra razón para la sal.
2) Hashing tampoco agrega mucha seguridad, creo. El hash se utiliza para ocultar un secreto durante el almacenamiento, no el tránsito. Si lo hash y pasas el hash, entonces eso significa que tu hash efectivamente es tu secreto, y un hash robado no es menos peligroso que un secreto robado. Por lo tanto, en un sentido muy real, también puede enviar el secreto, especialmente porque cambiará regularmente.
En resumen, efectivamente tiene dos defensas: un secreto compartido (que cambia) y una lista blanca de IP. Su secreto compartido será principalmente vulnerable a cosas como los ataques de repetición o la solicitud de escuchas: si alguien lo ve en tránsito, sabrá el secreto hasta que cambie. Usted mencionó que esto es de sistema a sistema, por lo que, dependiendo de si sus sistemas están o no en la misma zona de seguridad, probablemente determinará si dicha solicitud debe realizarse a través de TLS / SSL. Si estos sistemas se comunican entre centros de datos, es probable que desee comunicarse exclusivamente a través de TLS / SSL.
Su segundo nivel de seguridad es a través de la lista blanca de IP. Esto es principalmente vulnerable a la suplantación de IP, que, según la configuración de su red, puede o no ser un problema. Estoy seguro de que también hay más opciones, pero no soy un experto en redes.
Para un enfoque completamente diferente, puedes intentar implementar un protocolo de enlace. La idea básica es que cuando el servidor A envía una solicitud al servidor B, el servidor B valida la solicitud contactando al servidor A directamente, pasándole la solicitud completa que recibió y obteniendo una respuesta SÍ / NO (el "no" obviamente está devuelto si el servidor A no envió la solicitud en cuestión). Solo una vez que recibe el "SÍ", realmente procesa la solicitud. Esto requiere más esfuerzo para la configuración y también requiere más recursos de red / servidor, por lo que puede no ser preferible dependiendo de las necesidades de su aplicación. La ventaja es que descarta la suplantación de IP y también hace innecesario el intercambio secreto. Sin embargo, puede que no evite ataques de red más directos (es decir, MITM y similares).
Editar para agregar:
La idea del apretón de manos no es realmente mía. He usado ese flujo general en mis aplicaciones para validar las notificaciones de servidor a servidor. La idea en sí misma la robé de PayPal (así es como validan sus IPN), aunque probablemente tampoco sea originalmente su idea. Lo señalo simplemente porque es una práctica que ha estado en uso durante mucho tiempo, por lo que ambos pueden leer su documentación para comprender el flujo y (potencialmente) buscar información sobre problemas de seguridad pasados que puedan surgir debido a ese flujo. . Sin embargo, presumiblemente, dado que PayPal depende de una parte crítica de su infraestructura de pago, es bastante seguro:
enlace