shell-script – Ocultar la contraseña en los scripts de Shell

Pregunta:

¿Cómo puedo ocultar una contraseña en los scripts de shell? Hay varios 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 que nadie acceda al archivo (cambie los permisos y use el archivo en el script mientras accede a la base de datos).

Respuesta:

Primero , como ya han dicho varias personas, mantener las credenciales separadas del guión es esencial. (Además de una mayor seguridad, también significa que puede reutilizar el mismo script para varios sistemas con diferentes credenciales).

En segundo lugar , debe considerar no solo la seguridad de las credenciales, sino también el impacto en caso de que esas credenciales se vean 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. Por ejemplo, podría 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 borrar registros.

Además de restringir los permisos para cada cuenta, también debe tener restricciones sobre dónde se puede utilizar cada cuenta. Por ejemplo, la cuenta utilizada por su servidor web no debe poder conectarse desde ninguna otra dirección IP que no sea la del servidor web. Una cuenta con permisos de root completos para la base de datos debe estar muy restringida en términos de dónde puede conectarse y nunca debe usarse de 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 pueden modificar. (Y, obviamente, el servidor de base de datos debe estar protegido 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 acceso limitado de solo lectura, y solo desde una dirección IP en particular, es posible que no necesite más credenciales que esa, dependiendo de la confidencialidad de los datos y la seguridad del host, el script está siendo huido. 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 utilizar 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 sensible.

Además, asegúrese de que la conexión a la base de datos se realice mediante TLS, o cualquiera que esté escuchando en la red puede obtener sus credenciales.

En tercer lugar , considere qué tipo de credenciales utilizar. Las contraseñas son solo una forma y no son las más seguras. En su lugar, podría utilizar algún tipo de par de claves pública / privada, o AD / PAM o similar.

Cuarto , considere las condiciones bajo las cuales se ejecutará el script:

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 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 inicie 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 necesita ingresar la contraseña cuando inicie Apache. También puede tener las credenciales en algún tipo de hardware, como una tarjeta física o un HSM, que se pueden 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 sucede algo. 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 cualquier lugar de su sistema donde alguien pueda acceder a ellas, pero sí desea tenerlas para que su script pueda acceder a ellas, ¿verdad? Bueno, no del todo bien. Considere exactamente lo que está haciendo el guión. ¿Qué permisos necesita en la base de datos? ¿Se puede restringir para que no importe si la persona equivocada se conecta con esos permisos? En su lugar, ¿puede ejecutar el script directamente en el servidor de base de datos al que nadie más tiene acceso, en lugar de desde el servidor que tiene otros usuarios? Si, por alguna razón en la que no puedo pensar, absolutamente debe tener el script ejecutándose en un servidor inseguro y debe poder hacer algo peligroso / destructivo … ahora es un buen momento para reconsiderar su arquitectura.

En quinto lugar , 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, tendrá la posibilidad de acceder a 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 root 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 necesidad de 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 no permitir que los usuarios intenten conectarse a la base de datos, incluso si logran obtener acceso a las credenciales.

Si todo esto le parece exagerado y no puede pagarlo o no tiene tiempo para hacerlo, entonces, en mi opinión (arrogante y elitista), no debería almacenar nada importante o sensible en su base de datos. Y si no está almacenando nada importante o sensible, entonces dónde almacena sus credenciales tampoco es importante, en cuyo caso, ¿por qué usar una contraseña?

Por último , si absolutamente no puede evitar almacenar algún tipo de credenciales, podría hacer que las credenciales sean de solo lectura y poseerlas por raíz y la raíz podría otorgar la propiedad de forma extremadamente temporal cuando se lo solicite una secuencia de comandos (porque su secuencia de comandos no debe ser ejecutar como root a menos que sea absolutamente necesario, y conectarse a una base de datos no lo hace necesario). Pero todavía no es una buena idea.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım