Mejores prácticas para almacenar las credenciales utilizadas por el código

Question

Mejores prácticas para almacenar las credenciales utilizadas por el código

#1 de Hrvoje Milković (5 votos)

6

Actualmente, tengo muchos scripts que necesitan iniciar sesión como superusuario para automatizar muchas tareas. (Por ejemplo, crear tablas en bases de datos, crear otros usuarios, etc.)

En lugar de tener las credenciales (especialmente las contraseñas) almacenadas directamente en el script, las estoy leyendo desde un archivo (llámelo pwds.txt), al que solo puede acceder un usuario root.

Algunos de mis colegas dicen que un enfoque más seguro es tener la contraseña cifrada en pswds.txt, ocultar la clave en algún lugar y descifrar los datos cifrados en el script antes de que lo use.

Afirmo que solo reduce el problema para encontrar dónde se encuentra la clave, lo que no parece difícil en absoluto y un adversario que puede leer el script. Creo que este proceso simplemente complica la programación sin proporcionar realmente una capa real de protección.

Dos preguntas:

¿Quién es más correcto, yo o ellos? (y por qué)
Sé que el 100% de seguridad no existe, pero ¿cuáles son las mejores prácticas para mi problema?

passwords password-management password-policy

pregunta sel 21.02.2018 - 18:57

fuente

1 respuesta

Lea otras preguntas en las etiquetas passwords password-management password-policy

Alternativas a SMS como un canal fuera de banda Drupal 7 - ataque en los registros

score 5 · Accepted Answer

1) Eres 100% correcto, ¿Por qué? Si la máquina se ve comprometida, el atacante aún podrá recuperar la clave de descifrado ya que es necesario que exista un cifrado simétrico para descifrar mediante la aplicación y el archivo de claves debe tener los mismos permisos de lectura que la aplicación para que la aplicación pueda leerlo.

Me refiero a que la aplicación todavía necesita tener un directorio de descifrado secreto codificado en secreto para que el atacante la busque: D, incluso si la aplicación es un ejecutable binario el atacante puede volcar fácilmente cadenas de directorios de archivos y archivos desde él.

Lo sé porque lo hice desde un programa de idioma Go que necesitaba depurar y no tenía el código fuente (una de las aplicaciones de los clientes alojada en el servidor) :)

Los ataques de desbordamiento de búfer y demás funcionarán si el agujero está presente como App ether way almacena los datos en la memoria para reutilizarlos, por ejemplo, para la autenticación de la base de datos.

2) La mejor solución es tener una bóveda central donde cada aplicación solicite sus secretos y los alquile. Una solución de este tipo es enlace y más detalles sobre ella enlace

La mejor práctica general es minimizar los derechos de acceso y control de cada función para cada recurso de aplicación. Ejemplo: Si una aplicación solo usa una base de datos, ¿no tienen esos derechos de usuario para ver otros? o para ejecutar DML en otros, elimine los derechos de la tabla desplegable si la aplicación no realiza migraciones, etc.

Si no usa la bóveda si el script es ejecutado por ejemplo, el usuario root no guarda secretos con la propiedad de usuarios menos privilegiados, permita que el propietario sea el mismo usuario, use lectura, escritura y ejecute los permisos solo lo que realmente necesita.

Use TLS cuando pueda para sus recursos como datos de fuga de volcado de tcp si el atacante logra obtener la fase de autenticación como quiera que almacene los datos secretos.