Pregunta

La gente,

Tenemos un desafío técnico intrigante. Cómo escribir un archivo de auditoría seguro que el uso de pistas de un software para que los derechos de licencia se puede basar en el uso haciendo así más asequible para aquellos que lo utilizan menos.

En concreto, TickZoom vende una plataforma de operaciones de generación de alfa para los fondos de cobertura, que actualmente cuesta $ 2.000 / mes para la licencia incluyendo soporte (aumentará pronto a más del doble). Eso está bien para las instituciones, pero demasiado caro para las personas. Las personas suelen pedir un precio más bajo a cambio de un% de los beneficios obtenidos mediante el software hasta que pueden permitirse el lujo de pagar las cuotas fijas.

Nos gusta esa propuesta. Sin embargo, necesitamos una manera confiable para auditar el beneficio efectivamente generados en la plataforma y una manera de evitar que los usuarios de "juego" mediante la supresión o sobrescribir el archivo de informes de auditoría de ese modo los ingresos más bajos que los reales.

Esta aplicación está escrita en C # y esta porción del sistema se ofuscado al menos por lo que es difícil de descifrar el código.

El otro requisito es de escritura en el archivo para cada operación que se produce con el fin de permitir una mayor profundidad en la auditoría en el caso de que el usuario siente que hay alguna discrepancia en la tarifa total. De esta manera, los beneficios comerciales individuales se puede comparar con las declaraciones de los agentes.

Es, por supuesto, supone que el archivo se cifrará.

Sin embargo, cualquier ideas sobre cómo hacer que sea "a prueba de manipulaciones"? Especialmente contra un simple intento de eliminación?

Mi primera suposición es hacer que el software siempre se requiere un archivo de auditoría preexistentes o que se niegue a ejecutar.

A continuación, cuando entregamos el software que está empaquetado con un archivo de auditoría "vaciar", pero que, de hecho, tiene algún tipo de prueba de falsificaciones de verificación.

Los siguientes usuarios técnica obvia podría tratar de "sabotaje" con el archivo sería para alguien que simplemente copia de seguridad de ese original "vaciar" el archivo y luego lo utilizan para sobrescribir el archivo de auditoría posterior engañando así al sistema haciéndole creer que se trataba de una empezar de nuevo.

Tal vez eso se puede resolver mediante incluido algún tipo de "última actualización de marca de tiempo" y una fecha de caducidad.

Además, ideas totalmente diferentes soluciones son bienvenidos. Podríamos vernos obligados en este caso para agregar una capacidad de "llamar a casa", por lo que las operaciones sesión de usuario en nuestro servidor central. Pero eso parece desventajosa y, potencialmente, añade otro punto de fallo en una aplicación de misión crítica. Por lo general no les gusta mucho "llamar a casa" cuenta con buenas razones obvias.

Atentamente, Waynek

¿Fue útil?

Solución

Aquí es un pensamiento - cada vez que el usuario sale de una sesión con el software, generan un hash basado en el registro de auditoría. Cifrar el hash, y luego escribirlo en otro archivo, tal vez escondido entre sus binarios, o para el registro.

Cuando el usuario abre la aplicación siguiente, lee el archivo de registro, volver a generar el hash y ver si coincide con el valor registrado. Si no es así, cerrar la aplicación con un "archivo de auditoría manipulado" mensaje de error.

No engañar totalmente a prueba, pero sería bastante sólido.

Además, echa un vistazo a esta pregunta

Otros consejos

La declaración de su problema es:

  • no confiamos en el cliente; el cliente podría ser hostil.
  • queremos que el cliente para enviar datos de los que podemos confiar.

No hay una solución a este problema. Es lo mismo que decir "Quiero encontrar dos tipos, uno llamado Bob, uno llamado Bill, de tal manera que Bob es un alto pie que Bill y Bill es un alto pie que Bob". No vas a encontrar dos tipos con esa propiedad.

Es absolutamente positiva no puede confiar en nada de lo que viene de una máquina que usted no posee que podrían ser propiedad de un cliente hostil. Mi consejo es que no pierda su valioso tiempo tratando de resolver un problema imposible; pasar ese tiempo en hacer que su servidor, lo que lo hace propio y hacer confianza, robusto frente a clientes hostiles.

No, no creo que haya nada se puede hacer otra cosa que informe de todos los ingresos en la espalda en tiempo real a sus servidores, pero incluso eso tiene problemas.

- Editar:

Eres únicas opciones, como yo lo veo, son:

  • Convertir el sistema (o al menos de cliente ligero), con lo que todas las transacciones en el servidor basado en la web

Es evidente que este es probablemente bastante poco práctico, si ya está desarrollado un sistema de base local entera

  • pensar en un esquema elaborado que es "duro" para romper y espero que la gente que no se rompen

Y se combinan dentro de este método, algún tipo de perfiles que muestra si las tiendas están ganando X, y de repente X-sigificantAmount, se puede determinar que no son rentables incluso más tiempo, por lo tanto, probablemente engañar al sistema (o salir de los negocios :) Pero esta raya en toda una invasión de la privacidad, y puede no ser del todo apropiado.

En la práctica, creo que tendrá que sopesar los riesgos contra el posible beneficio, o encontrar otro punto de vista sobre cómo vender a estas personas (es decir, sólo dejar que la interfaz / aplicación en sí logran X en el total de fondos, si se llega , pronta para la versión Pro, o lo que sea).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top