¿Se espera que una aplicación de back-end logre datos confidenciales del cliente cuando está en modo de depuración?

¡Esta es una gran pregunta! También soy desarrollador de un producto c ++ que maneja datos de alta sensibilidad, y enfrentamos este dilema casi todos los días.

Cuando un sistema de producción comienza a lanzar alarmas (especialmente las relacionadas con el rendimiento o la configuración, se cree que también se aplican los errores de software / error) a menudo necesitamos que la depuración del nivel de seguimiento de la pila esté activada temporalmente para diagnosticar el problema. Estos registros contienen, inevitablemente, información confidencial: las direcciones IP o los usuarios involucrados en la transacción, a veces partes de los datos, se debe asignar un nombre. A menudo, nuestros clientes no se sienten cómodos dándonos estos registros por razones obvias. Es duro.

Los administradores que actualmente ejecutan su servidor sabrán qué nivel de sensibilidad tienen sus datos, y qué políticas de seguridad de la industria o el gobierno deben seguir al manejarlos (por ejemplo: los datos gubernamentales, financieros y de salud tienen reglas especiales). Es justo que su software tenga la capacidad de producir registros confidenciales, pero los administradores deben tener el control absoluto de cómo, cuándo y dónde se producen y almacenan.

Algunas cosas que puedes hacer:

• Asegúrese de tener mucho cuidado en clasificar correctamente todos los mensajes de error que contienen (incluso potencialmente) información confidencial en el nivel de registro correcto: INFO, ADVERTENCIA, ERROR, DEBUGACIÓN, RASTREO, etc.
• Sea explícito en su documentación sobre los tipos de información confidencial que se incluye en cada nivel de registro. Cuantos más detalles mejor, para que los administradores preocupados por la seguridad puedan hacer su trabajo correctamente.
• Asegúrese de que el nivel de registro DEBUG / TRACE esté desactivado en la configuración predeterminada del software, y que el administrador tenga que ejecutar una serie de advertencias para activarlo (es decir, no es posible hacerlo por accidente).
• Puede enviar registros de nivel DEBUG / TRACE a una secuencia de registro separada (mencionó un registro "seguro" independiente) que se establece de manera predeterminada en el almacenamiento local, lo que dificulta el envío "accidental" de la zona segura o la mezcla en con los registros estándar.
• Envíe su producto con una herramienta de redacción que sepa cómo enmascarar todos los datos sin procesar, nombres de usuario, direcciones IP, etc. de sus registros DEBUG / TRACE con marcadores de posición únicos (cada nombre de usuario / IP único se enmascara con una A, B,. ., AA, etc). A menudo, el nombre de usuario / IP / data real es irrelevante, pero la clave para diagnosticar el problema es que el error solo ocurre con los datos del tipo X, o que la dirección IP A (y solo A) siempre envía sus solicitudes tres veces, o lo que sea . De esta manera, un administrador puede estar seguro de que no se está filtrando nada importante si alguna vez necesita mover estos registros fuera de la zona segura (por ejemplo, enviándolos de nuevo a usted para la depuración).

Conclusión: Creo que es justo que su software tenga la capacidad de registrar información confidencial para fines de depuración, ¡y se lo agradecerá más tarde cuando tenga que depurar un sistema de productos que no funciona correctamente! Pero hace que sea lo más difícil posible activar "por accidente". Confíe en los administradores para conocer sus requisitos de seguridad y facilite su trabajo.

He estado trabajando como probador de penetración desde finales de los 90 y he visto muchas aplicaciones. No es raro que de vez en cuando una aplicación registre datos de identificación del usuario. La mayoría de los desarrolladores declaran que las personas que tienen acceso a los registros son confiables y, por lo tanto, no limitan el registro.

Si esto puede ser un problema, depende del caso de negocios y del nivel de seguridad deseado. En mi opinión profesional el registro de contraseñas nunca está permitido. Puede registrar el primer carácter y la longitud si es necesario. Pero nada más. De lo contrario, compromete el deseo de cifrar las contraseñas en movimiento y durante el descanso.

En entornos de alta seguridad, esto incluso podría aplicarse a otros datos como nombres de usuarios, nombres, direcciones, números de cuentas bancarias, etc.