Secretos: claves, almacenamiento y rotacion

La leccion anterior termino en una contrasena. Las contrasenas son los secretos que escribe una persona; esta leccion trata de los secretos que usa un programa cuando nadie mira: claves de API, contrasenas de base de datos, claves de firma, tokens para otros servicios. Fallan de forma distinta a las contrasenas humanas. Nadie reutiliza la contrasena de una base por pereza, nadie la olvida y nadie elige una debil porque sea mas facil de teclear. Fallan porque se copian a sitios que nunca debieron guardarlas y porque viven para siempre.

Un secreto confirmado en un repositorio no es un archivo que puedas borrar. Git guarda instantaneas, y cada instantanea que contuvo la clave la sigue conteniendo. Quitar la linea en un commit nuevo la quita del estado actual y no cambia nada de la historia. Incluso un force-push que reescribe la rama deja los objetos antiguos accesibles por el reflog, por cualquier fork, por cualquier clon ya hecho y durante un tiempo por el almacenamiento del propio proveedor. Eso no es un defecto de Git; es exactamente para lo que sirve una historia direccionada por contenido. La conclusion practica es la que mas tiempo cuesta aceptar a los equipos: para cuando lo notas, hay que tratar la credencial como publica. Encontrar una clave filtrada en la historia y confirmar que sigue siendo alcanzable. La busqueda es la parte facil.

$ git log --all -S 'AKIA' --oneline
9f2c1ab  remove keys from config
4d7e0f3  add deployment config

$ git show 4d7e0f3:config/prod.env | grep -c AKIA
1

$ git rev-list --all --count
8421

# the commit is still reachable: history is append-onlyEncontrar una clave filtrada en la historia y confirmar que sigue siendo alcanzable. La busqueda es la parte facil.

Las variables de entorno son el consejo habitual, y son una mejora, pero se venden de mas. Lo que aportan de verdad: el secreto no esta en el repositorio, no esta en la imagen del contenedor y difiere entre preproduccion y produccion sin tocar el codigo. Lo que no aportan: ninguna clase de aislamiento. En Linux el entorno de un proceso en ejecucion se lee desde /proc, asi que cualquier proceso que corra con el mismo usuario puede leer la clave. Acaba en los volcados de fallo y en los procesos hijos que lanzas, y asi es como una clave del servicio de pagos aparece en un log de una tarea que no tiene nada que ver. Y en muchas plataformas es visible en la pantalla de configuracion del panel, es decir, visible para cualquiera con permiso de despliegue. Las variables de entorno mueven un secreto de un sitio malo a uno mejor. No son una caja fuerte. Una variable de entorno la puede leer todo lo que ya pueda ejecutarse como ese usuario. No es nada, pero no es secreto. La derivacion de claves es el puente del secreto humano a la clave criptografica. Una contrasena no se usa directamente como clave AES, porque las contrasenas son cortas y de baja entropia y las claves deben ser uniformemente aleatorias. Una funcion de derivacion toma la contrasena, un salt y un parametro de coste deliberadamente caro, y produce una clave de la longitud correcta. La misma idea aparece en tres sitios a la vez, y merece la pena ver que es la misma idea: derivar una clave de una frase de paso, derivar un hash de contrasena resistente a pruebas y derivar una clave por registro a partir de una clave maestra para que una clave de registro filtrada no exponga el resto. El parametro de coste es lo que hace que cada una resista a un atacante que ya tiene el material almacenado. El cifrado de disco tiene un modo de fallo concreto que conviene nombrar. Si la clave que abre el disco esta en la misma maquina, o se obtiene automaticamente al arrancar desde un archivo de configuracion, entonces tiene los datos cualquiera que pueda arrancar esa maquina o leer ese archivo. Por eso el cifrado de disco completo protege un portatil robado y no aporta casi nada en un servidor en marcha al que un atacante ya llego.

in transit     TLS between client and service      a key you never see
at rest        disk encryption, KMS envelope      server holds the key
tokenized      provider keeps the card number    your database holds a token

PCI DSS 4.0 requires cardholder data encrypted in transit and at rest

None of the three protects against a valid account using the API.Tres capas que se quieren decir cuando se afirma que los datos estan cifrados. Protegen de cosas distintas y ninguna protege de una peticion valida.