Secretos y claves fuera del código

Cuando se descubre una clave escrita en el código, el primer impulso es borrar la línea y subir el cambio. Eso limpia el archivo actual y deja la clave intacta en cada commit anterior, en cada copia clonada y en cada máquina que alguna vez la descargó. Por eso el orden de la remediación es otro: primero se invalida la clave y se emite una nueva, porque desde ese momento la vieja ya no abre nada; después se saca del código y se limpia el historial si hace falta; y por último se revisa si hubo usos que no corresponden.

Tratar la clave como comprometida desde que se escribió en un repositorio es la decisión correcta, haya sido o no leída por alguien. La debilidad se clasifica como credenciales escritas en el código (CWE-798).

En config-app.txt la clave de la base de datos ya no está escrita: el archivo actual la lee de una variable de entorno. Eso es una mejora y no cierra el hallazgo, porque el repositorio guarda todos los cambios. Para saber hasta dónde llega la exposición hay que mirar el historial y localizar el cambio donde la clave entró.

Abre historial-repo.txt y busca el cambio que añadió la clave de la base de datos. La clave de firma de los tokens, en cambio, sigue en el archivo actual: son dos hallazgos distintos con la misma causa.

Un gestor de secretos resuelve dónde viven las claves y quién las lee, pero no las cambia solo. La rotación periódica limita cuánto sirve una clave que se filtró sin que nadie lo supiera: si se cambia cada 90 días, lo robado deja de funcionar a lo sumo en ese plazo. La política del cliente fija esos 90 días y el inventario trae la fecha del último cambio de cada secreto, así que cuántos están vencidos es un cálculo con la fecha de corte.

Abre gestor-secretos.txt y encargo.txt, donde está la fecha de corte. Cuenta los secretos cuyo último cambio es anterior a 90 días antes de esa fecha.

Cada secreto del inventario tiene sus lectores autorizados: las cuentas de servicio que de verdad lo necesitan. El principio es el de mínimo privilegio aplicado a las claves, y su comprobación es cruzar el registro de lecturas con la lista de autorizados. Una lectura de un secreto por una cuenta que no figura como lectora puede ser una configuración heredada o un acceso indebido; el informe no concluye cuál, pide que se aclare y que se quite el acceso si no se justifica.

Abre accesos-gestor.txt y gestor-secretos.txt y cruza las dos.

La gestión de claves, a nivel de decisión, se reduce a unas pocas reglas: la clave que cifra un dato no se guarda donde está el dato, quien administra los datos no es por defecto quien administra las claves, cada clave tiene un dueño y una fecha de rotación, y hay un plan para el día en que una se pierda o se filtre. Un cifrado con la llave pegada a la puerta no protege nada.