¿Mejores prácticas para mantener contraseñas en shell/scripts de Perl?

Question

Recientemente tuve que desempolvar mis habilidades de script Perl y shell para ayudar a algunos colegas. Los colegas en cuestión han recibido la tarea de proporcionar algunos informes de una aplicación interna con un gran back-end de base de datos de Oracle, y simplemente no tienen las habilidades para hacerlo. Si bien algunos podrían cuestionar si tengo esas habilidades (sonrisa), al parecer, la gente piensa que sí quiero decir que no puedo evitarlo.

Por lo tanto, a mi pregunta: para extraer los informes de la base de datos, mi script obviamente tiene que conectarse y ejecutar consultas. Hasta ahora no he logrado encontrar una buena solución para almacenar el nombre de usuario y la contraseña de la base de datos, por lo que actualmente se almacena como texto sin formato en el script.

¿Hay una buena solución para esto que alguien más ya haya escrito, tal vez como un módulo de CPAN? ¿O hay algo más que es mejor hacer, como mantener el combo usuario/contraseña en un archivo completamente separado que está escondido en otro lugar en el sistema de archivos? ¿O debería mantenerlos trivialmente encriptados para evitar que sean sacados de mis scripts con un grep de todo el sistema?

Editar: La base de datos Oracle se encuentra en un servidor HP-UX.
El servidor de aplicaciones (que ejecuta los scripts de shell) es Solaris.
Establecer las secuencias de comandos para que sean propiedad de mí solo es un no-go, tienen que ser propiedad de una cuenta de servicio que tiene acceso al personal de soporte múltiple.
Los scripts están destinados a ejecutarse como tareas cron.
Me encantaría ir con autenticación de clave pública, pero desconozco los métodos para hacer que eso funcione con Oracle, si existe tal método, ¡infórmame!

Answer 1

La mejor práctica, en mi humilde opinión, sería NO mantener contraseñas en un shell/script de Perl. Para eso es la autenticación de clave pública.

Answer 2

No hay una buena solución. Puedes ofuscar las contraseñas un poco, pero no puedes protegerlas.

Si tiene control sobre la configuración de su base de datos, puede tratar de conectarse por un conducto con nombre (al menos mysql lo admite) sin una contraseña y dejar que el sistema operativo maneje los permisos.

También puede almacenar las credenciales en un archivo con permisos restrictivos.

Answer 3

Como ha etiquetado ksh & bash, voy a asumir Linux.

La mayor parte del problema es que si el usuario puede leer la secuencia de comandos y localizar el método que utilizó para ocultar/encriptar el archivo, entonces también podrá hacer lo mismo manualmente.

Una mejor manera se puede hacer lo siguiente:

1. Haga su escritura por lo que sólo puede ser visto/lectura/abierto por usted. chmod 700 it. Hardcode contraseñas de distancia.
2. Tiene una secuencia de comandos "iniciador" que es ejecutable por el usuario y hace un sudo.

De esta forma el usuario puede ver su script de iniciador, examinarlo para ver que solo tiene una sola línea de comando. Pueden ejecutarlo y funciona, pero no tienen permisos para leer el origen del script que está sudorado.

Answer 4

En UNIX, siempre establezco estos scripts y almaceno la información de usuario y contraseña en un archivo que está fuertemente protegido (el árbol de directorios completo no es legible/buscable por usuarios regulares y el archivo solo es leído por el propietario del guion).

Answer 5

Guárdelos en un archivo separado, trivialmente cifrado, y haga un usuario separado en la base de datos con acceso de solo lectura a las tablas necesarias. Si crees que el archivo ha sido leído, entonces puedes cerrar el acceso solo a ese usuario.

Si quieres ser elegante, un programa SUID podría comprobar/proc // exe y cmdline (en Linux), y solo luego lanzar el nombre de usuario.

Answer 6

Si la secuencia de comandos se ejecuta de forma remota desde el servidor.

1. Haga sus vistas informes
2. dar al usuario que inicia sesión en el acceso sólo a seleccionar en el informe considera
3. Sólo almacenar la contraseña.

De esta manera, todo lo que el usuario puede hacer es seleccionar los datos para su informe. Incluso si alguien obtuviera la contraseña, estaría limitado en cuanto a lo que podría hacer con ella.

Answer 7

No estoy seguro de qué versión de Oracle está ejecutando. En la versión anterior de Oracle (pre 9i Advanced Security) algunos DBA tendrían CREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLY y establecerían REMOTE_OS_AUTHENT en verdadero.

Esto significa que su máquina solar remota podría autenticarlo como SCOTT y luego su Oracle DB aceptaría esa autenticación.

Esto es una mala idea.

Como podría visualizar cualquier Windows XP con un usuario local de SCOTT podría iniciar sesión en su base de datos sin una contraseña.

Desafortunadamente, es la única opción que conozco de Oracle 9i DB para no almacenar nombre de usuario/contraseñas en su secuencia de comandos o en cualquier otro lugar al que pueda acceder la máquina cliente.

Cualquiera que sea su solución, merece la pena echar un vistazo a través del Project Lockdown de Oracle antes de comprometerse.

Answer 8

Tengo/tuve un problema similar con los desarrolladores que implementan código SQL en MSSQL (de hecho a cualquier base de datos en ese servidor MSSQL, así que el rol tenía que ser SysAdmin) usando ANT desde un servidor Solaris. Una vez más yo no quería para almacenar el nombre de usuario y contraseña en los archivos Ant build.xml así que mi solución, que sé que no es lo ideal, es el siguiente:

1. almacenar pares de nombre/valor para el nombre de usuario y contraseña en una
archivo
2. cifrar archivos (en Solaris) texto plano y utilizar una frase de paso sólo se conoce a ciertos administradores
3. dejar sólo el archivo cifrado en el sistema Solaris
4. generación Ant.xml dirige una descifrar sudo y solicita la frase de paso, que se introduce por admin
5. fuentes ANT descifrados nombre de usuario al cargar el archivo y la contraseña como variables para la cadena SQL
6. ANT elimina inmediatamente el archivo de texto plano
7. ANT despliega código y salidas

Todo esto ocurre en cuestión de segundos, y el nombre de usuario y la contraseña de sql nunca son visiblemente accesibles en el servidor. A medida que el código es implementado por los administradores permitidos en producción, los desarrolladores nunca necesitan incluirlo en su código.

Estoy seguro de que podría ser mejor, pero ...

JB

Answer 9

Personalmente mantenga las contraseñas en los archivos de configuración, que se distribuyen de forma independiente de la aplicación, y se puede cambiar a la máquina específica/ambiente. En los scripts de shell, puede buscarlos en el script principal.

Sin embargo, en Perl hay una variedad de enfoques. Es posible que desee investigar Getopt::Long para opciones de línea de comandos (y adicionalmente Getopt::ArgvFile para almacenarlas en un archivo de configuración simple), o ver algo como Config::IniFiles para algo con un poco más de poder detrás de él. Estos son los dos tipos que generalmente uso, pero hay otros módulos de archivo de configuración disponibles.

Answer 10

Para almacenar contraseñas, puede realizar una rutina de cifrado de dos pasos, primero con una clave codificada en el script y, opcionalmente, una segunda vez con una clave almacenada en un archivo (que se establece utilizando permisos de archivo para tener acceso restringido) .

En una situación dada, puede usar un archivo de clave (+ clave del script), o si los requisitos de la situación no son tan buenos, puede usar el encyrption usando la clave codificada en el script. En ambos casos, la contraseña se cifraría en el archivo de configuración.

No hay una solución perfecta porque de alguna manera tiene que ser capaz de descifrar y obtener la contraseña de texto claro ... y si puede hacerlo, alguien más también puede hacerlo si tiene la información correcta.

Especialmente en la situación en la que les damos un script en perl (frente a un exe) pueden ver fácilmente cómo se realiza el cifrado (y la clave codificada) ... por lo que debe permitir que la opción use un archivo de claves (que también puede estar protegido por los permisos del sistema de archivos).

Algunos ejemplos prácticos de cómo poner en práctica es here

Answer 11

Es una pena que nunca vi este hilo antes - se ve muy interesante. Agregaré mis dos centavos para cualquier persona que encuentre el hilo en el futuro.

Recomendaría usar la autenticación del sistema operativo en el servidor de db mismo - REMOTE_OS_AUTHENT sigue siendo FALSO.

Si invoca la secuencia de comandos desde otra máquina, configure una clave SSH sin frase y use SSH para obtenerla. A continuación, puede canalizar los resultados de SQL a la máquina que llama y puede procesar esta información aún más.

Esto evita tener que codificar una contraseña en cualquier lugar. Por supuesto, si un administrador malicioso secuestrara la clave sin frase y la usara, también podría acceder a la cuenta de usuario en el host de la base de datos y luego podría realizar cualquier operación que el usuario del DB autenticado por el sistema operativo pudiera.Para mitigar esto, podría reducir al mínimo los permisos de la base de datos para ese usuario del sistema operativo, digamos "solo lectura".

Ingo

Answer 12

En las ventanas crear una carpeta y un archivo que contiene en su interior las contraseñas en texto claro. Establezca el usuario que ejecutará el trabajo programado (secuencia de comandos o lote) como la única persona con acceso de lectura/escritura a esta carpeta y archivo. (eliminar incluso administrador). Para todos los demás scripts, agregue código para leer la contraseña de texto sin cifrar de este archivo restringido.

Esto debería ser suficiente para unos pocos.

Palabras clave: Contraseña hardcoding

Answer 13

Hay soluciones anticipadas comerciales o más como AIM CyberArk puede hacerlo mejor, pero hacerlo de forma gratuita y fuera de la caja, he estado alcancía de nuevo la clave pública/privada SSH porque para empezar, los pares de claves SSH que probablemente ya se crearon cumplen con la política de seguridad; en segundo lugar, los pares de claves SSH ya tienen un conjunto de protocolos estándar para proteger las claves mediante el permiso de archivos, el endurecimiento continuo del sistema (como el cable trampa) o la rotación de teclas.

Esto es cómo lo hice:

1. generar el par de claves SSH, si no todavía. Los pares de claves y el directorio estarán protegidos por el protocolo/permiso predeterminado del sistema. ssh-keygen -t rsa -b 2048

2. utilizar la clave pública SSH para encriptar la cadena y se almacena en mismo directorio .ssh $ echo "secretword" | openssl rsautl-Encrypt -inkey ~/.ssh/salida privado id_rsa.pub -pubin ~/.ssh/secret.dat clave privada

3. uso de ssh para descifrar la clave, y pasar los parámetros a los scripts/AP en el tiempo real. El script/programe para incluir la línea de descifrar en tiempo real: cadena = openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in ~/.ssh/secret.dat

PS - He estado experimentando CyberArk AIM solución sin agente. es una especie de dolor que requiere cambios significativos/cambios de API para la API/script. Te mantendré informado de cómo va eso.