Autenticación para un script por lotes

Question

Autenticación para un script por lotes

#1 de D.W. (1 votos)

2

Parece sorprendente que aún no haya una mejor práctica aceptada por la industria para este problema (o tal vez solo una que no conozca):

¿Cuál es la forma más segura para un script por lotes, un programa que necesita conectarse a un recurso (por ejemplo, la base de datos) a través de una interacción no impulsada por el usuario para autenticarse? Las respuestas agnósticas tecnológicas son mejores, pero si hay una gran diferencia en función del sistema operativo (Windows, Unix, Mainframe, etc.), la base de datos o el lenguaje del programa, también es útil saberlo.

Sería bueno si pudiera explicar por qué la solución (u opciones en orden de preferencia) es segura (por ejemplo, protege contra usuarios internos malintencionados, atacantes externos, malware de estas maneras). También por qué tiene un bajo impacto operativo (cambio, mantenimiento, etc.).

Por ejemplo, mi lista:

Mejor preferencia de IMO (más segura) a menos:

Autenticación basada en certificados donde el certificado se almacena en un HSM
Autentificación basada en certificados donde el certificado se almacena en un módulo criptográfico de software
Autentificación basada en certificados donde el certificado es el almacén de certificados del sistema operativo, generalmente necesita root para obtener acceso, por lo que el juego está activo si esto ocurre
Autenticación externalizada basada en un LDAP
Contraseña basada en donde la contraseña se cifra y almacena en un servidor diferente o en el almacén de contraseñas. Solo la cuenta de servicio está autorizada para conectar, descifrar y recuperar la contraseña a través de un transporte seguro (básicamente, cómo TDE funciona con Oracle Wallet)
Contraseña basada donde la contraseña se cifra y almacena en el servidor. La cuenta de servicio solo puede descifrar.
La contraseña se basa donde la contraseña se almacena en el servidor pero está protegida por los permisos del sistema operativo y se excluye de la copia de seguridad (copia de seguridad manual en el almacén de contraseñas).

El certificado es el mejor con diferencia y el método de facto para algo como Amazon EC2, Github, etc.

Por favor, cierre y redirija si esto ya está respondido. No pude encontrarlo cuando busqué.

authentication databases service-account batch

pregunta Rakkhi 10.05.2012 - 05:17

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication databases service-account batch

¿Cómo investigar un posible acceso ilegal de un miembro del personal a los correos electrónicos? Script PHP / BASH malicioso (?). ¿Qué es?

score 1 · Answer 1

La respuesta depende del modelo de amenaza y de las amenazas que intenta evitar.

Un método sólido estándar es usar la autenticación basada en clave pública, como los siguientes ejemplos:

El cliente se conecta por SSH. El cliente se autentica utilizando su clave DSA personal (no protegida por ninguna frase de contraseña). O,
El cliente se conecta a través de SSL. El cliente se autentica utilizando un certificado de cliente adecuado. El cliente verifica el certificado del servidor para asegurarse de que está hablando con el servidor con el que se espera que hable.

Este enfoque es bastante bueno para la mayoría de las configuraciones. Es seguro contra ataques a nivel de red. Por supuesto, la clave privada del cliente vive claramente en la máquina cliente. (Tiene que hacerlo más o menos). Como consecuencia, cualquier atacante que irrumpa en la máquina del cliente puede robar la clave privada del cliente.

Si necesita detectar la amenaza de un compromiso de la máquina cliente, puede almacenar la clave privada en un HSM o tarjeta inteligente conectada a la máquina cliente y hacer que se autentique de esa manera. Esto proporciona beneficios de seguridad modestos: un atacante que compromete la máquina cliente ya no puede robar la clave privada del cliente, pero el atacante todavía puede hacer conexiones arbitrarias al servidor como cliente y enviar datos arbitrarios, siempre y cuando el atacante mantenga su control. sobre el cliente. Si se trata de una mejora de seguridad o no (en comparación con el simple almacenamiento de la clave privada de forma clara en el cliente) depende en gran medida de la aplicación. Además, si esto vale la pena el costo adicional y la molestia del HSM o la tarjeta inteligente también depende en gran medida de la aplicación.

También existen otros enfoques con algunas ventajas y desventajas leves en comparación con las anteriores, pero nada que sea abrumadoramente superior.