Sto per scrivere le linee guida aziendali su cosa non deve mai apparire nei log (traccia di un'applicazione). In effetti, alcuni sviluppatori cercano di includere quante più informazioni possibile nella traccia, rendendo rischioso archiviare tali log ed estremamente pericoloso inviarli , soprattutto quando il cliente non sa che queste informazioni sono memorizzate , perché non le importa mai e non legge mai la documentazione e / oi messaggi di avvertimento.
Ad esempio, quando si ha a che fare con i file, alcuni sviluppatori sono tentati di rintracciare i nomi dei file . Ad esempio, prima di aggiungere il nome del file a una directory, se tracciamo tutto in caso di errore, sarà facile notare ad esempio che il nome aggiunto è troppo lungo e che il bug nel codice è stato da dimenticare per verificare la lunghezza della stringa concatenata. È utile, ma si tratta di dati sensibili che non devono mai apparire nei log .
Allo stesso modo:
- Password ,
- Indirizzi IP e informazioni sulla rete (indirizzo MAC, nome host, ecc.) ¹,
- Accesso al database,
- Immissione diretta da utente e dati memorizzati
non deve mai apparire nella traccia.
Quindi quali altri tipi di informazioni devono essere banditi dai log? Ci sono delle linee guida già scritte che posso usare?
¹ Ovviamente, non sto parlando di cose come i registri IIS o Apache. Quello di cui sto parlando è il tipo di informazione che viene raccolta con l'unico intento di eseguire il debug dell'applicazione stessa, per non tracciare l'attività delle entità non attendibili.
Modifica: grazie per le tue risposte e i tuoi commenti. Poiché la mia domanda non è precisa, cercherò di rispondere alle domande poste nei commenti:
- Che cosa sto facendo con i log?
I registri dell'applicazione possono essere archiviati in memoria, il che significa sia in chiaro su disco rigido su localhost, in un database, di nuovo in plain, o in eventi di Windows. In ogni caso, la preoccupazione è che quelle fonti potrebbero non essere abbastanza sicure. Ad esempio, quando un cliente esegue un'applicazione e questa applicazione memorizza i registri in un file di testo normale nella directory temp, chiunque abbia un accesso fisico al PC può leggere quei registri.
I log dell'applicazione possono anche essere inviati tramite internet. Ad esempio, se un cliente ha un problema con un'applicazione, possiamo chiederle di eseguire questa applicazione in modalità traccia completa e di inviarci il file di registro. Inoltre, alcune applicazioni potrebbero inviarci automaticamente il rapporto sugli arresti anomali (e anche se ci sono avvertimenti sui dati sensibili, nella maggior parte dei casi i clienti non li leggono).
- Sto parlando di campi specifici?
No. Sto lavorando solo su applicazioni aziendali generali, quindi i soli dati sensibili sono dati aziendali. Non c'è nulla relativo alla salute o ad altri campi coperti da regolamenti specifici. Ma grazie per parlarne, probabilmente dovrei dare un'occhiata a quei campi per alcuni indizi su cosa posso includere nelle linee guida.
- Non è più semplice crittografare i dati?
No. Renderebbe ogni applicazione molto più difficile, specialmente se vogliamo usare la diagnostica C # e TraceSource . Richiederebbe anche di gestire le autorizzazioni, il che non è il modo più semplice di pensare. Infine, se stiamo parlando dei log inviati da un cliente, dobbiamo essere in grado di leggere i registri, ma senza avere accesso ai dati sensibili. Quindi, tecnicamente, è più semplice non includere mai informazioni sensibili nei log e non preoccuparsi mai di come e dove sono memorizzati tali registri.