Hai ragione nel senso che è un problema intrattabile molto simile al perché il DRM non può mai essere provabilmente sicuro. È possibile rendere molto difficile per un utente la creazione del registro, ma in definitiva l'applicazione dovrà disporre della chiave necessaria per la firma digitale dei messaggi di registro. Se la chiave esiste sul computer client, può essere rimossa dal computer client.

La vecchia massima di "non c'è sicurezza delle informazioni senza sicurezza fisica" è in gioco.

Quindi molto dipende dal livello di integrità richiesto. Quanto è probabile che gli utenti provino e forgiano il log? Qual è il loro potenziale guadagno? Sarei onesto con il tuo capo su come la sicurezza perfetta non possa essere raggiunta.

Dettagli tecnici della registrazione

Non è esattamente chiaro quindi ho solo pensato di chiarirlo. L'applicazione dovrebbe contenere una chiave privata per la firma. Si consiglia di rendere questo client specifico per compartimentare il rischio. Ci sono modi per rendere più difficile l'estrazione di questa chiave privata, ma è importante essere aperti e trasparenti, quindi non è possibile renderlo impossibile. La chiave pubblica è nota sia all'utente che all'utente per l'autenticazione del registro. L'applicazione firma il messaggio di log e quindi esegue la crittografia con una chiave derivata dalla password dell'utente.

A seconda del livello di sicurezza e del costo del software, qualcuno del team potrebbe suggerire di utilizzare un dongle hardware o un token USB per memorizzare la chiave privata. Tieni a mente che mentre questo rende la chiave più sicura se l'attaccante può inviare un falso messaggio alla chiave per la firma, l'attaccante può modificare il log senza ottenere l'accesso diretto alla chiave.

Dettagli tecnici dell'API REST

Potresti voler riconsiderare il permesso al client di determinare se il token è valido al fine di prevenire attacchi offline. Se il token viene memorizzato crittografato sul computer client, un utente malintenzionato con accesso al filesystem potrebbe estrarre il token crittografato e forzarlo offline fino a quando non scoprirà il token valido.

D'altra parte se il token di autenticazione può essere validato solo dal server, l'unico modo per forzare la password dell'utente è quello di fare una richiesta al server. Ciò consente di limitare il throughput di tali attacchi di forza bruta, bloccare i conti e vietare l'IP se necessario. Diventa più difficile ottenere l'accesso non autorizzato a un token. Ci sono due modi per raggiungere questo obiettivo. Il metodo più semplice se si rendono i token arbitrari sarebbe quello di rendere il token semplicemente una derivazione (PBKDF2) della password dell'utente.

Se il token deve essere indipendente dalla password dell'utente o è predefinito, è possibile crittografarlo e memorizzarlo sul client, ma farlo in modo tale che per qualsiasi password venga restituito un token decrittografato e non sia possibile distinguere i token validi o invalidi senza comunicare con il server.

Se segui questo percorso per evitare perdite di informazioni, i registri dovrebbero essere crittografati non da una chiave derivata direttamente dalla password dell'utente ma da una chiave fornita dal server su richiesta (con un token di autenticazione corretto). In caso contrario, un utente malintenzionato può semplicemente forzare i registri offline e utilizzarli come canarino per identificare la password corretta e quindi il token.

Userei un servizio fornito esternamente (Splunk on Cloud, Papertrail - ce ne sono altri, ma ho usato questi) per garantire un'integrità ragionevole. Oppure usa il tuo, separato dal servizio (basato su una soluzione commerciale o, ad esempio, ELK )

La parte riservata è più difficile. Per il caso Splunk, se si dispone di un elenco predefinito di utenti, è possibile creare visualizzazioni con un contenuto per utente e attribuisce i diritti di lettura agli utenti appropriati. Questo è appena scalabile, però.