¿Cómo puedo ocultar una contraseña en scripts de shell? Hay una serie de scripts que acceden a la base de datos. Si abrimos el script, otros también conocerán el nombre de usuario y la contraseña. Entonces, si alguien sabe cómo esconderse, hágamelo saber.
Tengo una forma:coloque la contraseña en un archivo y haga que el archivo esté oculto y nadie accederá al archivo (cambie los permisos y use el archivo en el script mientras accede a la base de datos).
Respuesta aceptada:
Primero , como ya han dicho varias personas, mantener las credenciales separadas del script es fundamental. (Además de una mayor seguridad, también significa que puede reutilizar el mismo script para varios sistemas con diferentes credenciales).
Segundo , debe considerar no solo la seguridad de las credenciales, sino también el impacto si/cuando esas credenciales se ven comprometidas. No debe tener una sola contraseña para todos los accesos a la base de datos, debe tener diferentes credenciales con diferentes niveles de acceso. Podría, por ejemplo, tener un usuario de base de datos que tenga la capacidad de realizar una búsqueda en la base de datos; ese usuario debería tener acceso de solo lectura. Otro usuario puede tener permiso para insertar nuevos registros, pero no para eliminarlos. Un tercero puede tener permiso para eliminar registros.
Además de restringir los permisos para cada cuenta, también debe tener restricciones sobre desde dónde se puede usar cada cuenta. Por ejemplo, no se debe permitir que la cuenta utilizada por su servidor web se conecte desde ninguna otra dirección IP que no sea la del servidor web. Una cuenta con permisos completos de raíz para la base de datos debería estar muy restringida en términos de desde dónde puede conectarse y nunca debería usarse de otra manera que no sea de forma interactiva. Además, considere usar procedimientos almacenados en la base de datos para restringir exactamente lo que puede hacer cada cuenta.
Estas restricciones deben implementarse en el lado del servidor de base de datos del sistema para que, incluso si el lado del cliente está comprometido, las restricciones no se puedan modificar desde él. (Y, obviamente, el servidor de la base de datos debe protegerse con cortafuegos, etc., además de la configuración de la base de datos...)
En el caso de una cuenta de base de datos a la que solo se le permite un acceso limitado de solo lectura y solo desde una dirección IP en particular, es posible que no necesite más credenciales, dependiendo de la confidencialidad de los datos y la seguridad del host del script. se está ejecutando. Un ejemplo puede ser un formulario de búsqueda en su sitio web, que se puede ejecutar con un usuario al que solo se le permite usar un procedimiento almacenado que extrae solo la información que se presentará en la página web. En este caso, agregar una contraseña realmente no confiere ninguna seguridad adicional, ya que esa información ya está destinada a ser pública y el usuario no puede acceder a ningún otro dato que sea más confidencial.
Además, asegúrese de que la conexión a la base de datos se realice mediante TLS, o cualquiera que escuche en la red pueda obtener sus credenciales.
Tercero , considere qué tipo de credenciales usar. Las contraseñas son solo una forma, y no la más segura. En su lugar, podría usar algún tipo de par de claves pública/privada, o AD/PAM o similar.
Cuarto , tenga en cuenta las condiciones en las que se ejecutará el script:
Relacionado:¿Código fuente de netstat?Si se ejecuta de forma interactiva, debe ingresar la contraseña, o la contraseña de la clave privada, o la clave privada, o iniciar sesión con un ticket de Kerberos válido, cuando lo ejecute; en otras palabras, el script debe obtener su credenciales directamente de usted en el momento en que lo ejecuta, en lugar de leerlas desde algún archivo.
Si se ejecuta desde un servidor web, considere configurar las credenciales en el momento en que inicia el servidor web. Un buen ejemplo aquí son los certificados SSL:tienen un certificado público y una clave privada, y la clave privada tiene una contraseña. Puede almacenar la clave privada en el servidor web, pero aún debe ingresar la contraseña cuando inicie Apache. También podría tener las credenciales en algún tipo de hardware, como una tarjeta física o un HSM, que se puede quitar o bloquear una vez que se inicia el servidor. (Por supuesto, la desventaja de este método es que el servidor no puede reiniciarse por sí solo si algo sucede. Preferiría esto al riesgo de que mi sistema se vea comprometido, pero su kilometraje puede variar...)
Si el script se ejecuta desde cron, esta es la parte difícil. No desea tener las credenciales en ningún lugar de su sistema donde alguien pueda acceder a ellas, pero sí desea tenerlas para que su secuencia de comandos pueda acceder a ellas, ¿verdad? Bueno, no del todo bien. Considere exactamente lo que está haciendo el script. ¿Qué permisos necesita en la base de datos? ¿Se puede restringir para que no importe si la persona equivocada se conecta con esos permisos? ¿Puede ejecutar el script directamente en el servidor de la base de datos al que nadie más tiene acceso, en lugar de hacerlo desde el servidor que tiene otros usuarios? Si, por alguna razón que no se me ocurre, absolutamente debes tener el script ejecutándose en un servidor inseguro y debe ser capaz de hacer algo peligroso/destructivo... ahora es un buen momento para repensar su arquitectura.
Quinto , si valora la seguridad de su base de datos, no debería ejecutar estos scripts en servidores a los que otras personas tienen acceso. Si alguien ha iniciado sesión en su sistema, entonces hará tiene la posibilidad de obtener sus credenciales. Por ejemplo, en el caso de un servidor web con un certificado SSL, existe al menos una posibilidad teórica de que alguien pueda obtener la raíz y acceder al área de memoria del proceso httpd y extraer las credenciales. Ha habido al menos un exploit en los últimos tiempos en el que esto podría hacerse a través de SSL, sin siquiera requerir que el atacante inicie sesión.
Además, considere usar SELinux o AppArmor o lo que esté disponible para su sistema para restringir qué usuarios pueden hacer qué. Le permitirán prohibir a los usuarios que incluso intenten conectarse a la base de datos, incluso si logran obtener acceso a las credenciales.
Si todo esto te parece excesivo , y no puede pagar o no tiene tiempo para hacerlo; entonces, en mi opinión (arrogante y elitista), no debería almacenar nada importante o confidencial en su base de datos. Y si no está almacenando nada importante o confidencial, entonces el lugar donde almacena sus credenciales tampoco es importante, en cuyo caso, ¿por qué usar una contraseña?
Relacionado:¿Generar cuatro palabras aleatorias de una lista para contraseñas similares a XKCD?Por último , si no puede evitar en absoluto almacenar algún tipo de credenciales, podría tener las credenciales de solo lectura y propias de root y root podría otorgar la propiedad de forma excesivamente temporal cuando lo solicite un script (porque su script debería no ejecutarse como root a menos que sea absolutamente necesario, y conectarse a una base de datos no lo hace necesario). Pero sigue sin ser una buena idea.