Cómo gestionar las credenciales de un script de PowerShell
Una de las tareas comunes de la mayoría de scripts de automatización es la de logearse a servicios que requieren de autenticación. Cuando ésto ocurre nos encontramos con que de algún modo tenemos que gestionar las credenciales de dicho servicio, y en este punto podemos caer en la tentación de crear una magnífica variable $usuario y otra $password donde, en texto planto, almacenar las credenciales de nuestro servicio.
|
|
Esta es el típica configuración que durante la fase de desarrollo puede parecer la más práctica, pero que cuando llega el momento de poner el script en producción podemos ‘olvidar’ corregir. Si además lo juntamos con que estos scripts muchas veces se ejecutan con usuarios con permisos muy elevados (a menudo demasiado para la función que realizan) tenemos una bonita bomba que en cualquier momento nos puede explotar en la cara.
Así que no me enrollo más y pasemos a ver qué herramientas nos da PowerShell para gestionar las credenciales en nuestros scripts.
Un vistazo a los Secure String
Los Secure Strings (System.Security.SecureString) como su nombre indica son datos de tipo string pero con un cifrado aplicado. Este cifrado, en su forma estandar, se realiza con DPAPI, que a grandes rasgos hace que dichos Secure Strings solo puedan ser descifrados por el propio usuario que los generó y en la misma máquina que lo hizo.
En este punto ya podemos ver por donde va la película: si introducimos un password en formato Secure String después seremos capaces de almacenarlo para su próxima ejecución y si alguien se apropia del archivo no será capaz de utilizar el password que hay almacenado en el.
Utilizando Get-Credential para gestionar las credenciales
La forma más sencilla de gestionar las credenciales en PowerShell es utilizando el cmdlet Get-Credential. Si lo ejecutamos veremos que se nos pedirá un usuario y contraseña:
Para seguir con el ejemplo del principio del post llenaremos la credencial con los mismos valores:
Si ahora examinamos el contenido de nuestra variable $credenciales veremos que se trata de un objeto de tipo System.Management.Automation.PSCredential con las propiedades ‘UserName’ y ‘Password’:
Si nos fijamos bien la propiedad ‘Password’ es un Secure String, por lo que si intentamos mostrar la propiedad no la veremos a menos que la volvamos a convertir a texto planto con ConvertFrom-SecureString:
Que como podemos ver nos devuelve el string cifrado.
Guardando las credenciales con Export-Clixml
Vale, ya tenemos nuestro objeto de credenciales creado, pero ahora la idea sería poder guardarlo de algún modo para una futura utilización. Para ello, una buena forma es valerse del cmdlet Export-Clixml, que crea una representación de un objeto con todas sus propiedades dentro de un archivo XML.
|
|
Si abrimos el contenido del archivo XML veremos algo así:
|
|
Importando y utilizando las credenciales almacenadas
Ya llegamos al final del asunto. Ahora que tenemos las credenciales almacenadas solo nos queda ver como podemos utilizarlas. Aún con el ejemplo del principio del post podríamos usar las credenciales así:
|
|
Como podéis ver en vez de utilizar los parámetros -User y -Password utilizamos el parámetro -Credential. La mayoría de cmdlets que autentican contra otros servicios admiten este parámetro, que espera un objeto PSCredential para realizar la autenticación en vez de pedir por separado usuario y password. ¿Quiere decir eso que si el cmdlet no admite la entrada de objetos PSCredential nos vemos obligados a utilizar usuario y contraseña en texto plano?
|
|
Evidentemente no, los objetos PSCredential disponen de un método con el que podemos acceder a las credenciales descifradas, con lo que podríamos acceder al password tal y como vemos en el ejemplo con $credencial.GetNetworkCredential().password, así que no hay excusa para seguir utilizando credenciales “hardcodeadas” en nuestros scripts.
Conclusión
¿Utilizando este método estamos totalmente protegidos? Realmente no, porque como hemos visto el cifrado reversible está vinculado al usuario que ha generado el secure string, por lo que si nuestra cuenta queda vulnerada (o una cuenta de administrador de nuestra máquina que pueda resetear nuestro password) podremos tener un problema, pero desde luego reduce el vector de ataque notablemente y puede evitar que por un despiste se filtre nuestro script y con ello las credenciales que éste utilizaba.