¿Cuál es la forma estándar de autenticación de integración de servidor a servidor (cross internet)

3

Digamos que tengo dos servidores en diferentes centros de datos. Necesitan hablar entre ellos, ¿cómo proteger la seguridad? TLS es una necesidad. Para la autenticación, nos preocupa usar la credencial, ya que si se la roban, cualquiera puede usarla para hacer la llamada de integración. Entonces empezamos a pensar en usar la autenticación mutua basada en el certificado del cliente. Sin embargo, mi entendimiento es certificado de cliente también puede ser robado. Entonces, ¿es realmente mucho más fuerte que el nombre de usuario / contraseña? Además, si hacemos una restricción de IP, ¿hará la integración mucho más segura?

Esperamos sus consejos.

¡Gracias!

    
pregunta William 26.08.2017 - 01:15
fuente

3 respuestas

1

ssh incluye, por defecto, la autenticación del servidor igual: cada servidor tiene su propia clave privada que solo se encuentra en una carpeta legible que solo se encuentra en la raíz y todas las máquinas colaboradoras tienen la lista de las claves públicas de sus pares.

Una configuración común luego permite que ssh pase el nombre del usuario que llama, y la persona que llama confía en ese nombre de usuario porque se ha autenticado en un compañero de confianza. Normalmente, esto no se extiende a la cuenta raíz, pero se usa comúnmente para la colaboración de servidores remotos sin supervisión con cuentas dedicadas.

    
respondido por el Serge Ballesta 24.12.2017 - 17:26
fuente
1

La autenticación mutua TLS es su opción más segura y es lo que generalmente recomiendo para la autenticación de servidor a servidor, excepto por una situación muy específica y menos común que explicaré más adelante. La autenticación de certificado mutuo de TLS es más segura que la autenticación de contraseña porque con la autenticación de certificado de TLS, las claves privadas nunca se envían en la comunicación. Con una autenticación de clave precompartida (también conocida como contraseña), el token secreto puede verse comprometido solo por una intercepción exitosa, y dado que ambos lados del servidor necesariamente manejan el token secreto en un punto u otro, por lo que puede comprometer a ambos autenticadores simplemente comprometiendo Un lado de la conexión. La autenticación de certificados limita el impacto, ya que solo un lado de la credencial está comprometido.

Con la autenticación mutua TLS de servidor a servidor, tiene la opción de utilizar una CA pública, que cuesta una pequeña cantidad de dinero pero le permite externalizar la complejidad de ejecutar una entidad de certificación raíz a alguien con la experiencia adecuada para hacerlo. , o puede ejecutar una raíz privada, por lo que no tiene que confiarle a un tercero la seguridad de su red de sistemas. Hay ventajas y desventajas de cada uno, y debes considerarlos cuidadosamente.

  

Sin embargo, mi entendimiento es que el certificado del cliente también puede ser robado.

Cualquier credencial puede ser robada, es por eso que debe proteger sus servidores y hacer planes de contingencia para estas situaciones. Si tiene una situación en la que le preocupa el robo de una clave privada, tiene dos opciones:

  1. En la mayoría de los casos, puede diseñar procesos y procedimientos para que pueda revocar y reemplazar rápidamente el certificado robado. Esto puede significar que debe usar un certificado raíz que genere los certificados de pares y / o que necesite una manera de revocar y desplegar de forma relativamente rápida en todos los servidores que necesitan autenticarse entre sí.
  2. Si tiene una situación en la que es extremadamente difícil reemplazar la raíz de la confianza, por ejemplo, si tiene millones de máquinas administradas por cientos o miles de empresas / individuos diferentes, entonces realmente desea asegurar la raíz de la confianza. En este caso, debe hacer # 1, y también usar un módulo de seguridad de hardware. Un HSM es un token de hardware que almacena su clave privada y realiza operaciones criptográficas para que la clave nunca abandone el HSM. HSM le permite convertir el riesgo de asegurar el servidor a la seguridad física del robo físico del propio HSM.

Mi otra recomendación puede ser necesaria si tiene una situación en la que necesita autenticación de extremo a extremo, donde su modelo de seguridad es tal que los servidores no se consideran una parte confiable en la comunicación entre los usuarios de cualquiera de los servidores. El ejemplo más común de esto es el correo electrónico y el chat cifrados de extremo a extremo. En este caso, desea agregar una autenticación y cifrado a nivel de la aplicación, de manera que los servidores nunca tengan la clave privada del usuario y, por lo tanto, no puedan hacerse pasar por sus usuarios. En este modelo de seguridad, los usuarios confían en otros usuarios directamente, pero no necesariamente confían en el servidor, excepto como un simple agente de entrega. Mi recomendación para esto es usar GPG o cualquier cosa que implemente Double Ratchet como el protocolo Signal.

Como alternativa, OAuth / OAuth2 puede ser necesario cuando necesite una autenticación de tres patas: usuario / aplicación, servidor de identidad y servidor de recursos. A menos que realmente tenga una situación de tres patas, probablemente no necesite la complejidad de OAuth / OAuth2.

  

Además, si hacemos una restricción de IP, ¿hará la integración mucho más segura?

Si ya tiene la autenticación adecuada, la integración será un poco más segura, pero no mucho. La restricción de IP realmente solo es útil contra los ataques DoS porque el firewall IP es relativamente barato de implementar con un firewall de capa 3, pero por sí solo, no es suficiente para ningún tipo de autenticación y el hecho de no tener restricciones de IP generalmente no es el fin del mundo.

    
respondido por el Lie Ryan 25.12.2017 - 17:27
fuente
0

Cuando la lista de sistemas interconectados es pequeña y es relativamente estática, la lista blanca de direcciones IP es el mecanismo más utilizado. Es menos seguro que usar la autenticación TLS bidireccional.

Para preocuparse por "¿qué pasa si me roban mi certificado TLS?" es como preocuparse por "¿qué pasa si mis frenos fallan?". Por esta razón, no tiene sentido acabar con los frenos. Más bien, aumenta esa buena solución con inspecciones y reemplazos periódicos.

En su caso, la solución sería

  • asegúrese de que los servidores estén bien asegurados para minimizar la posibilidad de compromiso
  • implementar un proceso rápido de detección y respuesta rápida para recuperarse en caso de un compromiso.

Eso aparte -

La forma más común de autenticación de servidor a servidor sobre TLS es a nivel de la aplicación. En cierto modo podemos llamarlo como aplicación a la autenticación de la aplicación.

OAUTH / OAUTH2 están diseñados solo para este propósito. Es posible que desee considerar el uso de uno de ellos.

    
respondido por el Sas3 26.08.2017 - 05:20
fuente

Lea otras preguntas en las etiquetas