Número 75
13 de decembro de 2023
|
Para que poidades poñer comentarios na Folla, o meu servidor web vai precisar de se conectar a unha bases de datos usando un contrasinal. A cuestión é: onde gardo ese contrasinal para que o programa o poida usar?
O que fai moita xente nesta situación é, simplemente, gardar o contrasinal na configuración do programa. É unha opción moi cómoda, pero ten un inconveniente moi grave: é moi doado trabucarse e subir a configuración do programa a GitHub co contrasinal incluído, e daquela todo o mundo pode descubrilo, descargalo e facer falcatruadas con todo o acceso que dá o contrasinal.
Non pensedes que ese é un medo infundado: alguén fixo o experimento de filtrar unha clave de AWS e, seis minutos despois, xa había alguén probándoa. Estas filtracións son tan habituais que GitHub analiza todos os commits na busca de claves, igual que fan Amazon e moitas outras empresas que subministran servizos.
Polo tanto, non poñades as claves, contrasinais e tokens de acceso nos ficheiros de configuración, especialmente se os xestionades nun sistema de control de versións. O mellor que podedes facer é usar un almacén de segredos como Hashicorp Vault ou como os que hai nas principais plataformas da “nube”, que gardan as claves e tokens nun sistema cifrado que rexistra e regula os accesos.
Polo tanto podo usar un xestor de segredos para gardar a clave da base de datos e así o meu programa só ten que se conectar e facer unha chamada RPC para obtela. Por suposto, para conectarse ao xestor de segredos o meu programa vai precisar dun token de acceso, pero non hai problema porque podo gardalo no xestor de segredos e… e…
Eh.
Non, non podo gardar o token de acceso ao xestor de segredos no propio xestor de segredos. Semella que non me salvei de ter que xestionar claves eu mesmo.
Polo tanto, se teño que termar eu dos contrasinais e non os podo poñer na configuración do programa, como llos achego?
Hai xente en Internet que recomenda usar un argumento na liña de ordes.
$ ./servidor -contrasinal_bd=oMeuContrasinal
Certamente é unha maneira de facelo, pero non é unha boa maneira porque calquera que teña acceso ao servidor pode ver o contrasinal executando a orde ps
.
$ ps ax
364096 pts/2 S+ 0:00 ./servidor -contrasinal_bd=oMeuContrasinal
Outra xente de Internet pensou que, se non se poden pasar contrasinais na liña de ordes, a mellor maneira de facelo é mediante variables do ambiente (ou “environment variables” para os que falamos todo o tempo en inglés).
$ CONTRASINAL_BD=oMeuContrasinal ./servidor
O problema é que isto ten o mesmo problema que a liña de ordes.
$ ps axe
364487 pts/2 S+ 0:00 ./servidor CONTRASINAL_BD=oMeuContrasinal SHELL=/bin/bash …
Visto isto sempre hai algún que di “pois quitamos o programa ps
do sistema e o problema fica solucionado”, pero iso non é certo porque esa información está dispoñible a través de /proc
.
$ cat /proc/$(pgrep -f servidor)/environ
CONTRASINAL_BD=oMeuContrasinalSHELL=/bin/bash…
O sistema menos malo que eu coñezo para lle pasar contrasinais a un programa é gardar eses contrasinais nun ficheiro cos permisos máis estritos que poidades e pasarlle o nome do ficheiro ao programa para que o lea.
$ ls segredo.txt -l
-rw------- 1 jtarrio primarygroup 19 Dec 11 16:08 segredo.txt
$ ./servidor -segredo=segredo.txt
Hai maneiras de refinar e mellorar este sistema. O ficheiro co segredo pode estar nun sistema de ficheiros cifrado, por exemplo. Os sistemas de contedores coma Docker poden crear directorios que son so accesibles desde dentro do contedor. E sempre é posible usar IPC, descritores de ficheiros, sockets e outras cousas propias de Linux e Unix para tratar de pasar información sen que outra xente a poida ver.
Dito isto, con refinamentos ou sen eles, esta é a maneira na que vou xestionar o contrasinal da base de datos no meu sistema de comentarios.
E vós que pensades? Coñecedes sistemas mellores? Se tal, mandádeme un email para que eu o poña aquí e así todos aprendemos.
A ilustración desta Folla procede dunha edición das Fábulas de La Fontaine.
Anterior: “Outras maneiras de restruturar código” | Índice | Seguinte: “E logo, que pasou?” |
1 comentario