Descubres que los registros de la aplicación contienen números de tarjeta completos y contraseñas en texto plano. ¿Cuál es la prioridad de corrección?
Respuesta breve
Los datos sensibles nunca deberían llegar a los registros: redacta o enmascara en el origen primero para detener la hemorragia, luego remedia los registros históricos y restringe el acceso. PCI DSS prohíbe almacenar así los PAN completos y los CVV, y las contraseñas nunca deberían registrarse. Unos registros «internos» siguen siendo un objetivo de primer orden. Cifrar o restringir el acceso al almacén sigue dejando secretos en texto plano en los registros, accesibles para cualquiera con permiso de lectura — copias de seguridad, pipelines de SIEM y administradores los ven todos.
La trampa de esta pregunta es tratar los secretos registrados como un problema de control de acceso cuando en realidad es un problema de minimización de datos. Esos datos no deberían estar ahí en absoluto — así que el primer movimiento es dejar de crearlos.
Por qué redactar en el origen va primero
Los registros no son una caja fuerte privada. Se envían a SIEM, se copian en copias de seguridad, se replican entre regiones, los indexan herramientas de búsqueda y los leen ingenieros de guardia. Cada una de esas copias es ahora un almacén de credenciales y datos de titulares de tarjeta en texto plano. PCI DSS prohíbe explícitamente almacenar PAN completos de esta forma y prohíbe almacenar datos de autenticación sensibles como los CVV tras la autorización; las contraseñas nunca deberían registrarse de ninguna forma. Así que el paso uno es enmascarar o redactar en el origen — impedir que la aplicación escriba los campos sensibles. Eso detiene la hemorragia. Solo entonces remedias los registros existentes (purgar o limpiar las entradas históricas, incluidas copias de seguridad y copias aguas abajo) y revisas/restringes quién puede acceder a ellos.
Por qué los distractores son incorrectos
- Dejarlo así — los registros son internos. «Interno» no es una frontera de seguridad. Personal interno, una cuenta comprometida, un bucket mal configurado o una brecha convierten esos registros en una divulgación. Es la respuesta de no hacer nada.
- Cifrar todo el servidor, seguir registrando los datos. El cifrado en reposo protege contra discos robados, pero la aplicación, el SIEM, cada administrador y cada copia de seguridad siguen leyendo los secretos en texto plano. Los secretos siguen ahí. Has cerrado la habitación pero dejado la caja fuerte abierta dentro.
- Simplemente restringir quién puede leer los registros. Endurecer las ACL es un buen paso de apoyo, pero por sí solo deja secretos activos en los registros, propagándose por pipelines y copias de seguridad, a una mala configuración de la exposición.
Qué está sondeando el entrevistador
Quiere el instinto de minimización de datos: arreglar el origen antes que los síntomas. La buena respuesta nombra PCI DSS, reconoce que «interno» y «cifrado en reposo» no resuelven el texto-plano-en-registros, y secuencia correctamente — dejar de escribirlo, luego limpiar lo que ya está ahí, luego endurecer el acceso.
Posibles preguntas de seguimiento
- ¿En qué punto de la pila implementarías la redacción para que nunca se escriba nada sensible?
- ¿Qué dice concretamente PCI DSS sobre el almacenamiento de PAN y datos de autenticación?
- ¿Cómo se habrían propagado los datos más allá del servidor de registros, y cómo lo limpias?