El error más repetido
Casi todos los incidentes de seguridad de origen interno empiezan igual: una clave de acceso, un token o una contraseña que alguien dejó en un fichero de configuración "solo para probar". El repositorio era privado, así que parecía seguro. Pero un repositorio se clona, se comparte, se sube a otros sitios y guarda su historial para siempre. Borrar el fichero no borra el secreto: sigue en el historial.
Separar el nombre del valor
La regla es sencilla y no tiene excepciones:
- En el repositorio (y en el registro) se escribe qué secretos necesita cada aplicación, por su nombre: "la aplicación de pedidos necesita la contraseña de su base de datos".
- En un gestor de secretos se guarda el valor, cifrado, con control de quién puede leerlo.
- En el despliegue, la plataforma busca cada valor por su nombre y lo entrega a la aplicación en ejecución. El valor nunca toca el repositorio ni los registros.
Lo que viene con esa separación
- Rotar es fácil: se cambia el valor en el gestor y se redespliega. El código no cambia.
- Se sabe quién accede: el gestor registra cada lectura.
- Cada entorno tiene sus propios valores con el mismo nombre, así el código es idéntico en desarrollo y en producción.
- Lo que no existe no se puede filtrar: si alguien comparte el repositorio, comparte nombres, no claves.
Y una comprobación automática
Por mucho que la regla esté clara, alguien la romperá un día por descuido. Por eso la plataforma revisa cada cambio buscando cosas con forma de secreto (claves, tokens, contraseñas) y lo rechaza antes de que se guarde. Es más barato un rechazo a tiempo que una rotación de emergencia.
Con el registro y los secretos resueltos, falta la tercera fuente de verdad: la que cuenta qué ha pasado con cada aplicación.
Cómo lo aplicamos: Ingeniería de Plataforma.