Quali informazioni non devono mai apparire nei registri? [chiuso]

Sto per scrivere le linee guida dell'azienda su ciò che non deve mai apparire nei registri (traccia di un'applicazione). In effetti, alcuni sviluppatori cercano di includere quante più informazioni possibili nella traccia, rendendo rischioso archiviare quei registri ed estremamente pericoloso inviarli , soprattutto quando il cliente non sa che queste informazioni sono memorizzate, perché non le è mai importato e non leggere mai documentazione e / o messaggi di avviso.

Ad esempio, quando si tratta di file, alcuni sviluppatori sono tentati di tracciare i nomi dei file . Ad esempio, prima di aggiungere il nome del file a una directory, se tracciamo tutto in errore, sarà facile notare ad esempio che il nome aggiunto è troppo lungo e che il bug nel codice era dimenticare di verificare la lunghezza del stringa concatenata. È utile, ma si tratta di dati sensibili e non deve mai apparire nei registri .

Nello stesso modo:

• Password ,
• Indirizzi IP e informazioni di rete (indirizzo MAC, nome host, ecc.) ¹,
• Accessi al database,
• Input diretto da parte dell'utente e dati aziendali memorizzati

non deve mai apparire in traccia.

Quindi quali altri tipi di informazioni devono essere banditi dai registri? Ci sono già delle linee guida già scritte che posso usare?

^{¹ Ovviamente, non sto parlando di cose come IIS o registri Apache. Quello di cui sto parlando è il tipo di informazioni che vengono raccolte con l'unico intento di eseguire il debug dell'applicazione stessa, non di tracciare l'attività di entità non attendibili.}

Modifica: grazie per le risposte e i commenti. Poiché la mia domanda non è troppo precisa, proverò a rispondere alle domande poste nei commenti:

• Cosa sto facendo con i registri?

I registri dell'applicazione possono essere archiviati in memoria, il che significa sia in chiaro sul disco rigido su localhost, in un database, di nuovo in chiaro, o in Eventi di Windows. In ogni caso, la preoccupazione è che tali 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 semplice nella directory temporanea, chiunque abbia un accesso fisico al PC può leggere quei registri.

I registri 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 avvisi 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 i dati aziendali. Non vi è nulla di correlato alla salute o ad altri settori coperti da normative specifiche. Ma grazie per parlarne, probabilmente dovrei dare un'occhiata a quei campi per alcuni indizi su cosa posso includere nelle linee guida.

• Non è più facile crittografare i dati?

No. Renderebbe ogni applicazione molto più difficile, specialmente se vogliamo usare la diagnostica C # e TraceSource. Richiederebbe anche la gestione delle autorizzazioni, che non è la cosa più semplice da pensare. Infine, se stiamo parlando dei registri che ci vengono inviati da un cliente, dobbiamo essere in grado di leggere i registri, ma senza avere accesso ai dati sensibili. Quindi tecnicamente, è più facile non includere mai informazioni sensibili nei registri e non preoccuparsi di come e dove sono archiviati quei registri.

Credo che il modo migliore per gestirlo sia trattare i file di registro come solo un'altra interfaccia utente per l'applicazione. Il fatto che le informazioni siano archiviate in file di testo non rende il contenuto diverso dalle informazioni visualizzate sulle schermate normali nell'interfaccia utente.

Pensa a come proteggere le stesse informazioni se fossero visualizzate in una normale interfaccia utente. Dovresti identificare chi era l'utente e quindi esporre solo le informazioni che questo utente era autorizzato a vedere.

Le informazioni nei file di registro devono essere trattate allo stesso modo. Devi prima rispondere esattamente a chi dovrebbe essere autorizzato per vedere il file di registro e quali informazioni dovrebbero essere autorizzate a vedere.

Passare in giro file di registro mal progettati è un enorme rischio per la sicurezza. Non credo che otterrai una buona soluzione inserendo nella lista nera alcuni tipi di dati. Una strategia migliore è di autorizzare ciò che potrebbe andare in ogni file di registro e progettare i file di registro dal basso verso l'alto da quello.

I dati della carta di credito non devono mai essere registrati.

Numeri di identificazione (come SSN negli Stati Uniti o Teudat Zehut # in Israele).

Nomi di computer di rete, percorsi di condivisione di rete.

Informazioni sanitarie di identificazione personale coperte dalla legge sulla portabilità e responsabilità dell'assicurazione malattia del 1996 (HIPAA). Questo articolo elenca i seguenti esempi:

• Richieste di assistenza sanitaria o informazioni sull'incontro con l'assistenza sanitaria, come la documentazione delle visite del medico e le note fatte da medici e altro personale del fornitore;
• Consulenza in materia di pagamento e rimesse sanitarie;
• Coordinamento delle prestazioni sanitarie;
• Stato delle richieste di assistenza sanitaria;
• Iscrizione e disiscrizione in un piano sanitario;
• Idoneità per un piano sanitario;
• Pagamenti del premio del piano sanitario;
• Certificazioni e autorizzazioni di riferimento;
• Primo rapporto di infortunio;
• Allegati sulle indicazioni sulla salute.

se la sicurezza è un problema, crittografare il file di registro

Dalla cima della mia testa ....

Le informazioni sulla carta di credito non devono essere contenute nei registri. I dati SSN (o SIN) non devono essere nei log.

... ovviamente ci sono delle eccezioni, se vi capitasse di lavoro per un po 'di dati centrale per una società di carte di credito o un ente governativo che gestisce i dati SIN, allora si potrebbe avere per accedere, perché è la carne principale di ciò che si stai elaborando / gestendo.

Si ma.

Per eseguire il debug di alcuni problemi sono necessari dati reali.

Quindi devi giocare un gioco di equilibrio: devi infatti discutere e concordare con i tuoi principali clienti cosa considerano dati riservati o sensibili e cosa no. Se diversi clienti non sono d'accordo, prendi lo scenario peggiore per ogni aspetto, a meno che tu non possa giustificarlo a quei clienti che potrebbero esagerare nell'etichettare tutto ciò che è sensibile.

Ho lavorato nel controllo del traffico aereo, finanziario e bancario. In ogni situazione ci sono dati sensibili. Esistono attività per le quali è inevitabile gestire dati sensibili, in quei casi è necessario assicurarsi il più possibile di lavorare con persone affidabili. Questo rischio può essere in qualche modo mitigato dalle clausole legali da concordare prima di accedere a tali dati (accordi di non divulgazione, utilizzo dei dati solo per validi motivi commerciali, accesso limitato ai dati, sanzioni penali per mancato rispetto o applicazione degli accordi ...) - e processi pertinenti che consentano di tracciare tali aspetti.

Se i dati sono fondamentali, è necessario pagare il prezzo per la creazione di sistemi che proteggano l'integrità, la coerenza e la sicurezza di questi dati.

Detto questo, hai ragione a porre la domanda "quali dati". Veramente rispondi tu stesso: la maggior parte è legata al mondo degli affari. Quindi chiedi ai tuoi clienti se non riesci a rispondere a te stesso, tenendo presente tutto quanto sopra e conservando un modo per identificare e risolvere i problemi che potrebbero sorgere.

Direi, registra i messaggi che sembrano divertenti mentre stai programmando. Non li troverai divertenti lungo la linea e saranno lì per sempre - proprio come quel post sconsiderato blog / facebook / twiter!

Mantieni noiosi i messaggi di registro :)