Estoy a punto de escribir las pautas de la compañía sobre lo que nunca debe aparecer en los registros (seguimiento de una aplicación). De hecho, algunos desarrolladores intentan incluir la mayor cantidad de información posible en el rastreo, lo que hace que sea riesgoso almacenar esos registros y extremadamente peligroso enviarlos , especialmente cuando el cliente no sabe que esta información está almacenada, porque a ella nunca le importó. y nunca lea documentación y / o mensajes de advertencia.
Por ejemplo, cuando se trata de archivos, algunos desarrolladores están tentados a rastrear los nombres de los archivos . Por ejemplo, antes de agregar el nombre de archivo a un directorio, si rastreamos todo por error, será fácil notar, por ejemplo, que el nombre agregado es demasiado largo y que el error en el código fue olvidar verificar la longitud del cadena concatenada Es útil, pero se trata de datos confidenciales y nunca debe aparecer en los registros .
Del mismo modo:
- contraseñas ,
- Direcciones IP e información de red (dirección MAC, nombre de host, etc.) ¹,
- Accesos a bases de datos,
- Entrada directa del usuario y datos comerciales almacenados
nunca debe aparecer en el rastro.
Entonces, ¿qué otro tipo de información debe ser desterrada de los registros? ¿Hay alguna guía ya escrita que pueda usar?
¹ Obviamente, no estoy hablando de cosas como IIS o registros de Apache. De lo que estoy hablando es del tipo de información que se recopila con la única intención de depurar la aplicación en sí misma, no para rastrear la actividad de entidades no confiables.
Editar: Gracias por sus respuestas y sus comentarios. Como mi pregunta no es demasiado precisa, intentaré responder las preguntas formuladas en los comentarios:
- ¿Qué estoy haciendo con los registros?
Los registros de la aplicación pueden almacenarse en la memoria, lo que significa, ya sea en forma simple en el disco duro en localhost, en una base de datos, nuevamente en forma simple o en eventos de Windows. En todos los casos, la preocupación es que esas fuentes pueden no ser lo suficientemente seguras. Por ejemplo, cuando un cliente ejecuta una aplicación y esta aplicación almacena registros en un archivo de texto sin formato en el directorio temporal, cualquier persona que tenga acceso físico a la PC puede leer esos registros.
Los registros de la aplicación también pueden enviarse a través de Internet. Por ejemplo, si un cliente tiene un problema con una aplicación, podemos pedirle que ejecute esta aplicación en modo de seguimiento completo y que nos envíe el archivo de registro. Además, algunas aplicaciones pueden enviarnos automáticamente el informe de bloqueo (e incluso si hay advertencias sobre datos confidenciales, en la mayoría de los casos los clientes no los leen).
- ¿Estoy hablando de campos específicos?
No. Estoy trabajando solo en aplicaciones comerciales generales, por lo que los únicos datos confidenciales son los datos comerciales. No hay nada relacionado con la salud u otros campos cubiertos por regulaciones específicas. Pero gracias por hablar sobre eso, probablemente debería echar un vistazo a esos campos para obtener algunas pistas sobre lo que puedo incluir en las pautas.
- ¿No es más fácil encriptar los datos?
No. Haría que cada aplicación sea mucho más difícil, especialmente si queremos usar diagnósticos de C # y TraceSource. También requeriría administrar autorizaciones, lo cual no es lo más fácil de hacer. Finalmente, si estamos hablando de los registros que nos envía un cliente, debemos poder leer los registros, pero sin tener acceso a datos confidenciales. Entonces, técnicamente, es más fácil nunca incluir información confidencial en los registros y nunca preocuparse por cómo y dónde se almacenan esos registros.
debugun nombre de archivo, pero no parainfoun nombre de archivo.