Log de Auditoria de Uso de Licença de Software Seguro

Question

Pessoal,

Temos um desafio técnico intrigante. Como escrever um arquivo de auditoria seguro que rastreia o uso de um software para que as taxas de licença possam ser baseadas no uso, tornando -o mais acessível para quem o usa menos.

Especificamente, a Tickzoom vende uma plataforma de negociação de geração alfa para fundos de hedge que atualmente custa US $ 2.000/mês para licenciar, incluindo suporte (aumentará em breve para mais do que o dobro). Isso é bom para as instituições, mas muito caro para indivíduos. Os indivíduos geralmente pedem um preço mais baixo em troca de um % dos lucros obtidos usando o software até que possam pagar as taxas fixas.

Nós gostamos dessa proposta. Mas precisamos de uma maneira confiável de auditar o lucro realmente gerado na plataforma e uma maneira de impedir que os usuários "o jogo" a excluam ou substituam o arquivo de auditoria, relatando ganhos mais baixos do que o real.

Este aplicativo foi escrito em C# e essa parte do sistema é ofuscada pelo menos dificultando a decifração do código.

O outro requisito é gravar no arquivo para todas as negociações que ocorrem para permitir uma auditoria mais detalhada no caso de o usuário sentir que há alguma discrepância na taxa total. Dessa forma, os lucros comerciais individuais podem ser comparados com as declarações de corretores.

É claro que assume que o arquivo será criptografado.

Mas alguma idéia sobre como fazê -lo "provas de adulteração"? Especialmente contra uma simples tentativa de exclusão?

Meu primeiro palpite é fazer com que o software sempre exija um arquivo de auditoria preexistente ou se recusará a ser executado.

Então, quando entregamos o software, ele é empacotado com um arquivo de auditoria "vazio", mas que, de fato, possui algum tipo de verificação à prova de adulteração.

Os próximos usuários óbvios da técnica podem tentar "adulterar" o arquivo seria que alguém simplesmente faça backup do arquivo "vazio" original e posteriormente usá -lo para substituir o arquivo de auditoria mais tarde, enganando o sistema a pensar que foi um novo começo.

Talvez isso possa ser resolvido incluído algum tipo de "última atualização de atualização" e um tempo de validade.

Além disso, idéias de solução totalmente diferentes são bem -vindas. Podemos ser forçados neste caso a adicionar uma habilidade "telefone para casa", para que as negociações sejam registradas no nosso servidor central. Mas isso parece desvantajoso e potencialmente adiciona outro ponto de falha em uma aplicação de missão crítica. Geralmente, eles não gostam muito de recursos de "casa do telefone", com boas razões óbvias.

Sinceramente, Waynek

Answer 1

Aqui está um pensamento - sempre que o usuário sai de uma sessão com o software, gera um hash com base no log de auditoria. Criptografar o hash e, em seguida, escreva -o em outro arquivo, talvez oculto entre seus binários ou no registro.

Quando o usuário abrir o aplicativo Em seguida, leia o arquivo de log, re-genera o hash e veja se ele corresponde ao valor gravado. Caso contrário, desligue o aplicativo com uma mensagem de erro "Arquivo de auditoria com" com "erro".

Não é uma prova totalmente idiota, mas seria bastante sólida.

Também, Confira esta pergunta

Answer 2

A declaração do seu problema é:

• Não confiamos no cliente; O cliente pode ser hostil.
• Queremos que o cliente nos envie dados em que possamos confiar.

Não há solução para esse problema. Você também pode dizer "eu quero encontrar dois caras, um chamado Bob, um chamado Bill, de modo que Bob é um pé mais alto que Bill e Bill é um pé mais alto que Bob". Você não encontrará dois caras com essa propriedade.

Você absolutamente não pode confiar em nada que vem de uma máquina que você não possui que possa ser de propriedade de um cliente hostil. Meu conselho é não desperdiçar seu tempo valioso tentando resolver um problema impossível; Passe esse tempo para fazer seu servidor, que você possui e confia, robusto contra clientes hostis.

Answer 3

Não, não acredito que haja algo que você possa fazer além de relatar todos os ganhos em tempo real de volta aos seus servidores, mas mesmo isso tem problemas.

- Editar:

Vocês são apenas opções, como eu vejo, são:

• Converta o sistema em baseado na Web (ou pelo menos de cliente fino), fazendo todas as transações no servidor

Claramente, isso provavelmente é bastante impraticável, se você já é desenvolvido um sistema inteiro baseado local

• Pense em algum esquema elaborado que é "difícil" de quebrar e espero que as pessoas não quebrem

E combine nesse método, algum tipo de perfil que mostra se as lojas estão ganhando X e, de repente, o X-Sigificantamount, você pode determinar que eles nem são mais lucrativos, provavelmente trapaceando o sistema (ou saindo do negócio: ) Mas isso se aproxima de uma invasão de privacidade e pode não ser de todo apropriado.

Praticamente, acho que você precisará pesar os riscos contra o possível lucro ou encontrar outro ângulo sobre como vender para essas pessoas (ou seja, deixa a interface/aplicativo gerenciar X no total de fundos, se for o mesmo versão pro, ou qualquer outra coisa).